Digital Design Desires

Response to: http://jonbho.net/2012/01/24/i-want-to-fix-programming/

Developing software is fundamentally a learning process; As developers, we direct the majority of our efforts towards exploring & learning the problem domain and the space of possible solutions. In comparison to this, the act of transcribing that understanding to a formal machine-readable representation ("source code") is rather less significant. 


Notwithstanding this, the learning process itself is intimately involved with the manipulation of formal representations and the interaction of these with the environment. The formal language (and associated tools) that we use helps us not only to formally specify a set of possible solutions to the problem; but also helps to guide us in our search for those solutions and to build up our knowledge and understanding of the problem domain and of our proposed solution. 


Importantly, the tools that we use help us to understand the implications of the formal statements that we have already made in our exploration.


This is really about the software development process as a whole, and how the specifics of the language support that process. The output of the software that we create, test results, debugger output, static analysis etc.. all help us to understand the problem domain and the current state of our search for a solution. 


The languages that we use do need to support these tools better than they currently do, (especially static analysis, IMHO) but the focus of the (many) discussions on the language itself and it's syntax is somewhat misleading, I think. 


I would rather the effort be spent on extending and improving the toolchains surrounding languages that already exist and are popular. I want continuous testing, style checking, static analysis and fuzz testing to be ready "out of the box" and enabled by default; from the get-go, I want my IDE/compiler/interpreter (with default settings) to refuse to build/run my code unless the style is spot-on, the test coverage 100% and the static analysis gives the thumbs-up. 


If that means I must constrain the way that I develop software, so be it. 


I agree with the original post: it would be nice for a program to consist only of invariants and test-cases, with the algorithm generated automagically. I suspect that, feasibly, the developer will still need to provide some guidance in the choice of algorithm, but I see no reason why we could not have our IDEs/text-editors provide continuous feedback when the statements that we type violate some constraints that we have previously specified, or cause some test-case to fail. 


This would have been unthinkable a few short years ago, but the computational power at our disposal right now is immense: enough to make us shift our concept of what is possible.

They tried to give me a database, but I said, NoSQL, No NoSQL, No No No-oo-oo.

I am starting (reluctantly) to come to the conclusion that SQL & NoSQL databases are the wrong tools for the tasks that I want to undertake: For a colourful but ultimately misleading metaphor: They give me a hammer when I want a screwdriver. The databases that my (limited) experience encompasses (MySQL, Oracle, MongoDB) all offer a slew of features that I neither use nor need. Furthermore, the subset of features that I *do* need is probably better packaged as a set of libraries than as a separate application. For example, I want to manipulate large quantities of data, stored in RAM, possibly spread across multiple machines, possibly operated on by processes operating concurrently or in parallel. I would like to be able to plug together the distribution/replication/sharding of data & tasks, the fault-tolerance, zeroconfig style ease-of-administration, even (maybe) some indexing capabilities, but in such a way that will let me choose when I want each feature.

Spaces over tabs: A rationale

A wider range of people will read from a document than write to it.
A document formatted with spaces (instead of tabs) will look the same to all readers.
A document formatted with tabs will look different depending on the reader's tab settings.
In a corporate environment, it is easier to enforce uniformity in the settings of the text editors of the group of people who can write to the documents than of the (larger) group who can read from them.

If, like me, you use your spatial awareness to navigate source documents, and as a consequence, really like things to be vertically aligned (Guido, why do you hate us so?), viewing a tab-indented document with the wrong tab size set is very disconcerting.

So, for these reasons you should choose spaces over tabs, and set a uniform indent size. (4 seems to be the most commonly accepted convention)