It's possible to make (via polyglot JS/HTML files[1]) apps that offer both a command-line interface that can be invoked with NodeJS (or other JS-ish runtime) or can be opened in the browser (via double-click, the browser's File Open dialog, or by just typing the file path into the location bar) if the right version of NodeJS isn't available (or for people who just don't want to give carte blanche to run outside the safety of the browser sandbox to programs downloaded from the internet, given the poor track record of NPM-based program creators/maintainers to stay on top of their dependencies).
A ton more programs, especially one-shot programs that operate on a single batch input (e.g. a directory of files) and then generate some output—like a ZIP copy of the files for your static site—should offer this but unfortunately don't. At best they'll put out an Electron app for cross-platform compatibility, but it doesn't sidestep the problem of granting overbroad capabilities to NPM modules (or the massive memory footprint). Then, in this case, there's Observable Desktop, which as a Mac-only app, falls short even of that mark.
Isn't the idea to write notes? I think constantly running a script to generate a static webpage would drive me insane. Isn't the whole point of a computational notebook to have some kind of integrated GUI?
have you taken a look at what the CLI is for? like you mentioned, it's pretty much just a build step! but there are some runtime things basked that are interesting [0]. i just have a watcher listening to file changes to trigger a rebuild. i have no need for real-time queries so just having the current state at build works for my purposes.
if you must know, the product i work on is primarily a data lake. we have our own query language -> i have a fork of the CLI w added support for parsing custom cells. i don't know of any alternatives that give me a notebook so easily!
> running a script to generate a static webpage would drive me insane
possibly web-brained take but i don't mind it much. builds are instant for me, network latency is the only thing i find myself waiting around on.
> Isn't the whole point of a computational notebook to have some kind of integrated GUI
well yea, pretty sure the entire point of the desktop app is to show what you can build atop the new api! this preview is meant to expand the capability of observable within your own custom web app. the original framework was too close to some of the frustrations you mentioned, so they're trying to make it more amorphous :)
I guess my point was that I don't really want my first interaction with a thing I'm casually curious about to be me building a custom web app on top of it. By making their GUI app Apple-only, they have lost my casual interest. I'm not sure what they gained by making that compromise.
Exactly. This is the exact stack I envision to be the future in that space. The work of Scott Logic is awesome (and the company looks really nice as well! People and values)
Unpopular opinion given all the craze around Elixir these days. I find the syntax extremely verbose and hard to read compared to e.g. Python. I was told great things about it by engineers I really respect. But each time I start reading Elixir code bases to get a good look at what an actual Elixir project looks like, I find the code hard to read and understand. Is it just me?
I was a python main before I started using elixir and I had similar thoughts, but after becoming more familiar with it, I actually think elixir is far less verbose than python.
They’re different enough languages that it’s really difficult to just open up an elixir codebase and try to read it. Elixir, like ruby, has a lot of syntactic sugar that just won’t make sense if you approach it with a Python mindset. Elixir is also functional, which can be a pretty big mind bender.
It’s really a language that you need to start from the basics and go through the tutorials to learn the basic syntax, operators, etc and write your own small programs. If you’re like me, you’ll just end up discouraged if you expect to be able to learn Elixir just by reading existing code.
I’ve been writing Elixir professionally for ~10 years at this point. I find it to be extremely easy to read, but that’s because side effects by and large don’t exist, and when they do they are very obvious. Ive written quite a lot of Ruby, JS, Swift, Obj-C, and Java during my career and Elixir is miles ahead of those for readability.
With that said, I do think because the syntax being familiar for Pythonistas and Rubyists that there’s an assumption it works like those languages and runtimes. It does not. It’s a functional language, in a purely functional VM, and that causes a lot of grief to newcomers. There are many assumptions folks bring with them that don’t hold. I think you have to take a step back when you come to a functional language with an OOP background otherwise it’ll be painful.
I’d encourage you to just write it for a while and avoid things like GenServers. Get a feel for just writing functional (pun?) code. Id also suggest to avoid reading code by people new to Elixir as it’s often weird, or irregular, because they lack the experience to write things idiomatically; relying too much on OOP principles.
As an example, in Ruby you strive to write functions less than six lines (in general)— in Elixir this can be an antipattern. Because breaking up the function will unnecessarily abstract and muddle what’s going on. That in large part is driven by the fact there are no side effects; I can see everything that is going on. Whereas with Ruby side effects and meta programming are prolific, making the code extremely dense. Writing a method that’s 20-30 lines in Ruby almost guarantees it’s violating the single responsibility principle.
The one thing that did trip me up when starting elixir, that I now love, was shadowing variables. It makes things look like they’re being mutated but they absolutely are not. It’s just reusing the same name, not the same value.
1. The syntax is significantly different than what one may be used to. Fair enough.
2. The paradigm itself is different and thus requires you to learn way of structuring your code in some pretty fundamental ways. This is a much bigger deal than one may initially give it credit for. For example, pattern matching. The mere possibility of defining multiple versions of the same functions based on the number and kind of arguments completely changes how one writes functions.
Instead of:
function hello(x) {
if (x == 2) {
// do x
} else {
// do y
}
}
We can write:
def hello(2) do
# do x
end
def hello(_) do
# do y
end
This was very disruptive to my brain at first as I was not used to reading code in this manner. My brain said "find function, read definition" but it had to learn "find function with proper arity and arguments, read definition". It's hard to put into words, but this made understanding Elixir code feel more difficult at first. However, once I did sink my teeth in , start to maneuver around code bases, and write my own modules it is hard for me to "unsee it" and go back to anything else. I love it! I think the most mind-blowing moment was when I started to pull back the covers in Phoenix and discovered that the framework wasn't some magical black box of FancilyNamedProviders but was just a collection of functions that I could actually read my way through quite simply. I never had to stop and say "wait what did that FacadeOfGoodness do again" but just traced simple functions.
Having worked a bit in Ruby, Python, and Elixir I think a lot of the difficulty comes from the minor differences. There aren't any objects or classes so the structure is naturally different and there is a tendency to have a lot of small functions so it must be read differently. If you're seeing tons of deeply nested Enum.map type calls, that's probably just bad code.
I think its worth spending more time in it. I've been working on an MMO in Elixir and I find myself coming back to rework/expand earlier subsystems and expecting to dread understanding WTF is going on but that has not been the case at all! Regardless of what knowledge I had of Elixir at the time I wrote the module - I can quickly pick up the chain of thought I had when I first wrote it. The code usually boils down to a combination of atoms (symbols), pattern matching on atoms, tuples, return values, and some sort of enumeration using Enum.map or Enum.reduce to produce an output. There's no other fancy tricks beyond that. And regardless if the data changes from list of tuples, to a map, or a set, the Enumeration logic doesn't change.
Maybe you forgot how long it took to learn to read & understand the code of the programming languages you're familiar with. Elixir is so different from languages you might know there's a learning curve.
No, it's the same for everyone: unfamiliar things seem "wrong" until you internalize them.
Try working in Elixir for half a year - you'll see that the syntax you now find verbose is that way for a bunch of reasons, and you'll find that you have no problems at all reading Elixir code, including in big projects.
The problem is that confronting the unfamiliar doesn't feel nice for most people and that you can't really speed up the process. On the flip side, though, half a year of weekends is not that long of a time or significant an investment. Especially since you'll get quite a few generally helpful skills out of it (working with actors, for example).
Tbh, I find well written Elixir to be easier to read than Python. But that's mostly down to functional vs imperative which is subjective/cultural. The same code using higher order functions and pipes that feels much simpler to me would likely be unpalatable to most Go programmer I know, and maybe a lot of Python programmers too (tbf, I can't stand the vast majority of Go code I have seen either).
Part of the verbosity is because Elixir is kind of a simple language (if you disregard the OTP stuff) and doesn't have a lot of sugar - ultimately it's just functions. Whatever else sugar is there is to nudge you towards a somewhat opinionated aesthete. In this specific regard, it's not unlike Go or Smalltalk (even if in any other way they are very different otherwise). I think the stylistic variance in how different people write Elixir is pretty low compared to how people write Perl/PHP/Ruby/Python, which is probably why reading difficulty quickly goes down with some familiarity.
Other part of verbosity is probably because culturally Elixir is kind of explicit. For example Phoenix is very convention heavy, but it's still low on framework magic. It's cool that Elixir (and Julia) has macros and that's good for library and framework authors to contain verbosity without sacrificing much of the explicitness. But as an application developer I very rarely need to reach for them either? Perhaps that's due to simplicity of language and synergy between data structure and standard library.
Though based on usage there are probably some areas where I would have preferred more sugar. For example, you just end up doing a lot of deconstructing/pattern-matching Maps. Every time I do `%{var1: var1, var2: var2} = map` I wonder if it would really be bad to have `{var1, var2} = map` like Javascript? It's not a very big deal though.
Also not to be a naysayer, there is a chance that the good feeling people have about Elixir is because they basically use it in the problem domain where the language and the runtime (and Actor Model) is an exceptionally good fit for. I mean web and network stuff is already large part of what people do, so that's not much of a con? Nevertheless would I pick Elixir for my next GUI or CLI program? I doubt it.
Elixir ecosystem is in turn dwarfed by dozens of other languages. It is still extremely niche in the big scheme of things. I can't personally recommend pursuing Gleam for any serious work on those grounds, but my risk aversion and sensitivity to hiring pools is on the very conservative end.
It's an autonomous glucose control machine for hospitals! Commonly referred to as an artificial pancreas, but it just controls sugar, not the hundreds of other things the pancreas does
