News for hackers. Stuff that matters.
Re:On the history and justification of the C programming lan... by nickpsecurity on Thursday August 18, 2016 @04:28PM (#12316092)
" If things had turned out differently we would be complaining about the lack of safety in code stil being written in Bliss or IMP or PL/S. "

Quite selective. The obvious counterpoint, which next version of essay will utilize, would be Wirth and Jurg's work in Lilith system. Two pro's + 8 part-timers, two years, plenty constraints, and whole system from HW to OS to apps to do with Pascal philosophy (balancing safety/speed/maintenance). To keep apples to apples, let's focus on language design the main two went with: the Modula-2 language. It's very simple, compiles faster than C due to cleaner grammar, is safe-by-default in a few ways, lets you turn that off where necessary, modular, supported concurrency, and runs fast. This approach got repeatedly iterated into progressively safer and faster systems by amateurs & pro's alike, sometimes just 1-2 students, that crashed less than C apps. Best part relevant to your comment: they built first Modula-2 compiler on a PDP-11. :P

Most of C's advantages, a few more on top of it, fewer problems, and developed on same architecture. Sounds like a clear winner from design standpoint. If you want simpler & faster, the Edison system is a good, extreme example of how ALGOL practitioner might do a C-like project. Too simple vs Modula-2 imho but beats C at its own game of fast minimalism with some Wirth-style benefits. Whole system, with source, got published in one paper.

http://modula-2.info/m2info/pmwiki.php/General/FAQ

https://en.wikipedia.org/wiki/Modula-2

http://brinch-hansen.net/papers/1981b.pdf

Re:On the history and justification of the C programming lan... by AnimalMuppet on Thursday August 18, 2016 @04:56PM (#12316254)
OK, Lilith took less time to write, and it was (also) on crummy hardware. Was it as useful as Unix was in production? Lilith never really took off. Either it wasn't as capable as alternatives, or it was marketed badly. My money is on "not as actually useful as theory predicted", though I have no evidence.

I note that Borland brought out a Turbo Pascal to go with Turbo C (fixing some of Pascal's shortcomings in the process), but never bothered with a Turbo Modula-2. If Modula-2 was better than Pascal, why not? (And, since the initial article seemed to be a fan of Algol, why didn't Borland do a Turbo Algol?) Microsoft had their Microsoft C that competed with Borland, but didn't bother to do a Microsoft Pascal. Why not? Because nobody cared about Modula-2, and not enough people cared about Pascal. And why was that? Because in practice, it was easier to write software in C than in Modula-2, or even than in Pascal.

You're idealizing dead languages. They're dead for a reason, and it's not just historical accident. In the real world, they were harder to use than the languages that theory said should be the best.

Re:On the history and justification of the C programming lan... by nickpsecurity on Thursday August 18, 2016 @07:38PM (#12317023)
"My money is on "not as actually useful as theory predicted", though I have no evidence."

The point was a research prototype they could use with safety and consistency down to CPU with hopefully benefits for teaching students. It succeeded at all that. The Ceres workstations that followed ran ETH university for a while. Quite useful. The students easily learned, modified, ported, etc the Oberon OS's. The hyperlink-driven GUI, mocked in that time, is also similar to the default method of obtaining information today that you're using to read this.

"but never bothered with a Turbo Modula-2. If Modula-2 was better than Pascal, why not?"

What does a company's marketing strategy tell us about the technical merits of a programming language? I don't know. It could be anything up to and including there were more C and Pascal users so they built C and Pascal compilers. Was my guess.

"And, since the initial article seemed to be a fan of Algol, why didn't Borland do a Turbo Algol?"

I'm fixing that part in next revision. It's coming across to some readers, including you, that I'm pushing for ALGOL itself to be built by 2 people on a PDP-11. That's... probably impossible. It's instead showing C did not have to be built, others did better with ALGOL subsets, most dominant (and productive) languages today have more capabilities in common with ALGOL than BCPL, and therefore that's the approach programmers should aim for instead of C's non-design. The constraints behind BCPL stopped being justified before PDP-11 existed. They definitely aren't now given all the alternatives.

" Because in practice, it was easier to write software in C than in Modula-2, or even than in Pascal."

This could be true for older versions. The question would be whether getting an app working... from prototyping to compiling to debugging to integration... is easier in C than in Wirth languages. I seriously doubt that just reading C programmers' own writings and bug reports. The minimal, extra amount of work is some typing you do that takes minutes but can save hours. They parse & generate faster but type-check more. So, compiler speed probably depends on implementation.

Hard for me to evaluate this one given students all over learn a language like Oberon easily while they struggle with C. Pros struggle to make C correct. How can C be less work?

"They're dead for a reason, and it's not just historical accident."

If that's true, then COBOL is still alive and well processing much of the world's critical transactions on its most reliable systems for a reason that's not historical accident and has everything to do with superiority of COBOL's design. Possibly why non-UNIX OS's dominate desktops, too. If popularity implies better design or usability, then perhaps people that believe that should buy Microfocus COBOL for Windows for their next app to test the theory. Whereas, an ALGOL subset & variant like Modula's, Oberon's or recently Go is probably way easier to work with due to design decisions per my theory. More effective in other metrics outside raw performance, too. Take your pick.

Note: You should also consider psychological and financial factors in the uptake of IT solutions. It might surprise you to find out that many popular things weren't necessarily the most effective solution. Or even most cost-effective.