enkiv2

I'm a left-anarchist.

I tend to find a lot of political & economic perspectives I see on here naive: folks have a faith in market solutions without a coherent understanding of how markets operate and under what circumstances the things markets optimize for conflict with the functioning of healthy societies; folks also have a pretty warped understanding of what certain things mean. (For instance: it's perfectly possible to have a fully communist society with free markets, although there are some issues with the stability of any system that uses markets.)

My support of free software has little to do with my political leanings, other than it being a product of a general absence of the kind of counterproductive overconfidence endemic to the right (i.e., the stuff I write in my free time doesn't have a wide enough audience to constitute a profitable business, so there's no benefit in not giving it away, especially since I can ignore patches or feature requests).

Free software has a political & economic impact, but it's more complicated than people generally admit: large companies are subsidized by the free labor of individual hobbyists who have been conned into shaping their personal projects in ways that make them useful to those large companies. (My personal projects are not just fringe but also idiosyncratic -- they are useful mostly only to me -- so nobody's liable to profit off them even if they have a stable of other projects to synergize them with.)

Software design & software engineering can be an important component of good praxis. I try to reflect my ideals in the software I write.

Capitalism transforms functionality from a cardinal concern (how much of the thing works, & how useful is it) to an ordinal one (which implementation is least-bad). Ordinal concerns are easily gamed: no matter how easy it might be to do something correctly, it's almost always easier to do it only slightly better than someone else (or to break somebody else's implementation so it's worse).

Capitalism also moves much of the emphasis to the initial selection stage: if any kind of lock-in is in place (even sunk cost), most of what matters is the implementation somebody initially picks, not whether or not they ultimately regret their selection. So, rather than making a solution that is stable and reliable or one that has deep rich expressivity, the emphasis is on making a solution that looks good on a shallow basis.

This kind of logic affects even folks who aren't getting paid for their work, because it's taken to be 'common sense' instead of a set of generally-undesirable side effects of a warped circumstance.

Software for a general audience expresses this in a more extreme way than other fields because it's nearly immune to costs like materials & liability, and because regulation largely hasn't stepped in to limit the worst of its side effects. If you build a house, it has to stay standing for long enough to sell (which is a lot longer than most software operates as intended), and it needs to pass inspection in order to be saleable; failure on either of these fronts is a big deal, because no matter how little you pay for labor, houses cost a great deal in materials, most of which lose nearly all their value in salvage. Software is almost pure labor, and can scale to an absurd degree because of this. Unlike publishing, software really doesn't have strong traditions left over from when manufacture and distribution was substantially more expensive & so quality was more important. As a result, the software industry behaves less like publishing and more like futures trading (that other entirely-abstract profession where people who are good at numbers inflate and pop bubbles while living in houses they can't afford and driving up the city's rent).

I usually put the process PID in the names of my temporary files, in order to avoid overwriting stuff. (If you're liable to do multiple runs with the same process, you can generate a random number at the beginning of the task -- or get the date, if you really want to keep the results in order -- and use it as a unique token.)

I first prototype operations as single command lines, then refactor those command lines as I migrate components of them to shell functions (often taking whatever unique token I want to use to distinguish runs). Eventually, when I'm satisfied with the behavior, I'll write the shell functions to a script with typeset -f, and then source the script later.

While it's not research-related (a lot of what I do at work is statistical analysis on server logs, but anything I develop at work I technically don't own & so can't post), a good example of this style is in my music synthesizer project: https://github.com/enkiv2/clisynth/blob/master/clisynth.sh ; all of the code in this file was prototyped at the command line.

Maybe the software industry will discover constraint programming the way that it discovered functional programming over the past decade. If it did, that would almost immediately increase programmer productivity for non-performance-critical tasks (since the compiler could supply the implementation), while making formal methods more easily applicable to production code & supplying the prerequisites for more clever automatic code generation methods.

(In general, software engineers becoming vaguely aware of tech invented in the 1960s and 1970s is a huge productivity boon. If you, as a developer, want to impress your peers, you should take a couple hours to read what software engineers thought was obvious prior to 1980, when software engineers had a strong background in software engineering.)

Debugging by abductive reasoning: imagine possible classes of mistake that might explain the behavior, then invent experiments designed to eliminate each entire class as an explanation. If a class of explanation cannot be eliminated, drill down. Often a bug is actually multiple unrelated bugs that manifest in the same way, because the universe is a shitshow.

The easiest way to get people interested in your hobby project is to write it yourself. If it's genuinely interesting, strangers will demand commit access.

If it's similar to a language I already know, I grab a quick-reference guide and start coding. If it's not similar to a language I already know, I read an essay (preferably by the creator of the language) about the design philosophy, then grab a quick reference guide and start coding.

C++ is kind of an unusual case -- it's part of that rare class of languages that are so bloated that they can't be 'learned' per-se, because nobody can keep the entire core language in their heads. Luckily, it's a mish-mash of languages most developers already know: it's C with java-like "object orientation", minus the constraints against multiple inheritance, with a grab-bag of strange implementations of familiar features provided by the STL. So, it's possible to limp along writing almost-C or almost-Java and then consult documentation when you run into a difference.

I would recommend against tutorials. The best tutorials take you on an illuminating tour of the philosophy of the language with a handful of illustrations in the form of real code; a normal tutorial covers the domains the author thinks are interesting while totally ignoring everything necessary to solve the kinds of problem the reader needs to solve (which the author is totally unaware of); a bad tutorial is wrong or misleading because it's written by somebody who also doesn't know the language. The more popular a language is, the more likely any given tutorial for it falls into the 'bad' category. Courses have the same basic problems as tutorials, but are substantially longer. Push comes to shove, if you need code in context & there's somehow no code already on your machine in that language (which may be true of APL or Julia but is very unlikely to be true for C++), look the language on X in Y Minutes or Rosetta Code.

Well, it's clear why this author isn't getting paid for his medium posts: he's writing low-effort low-quality material desperately in need of editing.

Medium doesn't present itself as a substitute for a full-time job. It presents itself as a mechanism by which people can get paid a non-zero amount of money for the kind of material they would be writing for free anyway, based on metrics related to actual quality (such as read time & explicit recommendation) rather than purely based on views (as with advertising).

I use medium and run sites that have ads. I make about twenty dollars a month on medium, and nearly all of that comes from material I wrote years ago; in comparison, I have been using adsense since 2006 and have made a total of nine dollars from it (across several blogs, a once-popular discussion forum, and a youtube channel with a couple monetized videos in the millions of views). Keep in mind that google won't cut you a check or do direct deposit until your balance hits $100; at the current rate, I will get my first Google Adsense payout early in the twenty-second century.

If your content is so bad that Medium is giving you nothing, you won't get anything from ads either.

I was only ever a regular on the (small, now-defunct) irreality.me imageboard. The most activity I ever performed on 4chan was that time I wrote a bot that responded to every post on /pol/ with a random section of Society of the Spectacle (in an arguably successful attempt to improve the quality of discussion there).

I find imageboards to be interesting from a media-studies perspective, though. They're a clear case (even clearer than twitter) of design influencing user behavior in a way that eventually generalizes outside of the platform. Three countries have shockingly similar & arguably totally distinct right-wing authoritarian populist movements that sprung up from totally distinct popular imageboards during the same period, & there are probably more that I'm simply not aware of. So, serious study of the kinds of behaviors imageboards encourage & highlight (and serious study of under what conditions those behaviors generalize) is potentially really interesting. It's one of those things that makes me wish I was a real social scientist instead of just a programmer with hobbies.

The easiest way to get into open source is to start your own projects.

Alternatively, you can find a project with a single maintainer and few or no third party patches & fix a serious issue (or add a useful feature). If your patch is accepted, then you've made a social connection with another developer (and maybe even a friend); if your patch isn't accepted, you can maintain your own fork & somebody might contribute to yours.

Contributing to someone else's project (particularly, large and complex projects) involves integrating into existing social structures, which often is difficult and underdocumented (particularly when the primary goal of the project is to just get the development work done -- such projects often don't go out of their way to make it easy for newbies to contribute, since newbie contributions are liable to be of lower quality). Some projects make a real effort, but that's unusual. Even then, large projects (because they have communities) are full of complex politics that are borderline incomprehensible from outside, and navigating these politics takes a lot of time that could otherwise be used for meaningful contributions to smaller projects.

The typical way to pick a name for a language is to choose a dead mathematician who is obscure enough that only mathematicians are familiar with his name (so, no Aristophanes, Euler, or Godel) & who hasn't already had a language named after him. (This worked for Erlang, Church, Haskell, Ada, and a whole host of others.)

Another popular way is to take a term from mathematics & misspell it. (See: Clojure, Clozure.)

Languages that are derived from other languages often have themed names -- for instance, the various javascript preprocessors have mostly coffee-flavored names, brainfuck derivatives usually include either "brain" or "fuck" in their names, and befunge derivatives usually end with "funge".

Sometimes, languages are named after imperative verbs (such as the approximately 3 languages called 'go') or arbitrary physical objects (Rust, Elm). Language-themed language names are popular, too (LISP, SmallTalk, Guile).

Languages I've made have been named after fictional characters (MYCROFT, named after the computer from The Moon is a Harsh Mistress, himself named after Mycroft Holmes), authors (WILSON, named after Robert Anton Wilson), and descriptive acronyms (GG, the language compiled by GGC, is for generative grammars).

Anarchy is a pretty loaded term (and I say that as an anarchist); chances are you'll turn off a lot of people with that name.

Try APL or Icon. They're terribly unpopular, but APL can't be beat for one-liners while Icon is substantially better at text processing than perl. Plus, both are still considered academically interesting, and both have open source ANSI C implementations that will build on any platform.

Crowley defines magick as the execution of Will upon the world. Programming is actually a better fit for this particular definition than most of the western-occult-tradition ritual stuff Crowley himself was doing (including the enochian stuff).

Somebody with only a shallow pop-culture understanding of occult tradition is bound to associate it with fuzzy thinking & children's media. The use of alchemical metaphors in SICP indicates that the authors have at least some familiarity with the history of magick, though.

The most important figures in the western occult tradition were mathematicians (like Dee) or invented early computational or permutational devices (like Llul). Magick is very firmly bound up in this kind of mathematical thinking. On the other side, the mathematical foundations of computing come out of mathematicians who had occult justifications: Godel (and Cantor before him) was a mathematical platonist who dabbled in gematria, and his work on computability was part of the ars magna for him. (In case you're not up on the history, Turing's work on universal turing machines was an attempt to rephrase Godel's incompleteness in a way that was accessible to non-mathematicians, and his later work with Church proving the equivalence between Godel's model and lambda calculus was built upon this work. While computing machines predated this formal basis, the formal basis is pretty important -- we all learned it in college, after all!)

He's an alchemist. The original version of the illustration says salve/coagulate rather than eval/apply.

It's fantastic to hear that somebody's actually written an emulator! I dug around looking for one only a couple weeks ago, and the closest I could find was somebody's blog post from 2011 where they managed to get the ROM dump running in MESS but hadn't implemented input support.

This model underestimates the importance of unknown unknowns.

Generally speaking, the best solution is one of the solutions not yet explored (simply because it requires a juxtaposition of ideas that are distant in conventional semantic space). Both conventional curricula and just-in-time learning follow conventional paths & therefore double-down on both path dependence and intellectual monoculture.

A fairly straightforward way to break this pattern is to simply invert it: discover what your peers already know, and go out of your way to learn things that your peers don't know. If something is concretely important and your peers know it, they will explain it to you (or point you to resources, or take care of it) -- the collective understanding is more important than the individual understanding -- and so filling in the gaps in order to cover more total ground is a low-risk high-reward endevour.

Concretely, what does this mean? It means that if you are writing Javascript and C++, you ought to learn PROLOG, COBOL, and MUMPS. If you're writing webapps, you ought to study the culinary history of the ancient near east. If you're doing QA, you ought to study midcentury continental philosophy. If you're working with databases, you ought to study professional wrestling.

The short answer is that they probably wanted to be identified. After all, it's an intelligence operation, so it serves several disinfo/doublecross-related purposes simultaneously.

The -bear APTs (fancy, fuzzy, etc.) had already been associated with russian military intelligence for years, by the civillian cybersecurity community, posting evidence of that on the public internet, before the election.

(There's always the possibility that some other organization is posing as russian military intelligence & using a well-known APT to spoof their own work. But, supporting multiple sides of a conflict in a way that leaves clear evidence is standard MO for russian intelligence since the 90s -- though typically, russian intelligence will publically take credit for the ops later on.)

It's important to understand that the primary purpose was probably not to get a particular candidate elected, but instead to undermine public trust in the election apparatus. (The easiest way to do that is to take advantage of the fact -- generally known among security people but not among normies -- that the election apparatus actually is pretty insecure.) Actually influencing election results is secondary to making sure american citizens argue over whether or not they were influenced by a foreign power.

Single line shell script:

(date ; cat) > ~/.notes

If I receive an email from someone I don't know, I assume it's not just spam but a scam and delete it without opening it. However, you might still have success with a more gullible or less paranoid audience -- particularly if your product is not intended for techies.

Mass emails are cheap, so a 0.1% open rate is enough to float your business if you live off ramen & clip coupons.

I only work on interesting technical problems in my free time. Nobody's really willing to pay for open-ended research.

(Luckily, interesting technical problems in computing don't actually require resources, other than time, and their interestingness is their own reward, so it's not like I need or expect anybody to pay me to work on them.)

I worry about posting this here. We all know 80% of HN readers are amoral scam-artists -- so you're kind of driving customers.

It's pretty common to have a script post to your account on your behalf in an automated or semi-automated way, if you're a programmer. (It's pretty common to do this on twitter too, but twitter has no interest in marking bots.)

If an account has both automated and organic posts, that account is both human and robot.

Let me rephrase:

In all slavic languages, 'robot' is the base of the verb 'to work'. So, by the same means by which some people have decided to translate 'robot' as 'slave', it would be more accurate to translate it as 'worker'.

Yeah. I wanted to foreground the way that ignorance of history blurs the line between iteration & revolution.

Actual revolutionary advances are rare. We haven't had any in the tech industry since the 1970s -- when declarative, functional, object oriented, and structured procedural programming were all formally defined, asymmetric encryption was invented, the first working hypertext systems were implemented, neural nets were first used for image processing, large-scale internetworking & heterogeneous distributed computing were pioneered, and we got all of the graphical UI concepts and models that are in use in mainstream software today.

Everything since the late 1970s has been either slow iteration on 1970s ideas or limited to academic/experimental systems with limited influence.

It's not too surprising. The first of these were produced in the immediate aftermath of Star Wars' success, & the entire personal robot boom occurred during the original theatrical releases of the trilogy. Plus, a trash can on wheels is one of the easiest mobile robot designs to get working.

It translates to 'worker', & the play came out shortly before the russian revolution, so it's clear that the subtext of the term in its original use is not merely a criticism of slavery but also a marxist criticism of the exploitation of the proletariat under industrial capitalism.

(Important to note that, just like in Do Androids Dream of Electric Sheep & Blade Runner, the 'robots' in R.U.R. are not mechanical devices but instead genetically engineered synthetic humans. That helps the metaphor a great deal: rather than being a pure 'other' whose behavior might be seen as a design error, it's simply a different breed or race of humans with different heredity that makes them convenient for othering, along with some argument about hereditary traits that supposedly make them more suited to hard labor.)

theoldrobots is a great resource. I didn't cite it directly because I followed it back to primary sources in many cases, but I leaned on it heavily while writing the article. It seems to be the only site on personal robots with anywhere near the breadth and depth of information necessary for even casual research on the personal robot industry as a whole.

And the machines mentioned in the article sold thousands of units at most.

The theme of the article is that the creators of these machines made a big bet on the idea that novelty and imagination alone would carry expensive, underpowered machines to market success, and that even when those machines were actually technically impressive, those bets were wrong.

The HERO was able to stay on the market for so long only because Heath was making their real money on electronics kits. The RB5X was able to stay on the market for so long because the overhead was close to zero. Androbot & Arctec folded almost immediately, because the TOPO was a $400 RC car and the Gemini was a $9000 tech demo with no arms.

A business plan that depends upon upper middle class frivolity to the tune of thousands of dollars per family is unlikely to succeed. Everybody in the article learned that the hard way.

I didn't cover the Omnibots because I didn't want to cover anything more disappointing than the TOPO :)

As a nerdy kid, I was exposed to all this personal robot hype (particularly marketing material from Nolan Bushnell's Androbot) via pop-science library books -- all of them somehow staying in circulation 15-20 years after nearly all the companies mentioned went out of business in '85-'86. Looking for information about the machines in those half-remembered books is what led me to write the article.

I think it would be really easy to miss all of that if you weren't specifically interested in robots growing up, or if you grew out of robot books aimed at children before those books had gotten into the library system. A lot of them were probably published after the machines (aside from the HERO & RB5X) were no longer available, because the publishing pipeline is about 18 months & Androbot went from launch to bankruptcy in about two years.