Forgot your password?
typodupeerror
Programming Education GUI Technology

Ask Slashdot: Why Are We Still Writing Text-Based Code? 876

Posted by timothy
from the because-there-are-only-so-many-lego-in-the-world dept.
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 discussion has been archived. No new comments can be posted.

Ask Slashdot: Why Are We Still Writing Text-Based Code?

Comments Filter:
  • by Anonymous Coward on Friday February 07, 2014 @08:59PM (#46191731)

    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)

    by Misanthrope (49269) on Friday February 07, 2014 @08:59PM (#46191737)

    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.

  • by Anonymous Coward on Friday February 07, 2014 @09:01PM (#46191751)

    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)

    by Anonymous Coward on Friday February 07, 2014 @09:01PM (#46191757)

    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)

    by Anonymous Coward on Friday February 07, 2014 @09:02PM (#46191767)

    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)

    by femtobyte (710429) on Friday February 07, 2014 @09:03PM (#46191771)

    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.

  • by machineghost (622031) on Friday February 07, 2014 @09:06PM (#46191803)

    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.

  • by dagrichards (1281436) on Friday February 07, 2014 @09:07PM (#46191813)
    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.
  • by sixtysecs (3529515) on Friday February 07, 2014 @09:12PM (#46191871)
    “Programs are meant to be read by humans and only incidentally for computers to execute”. — Donald Knuth http://stackoverflow.com/quest... [stackoverflow.com] http://www.codinghorror.com/bl... [codinghorror.com] http://www.codinghorror.com/bl... [codinghorror.com]
  • by umafuckit (2980809) on Friday February 07, 2014 @09:16PM (#46191905)
    There are "visual" (non-text) languages out there and they're not very nice. A major proprietary one is LabVIEW [ni.com], which mainly used for data acquisition and instrument control (hence the name). This is what the code might look like [unm.edu]. 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.

  • by MpVpRb (1423381) on Friday February 07, 2014 @09:18PM (#46191923)

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

  • by Bob9113 (14996) on Friday February 07, 2014 @09:25PM (#46191991) Homepage

    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.

  • by necro351 (593591) on Friday February 07, 2014 @09:33PM (#46192061) Journal

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

  • by Anonymous Coward on Friday February 07, 2014 @09:35PM (#46192071)

    Why? http://catb.org/~esr/writings/unix-koans/gui-programmer.html

  • Because... (Score:4, Insightful)

    by Darinbob (1142669) on Friday February 07, 2014 @09:39PM (#46192093)

    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.

  • by hcs_$reboot (1536101) on Friday February 07, 2014 @09:42PM (#46192141)
    and the reason being probably that, in OP's mind, thanks to all new technologies like Google Maps, GPS, Siri and the like, it seems we only have to ask simple requests to obtain a nice result, that, in fact, hides complex operations made servers side.
  • by Anonymous Coward on Friday February 07, 2014 @09:58PM (#46192237)

    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.

  • by Tom (822) on Friday February 07, 2014 @09:59PM (#46192245) Homepage Journal

    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" ?

  • by lgw (121541) on Friday February 07, 2014 @10:11PM (#46192327) Journal

    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)

    by Nerdfest (867930) on Friday February 07, 2014 @10:12PM (#46192343)

    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)

    by iluvcapra (782887) on Friday February 07, 2014 @10:15PM (#46192367)

    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:

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

  • by pla (258480) on Friday February 07, 2014 @10:18PM (#46192413) Journal
    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"

    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)

    by Dunbal (464142) * on Friday February 07, 2014 @10:27PM (#46192459)
    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
  • by Arker (91948) on Friday February 07, 2014 @10:37PM (#46192513) Homepage
    Text is not precisely synonymous with language.

    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)

    by Greyfox (87712) on Friday February 07, 2014 @10:54PM (#46192631) Homepage Journal
    What you really want to ask is "Why is programming hard"? It's hard because you have to know what you want to do. Go to any random company and ask a random employee how the company does what it does. What are its products, who are its customers, what do those customers want, what tasks does the business need automated to perform more efficiently? Projects fail so frequently (What is it, about 70% of the time?) because managers and some programmers think you can just start crapping out code without considering any of these things. You want a simplified environment where you can just draw a bunch of boxes together, but even if you had such an environment (As witnessed by the testimony of the people who have replied who do) it's STILL hard because you STILL have to know what you want. Programming is not fucking magic. We can't just crap out a bunch of code that magically does everything you want. Those of us who make it look easy have spent a lot of time mastering our craft. And we're still programming in text because we've found that it's the most efficient way of doing things, most of the time.
  • by vux984 (928602) on Saturday February 08, 2014 @12:04AM (#46192963)

    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.

  • by Frobnicator (565869) on Saturday February 08, 2014 @12:05AM (#46192977) Journal

    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)

    by EETech1 (1179269) on Saturday February 08, 2014 @12:06AM (#46192985)

    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)

    by sjames (1099) on Saturday February 08, 2014 @12:49AM (#46193179) Homepage

    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.

  • by ShanghaiBill (739463) on Saturday February 08, 2014 @01:13AM (#46193267)

    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)

    by AdamHaun (43173) on Saturday February 08, 2014 @01:26AM (#46193313) Journal

    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.

  • by ShanghaiBill (739463) on Saturday February 08, 2014 @01:58AM (#46193403)

    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.

  • by JWSmythe (446288) <jwsmythe@jws[ ]he.com ['myt' in gap]> on Saturday February 08, 2014 @03:20AM (#46193653) Homepage Journal

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

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

I don't want to achieve immortality through my work. I want to achieve immortality through not dying. -- Woody Allen

Working...