One of the pleasures in life is mentoring another developer, particularly when the other developer is smart and motivated to learn. This article, on populating a tree from a collection of paths, was the result of some weekend prep work and is a good case study on refactoring. By going through the process myself and documenting it, I was able to present the problem in general terms, and the person I was mentoring did the heavy mental lifting with only occasional guidance on my part. This worked because I was prepared — had I not done this prep work, I would have taken away from my mentee’s experience to actually solving the problem himself.
I’ve posted a new article on Code Project, explaining Merkle trees and providing an interactive demo of how audit and consistency proofs work. Read all about it!
Move aside IDE’s (Integrated Developer Environment) – it’s time for the new kid on the block, the Integrated Developer Experience!
Ok, so the acronym is already taken (Internet Data Exchange, Indonesia Stock Exchange, and probably others) but I’m co-opting it for how to talk about FlowSharpCode. I’m actually surprised “Integrated Developer Experience” isn’t used somewhere already. Maybe my google-fu is not up to snuff right now.
I’ve added some select DRAKON shapes for creating flowcharts. The Python code in the lower right editor is generated from the flowchart, and the output from the run is shown on the left.
PyLint is also now integrated into FlowSharpCode’s PythonCompilerService. This really improves the development process as many syntactical errors are detected before even running the code.
Also, the code generator creates an execution tree which independent of the language syntax, which means that support for other languages is easily added. Now granted, the code itself in each of the DRAKON shapes is Python code, but I have some ideas of how to make that code agnostic as well.
I was recently asked (paraphrasing) what parts of the work of software engineering do I find “juicy” so I came up with this diagram. Any software engineering task involves both developers (if only me), customers (might be a client), and the processes of design and implementation.
The “external” blue lines are where the customer potentially interacts with the developers, the output of the design, and the implementation phase (you can probably imagine how Agile fits in this.) The “internal” red lines are where the developers interact with the each other and the design and implementation phases.
From a certain perspective, the left side represents the “process” and the right side represents the “results.” Process and results should be balanced – developers may discover they require training in new skills, teams adjust based on where the team is in the process, etc. The process creates results which the developer and customer team review.
The process – results flow iterates with each result. The earlier results are produced, the better for everyone because this is where “education” occurs, for example, the developers learn more about the customer’s requirements, the customer may refine their requirements (or change them!) Both the developers and the customers learn things during iterations which in turn create adjustments in the process.
The list of items within the boxes is basically just all the stuff that I find “juicy” – the more of those items that get checked off for a project, the more excited I typically find myself regarding working on the project.
Article posted on Code Project here.
Classical flowcharting is definitely obsolete, however, in my opinion, a visual way of programming that supports both low-level and higher-level expression of concepts is a path to reduce the translation effort required to take human meaning and convert it into machine meaning. It also seems to me that such an approach can become a viable mechanism for an AI to actually write original programs, using building blocks that humans (or the AI) has previously written and most importantly, for us humans to visual whatever it is that the AI creates in a way that is comprehensible to us humans. With virtual reality, we should be able to create programs in a 3 dimensions, and even watch another programmer (or AI) create / modify existing programs.
First generation languages (1GL) were closely tied to the hardware, requiring the human operator to physically manipulate toggle switches to enter in the machine language instructions directly.
Second generation languages (2GL) can be loosely categorized as assembly languages.
Third generation languages (3GL) abstracted assembly language into a more human readable syntax.
Fourth generation languages (4GL) are distinguished from 3GH in that they are typically further abstracted from the underlying hardware.
Fifth generation languages (5GL), which abstracts the language itself such that it is based on “”solving problems using constraints given to the program, rather than using an algorithm written by a programmer.”
What will a 6GL look like?
In my opinion, it will look a lot like FlowSharpCode in which programs are written by piecing together the building blocks of smaller pieces of code (“behaviors”) using very visual tools, either a 2D canvas or a 3D virtual surface.
And while we’re at it, a 7GL?
Some may argue that a 6GL will be an AI, but again in my opinion, an AI that truly succeeds at “writing” an original program will do so by building from smaller behaviors. Expecting an AI to produce “code” in the languages that exist today is, well, a cute but absurd thought. A successful AI most likely will utilize some kind of “visualization” (whatever that looks like to an AI) for manifesting its “imagination” into concrete behaviors. And most likely, whatever visualization system the AI uses will most likely be able to be mapped onto a 3D or 4D (including time dimension) surface for us to peruse.