Follow Slashdot stories on Twitter

 



Forgot your password?
typodupeerror
Programming

ESR Sees Three Viable Alternatives To C (ibiblio.org) 594

An anonymous reader writes: After 35 years of programming in C, Eric S. Raymond believes that we're finally seeing viable alternatives to the language. "We went thirty years -- most of my time in the field -- without any plausible C successor, nor any real vision of what a post-C technology platform for systems programming might look like. Now we have two such visions...and there is another."

"I have a friend working on a language he calls 'Cx' which is C with minimal changes for type safety; the goal of his project is explicitly to produce a code lifter that, with minimal human assistance, can pull up legacy C codebases. I won't name him so he doesn't get stuck in a situation where he might be overpromising, but the approach looks sound to me and I'm trying to get him more funding. So, now I can see three plausible paths out of C. Two years ago I couldn't see any. I repeat: this is huge... Go, or Rust, or Cx -- any way you slice it, C's hold is slipping."

Raymond's essay also includes a fascinating look back at the history of programming languages after 1982, when the major complied languages (FORTRAN, Pascal, and COBOL) "were either confined to legacy code, retreated to single-platform fortresses, or simply ran on inertia under increasing pressure from C around the edges of their domains.

"Then it stayed that way for nearly thirty years."

ESR Sees Three Viable Alternatives To C

Comments Filter:
  • Jesus Christ... (Score:2, Insightful)

    by Anonymous Coward
    ...this guy is fucking full of himself.
    • Re: (Score:3, Funny)

      by Anonymous Coward

      Agree. C++ is the future. Anything else is for outsourced chimps.

      • Re: Jesus Christ... (Score:2, Interesting)

        by Anonymous Coward

        Python makes programmers more efficient than any other language. It will win out eventually, once people get over their irrational fear of whitespace.

        • by Anonymous Coward on Saturday November 11, 2017 @10:38PM (#55533521)

          Python makes programs less efficient than any other language. It will win out eventually, once people get over their irrational fear of having their code not run slow as shit.

          Fixed that for you.

        • Python makes programmers more efficient than any other language. It will win out eventually

          Let me know when you can run Python on an embedded AVR with 256 bytes of RAM. When you get down to bare metal, it is either C or assembly.

        • by Anonymous Coward on Saturday November 11, 2017 @11:43PM (#55533691)

          Programmers who think being efficient means churning out lines of code are not worth hiring anyway. Coding is a small, even tiny part of software development.

          • ... Coding is a small, even tiny part of software development.

            Normally ACs are off in the weeds but this is the most insightful post here.

        • by Z00L00K ( 682162 )

          Python is to programming today what Basic was to programming in the 80's.

          They share a lot of similarities.

        • by Junta ( 36770 ) on Sunday November 12, 2017 @08:11AM (#55534843)

          Python is a mixed bag.

            It takes much longer to write all but the most trivial stuff in C. Languages like Python let you be exceedingly lazy. However like pretty much all managed runtimes, it is slow and inefficient, and even within the realm of managed runtimes, CPython isn't a particulalry fast or robust one.

          Also a language that lets the programmer be lazy is one that leads to poor performance decisions. In C, if it is hard for the computer, you are made to realize it is hard because it's more work to program. In C, if something is an operator (like +/-/[]/etc) it's a fairly deterministic handful of assembly instructions (C++ does not have that characteristic, what with operator overrides and such of course). In Python, that could be simple operators, or it could be some mallocs and several memcpys, who knows. You want to use a hash? In C you are going to use moderately tedious function calls because hashes are an expensive choice compared to when you can get away with an array or struct. In Python? Sure, go to town, hash everything. You want to mix and match integers and strings in an array? In C, yeah, you know that's a stupid idea because it's hard to do. In Python, not a single thought required so people do it. Such code cannot be optimized by any language implementation.

          Of course, the above doesn't matter much of the time because the difference in good and bad CPU performance is orders of magnitude smaller than the network IO delays that many applications are contending with, so the "let the programmer be lazy and produce crappy code" doesn't matter since a developer can just crank though the code they want to do without a thought and that's sometime totally worth it,.

          Also talking about a language where there is threading, but made utterly useless by the GIL. The answer of course was "well you don't need threads anyway, other methods give the appearance of similar concurrency when I/O bound and are harder to screw up" (which is frequently true for many applications, but no comfort to the subset for which that is not true.

      • Re:Jesus Christ... (Score:5, Insightful)

        by Z00L00K ( 682162 ) on Sunday November 12, 2017 @12:55AM (#55533863) Homepage

        C++ has all the bad parts from both C and Object-orienting with little added benefit. There's also a reason why for example the Linux kernel isn't written in C++ but C, and that is the memory management of C++ that isn't predictable for use in the kernel.

        C actually is a pretty good language, but it has at least two disadvantages:
        1. No strong typing.
        2. Pointers - you can with no warning work outside the predicted area so you can easily overwrite the stack or just about anything else.

        The quirk with C is that the unrestricted pointers also is an advantage in some cases so it's not a good idea to entirely scrap that ability.

        C is also a pretty good language when it comes to writing small compact efficient code that is portable between hardware architectures. It puts demands on the programmer to be competent and really be careful about what he's doing, but the gain is great. This is very useful in embedded solutions. And if you look at what you use when you program Arduino then it's C.

        The only alternative to C in some environments is assembly programming, but that puts a lot more demand on the programmers.

        • Re:Jesus Christ... (Score:5, Insightful)

          by religionofpeas ( 4511805 ) on Sunday November 12, 2017 @02:05AM (#55534003)

          1. No strong typing.
          2. Pointers

          I've been programming in C for a few decades, and I've made plenty of mistakes over the years, but very few of them had anything to do with strong typing or pointers. Most of them are just logic mistakes that I could have made in any other language.

          • Re:Jesus Christ... (Score:5, Interesting)

            by Junta ( 36770 ) on Sunday November 12, 2017 @08:43AM (#55534931)

            While I have not made mistakes with pointers (so far), I will say that it is tedious to constantly be passing around the max size parameter to every little function because that's the only way for a C function to safely deal with pointer data.

            Of course on the other hand, when I have reason to use C, it is refreshing and keeps me more aware of the limitations of the machine at all times. The coddling of other languages makes me forget and do slow algorithms out of laziness.

    • by K. S. Kyosuke ( 729550 ) on Saturday November 11, 2017 @10:52PM (#55533573)
      Technically, everyone is full of himself.
  • "Cx"? Uh... (Score:4, Funny)

    by K. S. Kyosuke ( 729550 ) on Saturday November 11, 2017 @09:48PM (#55533329)
    How exactly is it pronounced? Cause I can already see other language designers claiming "Our language is better than Cx!"
  • by bettodavis ( 1782302 ) on Saturday November 11, 2017 @09:51PM (#55533343)
    Just because they will be different, funnier and hipster than regular ones.

    We are in [current year] for goodness sake!, modernity must be made of fads that beget novelty from novelty's sake.

    Also boring, regular hammers and nails have been more or less as they are for millennia for some unknown reason (functionality? familiarity?, experience? previous use cases?, what's that?).

    The time to change those old tools is really long overdue.
    • by Mal-2 ( 675116 )

      We have "modern hammers", and they are used quite a lot in construction. Ever heard of a nail gun [wikipedia.org]? Sure, they haven't totally rendered hammers obsolete (for one thing, they suck at removing nails) but neither will Cx completely replace C.

      • by Hylandr ( 813770 )

        You're still not going to use a nail gun if you don't have the nails. C is the nails.

      • by geoskd ( 321194 ) on Saturday November 11, 2017 @10:34PM (#55533509)

        Sure, they haven't totally rendered hammers obsolete (for one thing, they suck at removing nails) but neither will Cx completely replace C.

        Cx, (or Go or Rust, or any other fad damned thing) will not replace C. The reason is simple. C is perfectly fine for most of what it is used for, and there is a huge amount of legacy code (plus toolchains, IDEs, and much much more) that exist in the C domain. Its not good enough that the Next Big Thing (tm) be better than C, it has to be better enough to warrant the extra cost of converting existing C code, C toolchains, C environments and the simple fact that there are uncounted millions of programmers out there who, almost without exception, know C. If I am going to start a new project (or more importantly, if I am going to pay someone else to start a new project) that falls into one of the areas that are traditionally C strongholds (such as embedded systems programming, kernel level systems design, device drivers, etc...) you can pretty well bet that it is going to be C that is used. Anyone trying to talk me out of it had better have a damn good reason, since I know the risks of using C, and I have no idea what the risks are of using XYZ new fad.

        • Simulink has been dominating embedded for some time now. It just generates C and you can continue to use your tool chains.

          • Embedded or DSPs?

            Because "embedded" as in nearly invisible computers with small OSes or even barebones runtimes are still pretty much C's domain. The first compiler most of this systems get is a C compiler, usually gcc.
            • Because "embedded"

              Embedded as in the chips in vehicles: trains, planes and automobiles.

              The Freescale PPC e200 chips and the Renesas RH850 line.

              usually gcc.

              Not a single chip I've worked on has had a GCC compiler.

              It's either WindRiver's Diab [wikipedia.org] or Greenhills [wikipedia.org]. Former used on the mars rover.

          • How does Simulink perform when you have to write a USB device driver ?

        • "C is perfectly fine for most of what it is used for"

          Except for anything with complex I/O for which security is relevant. Complex I/O such as a network interface or an USB port for instance, although frequently even text input has proven been too complex to implement securely in C.

        • by AmiMoJo ( 196126 )

          What are the use cases for a type safe version of C anyway?

          On the embedded side you can't live without being able to do type punning and other unsafe but extremely common techniques.

          On the desktop side people have realized that big C apps are very hard to secure (hi Adobe) and maintain and moved on to other languages like C# or just gone full node.js.

          In the middle you have things like operating systems, drivers, stacks etc. I guess they might benefit a little from being type safe, but do we actually have a

        • by xtal ( 49134 ) on Sunday November 12, 2017 @09:34AM (#55535071)

          C, Ethernet, and RS232/485 will be with us long after humanity has gone extinct. Possibly after the heat death of this universe.

          There should be a name for technologies that achieve that level of entrenchment.

        • C is perfectly fine for most of what it is used for, and there is a huge amount of legacy code (plus toolchains, IDEs, and much much more) that exist in the C domain.

          C persists because its designers decided to invent a language to express how the world actually is, rather than how faddish humans would like that world to be (in particular, even LISP doesn't entirely pass this test, because—like it or lump it—real computers are state machines).

          C is not perfectly fine, though it's perhaps the adequ

  • Not gonna happen (Score:5, Insightful)

    by Cthefuture ( 665326 ) on Saturday November 11, 2017 @09:53PM (#55533351)

    For as long as we're running Von Neumann architecture machines then C and C++ will continue to dominate anything and everything that needs to be high performance and/or low-level/hardware access.

    Because if you don't need C/C++ then you're scripting or whatever much-higher-level language stuff. Languages like Go and Rust fit somewhere in between... no-man's land, where they're doomed to get lost like every single previous attempt at such languages.

    • Because if you don't need C/C++ then you're scripting

      Yes, APL and the like totally qualify... But then again, APL and the like would profit from better architectures than what C runs on, so maybe you're right.

    • Re:Not gonna happen (Score:5, Interesting)

      by roca ( 43122 ) on Saturday November 11, 2017 @10:14PM (#55533431) Homepage

      This is totally wrong. The runtime and compiler models for Rust are pretty much exactly the same as for C. People are running Rust code on 8-bit microcontrollers: https://github.com/avr-rust/ar... [github.com]. You can write kernels and device drivers in Rust and people are.

      This is all less true about Go because it needs a garbage collector.

      • Except for running on 8-bit microcontrollers, why is it "less true about Go because it needs a garbage collector"? Why should it be less true for Go when it worked for Oberon?
  • by chrism238 ( 657741 ) on Saturday November 11, 2017 @09:53PM (#55533355)
    Claiming "I have a friend....trust me on this" instills so much trust, doesn't it?
  • by Anonymous Coward on Saturday November 11, 2017 @09:57PM (#55533369)

    Static code analysis and runtime checking (valgrind) pretty makes C's little issues a non-event now.

    And that lack of type safety is actually needed in some domains, so solving it makes it harder to write say kernel code.

    The only problems I've seen with C in the last fifteen years are when the ****ing C++ zealots get control of the C compiler and have managed to break C in the process ;)

  • by roca ( 43122 ) on Saturday November 11, 2017 @10:06PM (#55533403) Homepage

    Lots of smart people have tried hard to pull this off. See, for example C-Cured from UC Berkeley. They did not take off. I doubt ESR's "friend" is going to succeed where they failed.

    I think an approach like Rust is more likely to be successful, where in addition to providing safety you provide a lot of nice language features to make the language more appealing.

  • by e**(i pi)-1 ( 462311 ) on Saturday November 11, 2017 @10:33PM (#55533499) Homepage Journal
    What I want from a programming language are Standard, Stability and Speed. Nobody minds the little quirks, redundancies or the lack of elegance. When I program something today, I want it to run in 10 years, without modifications! In particular, I want the language to be around still, the grammar once put stay a standard. I want the program to run stably. In particular, I expect developers to be very careful when changing the compiler. Even small changes annoy. An example in C (which is in general quite good in respect to stability) it was no more possible to run gcc -lm example.c . Linking the math library required gcc example.c -lm. One has to change now 700 Makefiles just because somebody thought this is more elegant? I don't mind if a language is extended or sped up, but don't for change old grammar, not even the smallest things. There is lot of code around which would need to be fixed. I'm in particular careful with new languages. They first hype and spike. A language needs to earn respect, prove that it is stable over a long period of time.
  • by Latent Heat ( 558884 ) on Saturday November 11, 2017 @11:22PM (#55533645)

    I looked into Python for scientific/numeric programming, and from what I gather, key value paired lists are at its foundation and everything, including its object class model, is layered on top of that. Java, on the other hand, is based on an object class model from which you construct data structure objects such as key value paired hash lists?

    What I like about Java is that it supports dense arrays of numeric values. Its dense-array model is an exception to "everything is a" hash list/object/thingy. It appeared to me that Python implements arrays on top of key value paired lists/hash lists/dictionaries/whatever-you-want-to-call-them. Maybe that works for sparse-array numeric linear algebra, but much numerical programming involves operations on dense numerical arrays where compilers optimize array access in loops to incrementing address registers. Even in Java, which does not allow disabling this safety feature, the compiler will analyze loops to optimize bounds checking.

    Python has NumPy to support dense arrays of numeric values in this fashion, but NumPy, at least at the time 10 years ago I looked at it, was this wart on the Python language, in other words, something that sticks out and gives the appearance that it doesn't really belong there. It is straightforward to operate on NumPy arrays in native-code extension modules to Python, but on the Python side, such an array is this "blob" that you can only poke at with native-function calls.

    Matlab is the "thing", the expensive, proprietary thing that persons with engineering domain knowledge who cannot be bothered to learn a "real" programming language use. It is for the people who used to use Fortran to perform engineering calculations with one of those Tektronix "vector storage" video displays 40 years ago and now they have Matlab, which combines a goofy scripting language with a GUI with a vast legacy Fortran and C numerical library with a graphical visualization library.

    Forget about Matlab; I run Java as my "FORTRAN" in Eclipse and my Java programs output tab-separated columns of numeric data. Java does not have an "immediate mode eval-prompt" like the Matlab command windows, but the incremental syntax checking and compiling allows for much faster edit-build-execute cycles that what Visual Studio offers with C/C++. If my program crashes, I can quickly find the offending line in the Eclipse edit window -- good luck with that in C/C++. The Eclipse console window is a text-mode GUI allowing data exchange with other GUIs -- C++ in Visual Studio does not support such data exchange of numeric console-mode output. My "Tektronix vector storage display" is copy-and-paste to an Excel or Open Office Calc spreadsheet to plot the results.

    In my ideal world, there would be 3 layers, scripting/incrementally compiled managed-code/native code. I would like something other than the serious-coin-per-seat sole-source Matlab as the scripting layer (it interfaces well with Java with transparent exchange of dense arrays, in fact, the Matlab GUI is written in Java), but I really like Java for that middle layer.

  • If it can't target something as small as ATtiny25, it's not an alternative to C.

  • by bug1 ( 96678 ) on Sunday November 12, 2017 @03:27AM (#55534147)

    There are no flaws in C that cant be fixed by becoming a better programmer.

  • by roca ( 43122 ) on Sunday November 12, 2017 @04:23AM (#55534321) Homepage

    The answer is here: https://bugs.chromium.org/p/ch... [chromium.org]

  • by ytene ( 4376651 ) on Sunday November 12, 2017 @04:45AM (#55534383)
    I don't consider myself to be a programmer by profession, although I have been in the past, with experience spanning quite a range of different language types, including COBOL (74 & 85), FORTRAN 77, BASIC, JAVA, PHP, Visual BASIC (up to 5.0), VBA and Assembler (several different CPUs).

    When I started to learn programming languages at high school, the number available was relatively small (compared with today) and the differences between them relatively significant. Each language was specifically designed to solve a reasonably well defined set of problems. If you were working mainly with mathematical problems such as with physics or engineering, you'd use FORTAN. If you were developing applications for business, you'd use COBOL.

    Look again at the syntax and structure of these languages and their origins, architecture and design are clear.

    I am very (very!) sorry to all those professionals currently working in the field of programming language design if what follows is offensive, but we seemed to have entered an age in which a "fantastic" or "revolutionary" new language is released every few months. The better ones then follow the Gartner Hype Cycle before drifting back into obscurity. The mediocre ones never seem to make it even close to widespread adoption...

    We now seem to have reached a point where, instead of designing and developing a programming language to solve a specific business, scientific or technical problem, language designers are simply stealing primitives and ideas from existing languages and throwing them together into a framework before declaring their solution to be "The Next Big Thing (TM)". Of course this is a generalisation - every now and then we see some really remarkable innovation happening in the language space. JAVA for example, with it's aim of "write once, run anywhere" and it's much improved memory handling, would be a valid example.

    But in my ignorance I can't help but look at the current state of programming languages and think that too much of what we see today is just different, not necessarily better. Perhaps the most egregious mistake I see us making, as an industry, is that we're losing sight of the fact that programming languages should be designed to be easy. Remember the relevant portion of ESR's own "Art of Unix Programming", the Rule of Representation, which says, "Fold knowledge into data, so program logic can be stupid and robust."

    Do we see modern languages with the data handling sophistication of COBOL, for example? No. That's acceptable if the new language has a well-defined set of design goals that don't include data handling, but if not, I think we need to think very carefully about that old maxim, "all progress is change, but not all change is progress"...

    So whilst I'm always interested in learning about developments in programming language design, I think it helps if we ask a few fundamental questions of a new language:-

    1. What are the specific goals and design requirements of this language? How well does it meet them? Are there any compromises made in doing so ... and, if there are, are they acceptable?

    2. Of all existing programming languages that exist today, which one or ones are closes to this new offering in terms of goals and design requirements? Having identified the competition, what are the features and key differentiators of this new language that make the existing language obsolete? Are we certain (for example), that before embarking on an all-new language, that it is impossible to extend the legacy competition with new language primitives?

    3. Given that all design decisions are in fact compromises by another name, what is/are the impact(s) of the design decisions taken that differentiate this new language from the competition? [If these yield benefits, then wonderful; if they bring costs, then are we willing to accept them?]

    4. What is the learning curve like? Does the new language include weaknesses that yield to common mistakes?

    5. How vulnerable is this language? Has it been *thoroughly* reviewed by recognised cyber security experts and appropriate automated tools to ensure that the design contains no inherent flaws that could lead to easy exploits?

    6. Considering the "competition" that this new language seeks to supplant, what does the migration path look like? Is this "new" language just going to be used for new code, leaving a mountain of legacy code that we will still need to maintain, or can there be/are there automated tools capable of importing legacy code and generating replacement code in this new language? Does this new language help *solve* the problem of legacy code maintenance, or does it make it worse?

    I am sure that there are a few more equally valid questions that we could add to this list, but hopefully you'll get the picture. Massive fragmentation in the programming language arena is just going to result in more of a mess for future technologists to support. This runs the risk that we'll end up throwing away more technology than necessary, simply because it is "unsupportable"...

    I guess the title of this article helps to answer the first part of my second question, but if so then the designers have set themselves a high bar indeed... In order to reasonably displace a language as ubiquitous as C, a replacement doesn't just need to secure widespread support and adoption, but also the huge range of migration tools - across all the different platforms supported by the incumbent - and that is not a trivial task.

    Ultimately, over the life of a piece of software, our choice of programming languages is going to be the most important and most restrictive of all the design decisions we make. Want to extend that address field from 80 characters to 100? Easy. Want to change the programming language from this to that? Not so much. With this being the cold, hard reality, I think that adoption of a new language should be a decision that programmers take with very great care indeed...
    • by jrumney ( 197329 )
      I like how you dismiss newer languages as "simply stealing primitives and ideas from existing languages and throwing them together" but hold up Java as an example of a really innovative language for stealing a subset of the syntax from C++ and the VM and garbage collection from Lisp and throwing them together.
      • by ytene ( 4376651 )
        An entirely fair cop!

        I should have augmented my reference to JAVA with exactly the point that you raise - I did not mean to infer that it was somehow exempt from the problems seen elsewhere, only to offer it as an example of a language that had actually contributed some new thinking to language design. [ At least, I *think* that some of what JAVA offers is original thinking, although I'd be happy to concede that the example was poor if someone can correct me].

        If we could return to the principle, howev
  • by NikeHerc ( 694644 ) on Sunday November 12, 2017 @09:53AM (#55535145)
    Any developer worth his salt should be very, very wary of any tool or app that comes from google; they have a nasty habit of providing things that eventually disappear.
  • by Feneric ( 765069 ) on Sunday November 12, 2017 @12:23PM (#55535755) Homepage
    I'd argue that the Nim language [nim-lang.org] is another modern alternative to C.

Long computations which yield zero are probably all for naught.

Working...