Living in the programming world

The end of an era: goodbye, GitHub

We all knew that Microsoft would destroy GitHub. Well, I hope we all knew. I knew it too, but somehow, I thought: it doesn’t matter. Maybe they’ll add some commercial features, maybe they’ll force some integration over VSCode or Visual Studio, but anyway, I didn’t think, at the time, that they’ll be able to make something really bad about it.

This ends now.

Microsoft (I’ll not use GitHub anymore here. I’ll keep GitHub for Atom, probably, but that’s how far I’m willing to go) decided that “public repos are reusable pieces of software” regardless of license, with their “Copilot” product. Yes, people are saying that’s legal, fair trade, blah blah blah. I don’t buy it, and I believe it’s only because it’s Microsoft that they are speaking like this. Every other system that inputs <copyrighted-content> and outputs <content>, when the input and output are the same “kind” (music, painting, code, poetry) needs to be aware of the original license, and that’s final. In fact, every tool that tried to do this in the past WAS victim of copyright strikes – so why Microsoft is not? In fact, there’s public code that’s not open source on Microsoft’s servers. If they are so sure that it’s not a “derivative work”, why didn’t they train their ML with private repositories? With Microsoft’s own private code? The answer is obvious – only the fool don’t want to see.

Anyway, I’ll be removing all code from Microsoft starting now. Unfortunately, there are issues to code cooperation and other things if I decide to self-host a solution, so until Gitea allows for federated content, I’ll got with Gitlab. I’ll start with Chlorine, Clover, and similar projects like REPL-Tooling, Duck-REPLed and Vision. Then, maybe I’ll start moving things on demand (after all, all code that EXIST today was slurped by Microsoft already, so why should I bother removing the damage that already was done). So, here I’ll try to document my process:
(more…)

By Maurício Szabo, ago

The power of Pathom

Most people don’t know the power of Pathom. Most people that I know of think that Pathom is about graphs.

They are wrong.

I mean, yes, in the end you’ll have a graph, with dependencies, but that’s not the point. The point of Pathom is the ability to transform your code into a soup or attributes. It’s also probably the best usage of qualified keywords for me, if not the only one that justifies the downsides (I’ll not enter in details here – just know that having to convert from qualified keywords to unqualified multiple times is not fun at all).

The name “soup of attributes” may not be a beautiful one, but believe me – it’s incredible. The idea is quite simple – instead of trying to handle all possible conversions from multiple sources to multiple destinations, you just define which attributes can be computed in terms of others, and Pathom does the rest. As always, things are better with examples, so let’s go.

I had to work on a system that somehow had strange rules – it needed to generate a bunch of text files for different companies. Each company expected a different file name and different fields. To generate the file, we had to accumulate data that came from a payload, from an external system that we called via REST API, and also from some data we had on our database. To make things worse, some companies would expect some of the data that was returned from REST on the filename, and there were also some state changes – like, if a file was already processed, the company would send us a return file, and we had to read some content of this file, move this file to another directory, renaming the file in the process.
(more…)

By Maurício Szabo, ago

The power of finding facts about personal preferences

It is unfortunate, really, that it’s 2021, and we still try to justify our personal preferences with “facts” that simply don’t exist.

I’m really sorry if this sounds aggressive, but as someone that saw this same pattern happening again and again, I’m quite tired. As Obie told us on a great talk about programming, music students, and painting, the pallette is not the point! Programming languages, frameworks, libraries, virtual machines are pallettes, tools, to make things better. As as with anything, people will prefer water paint, or crayons, or whatever – it simply does not matter. What matters is the ability to make great tools. Imagine if we treated music the same way we do with programming languages. It’s not hard to imagine bizarre conversations like:

  • “What, you play piano? Why, how are you going to play on the streets? The streets is where you earn money, don’t you know?”
  • “Wait, why are you learning guitar? How are you going to play on an orchestra?”
  • “Ocean Drums? Why invent another percursion instrument?”

Sounds crazy, right? So, just read this tweet, and see the madness appearing. Maybe the way that Robert Martin posed the question was not the best way to convince people to try Clojure, but anyway, people jumped up on defense of their pallets, their tools, to the point it was quite tiring, really. I’ll not post who told what, and I’m not going to post the exact replies, but let’s debunk some myths:
(more…)

By Maurício Szabo, ago

Static Typing – the dangers of incomplete info

Ok, so I’m going to use this post – Making Illegal States Unrepresentable – and I’ll add my experience to it. For people that don’t know F# (or that don’t want to check all the post to see what’s the point), the idea is that he’s trying to construct a type that will only be valid if a user does at least an e-mail address or a postal contact. Then, he ends with the following type (I’m “inventing” a way to represent this type that’s close to Scala, but easier to read for people that don’t know Scala or Haskell or F#):

type Contact {
  Name: String
  AND Contact: ContactInfo
}

type ContactInfo {
  EmailOnly: EmailInfo
  OR PostOnly: PostalInfo
  OR EmailAndPost: EmailInfo with PostalInfo
}

// Types EmailInfo and PostalInfo have to be defined also

Then, he uses 13 lines to construct a ContactInfo, and another 12 to update a contact info. He ends up concluding that these complicated types are necessary because the logic is complicated. And that’s where we start to disagree.
(more…)

By Maurício Szabo, ago

My 2020 retrospective

As my therapist said: 2020 was a year that put brakes on the whole world. And yet, for me, it was one of the best years of my life by far – maybe with the exception of 2012, where lots of other wonderful things happened too.

On this year, my daughter was born. There was also the covid-19 pandemic (yeah, it’s obvious right now, but maybe some years from now someone reading this post will probably not remember that it did exist) so if you join these two things, you’ll see how worried I was. It was always my wife’s dream to be a mother, and to have me at her side on the delivery room, but because of the pandemic, this would not be possible… or would it?

At that time, I was still living in Brazil. There are laws over there for the expecting mother to have someone helping her on the birth process – and we did use these laws so the hospital would be forced to accept that I would be with her. They tried to persuade me to not do it, multiple times, until I was able to get the maternity’s director cellphone and talk to her. So, yes – I was there, saw my daughter born, and I was with my wife’s and my daughter the whole time! It was probably the most incredible, magic moment of my life: when my daughter was born, she stayed with us the whole time, dimmed lights, looking at us. Recognizing us. She kept biting my fingers (when my wife had to rest for a while), and even today (she’s 6 months now) it’s one of her most enjoyable actions: to grab my fingers and gently bite then.
(more…)

By Maurício Szabo, ago

Last hours on my country

Right now, as I’m writing this, I have about 6 bags full of (mostly) clothes, a file with different documents, a bunch of fears, and a lot of hope. Tomorrow, if everything goes well, is my last day living in Brazil.

It was a strange adventure, first by making a simple trip (well, as far as “jump on a motorcycle with my wife and travel though the country and beyond, and end up traveling 6,449km” is considered simple), then by staying a whole month on an Airbnb and trying everything, from local meetups to social projects to local culture, restaurants, food, etc, and then finally getting all the documentation to live on the country we chose: Uruguay.
(more…)

By Maurício Szabo, ago

Implementing shadow.remote API

Since version 0.8.0 of Chlorine, there’s a new way to evaluate ClojureScript code: that’s the Shadow-CLJS Remote API. It is basically a new REPL (not nREPL, no Socket REPL) over WebSockets to try to solve problems when translating other REPLs to ClojureScript. So, to understand why these problems exist, I’ll first introduce the difference between ClojureScript and Clojure.

On Clojure, you’re always inside a JVM. This means that compilation happens on the same JVM that your REPL, and your code is running. If you practice REPL-Driven Development, even your tests are running on the same JVM. In practical terms, it means that when you fire up your REPL, you already have everything ready to run code, compile code, and evaluate forms.

On ClojureScript, the compiler is written in Clojure – that means it’s running on the JVM. So, to produce Javascript code you don’t need a Javascript environment – and that’s when things become confusing, because when exactly will you run the REPL? Let’s try from another angle: if you start the REPL on compilation time, you can’t evaluate code (because there’s no Javascript generated, nor any Javascript engine running). If you start the REPL when you run the compiled code, this REPL can become unusable if you stop the Javascript environment, and also you have to coordinate lots of state and translations between formats.
(more…)

By Maurício Szabo, ago