phaedrus

If the ASCII text format had included the color byte next to every letter-byte, we might have had manually colored programming languages (i.e. it would be a kind of code comment). Imagine, coding guidelines that include coloration requirements...

(I usually use this observation from the other side, as a reductio ad absurdum about coding guidelines that could as well be implemented as editor settings.)

I'm undiagnosed but personally I suspect I am autistic. I have hyperphantasia + eidetic memory, but I have periods of my life (years) with almost no autobiographical memory. The tape is blank or the index has been lost, or I was just too lost in thought to lay down any record what was going on around me. Mostly before the age of 12; I can access only a few disconnected moments out of time.

I was moved to tears when I used Google Street View to explore streets of a city that I know factually my father and I had walked through extensively, but I couldn't recognize a single thing or feel any personal familiarity with it. It's hard to explain why that upset me so much.

I would self-report as having hyperphantasia, but I also have face blindness. I looked up the vividness of visual imagery questionnaire (VVIQ) test, and the first few questions involved picturing a person - starting with the head and shoulders! Well fuck me. That part in my mind's eye is somewhere between blurry and Picasso. (The features don't hold still.)

This is especially well illustrated by the << operator for ostreams in C++.

I have a Bulbdial clock sitting on the mantel. I bought the kit around when they first came out but only got around to building it a few years ago. Recently when my niece stayed over, she slept in the living room, and she asked for "a nightlight". I turned up the brightness setting to provide a multicolored glow.

The last time this came up on HN, someone pointed out something that's stuck with me: the Internet and indie web pages didn't go away, we (the users) did.

The blog post would be a better link for this submission. https://sohl-dickstein.github.io/2024/02/12/fractal.html

So then I am not wrong that I do all my git commit messages via the "-m" commandline option with a short phrase like "frob the baz"?

(Initially I started using -m to avoid getting trapped in Vim. But even after I gained the option to use e.g. Notepad++ as the editor, I never saw the point in using anything more than "-m 'message'".)

As someone who has built a few hobby speaker cabinets, you absolutely CAN make durable and high quality objects for the home out of MDF. Or even particle board. So I think using taxes to try to discourage the use of certain materials in favor of others is misguided and only likely to lead to manufacturers doing different but worse underhanded cost cutting.

The problem is not the material per se but using inappropriate fastening methods for the type of material and/or a design that stresses the material in a modality where it is weak rather than where it is strong. An example of an inappropriate fastening method would be a screw into the edge of a laminated panel and the joint not glued.

For an example on the done-right side, if you look at any knockdown speaker cabinet kit from e.g. Parts Express, the MDF parts will have bracing and grooves where the user is meant to use wood glue, and screws mainly just to hold it together until the glue sets.

https://www.parts-express.com/Knock-Down-MDF-4-ft-Subwoofer-...

In furniture an example of using MDF in a way that almost has to be intentionally bad design: I have a tall chest of bedroom drawers where the drawer slides are suspended 2.5" off the internal walls by horizontal rectangular blocks of MDF. The blocks are oriented in a way that gravity and the torque on the block causes the layers of the MDF to de-laminate. (Picture riffle shuffling a deck of cards.) The resulting sag in turn makes the drawer slides no longer align.

https://en.wikipedia.org/wiki/Shuffling#/media/File:Riffle_s...

Almost anything else could have been done to make this design better. They could have rotated the grain direction of the MDF blocks 90 degrees. They could have oriented the blocks vertically in the long direction. They could have used 2x3 lumber (vertical or horizontal) instead of MDF. They could have actually made the sides as thick as the facade pretends they are. (The sides are hollow.) They could have brought the sides in to where the drawer slides actually are. Etc. etc.

Some of those things would have cost more or made the (lying) appearance of the furniture less substantial looking. But some of these solutions use the same (MDF) material and same or similar amounts, just different orientation. Either the person who designed it was an absolute dumbass, or it was deliberately made in a way that would fail after more than 90 days but less than 2 years.

Mandating different materials doesn't protect against stupidity or malice.

I have a German-made coffee grinder that was between $200 - $300 retail (though I got it for significantly less on clearance. It grinds well, but within a short time of getting it the electronics burned out. I opened it up to find a bafflingly complex circuit board with relays, opto-isolators, transformer, microchips, fuses, timers, etc. etc. Mind you this board has only one function: to turn an AC motor on and off.

I noticed the motor is a brushed "universal" motor like you'd find in a vacuum cleaner; that is, old technology that can run on DC or AC and needs only two wires to run. This complex circuit board... wasn't even justified for being a motor controller, because there was nothing to control! I replaced the entire burnt out circuit board with a hefty 20A 120-240 VAC momentary switch from my parts bin.

Since then the grinder's been working perfectly for about 14 years. But if I hadn't been willing and able to do that repair I might have gone through 10 of them in the same time. Part of making a quality product is restraint: to NOT put something on it (like that circuit board) that is unnecessary.

The article is glaringly wrong on one point: Diablo 2 is not 2D; it's natively 3D! The entire (visible) playfield is a triangle mesh. Interestingly as you walk in the game you don't move in relation to the mesh. The textures and vertex heights are modified according to what part of the ground is under the fixed mesh, like dragging a large sheet of clear plastic over a landscape.

There's gradations of poison ivy reactions. I'm so allergic to it that turns into bubbles on bubbles like a cluster of fish eggs. (I don't think I'd want to put hot water on that.)

My late father was so sensitive to poison ivy that it skips the bubble phase and melts the skin and flesh off his body. One time he got poison ivy on his hand, and it resembled the scene from Terminator Genisys when the good T-800, "Pops," holds the T-1000 under the acid shower and lost the flesh covering on its cyborg arm.

The disconnect here is between people who believe there's an inherent wrongness to things being worse than they need just because it's under a rug, versus those who see no problem here if the market doesn't punish it. I realize those in the first camp have the burden of proof to make a cogent argument beyond "this offends me personally," but those in the second camp are arguing from their own conclusion.

Edit: it's like climate change: individual decisions that are all locally justifiable according to some decision framework, but add up to a world which is objectively crappier than a world in which we did collectively behave this way.

One take I have when this topic comes up is that older, more efficient programs and assembly language instructions are the nanotechnology and atomic level of software. We just are making the same progression, backwards, that hardware technology made from bulk materials to computing with the smallest number of individual atoms. So when you see a 500 MB app doing the same thing that used to be done with 50 MB, 5 MB, or 500 KB it's kind of like looking at a 10 micrometer process CPU from the 1970s and marveling how much atoms it wastes to make a single gate when we could do the same thing with just a few atoms or fit many gates into the same footprint with 2020's era tens of nanometer processes.

Of course "progressing in reverse" is the same thing as saying we're regressing.

It's not just an aesthetic choice. You have people not understanding the layers below on a technical level. It's partly a lack of talent, partly a lack of willingness to make the effort, and in large part just a lack of visibility into anything 2 or more layers down.

The comment I wrote at a higher level in this same thread is, ultimately, a criticism of NOT using a statically compiled, statically linked language (because a form of tree shaking like original commenter suggested is already part of the linking step there, except for DLLs).

And yet, full disclosure and admitting to cognitive dissonance, for a (hobbyist) C++ game engine I'm currently working on that targets Emscripten for a web build and native for Debug build, I'm considering not even having a native-Release build at all.

The idea being if it's web-first and the native build being only for developer use for debugging, I could do things like supporting only one desktop graphics API (e.g. just DirectX) and optimizing the native graphics pipeline for simplicity over performance. End users would/could just use the web version.

Granted this is a bit different because I wouldn't be distributing a browser too a la Electron; it would just use the browser the end user already has. Just thought it's interesting that it's easy for me to criticize others, but with the choice of how to spend my own limited developer time (my free time) it's looking like this way of doing it makes the most sense.

This is an important distinction between statically compiled and interpreted languages which is often lost in discussions that focus on developer usability.

For many years I worked on my own game engine which combined a C++ core with an interpreted scripting language. I had developed a system of language bindings which allowed the interpreted language portion to call functions from C++. The engine quickly grew to a multiple-gigabyte executable (in the debug build), and no matter how much I tried to optimize the size it was still unconscionably huge.

One of the reasons I eventually gave up on the project was I realized I was overlooking a simple mathematical truth. The size was NxM, where N is the number of bindings and M the size of each binding. I was focusing on optimizing M, the size each binding added to the executable, while not just ignoring N but actually increasing it every time I added bindings for a new library I wanted to call from the game engine.

There were diminishing returns to how much I could improve M because I was relying on compiler implementations of certain things I was doing (and I was using then-new next generation C++ features that weren't well optimized); it would be a lot easier to simply reduce N. And the easiest way to do that would be some sort of tree shaking.

Unfortunately due to the nature of interpreted code it isn't known at compile time which things will/will not be ultimately called. That determination is a runtime thing, by calls via function pointer, by interpretation of scripts that start out as strings at compile time (or even strings entered by the user during runtime).

From a compile time perspective, static usage of every bound function, feature or library already exists - it is the C++ side of the cross-language binding. That's enough to convince the linker to keep it and not discard it.

In fact, the mere presence of the bindings caused my game executable to grow more per each included library than would a similar C++ -only, all-statically linked program. If a library provided 5 overloads of a function to do a similar thing with different arguments, an all- C or C++ application that uses only one of them would need only include that version in the compiled executable; the others would be stripped out during the linking step.

Since I don't necessarily know ahead of time which overload(s) I'm going to end up using from the interpreted language side of the engine, I would end up binding all 5. Then my executable grew simply from adding the capability to use the library, whether or not I make use of it, but moreover if I did use it my executable grew even more than an equivalent C/C++ - only user of the library because I also incur costs for all the unused overloads.

You can see why something like Electron would have the same problem. Unused functions can't be automatically stripped out because that information isn't known at compile time. To do it by static analysis the developer of the Electron app would have to re-run the entire build from source process of the Electron executable to combine that with static analysis of the app's Javascript to inform the linker what can be stripped out of the final executable.

And it bears mentioning neither such a static analysis tool for Electron app Javascript nor the compiler/linker integrations for it currently exist. In theory they could exist but would still have trouble with things like eval'd code.

Manual configuration would be possible but necessarily either coarse-grained or too tedious to expect most developers (of Electron itself or users of Electron) to go into that much detail. That is, you may have manual configuration to include or not include Xbox 360 controller, but probably not for "only uses the motion controls" while not including other controller features.

Either way you wouldn't be able to add-back support for it Javascript written after build time turned out to actually need the function or feature after all, unless you distributed a new executable. If you're building so much from source with configuration and static analysis, at that point why not write your whole application in a statically compiled language in the first place?

My thesis here is not that we should accept things like Electron being bloated because they cannot be any other way. My point is (as happens time and again in Computer Science) we had certain things already (like tree shaking and unused symbol stripping during the linking stage of statically compiled languages) and then in the name of "progress" let them either be Jedi-mind-tricked away or the people developing the new thing didn't understand what was being left behind.

And after all that effort, an operator overload is still the "wrong" API for the job anyway, because: it's missing a crucial argument! Any binary (infix) operator can only relate two things, but typically when you want to print something you actually want to relate three things: the stream, the object or value to print, and the way you want values represented.

Oh, sure, you can manipulate this by inserting magic formatting objects, but that's not different from saying all functions take one argument a la Category Theory or Haskell without syntactic sugar. Or you could write a class or function that allows you to tag your object or value by changing its type to a different one so a different operator<< overload is called. In the iostreams design, you're only indirectly selecting which print function to use by manipulating either the stream or the printed object. But in actuality the types of your two arguments are not different, so either you must munge global settings on the stream or "hack" which operator<< overload is selected.

And that's the crux of the issue; what you "really want" is a stream API with three arguments: the stream, the object or value, and a pointer to a function (or function object) that takes the value and transforms it to a stream of characters. Why not just pass that function directly and explicitly? Of course that requires something that's not just a single chained infix operator; my thesis being that starting with that quirky choice leads to down a path that ends in a bad design.

One justification I've seen is that the header defines the interface of a library and allows its implementation to change; the argument reads remarkably like that for pure abstract base classes or what other OOP languages call "interface". The problem, of course, being that C's version of this idea is a bastardized compile-time-only polymorphism.

But from a developer user experience standpoint, what is the difference between having to write things twice for this reason:

// header.h

int foo();

// library.c

int foo() { return 42; }

Versus writing things twice for this reason:

// interface.cs

interface IBar { int foo(); }

// library.cs

class Bar : IBar { int foo() { return 42; } }

Granted in C it was for dumb reasons whereas in a modern language it's for better (?) reasons, but: You're still writing things twice!

Except you can't rely on that. Youtubers can and do update the thumbnail to A/B test which gets more views.

I wonder what would happen if you countered the question with, "what were you paying the last guy?"

During an interview with a startup they asked me about my hobbies and then shut me down with mid-answer with "you're going to need to give them up" because they expect you to give so much of yourself that you wouldn't have time/energy for anything else.

Also the interview was super early, not to accommodate me interviewing off-hours, but because they (interviewers) "weren't allowed" to impinge on work hours to conduct the interviews!

The thing is, the supposed mentorship and office culture that fresh grads and neophyte employees believe they are missing largely never existed even before COVID.

- Companies just aren't interested in training people if they can hire someone trained somewhere else.

- Project-based time accounting doesn't account for time spent mentoring and transferring knowledge.

- Some older workers withhold knowledge and aren't punished for it. Some older workers share knowledge and aren't rewarded for it.

All this existed prior to COVID and expansion of work from home.

Instead of saying "bricked" you could say Voyager 2 is "soft locked".

A feature I've long desired would be to be able to ask what lies between or along the average or sum of the vectors representing two arbitrary songs or bands. For example what music is midway between "Florence and the Machine" and "Primus"? Or, what happens if you take the vector from Green Day to Modest Mouse and extend it - do you land on another (presumably obscure indie) band?

If Spotify won't give me those toys, are such things possible via the API that Spotify has provided?

The YouTube channel Second Thought recently put out a video (https://www.youtube.com/watch?v=3gSzzuY1Yw0) whose thesis was that even being cheaper than fossil fuels is not / will not be enough for green energy to win, because under capitalism a cheap thing that also has low profit margin will not attract investment compared to a bit more expensive thing which can be exploited for more profit. I wonder if a similar effect affects sites like Twitter and Reddit: the more efficient they are at connecting users and providing value for user's efforts, the less room there is for profit margin. As a coworker once pointed out to me, the parameter which represents "profit" in an economic system would correspond to "inefficiency" in an engineering context.

The rural high school I went to had these instead of computers until 1996 or 97.

I didn't know about CastleDB. The fact it uses JSON to store the DB data and schema itself is a nice feature. I've been using Sqlite for a similar purpose to store structured data and load configuration, but the biggest downside is having configuration in a .db file that's a binary blob doesn't play nice with Git or other source control.

I've been working on making a base or skeleton game engine for when I participate in Itch.io game jams that compiles from C++ to web assembly using Emscripten. It's exactly as you say no one wants to download and run an unknown binary blob; this severely limits how many people will try your game.

I'm alternately impressed that I can port C++ in this way at all, and sad at the state of the tooling still after so long. When something goes wrong with the web assembly version of the project, I can't debug it from first principles. This could be because, as an embedded and C++ programmer, I'm unfamiliar with Javascript debugging tools, but it's still unfortunate I can't single step through at the C++ source code level when debugging the web assembly build. I just want gdb for web assembly.

I've also run into silly/stupid bugs like keyboard input not working only in fullscreen, except if you leave it on overnight in which case 1 out of N tries the keyboard input comes back. I spent days trying to debug this, only to have someone on a forum answer it in about 2 seconds that it's because a Firefox change now causes keyboard input to be captured by the awesome bar during fullscreen (which of course you can't see). I could have tried this for a million years to figure out what was wrong and not had that insight. It doesn't bode well for my game engine project if things are this fragile; no other C++ compilation target is this janky.

Richard Hamming's talk, "You and Your Research" is applicable.

https://www.cs.virginia.edu/~robins/YouAndYourResearch.html