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
It doesn’t, and that is parent’s point. The companies it mentions and the “gig economy” it lambasts is largely the result of insane amounts of funding from SoftBank, causing those companies to make profit at any cost.
>SoftBank is Japanese and its Vision Fund is mostly Japanese and Saudi money.
Does that money exist in a vacuum? No, it's invested in American companies, for the most part. SoftBank has set absurd valuations, which other VCs have benefited from.
I wish they had thrown in with helping Firefox instead of handing even more web influence over to Google. A percentage of what Microsoft spent on EdgeHTML contributed to the Firefox project—ideally as employee time—would go a long way, along with the counterbalance of putting the Firefox engine and code base front and center of more Windows users.
Sadly Chromium is WAYYYY easier to development on than Firefox. Had Mozilla spent effort making the base of it as a framework in the same way Chromium is, they may have considered it.
There is a reason why Electron, QT etc use Chromium.
Kind of a shame.. There are a few areas where FireFox absolutely smokes Chrome. The way it reflows some heavy DOMs interactively is almost magical in comparison.
Curious, what makes Chromium better in your opinion? I have probably just touched the surface of the dev tools on both and haven‘t used any features that I would be missing on either.
It's a blank browser, has barely any "Google" specific stuff in it ready to go. It is easy to develop for, doesn't require cross language compiling (rust/c++), builds fast, easy to understand how the different parts work (at least for a browser developer it should be), has documentation, is meant to be used to develop your own browser.
Are you sure Chromium builds fast? lol, it takes my laptop with 12 cores and 64gb of ram over an hour to compile from scratch, not counting the ~20gb of git history to download (I maintain an internal build at work).
Limiting the threads as somebody elses said. For chromium no one really builds it on a laptop, everyone in my team used a build server or a 32 core monster desktop.
They worked on it a bit [0] but it has been abandoned along with all the other embedding efforts over time. As someone who embeds Chromium (via CEF) only because it's easy, I would really appreciate (and have been shouting into the wind about) focus on the embeddability of Gecko.
I suspect that their work in using Electron for things like VSCode made switching Edge over to Blink more enticing. I wonder if they ever considered looking at the Mozilla frameworks
Unfortunately historically there was a history of Mozilla not being a very stable platform to develop on top of (though I have no idea if Chromium was worse). There had been at least two separate embedding APIs that have been abandoned (the original one in the ActiveX control era and the external one after they moved to Hg), at least three Electron-like things (prism, XULRunner, and positron), and the field of corpses of Mozilla-based apps (I've worked for two, there were lots more).
Maybe they're better at API backwards compatibility now? Not sure; I'm unlikely to try again given previous experience. Which is a shame; I still use Firefox since it was called Phoenix…
If anybody has more recent experience working on their stack, I'd be happy to be correctly though. Preferably with examples of projects that _haven't_ been burned.
Cynical thought: in no way am I claiming this was the only reason for Microsoft choosing Blink, but it’s probably easier to find and replace Google analytics APIs with Microsoft endpoints than it is to add them into a code base after the fact.
That's pretty misleading. When you want to sync state across Chromium installs, you use a Google account, and that's really just scratching the surface.
Chromium comes with quite a bit of Google baked-in.
I don't see why they would've done that, given how much it was baked into other stuff behind the scenes throughout the years. Auditing it would be a massive undertaking that I'm not sure even the most well-off organization would like to try.
They probably can't, especially if the engine interfaces with proprietary code or is deeply linked to the kernel for example. It's likely part of the reason why they never got it updating as frequently as the Chromeium counterpart can, as this is entirely userspace.
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...
"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..."
Starting with Office 2016 (maybe 2013) App-V from MS does precisely what you describe and it doesn't require any sort of classic virtualization component to be accessibly by the OS or hardware.
