Felix Rambles

Another step to taking back control

Programming languages are not a given

14 February 2019 — Felix Pleşoianu

Having just brought a project to a good stopping point, and wanting to rest a little before diving into the next one, no matter how impatient I am, it occurs to me that this blog needs a little love. By pure coincidence, it's Valentine's Day. And because I happen to be in love with the craft of programming, it seems like a good idea to write down a bunch of thoughts that went through my mind a lot recently.

Most programming language research for at least the past decade seems to happen in the rarefied heights of type theory. Hardly anyone can be bothered to spare a thought for the syntax and API of languages programmers have to use in real-world conditions. Never mind the ease of implementing compilers and interpreters that someone will have to, you know, maintain. And so we're stuck with variations on the hoary old C syntax. Even when a daring computer scientist comes along to bring us something like Lua, people balk and go right back to their familiar punctuation soup.

(Speaking of which: don't you dare mock Perl programmers. They at least know to be wary of "line noise" code, and actively try to avoid it. Whereas C code often resembles APL in production.)

I've been interested in programming language implementation for ten years now, though I could never read more than half of SICP even after repeated attempts, and never progressed past interpreters and transpilers. These efforts culminated in a 2016 book, and more recently a 2K-word article, itself the culmination of many attempts, some successful, some failed. You can see the latest results for yourselves. Let me just point out a few things.

We need to think more and deeply about our most important tools. Not just packaging, build and deployment systems: those wouldn't have anything to work with if it wasn't for interpreters and compilers with which to make software in the first place. And communities of practice are lacking. There is an esoteric language wiki and a concatenative language wiki; the Tclers Wiki and the Portland Pattern Repository also have much on (types of) programming languages. All that is good.

However I couldn't seem to find a community of practice for Lisp-like languages, even though it's one of the most numerous family on Earth. Let alone for the more general category of homoiconic languages, or prefix-notation languages. There used to be one for Basic dialects, but it shut down, as that particular family has been dying out.

More importantly, with all the people out there who would benefit from knowing how to program but are afraid of it because reasons, I'd like to see a deliberate community of practice for friendly languages that don't look like programming. Purely declarative languages would help a lot here, but those crashed and burned along with Prolog. There are some visual languages, but they're big systems (and that's a problem, see above), fiddly to work with and give people the wrong idea.

Either way, please spend some time looking into the issue. You could end up doing everyone a big service.

Tags: programming, philosophy

Comments? Tweet  

Accepting contributions to open source projects

05 January 2019 — Felix Pleşoianu

Hopefully this doesn't count as subtweeting. A chat conversation I just had caused me to go on a big rant, and to me that's usually a sign it's time for a proper blog post. In this case, about accepting contributions to open source projects.

To be brief: with open source projects, people use up their precious spare time, that they're not getting back, to make a contribution. They can be clumsy. They can be wrong. They're still almost certainly doing it in earnest. The code they submit might be not be how you'd do it. It might have bugs or even be completely broken. Doesn't matter. Be nice! If you have plans to accept it at all, work with the contributor to make their submission acceptable. Even if contributions are closed, kindly explain why.

It's disappointing enough to be told off in the nicest way. They won't offer again, and you've lost a potential contributor for good. I made that mistake. Now all I can do is weep.

Years ago a very enthusiastic college student sent me an extensive patch that wasn't even usable as it was. If memory serves, the code was outright broken. I rolled up my sleeves and made it work. The app was that much better for it. People noticed, too. He was apparently well-known in that particular community. The goodwill earned that way lasted me a long time.

Did it take extra work on my part? Of course. Was it worth more than the kid's? Never! That piece of my app wouldn't exist but for him spurring me on.

More recently someone offered to help me who has a competing product of their own. They went out of their way to help a competitor. And came back with a counter-proposal when the first one didn't work out for me. That's how much effort people are willing to put in when they love what they do. Taking the trouble to accept it was the least I could do. Now there are two applications with that particular capability. The world is richer for it. Everybody won.

Even the most competent surgeon needs assistants willing to work with them, if they are to operate at all. We programmers... are a dime a dozen. And people are fed up with us as it is.

Tags: programming, culture

Comments? Tweet  

Unit testing and code clarity

19 October 2018 — Felix Pleşoianu

I don't usually think much about testing. It's just a normal part of programming. Lately, however, I've been playing with a new language, that has unit testing built not just into the standard library (like, say, Python) but the language itself! And the compiler supports code coverage too, for good measure.

It's incredibly fun, writing tests for code you haven't even finished yet, having them pass, and seeing the percent of coverage increasing. And that's a trap.

Because, you see, unit testing isn't your goal. Useful, working software is your goal. Preferably written in such a way that other people can read and change it.

(As as aside, code clarity means more than short functions and correct indentation. I've seen plenty of code, usually in C, that was small, neat, elegant... and you couldn't figure out how it did anything. Talk about missing the whole point.)

Unit testing is just another tool in the toolbox. Used at the right place and time, it can do an excellent job. Shoehorned in for the sake of ticking a checkbox, it will just get in the way. And don't even get me started about writing code to satisfy the tests as opposed to, you know, the end-user.

Nobody cares what tools a carpenter uses if the furniture they make is ugly, heavy, and requires climbing carefully over the nightstand to get in bed.

That said, I did actually use TDD exactly once. It was for a library of largely independent functions, the requirements were simple, and my tests were mostly there to document usage. That's another good case for tests, by the way, and in fact the D compiler also supports it directly. Making sure your example code runs, and runs correctly, can save you from a lot of embarrassment down the road.

Just focus on delivering already, before you forget why you were writing all those tests in the first place.

Tags: programming, philosophy

Comments? Tweet  

Programmers, disconnected

12 October 2018 — Felix Pleşoianu

When academics examine videogames, they'll often note how much developers thereof seem to live in an echo chamber, hardly aware of any media outside of their chosen profession. If they read at all, it's the same kind of escapist fantasy that games are already derived from, itself highly derivative more often than not. No wonder the results are twice disconnected from any chance at cultural relevancy. And that wouldn't be a problem if the same developers wouldn't all but demand to be deemed culturally relevant.

(Exceptions exist, of course. Personal games and walking simulators have taken off big time in recent years. Sure enough, nobody quite knows what to make of them.)

This morning, I was pointing out how open source is inherently derivative. In the mean time, I figured out why. You know how programmers have a reputation for being nerds. It's hard not to, in a profession that often starts in one's bedroom, during high school or even earlier. Which in turn allows people to skip certain rites of passage, whose forgotten importance was teaching people to be social. And open source programmers are derided as big-time nerds even among other programmers. We're the nerdiest nerds who ever nerded, as a friend would say.

(Exceptions exist there, too, as another friend pointed out. And if nothing else, some programmers come to this profession from other fields, bringing with them knowledge of different people with different needs. There's software to help coordinate disaster relief efforts, for example, something a business would never invest in.)

For the most part, however, open source programmers are twice disconnected from the analog world. How else? For the longest time, they've been busy playing catch-up. And in their hurry to reach parity with commercial software, so they can command the same respect, they forgot to check whether the products they imitated were still serving a real purpose, or had long been reduced to solutions in search of problems, only good to create more jobs for consultants.

Look. Programming can be playful. Programming can be art. It doesn't all have to be utilitarian and pragmatic. But when most of what we do seems to cause more problems than it solves, it's time to take a step back and figure out what the hell we're doing.

Tags: programming, philosophy

Comments? Tweet  

Sherlock Holmes the programmer

06 October 2018 — Felix Pleşoianu

A recent discussion about programming languages reminded me of a story not often told. Namely how I was turned off from learning C#. We were considering it as a replacement for Java because it was much better integrated in Windows, which would have allowed my employer at the time (a web agency) to expand into desktop software with an attractive line-up that required fewer explanations.

So I sat down and figured out the basics. The way Microsoft had chosen to "fix Java" was quirky at best, but C# did have some welcome features added back in. And one of them just happened to be a good fit for our very first application.

My one team-mate on this project balked. "What the hell is this? I have no clue what you're doing here."

It was a delegate. A goddamn delegate. A core feature of C#, and one of its major selling points at the time. (C++ didn't get lambdas until 2011; this was years earlier.) But my colleague seemed to have taken a shortcut: instead of properly learning the language, he was using the official IDE as a glorified Visual Basic, filling in the blanks with the simplest possible code to get his mouse-designed forms working at all...

Look, we were always in a hurry. Everyone is, in an industry where people are always expected to deliver outright miracles yesterday, for peanuts. But you'd think a seasoned web developer would already be familiar with the basic concept of a first-class function from, ya'know, Javascript, which had them from the very first version in, like, 1995.

Not my colleague. He was a very pragmatic person, you see. Always pointing out he didn't really enjoy programming, but only saw it as means to an end. Guess he had better things to think about, too, like a wife and kids. So he'd only bother to learn the absolute minimum he could get away with.

Sherlock Holmes, too, would purge from his mind all knowledge that didn't help his detective work, such as the fact that Earth orbits the sun.

So how do you suppose he dealt with crime that spanned timezones?

Tags: programming, education

Comments? Tweet  

Ramblings about Java

12 September 2018 — Felix Pleşoianu

So, the other day me and a bunch of other people were discussing programming languages on Discord. We happen to have a very knowledgeable person in that group, who pointed us at an epic rant they wrote some three years ago (it seems) on why Java is bad for you. Having some experience with the language myself, that resonated with me.

One place where I disagree with Mr. Mallett: the thought of prototyping software in Java is terrifying to me. Spending hours thinking how to formulate something in hundreds of lines of code just to throw it out? In Python, I spend that time thinking what to formulate, exactly. The code is often a one-liner. No, seriously. Java, with its endless chains of public static void eeny meeny miny moe... is anthithetical to experimentation.

Also, is it a surprise that Java is slower than C++? It's running in a virtual machine, FFS! Sure, it uses JIT compilation to make native code... for parts of your program... after noticing certain patterns. It works great for specific things, such as running the same script repeatedly in a simple interpreter. But take it out of its comfort zone, and you might just as well code in Lua. The same thing happens with Javascript, which can rival native code in highly contrived applications written by the same people who made the VM and compiler. Gee, thanks. And yes, I was naive too once.

Moving on, if you think Java programmers are ignorant, try PHP programmers. I once had to teach a former colleague that when a script keeps running out of memory, it just might be from too many database queries with not a call to mysql_free_result. Surprise, dear young programmers! Your computers do not, in fact, have unlimited resources, and the garbage collector can't take care of everything. And speaking of PHP, that's another terrible language for beginners, because while it's easy to pick up it also teaches you nothing about the hardware that will struggle to run your code, while encouraging terrible coding practices, regarding security in particular.

Oh by the way: I'm pretty sure interfaces in Java were meant to enforce type discipline. Like Pascal before it, it's a language designed to protect people from themselves by leaving them handcuffed in the path of a flash flood. Which is exactly why teachers love it: many teachers, you see, think their students are mentally challenged subhumans who can't possibly be allowed to do their own thing.

Except, of course, in Java you can easily just declare everything as an Object and make the language dynamically typed in essence.

I'd better stop before this gets too long. Go read the original rant.

Tags: programming, education

Comments? Tweet