Visual Programming Perhaps Inevitable
Even if I've been working on a visual programming editor I've thought it wouldn't be easily accepted by the public as anything else but a mere parlour trick. But there are hints that the transition into visual programming could be an inevitable progress. Something that we eventually have to do.
Although most programming still happens in plain text, there are faint signs it might change. In some ways we've done the text format less useful, and we've got problems related to parsing. Besides things still seem to converge on lisp at times, even if the only unique thing left in lisp is it's homoiconicity. Syntax tends to trade homoiconicity to readability, so it'd seem only way to get both would require to make syntax less important for readability.
Eclipse is a programming environment for java. It is a bloated piece of lard with an exciting twist. The java programming language is obesily verbose, so from a necessity the refactoring tools in eclipse are really sophisticated. Eclipse produces 10 times more code than what you type into it! These things are:
- Obnoxiously long import statements
- Class or method definitions
- Superfluous comments, type declarations, keywords and semantics.
I thought Lisp is unreadable, but java is easily less readable than that. Eclipse allows you to produce the kind of code diarrhea that is necessary to be productive in java. Therefore there are tools that 'correct' the code as you type it in. Of course it's not enough that you can produce it. You need to be able to maintain it too.
Eclipse has gotten to the point that it doesn't really matter whether the source code is well-structured or readable. With the refactoring tools you can work on the kind of code that'd take unfeasibly long time to modify by a plain text editor. Obviously, it is also capable of producing such code.
What tells Eclipse and Visual Programming apart is that eclipse is still showing the source code, instead of presenting anything easier to read.
Lint tools do kind of code analysis, with the intent to flag suspicious and incorrect use of language or syntax. To do this they have to parse the source code.
On python, linting most likely has most use when you plug it into an editor. The user finds out about syntax errors, unused variables and other obvious issues in her code that would lead to crash before she gets to try it out.
I'm not using lint tools myself, but I see these tools are kind of pointing to the direction that your computer could do much more for code than just evaluate it. In parsed languages the readability is introduced in the file format so it gets on the way of source code related tools.
Experiences with CSV and json
Comma Separated Values are an old, portable format for spreadsheets. Sometimes it is preferable over JSON, particularly when one needs to interact with spreadsheet data and software. There's not a general standard for CSV files, and sometimes there are issues with text encoding schemes. CSV can be something else than UTF-8 and \n -separated rows. It's still quite a favorable format sometimes.
These formats and the style in which they're used, share resemblance with lisp's literal constructs:
'(beta romeo (5 2))
Since lisp is just lists, the program can use it as a data interchange format. Though it is somewhat unfavorable compared to json, because there are various syntax specifications for lisp. Lisp authors love parentheses but all lisps do not use the same syntax. There are variations in notation that matter in the use of the syntax as a data interchange.
At the time when software designers find things such as json valuable, 'code-as-data' would likely be valuable concept too. It emphasizes on data driven software. I suspect that to be important larger the software grows. On data driven software the interchange format such as json can contain things that control significant parts of the program. The readability of such interchange format matters a lot, but at the same time it needs to be a lot like lisp.