Ask Slashdot: Why Are We Still Writing Text-Based Code? 876
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 more simple you make it the less complex it is (Score:5, Insightful)
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.
It's been done (Score:5, Insightful)
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.
Because people write text (Score:5, Insightful)
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.
Power. (Score:1, Insightful)
Words have power. They abstract complex ideas. One word and you have an image in your head. We don't think in terms of code, we think in terms of pictures. Text abstract it.
Labview (Score:5, Insightful)
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)
Text-based books (Score:5, Insightful)
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.
Because text is the only medium that's varied enou (Score:3, Insightful)
There have been LOTS of attempts at "visual code", and they all look great when you watch the 10 minute presentation on them, but when you actually try to use them you find that they all solve a very small set of problems. Programmers in the real world need to solve a wide variety of problems, and the only medium (so far) that can handle that is text code.
It's like saying "why don't we write essays in pictograms?" You might be able to give someone directions to your house using only pictograms (and street names), but if you want to discuss why Mark Twain is brilliant, pictograms just don't cut it: you need the English (or some other) language.
if you "get coding" so well, why arent you coding? (Score:4, Insightful)
Code is meant to be read. (Score:5, Insightful)
Because the alternatives are worse (Score:5, Insightful)
Graphical languages are still programming. Syntax errors don't go away, they just manifest themselves differently. I don't think graphical languages really solve any problems, they just create new ones. That's why they haven't caught on.
The problem is not... (Score:4, Insightful)
..text vs "something-else-that-isn't-text"
The problem is complexity
Programs are getting too complex for humans to understand
We need more powerful tools to manage the complexity
And no, I don't mean another java framework
As Simple As Possible, No Simpler (Score:5, Insightful)
Most of the unnecessary parts of code are there for clarity, to make the code less cryptic. Most of the cryptic stuff is cryptic because it has been condensed. Consider iterating with a counter:
for $i in ( 1..100 )
That's about as concise as it can possibly be, and still get the job done. Most languages get a little more verbose, to add specificity and clarity:
for ( int i = 1; i <= 100; i++ )
That specifies the type of the holder (int), that it should use include i=100 as the final iteration, and it explicitly states that i should be increased by 1 each time through. That's just a tiny example, but that is how most code is. It is as simple as possible, without becoming too noise-like, but no simpler. Some langauges, like PERL, even embrace becoming noise-like in their concision.
As for doing it with pictures instead of text, we try that every five or ten years. GUI IDEs, MDA [wikipedia.org], Rational Rose [visual-paradigm.com], UML [wikipedia.org], etc (there's some overlap there, but you get the picture).
I suspect the core problem is that code is a perfect model of a machine that solves a problem. The model necessarily must be at least as complex as the solution it represents. That could be done in pictures or with text glyphs. Why are text glyphs more successful? I'm guessing it is because we are a verbal kind of animal. Our brains are better adapted to doing precise IO and storage of complex notions with text than with pictures. It's also faster to enter complex and precise notions with the 40 or 50 handy binary switches on a keyboard than with the fuzzy analog mouse. But at this point I'm just spitballing, so on to another topic:
Fuck beta. I am not the audience, I am one of the authors of this site. I am Slashdot. This is a debate community. I will leave if it becomes some bullshit IT News 'zine. And I don't think Dice has the chops to beat the existing competitors in that space.
Language is the answer to your question... (Score:5, Insightful)
...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!
Re:I think IBM is working on it (Score:2, Insightful)
Why? http://catb.org/~esr/writings/unix-koans/gui-programmer.html
Because... (Score:4, Insightful)
Because text based stuff works. All the graphical programming stuff essentially is experimental. ALL of them have major faults. Yes, there are some people who think that everything can be done in UML and then automatically have that generate code, but that requires a huge investment to learn UML (at least as much time as it takes to learn a text based language) plus the code generated is not necessarily efficient. This is a very old idea, people have been working on this for decades!
It is only recently that we've had graphical displays that I would considere good enough for the level of detail necessary. The computer monitors from 10 years ago were not high enough resolution.
And frankly there's nothing wrong with text based programming. After all we are programmers. We all learned calculus (or should have), physics (or should have), we learned all the theory (or should have), we wrote term papers using text, and so forth. So to learn a simple programing language should not be a hurdle to anyone. We're professionals, we should never be saying "this is too hard!"
Graphical user interfaces are not efficient in terms of building something up. Lots and lots of mouse movement is necessary merely to draw out a basic set of blocks and flow control but then you still need lots and lots of mouse movement to apply the correct sets of properties to each box, each line, and so forth (ie, type in variable names, set their type, make them const, place them in the correct scope, etc). Whereas text you just start typing and it is fast. That's why we still use command language interfaces instead of graphical user interfaces for most professionals, they're faster and more efficient. You may think that typing is slow and cumbersome, but I find using tools like Visio and Powerpoint to be slow and cumbersome.
Finally, how are you going to share your graphical program? Do you require everyone who will read your code to also have the same graphical code viewer, no matter what operating system they are on? Sure this may be ok if you're just doing simplistic visual basic but in the real world you can't rely on this. The practical matter is that it will get translated into a textual form just to be shared. At which point you may have well done it in text to start with. Why do we have so many programming languages? Because not everyone agrees on just one language, and of course no language is equally efficient in all problem domains. The same issue will exist in any graphical programming style; no one will agree on just one, and you'll need different variants.
Basically, text based programs are indeed simpler and more robust. Now maybe you don't like some programming languages because they're too verbose and hard to type, in which case choose a language that uses higher level constructs, and so forth.
Re:I know this one... (Score:4, Insightful)
Re: I know this one... (Score:5, Insightful)
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.
Re:The more simple you make it the less complex it (Score:5, Insightful)
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.)
That's impressive for a newbie, but it's not even on the order of magnitude of complexity as a real application. And it probably didn't have input validation and a bunch of other items that new programmers always forget.
I've got a couple programs with several ten-thousand lines of code. If you want to visualize them, you will need a very, very large sheet. And it wouldn't be more transparent.
Since the late 1970s, I've remarked that software is the only engineering discipline that still depends on prose designs.
It's also the only engineering discipline with no physical representation. So maybe, just maybe, it's a case of "the rules don't apply because it's different" ?
Re:I think IBM is working on it (Score:5, Insightful)
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.
Re:It's been done (Score:5, Insightful)
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.
Doesn't Scale (Score:5, Insightful)
I do a lot of odds and ends in Max/MSP [cycling74.com] and Reaktor [native-instruments.com] for work. Normally I do the more robust stuff in C, ObjC and Ruby.
They're "dataflow" languages, you have boxes that transform data, and you wire them together in the order you want the transformation to happen. Everything's graphical. It's designed to be easy enough that someone with no computer background could use it– a composer or synth programmer will learn it for a few days and then off they go.
I've noticed some things:
If I have something thats useful, I'll often conceptualize stuff in Max and then rewrite it in C with CoreAudio, because I know the Max code is basically a dead end for its usefulness.
Re:Because people write text (Score:4, Insightful)
You clearly haven't searched for even the most trivial of "How do I..." topics recently, have you?
Why write three quick and dirty sentence-fragments on how to do it, when you can record a 10 minute video and post it to YouTube? And I wish I meant this as hyperbole.
More seriously, I agree with you. We still code in text because no programming language will ever let me easily express "c^=0xdeadbeef" by drawing a line between two data objects. Yes, wizards have become reasonably adept at setting up the core functionality of any app not worth writing in the first place. But even when they do allow you to write a line of code such as I gave above, well... I can type that in about a tenth the time it would take me to click... drag... click... right-click... click (function) select (xor)... click (constant) type "0xdeadbeef"... whatmorondoesntaccepthexforafuckingbitwiseop??? backspace*10 "-559038737".
Re:It's been done (Score:5, Insightful)
Re:It's who we all are (Score:4, Insightful)
Text is our most efficient method of encoding language, however.
The only language-agnostic way to program is to do it directly in binary or hex. The only reason this is language agnostic is because the Arabic numerals, unlike the Latin alphabet, is ideographic.
A "visual" system where you point and drool and get code generated for you *still has to generate some code* in order to work, whether directly in binary or through some higher-level intermediary language then fed to a compiler or an interpreter. If it's done right it might be a very useful tool but it's never going to change the fact that the only thing a computer can do is perform operations on numbers and push them back and forth across the bus.
Wrong Question (Score:4, Insightful)
Re:That's still limited (Score:5, Insightful)
I say cat, you the reader know roughly what I'm talking about.
Right. A unix command utility that concatenates its inputs as its output.
I didn't have to describe a small furry 4 legged animal.
oooooooh .... riiiiiight. in all seriousness, if i saw the word cat without context in nearly any setting I'd have been right with you on a furry critter... but here on /. especially given you'd mentioned the CLI and GUI, well, my brain was primed up for the other cat.
This Ask Slashdot must be from the /. Beta Team! (Score:5, Insightful)
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?
Re:Lego Mindstorms (Score:4, Insightful)
The familiarity, and the fact that it was already being used to do the modeling.
It's much easier to find people who are well versed inMatlab / Simulink VS. coding in C, especially the PHDs who really understand dynamic process control and simulation.
We already used Simulink to do the control algorithm design and simulation, but then we had to write detailed software specs to be hand coded by the controls group (to hope we got the same results) Sending them an updated Simulink model to be linked into the production application (and being able to rapidly make changes to the production code for testing) was a much more effective use of everyone's time.
There were still only a few people who really knew how it worked, but anyone who knew Simulink could get it to do whatever they wanted without having to deal with understanding the interactions in many thousands of lines of C code.
Wrapping a PID around a PID that's already around a PID is much less error prone in Simulink, and much easier to integrate into the application
You can have thousands of lines of code generated by a 5 minute update to a Simulink diagram. Copy it, paste it, delete it, change it around 5 ways on Wednesday, all without having to worry about breaking it, or leaving something behind that will haunt you.
Testing was also much easier as the functions knew the range of their variables and the whole thing could be simulated in Simulink to verify itself.
Rephrase (Score:4, Insightful)
Please rephrase your question in the form of a picture.
Or, if you prefer, interpretive dance.
As you contemplate that task, you will learn the answer to your question.
Re:I think IBM is working on it (Score:5, Insightful)
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.
Re:Power. (Score:4, Insightful)
EEs have been designing circuits with structural complexity at least as great as any software program, using graphical tools, all along.
The most complex circuits (in ICs) are synthesized from text-based HDLs or automatically generated by software tools. Schematics are common at the board level, but that's nowhere near the complexity of even a medium-sized software program. And of course all functionality is explained through text-based documentation.
Text is better for expressing abstract concepts. Graphics are better for expressing concrete concepts. If you try to use graphics for abstract concepts, you end up adding a lot of text anyway -- flowcharts, for example.
Re:This Ask Slashdot must be from the /. Beta Team (Score:5, Insightful)
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.
Re:I think IBM is working on it (Score:5, Insightful)
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. [wikipedia.org]
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