Hacker News Reader

Comment by carsongross | Hacker News Reader

It is fascinating to watch how both the java and javascript communities deal with the very different shortcomings of their respective programming languages.

It is also horrifying.

View on HN

This is just what programmers do. They all have irresistible urge to write their own meta language on top of what they are using.

C programmers do that with pre-processor. C++ programmers do that with templates and pre-processor. Java programmers do that with annotations.

And then you have Lisp, that said, "fuck it, let's keep just the meta-language!" :)

Not sure if you mean that positively, but considering your Java work, if meant positively, that is a huge compliment!

Oh, it certainly wasn't negative. I was doing Scheme long before I did Java, and I'm doing quite a bit of Clojure now, so I'm certainly a long-time Lisp fan.

I learned Scheme before I learned Java. Knowledge of lisp family languages makes me a far better Java programmer.

As mentioned previously, I finished up some preliminary Java coursework. This was around the time our quasar and pulsar work took off in popularity.

I see you as a hero and hope for a 1/1000 of your productivity when I peak.

Glad to see you were a Schemer too.

The thing is, will there be a time where people will stop dealing with a concrete specific language to stay at the `lisp` level, or will this keep going on forever ?

Because then you end up with millions of programmer-individual languages built using a meta-language.

It is fascinating to watch how people underestimate the cost of switching a programming language[1], and overestimate the benefits of a new one.

It is also horrifying.

[1]: Switching to another language on the same platform (JVM/JS) lowers the cost considerably, but it is still high.

True, how about starting with the right language? :) I only write Clojure for both JVM and JS. Works like a charm. The only problem is when you need to work in a team and nobody does anything else but Java and JS.

My rule of thumb is, if you need to switch a primary production language more than once a decade[1], then you're picking them wrong.

Personally, I've been using Java for over a decade, and a few years ago I added Clojure to the mix and expect it to serve me for over a decade, as well. I like them both and believe they both qualify as good picks. I'm also adding Kotlin now, too, mostly because its switching cost and added risk are practically zero.

[1]: for reasons other than targeting a new platform

Seconding Kotlin coming from Java. It takes maybe 2 days to learn everything in the language if you already know Java, and it fixes pretty much all the warts that bother me about Java (the big ones for me are immutable references, first-class/higher-order functions, and unnullable-by-default references. Type inference and string interpolations are handy as well). It also has a small enough runtime/stdlib (unlike Scala or Clojure, which I've also tried) to make it practical to use in environments where startup time matters, specifically Android.

When it comes to startup times and Clojure, I'm keeping my eyes on Skummet: http://clojure-android.info/skummet/

Just want to say I found this comment informative, on-topic, and its tone respectful and appropriate, so I'm disappointed it has been downvoted :(

Speaking of which, Estonia recently implemented a "no legacy" directive [1], under which all government systems will be rewritten from scratch at least every thirteen years. They are taking the stance that a good implementation will last around a decade, not less, but also not much more.

[1]: http://www.ozy.com/rising-stars/taavi-kotka-is-putting-the-e...

Sounds about right.

Absolutely, I need to learn about Kotlik, it almost looks like Scala at the first glance.

I agree with you about languages and targeting 10+ years with it. Stability is worth more than anything to me, out of the box performance also important (this tend to be great for older languages) not to mention the std library quality. For these reasons Java is an excellent choice.

Clojure came to me as a total surprise, since I haven't studied CS and because I was surrounded with Perl/Java engineers for a long time I haven't heard about Lisp till 2011. It changed my approach to software engineering a lot. It is absolutely eye opening, mind blowing and all that jazz.

ROFL. "Right" language. There is no such thing. There's only technical tradeoffs and personal preferences. Everything else is simply faith and dogma.

But, I'm sure someday we'll all discover your one true God... Err... Programming language, like the lispers and smalltalkers, the rubyists and the haskellers, the C++ fanatics and the C faithful...

There is such a thing but the scope is usually limited to a problem, a project, a department or a company. A good example would be OCaml and Jane Street for the latter.

Right. So for the exact same problem domain, one company might use Java and another might use Haskell, purely because of history, the candidates they can find, and any number of other possible concerns.

None of this has anything to do with objective technical superiority of one solution or another, assuming you could make that case definitively. And if one could make that case, technical superiority is only one input into a much more complicated decision-making process.

Again: there is no one true language. There never was and there never will be. Our entire industry, hell, all industries, operate based on tradeoffs, whether those be business, technical, political, or other. Why would programming language selection be any different?

In ten years some other language will get the right language, and the things you're talking about will be for dinosaurs.

Don't fall for that trap. What matters is that you build solid software that delivers value.

Well I might have given you the impression that I am a Clojure zealot. This is not true at all. I program in Ruby, Python, Java, Erlang, Go and OCaml on the top of Clojure. The only reason I prefer the later it because I can use the same minimal syntax to target 2 VMs and that is a huge win. It is also fun to show people the power of Lisp time to time, but that is it. If my manager or team asks me to write code in a random language I am going to learn it and do it, but for personal projects I tend to use Clojure. This is all.

This requires some explanation. What limitations are people working around here?

If you mean immutability, it's doesn't make sense to single out Java, since immutability was not significantly valued by any mainstream language until the 2000s (of course Haskell and various MLs existed before, but I'm talking about popular mindshare).

Exactly. Object oriented languages of this generation even embraced mutability. The idea was that by having encapsulated/hidden data, methods could validate data and make sure that objects are always in an inconsistent state, hence making mutability safe. (Of course, the same can be achieved in C with opaque pointers.)

It was only until concurrency/parallelization/multi-core became more important that immutability-by-default gained much traction.

Nowadays, Java feels like the victim of the OO hype: mutable by default, static methods being the only escape hatch from OO, only predefined value types (yes, I know, Java 9). People always say that Go is like pre-generics Java, but it at least doesn't make two of the aforementioned mistakes.

> make sure that objects are always in a consistent state

This only works for invariants that constrain the state of a single object. Realistically, invariants that constrain the state of multiple objects are a necessity, and no amount of in-object validation will help you enforce those.

Fascinating. A programmer gives automation/abstraction to other domains, but yet uses tools which rob him(her) of that in their own work. Amazing that we had tools to solve most of these problems decades ago.

How does anything here rob the programmer of automation and abstraction? This adds something, it doesn't detract. It's an annotation you can use where you want. Your observation is specious.

The GP is referring to Java as the tool that robs the programmer of [various dimensions of] abstraction.

This is like a robber who takes your entire house and lets you stay under the porch only when it rains. Will you be grateful to them for giving you shelter?

Not really, no. If we're doing analogies, it's like you bought a house with no porch, and sometimes you accidentally get locked out and are stuck in the rain. These guys came along and built you a porch to put next to your house for when it does rain.

It is 2015, there are house with porches since 1950 that you could have bought at the same rate.

http://www.paulgraham.com/avg.html

No, not "at the same rate". I wish people would stop linking Paul Graham posts as if they're gospel. In the very real world of running an engineering team, network effects matter, and only in 2015 is there a Lisp (and I don't say this as a "hater" or any of the other easy ways to dismiss someone, I like Lisp and my first collegiate language was Scheme and I've used GNU Guile in multiple projects) that can approach the same value prop as Java when those network effects, the ability to just raise your head and find a sufficient solution to almost any problem that isn't business critical and many problems that are, are taken into account.

That Lisp is written for the virtual machine originally written for Java.

I wish people would stop saying that Lisp is not suited for the real world when there are billion dollar businesses built using Lisps (other than Clojure).

It is 2015, please let us stop the FUD at least now :)

PS: I love Java and use it for my day job. Just a few days back I was reading about AutoValue and Immutabiltiy and wishing that Java had more power that would make these hacks unnecessary. I am not saying Lisp is the greatest, but Java definitely feels like assembly when you reach the edges and one has to wait for years to get updates.

There are billion-dollar businesses built with PHP, too. I wouldn't use that, either.

I don't like Java. I don't like Java at all. (I prefer Clojure or Scala, depending.) But I recognize why it is where it is, and Paul Graham saying Paul Graham things doesn't really change reality.

Reality is not black and white.

What "shortcomings"? What's "horrifying"? What real-wold use-cases does this "Immutables" library solve?

Immutable values can be safely shared across concurrent contexts.

You can create immutable classes "by hand". Just make all fields final and either primitive or reference to immutable type.

This framework just makes it a little bit shorter to type as it automatically generates some boilerplate code.

And you can also simulate any Turing-complete language using any other Turing-complete language. That doesn't mean it's practical to do so :)

As someone who programmed Java a couple of years, because work: it is quite doable, since there are now good collection libraries that provide mutable collections (e.g. Google Guava).

Of course, you cannot get the same guarantees that e.g. Haskell provides. Moreover, unless you return concrete types, that Map<> being returned by a method could be mutable or immutable (it's your guess ;), or hopefully in the documentation).

The problem is, as you say, it is quite doable, as long as you have internal access to all of the code. There's no way to ensure that, for example, a function actually returns an immutable map, or actually doesn't modify a map passed to it.

(And no, Collections.immutableMap doesn't.)

(And then there are problems with the JVM bytecode as well - do you know you can pass 2 into a function expecting a boolean? And sometimes it'll get treated as true and sometimes as false? The JVM is "wonderful" like that.)

Mutability isn't a shortcoming. It's a feature.

It's arguably a good feature, but I've come to the opinion that it's a bad default.

As with any feature, it must be used properly.

But, from an OOP perspective, modelling state changes is natural and desirable. So mutability seems a sensible default.

It's only the recognition of issues that can arise from state changes that has us wanting to lop off the entire feature. A rather strange and drastic "solution" in my view.

Immutability isn't a shortcoming. It's a feature. :-)

Hold on to that thought. I'll check back in with you in, say, 5 years. By then, we should have all endured enough unnecessary pain to lurch back in the other direction. :)

We're well into the era where scarce computing resources no longer limits us the way they used to. We're over some kind of hump with regards to that. Since computing power is more abundant, the limiting factor we're currently running into has to do with the cognitive overhead incurred by our current tools, since tools always lag behind somewhat. Our current tools are primarily built to be efficient with machine resources, but are not necessarily built to make efficient use of cognitive resources.

As cognitive resources become the bottleneck, it's sensible to invest in tools that decrease cognitive burden. So we're seeing an upswing in popularity with methods and techniques aimed at limiting the amount of unnecessary, incidental complexity generated. "Easier to use" is nice, but "less complex" is imperative right now.

Immutability is one of those techniques that can be leveraged to limit growth of complexity.

>Immutability is one of those techniques that can be leveraged to limit growth of complexity.

What you're saying is perfectly rational, right down to your emphasis on can. I don't take exception to immutability as one tool. My problem is with the notion that it is the only tool and the corollary that mutability is always wrong.

Mutability is a feature, of course. Lots of useful algorithms need mutable data structures (e.g., dynamic programming, unification, etc.), and have no counterparts that rely solely on immutable ones.

However, totally unconstrained mutability is definitely a shortcoming. The ability to look at a type signature and be immediately able to tell what might or might not change is a big win for maintainability, especially in big projects.

By the way, constraining mutability doesn't require a purely functional language. The ML family (Standard ML, OCaml) allows all expressions to have arbitrary side effects (when evaluated), but all values other than reference cells are immutable.

Reply on news.ycombinator.com