7 ms·

The Hundred-Year Programming Language

33 points by luu 4y ago

flohofwoe 4y ago
> (on SIMD) C never really added any kind of abstraction for them. ISPC and various C-derived GPU shading languages would beg to differ. But then the next question is: are high-level abstractions and 'compiler magic' even all that useful for SIMD, or are intrinsics the better solution? None of those things are part of the C standard of course, but in the real world the C standard does not matter - only the feature set of actually existing compilers does. Also I wish that obsession with the PDP-11 would finally die. C seems to be a pretty good match for all sorts of von-Neumann-computers, otherwise it would have died already. IMHO programming languages live and die with the hardware they need to - uh - 'program', a hardware architecture which requires an entirely new approach to programming will naturally require entirely different programming languages (and our computers still are close enough to computers from the 50's and 60's that the same programming languages map pretty well). It makes a lot more sense to speculate what hardware will look like in 100 years, because only this will tell what programming languages might look like.
- anfilt 4y ago
  I agree for instance gcc's vector size attribute works just fine in C. For instance I could declare a type like this: typedef uint32_t myVec __attribute__((vector_size(16))); and then when using that type in C, gcc alot times will do a great job vectorizing without having to reach towards intrinsics when looking at the generated code. Sure it's not standard C, but it still feel like C when using them. Even for things like shuffling it's still pretty logical to just treat it as a function for instance "__builtin_shuffle" that gcc provides to use on those vector types. The semantics of C can handle such things, it's just not standardized if you get what I am saying. So I get what your saying about the PDP-11.
- kaba0 4y ago
  Just because certain shading languages put on a C-like syntax doesn’t make them anywhere close to C. They have entirely different semantics. So no, C is just terrible when it comes to SIMD, but also when it comes to multi-threading, two areas that are the most important inprovements of modern hardware.
  - flohofwoe 4y ago
    Some are less different than others, for instance: "The Metal programming language is a C++14-based Specification with extensions and restrictions. Refer to the C++14 Specification (also known as the ISO/IEC JTC1/SC22/WG21 N4431 Language Specification) for a detailed description of the language grammar." (from: https://developer.apple.com/metal/Metal-Shading-Language-Specification.pdf https://developer.apple.com/metal/Metal-Shading-Language-Spe...) Meaning essentially that MSL is C++14 with a couple of restrictions (mostly concerning pointers), a couple of SIMD data types, and some custom attributes. ...the C++14 could just as well be replaced with some C standard, if the Metal designers wouldn't like C++ so much for mysterious reasons (and that arguably would have been the better choice - because for shader programming C++ really doesn't add that much useful stuff over C).
    - kaba0 4y ago
      C++ is very different from C, one language is actually usably expressive the other can’t even express a generic vector data structure without runtime overhead or copy-pasting.
      - flohofwoe 4y ago
        Not going to argue, but if you really want generics in C the usual solution is code generation. Also, it might be surprising to a C++ coder, but there's a lot of problems that can be solved perfectly fine without generics ;)
revskill 4y ago
As a user, i care more about portability between those programming languages. It's the best of both worlds. Nowadays, i tend to focus on polyglot programming, where i can pick the best tool for the job, it's the true Single Responsibility Principle that works for me. I also love language wars, because from them, i can know the tradeoffs of each language more clearly.
einpoklum 4y ago
> Fortran is significantly faster than C, for instance. That's news to me. Languages that are close enough to the hardware and allow for inline assembly can probably never be described as slow overall. Perhaps the author refers to some specific libraries? > Java is the most recent popular general-purpose language This post was written in 2022. Does the author not know about Python? Javascript? Rust? C#? and a bunch of others? Weird.
- flohofwoe 4y ago
  > Fortran is significantly faster than C, for instance. AFAIK the main reason is pointer aliasing, e.g. you may need to sprinkle C code with the restrict keyword to work around the issue. "Significantly faster" is debatable of course, I bet it's possible both in Fortran and C to write code that performans equally bad.
  - einpoklum 4y ago
    So you're saying that the aliasing defaults of C are an issue. Well... I suppose, but - not `restrict`ing your pointers in the hottest part of the code is a bit like not compiling with optimizations on.
    - flohofwoe 4y ago
      Yes, in the end it's just a regular optimization issue, check the compiler output, tweak the code, rinse-repeat...
- otabdeveloper4 4y ago
  Rust isn't popular, C# isn't general-purpose and the other two are older than Java.
  - graboid 4y ago
    I am curious, why do you think C# is less general-purpose than Java?
roenxi 4y ago
This article doesn't use the name "Lisp" enough. The language with the best chance of lasting a long time is the one with the simplest syntax. That is Lisp. It is already one of the oldest programming languages and the lisp family of languages are still mutually intelligible to each other despite being large. The language core hasn't settled and the rest of the programming community has nearly caught up with the Common Lisp standard library. Will a Lisp ever be the most popular language? Probably not. Maybe. Will they last 100 years? Easily. One or multiple of the current Lisps will still be there. If computers exist in 2123, someone will be making money using a current Lisp. Hopefully they'll be using one that has discovered the words "first" and "rest".
- prox 4y ago
  What is Lisp used for in production these days? The wiki didn’t really specify, just that it’s connected to mathmatics and AI research.
  - auggierose 4y ago
    This web site, for example.
    - capableweb 4y ago
      Specifically, Arc: - http://arclanguage.org/ http://arclanguage.org/ - https://en.wikipedia.org/wiki/Arc_(programming_language) https://en.wikipedia.org/wiki/Arc_(programming_language)
  - capableweb 4y ago
    Some web apps also run Clojure (a lisp for the JVM) for backend and ClojureScript (Clojure compiled to JavaScript) for frontend. Probably Nubank ("largest fintech bank in Latin America") is the biggest company I know using Clojure in production in various ways.
  - dgb23 4y ago
    Lisp is a language family. Popular, well known choices include for example: Common Lisp, Scheme, Racket, Emacs Lisp and Clojure. There are countless production systems written in these languages, ranging from embedded, to web apps to infrastructure tooling. The specific domains where they're applied, are just as diverse as one could imagine. The more interesting question is "Why would someone use any of these languages?". Niche languages are typically associated with risk in the business world. But the thing is that Lisp just keeps surviving, evolving and finding new problems and domains to tackle. My personal opinion is that these languages represent the powerful combination of freedom, stability and engagement. A Lisp is inherently non-condescending as it gives you more powerful tools than most other languages, but it's also very reliable because it's built on a very well understood, minimal foundation. Last but not least you are programming in a way that is very engaging. You are right there in the running program.
wslh 4y ago
If we try to predict the future instead of reviewing the past I speculate that in the future (complex) programming languages will not be necessary since a big amount of code written in the world is redundant. So minimum declarative stuff will be enough to create the amount of software now built by lot of engineers. On the other hand, it is interesting to discuss what will happen with low level programming such as writing drivers, operating systems, and browsers. Some of these could be generated from an spec. I remember HN posts such as "A full TCP/IP stack in under 200 LoC (and the power of DSLs)" [1] that sounds like a toy now but hope to see in the near future to build complete stacks and just fill the spaces between. [1] https://news.ycombinator.com/item?id=846028 https://news.ycombinator.com/item?id=846028
- flohofwoe 4y ago
  > So minimum declarative stuff will be enough to create the amount of software now built by lot of engineers. That idea is the nuclear fusion of software development, it's always just 15 years away, even 50 years ago ;)
  - wslh 4y ago
    Do you believe it would happen?
    - flohofwoe 4y ago
      Only in some niches, mostly related to data management, e.g. the same places where declarative programming already succeeds. I do agree though that the programming world is currently completely overstaffed, and that this has a bad overall effect on quality and progress, but this has 'business reasons', not 'rational reasons' and technological magic bullets are not the solution ;)
    - maze-le 4y ago
      In the early 2000s we had a Prof. for a course called "Hardware Technology". He really wanted us to get into electrical engineering and hardware focussed low level development, because according to him "SW development is dead, software can be created from specs and flowcharts by now". Great course, we learned about FPGAs and VHDL, but that advice really didn't stand the test of time.
edent 4y ago
I think it is interesting comparing computer languages to human languages. Reading Charles Dickens - a bit over 100 years old - is fascinating. Large parts of it are completely intelligible, and then all of a sudden there a phrase or bit of slang which just doesn't make any sense. Even listening to interviews with pop groups or politicians from the 1960s can produce a weird kind of cognitive dissonance - you know they're speaking the same language as you, but discussing long-dead concepts with outmoded words. I wonder if computer science will ever have the equivalent of Shakespearean scholars, trying to decipher the meaning or esoteric comments?
- psychoslave 4y ago
  >I wonder if computer science will ever have the equivalent of Shakespearean scholars, trying to decipher the meaning or esoteric comments They are already there. Usually you call them colleagues. :D
forgotmypw17 4y ago
I use Perl because the community prioritizes backwards compatibility. For the most part, you can run the same Perl script over 25 years of Perl releases, going all the way back to 5.000. This is one of the most important features for me, and I'm so grateful.
infradig 4y ago
Prolog got half-way there last year. It will go the distance. C as well. Lisp of course. The reason is that they define their paradigm. C#, C++, Rust, Ruby, Java are neither fish nor fowl and will not make it. Python has become too useful not to survive. I started with Cobol and would happily dance on it's grave before I pass.
- kaba0 4y ago
  Come on, Java is so insanely big that it simply will go there from momentum alone. Many says it is the new Fortran/Cobol, especially in finance but it has something special — the JVM. Plenty of old software continues to run on virtualized hardware simply because they depend on a given CPU architecture’s quirks and can’t be ported. The JVM is well-specified and thus any program programmed against it can run indefinitely, independent of hardware. Being cross-platform is also “vertical” in that past and future architectures can also be supported. And on top of that, tell me any other platform with a specification of both language and runtime (where even data races are not completely UB) that has as many independent implementation, many of which are supported by FAANG companies and could be developed alone further if anything were to happen to the others? Like, Alibaba alone could continuously develop the platform.
- timbit42 4y ago
  If by C, you mean, descendants of C, I agree with you. If you mean C itself will survive, I strongly disagree. I think with the recent focus on safety in languages, Rust and Ada, especially SPARK, will have better futures than C and C++. I think business is going to turn against C[++] for new projects, and there will be a push to rewrite C[++] code in safe languages, especially for operating systems, networking, and security code , making C[++] the next COBOL. Since safety isn't something you can simply bolt onto a language, many other safe languages will crop up to replace the rest of the unsafe languages.
davedx 4y ago
It's a very interesting article, but the lack of citations backing up some of the big claims make me doubt its premises. It's a shame because the author seems to know his programming language history. The most important IMO is this point: > Fortran is significantly faster than C Then later: > Is Performance Necessary for a Hundred-Year Language? > Fortran, one of the oldest thriving languages, lives and dies on performance. So that’s a check mark in the “yes” column. I did some googling and found that there are some design choices that might make Fortran faster, but it's highly debatable whether it's "significantly faster than C". Given how hardware has advanced over the years, "performance" just seems a weird feature to look for in a 100 year language too. You don't build performant software by building it in Fortran or C, you do it by making sensible design choices and writing thoughtful code, and not over-architecting or over-complicating provisioning. IMO C is obviously going to be a 100 year programming language, and I came away a bit disappointed the article didn't quite fully claim that. An interesting and thought provoking read nonetheless.
- adrian_b 4y ago
  In the past, Fortran was always faster than C in scientific computation applications, mainly because many optimizations are prevented when compiling C, by the risk of pointer aliasing. In modern C, such optimizations are possible by using "restrict". Nevertheless, few C programmers bother to write "restrict" wherever it should be used, so casually written C code remains slower than similarly written Fortran code. Moreover, modern Fortran has a lot of builtin operations for multidimensional arrays, which can be implemented in an optimized way by the compiler. Writing simple C code cannot achieve a comparable effect. Achieving a similar performance in C would require a special optimized library and this would result in extremely verbose and ugly C code. It is really impractical to do this in C and C++ must be used, with operator overloading, iterators and templates being needed to write a custom library that can match or exceed the builtin features of Fortran.
  - davedx 4y ago
    > Writing simple C code cannot achieve a comparable effect. Can you provide a citation or source on this please?
xorvoid 4y ago
Human language doesn’t stay the same over 100 years. Is it reasonable to expect that from a computer language? To be fair, they are different. But, I think close enough to make the analogy stand. Different idioms, ways of expression arise constantly: come into and out of vogue. Human languages aren’t rigorously defined like computer languages must be. Human languages are loosely specifically by the amorphous collection of “all speakers” (whatever that means). And they evolve along those lines with each generation reshaping the language. Computer languages also change but they tend to hold onto their baggage much more. E.g. C is drowning in all the unchangable legacy from the 70s and 80s. Is a 100 yr programming language possible? Sure. But it’s gonna feel a lot like you’re a scholar in 2023 writing a modern academic technical paper in Latin or Early Modern English. Doable, yes. But comical. In fact, this is arguably already the state of C. Very useful programs are still written in it. And it feels like Early Modern English. Does that matter? Idk. But as the current trend in programming goes, most young engineers won’t be happy with this dynamic. Personally, I suspect we get it just because we have so many damn programs in the world. But I can’t imagine anyone will count it as a success.
frou_dh 4y ago
I liked the following blog post on the topic (coincidentally... it reps one of my favourite languages, hehe): "IM READY: LET THE 100 YEAR PROGRAMS BEGIN: Exploring Standard ML's robustness to time and interoperability" http://len.falken.directory/p-lang/100-year-programs.txt http://len.falken.directory/p-lang/100-year-programs.txt
NikkiA 4y ago
I'm not sure it's right about algol being dead, I've seen a renewed interest in it over the last couple of years, and I believe I even saw a new algol compiler - but I can't remember if it was for -68 or -60.
- timbit42 4y ago
  ALGOL, its Wirthian descendants (Pascal, Modula-2, Oberon) and Ada were designed to be safe languages. Partly due to Pascal's weaknesses in systems programming and partly due to the low speed of computers at the time, C took over, which was a shame because it is one of the least safe languages, but networking hadn't become common yet and people wanted to save every processor cycle possible and didn't want to waste any on safety. I think this resurgence of focus on safety could bring some life back to this line of ALGOL descendants. Of course Ada is still used worldwide in high reliability systems such as aircraft systems, air traffic control systems, and spacecraft. There is Ada code in NASA's Artemis project.
jbm0 4y ago
(1) I didn't know that COBOL was Grace Hopper’s baby! But I've spent decades trying to avoid learning too much about COBOL lest I accidentally back into having to support a COBOL system. (2) No mention of PL/I in the vaguely Algol-like group. I liked PL/I! (3) I'd never heard of Laravel, and was pretty okay with that. (4) "One of C’s old promises was to act like a PDP-11 computer." I wasn't aware of this assertion. I'll have to think about it. Do the increment / decrement operations mirror the PDP-11's addressing modes? I guess maybe they do! https://en.wikipedia.org/wiki/PDP11_architecture#Addressing_modes https://en.wikipedia.org/wiki/PDP11_architecture#Addressing_...
- timbit42 4y ago
  Actually, it isn't, is spite of commonly being referred to as such. From Wikipedia: * "Designed by Howard Bromberg, Norman Discount, Vernon Reeves, Jean E. Sammet, William Selden, Gertrude Tierney, with indirect influence from Grace Hopper" * "[Grace Hopper] did not participate in its work except through the general guidance she gave to her staff who were direct committee members. Thus, while her indirect influence was very important, regrettably the frequent repeated statements that "Grace Hopper developed Cobol" or "Grace Hopper was a codeveloper of Cobol" or "Grace Hopper is the mother of Cobol" are just not correct."

33 points by luu 4y ago

> (on SIMD) C never really added any kind of abstraction for them. ISPC and various C-derived GPU shading languages would beg to differ. But then the next question is: are high-level abstractions and 'compiler magic' even all that useful for SIMD, or are intrinsics the better solution? None of those things are part of the C standard of course, but in the real world the C standard does not matter - only the feature set of actually existing compilers does. Also I wish that obsession with the PDP-11 would finally die. C seems to be a pretty good match for all sorts of von-Neumann-computers, otherwise it would have died already. IMHO programming languages live and die with the hardware they need to - uh - 'program', a hardware architecture which requires an entirely new approach to programming will naturally require entirely different programming languages (and our computers still are close enough to computers from the 50's and 60's that the same programming languages map pretty well). It makes a lot more sense to speculate what hardware will look like in 100 years, because only this will tell what programming languages might look like.

anfilt 4y ago
I agree for instance gcc's vector size attribute works just fine in C. For instance I could declare a type like this: typedef uint32_t myVec __attribute__((vector_size(16))); and then when using that type in C, gcc alot times will do a great job vectorizing without having to reach towards intrinsics when looking at the generated code. Sure it's not standard C, but it still feel like C when using them. Even for things like shuffling it's still pretty logical to just treat it as a function for instance "__builtin_shuffle" that gcc provides to use on those vector types. The semantics of C can handle such things, it's just not standardized if you get what I am saying. So I get what your saying about the PDP-11.
kaba0 4y ago
Just because certain shading languages put on a C-like syntax doesn’t make them anywhere close to C. They have entirely different semantics. So no, C is just terrible when it comes to SIMD, but also when it comes to multi-threading, two areas that are the most important inprovements of modern hardware.
- flohofwoe 4y ago
  Some are less different than others, for instance: "The Metal programming language is a C++14-based Specification with extensions and restrictions. Refer to the C++14 Specification (also known as the ISO/IEC JTC1/SC22/WG21 N4431 Language Specification) for a detailed description of the language grammar." (from: https://developer.apple.com/metal/Metal-Shading-Language-Specification.pdf https://developer.apple.com/metal/Metal-Shading-Language-Spe...) Meaning essentially that MSL is C++14 with a couple of restrictions (mostly concerning pointers), a couple of SIMD data types, and some custom attributes. ...the C++14 could just as well be replaced with some C standard, if the Metal designers wouldn't like C++ so much for mysterious reasons (and that arguably would have been the better choice - because for shader programming C++ really doesn't add that much useful stuff over C).
  - kaba0 4y ago
    C++ is very different from C, one language is actually usably expressive the other can’t even express a generic vector data structure without runtime overhead or copy-pasting.
    - flohofwoe 4y ago
      Not going to argue, but if you really want generics in C the usual solution is code generation. Also, it might be surprising to a C++ coder, but there's a lot of problems that can be solved perfectly fine without generics ;)

revskill 4y ago

As a user, i care more about portability between those programming languages. It's the best of both worlds. Nowadays, i tend to focus on polyglot programming, where i can pick the best tool for the job, it's the true Single Responsibility Principle that works for me. I also love language wars, because from them, i can know the tradeoffs of each language more clearly.

einpoklum 4y ago

> Fortran is significantly faster than C, for instance. That's news to me. Languages that are close enough to the hardware and allow for inline assembly can probably never be described as slow overall. Perhaps the author refers to some specific libraries? > Java is the most recent popular general-purpose language This post was written in 2022. Does the author not know about Python? Javascript? Rust? C#? and a bunch of others? Weird.

flohofwoe 4y ago
> Fortran is significantly faster than C, for instance. AFAIK the main reason is pointer aliasing, e.g. you may need to sprinkle C code with the restrict keyword to work around the issue. "Significantly faster" is debatable of course, I bet it's possible both in Fortran and C to write code that performans equally bad.
- einpoklum 4y ago
  So you're saying that the aliasing defaults of C are an issue. Well... I suppose, but - not `restrict`ing your pointers in the hottest part of the code is a bit like not compiling with optimizations on.
  - flohofwoe 4y ago
    Yes, in the end it's just a regular optimization issue, check the compiler output, tweak the code, rinse-repeat...
otabdeveloper4 4y ago
Rust isn't popular, C# isn't general-purpose and the other two are older than Java.
- graboid 4y ago
  I am curious, why do you think C# is less general-purpose than Java?

roenxi 4y ago

This article doesn't use the name "Lisp" enough. The language with the best chance of lasting a long time is the one with the simplest syntax. That is Lisp. It is already one of the oldest programming languages and the lisp family of languages are still mutually intelligible to each other despite being large. The language core hasn't settled and the rest of the programming community has nearly caught up with the Common Lisp standard library. Will a Lisp ever be the most popular language? Probably not. Maybe. Will they last 100 years? Easily. One or multiple of the current Lisps will still be there. If computers exist in 2123, someone will be making money using a current Lisp. Hopefully they'll be using one that has discovered the words "first" and "rest".

prox 4y ago
What is Lisp used for in production these days? The wiki didn’t really specify, just that it’s connected to mathmatics and AI research.
- auggierose 4y ago
  This web site, for example.
  - capableweb 4y ago
    Specifically, Arc: - http://arclanguage.org/ http://arclanguage.org/ - https://en.wikipedia.org/wiki/Arc_(programming_language) https://en.wikipedia.org/wiki/Arc_(programming_language)
- capableweb 4y ago
  Some web apps also run Clojure (a lisp for the JVM) for backend and ClojureScript (Clojure compiled to JavaScript) for frontend. Probably Nubank ("largest fintech bank in Latin America") is the biggest company I know using Clojure in production in various ways.
- dgb23 4y ago
  Lisp is a language family. Popular, well known choices include for example: Common Lisp, Scheme, Racket, Emacs Lisp and Clojure. There are countless production systems written in these languages, ranging from embedded, to web apps to infrastructure tooling. The specific domains where they're applied, are just as diverse as one could imagine. The more interesting question is "Why would someone use any of these languages?". Niche languages are typically associated with risk in the business world. But the thing is that Lisp just keeps surviving, evolving and finding new problems and domains to tackle. My personal opinion is that these languages represent the powerful combination of freedom, stability and engagement. A Lisp is inherently non-condescending as it gives you more powerful tools than most other languages, but it's also very reliable because it's built on a very well understood, minimal foundation. Last but not least you are programming in a way that is very engaging. You are right there in the running program.

wslh 4y ago

If we try to predict the future instead of reviewing the past I speculate that in the future (complex) programming languages will not be necessary since a big amount of code written in the world is redundant. So minimum declarative stuff will be enough to create the amount of software now built by lot of engineers. On the other hand, it is interesting to discuss what will happen with low level programming such as writing drivers, operating systems, and browsers. Some of these could be generated from an spec. I remember HN posts such as "A full TCP/IP stack in under 200 LoC (and the power of DSLs)" [1] that sounds like a toy now but hope to see in the near future to build complete stacks and just fill the spaces between. [1] https://news.ycombinator.com/item?id=846028 https://news.ycombinator.com/item?id=846028

flohofwoe 4y ago
> So minimum declarative stuff will be enough to create the amount of software now built by lot of engineers. That idea is the nuclear fusion of software development, it's always just 15 years away, even 50 years ago ;)
- wslh 4y ago
  Do you believe it would happen?
  - flohofwoe 4y ago
    Only in some niches, mostly related to data management, e.g. the same places where declarative programming already succeeds. I do agree though that the programming world is currently completely overstaffed, and that this has a bad overall effect on quality and progress, but this has 'business reasons', not 'rational reasons' and technological magic bullets are not the solution ;)
  - maze-le 4y ago
    In the early 2000s we had a Prof. for a course called "Hardware Technology". He really wanted us to get into electrical engineering and hardware focussed low level development, because according to him "SW development is dead, software can be created from specs and flowcharts by now". Great course, we learned about FPGAs and VHDL, but that advice really didn't stand the test of time.

edent 4y ago

I think it is interesting comparing computer languages to human languages. Reading Charles Dickens - a bit over 100 years old - is fascinating. Large parts of it are completely intelligible, and then all of a sudden there a phrase or bit of slang which just doesn't make any sense. Even listening to interviews with pop groups or politicians from the 1960s can produce a weird kind of cognitive dissonance - you know they're speaking the same language as you, but discussing long-dead concepts with outmoded words. I wonder if computer science will ever have the equivalent of Shakespearean scholars, trying to decipher the meaning or esoteric comments?

psychoslave 4y ago
>I wonder if computer science will ever have the equivalent of Shakespearean scholars, trying to decipher the meaning or esoteric comments They are already there. Usually you call them colleagues. :D

forgotmypw17 4y ago

I use Perl because the community prioritizes backwards compatibility. For the most part, you can run the same Perl script over 25 years of Perl releases, going all the way back to 5.000. This is one of the most important features for me, and I'm so grateful.

infradig 4y ago

Prolog got half-way there last year. It will go the distance. C as well. Lisp of course. The reason is that they define their paradigm. C#, C++, Rust, Ruby, Java are neither fish nor fowl and will not make it. Python has become too useful not to survive. I started with Cobol and would happily dance on it's grave before I pass.

kaba0 4y ago
Come on, Java is so insanely big that it simply will go there from momentum alone. Many says it is the new Fortran/Cobol, especially in finance but it has something special — the JVM. Plenty of old software continues to run on virtualized hardware simply because they depend on a given CPU architecture’s quirks and can’t be ported. The JVM is well-specified and thus any program programmed against it can run indefinitely, independent of hardware. Being cross-platform is also “vertical” in that past and future architectures can also be supported. And on top of that, tell me any other platform with a specification of both language and runtime (where even data races are not completely UB) that has as many independent implementation, many of which are supported by FAANG companies and could be developed alone further if anything were to happen to the others? Like, Alibaba alone could continuously develop the platform.
timbit42 4y ago
If by C, you mean, descendants of C, I agree with you. If you mean C itself will survive, I strongly disagree. I think with the recent focus on safety in languages, Rust and Ada, especially SPARK, will have better futures than C and C++. I think business is going to turn against C[++] for new projects, and there will be a push to rewrite C[++] code in safe languages, especially for operating systems, networking, and security code , making C[++] the next COBOL. Since safety isn't something you can simply bolt onto a language, many other safe languages will crop up to replace the rest of the unsafe languages.

davedx 4y ago

It's a very interesting article, but the lack of citations backing up some of the big claims make me doubt its premises. It's a shame because the author seems to know his programming language history. The most important IMO is this point: > Fortran is significantly faster than C Then later: > Is Performance Necessary for a Hundred-Year Language? > Fortran, one of the oldest thriving languages, lives and dies on performance. So that’s a check mark in the “yes” column. I did some googling and found that there are some design choices that might make Fortran faster, but it's highly debatable whether it's "significantly faster than C". Given how hardware has advanced over the years, "performance" just seems a weird feature to look for in a 100 year language too. You don't build performant software by building it in Fortran or C, you do it by making sensible design choices and writing thoughtful code, and not over-architecting or over-complicating provisioning. IMO C is obviously going to be a 100 year programming language, and I came away a bit disappointed the article didn't quite fully claim that. An interesting and thought provoking read nonetheless.

adrian_b 4y ago
In the past, Fortran was always faster than C in scientific computation applications, mainly because many optimizations are prevented when compiling C, by the risk of pointer aliasing. In modern C, such optimizations are possible by using "restrict". Nevertheless, few C programmers bother to write "restrict" wherever it should be used, so casually written C code remains slower than similarly written Fortran code. Moreover, modern Fortran has a lot of builtin operations for multidimensional arrays, which can be implemented in an optimized way by the compiler. Writing simple C code cannot achieve a comparable effect. Achieving a similar performance in C would require a special optimized library and this would result in extremely verbose and ugly C code. It is really impractical to do this in C and C++ must be used, with operator overloading, iterators and templates being needed to write a custom library that can match or exceed the builtin features of Fortran.
- davedx 4y ago
  > Writing simple C code cannot achieve a comparable effect. Can you provide a citation or source on this please?

xorvoid 4y ago

Human language doesn’t stay the same over 100 years. Is it reasonable to expect that from a computer language? To be fair, they are different. But, I think close enough to make the analogy stand. Different idioms, ways of expression arise constantly: come into and out of vogue. Human languages aren’t rigorously defined like computer languages must be. Human languages are loosely specifically by the amorphous collection of “all speakers” (whatever that means). And they evolve along those lines with each generation reshaping the language. Computer languages also change but they tend to hold onto their baggage much more. E.g. C is drowning in all the unchangable legacy from the 70s and 80s. Is a 100 yr programming language possible? Sure. But it’s gonna feel a lot like you’re a scholar in 2023 writing a modern academic technical paper in Latin or Early Modern English. Doable, yes. But comical. In fact, this is arguably already the state of C. Very useful programs are still written in it. And it feels like Early Modern English. Does that matter? Idk. But as the current trend in programming goes, most young engineers won’t be happy with this dynamic. Personally, I suspect we get it just because we have so many damn programs in the world. But I can’t imagine anyone will count it as a success.

frou_dh 4y ago

I liked the following blog post on the topic (coincidentally... it reps one of my favourite languages, hehe): "IM READY: LET THE 100 YEAR PROGRAMS BEGIN: Exploring Standard ML's robustness to time and interoperability" http://len.falken.directory/p-lang/100-year-programs.txt http://len.falken.directory/p-lang/100-year-programs.txt

NikkiA 4y ago

I'm not sure it's right about algol being dead, I've seen a renewed interest in it over the last couple of years, and I believe I even saw a new algol compiler - but I can't remember if it was for -68 or -60.

timbit42 4y ago
ALGOL, its Wirthian descendants (Pascal, Modula-2, Oberon) and Ada were designed to be safe languages. Partly due to Pascal's weaknesses in systems programming and partly due to the low speed of computers at the time, C took over, which was a shame because it is one of the least safe languages, but networking hadn't become common yet and people wanted to save every processor cycle possible and didn't want to waste any on safety. I think this resurgence of focus on safety could bring some life back to this line of ALGOL descendants. Of course Ada is still used worldwide in high reliability systems such as aircraft systems, air traffic control systems, and spacecraft. There is Ada code in NASA's Artemis project.

jbm0 4y ago

(1) I didn't know that COBOL was Grace Hopper’s baby! But I've spent decades trying to avoid learning too much about COBOL lest I accidentally back into having to support a COBOL system. (2) No mention of PL/I in the vaguely Algol-like group. I liked PL/I! (3) I'd never heard of Laravel, and was pretty okay with that. (4) "One of C’s old promises was to act like a PDP-11 computer." I wasn't aware of this assertion. I'll have to think about it. Do the increment / decrement operations mirror the PDP-11's addressing modes? I guess maybe they do! https://en.wikipedia.org/wiki/PDP11_architecture#Addressing_modes https://en.wikipedia.org/wiki/PDP11_architecture#Addressing_...

timbit42 4y ago
Actually, it isn't, is spite of commonly being referred to as such. From Wikipedia: * "Designed by Howard Bromberg, Norman Discount, Vernon Reeves, Jean E. Sammet, William Selden, Gertrude Tierney, with indirect influence from Grace Hopper" * "[Grace Hopper] did not participate in its work except through the general guidance she gave to her staff who were direct committee members. Thus, while her indirect influence was very important, regrettably the frequent repeated statements that "Grace Hopper developed Cobol" or "Grace Hopper was a codeveloper of Cobol" or "Grace Hopper is the mother of Cobol" are just not correct."