Early vs. Beginning Coders

I cannot agree with this more. A lot of people seem to think that a "better" language to learn programming with is one that is "easier" or "more forgiving", but everyone I know who started with C became excellent programmers whereas ability among the group who started with something else is somewhat more hit or miss.

Later, I tried using high values for line numbers just for the heck of it. Can I make a BASIC program that begins at line 100,000 instead of 10? By binary search (of course, not knowing such a word) I found that the highest line number I could use was 65,000 + something. I developed the misconception that this must somehow be because the computer has 64 kilobytes of memory.

Event-based programming was not discovered by Node. It was the dominant paradigm for decades, plural, on the desktop, and still is how all GUIs work, on all platforms, current and past. I've got a big blog post on deck about this one, actually, so I'll save the well-known pitfalls for that.

All of the async stuff that they've come up with has been tried before, and none of it is a miracle cure, though some of them are certainly better than callback hell. Still, many of them still have well-known problems with composability and program flow comprehension. This has been a rich source of people overestimating how green the grass is on the other side; for instance, Python has everything ES6 is going to have anytime soon, and it's still fairly klunky in many of these cases, IMHO. Not to mention the fact I've been outright stunned to see people in 2015 rehashing claims that cooperative multitasking is superior to preemptive multitasking because it gives you "more control" over the performance, which is roughly up there with seeing someone actively advocate for spaghetti programming because it gives you "more control".

Reactive programming dates back to Visicalc (note the fourth paragraph of the wiki page cites spreadsheets as an example); it has well-known problems with cyclic dependencies, which are shockingly easy to accidentally introduce. It strikes me as likely that the nature of web pages will tend to contain this problem, unless you're literally building a spreadsheet; this strikes me as one of the better tech fits. (The more you partition your problems structurally with "pages" and discrete "submissions" to the server, the less likely you are to spaghetti tangle your data flows accidentally, the way a single-spreadsheet application can so easily. The structure induced by the web is in this case harnessed to your advantage.) I wouldn't try to build a game with reactive programming, though.

The idea of using "binding" in your UI, as in Angular, was actually tried by multiple GUI technologies, and generally was hard to work with at scale (made easy things easy and medium things very hard). I'm pretty sure Microsoft had it at least twice on the desktop and once in ASP.Net; none of them stuck. The same effect may save you here, though... GUIs are generally in "pages" as well. Less sure about that. Adding binding to a pre-existing language can also cause inner platform effect, where you have to embed a full language for expressions inside the original programming language: [1] But this is one of those cases where advances may make something more practical than it used to be... dynamic scripting languages require a lot less work to make that work than the olden days, where the fact you were literally writing a new inner language really sucked (i.e., lots of new bugs the outer language didn't have).

Going to a bit of a wider range, NoSQL databases preceded SQL databases, which are called SQL databases precisely because there were databases, then there were SQL databases. Non-SQL databases had problems with being non-standard and causing your application to be too intimately tied to one of the very pieces of the tech stack most likely to fail one of your requirements and need replacing. That said, I will also point out that SQL databases really were in some sense too successful, and they should never have been the "only" choice. (But too many underinformed people still read too much hype and flee SQL databases when they really shouldn't.)

And I'll end my message with a clear restatement of my point, so it's both the beginning and the end: The point is very much NOT that any of these things are "bad" or "failed"... the point is that they are not new, and it would be advantageous to look back at our historical experiences with the tech where possible to learn what the pitfalls are. This is something that both the people writing the techs ought to be doing, and even if they do, the people using the techs really ought to as well, especially when it comes time to decide which tech to use.

[1]: https://docs.angularjs.org/guide/expression

For example, I know exactly how garbage collection works.. since I once had to write a GC for a project. So when I use a higher lang, that part isn't magic... it's just something someone else already wrote for me.

Whereas, if you started with a higher level lang, you could get by without ever learning how a GC works. Yes, you could dive into the details of your language, but there's no requirement for you to do it.

And I think that explains what you've noticed... it's hit or miss because those who chose to dive into the details of their lang eventually became excellent developers...

The hacker tradition is revered in large part because it seems to be so egalitarian. We all came from humble beginnings. Anyone who can grasp enough of the mathematics of the stuff can make the gizmo do something magical.

It's a common to be self deprecating about our former ignorant selves, and maybe some people find it encouraging to hear something like "don't worry, I was once a noob myself." But really, the word emphasizes the moments where you felt like an idiot. That doesn't help a beginner.

https://en.wikipedia.org/wiki/Shoshin