Reason 1: Strong, static, compile time typing

I used to take Pythonistas at their word that they didn’t actually need strong, static compile time type checking. That was before I spent over a year writing Python more or less full time.

I am constantly blocked by not understanding which variables have which types. I am frequently spelunking through many levels of code and popping open the debugger to find out what type a variable actually has when. Not having explicit, enforced types makes code far harder to understand and edit.

Corollary: var is very bad idea for Java and should not be used.

This is well known in the Python community today. PEP 484 is basically an admission that inline typing is a necessity for robust code, and Guido has admitted as much. It’s why large Python shops like Meta and Google have invested in tools like Pyre and Pytype to add strong typing to the language. These tools help, but they’re not as good as Java’s strong, reliable, static type declarations and type checking.

Reason 2: Checked exceptions

This entry was posted on Sunday, December 10th, 2023 at 1:59 pm and is filed under Programming. You can follow any responses to this entry through the Atom feed. You can skip to the end and make a comment. Pinging is currently not allowed.

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? Maybe not so much if you’re a carpenter, but if you’re a software developer it happens all the time.

I’ve noticed 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. Instead programmers define the DSL as a Python library and reuse the Python compiler with predictable results. Blaze/Bazel, Airflow, dataswarm, and many other projects have gone down this road. Gradle made the same mistake, only with Ruby instead of Python.

This is massive 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. <cough>Starlark</cough>

This entry was posted on Sunday, April 16th, 2023 at 6:01 am and is filed under Programming. You can follow any responses to this entry through the Atom feed. You can skip to the end and make a comment. Pinging is currently not allowed.

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”.

This entry was posted on Thursday, May 21st, 2015 at 6:21 am and is filed under Java. You can follow any responses to this entry through the Atom feed. You can skip to the end and make a comment. Pinging is currently not allowed.

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.

This entry was posted on Saturday, March 30th, 2013 at 6:51 am and is filed under Java. You can follow any responses to this entry through the Atom feed. Both comments and pings are currently closed.

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.

This entry was posted on Sunday, January 20th, 2013 at 6:47 am and is filed under Java. You can follow any responses to this entry through the Atom feed. Both comments and pings are currently closed.