Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Why I love Common Lisp and hate Java (2012)

kuomarc.wordpress.com

Post reply on HN
Print view View original

121–130 of 171 posts

Re: Why I love Common Lisp and hate Java (2012)

#121

Post by lmm »

nayuki wrote: post #7

It is a recurring theme for people to point out how verbose a hello world program is in Java: class HelloWorldApp { public static void main(String[] args) { System.out.println("Hello World!"); } } For argument sake, let's compare it not to Lisp but to Python instead: print("Hello World!") Once you get proficient in a language and start writing larger programs, your perspective can change entirely. What appears to be…

> In Java the top level only contains classes and interfaces. All functions must be put inside a class, and I believe this design simplifies conceptual understanding.

Strongly disagree. (Traditional) Java has no way to represent a function or a class as a first-class entity and it suffers for it. In Python functions and classes are plain old values (and indeed objects) and any value can live at top level in the module.

> * Python always executes the top level, so you end up with awkward idioms like: if __name__ == "__main__": main(sys.argv)

How is that any more "awkward" than the Java way? It's fewer lines of ceremony in all cases as far as I can see.

> * The "public" keyword might seem like noise, but in Python you denote private by prefixing the name with one or two underscores.

So Python has a) a better default (it's not that Java doesn't have a default visibility level, it's just such a spectacularly useless one that it never sees use) b) a concise symbolic syntax for something that's used extremely commonly, which is the right approach: http://www.lihaoyi.com/post/StrategicScalaStyleConcisenessNa...

> * Do you really want print() to be so easily accessible in the top-level namespace? It seems to me that the bigger an application gets, the worse it is to easily litter the codebase with print statements.

Big applications will always have their own frameworks and no possible default set of imports makes sense for big applications (Java's default imports from java.lang. get in the way for big applications too). But a good language should work for small scripts as well as big applications, so having print in there by default makes sense. (I can sympathise with having a no-default-imports option or something like Haskell's custom preludes).

> * You still eventually need to learn what "@staticmethod" means in Python.

My 10+ years of Python say otherwise. You really don't.

Re: Why I love Common Lisp and hate Java (2012)

#122

Post by lmm »

reality_czech wrote: post #91
RangerScience wrote: post #64

I've recently come around on Java (although I'll still rarely choose it), mostly due to the idea that "all things get complicated, so what matters is how you manage that complexity". Java started to "click" when I realized how much you build objects out of other objects like layers of an onion, just adding a bit at each step, and it clicked a bunch more as I understood Spring's bean system, which itself clicked more…

Java has been gradually eating all the good parts of Scala. So far, it's eaten lambdas, map / reduce / fold functions, option types, raw string literals, the concept of a built-in REPL, type inference for local variables, and default methods in interfaces (which is kind of like mixins). Pattern matching and type classes are on the menu, but not yet formally merged into Java. So what does Scala have left? Operator ove…

> Java has been gradually eating all the good parts of Scala. So far, it's eaten lambdas, map / reduce / fold functions, option types, raw string literals, the concept of a built-in REPL, type inference for local variables, and default methods in interfaces (which is kind of like mixins).

If you adopted Scala 5 years ago, you could have had all the good stuff Java has today, 5 years ago. If you adopt Scala today you can have all the good stuff Java will be getting in the next 5 years, today.

> Pattern matching and type classes are on the menu, but not yet formally merged into Java.

How many years or decades will those "formalities" take? Java language enhancements have a history of taking much longer than originally claimed.

> Operator overloading, which tends to lead to unclear code.

The problem with traditional operator overloading is that you have to memorize which symbol corresponds to which magic method name (I can never remember what method * calls in Python, for example). Scala avoids that because it doesn't actually have operator overloading; rather, operators are just normal methods that you call in the normal way.

> The ability to embed XML into code (why?).

Already moved into an optional library, being dropped entirely in the next version.

> A collections library which is nightmarishly complex. (See https://yz.mit.edu/wp/true-scala-complexity/ )

Replaced in the next version. (And the complex parts were only ever for doing things that are completely impossible in any other language).

> So what does Scala have left?

Higher-kinded types (which let you represent secondary effects in a uniform way - obvious things like validation or async, but also custom effects like database transactions or an audit trail). Uniform representation of structures/records (via Shapeless) that lets you traverse data structures in a normal, type-safe way.

Put that together and you get a language where you never need the magical frameworks that (real-world) Java needs. No reflection-based runtime serialization that you have to control via a type registry separate from the language type system. No reflection-based database mapping that you have to control via another, subtly different type registry. No AOP decorators where you rename a method and it magically stops having a database transaction applied. No magical annotations for your http routes that tell it which string class name to load at runtime for serialization, where if you want your web threads to do something before/after you use yet another magic method or registry. No magical autowiring framework instantiating all your classes for you.

Just plain old functions and values. Standard language features (plus one macro in shapeless that might as well be part of the language for it's used) for all of the above. One standard syntax (for/yield) for effect management that all the language tools understand. Libraries for things that would be language features in most other languages, but without having to resort to the free-for-all of custom macros.

That's what Scala has. If Java catches up to that one day, great! But without higher-kinded types, and without some kind of uniform representation of records/case classes/data classes/what-have-you, it will never get close.

Re: Why I love Common Lisp and hate Java (2012)

#123

Post by LoSboccacc »

nayuki wrote: post #7

It is a recurring theme for people to point out how verbose a hello world program is in Java: class HelloWorldApp { public static void main(String[] args) { System.out.println("Hello World!"); } } For argument sake, let's compare it not to Lisp but to Python instead: print("Hello World!") Once you get proficient in a language and start writing larger programs, your perspective can change entirely. What appears to be…

And all the verbosity disadvantage almost goes away anyway once you get outside default functions and stop using globals

Re: Why I love Common Lisp and hate Java (2012)

#124

Post by lmm »

zmmmmm wrote: post #112
reality_czech wrote: post #91

Earlier quoted context omitted.

Java has been gradually eating all the good parts of Scala. So far, it's eaten lambdas, map / reduce / fold functions, option types, raw string literals, the concept of a built-in REPL, type inference for local variables, and default methods in interfaces (which is kind of like mixins). Pattern matching and type classes are on the menu, but not yet formally merged into Java. So what does Scala have left? Operator ove…

> So what does Scala have left? This is why I think long term Groovy is better positioned than Scala, even if short term Scala has more of the mindshare. Groovy actually offers something fundamentally different, while Scala is perpetually trying to compete on Java's home turf. If people really want a pure, statically typed language Kotlin is pretty good and has less impedance mismatch with Java.

> If people really want a pure, statically typed language Kotlin is pretty good and has less impedance mismatch with Java.

I see this the other way around: Java genuinely has eaten most of the good parts of Kotlin, because Kotlin is positioned as a small enhancement over Java rather than a language that brings major improvements as Scala does. Adopting Kotlin means paying much the same cost as adopting Scala, but for much less in the way of benefits.

Re: Why I love Common Lisp and hate Java (2012)

#125

Post by LoSboccacc »

akvadrako wrote: post #27
rococode wrote: post #19

Earlier quoted context omitted.

You really should be using a logging framework instead though, if you're working on a large application.

You use logging for production, but if you just want to see what a value is while when you run your program in the IDE and might not for a logger imported, print is handy.

Nah there's debugging for that

Re: Why I love Common Lisp and hate Java (2012)

#126

Post by polityagent »

jimmyspice wrote: post #115
sidlls wrote: post #89

Earlier quoted context omitted.

The kind of verbosity you describe isn't really the issue in my view. The contentious verbosity is theKindWhereVariableNamesLookLikeThis and "fluent" programming style that turns "assert(testRes == expected)" into "assertThat(testRes).isEqualTo(expected)". It's excessive and removes value most of the time.

Well the fluent style is more verbose, but has the advantage of telling you more information about what went wrong. You get a report telling you that "x was not equal to y" rather than "expected true". The verbosity is way more helpful to me.

or you can use a language with macros, then a testing library can report the code being evaluated and the values in it.

Re: Why I love Common Lisp and hate Java (2012)

#127

Post by wiz21c »

FTA :

>>> But for a skeptic like myself — who spent 4 months intensively practicing Tai-Chi in Beijing, just to confirm the existence of “qi”

Has anybody here experienced this chi thing. My tai chi teacher can surely demonstrate it but I have hard times understanding with my occidental way of looking at physics... My understanding it's more a state of mind that allows the body to move in a very specific way.

Re: Why I love Common Lisp and hate Java (2012)

#128

Post by ausbah »

ilovecaching wrote: post #25

The languages that tend to become popular are simply languages that appeal to the lowest common denominator. Java was the language invented for the "common programmer", and people find that comforting. Now it's Go; as Rob Pike once said of it, "They’re not capable of understanding a brilliant language but we want to use them to build good software. So, the language that we give them has to be easy for them to underst…

Not gonna lie, to me that’s a lot of words to just say “people who use popular languages are beneath me because they simply can’t understand the ‘beauty’ that mathematical-esque and functional functional languages offer”.

Re: Why I love Common Lisp and hate Java (2012)

#129

Post by devxpy »

GlennS wrote: post #79
nayuki wrote: post #7

It is a recurring theme for people to point out how verbose a hello world program is in Java: class HelloWorldApp { public static void main(String[] args) { System.out.println("Hello World!"); } } For argument sake, let's compare it not to Lisp but to Python instead: print("Hello World!") Once you get proficient in a language and start writing larger programs, your perspective can change entirely. What appears to be…

These criticisms look to me like you are trying to use your Java programming style in Python. Prefer to use modules and tables of functions as an organising principle instead of classes. Use inheritance rarely, and method overriding almost never. Otherwise you can make a really big mess (see Django's Form class hierarchy). This sort of bad design where you have the flow of control jumping up and down the inheritance…

> Django's Form class hierarchy

I personally liked it. It is a little overwhelming at first, but after you get used to it, it's actually quite powerful.

Re: Why I love Common Lisp and hate Java (2012)

#130

Post by joe_fishfish »

lmm wrote: post #124
zmmmmm wrote: post #112

Earlier quoted context omitted.

> So what does Scala have left? This is why I think long term Groovy is better positioned than Scala, even if short term Scala has more of the mindshare. Groovy actually offers something fundamentally different, while Scala is perpetually trying to compete on Java's home turf. If people really want a pure, statically typed language Kotlin is pretty good and has less impedance mismatch with Java.

> If people really want a pure, statically typed language Kotlin is pretty good and has less impedance mismatch with Java. I see this the other way around: Java genuinely has eaten most of the good parts of Kotlin, because Kotlin is positioned as a small enhancement over Java rather than a language that brings major improvements as Scala does. Adopting Kotlin means paying much the same cost as adopting Scala, but for…

This is why Kotlin is such a hit for Android devs, who are stuck with only half the features of Java 8 (at best).
Post reply on HN