Comment by narzac | Hacker News Reader

Comment by narzac | Hacker News Reader

Well the article touches some good points, since it made me think...

The problem is the language and paradigms used not the framework or how many levels you abstracted the problem at hand.

The way as i see it, writing programs by manipulating data excessively, will lead us nowhere but complexity, which unfortunately is introduced by the program itself. Mainstream languages such as C++, Java, C# etc., should not be taught in schools as if they are the ultimate solution, and fp is sth not practical, it is a twofaced claim while stealing ideas from fp and patching these languages, nowadays.

Another one, saying how fast the IT changes at every chance and sticking with ancient programming languages. When someone points out the dilemma, then claiming not to having enough developers for say Haskell, Clojure, Go etc.. May be you should fix the education system morons, instead of building more complex frameworks, platforms.

Of course there are particular areas, such as simulations, modelling time dependent large data sets, embedded development etc.. where some languages will be the best suited while others will be overkill or not just fast/ viable etc.. Of course, I am not blindly saying, "Death to imperative languages" :P However, they shouldn't dominate.

As a final comment, The future of programming is already here, The question is are we ready for the future...

Whether you like it or not, your world runs on C, C++ and assembly. These languages form the ninety-percent-plus core of modern computing's foundation. Lift the hood of nearly any embedded system, BIOS or OS and you'll find these in heavy use. You'll find C code in the networking layers that let you talk to the world, and in the very light switches that let you go to the bathroom at night. C runs your dishwasher, your car, your elevators, and probably your toothbrush.

Then a lot of stuff gets layered on top of this. And sure, languages /do/ jit, but these are generally hothouse flowers, surrounded by an infrastructure provided by C, C++ and assembly. Few systems are native boot without involving a bunch of C.

I'm happy if people are satisfied to work in the layers above all this stuff. Frankly, not many folks (as a percentage of the programming population) can do good kernel level work. But don't pretend that it doesn't exist, or that it is somehow morally inferior to hacking away in Haskell.

Maybe this will change in thirty years; I think that's the time scale required to make a fundamental change in the way we program modern systems.

I'd /love/ to see a native Erlang system, soup to nuts. But there's little economic incentive to make one, given that the lower layers are actually doing a pretty decent job.

Whether you like it or not, your world runs on C, C++ and assembly. These languages form the ninety-percent-plus core of modern computing's foundation.

Isn’t that part of the problem? There is no technical reason we couldn’t have a language that offered the same fine control and hardware integration as C, compiled to native executable code in a similar way, but was both safer and more expressive. There is no advantage in having an awkward syntax for specifying types or in making all pointers nullable.

Mainstream industrial languages today are a triumph of good enough, and they continue to dominate primarily because of momentum and the size of the surrounding ecosystem rather than technical merit in the language itself. Unfortunately, this creates a vicious circle that reinforces the status quo, and the few organisations with sufficient resources to break that cycle have limited economic incentive to do so.

At least in embedded systems, this looks like something that can be done the open source way. The success of the arduino and the mbed in building popular ecosystems has shown us that.

I can see some better version of the .net micro framework, being improved by the open source community(1), and benefiting from the ms ecosystems and tools, becoming fit for some large part of embedded systems work.

Also I can see this getting adopted since it let's embedded developers in small companies, who has some power on which tools to use, learn another skill that can better their employment opportunities.

(1)improved speed could be achieved through using the cito compiler project, which might be good enough for many projects. And for making the language hard real time, it could be done using specific implementation of reference counting, although at some speed/memory cost.

There have been many contenders, notably Eiffel, Oberon and D. There are many others that I don't immediately remember the names of.

These languages have /great/ technical merit. They offer safety (in various forms) and other interesting technologies that C definitely lacks. They were lauded by academics and industry pundits. So why didn't they take the industry by storm?

Perceived technical merit is a terrible way to choose a language.

Pascal was widely regarded as a great language, a wonderful model, and it was widely used in the 80s by various large companies. Today it is mostly dead. I believe this is because Pascal only did an adequate job of expressing stuff at the hardware and kernel level, and that C was better. Certainly nearly everyone at Apple that I worked with breathed a sigh of relief when it became obvious that it was okay to write C instead of Pascal for new projects. For the most part we'd been writing C for years anyway, just in Pascal. About the only thing that people missed were nested procedures (whereupon, C++).

Your new "adult" language is going to need a set of very compelling offerings over and above "well, it's safer" in order to succeed.

Take a look at things people are doing /to/ C in order to be better:

- "analyze" builds that do control graph analysis and find bugs (not just ones endemic to C, but actual logic bugs, too)

- declarative sugar that helps tools to reason about what things like drivers are trying to do

- control extensions (commonly seen as macros providing 'foreach' like support)

- ways for tools to enforce local conventions (without spending tons of manpower on parsers and so forth)

Come up with a language as good as C at low-level programming, that has great debugger support, offers easy tool plugins, and that has interoperability with the gazillions of libraries already available [take a page from C#'s great interop story here], and you might have something. Go "academic" and just say "this is good for you, use it instead," and the working programmers will see nothing in it for them and ignore you, just as they've ignored or abandoned dozens of other offerings in the last 30 years.

C's success in the industry is largely tied to UNIX's success.

As UNIX systems started to spread into the industry and getting market share from mainframes, developers also wanted to have those utilities in their home systems. This lead to C being spread outside the natural environment (C) and "infecting" non UNIX systems.

As Pascal refugee, I only touched C when required to do so. Even with its quirks I find C++ offers a more welcoming place, thanks to its stronger type improvements and better abstractions over C.

Like any systems programming language, C will only get replaced if the operating systems vendors force developers to use something else.

This is what Microsoft is doing by transitioning Visual C++ to a pure C++ compiler.

UNIX vendors will never do it because C is synonym of UNIX. All even C compilers get to be written in C++ nowadays.

Who knows what other OS vendors might still be relevant.

There have been many contenders, notably Eiffel, Oberon and D. [...] So why didn't they take the industry by storm?

Some possible reasons, based on my limited knowledge of those languages:

Eiffel — Emphasis on simplicity over performance optimisation; emphasis on OO programming style; legal issues around various parts of the ecosystem in the early days

Oberon — Limitations of basic type system, such as a lack of enumeration types and the way coercion of numerical types worked until recent versions

D — Many of the same major strengths and weaknesses as the more established C++; two rival “standard” libraries for a long time

Your new "adult" language is going to need a set of very compelling offerings over and above "well, it's safer" in order to succeed.

Of course. You can throw in “it’s easier to write” and “it’s more powerful” and you still only have a small part of the big picture, because in reality so much depends on the surrounding ecosystem: development tools, libraries, and so on. However, there is no reason we couldn’t have a language that was superior to C in both safety and expressive power, remained compatible with calling to/from C functions at ABI level for library compatibility and ease of porting, and used a clean grammar to help tool developers.

Take a look at things people are doing /to/ C in order to be better:

While I don’t disagree with any of your examples, I’m not sure they really tell us anything useful. The absence of other things that people might do could be because they aren’t particularly valuable or it could be because they are valuable but also prohibitively difficult or expensive to achieve starting from C as the foundation.

> I'd /love/ to see a native Erlang system, soup to nuts.

I see where you are coming from but I don't see how assembly and a layer of C drivers is going to disappear. That is the whole idea behind having layers of abstraction. It is what makes one plug in a mouse and it works and then another mouse made by another company and it also works. There is a lot of firmware, assembly, kernel driver, kernel syscalls taking place but it support you moving your hand and a pointer moves on the screen correspondingly. We take that for granted but it is built on an existing infrastructure. It took years and it wasn't always the same. I remember older DOS days having to fish for mouse drivers.

Same with Erlang. Erlang itself is built with C. Beam VM is mostly C (maybe with some assembly). It runs on standard hardware with a few standard operating systems.

Now if we dream of the future. I can see architectures perhaps that do something like you suggest. There is one for instance: Erlang on Xen. The idea is that Erlang runs on a very small hardware footprint, without an OS (since Erlang's standard library pretty much provides large number of OS like features). Now they picked Xen and you can say perhaps "ha that's cheating, there is also Dom0 running!". But it isn't practical otherwise. Maybe they could have picked a particular motherboard and CPU combination but now it is hard to reproduce that, test it and lots thing have to be rewritten.

Take a look anyway, I think you'll be surprised:

http://erlangonxen.org/

You do realize your answer is based on the pointed out problem. Let me put it this way, I am saying, "We should wear better shoes, and you are saying, even you don't like it, you are wearing it right now, and it does a decent job". Yes that is what I am talking about :)

Oh system programming does exist, and I can understand the role of C, what I am saying is, even we have a better alternative to C, people would still stick with C.

There is no economic incentive, you are right but the reason itself mostly economical not technical.

Reply on news.ycombinator.com