Living in the programming world

Lazuli, beyond Ruby: Python, JavaScript, and Elixir

It’s been a while since I’ve been working on Lazuli – the editor plug-in for Pulsar (and probably VSCode in the near future) where I try to bring the Clojure REPL experience – that is, running code inside your editor and printing the result inside your editor, without having to copy-paste between two different tabs – to other languages.

If you didn’t read the previous post, the TL;DR; is: Lazuli is basically “Chlorine, but for more languages than Clojure”. Ruby was the first target, for two reasons – first, because I decided to go back to the Ruby/Rails stack; and second, because it’s probably one of the easiest languages to implement that on.

Since then, I’ve added support for Python, and I’ve been experimenting with JavaScript and Elixir. Each of them ended up being its own can of worms, and I think it’s worth writing down what I found – because some of the “obvious” solutions turn out not to work at all.
(more…)

By Maurício Szabo, ago

The “Code Organization Problem”

Recently someone asked me how I organize my Rails apps. That question came unexpectedly, and I probably did a poor job explaining what I do – this is essentially something that can span multiple hours of discussion, and probably will bring lots of disagreements. So I decided to make a post, and hopefully this might help other people (and to be fair, this is not only valid for Ruby but for any language, really).

First things first, if you I am working in a project with multiple people, I will try to keep the project’s defaults; if the project already have specific organizations (like “app/services” or “app/presenters”) I will follow them; Rails is probably one of the best experiences I have ever seen in collaborating with other teams, and eroding this might bring down the biggest benefit of the framework. But considering I don’t have an already existing structure, or if I need to create some new ones, I will try to bring some personal rules:
(more…)

By Maurício Szabo, ago

AI agents, Haskell, and the stubbornness of developers

Recently, I found an article about a member of the Haskell Foundation – who was moving his company away from Haskell. The company built a hardware product with Haskell, and they were moving away reluctantly.

I’m not going to repeat the whole thing here (you can read it yourself, but the TL;DR; is: the Haskell compiler and tooling ecosystem was too slow, and that became a bottleneck now that the LLM agent writing the code is so fast.

Now, let’s be clear: I don’t want to start a holy war about “static versus dynamic typing”, so I’m not going to do that. I’m not going to discuss if the merits of static typing are overrated or not, and I’m not going to discuss if dynamic languages are more or less flexible. This was discussed over and over again – and nobody knows the result. And for me, that in-determination is also a result.

What I am going to talk about is the stubbornness of software developers. It’s something that’s been bothering me for a couple of years now, and it still bothers me today. Looking at this article was no different.
(more…)

By Maurício Szabo, ago

When everything becomes relative to AI

I have to be honest: I feel I’m taking crazy pills recently.

There were a growing number of posts, in the past, praising AI for coding; then, it started to grow, and grow, and now, on LinkedIn, almost all the posts that come to me are about AI and coding, how good they are, how the “game has changed”, etc, etc, etc.

But here’s the catch: every bad practice that we fought against, over and over, for literal decades is now being praised because “AI is doing it”.

Every. Little. Thing.

From the most obvious to the less, against all good judgment, against academic research that shows that AI usage decreases contribution between coworkers, or that they make programmers slower while they think they are faster, that the code quality is lower, or that it makes people work longer hours, it seems that all rules are off when it comes to AI.
(more…)

By Maurício Szabo, ago

I have to be honest: I feel I’m taking crazy pills recently.

There were a growing number of posts, in the past, praising AI for coding; then, it started to grow, and grow, and now, on LinkedIn, almost all the posts that come to me are about AI and coding, how good they are, how the “game has changed”, etc, etc, etc.

But here’s the catch: every bad practice that we fought against, over and over, for literal decades is now being praised because “AI is doing it”.

Every. Little. Thing.

From the most obvious to the less, against all good judgment, against academic research that shows that AI usage decreases contribution between coworkers, or that they make programmers slower while they think they are faster, that the code quality is lower, or that it makes people work longer hours, it seems that all rules are off when it comes to AI.
(more…)

By Maurício Szabo, ago

The “Jankiest” way of writing Ruby gems

Recently I wrote about a Jank, the programming language that is able to bring Cojure to the native world using LLVM. I also mentioned that Jank is not yet ready for production usage – and that is just true; it still have many bugs that prevent us to use it for more complex problems, and maybe even some simple ones.

That doesn’t mean we can’t try it, and see how bright the future might be.

At my last post I ended up showing in an example of a Ruby code. Later, after many problems trying to make something more complex, I finally was able to hack up some solution that bypasses some of the bugs that Jank still have.

And let me tell you, even in the pre-alpha stage that the language is, I can already see some very interesting things – the most important one being the “interactive development” of the native extension – or if you want to use the Ruby terms, monkey patching native methods.
(more…)

By Maurício Szabo, ago

Calling Jank from C

For those that don’t know, Jank is a Clojure implementation but instead of targeting Java, it targets LLVM (Low-Level Virtual Machine). That means, Jank compiles to native code, and interops directly with C++.

Jank already have ways to call C++, but I wanted to do the opposite – to call Jank’s code from C. The reason might not be obvious, so here is an why: writing libraries.

Not all things need to be “stand-alone executables”. One example is libraries for Node, for Ruby, or Python. These languages are amazing on the levels of abstraction they support, and it’s easy to interact directly with code and their runtime (in Node, using Devtools, in Ruby, using something like pry or Lazuli, my own plug-in). They are also quite slow, and in some cases, we might need to call some native API that these languages don’t support. So what now? The canonical way is to write some extension in C or C++; now we have to manually manipulate memory and deal with safety issues (and before people say something about it “not being that hard”, it is. Most of CVEs happen because of manual memory manipulation in C – every cast, every printf, every strcpy can cause ACE and/or privilege escalation issues). They are also not interactive so if you’re trying to easily hack some solution, you need to write the code, compile, make a shared library, use the library via the Ruby/Node/Python code, see if it does the thing you want, repeat.

It’s tedious. Maybe with Jank we can speed up this process?
(more…)

By Maurício Szabo, ago

Linux, Wayland, and NVidia.

For some time, I’ve been trying to run my Linux under Wayland. It’s… always complicated. VERY complicated.

I have what people call the “unholy trinity” – Wayland, NVidia GPU (in a laptop to make things worse), and I use an Electron app (Pulsar). Pulsar is my main editor, so it’s basically “the reason I use a computer most of the time” really.

So it was a good surprise when I found out that things work… except…

Gimp.

And Darktable.

These flickered like crazy. And because they are image editors, this flickering is insane – it makes editing things essentially impossible (imagine you’re adjusting brightness and the screen is flickering between darker and lighter, and then stops… in the wrong frame, meaning you have no idea if it’s correct or not). So I tried to track the problem, and I finally have a solution (hopefully). This post will give the results, but the TL;DR; is – update your Linux (Ubuntu 24.04 is the MINIMUM version that you need), update your KDE to at least 6.2 (or use some recent desktop env with good wayland support), don’t use the Open Kernel NVidia driver, and update your Xwayland to at least version 24.0.
(more…)

By Maurício Szabo, ago

Exposing Clojure to Ruby and other languages – Java objects in C

In the first post of this series we decided to compile a Clojure library to a native shared library (with the GraalVM native-image command) and we used “isolates” so that a “global variable” in Clojure (and Java) would appear as if they’re “local” in Ruby. Then on the second post of the series we decided to make things local, and instead of “making a resolver then storing it in a global variable” we decided to “make a resolver and return it to Ruby”, and to abstract the nature of “callbacks” we used a CFunctionPointer in the Java side, and we sent the “block” from Ruby as an “opaque object” in Java, using GraalVM’s VoidPointer object.

Now, we need to do the opposite – we need to return a “resolver” to Ruby, and then we need to make a “List of Resolvers” in Ruby-side, and send it to Clojure-side somehow. These Clojure/Java objects (a Resolver, and a List of Resolvers) will also be “opaque objects” in C (meaning – we’ll receive them as void*, because they can’t be represented in C-land, nor in Ruby-land), but only in C – in Java-land (and Clojure, by definition) they’ll need to retain their types. The object GraalVM provides for this task is an ObjectHandle.

We’ll also fix a lot of memory leaks, so let’s move on!
(more…)

By Maurício Szabo, ago