That is not the hallmark of literate programming, but the hallmark bad/unhelpful code comments or docs. Like, you can also have bad/unhelpful function names or unclean and tangled implementations.
It doesn’t. Literate programming is letting the documentation, rather than the implementation, dictate the order and organization of the program.
You could theoretically write a literate program that is nothing but code, if the code is so readable that it doesn’t need explaining. The distinction is that it is “human first” over “computer first”.
To add to your excellent points: Elixir is compiled ahead of time while Ruby bytecode is generated as the code is loaded, which is probably the source of confusion in this case.
This leads to differences such as Ruby meta-programming happening at runtime, Elixir’s at compile time. The Elixir compiler (the Erlang compiler really) can also afford to do more work at compile-time which then leads to different approaches at the JIT level too.
I'll add that Ruby meta-programming has 2 pseudo-phases(at least in my mind): load time and 'true' run time. They're both technically run time, but smth like a has_many method in rails ActiveRecors runs once when the code is loaded, defines some other methods and doesn't run again while the process is running, normally.
You could also be defining methods pretty much whenever, for instance in response to user input, mutating the state of the process from that call onwards.
The former is much, much more common than the latter.
e. A blurring of the 2 is something like ActiveRecord defining field accessors dynamically once a DB connection is eatablished. You connect to the db and now your User model has email, first_name etc methods, unless you'd defined them already.
I'm guessing nothing quite like this could exist for Ecto(I vaguely know this isn't a super good comparison, Ecto is quite different from AR from what I remember).
That being said even that would still happen as part of a prod app's 'loading' phase so to speak rathet than during a request cycle.
Another difference between the two comes from Ruby having open classes, so there is no callback that says "no further changes will be made to this class". This means you need to postpone some meta-programming to certain events, like Rails telling the app has done initializing, or until something is invoked for the first time.
So you are right there are distinct phases but they are established by convention and practices. And sometimes it is different between dev and prod (lazy loading vs eager loading). Or at least it was back then. :)
> I'm guessing nothing quite like this could exist for Ecto
This is a good point because in elixir metaprogramming you can actually have some things happen at compile time. The frameworks use this for performance in a few places.
So if you had different behavior for ex and exs that would cause developer confusion.
Yeah, if you don't want the code to run when you're compiling it, don't have it do anything until some function is called.
And it would be the same as in another language if you run a program that has no side effects. For instance "python abc.py" will gladly run a abc.py that is empty or has "class ABC: pass" in it.
In Ruby, tests are the same you'd write in any other language. You test that things do what they are supposed to do, not the types of parameters or return values.
Ok but if you can't constraint the types passed to a function then the universe of objects you have to test is massive. For instance you may have a performance benchmark that checks that a certain operation runs in a certain big O -- say, you want to make sure a contains(collection, elem) functions runs in constant time. If you can't constrain the type of collection (to be some kind of Map, say) then you are left testing that all paths that call contain do so with a Map and not, say, a List. In a typed language the type system would ensure that for you.
The Atmos does not have a seconds hand. All models except two do not have minute indications.
I believe that is going to difficult measuring accuracy. You can approximate something if you compare it over a long period of time, perhaps at 12 o'clock, or as much 12 o'clock as you can tell by inspecting the hands alignment.
It is your choice. You are in charge and freelancing gives you the opportunity to bill _less_ and leave space to other important things in your life for which a regular job would compete. Family time, sports, hobbies, learning new things, etc.
This project is wonderful. Dozens of cities over the world are opening their doors to its citizens thanks to it. In Madrid, inhabitants have a direct vote on how to spend _millions_ of the city budget.
I wish the future of our society goes in this direction.
I have tried a bunch. Notion is super cool, but doesn't do tables at this moment (though they seem to be working on it). Some apps have one level of nesting only, which is not enough structure for my use case. By now I have settled on Dropbox Paper.
Also, having a WYSIWYG editor is cool, in raw Markdown links and images just do not look good for my taste (and tables, and more, compared to Dropbox Paper or Notion). The number of files for which they support syntax highlighting is small though. In particular Elixir is not in the list as of this writing.
"TeX: The Program" is a joy to read.