Slashdot Mirror

← Back to Stories (view on slashdot.org)

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

Posted by EditorDavid on from the legacy-languages dept.

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."

25 of 595 comments (clear)

  1. Jesus Christ... by Anonymous Coward · · Score: 2, Insightful

    ...this guy is fucking full of himself.

    1. Re:Jesus Christ... by Anonymous Coward · · Score: 1, Insightful

      All the most widely used operating systems are written primarily in C/C++

      All the most widely used web browsers are written primarily in C/C++

      All the most widely used business applications and their open source equivalents, are all primarily written in C/C++

      The problem is not the language. The problem is too many shitty, incompetent programmers and too many companies who don't give two shits about producing good products.

    2. Re: Jesus Christ... by Anonymous Coward · · Score: 4, Insightful

      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.

    3. Re:Jesus Christ... by Z00L00K · · Score: 5, Insightful

      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.

      --
      If builders built buildings the way programmers wrote programs, then the first woodpecker would destroy civilization.
    4. Re:Jesus Christ... by religionofpeas · · Score: 5, Insightful

      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.

    5. Re: Jesus Christ... by Hognoxious · · Score: 4, Insightful

      Just a thought: What do you suppose the worldwide carbon footprint of DRM is?

      A lot less than Bitcoin's.

      --
      Confucius say, "Find worm in apple - bad. Find half a worm - worse."
    6. Re:Jesus Christ... by VirginMary · · Score: 1, Insightful

      C++ is tricky to get right in a kernel context because you cannot depend on garbage collection. When using something like STL, stuff gets scattered across more memory pools than desirable. Reallocation strategies have unknown semantics and timing.

      1. What does garbage collection have to do with C++?
      2. Where does it say that you have to use the STL in kernel code?

      I used to program in C and still love the language. For years now I program primarily in C++, but also in Java, Python and PHP (Boy, do I *hate* this language!). I think that only idiots and masochist would prefer C over C++. C++ gives you far better abstraction capabilities. Destructors and const member functions are wonderful, just to pick two examples, and, if you understand how C++ works, you can get the same close-to-the-metal efficiency of C but with far fewer lines of code that is also safer and more reusable than the same thing written in C. It is much easier to write C++ code without memory leaks than to do the same thing in C. Finally RAII rocks.

      --
      When 1person suffers from a delusion,it is called insanity.When many people suffer from a delusion,it is called religion
    7. Re: Jesus Christ... by Junta · · Score: 5, Insightful

      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.

      --
      XML is like violence. If it doesn't solve the problem, use more.
    8. Re: Jesus Christ... by Hal_Porter · · Score: 3, Insightful

      People always say this - programmer time is expensive, compute power cheap, efficiency doesn't matter.

      However look at Reddit. They originally wrote in Lisp, and then rewrote it in Python. And it's still slow enough it goes down regularly. Despite the fact that it's using a relatively light framework - web.py and then Pylons.

      You could imagine writing a web framework in something like C or C++ that would be much more efficient than Python.

      I mean I like both Python and C/C++. Python is definitely easier to prototype stuff in. C/C++ is fast as hell. And if you're serving a website to vast numbers of people that means you need less hardware to do it.

      Or look at Windows apps. .Net and Java ones are so crappy I avoid them. Native Win32 with a stripped down framework gives you tiny, fast applications like uTorrent.

      I'm still convinced a lot of the smoothness of iOS applications over Android is because Apple use Objective C while Google use Java. You can handwave away the slowness of Java with things like JIT and AOT code conversion but just picking the two devices up you can see that Android is not a particularly performant environment.

      Now personally a multi vendor OS is important enough that I can live with it being a bit crappy so I went from Windows Mobile to Android and not to iOS. Android, like Windows Mobile before it is multivendor which means you have cheap hardware and loads of free or cheap software and third party Roms and firmware images. Like Windows Mobile it's kind of a mess though - Windows Mobile was always about ten years behind the state of the art in terms of UIs. Android is crippled because most of the applications are written in Java.

      --
      echo -e 'global _start\n _start:\n mov eax, 2\n int 80h\n jmp _start' > a.asm; nasm a.asm -f elf; ld a.o -o a;
    9. Re: Jesus Christ... by Zero__Kelvin · · Score: 1, Insightful

      Why would you just randomly make shit up about C++? Do you really think there aren't people here who actually understand C++ and realize that you literally have no understanding of it when we read your absurd claims?

      --
      Guns don't kill people; Physics kills people! - John Lithgow as Dick Solomon on Third Rock From The Sun
  2. Let's re-invent hammers and nails by bettodavis · · Score: 3, Insightful

    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.

    1. Re:Let's re-invent hammers and nails by geoskd · · Score: 4, Insightful

      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.

      --
      I wish I had a good sig, but all the good ones are copyrighted
    2. Re:Let's re-invent hammers and nails by xtal · · Score: 5, Insightful

      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.

      --
      ..don't panic
  3. Not gonna happen by Cthefuture · · Score: 5, Insightful

    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.

    --
    The ratio of people to cake is too big
    1. Re:Not gonna happen by Misagon · · Score: 4, Insightful

      I would say that before C++11, all C++ code could be compiled into the equivalent C code without loss of performance .. which is also how the very first C++ compilers worked.
      In C++11 came move-semantics and better synchronisation primitives that C did not have. In C, you may be able to use intrinsics for synchronisation and atomic access though but move-semantics even for simple value types can improve low-level performance.

      While I am also primarily a C++ programmer, I do mostly agree with the AC.
      Most of the so called "idioms" in C++ are what would be called "hacks" in any other programming language.

      C is more readable than C++. In C++, you often have to spend more mental energy trying to find out what exactly is going on in other people's code.
      For instance, because what looks like one type of call might actually be something else involving operators that takes place between types higher up in the class hierarchies, and what looks like value-semantics may actually be pointer semantics because references are used.
      You are often completely dependent on the IntelliSense (or whatever it is called) in the code editor you are using to not get lost.

      Next, shared_ptr needs multiple objects for a friggin pointer and C++ lack the concept of "borrowing" which I would say is absolutely essential in a language with unique pointers.

      --
      "We mustn't be caught by surprise by our own advancing technology" -- Aldous Huxley
    2. Re:Not gonna happen by PhrostyMcByte · · Score: 5, Insightful

      C has critical flaws everywhere...

      For what C is used for, none of those are even approaching "critical". A lot of criticism leveled at C and C++ these days tends to come from high-level devs who simply don't have enough context for what someone could want in an improved C. As someone who clearly has a better understanding, you could do better to rise above hyperbole.

      At this point with C, there are very few things everyone can get behind as an improvement. A lot of people like it for its small non-magic surface area, and something like e.g. tagged unions would even be too much syntax sugar. I think if people wanted a broadly more powerful language they'd move right to C++, but they don't -- so we need to look at why that is, and maybe we'll have a better idea of what a "new C" could possibly look like.

    3. Re:Not gonna happen by Pseudonym · · Score: 3, Insightful

      Most of the so called "idioms" in C++ are what would be called "hacks" in any other programming language.

      That's true in any programming language, by the way. Even Haskell, probably the most pure language that is used in practice, has a bunch of "idioms" to make up for the fact that it doesn't have mutable state. Almost any other language would consider that a hack.

      --
      sub f{($f)=@_;print"$f(q{$f});";}f(q{sub f{($f)=@_;print"$f(q{$f});";}f});
    4. Re:Not gonna happen by Anonymous Coward · · Score: 2, Insightful

      No offence but I can tell you are not a C programmer.

      The great thing about C is that you can fully understand every aspect of it.

      When I hear someone say that I know someone who hasn't been keeping up with the standard. You are probably still stuck at ANSI C.

  4. Instills trust, no? by chrism238 · · Score: 5, Insightful

    Claiming "I have a friend....trust me on this" instills so much trust, doesn't it?

  5. Solve the 'problems' of C now they aren't problems by Anonymous Coward · · Score: 3, Insightful

    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 ;)

  6. "C with safety" has been tried before by roca · · Score: 5, Insightful

    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.

    1. Re:"C with safety" has been tried before by Anonymous Coward · · Score: 3, Insightful

      Any forceful language isn't tolerated. You know damn well people are going to be driven away (banned indefinitely from communications) for hurting people's feelings.
      OpenBSD nor Linux wouldn't exist in their current forms under a rust code of conduct. No wonder the language is such shit.

  7. standard stability and speed by e**(i+pi)-1 · · Score: 5, Insightful

    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.

  8. Re:Solve the 'problems' of C now they aren't probl by phantomfive · · Score: 2, Insightful

    (1) Undefined behavior. UB is completely unacceptable in 2017

    You'll be sad to find out that your favorite language has undefined behavior as well, unless your favorite language is ML. It's just not worth the effort to fully define the language.

    --
    "First they came for the slanderers and i said nothing."
  9. A new c... by fyngyrz · · Score: 5, Insightful

    I think if people wanted a broadly more powerful language they'd move right to C++, but they don't -- so we need to look at why that is, and maybe we'll have a better idea of what a "new C" could possibly look like.

    I think a "new c" might look a lot like Go - without the handicap of garbage collection.

    There hasn't been a garbage collector written yet that doesn't constitute an outright insult to performance and predictability.

    --
    I've fallen off your lawn, and I can't get up.