41–50 of 68 posts
"How is Go or Rust better than C C++ Ruby Python Lisps Java Smalltalk Erlang and whatnot." - sure fire way to start a flame war with programmers ;)
My take on a few languages you mentioned. I'll try to stay as neutral as possible, but some things are bound to be controversial. - C#: Microsoft's answer to Java, supposedly does some things better (Java seems to be catching up some), but cross-platform support is so-so. - Go: I don't understand Go. It seems to be conceived as an improvement over C, and it gets many things right (and a few things wrong, like error h…
I remember thinking: "I keep reading all this stuff about how Lisp is so much better than all of the popular languages I know about, so is it going to start taking over soon? Is C++ about to go the way of the dodo?"
12 years later, C++ is still around and about as dominant as it was 12 years ago. So I guess the first thing I'd say is: PL enthusiasts on the Internet are not the best indicator of what's about to get big. My best explanation for this is: PL enthusiasts have a somewhat different set of values and aptitudes than mainstream programmers:
- a PL enthusiast is willing to invest a lot of effort into learning and using a language/tool that they think is better. Mainstream programmers will usually go with what has a lot of momentum and support.
- a PL enthusiast usually has a knack for thinking very abstractly, so what looks elegant to them will often be very difficult for less abstract thinkers to unpack.
- a PL enthusiast is usually more concerned with making a language fit an elegant mathematical model than making it fit the model of the underlying hardware.
So PL people end up loving languages like Lisp or Haskell because they are much "cleaner" from a mathematical/abstraction standpoint (particularly in how they eliminate or tightly control side effects). And even though the mathematical models aren't very close to how the hardware works, people have invested a lot of work into making the compilers optimize things so that they are often very efficient -- comparable to what you'd get if you wrote things in a much more "manual" way in an imperative language.
However, because there is a lot of transformation that happens in the compiler, it can be very hard to predict how efficient the program will actually be. You're sort of at the mercy of the compiler -- it can completely change the big-O in both time and space! So while the language itself gave you an elegant way to say something, you may have to get your head around the language's evaluation model and optimizations before you can understand why it has the performance characteristics it does.
For example, one time when I was trying Haskell I wanted to know if a trivial function I wrote took O(1) or O(n) memory. The people on the Haskell list were very helpful, but look how much analysis it took just to answer this simple question!
http://www.haskell.org/pipermail/glasgow-haskell-users/2009-...
But languages like Lisp and Haskell are still highly valuable even to the "mainstream" in that they explore a lot of powerful and abstract concepts, and these feed into more mainstream languages. 10-15 years ago few mainstream languages had "lambda" (from Lisp), now most mainstream languages do (JavaScript, Ruby, Python kinda, Java, C#, even C++). Algebraic datatypes (from Haskell) are showing up in Rust. So I think of Lisp/Haskell as idea incubators that make powerful features a lot easier to add to more mainstream languages, because Lisp/Haskell have already tried them out and run into all the questions and edge cases around them.
So now your next question: why all the new languages, and will any of them take off?
New languages are exciting when they can open up new possibilities. But the downside is that languages have strong "network effects" -- integrating different languages together is a pain. Languages succeed when the plusses of the new possibilities outweigh the inherent costs of using a new/different language.
You listed a lot of languages but the main one I want to talk about is Rust. Rust opens up a huge new possibility: the possibility of getting memory safety without giving up performance or control. No mainstream language has ever done this before.
Traditionally you have had two choices. Either you get top performance and control with a memory-unsafe language (C, C++) or you get memory safety while tethering yourself to a garbage-collecting runtime (Java, C#, Python, etc).
(People will come out of the woodwork here to argue that their favorite GC'd language is faster than C and C++ on their favorite benchmark. Such benchmarks usually tend to be a bit fishy, but this is beside the point. The point is that C and C++ give you the control to do whatever the other language might have done to beat you. Other languages winning is just a local maximum, in which the C or C++ programmer has not yet optimized their program to win. The reverse is not true: when you are tethered to a garbage-collecting runtime, there are certain behaviors built-in that you simply cannot work around).
What makes Rust exciting and very new is that it gives you the best of both worlds. Rust is memory-safe (except in localized "unsafe" blocks), but does not impose any kind of runtime or GC onto you. This could completely change the way that we write performance-critical software.
The premise that old languages are pinnacles of perfection is simply not true. C, Lisp, Haskell, Smalltalk, etc. – these languages did not get everything right. What they did do is get enough things right that it is really hard to make a language that is better by enough of a margin that it is worth breaking away entirely and starting from scratch. To make it worth switching to a new langauge, that language has to really make your life much, much better. Performance, convenience, safety, expressiveness – whatever a new language gives you more of, it has to give you so much more to be worth the trouble of switching to a less mature language with a smaller, less developed community. But that's what people are trying to do with these new languages.
Consider Lisp as a potential pinnacle of perfection. Paul Graham quipped that Lisp was "discovered" by John McCarthy, rather than invented or designed – Lisp already existed in the way that mathematical truths exist. That's a cute idea, but clearly not literally true. There were still a lot of design choices – parentheses for example. Why not square or curly brackets? Why not indentation? There were also choices that are now almost universally recognized as mistakes. Dynamic scoping, for example, which was later replaced by lexical scoping in Scheme.
People who haven't tried their hand at language design generally tend not to fully appreciate how many unfortunate tradeoffs are inherent in the process. Static vs. dynamic? Both have great benefits as well as major drawbacks. That's just the first major choice – and each choice affects most of the rest of the language. A coherent language design ends up being a crystalized fractal of difficult, uncertain choices. You never know when the difficulties you're facing in one area might have been easier in some nearby fold of this vast, combinatorial design space – most of which is completely unexplored. The problem is compounded by the fact that although it may seem mathematical, language design is really a subfield of applied psychology: ideas often seem great on paper, but when you try them out, people find them incredibly awkward, unintutive, or just plain annoying.
>So what I don't understand and hope somebody here could >shed some light on it is what's with all the new languages? >How many of them really bring something new to the table, a >better way than the old one?
Probably the term "language" is a bit misleading (and fuel the notion that 'english'=='german' just different) and is better to think in machine builders, where its interface is based in combinations of words, but the words ARE NOT WORDS.
So, is posible to build a better machine builder than others? Of course. Some are very linear (and fast) but not that good at make parallel work. Some are very unsafe. Some are complicate to operate. Some are very non-sensical, where turn left mean instead self-destruction. Some requiere a lot of steps to produce the end-work.
The beauty of a language is that a SINGLE word can not only imply a meaning, but also is EXECUTABLE with a behavior.
go ... async .. for ... spawn ...
Is like have a machine that chomp wood. It could be made of hundreds of small pieces. Or it can be a axe, in a single iron mold.
A new language can be made when is understand that is possible to get NOW the axe and chomp, instead of build it like in minecraft. Even if the end result become the same (dude, people do insane things in minecraft) your way of THINK change if you are NOT PLAYING MINECRAFT but instead, something else.
Some languages try to move closer to the "I have a axe right now, let's move on" faster than others. IE: Some machines are more low-level than others.
With that idea on the mind, a language (machine builder) designer start to see some things: Even if have minecraft-level sub-machine builder is important (ie: The parts that almost all languages have like for, if, list, chars) is another level, game, to have machines tailored to some task.
And if you extend the idea far enough, you can see that is better to have several of that specializations of that in a single package. If the mix going well, you have a happy factory worked that is very... happy!. Or you have another crazy machine where turn left mean self-destruction. But well...
Of course, some natural limits are hit because the limitations of the computer architecture itself (and the limitations of the factory worked), but as I say:
Some people do insane things with minecraft.
> When I read about Smalltalk or Lisp or Haskell people regard them as the pinnacle of programming language design and yet their popularity isn't really proportional to those statements. That's like saying you read about Bob Dylan being the pinnacle of songwriting, but his popularity compared to Beyonce not bearing that out.
Looking at the most popular ones - the learning usually sparks from necessity - setting up a blog and modifying it (Wordpress -> PHP), making a webpage interactive (jQuery -> Javascript).
From that necessity grows a community that creates libraries, classes, plugins, extensions, scripts, full frameworks and even servers (node.js).
This all makes it very hard to prioritize a language that doesn't have such easily accessible libraries, classes, plugins, extensions or frameworks readily available and it becomes even harder when there is a small community to gain knowledge from.
Talking from my own experience, when you are learning it is fun to create libraries, classes and plugins - but when you are up to your ears in real work a very small amount of time can be spent on creating content for the community.
How is Go or Rust better than C C++ Use C or C++ and then try out Go or Rust.
I feel many of the C++ criticisms I read have to do with the older standards (98/03). C++11/14 is a very major upgrade to C++. C++ certainly still has its pitfalls, but things have gotten much better. It honestly feels like a new language to me.
Go is also crossplatform, whereas gcc/clang don't like working on Windows, and Microsoft doesn't like implementing the full C++11/14 specs without waiting years after the open source community has already been using the full specs. This results in fragmentation.
Caveat Emptor: All the analysis below pertains mostly to type system features and other "surface observable" aspects of the lanugage. Newly maturing compilation techniques are certainly another reason for the recent explosion (e.g. Rust, Haskell). But I'll stick to what I (ostensibly) know. > I have no particular background in programming languages design and theory Well then, good news: most of these new languages -…
Some great points! Out of curiosity, does anyone know of any studies/inquiries into the interaction of type systems with languages that favor composition over inheritance? I imagine that a more inheritance-driven language would be more amenable to strong type checking, for example.
> I imagine that a more inheritance-driven language would be more amenable to strong type checking, for example.
AFAIK the conventional wisdom among formal methods people is actually the opposite.
If you don't mind my asking, why do you imagine this?
> does anyone know of any studies/inquiries into the interaction of type systems with languages that favor composition over inheritance?
I'm not sure what you mean. Do you mean studies about interactions between type systems of these two sorts (e.g. as in Scala)? Or do you mean a comparative study asking which is better?
As I mentioned, I think the conventional wisdom is that inheritance makes things more difficult from a type checking/verification perspective. For this reason, the big arguments for inheritance tend to be oriented toward pragmatism rather than ease of formal reasoning.
Earlier quoted context omitted.
Some great points! Out of curiosity, does anyone know of any studies/inquiries into the interaction of type systems with languages that favor composition over inheritance? I imagine that a more inheritance-driven language would be more amenable to strong type checking, for example.
angersock, > I imagine that a more inheritance-driven language would be more amenable to strong type checking, for example. AFAIK the conventional wisdom among formal methods people is actually the opposite. If you don't mind my asking, why do you imagine this? > does anyone know of any studies/inquiries into the interaction of type systems with languages that favor composition over inheritance? I'm not sure what you…
My reasoning is that an inheritance-based language has some notion of "A extends B extends C", and so if I need to check compatibility of types I can just walk the class hierarchy and get an answer.
I'm clearly missing something--maybe I'm just using the wrong mental model for types?