Live data from Hacker News

Why I love Common Lisp and hate Java (2012)

kuomarc.wordpress.com

151–160 of 171 posts

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

#151

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.

Horray! I remember the first time I poked at Java, back in 2007, and I hated it, in large part because it was missing these. It's fantastic it's eaten these good things.

> So what does Scala have left?

Style/syntax and community?

I don't know enough about either language to debate on the points you've brought up; what I do know is that Scala feels a lot more like writing Ruby/JS/Python than writing C++/C#/Java.

I've only just started writing real class definitions in Scala, and the way that "constructors" work really drives home this similarity and difference; the kind of code you write to define the class looks to be the exact same kind of code you write to define everything else.

I also haven't poked into the larger Scala community, but I can't imagine it's all that similar to the larger Java community. Even if Java reaches some kind of feature parity with Scala, I bet this difference remains, and it'll come across in the libraries, common usage patterns, help on the internet, and conventions.

Again comparing to Ruby, the effect that "Matz is nice" and (when you add in Rails) "convention over configuration" have goes beyond code features into what it's actually like to use and work with the language day in and day out.

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

#152
post #144

Earlier quoted context omitted.

Alice: Hey Bob, want to try my nifty new function? Bob: Sure, Alice, what does it do? Alice: It takes a string and it returns an integer. Bob: But what does it actually do? Alice: I told you. It takes a string and it returns an integer. Bob: But what does it do with the string? What's it for? Why should I use it? Alice: Hey, I just gave you the full documentation for my function. You have everything you need. Now go…

I think you're criticizing a language you have no experience in. Haskell development is type driven. You start by defining and constraining your types until you get a DSL to write signatures in. See the Idris O'reilly book for more on type driven development. By the time you've added type constrains through typeclasses, selected types named after the domain, and selected a suitable name for the function, it's possibl…

I didn't critisize Haskell. I only criticized a statement about its type system.

> You're also forgetting that signature includes the name of the function.

That's what I wanted to point out. The name of a function is even more important than its types. Types alone seldomly give you the complete picture of what's going on in a function.

Of course the name can be wrong whereas types can't, but the name is less likely to be wrong than a comment.

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

#153

Earlier quoted context omitted.

Swift is statically typed and a “Hello, World!” in Swift is just print(“Hello, World!”).

So going back to the original commenter's points: how does Swift handle top-level code? Where is it legal for me to write print("Hello, World")?

[deleted]

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

#154
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…

Totally agree with you - I like Java precisely because it's so verbose. I'd rather have to type 20% more than spend 20% more time figuring out other people's code. And honestly, I always feel that the Hello World example is kind of biased. It's more an example of Java's way of launching a program being verbose because every program requires a certain minimal structure. But for the rest of the entire Java language tha…

> I'd rather have to type 20% more than spend 20% more time figuring out other people's code.

If that were the trade off, it would be a no brainer. But instead it feels like double the code, for no clarity (or negative clarity because the noise becomes obfuscation).

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

#155
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.

Even Java has testing libraries that provide optional failure case messages with asserts to provide specific context where necessary.

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

#156
post #142
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.

What fundamentally different does Groovy offer? What do you mean by "Scala is trying to compete on Java's home turf"?

Groovy is a truly dynamic language (with all the pros and cons that come with that). So you can put it into contexts such as interactive scripting where Java will always be suboptimal and solve problems Java doesn't even want to solve. On the other hand, every single good idea that Scala comes up with will eventually be co-opted by Java, because there is no reason for that not to happen. It is just a matter of time.

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

#157

Earlier quoted context omitted.

Types aren’t documentation, no matter how many Haskell users delude themselves thinking it is. Documentation is more than a function definition. Types don’t explain rationales and how to use functions and programs. Types don’t give proper examples.

I suggest reading Type-Driven Development with Idris by Edwin Brady. I don't think you have enough experience writing Haskell to understand the outcome of type driven development. In Haskell you start by defining your domain as types, and constrain those types with typeclasses. By the time you get to writing signatures, the implementations can almost be inferred (in Idris they actually can be inferred, the code liter…

This is (probably often) true for all those who can load a few dozen arbitrary type signatures into their active memory and start drawing conclusions. For the rest of us a few examples of how to do common things would help a lot. Please include documentation.

I have experienced what you're talking about with Haskell but it was a lot of uncomfortable work. But it's "technically" true that the types often describe how to use a library, sometimes so well that errors cannot happen.

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

#158

Earlier quoted context omitted.

From the perspective of a python programmer, I must say this is an interesting list. I'm rather convinced by your points on print and public. On the other hand, "__name__ == __main__" is just a convenience for debugging and small scripts. I wouldn't use it in real programs. I dont use @staticmethod, or find it useful. If I want a function, I use a function.

> I dont use @staticmethod, or find it useful. If I want a function, I use a function. In principle, it makes sense to "bundle" functions that are strictly related to a class within the class itself (i.e. as static methods). Of course, the benefits viz. top-level functions are only noticeable if your codebase is big enough.

What are those benefits?

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

#159
post #101
post #59

Earlier quoted context omitted.

>Not allowing free functions is really just a poor design choice. I don't see why. The verbosity is pretty minimal and you enforce the availability of a privacy scope you wouldn't have had. ie private static methods and members that your public statics can use. Although, pure functions are nice if you can't trust the code you're calling won't surprise you.

I think this has to do with naming. Naming is generally hard, with free functions you must name the function, in Java you must also name the class. If you could show some examples of single method interfaces whose naming makes sense, I'd be delighted!

>If you could show some examples of single method interfaces whose naming makes sense, I'd be delighted!

IDisposable with a single Dispose() method?

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

#160
post #72
post #52

Earlier quoted context omitted.

>I find a debugger just slows me down 1st you have to add the useless print statements and after decades of programming a debugger is vastly superios in terms of 'debugging' when compared to printing. (Back in time basic had no debugger even) Also printing is utterly useless for high concurrent code, as printing alters memory visibility, usually adds global sync, etc..

Attaching a debugger will also change the behavior of concurrent code.

This would depend on the language/compiler/linker - take Java (which the article is about). Attaching debugger does nothing prior to adding a breakpoint.

The breakpoint would cause the method to be deoptimized, executed in the interpreter. Removing the breakpoint would allow the method to be optimized again.

Now obviously during stepping in, the thread would be blocked and not highly concurrent. However print statements just bare the concurrency.

Post reply on HN