apotheon

I'm not sure whether you're serious.

Imagine telling Brian Kernighan about a cool language you found called C, not realizing Brian wrote a lot of C.

Imagine telling Dave Thomas about a cool language you found called Ruby, not realizing Dave has written a lot of Ruby.

Imagine telling Douglas Crockford about a cool language you found called JavaScript, not realizing Douglas has written a lot of JavaScript (much of it full of bad ideas, but that's irrelevant in this case).

Imagine telling Harold Abelson about a cool language you found called Scheme, not realizing Harold has written a lot of Scheme.

Imagine telling Randal Schwartz about a cool language you found called Perl, not realizing Randal has written a lot of Perl.

Like all of the above, for the respective language (LISP in Peter's case, C in Brian's, and so on), Peter Norvig is a well known master who has written a seminal work about the language.

q.v. Paradigms of AI Programming: Case Studies in Common Lisp

He also wrote Teach Yourself Programming In Ten Years, which many people who know basically nothing about LISPs have encountered and consider important.

If I would have any objection to the brief story's use of the term "ironic", it would be about the fact that many LISPers might not be as enthused about Clojure, so it's possible Peter hasn't really looked into it. Your question implied that Clojure is just "Lisp", though, and if we're talking about "Lisp" in a generic sense (i.e. the LISP family), I think Peter Norvig is one of those luminaries that everyone who pays attention to the social context and most important written works about LISP would know. I don't even pay that much attention to those aspects of LISP knowledge, and I know about him in the context of LISP.

That's not to say everyone who has an interest in LISP should be thought deficient for not knowing about Peter. It's fine if you haven't stumbled across him before. Sometimes, people just miss things that, in retrospect, might seem like something they should have known.

That doesn't mean you have to even have an interest in LISP.

This should, however, hopefully, give you a sense of why Peter might think it was "ironic", even if "ironic" feels a bit questionable as the appropriate choice of term there. I'm sure to him it felt a little ironic, and that makes sense to me as an emotional response, at least.

Does that help?

(Imagine telling William Shakespeare about the Renaissance era techniques of being a playwright, or telling James Cooke Brown about a conlang called Lojban. Of course, I suppose James might be dismissive of Lojban, given he tried to control Loglan by proprietary means after creating it, thus prompting others to reimplement it as Lojban, undermining his efforts at such control.)

edit: Note that I'm not saying there's anything wrong with someone not realizing one is speaking with a Big Name in LISP when meeting Peter Norvig. I'm just saying that Peter is perhaps justified in finding it a little "ironic", and jumping to conclusions about why he would feel that way (if that's what you're doing) might not be fair.

I would probably feel awkward in Peter's position. I've been in a similar position before, including once being told about a cool article that I actually wrote as if it would change my life, and I never know what to do in a case like that. How do you point it out without possibly making someone feel offended? Humans get offended at the silliest things sometimes, and I occasionally find it quite difficult to predict.

You appear to have the empathy of a moldy cheese sandwich.

> I am under instructions to talk about this stuff, openly and honestly, and to see that people aren’t as judgmental as the wounded child within believes.

In my experience, you should prepare to be disappointed. Judgementalism is how people survive in a world that rewards niarcissism; they judge others to be inferior to give themselves the strength to go on. It's an arms race.

Intellectually, I understand that people are mostly crap. Emotionally, I keep making the mistake of trusting people's supposed good intentions when I feel like I've gotten to know them, and finding out that, once again, they're judgemental assholes who will fabricate tales to tell themselves so they can absolve themselves of meaningful guilt.

There are good people, non-judgemental people, caring people, who can sympathize with you and who deserve your trust (assuming you're a well-meaning person, as I suspect from what I've read here). From your description of some aspects of your life, it seems you've found one or two, and I'm happy to hear it.

Mostly, people want to tell you fairy tales about the good in the world. Most of it is pretty mediocre; even middling is a stretch. It's not distributed evenly, though, and it's worth holding out hope. I was lucky enough to meet one of those rare lights in my early teens, and we're still in touch. I was lucky enough to meet several others along the way, and I charish their influences on my life. I'm lucky enough to live my life with one now, and for quite a few years up to this point. They make it all worthwhile.

I think a lot of the arrogance that develops in some smart kids is a result of being shunned for being right. Kids often start out trying to help others by pointing out how something could be better, get socially (sometimes physically) beaten up for it, then develop into condescending assholes as a defense mechanism.

You need to give better advice than this to people when they're five, when they actually need it.

I learned early on that being right was no defense, and that no matter what happened I would always be blamed. These were the wrong lessons, but society at large was the wrong teacher, so I guess we're even.

This doesn't stop when we stop being kids. In the so-called "adult" world, people make some of the stupidest decisions imaginable on a daily basis, and refuse to acknowledge any errors in their choices no matter how they're brought up. Helping other people turns out to be an exercise not only in futility, but in masochism as well.

I've been called "justifiably arrogant" in the past. I've been condescending. I've come out the other side, and now basically think of myself as kind of mediocre. I used to look around at how people make much worse decisions than me about the important stuff and feel a little comforted by the idea that at least I'm doing better than them. Now, it just makes me sad, because I realize I kinda suck, but 98% of people make me look good by comparison.

I've learned to "go along to get along" to some extent, with people who don't matter to me. The people who do matter to me are the people with whom I can be honest, because honesty is a great way to get yourself in a lot of social trouble otherwise.

Mostly, what it comes down to, is that basically everybody sucks, smart or not, and everybody wants to believe "My shit doesn't stink." There's a grave injustice afoot when someone actually has a good idea, by way of applying some native intelligence and learned rationality to a problem, and gets punished for it, though -- and native intelligence helps people realize they're getting burned at the stake over someone else's superstitions, thus making "smart kids" bitter, dismissive, and lonely.

I'm generalizing a lot. Exceptions abound.

It depends on whether you're talking about an actual whole new, radically different language or something that is essentially C "with improvements". My point is not that C "with improvements" is the ideal approach, only that (at this time, for almost purely social reasons) I don't think C is really subject to replacement except by something that allows you to mix standard C and the "new language" because, apart from specific improvements, they are the same language.

This might come with huge drawbacks, but it still seems like the only socially acceptable way to fully replace C at this time; make it so you can replace it one line of code at a time in existing projects.

> What is meant by "portable code"? Should it refer only to code that should theoretically be usable on all imaginable implementations, or should it be expanded to include code which may not be accepted by all implementations, but which would have an unambiguous meaning on all implementations that accept it?

That's a good question. I'm not sure I know. I could hazard a guess at what would be "best", but I'm not particularly confident in my thoughts on the matter at this time. As long as how that is handled is thoughtful, practical, consistent, and well-established, though, I think we're much more than halfway to the right answer.

> Historically, if there was some action or construct that different implementations would process in different ways that were well suited to their target platforms and purposes, but were incompatible with each other, the Standard would simply regard such an action as invoking Undefined Behavior, so as to avoid requiring that any implementations change in a way that would break existing code.

If I understand correctly, that would actually be "implementation-defined", not "undefined".

> a directive demanding that "long" be 32 bits would provide a clear path for the implementation to meet its customers' needs

There are size-specific integer types specified in the C99 standard (e.g. `uint32_t`). I use those, except in the most trivial cases (e.g. `int main()`), and limit myself to those size-specific integer types that are "guaranteed" by the standard.

> Just get it done. Don't ask.

Yeah, I didn't think it would go the way it did. That was the first time I noticed a problem.

What I really should have done is start searching for another job a week into this "process".

I'd rather give employers what they want, and -- if what they want is stupid or insane like that -- leave before I have to give the employer very much of what it wants, because I don't want to be a part of that.

> I heard later on that a VP refused to accept the solution because he insisted it must be wrong since it was completely inconceivable that it could be solved that quickly.

I loathe crap like that.

> I'm against the idea of laypersons or the [non-judicial] branches of government using the guise of "ethics" or "morality" to arbitrarily silence people.

I agree with that position.

I haven't looked at Zig too closely yet (only started just a few minutes ago), but it immediately appears to me that this violates one of the requirements I suggested, as demonstrated by this use-case wish from my previous comment:

> > using the new language's compiler as the project compiler front end's drop-in replacement (without having to make any changes to the code at all for this first step)

I'll look into Zig more, though. Maybe I'll like it.

---

I stand corrected, given my phrasing. I should have specified that it needs to also support incrementally adding the new language's features while most of the code is still unaltered C, rather than (for instance) having to suddenly replace all the includes and function prototypes just because you want to add (in the case of Zig) an error "catch" clause.

> What is your definition of "portable"?

In that particular statement at the beginning of my preceding comment, I meant portability across compiler implementations.

> Eliminating an argument from a function by hiding it in a data structure is not that compelling to me since I can just do that on my own.

I meant to refer more to the idea that, when doing it on your own in a particular way, the compiler could support applying a (set of) constraint(s) to prevent overflows (as an example), such that any constraint couldn't be bypassed except by very obviously intentional means. Just automating the creation of the very, very simply constructed "plus a numeric field" struct seems obviously not worth including as a new feature of the standardized language.

> the fact that length+pointer is such a common construct indicates that most people don't have any issues with it

I think you're measuring the wrong kind of problem. Even C programmers with a high level of expertise may have problems with this approach, because it's when programmer error causes a problem not caught by code review or the compiler via buffer overflows (for instance) that we see a need for more.

That's obviously true, but at the same time the specifics of how one chooses to set criteria for inclusion in the standard should probably keep in mind the social consequences. If the intended consequence (e.g. ensuring that implementation is easy enough and desired enough to end up broadly included for portability) and the likely consequence (e.g. reduced standardization of C capabilities in practice, with rampant relianced by developers on implementation-specific behavior to the point almost nobody writes portable code any longer) differ too much, it's time to revisit the mechanisms that get us there.

Yep. That happens a lot, in practice.

> Popularity contests are not simple.

I did not, in fact, say they were.

> My claim is that having the most mindshare/resources is the simplest way to keep having the most mindshare/resources.

That's largely true. Of course, having "enough" mindshare/resources is plenty, generally; one needn't necessarily have "the most". I don't see Ruby or Rails going away any time soon, even if your local area's angel.co listings show a 40% higher rate of job postings that explicitly mention Django in the headline. Development is still quite active both on, and with, the language and the framework.

> Coming back to the original topic, this might mean that even if you invest a lot in the "best" tool to solve your problems it is possible that the lack of ecosystem around it (due to other people choosing "worse" tools for the same problems) makes it a losing investment.

If your choice is Smalltalk, that might be true. If it's actually a very active community around a language and framework that provide extremely good productivity support and a lot of advanced tooling constantly attracting more innovation and heavily used in some sectors, like Ruby and Rails, it's not so true. There's pretty much guaranteed (absent government-granted monopolies) to be quite a bit of diversity in "popular enough" languages and tools for any high-traffic development sector, and "startups" definitely qualifies as such a sector of development as a field of professional work. The "winner" approach you seem to want to champion would have room for basically two options, and both of them have "Java" in the names of their most popular implementations, so arguing about the relative popularity of a Python framework in one corner of the world is irrelevant at best given your evidently intended thesis.

> Example: Bitcoin is the among biggest cryptocoins mostly because it was the biggest at some point.

This is a good point, but does not address the fact that this doesn't mean discounting Decred or Monero as a terrible choice for any useful timescale is the obvious best option.

Ruby on Rails is more popular in some areas than Django. Ruby on Rails gets a lot of time and money investment. Ruby on Rails is likely to be a good, stable choice for years to come. That example illustrates the fact that always choosing "the winner" doesn't make sense if "the winner" involves choosing the second-worst tool for your specific job out of a field of a dozen or more available tools.

Not literally everyone, I would think, but the previous statement could, in theory, still be true. It would just require some people to want something else, conflicting with that desire, even more.

I know, this is pedantic, I suppose. Mea culpa.

> Conversely if you don't want any of this what's wrong with:

As I suggested, adding a(n optional) constraint such that "buf" can be limited by "len" in such a struct is a possible approach to offering safer arrays. Such a change seems like it kinda requires a change to the language.

> every single item in C++ was wanted and championed by someone

This is irrelevant to the point I made in the text you quoted.

> Well, C did turn into C++. The entity that gave forth C++ is C.

My mother didn't turn into me. She just gave rise to me. She's still alive and well.

My point, which seems to have completely escaped you, is that C itself should not turn into C++, so claims that any attempt at all ever to improve C with the addition of a single constraint mechanism for managing pointer size safely is a slipper slope to duplicating what C++ has become, leaving no non-C++ C language in its wake -- well, such claims seem unlikely to be an unavoidable Truth.

> A good way to have a C++ with fewer features would be to trim from C++ rather than add to C.

Again, my point is not easily crammed into the round hole of your idea of how things worked. It is, instead, that C can have a few more safety features without becoming "C++ with fewer features".

I feel like you didn't read my previous message as a whole at all given the way you responded to it, and just looked for trigger words you could use to push some kind of preconceived notions.

That should have said "many contend". Now it seems too late to edit.

If we assume, basically, that only The Winner Language should ever be used, we either end up with a long-term glut on technology churn (e.g. JavaScript's miserable state of instability right now, but for everything and not just JavaScript) or rapid development of novel forms of mediocrity (Java), and nobody should ever bother with Python, in which case the previous commentary still makes no sense because Python isn't "The Winner".

Sufficient investment for significant ongoing value is a matter of a threshold relevant to the particular needs served by the target technology, not of rank. As long as there's "enough" interest, it will have as much likelihood of stable or increasing value for (appropriately targeted) users as anything else.

Meanwhile, too much investment from too-big interested parties can ruin something pretty thoroughly.

Things are not as straightforwardly popularity-contest-driven as you seem to suggest.

There's an iceberg of Ruby jobs that don't exist in the most obvious places to search, and because other languages have gained more spotlight (including anything that even smells of ECMAScript) there are fewer people searching for Rails jobs so the number of Rails jobs is pretty well matched to the number of job-seeking Rails devs. Also, early stage startups tend to hire from people they know, not from job search sites. Finally, there are many "full stack" jobs where work on the backend means Rails.

A simplistic metric like "job listings on angel.co" (especially if you're specifically looking for Rails in the job posting title) don't tell the whole story.

If you're basically building everything from scratch, of course you aren't going to see the churn as much.

If you build on others' frameworks, and those frameworks drop out of maintenance because the maintainers moved on to shiny new things, any security vulnerabilities or emerging incompatibilities with browsers can quickly prove ruinous for people who used those frameworks.

I wrote a SPA while working at a consultancy. It was actually pretty churn-proof the way I wrote it, but during one vacation day and the following weekend a couple people (including the boss) just rewrote the whole thing to use more faddish framework stuff. I don't work there any longer, but since then (about 2016) they've probably had to effectively rewrite it twice if they kept up with that approach.

That's what I mean by "constantly impending obsolescence".

I once worked at a nine person company where a three-minute fix to a piece of internal software ended up taking about two months of screwing around with revising a project proposal and, in the end, it was decided to drop the fix because what amounted to the #2 person in the company decided the tool would "eventually" be thrown away anyway.

Let me know when it's done settling in ECMAScript Land, then. In the meantime, I'm doing interesting stuff Somewhere Else.

I enjoyed the hell out of writing application plumbing, but the moment it started turning into an actual application that interacted with the outside world I was dealing with the hell of the Node ecosystem of "compiling" and packing for the browser, framework crap, buggy testing libraries, and all the rest of that nonsense, with an acutely clear understanding that all of it would change in five years and I would have almost zero useful knowledge from the tooling and ecosystem experience of the preceding half-decade.

In the mainstream professional JavaScript world, my advice is to escape as quickly as you can, and pursue things where the learning focus is on more interesting things than the arbitrary whims of the authors of half-baked (because they never have time to mature before they die) frameworks. If you can just live on the fringes and write JavaScript your way and not worry about constantly impending obsolescence of your entire technology stack (from Linux all the way up to your JavaScripty CSS framework), though, I'm sure you can have a great time doing it.

I'm writing a lot of C and Ruby these days, and I love it. I get to learn more about myself as a programmer, instead of more about other programmers as fly-by-night framework developers.

Oh, yeah, and if I have to learn a whole new fucking sub-ecosystem and new version of the language itself with a bunch of breaking changes every two to five years, I don't have any time to spend learning fun things like a whole new language designed around a whole new paradigm.

ECMAScript and everything that touches it has become an actually focused bane for the joy of programming. It was fun just writing some clean plumbing for JavaScript applications in the past, but everything else about the process always ended up involving a bunch of scrambling to catch up with rapidly changing technology, planted on shifting sands even while I'm working with it, any time I start on a new project, where all I'm learning is a new set of persnickety conventions that will punish me if my approach is "wrong", force new work-arounds on me, and generally suck up all my time learning new rules to follow instead of interesting new ways of thinking about things that make me a better programmer and software designer.

Learning the interesting stuff, and figuring out new approaches to new problems based on the needs of those problems (and not the whims of the community), is a lot of what makes programming fun for many of us.

Linux exhausts me similarly.

* ALSA; esound; PulseAudio; etc. Just give me updated OSS or sndio on a BSD Unix system. That shit is stable, well-maintained, and not arbitrarily different every few years.

* SysV; upstart; systemd; etc. Just give me BSD RC. Maybe it's not ideal, but shit, it isn't swallowing 80% of userland with eventual ambitions of conquering the kernel and some of the worst defaults I've ever seen.

I'll just stop now, but I could go on for days in this vein. Maybe some of these tools are great, but I don't expect any of them to remain ascendant for more than five years in a form that is effectively recognizable by any significant measure but its name. The churn drives me insane. One of the reasons I aimed for software development in my professional life, abandoning the system and network administration (aka "ops") side of thing, was to escape all that crap. I want to write quality code, build new things and improve existing things, not participate in a rat-race to remain relevant just to have acquired nothing enduring from decades of effort other than stock options and a nice car.

From what I've seen, specifically-Ruby jobs tend to pay more than specifically-Python jobs (and more than specifically-Java jobs, for that matter), and while Rails and Django seem kinda balanced in some areas, in others Rails beats the tar out of Django for startup market share.

That doesn't make any sense.

Use the right tool for the job. If "the winner" was all that mattered, we'd all be using Java now, and it would remain the top language forever, as long as it makes any sense at all to use -- not even requiring it to make more sense than other options.

C++ introduces a shit-ton of stuff that one often doesn't want, and even Bjarne Stroustrup (who many content has never seen a language feature he didn't want) has been a little alarmed at the sheer mass of cruft being crammed into recent updates to the standard. I know many C++ people think C++ is pure improvement over C in all contexts and manners, but it's not. It's different, and there are features implemented in C++ and not in C that could be added to C without damaging C's particular areas of greatest value, and many other features in C++ that would be pretty bad for some of C's most important use cases.

C shouldn't turn into C++, or even C++ Lite™, but it shouldn't remain strictly unchanging for all eternity, either. It should just always strive to be a better C, conservatively, because its niche is one where conservative advancement is important.

Some way to adopt programming practices that guaranteee consistent management of array and pointer length -- not just write code to check it, but actually guarantee it -- would, I think, perfectly fit the needs of conservative advancement suitable to C's most important niche(s). It may not take the form of a Rust-like "fat pointer". It may just be the ability to tell the compiler to enforce a particular constraint for relationships between specific struct fields/members (as someone else in this discussion suggested), in a backward-compatible manner such that the exact same code would compile in an older-standard compiler -- a very conservative approach that should, in fact, solve the problem as well as "fat pointers".

There are ways to get the actually important upgrades without recreating C++.

These are all good points, and I don't see a legitimate, technical reason to avoid deprecating and eliminating identifier list syntax in new C standards (but then, I'm not as much of an expert as some people, so I might be missing something important).

That having been said, a compiler vendor has, almost by definition as its first priority, an undeniable interest in keeping customers happy while, at the same time, ensuring strong reasons to see value in a version upgrade. When dealing with corporate enterprise customers, that often means offering new features without deprecating old features, because the customers want the new features but don't want to have to rewrite anything just because of a compiler upgrade.

They'll want C17 (and C32, for that matter) hot new features, but they will not want to pay a developer to "rewrite code that already works" (in the view of middle managers).

That's why I think they'd most likely complain. Their concerns about removing identifier lists likely have nothing at all to do with good technical sense. Ideally, if you don't want to rewrite your rickety old bit-rotting shit code, you should just continue compiling it with an old compiler, and if you want new language features you should use them in new language standard code, period, but business (for pathological, perhaps, but not really upstream-curable reasons) doesn't generally work that way.

This seems like a poor way to establish criteria for standardization. It essentially encourages non-standard practice and discourages portable code by saying that to improve the language standard we have to have mutually incompatible implementations.

It has been said that design patterns (not just in the GOF sense of the term) are language design smells, implying that when very common patterns emerge it is a de facto popular-uprising call for reform. That, to me, is a more ideal criterion for updating a language standard, but practiced conservatively to avoid too much movement too fast or too much language growth.

On the other hand, I think you might be close to what they meant by "existing practice". I'm just disappointed to find that seems like the probable case (though I think it might also include some convergent evolutionary library innovations by OS devs as well as language features by compiler devs).