HN Theater @HNTheaterMonth

"I appreciate that a lot of people start with C-ish syntax, and a similarly large number of people prefer that syntax, but I’ve never heard anything that demonstrated an intrinsic benefit of C syntax."

Short stuff is easier to type and maybe to read. There's that. Far as its "design," it was made by tweaking BCPL to make it run on a PDP-7 and then PDP-11. The assignment change was admitted as personal preference. BCPL itself was an ALGOL with LISP features that had every feature for safety, maintainability, etc chopped off to compile on a terrible piece of hardware they were stuck with. There was little to no design: can't overemphasize they literally just kept what that one machine could compile. Far as C, even structs originally weren't in it but got added after their failed attempts to port UNIX from assembly. Presentation below has proof from historical papers written by BCPL and C inventors.

https://vimeo.com/132192250

People just assume there was sensible design because of all the C code out there (argument from popularity). The brain then starts rationalizing attributes about it that were designed or hacked in for totally different reasons in a past of constrained hardware lacking knowledge or tools of modern, language design. That context no longer applies to most users of C. It's just myth-making by users reinforcing use of it.

⬐ jstimpfle

> The brain then starts rationalizing attributes about it that were designed or hacked in for totally different reasons in a past of constrained hardware lacking knowledge or tools of modern, language design. That context no longer applies to most users of C. It's just myth-making by users reinforcing use of it.

That's just _your_ rationalization. I don't think it's commonly claimed that all was set in stone from the beginning. The history is there for everyone to read.

Another possible explanation is that C is so minimal (in spirit) and doesn't get in the way, people are able to pull of impressive things, which makes them love C.

And now why exactly isn't (the gist of) C sensible design? I fail to see your argument. By the way, please enjoy this cool video: https://www.youtube.com/watch?v=khmFGThc5TI

Great overview. To support it on the design side, the video below shows the evolution of the language from CPL to BCPL to B to C. In it, you see they don't start with what's great for analysis, safety, or efficiency so much as what can compile on terrible hardware. Thompson's modifications are a mix of arbitrary and what will make it work on a PDP. Ritchie enhances a bit for operating systems. This is start contrast from the careful design of languages like Ada or Modula-3 balancing expressiveness vs safety vs performance. No surprise a bunch of problems followed. And same ones today, 30+ years later, in average app even with better tooling available since the language itself defaults on making simple stuff require extra work to do safely. Not necessary as Wirth, Morrisett, and others showed.

https://vimeo.com/132192250

It mostly wasn't designed if you're talking about C. It was almost totally the result of terrible hardware and personal preference derived from BCPL which was terrible hardware. The Vimeo link below goes from one paper & computer to another from CPL to BCPL to B to proto C's (IIRC) to C itself. Also shows interplay between C and C++ development. I'm also including my rant that summarizes the video in bullet points with some commentary. I still need to update it, though, with critiques from last time it was on HN.

https://pastebin.com/UAQaWuWG

https://vimeo.com/132192250

Now, for the other languages, who knows. I agree it's always fascinating to learn how they were done. I didn't get that feeling learning C's history. Not like when I studied Wirth's Lilith and Modula-2:

https://en.wikipedia.org/wiki/Lilith_(computer)

Note: Full description is in references under "Personal Computer Lilith."

I didn't know he asked for a better citation. I failed to spot that reading it originally. My mistake. I'll stop making that claim. I might still reference Karger in these discussions even if no credit was accidental as Karger's work deserves more recognition outside academia and actually teaches solutions to crap-load of problems (including this partly).

One more on Thompson. What got me suspicious about him was he had a famous work before that was also done by someone else. The other was much of the C language: its bare-metal nature, few keywords, and so-called "C philosophy" of programmer is in control. The original publications that got acclaim didn't cite the BCPL author, Martin Richards, at all despite him inventing and implementing all those concepts. They were in fact the BCPL philosophy originally with same semantics. Instead, just cited the B language like they did it all on their own in isolation with history crediting the victor that way. Publications that came a while after that started referencing BCPL.

Got that from the talk below which is great for tracing history of C from CPL project to BCPL to C to C++ influence.

https://vimeo.com/132192250

Really gives the big picture why Martin and others would do such languages with the constraints they were operating in. For this discussion, Martin Richards lays foundation for C-like languages with all key features and philosophy of C at 19:40 mark. Illustration of potential plagarism of C from Richards' work at 23:17-27:30. Looks a lot like cases of plagarism I've seen in academia but curious of your opinion as you're much more experienced in academic field. Would you think it was plagarism if you came across both works simultaneously seeing the one that came later without references was making waves?

"Did Dennis Ritchie have a hand in creating Go? I must have missed that."

Oops. You got me on my bad memory there. I misremembered Griesemer. The C language was originally just B modified with structs to try to port UNIX from assembly. Also, the limited keywords & "programmer is in control" philosophy came straight out of B. The details are in this nice Vimeo that traces its development going through papers they presented:

https://vimeo.com/132192250

"An expert in windowing systems and concurrency"

Even if we drop "language" expert, my comment had him bringing in concurrency mainly. I didn't know Cardelli started with Newsqueak, though. Makes sense given stuff as good as Modula-3 rarely comes from a vacuum.

"Articles like this one[1] by Pike only serve to reinforce my thoughts that he, though a rather smart guy otherwise, is really rather ignorant about language design and about the role of types in programming in general."

Well, see, it's been given a test. The Concurrent Pascal, Ravenscar, and Eiffel SCOOP approaches to concurrency were all very effective for what they're designed for. I've been sitting on the bench on Go watching it from afar to see what Pike's method does. So far, I see a lot of people griping about concurrency errors that didn't happen in SCOOP. Meanwhile, Rust has improved on things in a new way. Your characterization of him as an experimenter more than an expert may be right.

"None of Wirth's languages had GC until Oberon, as far as I'm aware. "

All of his languages except the first two that he started with. They made a lot of languages. It's kind of a strength and weakness of theirs as doubling down on a great one might have accomplished more. Might given Cardelli did without much direct impact.

"Oberon, on the other hand, was a very spartan language that offered little in terms of features"

So was early C. It's why I bring up Modula-2 or Oberon in comparisons as nobody is writing or deploying Modula-3 or Ada on a PDP-11. I'm not a fan of Oberon except for bootstrapping better languages or for minimalist hardware. Even then I'm more PreScheme.

"Later versions of Delphi grew to C++ levels of size, complexity, and hairiness"

Snowballs rolling into avalanches. Common ill in tech although I think it's human nature or economics more than anything. It takes a cathedral model that prioritizes just right amount of complexity to avoid. I just subseted languages like embedded people do to avoid the shit. Until I had to debug a 3rd party library. (shakes head)

"The patterns of thinking that we take for granted around iteration and prototyping were still too alien. You have to get it before you can do it, and the types of programmers who were inclined to get it weren't in decision-making positions."

Maybe I was too harsh on them. It does seem likely. Further, it probably came directly out of the nature of programming on expensive, shared, and often batched machines. Here's a great example of what programming looked like in the 60's (skip to 5:27):

https://vimeo.com/132192250

It wouldn't have been much better a bit after 1970 where many of the same concerns and processes would exist. I still think one has to ignore most of the Royce's paper to not pick up on iteration paradigm. But, I could easily see someone in that mentality sort of glossing over it, spotting a diagram of their current flow, giving it a name, and pushing it from there.

Finally read the paper you gave me. It was really neat to see iterative development kept getting independently invented from the 60's onward. It getting into the mainstream was an inevitability due to its inherent advantages. The majority just couldn't contain it within limited groups forever.

"and found out that what they had really done was write code first, secretly, and then write up the requirements and design docs based on what they had learned. In other words they did things in the 'wrong' order but published them in the 'right' order."

That's funny you say that: history is repeating in high-assurance field. Safety-critical design is like waterfall or spiral on steroids with specs, constraints on implementation, rigorous testing, analysis... you name it. To outsiders, it seems they're using a waterfall-like refinement strategy to build these things. Insiders trying to get Agile methods in there have countered that with an unusual supporting argument: successful projects already use an iterative process combining top-down and ground-up work that results in a linked, waterfall-like chain of deliverables. The actual work is often done differently, though, so why not allow that kind of development in the first place?

With your comment, I've heard that twice. Another quick one was Mills' people not being able to run their own code in Cleanroom. Sometimes it wasn't necessary but it has many benefits. So, of course they often ran their own code during prototyping phase to get an idea of how the final submission should be done. We'll all be better off when management lets their processes reflect the realities of development. At least it's already happening in some firms and spreading. :)

https://vimeo.com/132192250

⬐ acqq

For those like me who prefer slides:

http://www.pvv.org/~oma/HistoryAndSpirit_NDC_Jun2015.pdf

They are good!

That vimeo talk was rich.

ps: https://vimeo.com/132192250

⬐ nickpsecurity

It's in my references.

⬐ agumonkey

I just wanted to put it upfront rather than a link at the bottom.

⬐ nickpsecurity

It's all good. Makes sense. Just making sure one of us didn't overlook it in the references.

There is some interesting content here regarding how older languages were ignored in the process.

History and Spirit of C and C++ @ NDC 2015

https://vimeo.com/132192250

⬐ nickpsecurity

Appreciate it. Watching it now as I have some spare time. Seems good so far.

⬐ nickpsecurity

Finished. Was a pretty good video. I did a write-up of it below on Schneier's blog to justify eliminating C because it's provably Bad by Design. All due to limitations of the PDP's and, new to me, the EDSAC. Also more of a rip-off of BCPL than I thought before.

https://www.schneier.com/blog/archives/2015/10/friday_squid_...

⬐ pjmlp

Very good write-up. Sadly I can only up-vote once.

Actually, he adapted BCPL by changing a bit the syntax and taking a few things out to fit into the PDP, but even the manuals were almost a copy from the BCPL ones.

https://vimeo.com/132192250