HN Theater @HNTheaterMonth

Rich Hickey is supposed to have said that he created Clojure because he was tired of telling people to read that book.

Best I can find as a source for now is https://www.youtube.com/watch?v=2y5Pv4yN0b0 -- I thought there was a link somewhere to Hickey himself saying this, but can't find it.

And by telling I think you mean that over time Java has very thoughtfully evolved in a way that respects backwards compatibility, or that once a feature is in the language it'll very likely stay there for the next 25 years. Yes, innovation is very important (and happening faster than ever now with the 6-month release cadence), but a majority of the work isn't in deciding what goes in, it's deciding what stays out and if something does go in how does it satisfy both audiences of "move slow don't break" and "move faster we want features".

A good video on this process: https://www.youtube.com/watch?v=2y5Pv4yN0b0

Things are innovating faster than ever, but, the trick is always to address the challenges of both today and tomorrow, while staying true to compatibility and stability.

Check out Brian's talk on Stewardship: https://www.youtube.com/watch?v=2y5Pv4yN0b0

I recommend Brian Goetz’ talk about language stewardship. I don’t think what you’ve said here is true, and it kind of bums me out because some of these features took years to develop so they wouldn’t break people on ancient versions. That deserves much respect and appreciation.

https://m.youtube.com/watch?v=2y5Pv4yN0b0

For python 2/3, it was because the BDFL made a wrong call. But we are past that now, and we collectively learnt something from the debacle, including the BDFL himself:

> As for "Machiavellian Python maintainers", that's real. There have been explicit attempts to apply pain to Python 2.7 users. This has decreased since von Rossum got stuck maintaining Python 2.7 code at Dropbox as his day job.

(https://news.ycombinator.com/item?id=13020680)

For java 8/9, it was because Brian Goetz still has a boss. We can just compare https://www.youtube.com/watch?v=2y5Pv4yN0b0 to https://www.youtube.com/watch?v=wHoRBvt3U6o. Hopefully some lessons were learnt as well.

Brian Goetz has been a role model on how to lead [0] a language for a long time now for me. Thanks for all the great work Brian.

[0] "Brian Goetz - Stewardship: the Sobering Parts", https://www.youtube.com/watch?v=2y5Pv4yN0b0

As far as speed-of-evolution, it is worth understanding that the slower speed is at least partly a by-product of different goals. This talk, "Stewardship: The Sobering Parts" by Brian Goetz, is informative and well worth the watch: https://www.youtube.com/watch?v=2y5Pv4yN0b0

See "Brian Goetz - Stewardship: the Sobering Parts" https://www.youtube.com/watch?v=2y5Pv4yN0b0&t=3399s

Against my better judgement I did a reverse image search and found the post that you found that screenshot from [1]. The post is full of people having exactly the sort of problems you would expect from an automatic software updater, along with instructions from Jeff on how to manually update using SSH and git.

These things happen. The world is messy, and whether due to technical inadequacy or run-of-the-mill software updater bugs, web backends will not always be updated. As you've noted, this could eventually lead to security problems, and I agree -- but that doesn't justify intentionally breaking their code. To say that their breakage is justifiable because they'll be 0wned at some point anyway is an absurdly darwinian argument.

To address your last question, the way you update a system like the web is exactly the way we always have -- accretion. With very few exceptions, websites from the early 90s still work today. We didn't remove the `table` tag when we introduced flex boxes. We add new APIs while preserving existing functionality. If you want to see a fantastic talk on this exact subject, watch "Stewardship: The Sobering Parts" by Brian Goetz [2]. It is well worth your time.

[1] https://meta.discourse.org/t/how-do-you-update-discourse/109... [2] https://www.youtube.com/watch?v=2y5Pv4yN0b0

⬐ Klathmon

And I agree that we shouldn't break things lightly, but in this case that wasn't possible.

The options were let website scrolling be laggy and janky on mobile, or break a very small amount of websites. (and your point is that things may never be updated, so no amount of "giving them the ability to opt-in to these improvements would ever help)

And I stand by my thought that they made the right decision here, despite the very few easily upgraded sites that were impacted.

There's a great talk about backwards compatibility in Java by Brian Goetz: https://www.youtube.com/watch?v=2y5Pv4yN0b0

⬐ _Codemonkeyism

Watched, great talk, thanks!

Brian Goetz the Java Language Architect addressed the very points you raised in a talk called "Stewardship: the Sobering Parts" [1]

I highly recommend anyone with these very valid concerns to view it once.

[1] https://www.youtube.com/watch?v=2y5Pv4yN0b0

On the topic of stewardship, I highly recommend this talk by Brian Goetz titled "Stewardship: the Sobering Parts" [1]

Brian goes about how important compatibility is for the language, the concept not throwing customers code under the bus by bringing breaking incompatibilities. (ie Python 2 --> 3)

Java has its warts and isn't "cool" but I respect their design decisions.

[1] https://youtu.be/2y5Pv4yN0b0?t=1578

⬐ KevinEldon

Thanks for the link. I haven't watched that talk, but I will, and I was thinking of Brian when I wrote my comment. His work and he work of others on the Java team is important, serious, and hard.

See Brian Goetz's talk on language stewardship (https://www.youtube.com/watch?v=2y5Pv4yN0b0). I'm sure nobody wants to add new and interesting features to Java more than the people who work on the language every damn day, but they've made a strong commitment to the community to not break existing code.

⬐ ygra

C# shows pretty compellingly that adding features does not have to break existing code. For example, you can use every keyword added after 1.0 as identifier, too.

⬐ SideburnsOfDoom

But it can make things more complex too. e.g. I recently learned that the main reason that asynchronous C# methods have to be declared "async" is so that the compiler knows that in the method body, "await" is a keyword. Without this backward compatibility requirement, it could be inferred from the return type + the presence of 1 or more "await" keywords.

To add on to that...

Even though, I haven't been involved in the contributing process for Clojure, but I thought it was interesting that Brian Goetz's keynote at the Conj 6 months ago was about stewardship, in particular, stewardship of the Java language:

https://www.youtube.com/watch?v=2y5Pv4yN0b0

It gave me a better appreciation for the differing concerns of someone using a language or contributing a patch vs. someone designing & maintaining a language.

In my day-to-day, I use languages other than Clojure, and I sorely miss the cohesive and good design. Brian Goetz's talk nails it on the head why the languages in my day-to-day are sub-optimal, even if they're currently the "new hotness"... at least for now...

Watch this awesome keynote by Brian Goetz, he talks about valie types and generics.

Brian Goetz - Stewardship: the Sobering Parts

http://m.youtube.com/watch?v=2y5Pv4yN0b0

> No tail calls support

Due to the way JVM does bytecode verification. It will be fixed in future versions

https://www.youtube.com/watch?v=2y5Pv4yN0b0

> no (optional and confined) unsafe pointer arithmetics

www.docjar.com/docs/api/sun/misc/Unsafe.htm

Will be replaced by an official API in Java 9.

> no value types

http://openjdk.java.net/jeps/169

> pathetic limit on a method size makes it an extremely shitty target for any language other than Java.

Java Virtual Machine

⬐ sklogic

> Due to the way JVM does bytecode verification.

In CLR you can selectively switch off the verification.

> www.docjar.com/docs/api/sun/misc/Unsafe.htm

I do not want an inefficient API. I want a low level functionality which can be mapped efficiently to what the real hardware does.

> http://openjdk.java.net/jeps/169

> This work is not intended to change the Java Language Specification or JVM bytecode instruction set.

Okay... It's not going to be anything useful.

> Java Virtual Machine

And that's exactly why it sucks. There are much more universal VMs out there.

⬐ pjmlp

> In CLR you can selectively switch off the verification.

Why open the door to security exploits?!

C derived languages are already enough.

> I do not want an inefficient API. I want a low level functionality which can be mapped efficiently to what the real hardware does.

Ever heard of intrinsics? Just because it looks like a method call, doesn't mean it is one.

> Okay... It's not going to be anything useful.

The final form is still ongoing work.

> And that's exactly why it sucks. There are much more universal VMs out there

Except for the CLR, I don't know any other.

The universal VM has been pursuit since UNCOL was presented to the world.

⬐ sklogic

> Why open the door to security exploits?!

Why limit your VM expressive power? Restrict only untrusted loadable modules, do whatever you want in the trusted realm.

> C derived languages are already enough.

Not nearly. You won't have a managed VM with fast run-time code generation with C.

> Just because it looks like a method call, doesn't mean it is one.

Problem with intrinsics is that the majority of your optimisation passed do not know anything about them. See LLVM as an unfortunate example. Most of the SIMD intrinsics are not even used in a simplest constant folding there.

> Except for the CLR

Bingo! CLR is better. Scrap JVM.

⬐ pjmlp

> Not nearly. You won't have a managed VM with fast run-time code generation with C.

I was speaking about security exploits. C should never have happened.

> Bingo! CLR is better. Scrap JVM.

Yes the CLR does quite a few things better than the JVM compatible VMs do currently.

However, the JVM being a specification means I can find a JVM for anything has that a CPU, from smart cards up, servers, mainframes, cars, weapon guiding systems, factory robots, anything.

So while technically better than the reference implementation, it doesn't cover the application spectrum JVM compatible VMs do.

People tend to forget that Sun (now Oracle) JDK is just the reference implementation.

Note I use both eco-systems since the beginning.

⬐ sklogic

> I was speaking about security exploits. C should never have happened.

I see. I sort of agree - C should never have been exposed to the programmers. But a C-level VM is an extremely useful thing for implementing high level languages. I'd rather move safety checks a number of levels up, and leave VM level to performance-related stuff.

⬐ pjmlp

While I agree with you, I rather have AOT compilers, no need for VMs.

And both Microsoft and Oracle are realizing this.

.NET has native compilation on WP, with .NET Native coming on .NET 5. NGEN is a very simple compiler just for optimizing startup time.

Java always had AOT compilers in commercial JVMs, but not on Sun.

Now Oracle has SubstrateVM, and there are plans for AOT compilation at least in Java 10 timeframe.

⬐ sklogic

VMs should be available in runtime (no matter if an AOT is present or not) in order to allow an efficient run-time code generation. And VMs should also be available during compilation to make it possible to efficiently implement reflective compile-time meta-languages (e.g., like Common Lisp).

And the difference between abstract machines, intermediate representations and virtual machines is very elusive (see all the confusion around LLVM for example).

It is only tangentially related, but I recommend this video from Brian Geotz, a Java language architect. He breaks down the challenges of adding features to the language, in a room full of Clojure devs no less. Worth a watch: https://www.youtube.com/watch?v=2y5Pv4yN0b0

⬐ xpto123

great insight into guiding principles on how to evolve a language used by millions of users and running on a billion machines, from the language architect of maybe the most popular language in the world today (Java).

Insight into advantages of Value Types for Java 10, the talk not Clojure specific unlike the logo might indicate (it just happened at Clojure conf).

Great stuff, liked it a lot / recommend.

⬐ canadev

Agreed; I thought it was really interesting.