Programming on valium

[fare]

Google AutoValue: what in Lisp would take a few hundred lines max in Java is over 10000 lines not counting many, many libraries. Just WOW!

Thus, Java has macros too, it's just that they are 10 to 100 times more programmer-intensive than Lisp macros. I feel like I'm back in the dark ages.

Even for "normal" programming without new macros, a program

Comments

Concur...

[ext_2984214]

We have at least 50 years experience telling us that programming in languages freer of odd side effects and syntax is more effective than using languages with obtuse, overblown syntax and cranky semantics. Yet fools continue to design and promote them, often using wild explanations to attempt to promote their flaws as features (Bjarne Stroustrop and C++ have elevated this to an art form, in whose footsteps I see Guido Van Rossum following). And our industry continues to use them. I despair of any change other than that of my own habits. I'm very happy with my Lisp-based languages, thank you.

"Java is a DSL for taking large XML files and converting them to stack traces"

[fare]

The Perils of Partially Powered Languages disses the combination of Java with external DSLs like XSLT or Ant, in favor of internal languages such as Haskell's xml-hamlet. I've discussed this case before. To me, not only XSLT or Ant are partially powered languages - so is Java.

Memoization

[fare]

Sometimes, you really want Memoization, but while in Lisp it's a trivial hundred-odd lines of heavily-commented code (as in my fare-memoization), it's a lot of code in Java, that doesn't quite automate as much (see, e.g., Guava's CacheBuilder or Interner), because not only there are no macros, but there is no easy tuple type to represent the arguments and you have to declare a new value type (hopefully using AutoValue) for every new function signature for which you want to memoize a function. Ouch. Time to add AutoMemoize to the Google auto library?

Side-effects combined with high-costs of encapsulation

[fare]

Because functional programming is expensive (the simplest function takes fives lines instead of 20 characters), and because macros are unaffordable (see AutoValue above), most people eschew encapsulation of side-effects within higher-order functions or macros, and instead manually apply "design patterns", becoming human compilers. Of course, humans are bad compilers and this is the source of a lot of bugs, ever repeated, that would otherwise have long been encapsulated and automated away. When in addition, these manually-macro-expanded things include side-effects, and especially so in the presence of concurrency, debugging and maintenance become nightmares.

And Java programmers think this is "normal".

Java Shop Politics

[fare]

Shriram K linked to this post on the social effects of Java:
https://michaelochurch.wordpress.com/2012/04/13/java-shop-politics/