Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

Designing a new language is the new designing a new framework. Ugh.


Yeah, screw progress and experimentation, right?


Has there really been that much actual progress made lately, though?

I'd say that C++, Erlang and perhaps Haskell are the most recent languages to bring anything new to the table in a way that's at least somewhat usable in practice. And they're decades old at this point.

C++ helped make OO and generic programming feasible. Erlang helped with developing concurrent, distributed, fault-tolerant software. Haskell brought pure functional programming and laziness to a wider audience.

Otherwise, the widely-hyped languages of today, including Scala, Ruby, JavaScript, Go, Rust and even Kotlin generally just rehash what C++, Erlang, Haskell and other languages offered several decades ago.

Some of those languages, like JavaScript and even Go, are arguably worse in many ways than languages developed in the 1980s or way earlier.

At best, we're seeing small, incremental improvements. More realistically, we're just seeing old ideas rehashed again and again, with minor syntactic differences. Thus we aren't really seeing real "experimentation", and we aren't witnessing much "progress".


This sort of conversation is usually pretty subjective so it will be impossible to actually come to any agreement.

That said, ignoring the JVM in this conversation is near criminal. High performance GC, JIT, standardized profiling, etc. are all major steps forward. Are they language improvements? No, but they proved that a VM is a viable target platform and that was under serious debate in the late 90s.


I ignored the JVM because it really isn't that special at all, and its supposed benefits haven't been proven to exist in reality.

Various types of VMs predated it by decades, including ones that used various forms of GC and JIT compilation. See some of the Pascal and Smalltalk implementations from decades ago as an example of these systems. These did see a fair amount of use, in practice.

The JVM isn't particularly portable. It may support most of the major mainstream OSes used today, but it's not like portable C or C++ code (including other language implementations for Perl, Python, and so forth) that can run on all sorts of obscure and ancient systems.

Its performance isn't particularly remarkable, either, even with all of the effort that some very large companies have put into it. Its been pretty much relegated to server-side use at this point, and even then we're seeing more and more effort made to move away from it. People are realizing that it's often better to go native, as we're seeing with newer languages like Go and Rust.

The JVM did get a lot of hype, and has seen a lot of use, but it's mediocre at best. There's nothing particularly earth-shattering about it.


I hate to debate you about Rust; but no other practical language offers same memory-safety with no garbage collection that Rust provides, the lifetime and ownership systems are fairly unique. AIUI, Cyclone had something similar to lifetimes, but in a different manner, and without the considerations for concurrency/data races that Rust has.


If all the languages and frameworks that are being developed were progress, then sure. If they were meant as just experiments, then more power to them. Here's the deal, we'll see a flood of "Why I chose (X) language" posts. A year later we'll see a flood of "Why I left (X) language" posts. Developers read too many blogs and follow too many fads. They are like golfers! "This'll get you an extra 10 yards on your swing!" B.S.


So what? I don't know about you, but I started programming for fun. Where's the fun if you never experiment or try new things?

You can't discourage people from experimenting with new languages, frameworks, design patterns, etcetera, just because some people might use it and fail.


You're making the dangerous assumption that a failed experiment is synonymous with no progress.

We actually learn a lot more from failures than successes.


I am not assuming that at all. Re-read my first two sentences.

The problem that I see is that developers only want to work on what is new. They don't want to work with C++ because it's old. They don't want to work with Java because it's old. They don't want to work with Ruby because even it is old. It's the same thing with frameworks. There has been an explosion of frameworks because developers can't be caught dead working on something older than 6 months.

If one's intention is to rewrite entire applications every year, knock yourself out. But if you're writing apps for customers who expect it to be solid and remain in the field for a useful amount of time, then you need the reliability of C++ or Java or C. Not some language someone whipped together in a handful of weekends.

Another commenter mentioned beginning development because it was fun. I did too. It still is, but I also grew to care about the products I develop. And no, it's not fun to chase issues with immature technology when a customer is wanting answers.


This is a problem? If not for the early adopters, how would new languages get a chance?


I agree with the positivity. It is always easiest to critique and stick with the familiar.

Something we can quantitatively take away from the slur of new languages is that new languages are easier now than ever to create/implement. This should be a good thing. This means faster iteration can occur. Even if that iteration is not necessarily taking place, the creation of new languages verifies this ability.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: