The Cafes » Programming

I’m noticing a common anti-pattern of defining declarative DSLs in Turing complete languages — specifically Python — to avoid the overhead of learning new syntax and tools, XML or JSON, and just reusing the Python compiler: Blaze, Airflow, dataswarm. datasets, register_type_info.py for UPM semantic tree, Or Gradle with Ruby.

This is a very bad tech debt that causes massive problems (security, indeterminancy, irreproducibility) and has heavy cost. Never do this. It always leads to a huge expensive effort to redefine the language as its own thing (not Python) that still looks like python, and the team ends up writing a complete parser in addition to everything else. XML is not that hard. Nut up and learn it.

Do not write declarative configs in a Turing complete language.
Do not invent Python subsets for config files. Starlark

How many times have you seen someone use a hammer to pound screws because they are a hammer expert, they are comfortable with hammers, they don’t know how to use a screwdriver, and they don’t want to take a week to learn how to use a screwdriver?

Happy 20th Birthday Java! Next year I’ll buy you a drink. InfoWorld has published some of my thoughts on the occasion, “Java at 20: How it changed programming forever”.

java.util.Arrays uses quicksort (actually dual pivot quicksort in the most recent version) for primitive types such as int and mergesort for objects that implement Comparable or use a Comparator. Why the difference? Why not pick one and use it for all cases? Robert Sedgewick suggests that “the designer’s assessment of the idea that if a programmer’s using objects maybe space is not a critically important consideration and so the extra space used by mergesort maybe’s not a problem and if the programmer’s using primitive types maybe performance is the most important thing so we use the quicksort”, but I think there’s a much more obvious reason.
(more…)

In my day job I work with a lot of very smart developers who graduated from top university CS programs such as MIT, CMU, and Chicago. They cut their teeth on languages like Haskell, Scheme, and Lisp. They find functional programming to be a natural, intuitive, beautiful, and efficient style of programming. They’re only wrong about one of those.
(more…)

I hate 1% problems. No this isn’t an OWS slogan. I’m thinking of those code issues that really aren’t a problem 99% of the time, but when they bite, they’re really hard to debug and they cause real pain. Several common cases in Java:

1. Using java.util.Date or java.util.Calendar instead of JodaTime.
2. Not specifying a Locale when doing language sensitive operations such as toLowerCase() and toUpperCase().
3. Not escaping strings passed to SQL, XML, HTML or other external formats.

What I hate most is that it’s really, really hard to convince other developers that these are problems they should take seriously. (more…)