The Intellectual Wilderness There is nothing more useless than doing efficiently that which should not be done at all.

2019.12.24 23:20

Erlang: A new packager and launching tool

I’ve never really liked the way that Erlang’s existing tools generally force one to accept “releases” as the One True Way to structure, build, test, launch and deploy Erlang programs. We have escript, of course, which is fantastic, but it does come with a few handicaps such as making it a somewhat cubmersome and magical process to write OTP-structured programs as scripts.

“Why do would you care about this? Isn’t Erlang what you use for writing game servers and streaming servers and web servers and… the key word being ‘server’?”

I care because I also write a lot of client-side code and Erlang provides a very smooth paradigm for writing networked GUI and CLI programs. While how to best structure those has been a bit of an exploratory art of its own since the first release of Erlang’s GUI bindings, the best way to deploy them to client systems (that is “end-user systems” — yes, the unwashed, non-technical masses) has been one of those subjects people tend to wave off because, well, nobody wants to discuss it and, “HAH! Who would write client-side Erlang without endless armies of tech support goons around the product?!?”.

Well, now we can (or at least I can).

I’ve started on a suite of tools that handles source templating for projects (GUI apps, CLI utilities, escripts, traditional OTP applications and library projects), packaging of them, distribution and resolution of the packages, building, and launching (in a “first-run means automatic deployment” paradigm) in a way that a developer familiar with other dynamic scripting languages would probably feel more at home with.

I’m still messing about with a few of the minor features (like text search for packages based on tags, a GUI application browser, an installer for Windows, and so on) but the core of it is in place for developers already.

If you’re an Erlanger or perhaps just Erlang-curious but never were quite sure how to get started with writing Erlang programs because structuring an Erlang project was always a bit of a mystery you never had time to work your way through, give it a try and please give me some feedback so I can improve the tools.

The tool itself is called ZX and the distribution service node code is called Zomp. To run the installer it all you need is an Erlang runtime somewhere in $PATH.

Link here: ZX/Zomp

2014.03.3 12:24

Source or Satire?

Filed under: Computing — Tags: , , , , , , , , , — zxq9 @ 12:24

From time to time I encounter openly discoverable code that is so wild in nature that I can’t help but wonder if the author was writing a machine function or a satirical statement.

Groovy source:

After spending a few days plowing through Java code at the outset of a new Android project I found myself checking around for practical alternatives. In the course of that search (which netted Scala, Groovy and Clojure, in descending order of easy tooling for Android) I stumbled across this gem of a source file in the Groovy codebase. At first I couldn’t really tell if this was a joke about Java’s expressiveness or a functioning bit of code, but then I realized it is actually both — all the more funny because its expressing a cumbersome optimization that will execute on the same JVM either way:

Breach: A browser as practical satire

Someone from the Erlang world was kind enough to paste a link to Breach — a browser written in node.js. Its so full of meta fail and manifests the very essence of hipster circular logic that… I can only assume it is satire in the same vein as INTERCAL.

IBM SDK for Node.js on System Z

The going question at IBM has, for the last few decades at least, not been “Is it a good idea?” but “Are people deluded enough to pay for this?” This stands in heavy contrast to the countless bouts of genius that have peppered their research and development over the last century.

But IBM is a business, after all, and we’ve all got to eat. IBM was late recognizing that the majority of programmers and other IT professionals had left the world of engineering behind for the greener pastures of pop culture and fansterish tech propaganda, and to play catch up IBM had to innovate. Actually, this is a sort of business genius: IBM realized that tech doesn’t sell as well as bullshit and buzz when it watched Motorola get steamrolled by Intel’s marketing efforts around the original 286.

Intel pitched a bad chip design to tech illiterate execs, deliberately avoiding customers’ engineering departments, and prevailed against Motorola’s vastly superior designs — brilliant, if you don’t mind being a charlatan. Fortunately, Intel has at least occasionally made up for it since then (having been the only ones serious about SSD reliability early on, for example).

IBM has gone one further. I think this must have started as a practical joke at IBM, and then someone realized “Wait! Holy shit! This could be the hipster coup of the century and get us back in the web game!” Har har har. Joke’s on… all of us.

IBM SDK for Node.js v1.1 on System Z

“Process scope variables” in Erlang

I couldn’t have written a more concise satire-by-demonstration on what sucks about bringing the Java-style OOP thinking process as mental/emotional baggage when one starts using Erlang than this short message that appeared on the Erlang-Questions mailing list one day:

> So much time spent for removing one State variable from a few function calls.

much more time will be saved when refactoring from now on.

most funs will now have signature:

-spec a(pid()) -> ok.

and most function bodies will look like:

it will be a breeze now.

Like… whoa. That just happened. And it wasn’t sarcastic.

A gloriously sarcastic response can be found here.

Powered by WordPress