As Half-Life 2 itself did not have a developer commentary, I personally recommend checking the book "Half-Life 2: Raising the Bar," and, if you really want to do a deep and lengthy dive into the particulars of HL2's level design, check out Robert Yang's commentary-driven playthrough of HL2: https://www.youtube.com/watch?v=VheYcG2T5qw
The Nim language in 2008 (when it was known as Nimrod) had originally been planned a similar approach of considering a unified AST with multiple "syntax skins," and as far as I understand there used to be a limited implementation of this. This would theoretically have been a boon for Nim, because an often complaint about Nim from emigrating programmers from languages with a C-style syntax was the (rather superficial) complaint - "no braces? Pythonic syntax? Yuck!"
The problem with this - and why Nim never really committed to the "syntax skin" concept - is that it would have led to far much fragmentation within Nim's own community as some users would prefer one "sub-language" over another. Given as it is the opinion of new languages (Nim included) towards a tool-based unified syntax formatting (e.g. certain naming conventions for identifiers, number of spaces for indent), "syntax skins" have become harder of a sell in favor of lingual consistency.
The original idea was that the same program could be rendered in a variety of different syntaxes in the author's IDE - but the implied maintenance cost of such skins plus that previously mentioned potential for fragmentation led to this idea falling to the wayside. Nim, as a language, grew to be quite flexible within its prime syntax over the years - e.g. the macro system (which modifies the AST directly) made way for a variety of DSLs (e.g. https://github.com/khchen/wNim#code-examples) that remain valid Nim code.
musl is just another implementation of the true stdlib. I think what they want is an alternative to standard-conforming stdlibs that fills a similar niche - in other words, a "non-standard" standard library.
2001 was a silly time. Obviously, in any domain, there are times when we must judge a book by its cover for sake of there being only so little time in the world; but it seems so bizarre - well, maybe not bizarre for Paul Graham, but whatever - for someone to write this long-winded article talking about why "XYZ technology I've never used sucks." (Of course, Java sucks IMO, but this is a very poor critique)
I find it amusing Paul regards C's origins as being "hacker" and Java being apparently not. How exactly was Java's original design (as Oak) by James Gosling that much different under the circumstances by which C was developed by Dennis Ritchie when Bell had been reworking PDP-11 UNIX?
> Command-line tools should print colorized output.
Just add a "colorless" command line argument if you need to parse things without ASCII color codes. Better yet, detect when the program is outputting to a pipe and disable colorized output, e.g. like Git https://unix.stackexchange.com/a/19320
> They will use lots of math in their career.
The validity of this is highly domain-specific.
> 'git' and 'GitHub' are synonymous.
Aside from GitHub-a-likes (e.g. GitLab, BitBucket), what does this mean? I'm assuming that it's that you can use Git by its original use pattern (i.e. without a "single-source-of-truth-plus-issue-tracker-as-a-service" system and more as a "true" DVCS) but very few projects seem to really use it this way. They're important projects, sure (e.g. Linux) but they are few in number.
> Sprinkling printf statements is an efficient debugging technique.
This is...opinionated. As useful as GDB can be in a pinch I have often preferred to just output things to console. `printf` specifically is a bad example, as C doesn't have reflective abilities (out of the box, anyway), making debug-by-manual-print harder.
> Compiler warnings can be ignored, as they'd be errors otherwise.
I smell a Golang programmer...
> Using lambda in Python is a good idea because it shows others you have a CS degree and understand the "Lambda Calculus".
Kinda rolling my eyes at this one. Yes one can "be annoying" with FP-like concepts but lambdas can be very useful in a pinch.
>Object-oriented programming is the best and most common programming paradigm.
>Using a custom written Vector class makes your program object-oriented.
I feel I should add my personal falsehood: "State objects with methods means your program is object-oriented."
>The ability for an application (eg, Office) to install side-by-side with other versions of itself is entirely different than its Backwards Compatibility (eg: ability for current versions to open and/or save Office 2007 format). In fact, because of the latter, provided they did a good job at it, the former is arguably irrelevant.
I am still somewhat surprised that Windows doesn't have a Docker-esque sandboxing system to solve this problem (I mean, it has Docker, but it's based on a full VM). I suppose in the third-party realm at the very least you have Sandboxie, but meh...
A lot of people view the era from when Steve Jobs up to when he came back as this kind of "malaise era" for Apple, which, granted, was not unearned; nevertheless, there is something very charming about a lot of Apple's products from that era - and this is coming from someone with more personal nostalgia for the Win9x era than anything.
Something about pre-10 Mac OS is "cute." I can't put my finger on one single thing, so I suppose its more of an aggregate property.
They're referring to the font, yes. Lots of people used it in the post-Web 2.0 era because it has a "distinctive" look, which naturally lent itself to fatigue.
I am no apologist for China, but the course of the American Dream itself was similarly colored by a "rose-tinted" view juxtaposed with less-than-ideal circumstances. One could look at for instance its original emergence in the 19th century after being primarily brought on by the 1848 revolutions in Europe, legalized chattel slavery still existed and manifest destiny would turn out spill a lot of blood in its wake, both that of natives, settlers, and soldiers. This, of course, ignores the emancipatory possibility of the American Dream then - for instance, the massive emigration to America and throughout its frontier that occurred in the 19th century provided much of the pretext for the actual dismantling of chattel slavery.
The more modern, post-WWII imago of the American Dream of a booming economy and cute little suburbs was overlaid over antiquated Jim Crow laws and early Cold War saber-rattling that would accelerate into the greater turmoil of the '60s, which would turn out a tragedy more than anything. Many of the criticisms you put on China now have mirrors in a historical America.
China and America are really both flip sides of the same coin. It is true that looking at China as a safe haven when America's economy and culture has become so anxiety-riden is silly and ignorant. China is able to rationalize itself with a liquefied idea "socialism" it never truly was able to understand in the first place, and has grown to content to treat the task of governing its people in similar kind to herding animals.
I would not pin China's blame singularly on the CCP or Xi for that matter, but I would rather describe the CCP a symptom of modern capitalism. If one were to hypothetically "clean the CCP's house" with a new stock of younger legislators that weren't "beneficiaries of the Mao era" as you claim, than you would likely find them repeating the same regressions as their predecessors; never mind that Xi himself was a victim of the Cultural Revolution, considering that his sister was killed by student protesters and his father was jailed for 10 years. China's problems (more problems of contemporary society in general) extend beyond the Mao legacy, similar to how Leon Trotsky did not regard Stalinism in the Soviet Union as purely beginning and ending with the one man.
Are you advocating for implementing langauges in an AST-less way or are you working towards maturing your language? You don't sound diametrically opposed to ASTs (which are evident in essentially any modern language), so I have to ask why V was not originally implemented with one and why you don't consider it a more important problem.
Using codegen to handle the JSON stuff is clever, sure, but it certainly makes me uneasy! It gives a very Jenga Tower impression of the state of the project...
Claims to "being able to now compile itself in 0.09 seconds" whilst pushing the need for an AST to the side represents a serious problem in the language's general direction (and I mean general in an aggregated way). Of course shelling-out to curl for your download function is a bodge to be fixed, but the language's issues are not merely one specific problem. The author's misrepresentation of the language, of course, hangs overhead upon all of this.
I don't want to discount all of the work people have put into V. It is clear that they have made considerable progress since earlier this year and I commend them for pushing the language into a more usable state. Nevertheless, I still retain a considerable degree of skepticism.
I don't really get what point you're trying to make here. Yes, people should not be mean-spirited, but the opposite (i.e. the internet should be a hugbox) is just contrarian; and, for the record, I don't think the article is very mean-spirited at all when you take in consideration what percisely it was responding to.
A lot of the criticism of V takes aim at how the language was advertised which strikes a lot of people as rightfully annoying in the "C++ killer" space, something that a lot of people have put a lot of hard work already into which should not be entirely out of hand (this space is becoming very crowded for attention). If V's code remained the same at launch with its author choosing to be a little more conservative and thoughtful with its announcement, this type of response would not have happened. Its author did not make the status of the language entirely clear. When Odin came out a year ago, Lobster half a year ago, Zig three years ago, or Mun a month ago (of whom its authors were considerably modest: see https://news.ycombinator.com/item?id=21173822), sure, they were critiqued, but they were not met with the specific kind of response V had for a reason.
Keep in mind languages (that don't aim to be toys) should rightfully be subject to a greater degree of criticism as their goals are primarily to upend a domain in such a way that if they fail, it renders the efforts of a lot of other people writing code in that language as something for naught. People take gambles when they adopt new technologies in general, but languages (maybe operating systems by extension) are of a significantly different scope.