Slashdot Mirror
Ask Slashdot: Why Are We Still Writing Text-Based Code?
First time accepted submitter Rasberry Jello writes "I consider myself someone who 'gets code,' but I'm not a programmer. I enjoy thinking through algorithms and writing basic scripts, but I get bogged down in more complex code. Maybe I lack patience, but really, why are we still writing text based code? Shouldn't there be a simpler, more robust way to translate an algorithm into something a computer can understand? One that's language agnostic and without all the cryptic jargon? It seems we're still only one layer of abstraction from assembly code. Why have graphical code generators that could seemingly open coding to the masses gone nowhere? At a minimum wouldn't that eliminate time dealing with syntax errors? OK Slashdot, stop my incessant questions and tell me what I'm missing." Of interest on this topic, a thoughtful look at some of the ways that visual programming is often talked about.
This view is belied by the graphical tools used to design and layout hardware and chips. Higher level languages in particular are largely based on connecting the data flow between various pre-defined blocks or objects - function libraries.
I actually built a primitive graphical Pascal pre-processor back in the late 1980s, which used the CMU SPICE circuit board layout program. Since the output of the program was text based, it could be processed into Pascal code. The model I used was that a function was a 'black box' with input and output 'pins', but also could be designed itself in a separate file.
I never actually finished it, but it was pretty workable as a programming paradigm, and opened up some new ways of looking at programs. For instance, a 3-D structure could be used to visualize formal structure (function calls, etc.) in one axis, data flow in another.
Also, the Interface Builder for the NeXT machine was more-or-less graphical, IIRC only 2-D. It made for very fast prototyping of a new user interface, and the 'functional' code could be put in later. (I saw a former schoolteacher, who had never used a computer until a few months before, demonstrate creating a basic calculator in Interface Builder in under 15 minutes. It worked, first time.)
I think the real issue is in large part a chicken-and-egg problem. Since there are no libraries of 'components' that can be easily used, it's a lot of work to build everything yourself. And since there is no well-accepted tool, nobody builds the function libraries.
Looking at this from a higher level, a complex system diagram is a visualization that could be broken down to smaller components.
In practice, I believe that the present text-based programming paradigm artificially restricts programming to a much simpler logical structure compared to those commonly accepted and used by EEs. For example, I used to say "structured programming" is essentially restricting your flow chart to what can be drawn in two dimensions with no crossing lines. That's not strictly true, but it is close. Since the late 1970s, I've remarked that software is the only engineering discipline that still depends on prose designs.
It's easier to be a result of the past, but more fun to be a cause of the future! http://www.spacefinancegroup.com/
to what the programmer of the computer programmer envisioned.
I think the story OP should learn some Lisp. Seriously. Just to grok it.
Part of the frustration I had with many programming languages is feeling I was trying to build castles with toothpicks. If I moved the wrong way or wasn't utterly careful, the structure would fall.
Maybe the OP feels the same way since he is talking about feeling a single level away from assembly.
Like the most powerful editors (emacs and beyond) requires commandline. That's just how it is. If you want fast to learn, then you absolutely want a pretty GUI and all that nonsense, but a user will hit his head on a low ceiling if he's a fast learner. Because GUIs just don't do anything but the small tasks envisioned to them. OTOH, commandline is hard to learn but a much higher ceiling.
Put another way, text is abstractions. I say cat, you the reader know roughly what I'm talking about. I didn't have to describe a small furry 4 legged animal. Now if I did a graphical representation of it, I would be limited to the parameters I gave the original cat - fur (there are furless cats like the sphinx), legs (some cats are missing legs), tails (the manx). How would a graphical representation take that into account? Through clunkiness if at all.
It's kind of like the difference between an alphabet and a logographic system like kanji.
Kanji seem like an awesome idea at first. You make a picture of the sun, and voila, you have the sun! And then a picture of the moon, and you have that idea. Moonlight? Combine kanji for moon plus kanji for light and you probably have moonlight!
Awesome right? Yeah it's just fucking great until you realize you have to start making 30 strokes for one word, and that small pics start looking like each other, and that unless you know that very specific kanji, you have no clue how to write it out. And unlike the english alphabet which has 26 letters and once you learn them and combination you can sound out most words, you have to memorize thousands of kanji and even more kanji combinations or you'll get hung up reading highschool level newspapers.
I view CLI like the alphabet and GUIs inevitably like the alphabet and kanji. One is more awesome than the other in theory but in practice...
In practice, I believe that the present text-based programming paradigm artificially restricts programming to a much simpler logical structure compared to those commonly accepted and used by EEs. For example, I used to say "structured programming" is essentially restricting your flow chart to what can be drawn in two dimensions with no crossing lines. That's not strictly true, but it is close. Since the late 1970s, I've remarked that software is the only engineering discipline that still depends on prose designs.
Funny that you should say that. For the last 20 years, the trend in Electrical Engineering is away from graphical entry and toward text based design languages. Hardly anyone designs logic by drawing gates anymore. We use languages like Verilog and VHDL, which look a whole lot like software languages. Even the analog designers make use of Verilog-A or even just Spice, all text based. When it comes down to building a circuit board or analog circuitry on a chip, there is still a manual "compile" step of drawing diagrams and polygons but that is only because the result is ultimately a three dimensional object (well, more lke 2.5D) and it is the only way to be sure you get what you intended. It is not because creating designs graphically is considered convenient.