Felix Rambles

Another step to taking back control

Insights from programming language implementation

30 November 2019 — Felix Pleşoianu

I've been making interpreters for over ten years now, and I'm finally starting to understand this stuff better. With ten of them on the site right this moment (not counting my book, or the tutorial that started it all) and two more on the way, it might just be a good time to write down a few things I've learned about this craft over the years.

For one: AST interpreters have abysmal performance. We're talking 100 times slower than the same algorithm implemented in the host language (before compiler optimizations, anyway). You're better off using direct interpretation, which is twice as fast and easier to understand.

For that matter, if you're going to implement a Lisp-like language, beware that the Tcl approach of making even control structures into ordinary procedures is a trap. Sure, in theory it's more elegant to not need any special forms in your eval function. But in practice, you end up writing lots of brittle, convoluted code to cover the various permutations, thus negating the advantage. Besides, what programmer in their right mind is going to redefine what if means in production code? Or at all, except for bragging rights?!

Life is full of special cases. Come down from your ivory tower.

That said, a little thinking goes a long way. Stack-based languages are infamous for their backward syntax. And they do have syntax, make no mistake: you can't afford to mix up the order of if, else and then! But does it have to be that way? Because even newer entries in the family, much higher level than Forth was forced to be, still sort of throw up their hands and go "whatever". And I recently proved it doesn't have to be the case, by taking inspiration from an unlikely source: Logo. Which, by the way, is full of those dreaded special cases, yet one of the friendliest ever created (unlike Perl, which is the opposite).

As a programmer, it's a good idea to know several languages. As a programming language designer? You'd better know a lot of them, big shot!

Last but not least, my recent research seems to suggest that orthogonality in programming language design might be overrated. And before you yell at me:

  • syntax and semantics have a messy relationship;
  • the most theoretically pure languages also tend to be the fussiest;
  • take a look at HTML.

I'll be around. Cheers.

Tags: programming, philosophy

Comments? Tweet  

Chronicling climate catastrophe

10 November 2019 — Felix Pleşoianu

Remember when people could still deny climate change with a relatively straight face? It wasn't really that long ago. Halfway through this decade, say in 2015, it was still mostly visible in statistics. Then news sources started reporting on just how bad things really were becoming. Sparsely at first, more and more often as time passed. And today?

Maybe you've heard that we just lived through the hottest October ever recorded, but then (articles in French) so was June and for that matter also July, not to mention the past four years. And while Indonedia has reduced forest fires, in the Amazon they were stoked on purpose. More recently, California's led to a massive blackout, and that looks likely to be just the beginning. Heck, last summer even the Arctic was burning.

Meanwhile, also in June India was melting, with the drought chasing many farmers to the city (if not driving them to suicide), not that cities weren't also struggling. Think the developed world is doing better? Turns out, Americans drill ever deeper for fresh water these days, not least because food giants are sucking the wells dry. (And yes, that happens in America as well.)

Oh, we'll have more humidity than we can handle soon, just not the kind we need. Turns out, heavy rains are getting common everywhere, while oceans are rising faster than estimated, which in turn endangers more coastal areas. Add to that the melting permafrost (article in French again; here's the same story in English), not to mention all that ice in Greenland, and we're all going to end up in literal hot water. Full of plastic, no less. Most of which won't be so easy to clean up, though people are trying.

Meanwhile, we have more CO2 in the air than in the last three million years, and methane emissions are 100x higher than we thought (an even more dangerous gas). You'd think people would be at least trying to slow down, but no, we keep emitting more crap.

Still expecting a miracle?

Tags: climate, disaster, links

Comments? Tweet  

GtkDialog and missed chances

06 November 2019 — Felix Pleşoianu

After rediscovering Puppy Linux earlier this autumn, I got the chance to re-evaluate a number of technologies I had run into before and forgotten about. One of them is BaCon, a.k.a. the Basic Converter, that I already used successfully for half a dozen game ports and a little utility, with more to come. Another is GtkDialog.

Wait, what's GtkDialog? You can think of it as a powerful alternative to Xdialog, but it's really much more. Thanks to a markup language that resembles XML (but apparently isn't), you can tell it to make any kind of GUI, even with a menubar, and it will reply with everything the user entered when they press OK. That's not where GtkDialog shines though; among other things, you can make buttons run some shell command then refresh another widget, which itself reads from the shell:

<window title="Hello, GtkDialog!">
 <vbox>
  <entry>
   <variable>OUTPUT</variable>
   <input>cat /tmp/gtk-date</input>
  </entry>
  <hbox>
   <button>
    <label>Refresh</label>
    <input file stock="gtk-refresh"></input>
    <action>date > /tmp/gtk-date</action>
    <action>refresh:OUTPUT</action>
   </button>
   <button>
    <label>Quit</label>
    <input file stock="gtk-quit"></input>
    <action>EXIT:OUTPUT</action>
   </button>
  </hbox>
 </vbox>
</window>

Feed this to GtkDialog, e.g. via the --filename or --stdin options, and you've got yourself a graphical front-end to a command-line utility that was never meant to have one.

So why have you never heard of this little wonder?

Read more...

Tags: Linux, programming

Comments? Tweet  

Dijsktra is dead, Basic is alive

23 October 2019 — Felix Pleşoianu

A recent conversation in the Pygame server on Discord brought up the infamous quote by Edsger W. Dijsktra. You know the one:

It is practically impossible to teach good programming to students that have had a prior exposure to BASIC: as potential programmers they are mentally mutilated beyond hope of regeneration.

Which only made me aware of how Dijsktra has been dead for 17 years, and here I am having a blast making games in Basic. Not just modern dialects, either, but also the line-number kind he was railing against, ostensibly because of all those hated GO TO statements.

Speaking of which, Dijsktra was wrong.

How come? You just try making a couple pages of line-number code work without careful planning, never mind more. If anything, it's structured programming that lets you make a mess. You sort of go back and forth over the program, adding a little here and there, never having to stop and factor it out into functions, or group variable declarations in a way that makes sense. Unless you learn the discipline of doing it anyway.

However, I suspect that's not what Dijsktra actually hated about Basic. My bet is the old grump was simply jealous that his students were having fun with it, and hated using a Serious Programming Language like Pascal. Of course they did. Brian Kernighan wrote an entire book about the reasons Pascal was unsuitable for real-world use (at the time, anyway), but the root cause was that Pascal was designed to support a very particular style of teaching computer science. One that assumed students were mentally challenged subhumans whom the teacher had to whip into shape with his Superior Intellect, that revealed him and him alone the One True Way of doing things.

Compare that with the freewheeling exuberance of shell script and C, both also derived from good old ALGOL. Structured programming has nothing to do with it.

Sure enough, even with the imminent demise of a Basic programming community, many others remain, and continue to create wonderful things in many different dialects. What do we rememeber old grumps for? How they tried to stop everyone from having fun.

How's that for a legacy.

Tags: programming, philosophy

Comments? Tweet  

Even more Puppy Linux nonsense

26 September 2019 — Felix Pleşoianu

So, as of this week, I've been using Puppy Linux 8.0 full time. It's hardly ideal, but the only reasonable upgrade path for me right now. And as promised last time, there's still more to unpack.

For one thing, it turns out that much of the reason why the system felt sluggish was Compton. What's Compton? A compositor as it turned out. Which does nothing except add shadows to the windows and menus... while using a noticeable amount of CPU. It also seems to leak memory, so after several hours of continuous operation it starts thrashing, which is how I found the problem. And could it be? Yep... after disabling the compositor, the freezing desktop bug also vanished. Well, until next boot, when the damned thing auto-started again despite my disabling it. When it returned for a second time, I removed it from the base OS image altogether, at which point it finally stayed out.

Hey, programmers: an OS that doesn't obey the person at the keyboard is broken, and potentially dangerous.

Anyway, even without it, Thunderbird still thrashes horribly just starting up, while LibreOffice takes way too long to do the same. Downgrading to 5.4.3 (from the previous edition of Puppy) helped, but only a little. In desperation, I also tried OpenOffice, which is much smaller but also unusably slow. And there's nothing at all between them and the much more primitive AbiWord.

Well, "primitive". It turns out the information on the Puppy Linux wiki is badly out of date. Contrary to what it says, AbiWord 3.0.1 proved perfectly able to open a 123-page ODT file, while preserving most of the formatting. Only the table of contents looked different, though page numbers were still correct, and trying to follow the internal links did nothing. (Gnumeric seems to work fine too.)

But none of that is the operating system's fault. To its credit, Puppy was at least very stable through all this, remaining up even when I gave Opera more than it could chew by accident. Closing the offending app is hard when you're low on RAM, but Puppy somehow managed anyway. Not unlike during installation in fact.

Let's see, what else? I like the DeaDBeeF music player. It might even be able to supplant Audacity for my limited needs. As for video, after trying out the various available options and finding most of them barely functional if at all, I ended up right back at good old VLC. This is why everyone uses it, folks: it gets the job done.

Which is my verdict on Puppy Linux after several more days: it gets the job done, dammit! It's weird, full of quirks and even a few bugs, but stays put, works as advertised, and allowed me to move forward at my own pace, with my limited means. When that's more than I can say about big names, you know IT needs a shakedown.

Tags: Linux, software, review

Comments? Tweet  

Puppy Linux Redux

23 September 2019 — Felix Pleşoianu

Nearly two weeks ago, I wrote about my experiences trying Puppy Linux again for the first time in way too many years. It proved much more useful than expected, and right now it's the most widely deployed operating system in my household (on par with the Android devices), at three installations. Let me tell you how that happened.

But first, a couple of clarifications:

  • I failed to get the Broadcom wi-fi adapter working after all. Oh well.
  • There is, in fact, a tool to fetch and set up SFS bundles automatically, called sfsget, though in the 32-bit edition it lists just a couple of essentials.

Anyway, for my second attempt I picked the same edition, and an even more limited machine: my original Asus Eee PC 701 netbook. It has the same 512M of RAM, but only a 900MHz Atom CPU, and a 4GB (not a typo!) SSD for storage. Can't exactly afford setting any of that aside for a swap partition, which made the install process almost run out of memory. But it worked, and let's just say solid state drives plus compressed filesystems make for speedy loading. X11 on the other hand ruins the boot time. (Also, there's no way the poor machine will run a modern browser, so Dillo will have to do.) And you know what? With two distros installed, I still have three quarters of the drive free. Another success!

Now for the big test: Bringing my work computer to 2019, or almost. It's a rather beefier machine, with a dual-core Atom running at 1.6GHz, and 2GB of RAM. Too bad the 64-bit edition pretty much nullifies the advantage. Oh well, at least the HDD no longer sounds like it's dying all the time, and restarting the window manager is almost instant. Something I had to do quite often at first, both for config changes and another odd bug: after moving the main tray to the top of the screen, the application menu would often freeze while browsing through it, taking along the entire desktop. The mouse cursor would still move, but nothing else. Luckily, I can press F12 to bring up the pop-up version, pick Exit, and restart JWM.

Otherwise, LibreOffice 6.1.4 barely starts, and Thunderbird 60.0.1 is even slower! Good thing the operating system uses SysV Init and a lightweight C library (Musl), otherwise it would be unusable. Opera (58) is sluggish, too, but that's because individual tabs are swapped to disk when out of focus. Guess it will have to become my default browser, with PaleMoon only for development.

The things I have to think of in order to keep an older PC alive nowadays.

As of this writing, I still haven't tried to do all my usual work, but the essentials are there. Keeping in touch with everyone was the biggest issue, and that was easily taken care of. Might come back with a part three to wrap it up.

Tags: Linux, software, review

Comments? Tweet  

Meeting an old friend again: Puppy Linux

11 September 2019 — Felix Pleşoianu

The last time I used Puppy Linux for any length of time must have been 15 years ago, or almost. Much has changed in computing since. In 2018, on my first attempt to revive a laptop almost as old, the ole' pupper didn't have 32-bit support anymore. I walked past, thinking they had fallen into the trap of planned obsolescence like so many others. But Devuan Linux, my choice at the time, didn't work out for a number of reasons, and when I decided to try again this autumn, neither did Debian 10, which even in text mode makes the poor machine run hot enough to worry me. After seriously considering NetBSD, and rejecting it (not for the first time), a second look at the Puppy website revealed those ever more elusive 32-bit editions were now available for all the official, actively maintained versions. I grabbed the latest one: 8.0, codenamed Bionic Pup. Not the best choice in retrospect, given the target hardware.

Speaking of which, this is a single-core Celeron M running at 1.6GHz, with 512M of RAM and a SiS 630 video adapter whose driver was retired from X.org at some point. You'd be surprised how well it can (still) run modern Linux if a sane init system is used. In fact Puppy boots faster on it than the much older distribution on the newer, beefier machine I'm using to write these lines. The first-boot setup wizard is comprehensive, even allowing the screen resolution to be picked from a list, and installation is dead simple, taking up a directory on any available partition. Since it doesn't disturb what is already there, dual boot was an easy choice.

Puppy is such a friendly animal, bundled with a surprising number of apps for its tiny size, and more graphical setup utilities than Mageia. Newcomers can probably get away with doing like I did: grab the latest version, boot from the live CD (yes, CD!) and follow the prompts. Linux experts might want to skim the wiki and forum first, to learn about the things Puppy does in its own way. Like how each edition is slightly different, as members of the community express themselves. Or how you can trust an older version, as the base is self-contained and rock-solid while packages still get updates simply because people care. Bigger additions can take the form of filesystem overlays, that are more robust than packages but must be retrieved manually, which takes a bit of poking around.

That was where the hardware showed its age, in fact, as LibreOffice 5.4.3 barely started. Maybe if I had remembered to close the browser first. Oh well. If anything, the surprise was how well everything else worked. Also how good it all looks. (Better than the 64-bit edition in my opinion.) I did run into a bug where the desktop sometimes freezes, but switching to another virtual console then back to X fixes it. Might be my ancient, oddball hardware, or lack of RAM.

As of this writing, the one thing left to try is installing the firmware for my Broadcom wi-fi adapter. Wish me luck!

Tags: Linux, software, review

Comments? Tweet  

Age of Opinions

23 August 2019 — Felix Pleşoianu

You know why operating systems suck?

Try to discuss operating systems with anyone, the result is always a flame war.

You know why programming languages suck?

Try to discuss programming languages at all, the only result is a flame war.

You know why text editors suck?

Try to have a serious discussion about them... yep, you've guessed it.

Repead ad nauseam. About file formats. IM protocols. Hardware architectures.

We live in a day and age when trying to discuss the relative merits and failings of anything only results in everyone YELLING at you. Because their favorite [insert noun] is perfect and above any criticism. (Unless they happen to hate it, then it's the devil and can't possibly have any redeeming qualities at all, ever.) This is especially true of proprietary products for some reason. What, haven't you heard? Open source is strictly a matter of abstract morality with no bearing on practical matters like code quality or interoperable standards. Yes, people still believe that in 2019, and it's scary.

Worse, in recent decades we've gradually developed a culture where it's perfectly all right to have an opinion. The less founded, the better. But you just try to bring up facts. Reasonings. Any kind of proper arguments. People will, wait for it, YELL at you. Reason tends to clash with comfortable lies, you see. And people would rather have comfort than a grasp on reality, that would allow them to do something about their problems.

Taking action makes people responsible, you see. Worse, having knowledge to act upon and refusing to act also makes people responsible. And people fear responsibility more than death. Often literally.

But boo-hoo, everything sucks! Why can't anyone seem to make things better?

We tried. And you YELLED at us. Now sleep in the bed you've made.

Tags: technology, culture, philosophy

Comments? Tweet  

Who mistakes fiction for reality?

15 August 2019 — Felix Pleşoianu

It seems to be repost season around here. This time it's an article written seven and a half years ago, on 10 March 2012 (coincidentally, one year before My Opera closed down). I'm bringing it back now because it's referenced from another place that I'd forgotten about, but also because it somehow continues to be highly relevant after all this time. Doubly so as yet another mass shooting in the US of A is being blamed on videogames, even after multiple scientific studies have failed to spot any hint of a correlation. Think we'll ever be rid of this pernicious myth?

In the mean time, I wrote more about the way violence is misunderstood in western society. Game developers, you see, don't understand violence any better than the general public does. And violence in games (like in all fiction) is a statement, often of the political variety. It sends a message when you put a marine with an assault rifle in there to shoot at whomever the latest Hollywood blockbuster decided to paint as the bad guy of the month. You may not be causing violence, but you're contributing to the discourse, like it or not. Be aware of what you're saying.

Otherwise, the text holds up surprisingly well. People continue to grow more disconnected from the physical side of things, less understanding of each other's abilities and limitations. A growing movement has been pushing disability awareness, but outside of that? The assumption that all able-bodied people can do the same things in the same way still dominates, and it ruins lives. Doesn't help that we're obsessed with "fairness", by which we mean, "don't hand anyone a torn rag unless they've worked hard for it to prove worthy".

I'm veering off-topic by now. My point remains: a lot of people have little life experience, therefore a tenuous grip on reality, and that makes them easy to sway by fictional depictions that anyone who's done a thing or two can easily recognize as made up. So it's not that media have become more realistic in recent decades... but that life is increasingly experienced only through media.

Results are of course worryingly similar. Enjoy the original text... if you can.

Read more...

Tags: media, society, philosophy

Comments? Tweet  

When scripting languages shrink

11 August 2019 — Felix Pleşoianu

Javascript, Python, Ruby: these are the popular dynamic languages in 2019. Naturally, people want to use them not just for app development but also to script software written in C or the like. Problem is, the official implementations of all these languages have grown rather large (even Tcl isn't small anymore), and that makes them tricky to use for such a purpose. Only Lua has stayed as lean as always, but no matter how good it is, having a choice is always the better idea.

Intreprid programmers have set out to correct this situation however, and nowadays we can enjoy tiny alternative scripting engines for several of these languages.

Duktape is a JS interpreter consisting of one C file and its header. It can be used as such, or customized to include or omit certain features. By default it builds to an executable around 200-300K in size (I seem to have deleted my copy in the mean time). The official website lists a number of reputable projects that use it, and half a dozen alternatives!

MicroPython is an interpreter for the eponymous language designed to run directly on single-board computers, but also on popular operating systems, and even web browsers. It aims to be largely compatible at the language level, though the standard library sports many differences, for obvious reasons.

Jim Tcl is a surprisingly complete Tcl implementation, including a couple of extensions not even the official interpreter supports. It also has a compatibility layer to cover what differences exist, and enjoys a good reputation.

TinyScheme is no less than the scripting engine used in GIMP! It can be easily built to a stand-alone executable 170K in size, and claims to implement a good chunk of R5RS, the last version of the language that cared about minimalism. Hasn't been updated since 2013 unfortunately.

As you've probably noticed, I only played with a couple of the above, briefly. What all of them have in common is being implemented in C; native scripting engines for other compiled languages are much less common, except in the Java and C# world. Honorable mentions for a few others:

  • LIL, another miniature Tcl-like;
  • MuJS, another small JS that even has a DOS port;
  • MRuby might be interesting to fans of that language.

There are of course many others, for original and/or less known languages, but you don't need to go entirely off the beaten path to keep your software small and light on dependencies. So give a chance to one of the above next time.

Tags: programming, links

Comments? Tweet