Ciro Santilli @cirosantilli 37

Added ourbigbook --format-source automatic code formatting. I implemented it for the following reasons:

This also ended up having one unexpected benefit: whenever a new feature is added that deprecates an old feature, by converting the large corpus from github.com/cirosantilli/cirosantilli.github.io to the new feature I can test the new preferred feature very well.

For example, converting \x[blue cat] en masse to the new insane syntax <blue cat> found several bugs with the new insane syntax.

This seemed somewhat easy at first, so I started it as a way of procrastinating more urgent Web features (web scares me, you know), but it ended being insanely hard to implement, because there are many edge cases. Also, most bugs are not acceptable, as they would corrupt your precious source code and potentially output.

But well, it is done!

The name cirodown should not appear anywhere now, except with very few exceptions, e.g.:

I have also squatted OurBigBook on all major social media handles for near future usage, e.g.: twitter.com/ourbigbook and so on.

I was going to do this sooner or later, it was inevitable, but the timing was partly triggered due to noticing that English speakers (and likely many other nationalities) are not able to easily read/hear/pronounce "Ciro".

And do 5 big queries instead of hundreds of smaller ones.

For example, a README.ciro document that references another document saying:needs to fetch "speed-of-light" from the ID database (previously populated e.g. by preparsing light.ciro:to decide that it should display as "Speed of light" (the title rather than the ID).

Previously, I was doing a separate fetch for each \x[] as they were needed, leading to hundreds of them at different times.

Now I refactored things so that I do very few database queries, but large ones that fetch everything during parsing. And then at render time they are all ready in cache.

This will be fundamental for the live preview on the browser, where the roundtrip to server would make it impossible

Name of the clade of archaea plus eukarya proposed at: www.frontiersin.org/articles/10.3389/fmicb.2015.00717/full. Much better term than prokaryote as that is not a clade. Let's hope it catches on!

IDEs are absolutely essential for developing complex software.

The funny thing is that you don't notice this until someone shows it to you. But once you see it, there is not turning back, just like Steve Jobs customers don't know what they want quote.

Unfortunately, after the Fall of Eclipse (archive), the IDE landscape in 2019 is horrible and split between:

Programmers of the world: unite! Focus on one IDE, and make it work for all languages and all build systems. Give it all the features that Eclipse has, but none of the bugginess. Work with top project to make sure the IDE works for all top projects.

Projects of the world: support one IDE, with in-tree configuration. Complex integration is often required between the IDE and the build system, and successful projects must to that once for all developers. Either do this, or watch you complex project wither away.

Build tool maintainers: make it possible for IDEs to support your tool! E.g., implement JSON Compilation Database output so that IDEs can read the exact compiler commands from that, in order to automatically determine how files should be parsed! Or better, just use libllvm in your IDE itself as the main parser.

Ciro is evaluating some IDEs at: github.com/cirosantilli/ide-test-projects

A language that allows you to talk to and command a computer.

There is only space for two languages at most in the world: the compiled one, and the interpreted one.

For 2020 now, when you have a choice, you must go for:

Those two are languages not by any means perfect from a language design point of view, and there are likely already better alternatives, they are only chosen due to a pragmatic tradeoff between ecosystem and familiarity.

Ciro predicts that Python will become like Fortran in the future: a legacy hated by most who have moved to JavaScript long ago (which is slightly inferior, but too similar, and with too much web dominance to be replaced), but with too much dominance in certain applications like machine learning to be worth replacing, like Fortran dominates certain HPC applications. We'll see. Maybe non performance critical scripting languages are easier to replace.

C++ however is decent, and is evolving in very good directions in the 2010's, and will remain relevant in the foreseeable future.

Bash can also be used when you're lazy. But if the project goes on, you will sooner or later regret that choice.

The language syntax in itself does not matter. All that matters is how many useful libraries and tooling it has.

This is how other languages compare:

Overview of Shimano brands 2018: www.evanscycles.com/coffeestop/advice/the-complete-guide-to-shimanos-mountain-bike-groupsets-and-their-hierarchy