I think it’s useful to coin pithy terms for phenomena that all software engineers experience but don’t have a name to put to. Our term of the day is “finger trap”.
A finger trap is a programming problem that is conceptually very simple to state, and algorithmically fairly trivial, but an unreasonable pain in the ass to actually code given that simplicity.
It’s named after a gag called the Chinese Finger Trap, simple, deceptive, and the harder you struggle with it the more trouble you have extricating yourself.
My favorite very simple example of a finger trap is interpreting C backslash escapes. The trap closes when you realize you have to interpret \\, \\\, \\\\, and so forth.
A very famous finger trap is BitBlt – copy a source rectangle of pixels to a target location. The tricky part comes from the background having edges; you may have to clip the copy region to avoid trying to copy pixels that are off the edge of the world, and then modify the copy so you only copy to locations in the world.
These two examples exemplify what I think is the most common kind of fingertrappage: when it’s easy to miss edge cases, and as you get deeper in the edge cases proliferate. In the case of BitBLT these are both figurative and literal edge cases!
When I bounced this term off some friends I learned that Amazon uses finger traps to screen potential developer hires. A finger trap, you see, is a test both of coding skill and personality. How good are you at anticipating edge cases? How do you react when you discover there are edge cases you didn’t expect?
Do you plow on stolidly, spot-gluing a series of increasingly dubious kludges to your original naive approach? Do you panic and recover only with difficulty, if at all? Or do you step back and rethink the problem, sitting on your coding fingers until you have mapped out the edge cases in your head to at least one level deeper than before?
A Chinese finger trap gets its grip on people because, having gotten themselves in a little bit of trouble, they do an instinctive but wrong thing, and then repeat the failing behavior as though doing it harder will get them out of trouble.
Software finger traps catch developers in a very similar way. To get out of one, relax, rethink, and reframe.
The good news, if you’re a junior or intermediate-level developer, is that once you’ve seen enough finger traps you’ll start to be able to detect them before they close on you. In which case you can move straight to the winning part of the game, which is developing a clear mental model of the edge cases before you write more code.
You will not always succeed at this the first time. Serious finger traps have multiple layers, and spiky bits where you’re least expecting them. The point is, when you hit a finger trap, you have to relax and think your way out. Trying to code your way out will only get you more stuck.
My commenters are invited to suggest other examples of finger traps.
I’ll bite. What finger trap did you get your fingers trapped in?
>I’ll bite. What finger trap did you get your fingers trapped in?
Wasn’t me this time. Yesterday my apprentice discovered strconv.Unquote() in the Go standard library. I remarked that I had written roughly equivalent code in C several times and doing so is a royal pain despite how simple it is to specify. A friend who works at Amazon chimed in with the observation that they use problems like that as screening devices, and the post was born.
It is worth noting that I went looking for Unquote because I was in the process of watching what should have been a small handler balloon into a looping mess. It seemed like a function that ought to be in the libraries.
Getting escape sequences right imports one of the major problems with parsing badly designed bit protocols: if you start anywhere but the very beginning you will emit garbage. And how do you know that you have properly started from the beginning…..?
An obvious but bad move, made without thinking? Fingerfehler
Finger trap: a CD/DVD caddy closing before you have time to remove your fingers from the CD/DVD you just inserted.
FD
Where a response to kafka-trapping, etc, is deemed unacceptable. (Middle-) finger trap.
Implementing a caching subsystem. I might have actually lost a finger once.
>Implementing a caching subsystem. I might have actually lost a finger once
Oh yeah. Especially getting right when you have to invalidate/refresh the cache. Often a finger trap.
Parsing a bit of code (C, SQL, whatever) with quotes and comments.
You can’t handle the quotes first, because some of the quotes could be in comments (where they don’t really count). And you can’t handle the comments first, because some of the comment start/end markers could be in quotes (where they don’t really count).
The ONLY way to do it is to make one pass that handles both quotes and comments at the same time.
Or, use the formal grammar to generate your parser, or at least to tell you how it should work.
Regexp are often involved in finger traps. (They don’t cause finger traps, but they often feature in them.)
Part of my day job involves antispam – and there are a LOT of places to catch my fingers in that.
You’d think instant messaging would be a reasonably easy exercise in taking input text and sending it to a remote address, but…
You’d think encoding Unicode without blowing up file sizes or bandwidth would be reasonably easy, but…
You’d think it’s reasonably easy to implement cascading window displays with convenient keyboard shortcuts for min- and max-sizing, and flushing them against one of the screen edges, but…
Hypothesis: any coding problem for which the phrase “reasonably easy” appears to apply is a finger trap.
>You’d think instant messaging would be a reasonably easy exercise in taking input text and sending it to a remote address, but…
I get why your other two examples are finger traps. Why this one?
Admittedly, I’ve not coded it myself – I’ve just looked at the other apps that exist, observing their vast multitudes and feature sets, and extrapolated. Edge cases, AFAICT:
* guaranteeing delivery
** guaranteeing delivery only once
** collapsing multiple copies, in case that happens
** guaranteeing delivery if the recipient’s app is different from yours
* alerting the recipient in case it’s important
** NOT alerting the recipient in case it would be disruptive
** alerting the recipient quietly in case they still want to know
** NOT alerting the recipient if it’s a long exchange and you don’t want them to feel spammed
* permitting multiple recipients
** over a period of days
** with adding and removing of recipients
** managing who’s permitted to alter the list
* permitting multimedia delivery
** permitting continual streaming
Maybe you want finger problems to mean something more precise, but FWIW, I’ve seen how the initially simple job of sending someone texts in real time managed to blow up into a nontrivial problem.
Pondering it for a moment, I can see someone making the case that instant messaging is more of a Christmas tree problem than a finger trap. To me, the salient problem is that all the extra ornaments end up affecting how the base case should have been implemented.
>Maybe you want finger problems to mean something more precise, but FWIW, I’ve seen how the initially simple job of sending someone texts in real time managed to blow up into a nontrivial problem.
This certainly shares the trait of finger traps that most of the pain comes not from algorithmic complexity but from it being proliferating edge cases all the way down.
It’s unlike what I think of as a finger trap in that you can’t think through all the edge cases from first principles. You have to collect a lot of information about user preferences and use patterns before you even know what the right thing is.
I think that takes it out of the finger-trap category.
Moreso because user preferences may actually conflict, so it may not be possible to put together a consistent specification without ignoring the pitiful cries from some section of your userbase or other. It’s a social problem, not a programming problem: I don’t have a problem with multiple delivery, but Aunt Tilly will. Aunt Tilly won’t mind GTK3, but I’m hoping for somebody to hostile-fork GTK and give us GTK2+i. Aunt Tilly won’t mind systemd, I really want to lobby JWZ to repackage /bin/mail as a systemd component, submit it to the systemd project as systemd-maild and declare the systemd project forever finished.
Why does Gnome get to take over the GIMP tool kit?
Because everyone more sensible seems to have abdicated?
They abandoned it because it was a finished work.
> You have to collect a lot of information about user preferences and use patterns before you even know what the right thing is.
Hence the maxim: “Plan to throw one away.” Don’t get too attached to the clever approach you came up with before you fully understood the situation.
In my world, a lot of that comes down to a variant on von Moltke: “No design survives contact with the users.”
Any time you’re trying to do math with a calendar. For instance, writing “recurring every month” into code is a fingertrap, and there’s plenty more.
Correctly handling multiple levels of encoding is at least arguably one (e.g., an HTML string embedded in Javascript embedded in a HTML attribute embedded in a programming language’s string). If you really know what you’re doing, it’s not really that hard, but I’ve seen a lot of broken fingers around this area.
Grammars for non-trivial languages get fairly subtle, even when you use the right tools for the job. Someone who doesn’t know the right tools and just starts banging away with “string” functions is doomed. (Many who do know the right tools write their own parsers from scratch, but this is definitely a case of needing to understand the rules before you can break them.) But in principle, the underlying math is very simple.
Going to agree with you about elementary calendar stuff. Your other examples have high enough intrinsic algorithmic complexity that I don’t think they really belong in the finger-trap category. Even some calendar computations bust that barrier.
Maybe I didn’t emphasize simplicity of the underlying algorithm enough.
Maybe specifying what a finger trap is, is a finger trap.
:-D
I solve calendar finger traps and make them fairly simple with a good julian date routine. Once that was debugged, calendar code was fairly simple. Having solid code let me find a couple bugs on the NASA website, probably a junior coder.
>probably a junior coder.
Even a senior coder is a janitor today. Including in salary. You guys didn’t turn out to be as clever as you imagined yourselves to be: which is extremely shameful. Janitors are respected more than you.
The only way your insult works is if you believe that janitors belong at the bottom of the barrel.
Why do you have such disdain for janitors? They do an important job. I am very grateful for their hard work.
Grow up.
Frankly, anyone willing to clean a public restroom on a regular basis deserves a beyond-middle-class salary. Even at places with a restricted set of fairly well behaved users, things can get nasty. The circular error probable demonstrated in men’s rooms open to the general public is worse than the military achieves with artillery fire.
I solve calendar math problems by outsourcing them to GNU date and letting it do the work for me. I learned that lesson trying to implement “how many days in a month” logic myself, and realizing the date maintainers had already done this work, so I don’t have to.
I think part of the issue here is *hidden* algorithmic complexity, where something that appears to be a primitive in fact has to be defined quite intricately.
>Any time you’re trying to do math with a calendar. For instance, writing “recurring every month” into code is a fingertrap, and there’s plenty more.
These things depend on the level of abstraction. There are all kinds of frameworks or libraries for things like this, this is a problem only if you are working on the basic standard library / OS API kind of level.
Which cashes out to the kind of problem that there are at least three subsets of programming that people are often not aware of because their own subset looks like the whole of programming to them. This is why I stopped reading programming blogs because people come up with something that works in their world, say, they say unit tests rock, and they don’t realize how it looks in other worlds, like, those worlds where you cannot possibly unit test because every piece of code has potentially anything from a 20GB SQL database as its potential “inputs”.
One subset, that used to be the “standard” subset, mostly still so for older people, is what I would call technical programming. This is the kind of programming that is relatively close to the hardware, requires a good understanding of the underlying technology. It is in these fields where people tend to work on the OS API or standard library level, in these fields are such things a problem, also ESR’s examples are from this field.
Then there is the subset academia considers the “standard” subset, Computer Science / Mathy wizardry, like what Haskell folks like to do. It requires are strong understanding of the underlying theory, and generally it is highly abstracted away from the underlying technology. It is executable math, and these people rarely care about technology.
Then there is subset the “startup culture” considers the “standard” subset, which is mostly web development. Since these guys blog a lot, easily become Silicon Valley superstars, and can be bought out for like $800M (YouTube), this subset is fairly loud and noticeable. Examples are typical model-view-controller stacks, LAMP and similar stacks. This is a fairly narrow world but because lucrative, people in tend to think it is just what programming is because all the cool kids in Frisco are doing this.
Then there is a subset which I would call domain programming, where you are are playing within a fairly narrow framework, actually more like scripting than programming, and the programming task is in itself easy, it is understanding the use case, the problem domain that matters. Examples could be medical systems, business/accounting software, but the cleanest example is videogames. A videogame developer might spend years inside the scripting environment of Unity never taking a step outside, or some other high-level, abstracted away framework. Such a developer will be typically a mediocre developer but a good domain expert. I.e. he knows what makes a videogame cool, he less good in coding, but that is okay because the environment is easy enough. In such cases, either the framework provides e.g. date math functions or if the developer knows his limits, he won’t even try.
Well, sure, but all problems are simple if you can just call solveTheProblem(). (Which is why the ever-popular “Make A Blog/Todo List/CRM/Operating System In Three Lines Of This Trendy New Language” posts are almost always a waste of time.)
I learned a related idea at an early age: “if it seems hard, you’re probably doing it wrong.” It has some overlap with Finger Trap but maybe more broad.
I heard it mostly applied to mathematics (there’s more than one way to do many things, and part of doing the math is choosing the easiest approach that still produces the correct result) and mechanical engineering (there’s often a better tool for what you want to do than the one you’re using to do it now) but it works in software as well. Software is simultaneously mathematics, tool-building, and tool-using, so the idea applies three times over.
The idea is that if you’re running into a lot of problems during implementation or testing, go back to an earlier step–design, requirements, architecture, tooling, dependencies, research, all the way back to the very purpose of the thing you’re building if necessary–and make sure that you’re not wasting effort deriving a garbage output from garbage input(s). Mistakes happen everywhere in the development process, so you should not assume defects appear only in the most recent stages. That assumption is the trap.
Also, if you’re not working on the leading edge of CS research, there’s a good chance that the problem you’re chasing isn’t novel, and you should consider seeing if someone else solved it before you did. If their solution was different, that’s a good sign that one of you is wrong about something, and all you have to do is figure out if that one is you.
>and mechanical engineering (there’s often a better tool for what you want to do than the one you’re using to do it now)
Seriously I could make a living out having 100 programmer clients, who would each tell me what are they going to build next week, and I would with five minutes of googling find them an open source library/framework that is already out there and does just that. And charge them $25.
The point is, this sort of blindness, just not stopping to think “maybe someone already solved this” is so extremely common. I think it is just because programmers like to program. It is one of the few jobs that is capable of awaking passion, at least in the right kinds of people. They like to program, they see an interesting problem, so they want to solve that. If they know it is already solved they could not justify spending the time/money on it, so they simply don’t look.
While I agree that there’s no point in rolling your own if there is already something out there that is open source and does the job, that involves more than just the open source library/framework being there and findable with a Google search. Is the library maintained? Are the maintainers responsive to issues? Is the library’s license compatible with what you are doing? And so on.
External dependencies are often necessary, but they are a risk, and the risk should be evaluated before taking them on.
One of my friends has a hard and fast rule about every executable he writes. That is that he puts most of the logic into a library, and lets the executable per se only concern itself with details of parsing command lines and prettying-up the output, leaving the library to do most of the work. This way, the library can be re-used in other projects. And even if it can’t, the discipline of separating the logic out this way makes for better code.
I do believe I’ll be buying your friend a beer
> think it is just because programmers like to program.
That, and you can’t charge someone $200/hr to write a shell around an open source library.
This reminds me of my motto, “The impossible we do immediately. The difficult takes a little longer”. On the grounds that if it’s impossible, the only way you’re going to do anything with it is if you can spot the change in assumptions that renders it possible (and in the vast majority of cases, trivial). Whereas if it’s merely difficult, you can spend an arbitrarily large amount of time grinding away at it.
That’s the “base version of the General Technic’s Motto” from John Brunner’s Stand On Zanzibar.
The “current” version is “The difficult we did yesterday: the impossible we’re doing right now”.
“Hipcrime: you committed one when you opened this book. Keep it up: it’s our only hope.”
No it isn’t. Read it again, slowly ;-)
One of the gnarliest pieces of code I’ve ever written was the part dictating line wrapping in the message buffer in the nethack4 fork project a while back. What we wanted was behavior less like:
It hits! –More–
It bites! –More–
The hill orc zaps a curved wand! –More–
The hill orc is suddenly moving faster.
And more like:
It hits! It bites! The hill orc zaps a curved wand! The –More–
hill orc is suddenly moving faster.
With the behavior adapting to different terminal sizes, requiring fewer –More– prompts if the message buffer has more lines available in it, ensuring the player can see every line before it scrolls past, not overwriting the end of any line with a –More–, etc.
My impetus for dealing with it was that ais523 had already tried and only mostly succeeded, after two other people had tried.
I should maybe clarify that mine wasn’t the final implementation; ais523 later went back and redid it again. The patch notes are mildly entertaining (I think I misremembered how many previous attempts there were, though).
>It hits! It bites! The hill orc zaps a curved wand! The –More–
hill orc is suddenly moving faster.
Echoing my comments above about conflicting user preferences (but without the grumpyness I feel about GTK or systemd), I actually like your specified behavior less than the behavior you were trying to improve. Assuming you’re using a one-line message area like most rougelikes I’ve played (and as indicated by the fact that you’re using –more– prompts), the line break after “the” (or in the middle of a message in general) is not the greatest. It would be better to have an integer number of messages per line, except in the case where a single message takes multiple lines. The original behavior fulfilled this, though less efficiently than would be ideal, and I can imagine users that would outright prefer the old behavior.
> I can imagine users that would outright prefer the old behavior.
I think I might be of those.
>It hits! It bites! The hill orc zaps a curved wand!
All at once? Did the hill orc do something earlier to speed itself up? Those are normally three separate events.
Also you don’t get the suspense of having to spacebar three times to figure out if you even survive all of this.
Well, the convention in roguelikes is that “it” is an unseen enemy (in darkness, out of line of sight, magically invisible, or the player has been blinded), and “the foobar” is a visible enemy, so “It hits! It bites!” indicates on or more invisible monsters attacking in melee (can’t be out of LOS because these are melee attacks and roguelikes generally give the player 360° vision, player can’t be blind because the hill orc is visible, and it’s unlikely that the monsters are in darkness because it is unusual, though not impossible, for one or more squares adjacent to the player to be unlit while other squares, adjacent or not, are lit), and “the hill orc zaps a curved wand” indicates a visible monster acting.
I think the ‘Falsehoods Programmers Believe’ lists are a symptom of finger traps: https://github.com/kdeldycke/awesome-falsehood
This seems related to what I call “getting ye flask”. To get ye flask is to solve a problem which should be simple in principle, but actually is fraught with difficulty, if not downright impossible given your current set of assumptions and constraints. Say you want to write a container library in Go. You could implement containers of interface{}s, but the container abstraction breaks down when you realize that objects of any type can be added to such a container, even mixed types. And Go lacks parametric polymorphism utterly, so there’s no way to implement the basic aggregate types used daily by Java and C# programmers in Go. You can’t get ye flask.
Sometimes, ye flask can be gotten by challenging the assumptions and constraints — for example, code generation in the Go example above. But ye have to be careful, lest ye grasp a load-bearing flask!
I think finger traps result more from unconsidered complexity, whereas ye flasks result from wanting to do something and then finding out the system you’re interacting with does not want you to do that thing — or its designers never considered you might need to do that thing and accidentally closed off the possibility. (Correct compositing in X11 is a ye flask that’s only gotten by switching to Wayland.)
The term comes from Strong Bad’s description of text adventures in this Homestar Runner cartoon.
“…it’s bolted to the table which is bolted to the floor which is bolted to the rest of the dungeon.”
>(Correct compositing in X11 is a ye flask that’s only gotten by switching to Wayland.)
I gather that there are also issues in the design of the extant graphics APIs that cause trouble here: Basically, the assumption that there is one program that is using accelerated graphics at a time, and that it owns the GPU completely, which breaks down when youhave a compositor and a game running simultaneously.
In any case, the stability of compositing on NVidia hardware under X seems to have improved considerably in the time since I switched to Linux, and it was at least usable when I started. ATI hardware is as bad as it was when I started (but then, it tends to choke on OpenGL even on Windows). OTOH, I understand some of the improvement with NVidia is that their binary drivers reimplement large parts of the X Server, or something similarly black magicky.
Basically, the assumption that there is one program that is using accelerated graphics at a time, and that it owns the GPU completely, which breaks down when youhave a compositor and a game running simultaneously.
This isn’t even a stupid assumption; GPUs with the capability of interlacing draw calls between multiple processes are a relatively recent development (say, ~15-20 or so years, at least at the consumer level). It used to be you actually couldn’t have multiple processes doing OpenGL/D3D on the same GPU simultaneously.
I think we should expand the date finger trap to include dates, times, and timezones. Good lord, how much historical time has been spent trying to work around those topics? Especially when time changes twice a year. Databases don’t sleep during those times, and I’ve seen some weird situations that are difficult to foresee. Timezones in general are a fingertrap. So seemingly simple, and yet…
Obligatory link: https://youtu.be/-5wpm-gesOY
>Obligatory link: https://youtu.be/-5wpm-gesOY
*wince* For my sins, I’m an expert on this.
This is not a finger trap. Oh, no indeedy it is not. It is a case of the application domain being messy and horrible, often leading to bad API designs that never quite get fixed. “Toxic swamp” would be a better description.
The Golang guys nuked the entire C time/calendar API and built a better one from scratch. It was the right call.
Why don’t you like C?
>Why don’t you like C?
What motivated that question?
He didn’t say he didn’t like C, he said he didn’t like the C timekeeping API.
That’s similar to when RMS recently did a 180 on pedophillia, and absolutely hates pedophiles now. ESR now is opposed to C, even said he wouldn’t start a project in C anymore and would instead use trash like Python.
>ESR now is opposed to C, even said he wouldn’t start a project in C anymore and would instead use trash like Python.
You appear to have some comprehension problems.
It is nowadays true that I would be reluctant to start a new project in C, but it’s not because I’m “opposed” to C. I’ve been writing C code for 35 years; not only am I a master-level programmer in it, I have written some of the explanations other people read to become masters themselves. Nothing as simple as “opposition” is going to come out of that kind of experience.
No, what is true is that experience has given me a sense for where the cost/risk tradeoffs favor C, and that domain has been shrinking as the price of machine cycles and storage has dropped.
It also is not true that Python is C’s principal competition in my universe. I like it for scripting, but for the kind of heavy lifting I used to do exclusively in C I nowadays choose Go.
You have, sadly, effectively stepped away from C, a constructive eviction of it (if you will). You should not waste machine cycles: “we” aren’t getting more of them for single threaded problems anymore (which are most of the problems). We have hit the brick wall.
Could you please come back to C? Please. Cycles shouldn’t be wasted and there are C libraries for everything that are fast and efficient.
RMS reversed his stances on longstanding opinions of his. This is celebrated by many, (and lamented by a few sick insane males who wish Japan had won.)
But you turning your back on C is one treason too far. Please reconsider.
We all beg you. Come back.
>You should not waste machine cycles:
I shouldn’t waste my time, either, and coding in a language that forces me to do lots of low-level resource management wastes my time unless it’s in one of the increasingly unusual cases where doing otherwise runs me into a hard resource limit. Usually my time is a lot more limited than the amount of machine cycles I can spend.
And then there’s downstream defect rates. Downstream defects are very, very costly, and C is quite hazardous that way for reasons I shouldn’t have to rehearse.
You want me to come back to C for new projects? Interest me in a problem for which C’s combination of capability and risk is the best fit. Those are increasingly uncommon.
How about loyalty to that which was loyal to you? Casting aside C is like casting aside software engineering itself. A man strives to make the most efficient and effective use of his tools, to hone his skill and his craft. A consumer cares about making the most of his time. The craftsman accepts that his craft is his life. Are you a craftsman, a wizard, or a consumer of new fads? Single threaded performance has his a hard brick wall. This will never change. Ever.
>Casting aside C is like casting aside software engineering itself.
You are becoming increasingly silly.
A wise engineer chooses the right tool for the job. You use a wrench where a wrench is needed and a screwdriver where a screwdriver is needed. If I’ve noticed that more of my jobs need screwdrivers than wrenches these days, it’s silly to say “Abandoning the wrench is abandoning engineering itself!”
Show me a job for which C is the right tool and I’ll use it. I’ll use it quite effectively, thank you. But there was software engineering before C ate the world (I was there for some of that) and there will still be software engineering in the distant future when C has entirely passed from use.
Get some perspective, man. It’s a tool. It doesn’t have loyalties. Yeah, makers get fond of their tools; it is bittersweet, for me, watching the long slow fade of a language I’ve been so heavily involved with for so long – and still am on existing projects.
But ultimately your craft is about the work you do, the value you produce, not the tool you use to do it with.
>Single threaded performance has his a hard brick wall.
I should note that the correct response to this is not to fetishize C, it’s to build and deploy a language that is better than C is at C’s job.
Not a theoretical possibility anymore. The Rust people are trying. I’m by no means certain they will succeed, but if it’s not them it will be something else. Eventually.
>Not a theoretical possibility anymore. The Rust people are trying. I’m by no means certain they will succeed, but if it’s not them it will be something else. Eventually.
They will not succeed. There are many.. let’s be honest: Most problems are not parallelizeable, and usually even if they are, the overhead to parallelization give you Zero net benefit in the end.
And abandoning the wrench is abandoning engineering itself. If you’re working only with a screwdriver you’re just doing maintenance, not prototyping.
Are your best days behind you? Come back to us ESR. Come back. People say you’re out of the game. Just like they talk of RMS. For a very similar reason.
ESR is entirely correct – Rust is quickly becoming relevant in domains where C/C++ used to be the only realistic option. The fact that we’re contending with new hardware performance walls – not just single-core performance, but total memory bandwidth as well in heavily-parallelized problems! – only makes the issue of what languages we should advocate for _more_ pressing, not less! C and even C++ are no longer a plausible option as general-purpose application languages, whereas some combination of Rust and a variery of GC’d languages (of which Go is one) just might be.
Recent versions of Rust even improve support for asynchronous and event-based programming, which was very much a pain point when ESR was last seriously considering the language. The newest release of _tokio_ (0.2) is finally building on these improvements to make these sorts of problems a _lot_ easier to address and solve in Rust – and plenty of further developments are in the pipeline; see this blogpost https://tokio.rs/blog/2019-11-tokio-0-2/ for details. Rust is a genuinely compelling project, and readers of this blog should be paying attention to it.
What somebody really needs to do is nuke our system of timekeeping from orbit, not just individual APIs that try to deal with it: Precision timekeeping becomes a TAI second count, and civil timekeeping is defined in terms of the rotation of the Earth (so one second of civil time is by definition 15 arcseconds of counterclockwise rotation of the earth relative to the mean sun, as observed from above the north pole), and using civil time units for precision time or vice versa is verboten, in particular there is no such thing as a “day” of precision time, or a “date” in precision time with any more structure than an SI second count from an epoch. Civil time becomes year-round, global UTC. Computers keep separate precision and civil time, obtained from separate sources, and do *not* use a conversion of one as a source for the other.
Which is why timekeeping is a finger-trap.
“This is all so easy to do, if only humans weren’t involved”
Given that people still use UTC instead of TAI? Yeah.
This sounds nice, but doesn’t actually work at all.
In particular, you need to convert between civil time and precision time, because the things you want to time precisely have interactions with humans who live in society and reckon their phenomenological experience according to imprecise concepts like days, weeks, months and years. Thus, your systems must be designed with interconversion in mind; this alone is enough to sink the idea of defining civil time seconds in terms of a fundamentally imprecise process like the rotation of the Earth. Likewise, no human ever wants to know where the sun is in Greenwich, England unless they actually live there; thus, no human will ever use UTC in their daily life, rather than a local timezone.
This problem domain is a toxic swamp, as our host puts it; and fundamentally it’s a toxic swamp for unavoidable and inherent reasons. You could invent your own new system from the ground up if you wanted, and it might well be easier to work with, but it would not be fit for purpose as regards everything humans actually want to do with timekeeping; thus you’d just be reenacting this yet again.
>In particular, you need to convert between civil time and precision time, because the things you want to time precisely have interactions with humans who live in society and reckon their phenomenological experience according to imprecise concepts like days, weeks, months and years. Thus, your systems must be designed with interconversion in mind; this alone is enough to sink the idea of defining civil time seconds in terms of a fundamentally imprecise process like the rotation of the Earth.
Under what context is it relevant both how many SI nanoseconds long an interval is *and* whether one or both ends of that interval, e.g, fall within the month of October?
>Likewise, no human ever wants to know where the sun is in Greenwich, England unless they actually live there; thus, no human will ever use UTC in their daily life, rather than a local timezone.
Except that local time is a crap approximation for where the sun is to begin with, due to DST, oddly drawn timezone borders, etc, and I can always just memorize or look up what UTC midnight falls at for my current location.
Local time is close enough to be used as a Schelling point for human interactions, e.g., the classic 9-5 job.
> Under what context is it relevant both how many SI nanoseconds long an interval is *and* whether one or both ends of that interval, e.g, fall within the month of October?
When my GPS company wants to bill clients for how long they’ve used our correction services, for one thing.
(in this case: data is created in precise-mode, needs to be trivially converted to civil-mode for human interactions like billing, and making every node that needs to do this conversion into a low-budget IERS is not an option.)
> Except that local time is a crap approximation for where the sun is to begin with, due to DST, oddly drawn timezone borders, etc, and I can always just memorize or look up what UTC midnight falls at for my current location.
Local time is a plenty good approximation within an hour or so, which is all you need.
Adding the noticeable mental friction of “okay, where am I and where’s the sun at 0000 UTC” to every interaction involving time is a non-starter. People will flatly refuse to do it, poo-poo them as irrational all you like.
>…you’d just be reenacting this yet again.
As a side note, I wonder what it says about nerd culture that I didn’t need to follow your link, just inspect the domain name (not even the full URL) to know exactly what I would find on the other end of the link (“…there are fifteen competing standards”).
Found this a couple of weeks ago, and boy do I know a handful of these.
>Found this a couple of weeks ago, and boy do I know a handful of these.
That is very amusing.
>What somebody really needs to do is nuke our system of timekeeping from orbit, …
Just like what a communist technocrat would say. How many people will you need to destroy to “reprogram” the world into what you think is easier for you? Lazyness + genocide, and yet you tech-trans think you’re superior to all.
having gotten themselves in a little bit of trouble, they do an instinctive but wrong thing, and then repeat the failing behavior as though doing it harder will get them out of trouble.
Sounds a lot like the Democrats’ impeachment strategy (or, more accurately, their “get rid of Trump” strategy in general)…
Could we please leave politics at least out of technical / computer science threads, please.
Technically out of scope, but, I’m in a mood.
“Get government out of marriage” is a finger-trap.
This convincingly argues otherwise: http://tailsteak.com/archive.php?num=495
Well it demonstrates why the problem can appear to be deceptively simple. However, I notice that the comic makes no mention of children.
Look at these three articles for a good discussion of the problem.
The fundamental problem for libertarians:
You may argue that the state used to leave marriage and family law to the church. That’s true in fact some countries (mostly in Asia) still do.
However, the state would also back up the church’s decisions with force, which ultimately requires either an official state church, or at best an official list of approved churches and that everyone officially belong to one of those churches.
That assertion, in an argument directed at libertarians, all but guarantees your entire argument will be written off as either ignorance, defeatism, or some combination of the two, by a significant chunk of your audience. Even the minarchists, though they might not have enough confidence in the anarchist solution to want to live in the first experiment, still often find it interesting and think it should be tried somewhere.
Given the current situation in the United States, that argument is also unfortunately true. And that is in fact what is happening.
Thinking about it, libertarians’ tendency to dismiss realistic assessments of the political situation as a combination of ignorance or defeatism goes a long way towards explaining their lack of success in reducing the size of government.
I’m gonna call motte and bailey on this. The quoted passages were talking in the kind of abstracted terms that strongly imply ‘we are discussing problems and/or solutions in principle, at a theoretical level’, as opposed to ‘present-day practical politics’. Note in particular the word “always” within the sentence I quoted.
Equivocating between “non-government-controlled marriage is impossible, because children” and “the current Congress wouldn’t pass that bill” does you no favours.
It may not be clear from the passages I quoted, but the linked articles deal heavily with the specifics of recent history.
In any case this isn’t a case of “the current Congress wouldn’t pass that bill”, but “we would need to completely restructure the way people think about the nature of law”. Which I’d be all for; however, if we could do that, we should do that first before doing things that depend on it.
In any case, this only further support for Ian Argent’s original point that getting government out of marriage is a finger-trap.
I’m not sure that “the current congress wouldn’t pass the bill” is the point being made. I think the point may well be more theoretical, and that a strong argument can be made that an organization empowered to enforce contracts is *definitionally* a government.
To which the libertarian replies “no, we need a word to describe that thing we hate, and until everyone speaks Eldraeic and we can start calling them korasmóníë, ‘government’ is the closest term we have”.
For instance, David Friedman’s definition of the term ‘government’ revolves around legitimised coercion, and quite clearly excludes the kind of just-a-contractual-extension-of-each-individual’s-right-of-self-defence private protection system that an-caps propose.
And how does choosing and enforcing a teenaged-girl’s prom dress fit into your notion of just-a-contractual-extension-of-each-individual’s-right-of-self-defence private protection?
Since those articles were published, the government’s “disengagement from marriage” has lead to even worse examples of government entanglement with private lives. Thus, I can provide you with much more coercive and intrusive examples.
>For instance, David Friedman’s definition of the term ‘government’ revolves around legitimised coercion, and quite clearly excludes the kind of just-a-contractual-extension-of-each-individual’s-right-of-self-defence private protection system that an-caps propose.
And the enforceability of a contract depends on some organization with the power of legitimized coercion.
>And the enforceability of a contract depends on some organization with the power of legitimized coercion.
But the contract enforcer doesn’t have to be like a government in claiming a monopoly on the licit use of force. Friedman’s theory of libertarian governance is based on that insight. It’s pretty much the Standard Model found in most versions of anarcho-capitalism at this point. Including mine.
As Nick Szabo points out here, Friedman’s theory is based on contradictory premisses.
The problem is that any externality is weaponizable.
I fail to see how any of Szabo’s examples preclude the farmer and railroad striking an agreement. Even the last one:
Railroad: Rawr, I’m gonna torch your field!
Farmer: I’ll pay you not to do that.
Railroad: How much?
(some amount of haggling later…)
Railroad: OK, you got yourself a deal.
Even if the farmer and the railroad fail to make a deal, that just means the railroad values its desire to burn the farmer’s fields more than the farmer values keeping his fields. In other words, as horrible as it sounds, this is the economically efficient outcome.
Try again.
Except the railroad doesn’t desire to burn the farmer’s field. The only reason it’s threatening to do that is to extort money from the farmer.
>Except the railroad doesn’t desire to burn the farmer’s field. The only reason it’s threatening to do that is to extort money from the farmer.
Nice set of railroad tracks you’ve got there. Be a shame if something happened to them.
You and Nick Szabo are making the same mistake. All negotiations involve the possibility that one or both parties will decide their optimax is the use of force. This doesn’t invalidate Coase’s Theorem, it just requires that you think about costs and risks more inclusively.
I noticed many years ago that Coase’s Theorem is the killer joke of economics. You can easily spot the people who really get it; they become libertarians in spite of themselves.
The problem is that this is a negative sum interaction, with the result that the farmer’s pay off to the railroad is distorting for the same reason a tax is. It causes the farmer to farm less. In fact the railroad has an incentive to tax at the Laffer-maximum. Furthermore, the railroad uses its extorted money to invest in new track, not based on demand for transport, but based on where it can extort the maximum amount of money from those living nearby.
It get’s even worse if we replace the single railroad with multiple arsonists. Now they no longer have an incentive to limit themselves to the Laffer-maximum since anything one doesn’t take will be taken by another.
Nick Szabo goes into details in the comments here and here.
Except if the Coase theorem held in the generality you and Friedman think it does, governments wouldn’t have been able to out compete anarcho-capitalist regions, and we’d be living in an anarcho-capitalist utopia right now.
>Except if the Coase theorem held in the generality you and Friedman think it does, governments wouldn’t have been able to out compete anarcho-capitalist regions, and we’d be living in an anarcho-capitalist utopia right now.
You’re missing a crucial condition. Coasian conversion of externalities to market signals only works to internalize all those costs if transaction costs are sufficiently low. The historical norm is for transaction costs to be high, producing markets that don’t clear well.
That’s why we have governments and firms. And that’s why libertarians like me believe that the most effective way to change politics for the better is to help markets clear faster and lower transaction costs. We are literally and intentionally greasing the skids for Coasian effects.
Which, in turn, is why we have been overrepresented among Internet pioneers.
Transaction costs don’t solve the mobile bandit problem I alluded to in my previous comment. Unless they’re so low that a deal involving all potential mobile bandits is feasible, and even than such a deal would effectively be a government constitution.
[This is nested too deeply to actually reply to ESR, so I’m putting it here.]
ESR> But the contract enforcer doesn’t have to be like a government in claiming a monopoly on the licit use of force
With a contract, the parties can agree to a particular enforcement agency, and write that into the contract itself.
That’s not the problem. The problem is with people who have not agreed to an arbiter for their dispute, and at least one of them thinks someone has violated his person and/or property. That second person is unlikely to agree to an arbiter chosen by his accuser, and vice versa. Anyone acceptable to the other side must be biased in their favor, after all.
The reason children are relevant at all is that we all recognize that a minor child is incapable of consenting to a contract, which means that consent of one who hasn’t even been conceived yet is right out.
Thus when The Bride of Monster and I were wed, there were four parties to the “contract”: the two of us, and our not-yet-conceived Monsterettes 1 & 2. The only legitimate state role in marriage is to protect their rights by placing limits on the arrangements to which their consent by proxy could be granted.
It’s worse than that. The marriage contract in the example did not include a clause about any daughter’s prom dress. Nonetheless, the court was obliged to address the issue. This is not enforcing a contract, at best it’s creating an implicit contract out of thin air and enforcing that.
But (as far as I can interpolate from limited information) the court was only so obliged because of the presumption that (a) a child is not permitted to be master of itself, and must therefore be the slave of another, and (b) by default the child is jointly owned by the parents. Meaning that if the parents can’t agree, and don’t have an existing dispute resolution mechanism to fall back on, the court has to get involved.
Wouldn’t it be simpler to let the girl choose her own damn dress? (Assuming she’s the one paying for it, that is. Otherwise, she only gets to choose between those gifts at least one parent is willing to bestow.)
And that is precisely why attempting to get the government out of marriage is such a finger trap.
… only if you accept those premises (a) and (b). And if your system starts by axiomatically declaring some people to be slaves, is it any wonder that it ends badly?
(Eikones help me, now I’m snarking like an eldrae.)
Sorry, I missed what you were saying before, probably because my brain automatically corrected it to something not completely bat-shit insane, but to play along, are you going to argue that a newborn baby is equipped to be master of itself? If not, you haven’t escaped the problem.
In any case, it is an empirical fact that children are not capable of being masters of themselves. Which means that if the child is not “owned” by his parents, he’s likely to become *de facto* owned by the state. To use some rather extreme recent examples, what do you think of the recent cases of court ordered gender transitions of children?
No, but I’m going to argue that that doesn’t make anyone else the master of it either.
Basically, I acknowledge that children are a Hard Problem, I don’t accept that our current solutions are good enough that we can stop looking for better ones, and I certainly don’t accept using them as a justification for a system where your taxes depend on your marital status.
In any case, the example wasn’t about a newborn, but the qualitatively-different case of a teenager. At some point, parental control changes from “protect this baby from itself as it doesn’t know what a mains socket is” to “make sure our kid doesn’t get into messy entanglements (sexual or otherwise)”, at which point I have to say I’m a big fan of the idea of measuring majority by tort insurance rather than age (the threshold depending on what particular thing you want to do), because now you just need someone, not necessarily your parents, who trusts you not to do anything dumb, and to the extent that they’re willing to put money on that. And if that someone was wrong, hey, at least the damage you do will be paid for, and you won’t be judgment-proof.
Except there are also a lot of good-seeming ideas that make things much worse.
I’m not quite sure how this is supposed to work, but it strikes me as vulnerable to the “rich pederast with candy” problem. Keep in mind that children up to a certain age will readily accept nearly anything the adults around them say.
I haven’t worked out the details myself, but I suspect the insurance companies’ incentive to not sell a policy to someone being funded by a rich pederast deals with this. (Combined, that is, with a rule against sex with your tort insurer, to prevent the pederast from insuring you himself.)
If you really want enough concrete details to critique the idea in depth, you’d better ask Alistair Young — that’s where I encountered the idea.
And what incentive would that be?
That doesn’t strike me as a particularly enforceable rule. At least not by any means a you’re apparent libertarianism would feel comfortable with. Also, sex is not the only way to exploit children under this system.
I haven’t read through the whole thing, but my first impression is that it’s even less well thought out than the impression you gave. In fact it appears little more than a “horny nerd fantasy”.
To summarize my point: government in marriage is not just about who performs the ceremony. It’s about family law and dealing with divorce if allowed.
The standard libertarian answer goes something like this: If the parents are married, the marriage is, after all, a contract and should damn well specify these things; if it does, then whatever it specifies should be upheld (pacta sunt servanda); if either of those conditions fails to hold, then ‘family law’ is about the default rights and obligations in the absence of a contract modifying them, and whatever that might be, it’s not marriage law, and shouldn’t be affected by what other contracts the parents might have signed with each other, or whether those other contracts fit any particular standard someone might want to call ‘marriage’.
Except one of the many functions of the legal system is deciding what kinds of contracts are or aren’t enforceable.
For example when no-fault divorce laws were passed, they effectively spliced unilateral abridgment clauses into all existing marriage contracts and forced all future marriage contracts to contain such clauses.
Also how does your “just an ordinary contract” theory of marriage apply to any children born from those marriages, they after all didn’t sign any contract and in any case wouldn’t be competent to sign them anyway.
BTW, you may want to read the articles I linked, they address most of your objections.
Many (most?) libertarians reject this: if all the parties to a contract provably assented to the same contract, then the contract means what it says and no more. We call it “freedom of contract”.
And children born under the current system didn’t consent to what that throws at them, either; your objection proves too much.
(Spitballing: maybe parents could be tortiously liable to the child for creating it without a plan to support it? Amusingly, this means that not getting an abortion could be considered a ‘crime against the unborn child’, which tickles my sense of irony.)
After getting halfway through the second one, I couldn’t stand any more of the special pleading, apologia, motte-and-bailey fallacies, etc. Managing to confuse a restriction of freedom of contract with liberalisation shows that the writer, though clearly conservative and attacking the Left, has fully swallowed their propaganda about left == liberal. The people who want the government “out of the marriage business” are not the Lifestyle Left! Those folks want the government to explicitly define every combination as marriage and then lock up any bakers who exercise their freedom of association to not trade with them!
Except actual libertarians were making those arguments, some of them still are.
They tend to be the Lifestyle Left’s useful idiots.
No it doesn’t, I don’t agree with your delusion that children are capable of being masters of themselves. And the current system of them being raised by their parents works rather well, or at least it did before people tried to get the “government out of it” which resulted in much more government involvement messing things up.
being raised by their parents
Being raised by their parents is not the same as being *owned* by their parents, which is the term you used upthread. The parents are not the child’s owners. They are the child’s *guardians*–the parents have a responsibility to protect the child’s interests and do what is best for the child until the child is old enough to start making those choices for itself.
The rationale behind the state getting involved is that some parents don’t properly exercise their responsibility as guardians, so the state has to intervene to make them, or in some cases to take the child away from its biological parents and become the guardian itself. And the real argument against allowing the state to do this is how badly it botches that job. For example, in my state, the vast majority of children in foster care never get adopted; they end up “aging out” of the system at 18, with essentially no family that the state recognizes. Most of them would have been better off with their biological families, however imperfect and dysfunctional.
In other words, the proper libertarian argument against state involvement with marriage and children, as with anything else, is not that leaving the state out of it always leads to good outcomes; it’s that letting the state into it leads to worse outcomes.
Except what if the parents disagree? What if there’s a dispute about who the parents are?
This is one of those areas where a little state power on the front end, i.e., enforcing traditional marriage norms, prevents the need for a lot of state power on the back end, i.e., the whole divorce family court system.
what if the parents disagree?
If the state can’t get involved, then they’ll either figure it out, or other adults in the family will knock their heads together and make them figure it out, or they’ll disagree and the family will be worse off for it.
Will that be worse for the kids than a household where the parents can always reasonably work out a consensus plan? Yes. Will it still be better than the state getting involved and micromanaging the family? Yes.
a little state power on the front end, i.e., enforcing traditional marriage norms
Assuming for the sake of argument that “traditional marriage norms” are in fact optimal, that still does not mean the state should enforce them, because the state will not stop at that.
That works in societies structured around extended families. Not for societies based on nuclear families like early 20th century America, or societies based on atomized individuals like most modern western societies.
That works in societies structured around extended families. Not for societies based on nuclear families like early 20th century America, or societies based on atomized individuals like most modern western societies.
You missed my third alternative. Yes, in societies like many western ones today, there are fewer other adults in a position to exert influence on parents to get their act together. That means there is more likelihood of suboptimal environments for kids to be raised in.
What it does *not* mean is that having the state interfere will improve the situation.
If the only possible option you can think of other than “slave” is “their own master” then I don’t know what to tell you, other than that there is something deeply messed up and perverse in your thinking. You are making the worst stereotypes of stupid lolbertards look like subtle and incisive thinkers by comparison.
Here is a hint: In any of the fundamental relationships (husband/wife, parent/child, etc) if one side of the relationship starts thinking in master/slave terms they will reliably destroy both the relationship and the people involved.
That should tell you something.
I think you replied to the wrong comment. I never described anyone as a “slave”.
Sorry, I’ve been reading a lot of Alistair Young’s Eldraeverse lately, and seem to have picked up their habit of referring to anything short of perfect laissez-faire as “slavery” (to give you a flavour, their word for “democracy” glosses as “mutual-slave-state”).
But to your point about slave/master dichotomies, I’d argue it is the belief that the two come together that is unhealthy. A hint for you: if everyone is master of themself, no-one is a slave.
Arguing against libertarianism with libertarians is a finger trap.
For example, just try to say that only a government can build a road. You’d think it’s obvious, which is why you see so many people making that argument. But it’s a finger trap.
It’s arguably missing the point of the post to mention this, but I’ve never found escape-parsing remotely tricky, because obviously you just run a state machine over the damn thing. I was quite surprised when I learned that there are people to whom this is not obvious.
(Specifically, someone on the IETF apps-discuss mailing list a few years back, who objected to an ‘escape-the-escape-character-as-itself’ design on the grounds that it was hard to parse with regex, as though that were a sane thing to do.)
>obviously you just run a state machine over the damn thing.
Well, yeah. The problem is, writing even relatively small state machines is a finger trap. :-)
In the exact sense that it’s really simple in concept but annoyingly difficult to track all the cases in your head exactly enough that you Just Write It. How often have you breezed through one, tested, and gone “D’Oh! I forgot N obscure state-input combinations”?
>How often have you breezed through one, tested, and gone “D’Oh! I forgot N obscure state-input combinations”?
0 times.
>0 times.
You strain my credulity.
>How often have you breezed through one, tested, and gone “D’Oh! I forgot N obscure state-input combinations”?
Think of the truth table for this combined statement.
I have met [all conditions] in this statement 0 times.
That’s *obnoxiously* pedantic.
I don’t know about Nick, but if I were he I’d take that as a compliment!
I wonder if he’s an Aspie. This is the kind of pedantry I would expect from one. And I ought to know, because I am one.
But the escape-parsing state machine only has two states, “in an escape” and “not in an escape”. To prove how easy it is (or, alternatively, prove to myself it’s harder than I think, should someone point out an error), I’ll write it in this comment box, without testing.
void unescape_in_place(char *str)
{
char *in, *out = str;
bool esc = false;
for (in = str; *in; in++) {
if (esc) {
switch (*in) {
case 'n':
*out++ = '\n';
break;
case 't':
*out++ = '\t';
break;
/* etc */
case '\\':
*out++ = '\\';
break;
default:
*out++ = *in;
break;
}
esc = false;
} else {
if (*in == '\\')
esc = true;
else
*out++ = *in;
}
}
}
(Annoyingly, it looks like the blog software is eating my indentation, regardless of <pre> or <code> tags. Hopefully it’s readable enough anyway.)
Now, granted, if you try to do this within the larger context of a parser, so that (e.g.) the same bit of code has to handle both scanning for
"and skipping over\", then it can turn into a finger trap.(And some point about C may be made by the fact that on proofreading before posting, I did spot a mistake: I’d written the one instance of
==as=…)Oh fine, I need to stick an extra
*out = *in;on the end to NUL-terminate it. But that’s an off-by-one error from the loop, rather than a state-machine problem per se. And I still spotted it without needing to test. /me frantically spins, generating excusesDid you really need to handle the “*out = ‘\\'” case explicitly?
And what about all of the numeric escapes?
It didn’t need handling explicitly, no, but it (maybe) makes things more readable.
If you want numeric escapes too, then OK, it turns into a Proper State Machine and maybe could be a finger trap (but probably not; the state transitions don’t get all that much more complicated). But my point was that the “you need to handle \\\\\\” that Eric described as ‘the trap’ in the OP was really not hard unless you were approaching the problem the wrong way to begin with (in which case you probably didn’t have a clean statement of the problem).
Thoughts about state-machine toolkits like https://en.wikipedia.org/wiki/Ragel, Umple, etc.?
As a reference point, Zed A. Shaw wrote some stuff about developing state-machines with Ragel, and the merit he saw more generally in modelling using state-machines.
>Thoughts about state-machine toolkits
Ragel looks like it was written by somebody who thinks and designs like me. I could use it.
Not so impressed with Umple. But then I never have seen much point to UML.
Some news has been making the rounds. Richard Matthew Stallman will not be returning to programing. He says he is too busy, reading emails. Why are the emails so important? It is fun to email him, and he often responds, but that’s just a good thing for the email-user, not really for Richard. Wouldn’t Stallman’s standing improve if he programmed again, to silence the “he does nothing” crowd, and to give some fun and enjoyment? How can reading emails everyday be that great? Eric, what is your opinion on this. RMS languages are _C_ and Lisp.
>Richard Matthew Stallman will not be returning to programing. He says he is too busy, reading emails.
[citation needed]
Anybody who has actually known RMS for longer than ten minutes is going to take a lot of convincing about this. I’ve known him for 40 years.
How can I cite an email? He was asked and he said he wouldn’t.
You might reposte’ “those higher priority things aren’t email”. He’s not in the FSF anymore, and other emails suggest the HPT’s are email:
To the question: How are things
Suggests that the work is email, but doesn’t exclude other things being the work.
>I have no time for that. I have higher priority things to do.
He does. Like finding a permanent place to live. Making sure he can pay for food. And putting back together a life that has been cruelly shattered by SJWs and evil scum (but I repeat myself).
So you accept that RMS has given up programming? Isn’t it a shame. I had hoped there would be some silver lining. I hope he has some ca$$$H stashed away and didn’t give it all to the vipers at the FSF (I have never met a foundation that wasn’t a hall of brutuses though).
SJWs and Regular Americans look like two sides of the same coin to me. The Proud American Men wanted him dead for being “a pedo”, the SJWs for a similar reason. They’re all scum: because they’re just different (slightly) expressions of the same underlying beliefs and culture.
Sad he caved to them. He has a house he owns in Massholeachuchets, right?
Why won’t he rejoin his programmer brethren? Doesn’t this make you sad?
>So you accept that RMS has given up programming?
No, I don’t, and it takes a deliberate misreading of what I wrote to suppose that I do. I do not believe RMS will permanently give up programming before he has been dead for several days.
You’re trolling. I’m not going to ban you yet, because it takes much worse behavior than mere trolling for me to ban anyone. However, I am going to shun you. I think you’re an asshole – a petulant little pimple who deserves a good slapping – and I am not going to encourage you by responding to any of your comments in future. I will also recommend to my regulars that they ignore you.
If you’re typical of your type, you will respond by screeching for attention like a demented howler monkey. Knock yourself out; I won’t care, until and unless you cross a certain line which I will not specify so you won’t be able to game it. If you cross that line, I will suddenly and quietly ban you. There will be no discussion, no appeal, and no reversal; you’ll just be blocked.
Alternatively, you could try saying something interesting and useful.
I got the impression, from the emails, that RMS has given up programming.
The question was asked of RMS because for the last decade (2008 till now) RMS has /not/ been programming much at all, but was doing FSF related things instead. There was hope, now that he was thrown out of the FSF(*) and MIT(non-paying position, who cares) he would come back to it
(*and it is not surprising about the FSF: if you have dealt with non-profit foundations, it is _always_ a bunch of backstabbing going on, and jockeying for position. Do some pro-bono legal work for any on them: they are simply concerned with finding reasons to oust eachother. First thing _I_ was asked to do was basically find if Director A could oust Director B because of Thing. The answer was Yes. I assume my legal work was then used to effect such)
Thus RMS was asked: will he be back to programming.
He said No.
What more is there to tell? He doesn’t program anymore, sadly. We _want_ him to program.
(Note: this work was for a different Non-Profit I will not name, but they’re all the same)
We should actually strive to remake the entire ecosystem, including a better hardware architecture to replace X86-64 in the long term. I personally like this hacker’s ideas:
http://www.loper-os.org/?p=1361
http://www.loper-os.org/?p=284
In the meantime, there is also this language, another attempt at a C alternative, though still immature:
https://ziglang.org/
>We should actually strive to remake the entire ecosystem, including a better hardware architecture to replace X86-64 in the long term.
It’s going to be RISC-V.
The ISA design doesn’t suck, and they’re making all the right economic and political moves. I’d like to know who is running their grand strategy, because whoever he is is good. There’s careful positioning going on that will only bear fruit in 2 to 5 years, but when it does, watch out.
First they’re going to disrupt the shit out of ARM, then they’ll do Intel. It’s going to be a lot of fun to watch. An absolutely classic Christensonian attack from below, and if I were a C-level at ARM I’d be crapping my pants already, because they cannot fail to see it coming but there is nothing they can do to stop it.
Intel can at least fool itself for another few years.
There’s only one company with the wherewithal to seriously challenge Intel on performance with a non-x86 part, and that company is Apple. Apple is currently committed to the ARM route, but they’re also the only company with the ability to pivot their entire hardware and software stack to a new ISA 100% seamlessly, so we’ll see. If Apple embraces RISC-V, Intel is in real trouble. Otherwise they’re safe from an open-source disruption from below at least.
>If Apple embraces RISC-V, Intel is in real trouble. Otherwise they’re safe from an open-source disruption from below at least.
Apple not flipping will certainly delay the year of Intel’s disruption, but not prevent it.
I am certain of this because RISC-V’s value proposition is both simple and powerful. It is “We can make your recurring IP costs go away.” And they have a reference, what they did for Western Digital. It used to have to pay rent for every one of its drive controllers. Now it doesn’t.
That’s a big deal, and a very serious headwind for ARM and Intel to have to fight. ARM is more vulnerable, both because they’re closer to existing RISC-V implementations on the power curve and because IP rent is all they have. Without it, there’s no company.
Intel is less vulnerable. It owns fabs; it’s not entirely dependent on IP rent, though of course losing that would kick the hell out of its margins. But less vulnerable doesn’t mean invulnerable…
You know what? I should do a post about this. There’s another aspect to RISC-V’s competitive posture that is novel, interesting, and hard to notice.
Eagerly awaiting this, because overall I agree: RISC-V is gonna change everything. Yeah, RISC-V is good.
> other examples of finger traps
How about parsing indentation-sensitive code?
Seems simple enough: In your lexical analysis, keep track of the current level of indentation, and emit INDENT and DEDENT tokens; now, you can treat it as a context free language…
…Except you don’t want to care about the level of indentation inside parentheses. Okay, so as a hack, have the lexer keep track of open parens… dammit, I also need to worry about multiline strings, which may have parenthesis in them…
Is there a glossary of ESR coinages somewhere? Finger traps, Kafka-traps, motte-and-bailey arguments … Some for programming, some for politics, some for just thinking more clearly.
A good term packs up a complex idea into a unit that can be handled more easily and carried along while dealing with OTHER complexities until the time is ripe to unpack and deal with the components of the original unit. Like a verbal sort of algebra.
If a list exists, where is it? If not, is there a keyword on the dated blog posts where terms are introduced? Or does developing a list require reading (re-reading?) all posts since day zero?
>Is there a glossary of ESR coinages somewhere? Finger traps, Kafka-traps, motte-and-bailey arguments … Some for programming, some for politics, some for just thinking more clearly.
I did not coin “motte-and-bailey arguments”. That one was originated by an academic paper attacking postmodernism and popularized primarily by my friend Scott Alexander over at Slate Star Codex.
I’m working on a book that will have a compendium of my programming-related coinages as its first section.
I don’t think ESR coined “motte-and-bailey”; that was popularized by Scott Alexander on Slate Star Codex, but he didn’t coin it either; I think the SSC article links to an academic paper that originally coined it.
I apologize. Though had I access to an official dictionary, I might (maybe ) have RTFM before posting about botte-or-maileys.
So, what about ” “prospiracy” ? And are the protestors in Hong Kong part of one?
“Prospiracy” has the added problem of being in use elsewhere, with a different meaning from Eric’s. Urban Dictionary and other sources describe a prospiracy as a covert collusion to do something good. Eric describes it as a conspiracy where all or at least most of the colluders aren’t aware they are colluding.
At this point, given that I can’t find that meaning in use with that term anywhere else (leading to another rant I have about searching for definitions on the internet, but I digress), I judge it’s probably easier for Eric to coin a new term than to fight a meaning that probably fits everyone’s intuition better anyway, based on the roots.
It probably needs to end in “spiracy”, whatever it is. “Cryptospiracy” is evocative, but also might connote an effort by the colluders to make it look like something else. “Ignospiracy” might fit better.
“Con-” as a prefix means “with, among, between”. Perhaps “extraspiracy” in the sense of “outside, beyond”. Or just expiracy.
Unspiracy?
Exospiracy? With a nod to “exoskeleton,” as being a collusion where the structurally-important colluders are are on the ‘outside,’ rather than on the ‘inside’ as is the case in a standard conspiracy – which can be back-named an ‘endospiracy.’
@ESR
https://www.youtube.com/watch?v=pW-SOdj4Kkk&feature=emb_title sounds like up your alley – civilizational collapse discussed in the framework of robust vs. bad software. It is all about simplifying and removing unnecessary complexity.
Somewhat related. I don’t think Urbit can succeed as it is too “exotic” to stomach, but the problems it tries to solve are real. The Internet was meant to be something decentralized, yet now people use their browsers as “modems”, clients for servers ran by Facebook, Google etc. People need their own personal servers, perhaps in the cloud if they are uninterested in managing them. And if people do have their personal servers then… what is the difference between an email, a tweet, a blog post, a blog comment, a Facebook posting, an instant message? They are all HTML pages with embedded multimedia, let’s call them content pages, shared with some people (email) or all (blog post), with some added things like showing only the first 280 characters (tweet, but can be just a client-side view) or allowing a trusted group of people to mark a content page shared with you urgent (instant message) and then it beeps on your phone, or referencing another content page (blog comment, with client-side options for tree view).
There is a potential for massive simplification and redundancy-removal there replacing all this with one thing, a content page with some extra properties on your server and other people’s servers copying it if you allow them to, but it seems for something like that you have to reinvent the Internet on the basis of personal servers. (However they should not be reinventing programming language reserved words with fsckin’ runes.)
Is anyone else solving this? Even planning to?
If I am understanding you correctly, I think that Sir TBL is doing something like that over here ( https://solid.inrupt.com/ )
You mean you haven’t heard of IPFS? :)
You don’t have to reinvent the internet to have the notion of a personal server. The internet is built to support such things from the start. Whether it actually does depends on your ISP and who’s in charge of the government in your area. And, if centralized services have better marketing and the ear of government regulators and ISPs, who have the power to restrict the amount and type of traffic you send over the wire, there’s not a whole lot you can do by “reinventing the internet” or building some silly, unnecessary inner platform on top of it. Urbit is simultaneously a technical solution to a social problem and another “back to zero” cry from a soi-disant genius who promises “just follow me; I’ll do things right this time!” I tend to distrust such claims, especially when a platoon of supporters paratroops in to Reddit, Hackernews, and this blog, all repeating the same nostrums in such a way to make MLM distributors and Newlisp advocates seem like independent thinkers.
When it comes to building distributed publication services, IPFS comes closer to the sweet spot of building on existing concepts and infrastructure in innovative ways, appears to have the most uptake out of all of them, and comes with way less bullshit. But again, as above, there’s only so much a distributed platform like IPFS can do. You have to cultivate a high regard for decentralization in the broader society, otherwise Google and Facebook will just happen all over again.
I think you might be ignoring the big lesson that was learned just about around these parts: ESR was preaching for decades about the promised lands of Open Source and Linux and it worked for e.g. web developers but the average user did not care. And then Android happened…
So the lesson is, IMHO, don’t preach to people what they should want, rather give them something they actually want but in a way that also gives them what you think they should want.
James Noyes mentioned Solid, which I think has a better chance of succeeding because it has Sir TBL’s name on it. But still I don’t see them selling people what they want. Like, it could be “upload your YouTube vids through our app and you get it backed up on your personal server plus cross-posted to all the other social media”.
Once people would be “tricked” into having personal servers (start with people who make a living off social media since they influence everybody else), Facebook and Google can as well be happening again, but now they are just content aggregators combing through all the personal servers which makes them WAY less monopolistic and dangerous, and way more replaceable and outcompetable.
(BTW take a look at Pico LISP, not Newlisp, if for no other reason then because it demonstrates the typical (Central) European cultural approach to software and then one can discuss if it is a good thing or not. Basically what I mean is a strongly “batteries included” approach, “everything you need to do the job in one package”, not the Unix “do one thing well” approach where you assemble and connect your tools piecemeal.)
“Solid” is just short for SOcial LInked Data – hence Solid standards are most likely going to interoperate quite tightly with both the Fediverse (a variety of federated services based on Web standards) and “semantic”/Linked Data standards. This essentially already gives us these usecases “for free”, since the Fediverse supports them. The problem is that there’s no incentive for existing “walled gardens” to interoperate properly unless the network effect around the federated variants is strong enough. And that might take some time, just like it took some time for interoperable e-mail to supplant the likes of Compuserve.
>Once people would be “tricked” into having personal servers (start with people who make a living off social media since they influence everybody else), Facebook and Google can as well be happening again, but now they are just content aggregators combing through all the personal servers which makes them WAY less monopolistic and dangerous, and way more replaceable and outcompetable.
I realized this is actually a historic pattern. The reason Facebooks happen is that humans are too much of a herd animal. We want to be in that thing that all the cool kids are doing. Really explains stuff like religions, or stuff like historic fads that seem ridiculous even a few years after but back then they were just totally the thing.
On the other hand, the whole herd thing is less dangerous if you have the kind of frontier-ish homesteader society where most people own their house, their land or tools of trade, when they have this sort of economic-social independence. For instance, because it makes it easier to not join the latest herd-thing. Or to quit it. Or being on the wrong side of some herd-thing is less likely to totally wreck you.
So the Information Age version of it is that you should absolutely and exclusively own all your data. Be a data farmer, data homesteader, not a data peasant. And yes people will keep throwing them into all kinds of Facebooky things because that is the “in” thing and all the cool kids are throwing all their cool data into it. It is just pretty much like putting on your best toga and going for a stroll on the Roman Forum. Being a social animal. But if that is only sharing, sharing that can be revoked, if that thing merely “rents” their data, then it will be far less dangerous.
Android is, for all intents and purposes, almost as closed as iOS, and way more intrusive on your privacy. Not the best example.
And ESR wasn’t preaching. That was Stallman’s thing. What ESR was doing is more… marketing. Tailoring the message to appeal to business executives, who make the real decisions about what software gets used. And it worked. First among companies on the brink of failure like Netscape, and then among successful companies who knew their number was up (and every company’s number comes up eventually).
Now even Microsoft is cozying up to open source. Frickin’ Microsoft. Think about it: The vi vs. Emacs editor wars of yesteryear are moot now because both contenders lost big to an open source, cross-platform code editor… from Microsoft.
That uses a rendering engine made by Google, no less. Heck, VSC even has a great vim plug-in, probably the best I’ve ever used in a GUI text editor.
Rust is at the point where if you are considering C for a new project, you should really stop, step back for a moment, and try out a pilot project in Rust. (Does this mean that C is itself a finger trap?) But — and this is the crucial bit — don’t give up when you run into something weird or abstruse. Stick with it, the way you stuck with Emacs if you’re an Emacs user. Entire classes of memory and concurrency bugs that have dogged C and C++ programmers for decades just go away in safe Rust, so it is well worth the investment.
Yes, it has no GC. This is a feature. “But muh cyclical data structures…” Put your nodes in a vector and represent your graph with indices into that vector. You can even use the type system to assign the same lifetime to the indices as that of the vector, thus assuring that you can never take an index to an invalid vector.
Rust is — absolutely — the future of programming. You may not be using Rust the language, but static typing with parametric polymorphism and static compile-time lifetime analysis are coming to a language near you.
I find it interesting and encouraging that Rust is not only used for the kind of things one would use C for, but there are also Rails-like web frameworks, something one would never consider using C for.
There was this trend that speed does not matter anymore, so let’s just write every application in Python or the equivalent. Then things like Rapsberry Pi and Arduino and whatever happened and if you want a web server running on gadgets like that because that is the easiest way to control their behavior from elsewhere (for example), a fast language for web development could get interesting again.
It would be good if one could do what they call today “full stack development” although I would just call it application development without switching between languages. Some French people, using the typically European “everything you need in one package” approach (as opposed to the modular, tools should do one thing well and then link them up US approach) made https://wakanda.github.io which is full stack JavaScript integrating back- and frontend rather elegantly. But… it is JavaScript. It is not going to be fast on such a gadget. Hence looking forward for Full Stack Rust or the like.
I don’t like deeply embedded threads so saying it here rather than there. Coase Theorem. If you look up what https://en.wikipedia.org/wiki/Transaction_cost means, first thing you should notice is that literally all three broad categories of it have trust as a core component of them. If everybody would be very trustworthy, you would just buy from whoever advertises that he has the best price at your required level of quality, shake hands and that is it.
There is this study asking whether the Prisoner Dilemma refutes the Coase Theorem https://papers.ssrn.com/sol3/papers.cfm?abstract_id=2373635 which I haven’t yet read in the full, but the excerpt saying “one in which property rights are well-defined and transactions costs are zero (i.e. the prisoners are allowed to openly communicate and bargain with each other)” – immediately makes me think that it really matters if they believe or not what the other is communicating and if they keep their bargained promises or not.
My experience about human nature is pessimistic, but in a specific way. People almost never act unethically with people they KNOW to be honest and decent. The reason of most unethical behavior is not trusting others to be honest and decent (“screw them before they screw us”) or finding a way to convince themselves they are not honest and decent (“It was in my interest to screw them but they are assholes anyway, so they deserved it”).
A society with trust maxed out would be the closest thing to utopia.
Currently, it seems the world is becoming lower-trust.
Well, it is a tech thread, so let’s look at that aspect. The problem was realized long ago and that is why “trustless” systems are developed.
Remember the DAO hack? That’s when I started to be skeptical about “trustless” systems. Basically the problem was that they were telling everybody “code is contract”. And then someone found a bug and stole a lot of money. Then it was a shitstorm. Some argued that if “code is contract” then it was not even a theft. Any transaction the code allows is allowed by the contract, logical? But it was obviously violating the verbally agreed purpose of the DAO. Thing is, it is simply not true on a blockchain that “code is contract”. Because miners have a lot of power to decide things. This was know from the very beginning of BitCoin, Kanazawa wrote “it is based on the assumption that most miners are honest”. In this case the matter is not even honesty, but rather how the miners are going to interpret and enforce the code that is the contract. One miner have put it very elegantly: you can say that the DAO code is contract, but the code that runs my mining rig is also contract then, and this contract says I have the right to judge, interpret and selectively enforce your contract. Which I am going to do by mining the hard fork that locks your hack out. Hard to argue with that. Either all Ethereum code is contract or none of it. Being a good formalist, I proposed making it formal, miners should form a judicial jury, with a formal process of filing such lawsuits. If the code says they have the power to judge, let’s formalize the process. I don’t think anyone listened, though.
So anyway, it empathically turned out to be NOT “trustless”. And I cannot solve the problem, all I can do is to say that formalism helps to mitigate it, if for example you have to trust miners, if miners do have a power to judge such contracts, then this power should be made widely known, there should be a widely known formal process for filing a suit at their court and so on. Formalism merely eliminates the cases when you did not know that you are implicitly trusting someone and makes it explicit. I can’t do better than that…
The reason the miners are supposed to be trustworthy is that there any many of them so it should be hard to get them all into the same conspiracy. Also the people running full nodes are possibly equally (or even more important).
In the case of Etherium: the DFL’s word provided coordination for the miners. Also, dues to the growth of the chain it’s almost impossible to run your own full node.
esr.ibiblio.org is acting up again, much as it had 3 months ago.
Website wouldn’t load at all in my iphone for several days. Today I can load the homepage but not the posts. The template has always displayed poorly on my iOS version, especially nested comments, but now it’s showing nothing.
Self-inflicted finger trap…
So Sunday I”m working on some code that receives a pair of records from an http PUT to an API. Either record can be either an update of an existing record or can be a whole new record. Each combination out of 4 possibilities has to be handled somewhat differently. Both records have to fail or succeed together.
The longer I worked on it the more it started to look like some spaghetti code you might write in GW-BASIC and the more convoluted and confusing it seemed. So I closed down my IDE, got up from my chair, and did something else entirely until this morning (Tues).
Today upon taking a fresh look, it now seems … maybe not exactly simple, but at least straightforward.
And the code is basically done after an hour of work.
Self inflicted.
In Programming Pearls, Jon Bentley wrote about binary binary search as a finger trap (although he doesn’t use that term). Although it sounds simple, a bug-free solution is apparently not simple. https://www.cs.tufts.edu/~nr/cs257/archive/jon-bentley/correct-programs.pdf
>In Programming Pearls, Jon Bentley wrote about binary binary search as a finger trap (although he doesn’t use that term).
I confirm that I consider this an excellent example of a finger trap.
And, notoriously, this is the implementation with a bug that lurked for many years…
>And, notoriously, this is the implementation with a bug that lurked for many years…
Do you mean Bentley’s code? Cite on the bug, please. It would make a good addition to the expanded version of this post in my next book.
I found this explanation of the bug in Bentley’s binary search: https://ai.googleblog.com/2006/06/extra-extra-read-all-about-it-nearly.html
It’s an integer overflow bug, and for me it is obvious only once I know it’s there.
>It’s an integer overflow bug, and for me it is obvious only once I know it’s there.
Thanks!
That’s the one. You wouldn’t think it mattered until it did. IMO the C++ STL is interesting in this area with lower_bound, upper_bound algorithms. Don’t know about Go/Rust et al. But the history of the assumptions of bsearch(3) might be worth going into.
It’s even subtler than you think, because in C, signed-integer overflow is UNDEFINED :) :) :) Meaning that it’s legal for Scott Nudds to fly out your nose if you do (low + high) / 2 for large enough values of low and high.
A great mitigation strategy to use is to use size_t for anything that is or might be an array index. But even then you will run into strange problems if your array size is over ((size_t)-1) / 2, so you may want to still employ the low + ((high – low) / 2) trick.
I won $5 from Bentley when he bet me that I couldn’t write a correct binary search in 30 minutes (on paper, no references–he watched me do it). It took me the full half hour. I bet he still remembers it. He was pissed. :-)
I run across finger traps from time to time and I always react the same way.
I sit back in my chair and start to think about it.
If I feel the need, and I usually do, I go take a walk and smoke for a bit.
Most times a possible solution will come to me while doing this.
I just walk away, let my brain do it’s thing.
I don’t even really think very hard, I just relax.
Post something so we don’t worry that you’re as dead as RMS
>Post something so we don’t worry that you’re as dead as RMS
The rumors of my demise are greatly exaggerated.
Near as I can tell, RMS isn’t dead either.
He’s fine, unless he’s got dirt on the Clintons…
Shout into the void:
“ibiblio’s still flaky!”
No one hears your cries.
I’m conjecturing that ibiblio goes flaky every three months when the ssl certificate is renewed. So starting August 16 then recovering, starting again November 14 and now apparently recovered, and a prediction for renewed flakiness starting Feb 12, 2020.
And it seems to be a weird certificate too, not having anything to do with ibiblio.
Since I was experiencing the 500 errors with unsecured HTTP access, and also upon checking see that the “primary” http://www.ibiblio.org certificate is dated October 2017-2020, I think the problem trigger is a little more subtle than “SSL gets renewed”.
Of course, the fact that the SSL certificate I am getting when trying HTTPS access to this blog is indeed “a weird certificate” for a random-seeming site implies that there is some sort of crossed wire in the way ibiblio is managing their content delivery. To me, that sort of crossover seems far more concerning than periodic site unavailability (what other data might be getting commingled? Is access to this site being unintentionally granted to other parties, possibly including admin access?).
Bitblt isn’t that hard. Not in assembly language: https://github.com/RussNelson/painters-apprentice/blob/master/painti.asm
Okay, it IS hard. But it’s possible. Even in assembly language. Even on the 8086 processor without a barrel shifter.
Maybe this is more of a gotcha, but it getchyas way too often:
JSON strings embedded in JSON data structures, especially when you’re passing them around the internet.
>JSON strings embedded in JSON data structures, especially when you’re passing them around the internet.
Oh, yeah. Multi-level quoting is a notorious finger trap.