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.

Comments

The more simple you make it the less complex it is

[Anonymous Coward]

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

[Misanthrope]

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.

Re:It's been done

[Nerdfest]

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.

Re:It's been done

[Dunbal]

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

Because people write text

[Anonymous Coward]

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.

Labview

[Anonymous Coward]

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

[femtobyte]

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.

if you "get coding" so well, why arent you coding?

[dagrichards]

You may believe that you 'get code'. But clearly you do not. there have been more than a few attempts to make common objects flexible enough so that even you can stack them on top of each other to make applications. They are unwieldy and create poorly performing applications.

Code is meant to be read.

[sixtysecs]

“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...

Because the alternatives are worse

[umafuckit]

There are "visual" (non-text) languages out there and they're not very nice. A major proprietary one is LabVIEW, which mainly used for data acquisition and instrument control (hence the name). This is what the code might look like. Developing small applets in LabVIEW is very fast, but things get horrible as the project gets larger. LabVIEW issues include:

• Hard to comment
• Very easy to write bad code (particularly for beginners)
• Version control is awkward
• Clunky to debug because programs are hard to follow.
• Hard to modify existing code
• Coding becomes an exercise in placing the mouse in just the right places and finding the right little block.
• As a beginner you waste lots of time trivialities instead of actually learning to code.
• Hard to learn from a book or even from reading somebody else's code.
• Documentation is crappy.

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.

As Simple As Possible, No Simpler

[Bob9113]

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, Rational Rose, UML, 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...

[necro351]

...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 know this one...

[Anonymous Coward]

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

[Tom]

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

[lgw]

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.

Doesn't Scale

[iluvcapra]

I do a lot of odds and ends in Max/MSP and Reaktor 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:

• Code sharing almost never happens. You can't email a snippet of your "patch" (a program) as text, you can't post it in a text box at stackoverflow, it's almost impossible to communicate with other people about what you're working on without emailing the binary document. When you send someone a patch to look at, you're doing a lot of "look to the left of this," and "look for the red box."
• Code reuse can be difficult because boxes generally aren't typed in any way, so interfaces are difficult to verify and document.
• ... This leads the dev environments to only be as good as their templates and default libraries. People prefer Reaktor to Max not because it's easier for developing, but because it comes with a bunch of really useful default synths and sampler instruments, which people will tweak slightly.
• It's very difficult to talk about the algorithm itself, you have to spend all your time orienting yourself. If the program you're building is a simple pipeline, it's easy to see what's happening, but if you have loops and divergences it becomes very hard to understand what's going on in the abstract.
• Data types are a hack. You end up having to have different color wires that carry different things, type-tagging of binary data is routine, and you often have to do conversions because the environment runs different data connections at different levels of service. Trial and error is usually required to see if a box responds to a message in the way you want; I can write correct C without having to run the code, I would never try that in Reaktor.
• Execution order is a hack. If you connect one output to two inputs, which input will process the output first? There's conventions: In Max: the rightmost box will act first, and your graph is traversed depth-first right-to-left (this rule introduces ambiguity when dataflow is fed back). There are also boxes/modules that can make execution order explicit in various ways. (Note that in most cases we don't care about execution order, and the implicit multithreading is quite nice.)
• Doing N of anything is a pain. In Max, It's easy to build a sampler that can play one sample. It's easy to build one that can play two. It's basically impossible to build a sampler that can play N, without using the textual scripting language (ha!) to dynamically rewrite your patch based on creation arguments.

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:That's still limited

[vux984]

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!

[Frobnicator]

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:I think IBM is working on it

[ShanghaiBill]

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:This Ask Slashdot must be from the /. Beta Team

[ShanghaiBill]

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

[JWSmythe]

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...

<font color='#FFFFFF'><font color='#ff33dd'><font color='#000000'><i><span style='color:#0cd'><b><font face="Book Antiqua, Times New Roman, Times"><a href='C:\My Documents\FP98 Examples\homepage.htm'></a></font></b></span></i></font></font></font>

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

/* disabled for now, fix tomorrow. */
/* John - Feb 13, 1998 */
if (0){
...
// 500 lines later
}