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.
The reason programming languages are still as they are is for a simple reason, because you can't produce something complex with something simple, I.E. the more you simplify something the less control you have of it. Can a programming language be made that is not text based? Sure, but I highly doubt you are going to get the flexibility to do a lot of things. Even assembly is still required sometimes.
This is a rhetorical question. It would be similar to ask "why do we write books or manuals when we can just record a video"
The answer is written words is how we communicate and record such communication as a civilization. Written communication is easy to modify and requires little space to store. And this is just scratching the surface, not touching things like language grammar or syntax, etc.
Because visual programming is even more awkward in almost any aspect (see Labview).It takes significantly longer to write, large projects are all but impossible. There is a reason why circuits are not designed anymore by drawing circuits (in most cases anyway)
Why are we still writing text-based books, and communicating in word-based languages? Surely, we should have some modern, advanced form of interpretive dance that would make all such things obsolete. Wait, that's a terrible idea! Text turns out to be a precise, expressive mode of communication, based on deep human-brain linguistic and logical capabilities. While "a picture is worth a thousand words" for certain applications, clear expression of logical concepts (versus vague "artistic" expression of ambiguous ideas) is still best done in words/text.
Sure, and similarly, laws should not be written down in legal language, they should be distributed in comic book form.
When all you have is a hammer, every problem starts to look like a thumb.
“Programs are meant to be read by humans and only incidentally for computers to execute”. — Donald Knuth http://stackoverflow.com/quest... http://www.codinghorror.com/bl... http://www.codinghorror.com/bl...
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/
...and I do not mean programming language, though that can help.
There is not a big gain (any gain?) to seeing a square with arrows instead of "if (a) {b} else {c}" once you get comfortable with the latter. I think you hinted at the real problem: complexity. In my experience, text is not your enemy (math proofs have been written in mostly text for millennia) but finding elegant (and therefore more readable) formulations of your algorithms/programs.
Let me expand on that. I've been hacking the Linux kernel, XNU, 'doze, POSIX user-level, games, javascript, sites, etc..., for ~15 years. In all that time there has only been one thing that has made code easier to read for me and those I work with, and that is elegant abstractions. It is actually exactly the same thing that turns a 3--4 page math proof into a 10--15 line proof (use Louisville's theorem instead of 17 pages of hard algebra to prove the fundamental theorem of algebra). Programming is all about choosing elegant abstractions that quickly and simply compose together to form short, modular programs.
You can think of every problem you want to solve as its own language, like English, or Music, or sketching techniques, or algebra. Like a game, except you have to figure out the rules. You come up with the most elegant axiomatic rules that are orthogonal and composable, and then start putting them together. You refine what you see, and keep working at it, to find a short representation. Just like as if you were trying to find a short proof. You can extend your language, or add rules to your game, by defining new procedures/functions, objects, etc... Some abstractions are so universal and repeatedly applicable they are built into your programming language (e.g., if-statements, closures, structs, types, coroutines, channels). So, every time you work on a problem/algorithm, you are defining a new language.
Usually, when defining a language or writing down rules to a game, you want to quickly and rapidly manipulate symbols, and assign abstractions to them, so composing rules can be done with an economy of symbols (and complexity). A grid of runes makes it easy to quickly mutate and futz with abstract symbols, so that works great (e.g., a terminal). If you want to try and improve on that, you have to understand the problem is not defining a "visual programming language" that is like trying to encourage kids to read the classics by coming up with a more elegant and intuitive version of English to non-literate people. The real problem is trying to find a faster/easier way to play with, manipulate, and mutate symbols. To make matters worse, whatever method you use is limited by the fact that most people read (how they de/serialize symbols into abstractions in their heads) in 2D arrays of symbols.
I hope helping to define the actual problem you are facing is helpful?
Good luck!
--"You are your own God"--
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...
As an EE I call complete bullshit on this. Other than simplistic circuits most modern electronics design is done just as software: textually. Ever heard of Verilog and VHDL? These have largely replaces schematics. You can't have a schematic for a modern complex IC. The schematic would cover a fairly large state like Florida for something like a SPARC T5 or Core i7. There are so many pathways that even labeling the lines would be problematic. The days of something like CS0 are over. VHDL supports structured naming. These days netlists for complex chips are huge.
The tools and techniques for IC design have changed to a more textual mechanism precisely because text is better at dealing with complex abstractions. Please don't tell us what EEs do if you aren't an EE.
It's been my experience over the last 25 or so years that, to the corporate apes in charge, anything they don't understand is easy.
The hard part is clearly, unambiguously describing the solution to the problem at hand. English is a crappy language for that (legalese and standardese are harder to read than code). The easy part is expressing your clear thoughts in a formal language. Seriously, if you can't get past the fact that you need a formal language, you'll never be writing non-trivial programs - you've high-centered on the easy part and haven't even gotten to the hard part.
There's one tried and true way to create a computer program to solve your problem without learning to code: hire a programmer. Even then, you'll likely discover that you lack the ability to even explain the problem clearly and unambiguously.
Socialism: a lie told by totalitarians and believed by fools.
Why are we still writing books using text (for the most part)? Doing it with pictures or other methods is frequently not clear enough even for fiction. Text is concise, or at least more-so than other methods.
</b>
Socialism: a lie told by totalitarians and believed by fools.
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.
I would like to complain that OP had to explain his concept to us in words. Why are we still using something as primitive as words - abstract collections of symbols depicting sound (of all things!)- to convey meaning. Surely in the tens of thousands of years or more that humans have had language, someone must have come up with a better way of transmitting information... oh, and fuck beta
Seven puppies were harmed during the making of this post.
If you have to understand the concepts anyways, why is text worse than a graphical set up? You can't really avoid learning syntax this way if you want to write anything actually complicated.
Also, fuck beta.
For that matter (and it really does matter), why is Slashdot still text based? I mean, my 2-year-old daughter enjoys looking at pictures on an iPad. So why not make Slashdot picutre based only, to open it up more to the masses (who often have the intellectual capacity of a 2-year-old anyway)? You could start by having 42% of visitors arbitrarily enter this new picture only mode which would have the second letter of the Greek alphabet (I love Greek!), and an embedded picutre that everyone associates with slashdot (some .cx domain or something). I'm blanking on the second step here, but I promise you, we will PROFIT!
Oh, I get it! This question for Ask Slashdot must come from the Slashdot beta team.
Now, I understand that as a Slashdot beta developer you don't know how to program. We can all see that.
Web site development is more difficult than the programs you are used to where you drag a picture of a shape onto another picture of the shape, or how when a large colored shape is presented you click on the corresponding color image.
All of that "cryptic jargon" is important to computers. Just like all that "cryptic jargon" in legal agreements is important to judges.
Since you must be on the Slashdot beta development team, I'll point out that people sometimes don't like it when you make changes. Try some of these:
* Go to the Louvre with a paintbrush and some oil paints. Attempt to fix the eyebrows on the Mona Lisa, because they have faded off. Tell me how people like your slight changes.
* Go to the Royal Academy of Arts and slightly modify DaVinci's Last Supper. Maybe stand the salt shaker back up and paint over some of the damage that was done after people cut an arch through it for a doorway, or after the WW2 bombing damage. See how well people respond.
* Pay a visit to the Sistine Chapel, that thing has lots of cracks on it. Tell me what happens after you climb up to the ceiling with your bucket off plaster to fix the cracks.
* The White House lawn looks nice, but it could be changed to allow more foot traffic. Tell me what happens when you take your backhoe up to the presidential mansion and being excavating for new footpaths.
Any change, no matter how tiny, has the potential to destroy the essence of the item. You got that, Slashdot beta team?
//TODO: Think of witty sig statement
>surviving languages use symbols representing sounds
over a billion people have a few symbols with you...
Are you referring to the Asian languages that use Chinese characters?
- Vietnamese used to be written in Chinese characters, it now uses the Latin alphabet.
- Korean replaced Chinese characters with the phonetic Hangul 500 years ago.
- Japanese has not one but two phonetic alphabets to go along with their Chinese characters. They mix all three together, and you can tell a passage is intended to be simple to understand when it will be all phonetic except the simplest of Chinese characters.
- Even China simplified the traditional characters because they were deemed too hard to learn. School children are taught new Chinese characters via pinyin, a phonetic scheme that uses Latin characters. Since they don't have a phonetic system, when they borrow foreign words then they match the foreign pronunciation with the set of Chinese characters that have the closest pronunciation. The result is a mix of characters where some have their original symbolic meaning, and others that only stand in for their pronunciation. Think "what your name means in Chinese" party trick.
- Typing Chinese characters usually means typing out the pronunciation and then selecting the character.
I think the point that symbolic characters are on the decline is very valid.
boldly going forward, 'cause we can't find reverse
What does that have to do with BETA?
It is because both BETA and "graphical coding" are abominations. The people pushing "graphical coding" are usually PHBs or other "non-programmers" (such as the submitter). I have never met a programmer that has used GC and prefers it over just writing code.
Note to submitter: Before you try to "fix" a profession, try learning enough to understand it first. The first thing you need to understand is that you are recycling a thirty year old idea, that has been tried and failed many, many times.
The art analogy is definitely wrong for Slashdot.
A better analogy is written language. For instance, I could write the sentence "Today I went to my friend's house." Or I could convey the same message graphically, but using an icon to represent myself, another icon to represent my friend, and my friend's icon could then be placed next to an icon of his house with the "ownership" relationship connecting them. Then I could draw a vector from my icon to the icon representing my friend's house, and then a small calendar could be placed on this vector with today's date, and another graphical feature added to indicate that this is all past tense.
Would the graphical representation be faster to create? Of course not. Would it be easier to understand? Only for someone that does not understand written English. The graphical representation of algorithms is no different. It is far faster to just write textual code, and it is more understandable to people that actually understand the programming language. This is why "graphical coding" is almost always proposed by people that are not programmers (such as the submitter), just like "graphical English" would only be proposed by people that don't understand written English.
I do recall some attempts at "graphical coding", where a function was an icon that you could drag into your code, and other such nonsense.
Wikipedia has a whole list of them.
Thankfully, most never really took off, except for the WYSIWYG HTML editors. I still hate it when people who make their entire WYSIWYG site, and then ask me to go make "simple" changes. Sure. 3 hours to reformat the HTML itself and strip out extraneous crap, and 5 minutes to make the change. ...like...
I don't mind charging the time to do it, but I hate doing the work. Sometimes I'm actually stunned how much crap can be shoved into code, that does absolutely nothing.
It happens in real coding too. I've found thousands of lines of unused functions, or even
Serious? Seriousness is well above my pay grade.