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.
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.
Try Lego Mindstorms and see whether you find it quicker or slower. It's easy to make something simple but once the algorithm gets complicated it is not much easier to decipher than text code, and no faster in my experience. As soon as you want to get serious with the system, you will wish it had a low level system that lets you lay it out in text instead of images.
This is partly the reason why surviving languages use symbols representing sounds rather than images as the Egyptians used. It's faster to write, and possibly faster to read.
Do it yourself, because no one else will do it yourself. [beta blockade 10-17 Feb]
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.
I think the /. folks think it's an early April Fools day. Not write code using text? That's like saying, write a book with pictures. Sure it can be done, but it doesn't apply to all books.
Maybe beta is an early April Fools joke too.
Well, Grasshopper, or Unschooled Acolyte, or whatever your title of choice may be...
You did not hear this from me.
But most developers belong to the Church of Pain and we pride ourselves on our arcane talents, strange cryptic mumblings and most of all, the rewards due the High Priesthood to which we strive to belong.
Let me put it bluntly. Some of this very complicated logic is complicated because it's very complicated. And pretty little tools would do both the complexity and us injustice, as high priests or priests-in-training of these magical codes.
One day we will embrace simple graphical tools. But only when we grow bored and decide to move on to higher pursuits of symbolic reasoning; then and not a moment before will we leave you to play in the heretofore unimaginable sandbox of graphical programming tools. Or maybe we'll just design some special programs that can program on our behalf instead, and you can blurt out a few human-friendly (shiver) incantations, and watch them interpret and build your most likely imprecise instructions into most likely unworkable derivative codes. Or you can just take up LOGO like they told you to when you were but a school child in the... normal classes.
Does that answer your impertinent question?
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.
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.
One practical example that I know of is Simulink, which can be used to generate code from diagrams. I did some testing years ago on Simulink-generated source code, and the code itself was awful looking but always worked correctly. Not a lot of fun to test when you had to dig into it, though. Also, testing seemed superfluous after never finding any bugs in it. All the bugs we ever found were in the original Simulink diagrams that the humans had drawn.
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.
Does APL suffice?
And why should you change if what you had worked great. I'm not against change, just as long as it is change for the better. If they came out with some new snazzy looking way to write code, but everyone said it sucks...but the old way worked just fine...then freaking stick with the old way. Unless you just don't care about actually making writing code better. Now who in their right mind would want to change something just to make it worse?
Doctors destroy health, lawyers destroy justice, universities destroy knowledge, religion destroys spirituality
“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...
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.
soylentnews.org
..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
There have been a number of attempts at making coding easy enough that non engineering types will be able to conceive their requirements in software then communicate these through a tool, usually in a visual manner and turns this into functional software. This has come in many different forms over the years, Powerbuilder, FoxPro, Scratch, BPEL, etc...
The fundamental flaw is one of the software development industry, especially when it comes to line of business applications. Analysts writing requirements have been and always have been an inefficient and flawed model as most requirements documents are woefully incomplete and tend to not capture the true breadth of necessary functionality that ends up existing in resultant software. Analysts are business oriented people and they will think about the features and functionality that are most valuable and tend to miss or not waste time on what are deemed as low value or low risk items. Savvy technical folks have needed to pick up the slack and fill in the gaps with non-functional requirements (Architecture) or even understand the business better than the analysts themselves for quality software for the business to even be realized.
I have seen this song and dance enough. True story, IBM sales reps take some executives to a hockey game, show them a good time, tell them about an awesome product that will empower their (cheap) analysts to visualize their software needs so that you don't need as many (expensive) arrogant software engineers always telling you no and being a huge bummer by bringing up pesky "facts" like priorities and time. So management buys Process Server, snake oil doesn't do it justice, without consulting anybody remotely technical. Time passes, and analysts struggle to be effective with it because it forces them to consider details and fringe cases. Software engineers end up showing them how to use it, at which point it just becomes easier for the software engineer to just do the work instead of holding hands and babying the analysts all day. Now your company is straddled with a sub par product that performs terribly, that developers hate using, that analysts couldn't figure out and that saved the company no money.
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/
So-called "visual programming", which is what you're wanting, is great for relatively simple tasks where you're just stringing together pre-defined blocks of functionality. Where you're getting bogged down is exactly where visual programming breaks down: when you have to start precisely describing complex new functionality that didn't exist before and that interacts with other functionality in complex ways. It breaks down because of what it is: a way of simplifying things by reducing the vocabulary involved. It's fine as long as you stick to things within the vocabulary, but the moment you hit the vast array of things outside that vocabulary you hit a brick wall. It's like "simplfying" English by removing all verb tenses except simple past, present and future. It sounds great, until you ask yourself "OK, now how do I say that this action might take place in the future or it might not and I don't know which?". You can't, because in your simplification you've removed the very words you need. That may be appropriate for an elementary-school-level English class where the kids are still learning the basics, but it's not going to be sufficient for writing a doctoral thesis.
Kind of a weird example but RpgMaker is a tool that lets non-programmers create their own RPG games. While there is a 'text based code' (ruby) layer a non-programmer can simply ignore it and either use modules other people have written or confine their implementation to the built in functionality.
Now look at the complexity involved in the application itself to enable the non-programmer to create their game. Dialog boxes galore, hundreds of options, great gobs of text fields, select lists, radio buttons. It's just overflowing with UI. And making an RPG game, while certainly complex, is a domain limited activity. You can't use RpgMaker to make a RDBMS system, or a web framework, or a FPS game.
The explosion of UI complexity to solve the general case -- enable the non-programmer to write any sort of program visually-- is stupendously high. WIth visual tools you'll always be limited by your UI, and what the UI allows you to do. Also think of scale, we can manage software projects with text code up to very high volumes (it's not super easy, but it's doable and proven). Chromium has something like 7.25 million lines of code. I shudder to think how that would translate into some visual programming tool.
I'm not sure how well it would scale
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.
Stop-Prism.org: Opt Out of Surveillance
All other potential "interfaces" lack expressiveness. Just compare a commandline to a GUI. The GUI is very limited, can only do what the designers envisioned and that is it. The commandline allows you to do everything possible.
So, no, we are not "still" using text. We are using the best interface that exists and that is unlikely to change.
Most ACs are not even worth the keystrokes to insult them. Be generically insulted by this and ignored otherwise.
...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"--
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.
Actually you can't tell your car to start by turning a key. Turning the key starts a complex series of interactions between the fuel pump, fuel-injection and air intake systems, ignition system and starter motor to get the engine turning over and then to manage disengaging the starter motor and switching from battery to alternator power once the motor's running until you let the key go from Start back to Run. You can ignore all that and talk only in terms of the key being turned if all you want to do is drive the car, but if you need to say diagnose why the car won't start or figure out why it's running rough and has no power you need to delve into the complexity behind just turning the key. You can no longer ignore it and abstract it away. That's the key: not whether it's code or a mechanical system, but the degree of abstraction involved. Most programming languages are seen as complex because they dive below the level of "start the car" and work at the level of "OK, how exactly do I design the drivetrain of the starter motor so it'll rotate the engine crankshaft until the crankshaft starts turning faster than the starter motor is, then automatically and instantly disengage so the engine won't strip the starter motor by trying to turn it faster than it's safe to?" (and that's just one small part of what's needed to make turning the key start the car, and not even the most complicated part).
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.
Slashdot, fix the reply notifications... You won't get away with it...
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...
I used to write articles for magazines as a full-time job. When I first started using the outliner MORE, I found that the task of writing became much, much easier: I would outline the article, then fill in text for each outline item. When I was finished, I would then export the text and there was my article. It let me design the articles top-down, just as a EE designs a circuit top-down. Moreover, as the article would develop, I could shift things around very easily without having to do massive cut-and-paste exercises.
Software design? I do that top-down mostly. I design the top level with functions, then fill in the functions. Lather, rinse, repeat as many times as you need to. The result is a piece of software that is highly maintainable.
One of my biggest complaints about "graphical" programming is that you can't have much on the display -- you end up paging *more* than with a text-based system. It isn't the text that's the problem; its the lack of top-down designing on the part of the human.
Now, one system that I absolutely loved working with had an IDE (text-based) where you deal in layers. When you click on the function name, the function itself comes up in different windows. I found that paradigm encouraged small, tight functions. Furthermore, the underlying "compiler" would in-line functions that were defined only once automatically. (You could request a function be in-lined in all cases, like in C, if you needed speed over code size.)
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.
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" ?
Assorted stuff I do sometimes: Lemuria.org
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.
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:
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.
Don't blame me, I voted for Baltar.
</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.
But if you have such a tool, you still have to find it. I can type ifconfig faster than you can find the tool (and of course, ifconfig is superior to ipconfig but that's another story).
Now is the time when someone says "but I just pin it to the taskbar so it's easy to find". Then someone else responds "a real power user would use Windows 8 and just start typing out I P C O until the program popped up and you could click on it." Then someone else would say "I'm on a Mac you ignorant lout." And someone else would say "I hate this BETA!"
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.
=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Friends don't let friends enable ecmascript.
Also, just try using source code management (such as svn or git) with graphical programming languages. Even if they save in something sort of text-based (like XML), it's much harder to track and merge changes. And it's impossible when they save code as binary blobs. (LabView, I'm looking at YOU.)
This is the number one reason why graphical programming languages are dead in the water from the start for any but the smallest toy projects.
#naabhaprzrag, #sverubfr-000, #agi-fcbafberq, negvpyr[pynff*=' negvpyr-ary-'] { qvfcynl: abar !vzcbegnag; }
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.
I'm trying to teach myself to set people on fire with my mind... Is it hot in here?
" Why, even the Cray Supercomputer would have been astounding in its day if AND, OR and NOT weren't the only gates we had to build with."
Do you know how hard it was to get the individual components and materials to build MAYBE gates, and how tight the tolerances had to be?
Doc Brown only needed one flux capacitor, those things each needed at least a dozen.
And you couldn't just take a MAYBE gate and slap an inverter on it to get an NMAYBE, you had to turn the whole design inside out, and the XMAYBE only existed on paper, because it would have taken the equivalent of 3 Manhattan projects and a quarter of the GNP of the entire Western Hemisphere just to produce a working prototype.
I see even classic Slashdot is now pretty much unusable on dial up anymore.
I'd also throw in, we're still writing text based messages - even though competing pictogram systems have been developed, none seem to have caught on well enough to displace the written word, composed of characters from a relatively small alphabet.
I made a LabViewLike graphical system for compiling algorithms into parallel processors as part of my Masters' thesis. It used a schematic capture program to build the hierarchical graphic "data flow" - but at their core, the basic modules were still short text based programs.
Some "programmers" might operate at an entirely graphical connect the lego blocks level, but sooner or later it comes down to 1s and 0s, and somewhere along that chain (several somewheres in modern practice) it will be represented in text based languages.
I think the graphic based systems haven't taken over for the heavy lifting because they're all too specialized, my thesis included. Most "real jobs" need more flexibility than the non-text based systems can provide. Having said that, I use 100% graphic based UI design, even though the tools translate to .xml for me, I almost never "get my hands dirty" on the text based code for my UIs, anymore.
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
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.
"I consider myself someone who 'gets code,' "
I think I spotted your initial error. Would you like cheese with that wine?
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.
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.
Visit the
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.