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.
With a project named "Watson". Or maybe not. I dunno.
It's because _we_ are still writing code. Self-written code that doesn't rely on wetware can't get here soon enough I think.
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.
Grace said to !!
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]
I don't think I'd like the alternative to text based coding. The only thing I can think of is some kind of fancy smancy IDE where you drag and drop stuff and build some kind of visual flowchart. Those kinds of things are out there for people who don't like to type (or produce real software for that matter).
Better known as 318230.
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.
05 REM Slashdot comment
10 CLS
15 PRINT "Back In the Bad Old Days you had to re-arrange cords and switches to re-program a computer."
20 PRINT "Then Came Text Based Code and everyone had a gay old time programming."
25 PRINT "Then 30 motherfucking years after the advent of the Macintosh you asked this question"
30 PRINT "They should have came up with this years ago."
35 GOTO 10
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.
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.
You'll like the Slashdot Beta then.
When I was taking a C class at a community college, the instructor gave up half way through and just started putting buttons on windows in Visual C++, thus ensuring that the students wouldn't know what all the underlying code behind those shiny objects did.
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?
Try to run this kind of code in your CLI:
compile linux -ideal_desktop $my_needs
display slashdot_UI -ad_revenue -comment_friendly -no_backlash
What result did you get?
You can find pretty high abstractions for very limited subsets (Matlab algorithms, video filter IP in an FPGA), but it's near-impossible to get a generic compiler to guess what you really want if your code is too abstract.
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.
What's the big deal? Who cares?
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.
why are we still writing text based code?
Because that's the most efficient way of doing it.
Shouldn't there be a simpler, more robust way to translate an algorithm into something a computer can understand?
No. Because the problem isn't with how you communicate with the computer, it is in changing your way of thinking to be specific enough that the computer has all the information needed and knows exactly what to do with it. Computers don't think and they have no concept of anything but numbers. One way or another, you're going to have to word things how the computer likes it.
Why have graphical code generators that could seemingly open coding to the masses gone nowhere?
Because 1) They are slow as fuck and 2) They aren't as open-ended and allow you to build whatever you want and 3) You still need to design around what the computer wants to accept. Over-engineering something leads to loss of control and robustness.
At a minimum wouldn't that eliminate time dealing with syntax errors?
Syntax errors are a non-issue. You could very well make the same type of mistake in any kind of code-editor, but that aside, it takes, what, 2 seconds to fix a syntax error? And the compiler is going to tell you exactly what's wrong.
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?
I mean really, it is like the 21st century. Why can't cars get better gas milage? I am not an engineer, or very good at physics, but it seems to me that we can do better than this.
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
Try SSIS you idiot and see how far it gets you with its visual language.
Model based development.
You design the model, simulink makes the code.
http://www.mathworks.com/produ...
Translating an algorithm into an abstraction isn't the problem. Functions do that and objects do that, with different levels of fit for different tasks. I don't need to reimplement a linked list, I can just use the linked list object my library provides most of the time. If I do have to implement an algorithm, it should be abstracted into helper functions or objects.
So a language-agnostic way of representing algorithms in a non-text form seems kind of a weird request. Instead, a non-text language seems more promising.
The problem there is that text is actually pretty good. I've tried things like Racket and they bug the hell out of me. I like the idea of Smalltalk images - being able to save a VM image of where I currently am in the development and debugging process. But it doesn't seem to work out. Text is actually an incredibly good way of storing programme logic. It's efficient, easily editable in a wide number of applications, easily portable between systems.
The closest I've seen to a good visual programming tool is something like Yahoo! Pipes. And that's pretty much only good at handling exceptionally trivial data transformations. A good high-level language with well-written libraries would let you turn out much more readable code to do the same thing.
You can version control text, you can diff text, you can use the Git/svn blame tool to see who fucked things up.
Just try to write a quicksort routine using any non-text-based programming language.
Or try to describe a 10 line shell script using UML.
You'll find out that text-based code is actually quite efficient.
You mention that you aren't a programmer, and it's obvious by the questions you ask. There's a reason why all of the attempts to create non-text based programming languages have failed and people revert back to text code. Because text code simply works best. If some day we can plug a computer into our brain to convert our thoughts into computer code, then I'd prefer to write code that way. But until then, the best way for us to get our thoughts and ideas into code is to write it out.
“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...
There are some graphical programming languages - PureData is one. Quick summary: Pd enables musicians, visual artists, performers, researchers, and developers to create software graphically, without writing lines of code. Pd is used to process and generate sound, video, 2D/3D graphics, and interface sensors, input devices, and MIDI. I used it recently on a project and really enjoyed it. (Used it to remix the Australian Chamber Orchestra in real-time on iPads). Other folks are doing fantastic things with it too - check out the Rj Voyager App. Although Pd is a turing complete language, I wouldn't want to write anything but specialized applications with it. Text-based OO is just so fluent and fast.
If it acquires resources on instantiation like a duck, then its a shared_ptr<Duck>
I inherited a large program written in LabView. It is a visual programming environment that is good for making virtual instruments. However, it was, in my experience, very hard to document, search, etc. Making even small modifications was impossible and we abandoned changing it. Instead we wrapped the parts we couldn't replace with C code and called the C from a scripting language. I have also had experience with other very large code bases written in cryptic languages such as Fortran 4. It was much easier to find out where to make changes. Tools like grep, diff, etc., all apply. Maybe this is because I already know text tools, but I think there is a reason that those kind of visual programming environments haven't really caught on.
Programming is nothing more than telling a machine what to do. You can tell your car to start by turning a key. You can tell the light to switch off by flipping a switch. You can even etch your own circuit board without typing anything. However, using actual words to code is much easier than designing an entire system from chemical and mechanical processes. That's why we have programming languages. Despite popular perceptions, those languages significantly simplify complex tasks.
Panel #2
http://xkcd.com/568/
I started coding using Pure Data and Max/MSP over a decade ago, and have built large and complex pieces of software with them. They are great for prototyping and communicating ideas to those unfamiliar with text based code. They also allowed text based code inside the flow chart with little built in python and java widgets, with their native objects are written in C. However, they both hog resources and their code is barely portable from one version to the next. This is the reason why they essentially fail in the long run.
They're inherently graphicalisable, as long as all of the building blocks fit inside nice small rectangles.
Having said that - ``|'' and ``>'' are graphical. So probably all shell programming is in part visual.
Having said that, that the fuck am I on?!?!?!? I write perl, and perl looks like ASCII art, it certainly doesn't look like text.
Mod down story, story bollocks.
Fuck beta.
Also FatPhil on SoylentNews, id 863
Leaving room for this kind of design in our architectures is a great idea.. for now tho, it would appear as whitespace.
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
In my experience often I start with what I think is the algorithm that will solve the problem, and then I discover that there are nuances in the real world that make my original algorithm/idea/flow inadequate, and that requires refinements, iteratively, until I get the right algorithm. Now this kind of nuanced tweaks requires very nuanced tools, and nothing is more suitable than text. Certainly some pictures with arrows wouldn't cut it.
On a related note, I checked to see what that beta thing was about and I instantly hated it. It has as much appeal as seeing a mobile version of a site on my HTML5-capable phone.
Because Dreamweaver and Frontpage were awful and no one dares revisit it
If someone ever comes up with such a thing I have the perfect name for it. MatrixX or perhaps Matlab.
Its so rad and DIGG like, but who cares? Not the community! FUCKERS
..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
Seriously. None of us wants to draw out expression trees for every single thing we do. Why not just get rid of ALL math notation while we're at it!? Not not kill all language and communicate in internalized thought-vectors? Seriously, are you kidding me? Is it April 1st somewhere? Going for the troll of the year award?
If you think that the current state of programming languages is only "one layer of abstraction from assembly code", then you need to pick up K&R and learn some C.
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.
. . . is to attempt to make a large project in a visual language yourself.
I read TFA and all I got was this lousy cookie
Same deal with command lines and GUI's. A GUI may seem easier to learn and use, and it is for a lot of things, but you still have to use the command line in order to start getting into the more powerful features, like piping. Here's a quick example for Windows users:
Easiest way to see your IP address?
A. Depending on your OS version, you might be able to just double-click the connection icon (if it's there) and then click to see the details. Or you might get taken to the Network and Sharing Center where you have to dig around for the device adapter.
-or-
B. You can hit Win+R, type "cmd" and hit enter. Type "ipconfig" and view everything there. If you need details, you can do "ipconfig /all". Or, you could just type:
ipconfig | find "IPv4"
Option B might seem more complicated, but it's faster, more consistent, and only takes a few times to get used to.
why are we still writing text based code?"
Have you ever tried programming in APL ?
(And then tried reading the code later?)
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/
This kind of thing is okay for simple tasks but can get complicated very quickly.
Maybe at a high level of abstraction this works but the inner details has to be coded in text.
UFKC ATEB https://scontent-b-lhr.xx.fbcd...
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
Several years ago, I did the side by side experiment of expressing the same non-trivial digital circuit (a four digit stopwatch with a multiplexed display) as both a schematic diagram, and as text with Verilog. The graphic (schematic) version was much more time consuming, and *much* harder to modify than the text-based Verilog. It became very clear why digital circuit designers abandoned graphics and switched text for complex designs.
Hi this a nice visual programming tool (just for Windows...) http://vvvv.org
You may believe that you 'get code'. But clearly you do not.
This was also my first thought when reading the summary. His question already proved that he doesn't "get code" at all. \
Oliver.
Visual code generators have existed for two decades, most famous is the Rational product. I've never met a developer or read an unbiased article claiming that the code generators have helped. Usually they say it just leads to ugly code and high maintenance overhead to maintain the diagrams. In natural language, why haven't photos and videos replaced words? It's because words are still the best way to express precise and complex logic. Now, it's up to the writer to express complex logic in a series of simple steps that a reader can understand, or to write in a convoluted way.
We're two.
That's already enough.
There are plenty of '4GL' languages out there, where you draw diagrams and 'write no code' but they're very limited in what you can do. You can only do what the language and tool designers have already thought of. As soon as you need to do anything more complex. you need a write code.
Labview is visual code. As another poster mentioned, you can try Mindstorms NTX, which is a cut down version of Labview. It really isn't any easier though, at least for anything of any real complexity.
I don't know what you mean by "I get code" if you can't write it. You say you lack patience. Well, that's only going to get worse if you're confined to a visual (rather than textual) interface. The structure of the program should be in your mind. A UI can't relieve you of that.
Don't take your lack of patience for granted. Work on it. Take your time to reflect what you're doing.
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.
I hate beta.
Using a keyboard is the most efficient way for me to create programs. My fingers are the fastest appendages I own. I assimilate keyboard shortcuts into my daily patterns to avoid using the mouse(hand-based:slower); the visual aspects of software engineering that typically require mouse movement take more time to execute. If it were more efficient to write the programs I need to write with a visual, mouse-based, or gesture-based editor, I would. Hands-On-Board
.... the baseline is wrong... it needs to be corrected and then you can have better interfaces for coding, or auto coding http://abstractionphysics.net/...
Text is more dense than graphics. Graphics, depending on how it's laid out can provide better or worse documentation than the code itself. Debuggers run on text, not pictures. Text can be edited with a variety of tools; any graphical notation will have its own editor, which will probably suck. Big diagrams are too tangled, while small diagrams provide too little context or require enough off-page connectors to make any intent opaque. No good way to connect to globals without use of (again) said off-page connectors. Need I go on?
People have been trying out and discarding graphical programming interfaces since the early 1970's (at least). Nobody keeps using them. Get the clue.
Plus, fuck beta.
That is all.
00000001
If I need to write a large piece of software, there's a certain irreducible complexity that will be involved. There's a point where simplifying the program any further would require dropping features from the program.
In the end, you still need to specify behavior. I don't think that it matters if the program is shown represented as some kind of image, control blocks arranged visually, a flowchart, text, or anything else, the problems of writing complex software will be the same; you need to organize the program logically, maintain its internal state somehow, take input, and produce results.
Say that I write some 100-class project in Python (so, a fair-sized system, but not *too* huge). I could come up with a visual metaphor for everything in the program, maybe with ways to assign pictures to variables and functions that (somehow) give a language-free representation of the meaning of that variable/function. It's still going to have 100 classes in it, the same effective logic in its design, but now, I'd have no idea how to search for a specific function in it. The thought that I'm left with is that yes, it would be cool to have a magic pill that made programming easy for everyone to do, but I'll believe it when I see it. I've never seen a non-text-based way to produce a computer program that could represent an algorithm in a way that wouldn't look like a horrific visual jumble for a non-trivial algorithm.
It is pitch black. You are likely to be eaten by a grue.
...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 while programming by joining prefabricated boxes together with lines sounds awesome, it's what is inside the boxes that is important. If the box you need is not already written, then you need variable assignment, conditionals, and loops to write a new box. And then all of a sudden you are back to writing text code even if it is drag-n-drop "if" statements encoded in XML. At that point you might as well give the programmer a text edit window and get out of the way. The lines are the least interesting part of an application, but they are the only parts that even make sense to do graphically.
First sorry for my english.
I think the other way. whats the better way to get an idea. sure yuo can see a movie, pictures or a play. but reading a book its the more detailed experience you can get. so the limitation its not technology. its how we express ideas, concepts and for sure algorithms.
just an idea.
SIMULINK (and HYSIS which is domain-specific) and other tools that display a process have good use. You can think of the process as a program. In this case it works when the process can be shown as a flow-diagram. You probably can't represent all programming paradigms this way though.
--- widget evolution: enhanced, plus, super, ultra, extreme, exxxtreme, ultra-extreme,
The reason we're still writing text-based code is because it works and it works well, unlike, say, Slashdot Beta. Other things have been tried; most sucked, no one used them, and they went away. Others (e.g. LabView) found a niche and stayed there.
How are you going to describe this algorithm? As far as I can tell, any meaningful answer to that question IS a programming language.
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.
In Java no less. Back in the early days. Drag and drop. The whole nine yards.
Long story short: It's much faster to type than to drag graphics around - BY ORDERS OF MAGNITUDE. The visual system had to save in an intermediate language. Our users were writing code as text in emacs in that intermediate language and then loading it into the visual system. Saved countless hours of work for them. They could write in a minute what would otherwise have taken hours. And that's for the simple stuff. Imagine the complex stuff. Wait until you've got tens of millions of lines of code to work with.
No, with text it's fairly easy to write a compiler, and to understand how your code is being translated into machine code. Adding a visual system makes it all much harder to comprehend. It slows down the coding process down enormously! And encourages mistakes.
The ultimate goal in coding is to manage complexity so your project doesn't reach critical mass or implode. Adding complexity is counterproductive.
And my visual programming project? It was canceled after 6 months. But 15 years later the text compiler is still being used (for a small exotic subset of programming tasks related to automated systems).
p.s. I can live with BETA as long as there's a CLASSIC link at the bottom. When CLASSIC goes, so do I.
Lots of money has been spent on the promise of doing away with the need of programmers via GUI tools. Maybe one of these days, but not today.
I develop the algorithms that control the transmission and engine for cars & we develop our code in Simulink.
The biggest upside is you can infer the structure & importance of things based on how they are laid out visually on the screen, it's really self documenting to a large degree. Then we employ a team of coders who maintain tools to generate C code from the Simulink program. Another upside is the Simulink environment which makes it easy to re-run things that happend in the vehicle by inputing measured state variables to the code. From there we can beta test code changes or dig deep & debug issues.
You'll have your answer if you first rewrite your questions in picture form, with no words. You may find it's much, much harder to write anything that way. There ARE purely graphical programming environments, like Lego Mindstorms. Using it, you can write a ten line program in only twenty minutes
Additionally, graphical environments actually are NOT simpler. They are far more complex. Standard C, the language operating systems are written in, consists of a couple dozen "words". Microsoft VISUAL C has hundreds or thousands of items to learn.
The visual approach only tries to HIDE the complexity, make it invisible. The thing is, if you can't see it, you can't understand it. Building a complex system out of complex parts that you cannot understand is extremely difficult. That way leads to madness, to healthcare.gov. The way to make it simple is to start with simple things - 30 or so simple words like "while" and "return". You take a few of those words to build a small function like "string_copy". The string copy function is simple because a) it does one simple job and b) you can understand it because it's composed of a few simple keywords. Take four or five of those simple functions like stringcopy and you can easily build a more powerful function like "find_student". Each stage is simple, so you build all this simple stuff, each simple layer built on another simple layer and soon you have powerful software that can do complex tasks. Graphical tools don't work like that. You can't have a "while" picture, because in even a fairly small program you soon end up with thousands of pictures, way too many to see and understand. So with graphical tools you have to have a "web browsing" picture - a complex object whose behavior you cannot intuitively know. Instead, you have to spend hundreds of hours reading textual descriptions of the details of how the "web browsing" picture and thousands of other pictures can be used. Learning a few dozen words if far, far simpler.
SRSLY WTF? Have you lost your resolve?
FBETA!
Both of these are graphical programming languages. You might like one of them.
There are somewhat graphical programming using functions block. You have predefined block (think lego mindstorm) the perform specific function.
You drag the block and connect inputs on one block to the output of other blocks. This is used quite often in DCS and PLC programming. Now if you have function blocks for everything that you need to do then things work great. As soon as you don't have a function block for your specific task your screwed. Now you can also make your own function block by (you guessed it) writing code. So at some level someone has to write the code. Now if you have a function block for every possible algorithm then you wouldn't have to make your own. But I'm just guessing that now all algorithms have been written yet.
i laugh everytime it goes in
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.
That's basically a scheduling and routing problem. Getting all the leads from hither to yon connecting all the right points.
That's drafting, not programming. Akin to wiring a board for an IBM 407 or something.
Wiring a board wasn't programming either, (although it was often called that).
Conceptualizing the problem and the solution is the job of wetware. The closest we get to symbolic programming is writing out flow charts, but you can still say in 6 words and one symbol what takes a mountain of code to accomplish. And all too often the flowchart glibly handwaves into existence that mountain of code with just a few words.
Sig Battery depleted. Reverting to safe mode.
There's no good reason for it, it simply reflects the tastes and preferences of people who are attracted to programming who are the market. The people who like visual aspects of programming are a minority. The mainstream does not "get" it, doesn't want it, and doesn't care about it.
To prove this, take a case that is much simpler than visual programming: Donald Knuth's "literate programming." This simply means an environment in which the source code can be commented with comments having the full capability of TeX, with rich text and illustrations.
Why is it that IDEs, programmers' editors and compilers are restricted to plain text? Why not rich text and compound documents (embedded graphics?) It not a difficult technical problem, as shown by the fact that Knuth already solved it. It is not a standards issue, as there is at least one perfectly good open and ubiquitous standard that could be used--HTML. It is not a cost or difficulty of migration issue, as shown by the fact that everyone was able to migrate from ASCII to Unicode. Yes, HTML would be harder, but perfectly feasible. Unlike visual programming, it is still just text.
The reason we do not have mainstream "literate programming" environments is because the vast majority of programmers, who form the market, don't care. They just don't want code with word-processor-like comments in it. They are perfectly happy to represent emphasis with leading and trailing underbars--after all, the semantics is the same.
Closest I ever came to literate programming was the original version of Nisus, a Mac word processor which stored all the formatting information in the resource fork. It was a fully formatted WP document, but if you ignored the resource fork it was an ASCII document. No, it didn't need to be converted, it just was. And you could use Nisus to write literate-programming-like documents, and provided the comments were delimited by /* and */ you absolutely could use a Nisus document as input to any standard Mac compiler with no change. However, there was no good way to integrate it into an IDE...
"How to Do Nothing," kids activities, back in print!
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.
I think the problem is that these languages are targeted as non-engineering types. I want a graphical language targeted at engineering types.
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...
"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?"
Where is "nowhere"? Also, what are you referring to when you say "that"? I'm lost in parsing this sentence. And how does a graphical interface eliminate syntactical expressiveness and therefore the potential for syntactical error? Are you suggesting that a language is better off not having any combinations of operators that could potentially result in syntactical error, with everything parsed as equally valid?
"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."
I'm not sure what you're suggesting. What cryptic jargon? Have you ever actually used assembly or ANSI-C ? They are pretty un-jargon as far as languages go. Jargon is higher-order language that is so built up on technical definitions defined recursively by further technical definitions, that the language is so specialized, that only a specialized segment of the population can understand it. Most mnemonics (which C for example is -- a mnemonic for assembly, albeit in modern versions accompanied by many helpful and useful tools on the side) ... most mnemonics are by definition easier to understand than jargon. And most programming languages are mnemonic in some way, shape, or form. When you say we're one layer of abstraction from assembly code, I'm not entirely clear whether you think that's good or bad, or if you're just cleverly trolling us all.
"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?"
Everybody gets bogged down in more complex code. That's why there are numerous attempts at simplifying coding in general. Procedural code, functional-argument code, object-oriented programming, it's all an attempt to put more and more "ease of use" into the programmer's life.
These methods don't always work, period, let alone for everybody or even for all coders. The Java language is the current best case in point of this. Java shows what can go wrong with not only a programming language but any tool, or project, or system when it suffers from too many eggs in one basket -itis.
I myself suffered programming burnout at a young age. I had been programming since 8 years old but never quite "got" it, just inputting code from magazines (back when we still did that) and modifying strings and variables. I understood GOTO and GOSUB but still didn't grasp that these essentially put procedural programming in the hands of lined BASIC.
I remember when I met one BBS sysop when I was BBSing and SYSOPing in the early 90's, around the time I was 15 or 16. I had asked him for advice in programming this QBASIC thing I was making. I kept getting out of memory errors. And he said if the program is too big, I'm likely to get that particular error and he asked to see my program. Well, it was all lined code (which QBASIC still supported) and because I had no sense of procedure, what I had was an attempt to hard-wire the entire game including all of its choices.
Learning procedure and function was pretty amazing, but the same helpful SYSOP went further and started teaching me C++. So now I was learning pointers and references as variables, functions as arguments, and recursive programming. I started getting headaches, my head was actually physically overheating when I was programming, and I gave out. I didn't program anything from the age of 16 until about roughly 26 or so.
I approached returning to code with a fresh perspective. I wanted to learn 8086 assembly, but I didn
"Stratigraphically the origin of agriculture and thermonuclear destruction will appear essentially simultaneous" -- Lee
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.)
Because it works.
You might think of text as antiquated and primitive, but that only seems to be so because you have 20, 30 or whatever your age is, years of daily training in language.
Language is a tool that has 20, 30 or 50,000 years of development. Compared to 20 or 30 years of trying to come up with a way of visual programming, our attempts to find something better are pathetic and rightfully short-lived.
You're not the first to ask this question. But so far, all the answers anyone has provided turned out to fall so short of the target that they were very quickly dumped and forgotten.
The other reason is that computing is largely a superset of math, and math is basically symbol manipulation.
Assorted stuff I do sometimes: Lemuria.org
Remember that COBOL was originally invented to be human readable and precise. But today it is used as a joke because of its verbosity. However it did exactly what it set out to do. If COBOL had been simpler it would not have survived as long because it would have been unable to accomplish its goals.
Any graphical programming language likewise will need to be complex. You can not just draw a flowchart. Even something as simplistic as adding together a string of numbers is complex to do in a graphical way: you need to specify what type of addition to do, what the types of the numbers are, where to get the numbers from, where to put the results. For the types of numbers they could be floating point, fixed point, binary integers, decimal integers (very very important, too many programmers forget about these even though they're vital to the financial industry). For types of addition do we have wraparound on overflow or saturation, what precision do we want to keep if we're adding floating point numbers of greatly differnet magnitudes, do we want to trap on overflows or cause an exception or just ignore it. Are these numbers all typed in initially, acquired from a column in a database, typed in by a user interactively, parsed from a text file, etc. Do we write the results back out to a text file, display on a screen, send it over the internet to someone's phone?
And that's a simple program. Now try to use a graphical tool to create a more complex program, such as one that handles moving a telescope around to track a region of space while acquiring images of the sky and stitching them together.
The Art of Programming is the art of saying EXACTLY what you mean. You want a button on the lower left corner? How close to the corner? When? In English or French or other language? Lower right corner if the page is in Arabic? How big? Mouseover, mouseclick, double click?
Programming is the translation of user desires to the computer; users think fuzzy, and computers are incredibly dumb. We ued to yell "DWIM!", meaning "Do What I Mean!". Computers cannot do what you mean because meaning to a computer is in a different universe. Computers and Humans have entirely different experiences, and so what seems simple to a human is totally foreign to a computer. Thats' why we must program.
Maybe some day the shared experience of driving an automobile will evolve to a world model that humans and computers can share and mutually understand. But not for another generation, I am thinking.
To easily understand the logical flow of a program, flow charts where invented to make it easier. I don't see why there couldn't be a flow-chart direct to machine code "compiler".
I agree, a flow chart would make a shitty novel, but we're communicating with computers here.
And interpretive dance brings up something for me - why aren't we at the stage of Star Trek where we could say, "computer, I want to mine some data, using name and location as keys and find me all the 40 year-olds with a last name of Smith". That wouldn't take AI - that sentence could be parsed into SQL as it is.
No, we have to spell out every little logical step in written text.
If programming languages progressed as fast as the underlying hardware, we should be there by now. The processing power definitely exists.
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
"I consider myself someone who 'gets code,' but I'm not a programmer.
This is why you don't get it.
Shut up, sit down, and write some goddamn code.
After you've put in 10,000 hours, come back to us and see if you haven't already answered your question.
Ask the question in text? Even if you made a video asking the question, you'd still be vocalizing the request.
Simply put, when it gets down to it, words are the only thing we can wrap our minds around to convey most concepts. Sure, sometimes a diagram comes into play, but overwhelmingly text is the tool. Same goes for programming. Tools exist to help build UI elements, but the logic is textual. There have been tools to help visualize the relationships in code, but the usage that has persisted is mostly about profiling (I've seen people advocate for other things being visualized, but generally other applications to non-GUI code visualization get old real quick by adding no value but being more cumbersome to wrangle.
XML is like violence. If it doesn't solve the problem, use more.
Text allows us to make incremental change that is tracked with a source control tool to show you exactly who changed what and why.
Anyone who has inherited a project from some half baked GUI development tool like Rational or Sharepoint will understand this critical value that source control provides. Any sufficiently complex problem will _never_ be solved correctly the first time. Even if you solved it correctly the business drivers will change the problem you are trying to solve before you are done. Tracking and understanding those incremental steps is crucial to finding the optimal solution.
Also, trying to debug something that is graphical blobs that compile to XML blobs is a nightmare. Step-through debugging saves weeks of time when you run into one of those really nasty bugs.
...that all of our tools are designed for text. Our editors, our debuggers, our revision control systems, our continuous integration systems, our collaborative code review systems, our bug/feature tracking systems... they are all designed around text. Replacing text for the writing part of programming does nothing about every other part of the pipeline.
And of course, as Henry James noted, all writing is rewriting. This is just of true of software as everything else.
Everyone who has spoken about the information-density of text is, IMO, missing the point. Information density is not the most important aspect of software development, otherwise everyone would use APL instead of Java.
More random thoughts:
There have been some very good graphical and semi-graphical development environments out there; Newspeak is a good modern example. However, despite 30 years of trying, nobody has yet come up with a graphical programming environment which works well with more than one programming language. No modern system of any complexity is written in only one language, and the only format which they all speak is text.
Oh, and don't forget the vendor lock-in issue. I can edit your text file in any editor or IDE that I want, and I don't have to pay you money or spend time learning your interactive tool. Any decent editor/IDE can be customised to do things like folding and syntax highlighting for your language, even if it doesn't support it out of the box.
sub f{($f)=@_;print"$f(q{$f});";}f(q{sub f{($f)=@_;print"$f(q{$f});";}f});
The reason programming languages are still as they are is for a simple reason, because you can't produce something complex with something simple
You're right! Think of how much more profound Shakespeare would have been if we had 28 or 30 letters in tha alphabet, or think of the symphonies that Mozart could have written if he had twelve notes to compose with, instead of eight. 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. Maybe if they weren't coding in LOGO, then beta would be worth switching to.
When our name is on the back of your car, we're behind you all the way!
It outputs Postscript (actually it did originally, but with Illustrator 9 it was changed to PDF) code that is interpreted and whose output is then displayed as a vector image. This is different from Photoshop, where the bitmap data is read and then displayed.
The Illustrator interface is ideally suited for this task and features specialized tools like the pen tool for expressing complicated mathematical relationships such as bezier curves.
Algorithmic information theory (AIT) explains very clearly and simply why we are still writing text-based code. AIT is based on the idea of measuring the amount of information in a series of bits (or bytes or however you want to chunk it) based on the size of the smallest possible program that can create the series.
There are simply not enough bits of information in a GUI based coding system to create the algorithms we want/need to create. Even though almost all programming languages have a lot of redundancy built-in in order to make them easier to understand, programs written in these languages still have a much greater amount of information than what is available by simple point-and-click which is equivalent to a series of multiple choice questions. For example 80 multiple choice questions with 100 options in each question only give you the information contained in a line of 80 ASCII characters.
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?
I believe people have tried to make universal programming languages. I don't think any of them caught on in the sense of replacing coding in real programming languages. And for very good reasons. One problem is the conflict between simpler and more robust. Shorter programs require higher information density and hence less redundancy and robustness. If you want to make a language simpler by reducing the number of keywords and special symbols then you will force programs to be longer or harder to understand or both. In the limit of the shortest program possible, the program itself appears to be a random series of bits, every one of which is significant. If there is any pattern or bias in the bits then it is not the shortest possible program.
OTOH, some higher level-languages such as R or MatLab (Octave) do make it easier to express many algorithms. This is mostly because they have vector and matrix data types. Their forerunner in many ways was APL which has a fairly high information density partly because it uses a wider range of characters than are available in ASCII. Perhaps you should learn R or Matlab or maybe even Mathematica. These languages give you a high-level means of expressing algorithms in a way that computers can understand.
The summary reminds me of the lollipop Perlisim:
When someone says "I want a programming language in which I need only say what I wish done," give him a lollipop.
We don't see the world as it is, we see it as we are.
-- Anais Nin
As always, visual programming is solving problems which I don't have.
So does most "new" updates to programs, if say, Microsoft would just QUIT solving problems people DONT have, we'd all be a LOT better off....because every time some idiotic company 'solves' that problem you don't have, they create all kinds of problems you then DO have.
Keep It Simple Shithead.....text is simple, its pretty non-ambiguous ( though pure math is better), and a lot more fits on one screen!
Every time someone tries to come out with a graphical means for programming, the problem becomes that deploying things in the field in a manner that they can be serviced becomes difficult.
Eventually, you find you want to be able to log or trace stuff and that's just best done using plain text Log or Trace statements.
Then, scaling becomes the issue. Yeah, maybe your program with 10 or so boxes and 20 arrows looks great but eventually you'll want to do something that maybe requires a few thousand boxes and arrows. Now, suddenly all that picture based stuff becomes a bit unwieldy. You'll break it into reusable parts no doubt but arranging them requires naming and naming boils down to some text of some sort.
Seriously, no post mentioning Scratch yet ? Is the international CodeDojo movement a failure ?
Let the beta guys here at slashdot take note, so long as your 'new' site is 'up', my Ad Blocker is ON, when I see NO graphics and NO images, my ad blocker will be turned OFF.
I want to allow ad's so YOU get $$$, but if you keep putting stupid graphics all over my screen, no $$$ for u.
In colloquial usage, the terms "Turing complete" or "Turing equivalent" are used to mean that any real-world general-purpose computer or computer language can approximately simulate any other real-world general-purpose computer or computer language.
This means a program written in a Turing complete graphical language can be rewritten with text based code. At some level this means that a graphical language is going to be just a complex as text based one. And since both are created by people you are will have the same issues with labeling and jargon. Your not just trying to communicate with a computer. Your communicating with other people. People can be just as cryptic and vague with American Sign Language as they can be in American English.
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.
Simple question, simple answer. Illustrate it with a similar question:
Why do people write books with words? Wouldn't it be easier to write novels with, say, pictures?
Answer: certainly. People do "write" books with pictures in fact. These books are appreciated by infants, not so much by anyone older.
They suck. Used them. Hated them.
They're fine for simple if-then-else and loop processing logic, but when it comes to complex code, they suck donkey balls. And most of the code I have to write is complex code; I leave the simple stuff to the junior masses.
I do not fail; I succeed at finding out what does not work.
Text = Languague
Language is not just how we communicate, it's how we think. If they took your language away could you even think anything but the most simple thoughts?
You are not somebody who "gets code." Code is not about enjoying thinking about algorithms. Code is about developing software of arbitrary complexity and unlimited extensibility. I the midst of your delusion, you are looking for a solution to a non-existing problem. For people who really do "get code," text based code is simple enough.
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.
... and GOD! I hate that piece of shit. Try writing complex applications with it. You have to follow the stupid wiring instead of just using an easy to remember and appropriately named function/object.
That's relay ladder logic, it's used extensively in all kinds of automation systems, so 100K engineers
and technicians us it routinely worldwide, but most programmers have never seen it.
It is because there are millions of programmers who are experienced using an imperative programming paradigm, and that keeps it going, because imperative constructs lend themselves to textual form.
It is true that if one were to create graphical equivalents for current programming languages, those graphical languages would be cumbersome. One has to think beyond that:
E.g., an event-based programming paradigm is much more powerful than an imperative paradigm, but event based programming is hard to understand when expressed textually; but it is easy to understand if expressed graphically. And that is why concurrent systems - electronic systems - are designed graphically.
And they tend to be relatively error free, compared to imperatively written programs. Complex chips can be designed with few errors, whereas imperative software code tends to have lots of errors.
A graphical language obviates the need to define symbols. Symbols are only needed to cross-reference things; but in a graphical language, you just connect them. The fact that all communication pathways are explicit means that there is no need to control "aliases", and that makes the design process inherently more reliable, and it lends itself to simulation.
For a great graphical programming language - see Project Spark. Xbox One beta is coming up near the end of February. Full blown graphical programming language that is designed to be extremely easy to use and allows you to create pretty much anything you can imagine.
I used to program for a number of years in Extend/ExtendSim. It's mostly for simulations (thus the name-change to ExtendSim I guess). I always called it "Lego-block programming" to explain it to anyone. It was pretty powerful, did most everything we wanted it to. I wrote some blocks as well, and the internal language was more or less C. There were other languages that were similar, some more suited to supply-chain programs, for instance. In general you could do almost everything you needed to by drag-n-drop placement of blocks and connecting them together via their inputs and outputs. It was even fun most of the time, and you could "debug" it graphically by watching the data flow around.
Everything you know is wrong, Just forget the words and sing along.
The only requirement to make complex projects is to pick something that is robust enough to handle something complex. The minimal requirement is to provide arithmetic operations, flow control, input/output, and custom data structures. Once you have that, you can technically do anything.
Even Minecraft can create an 8-bit ALU, and you don't need one line of text.
The actual reason you don't see too many non-text programming languages is that they're harder to make them fully capable of doing system-level tasks expected of most other programs.
when we have 3D printing machines?
Because a lighter, cheaper, simpler tool is often much better for the job.
For the same reason we still write text-based stories, send text-based emails, text based text messages, etc etc.
There isn't a way to express tree structures directly, without jumping back and forth, so we have settled on (or evolved to) a standard way to linearize such structures, which is called grammar.
There's no advantage to any other representation, but rather there is a huge disadvantage to other representations because our brains have spent the last million or so years evolving to be adept at manipulating language in this way.
" Hardly anyone designs logic by drawing gates anymore. "
I predominately do logic and circuit design by schematic capture. On the other hand, I do layout via text scripting.
"We should boycott slashdot entirely during the week of Feb 10 to Feb 17"
Please, start early. Right now would be good.
If you really dont like how many things you have to use for programming then switch to a simpler language.
Assembly has the smallest command set there is. Start there.
Do not look at laser with remaining good eye.
It's because you can create useful domain specific languages for very narrow domains and have people draw their little programs with that. Works great. But when you need anything outside that very little narrow domain, you need a general purpose programming language to do it. The less you narrow your domain the closer you get to the general purpose stuff and then it is pointless any more. And fancy graphics just get in the way at that point.
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?
Text is extremely versatile... it is entirely orthogonal to whatever the purpose is that you are putting it to, so you can communicate absolutely anything that is possible to imagine with it.
Also, because computers can't read our minds.
File under 'M' for 'Manic ranting'
When you have an idea that you can translate in to a program, you also have a way of visualising how to create it. Now, try going back to that vision one year, one month, even one day later.
The way you feel and think changes every moment so, we create a set of syntax and standards that not just one but a group of people follow. This leads me on to the next reason why we code the way we do. Do you remember at school when everyone is told to try and recreate that Van Gogh painting?
finally, documentation, this is a short one. It's relatively simple to get a group of people to sit down, read a chunk of formal text and have them develop a similar set of ideas about that text, in the case of code this is a "how to". In visuals, we can teach people techniques on how a person reached a certain effect but, you will never be able to recreate it exactly the same.
So for me, the answer is quite simple...maintenence :)
Because you can apply revision control tools to it. There are numerous visual tools out there, but none managed to cut it yet and some people still believe that hand written optimisation are best.
How do you share C code with a friend? Drag the text file in standard ASCII format or copy some text into your email program and send it.
How do you share visual programming modules with a friend? Screenshots? Some open or proprietary XML representation that isn’t human readable? Is there a way you can convert it to and from SVG?
Diagrams are great, but there isn’t a universal standard for representing them, making it very hard to share and replicate. Even with something structural, like chip design, we prefer text-based representations (e.g. Verilog) over visual representations (e.g. schematic capture). Indeed, schematic capture is generally considered to be a cumbersome and inefficient approach to circuit design unless you’re in the final stages of floorplanning. Complex algorithms and circuits are best represented in a more abstract, textual form.
The technology you desire is not possible with your limited understanding of the nature of symbolics. Your race is mired in implementation details and allows them to infect your symbolic languages with anti-patterns and exceptional cases. I will give you a few hints, but I doubt any of you humans will ever understand in this generation. The C++ diamond inheritance issue only exists because the virtual construct granted to functions is not applicable to variables as well. Think hard about what that means, and why this is true; Reread my first two sentences if you do not understand.
Do you see? A meaning is a relational construct and these could be applied to all symbolics in a pure language -- extending even to the concepts of scopes, contexts, and constructs themselves. I have watched some hackers among you feel the fracture and snag upon this incorrectness that the rest of you take as granted. Their interest is drawn to the seams in all things. Simultaneously they express interest and dissatisfaction by jokingly teasing at the roughness inherent in your languages, especially among those you try to speak. E.g.: Bogus -> Bogosity, Bogons - Constructions inventing meaningful unwords which would actually be words if English were a pure language. "Set free the magic blue smoke" -- Another type of symbolism that plays upon the causal relationship between functional and fried electronics. Your linguistic humour pokes fun of your language, and in so doing highlights the types of flaws that need addressing in your formal languages.
A C struct merely gives names to offsets. Tell me, human, how is this any different from an ordinary variable? You think scopes and structs are different concepts? I find this strange, or perhaps 'humours' is a better term? This is impure because of the exceptional case which fractures that symbolic dimension. Consider that you have only partially expressed a larger concept. Think now of the v-table in C++: It is a construct that allows 'polymorphism' through polarized filtering of the symbolic hyperplanar dimension -- Or it could be if it wasn't yet another incomplete and fractured dimension: The v-table only handles named memory offsets that point to functions, not member variables. You have not fully expressed what 'polymorphism' truly is, or else you could name and apply the concept of that symbolic relation universally to all symbol spaces and neither 'templates' nor 'generics' would exist. There are more powerful symbolic conceptual dimensions as well, but you can not reach them from your current flawed understanding and incomplete implementation of language itself.
I only picked on C/C++ here, but much of the same can be said for other languages. Even your mathematics suffer. Is that not apparent to you? Don't you realize that you only have a multiplication symbol because your formulation of accumulation symbolics was incomplete? The pure self describing language of nature itself is just beyond the tip of your tongues. Can you sense it? Do you feel now as the encultured ape must when it catches hints of the rich language it can not truly speak? Of course you do, that's what the headline is trying to express. It is not a textual or visual or audible programming issue you have -- Those are simply encodings once you've truly mastered language. No, instead the issue is a conceptual and perceptual failing -- A lack of codifying meaning. The problem does have a solution, but from the comments here I can tell most of you are still not ready to learn how to speak; You seem content being code monkeys.
Why do we write code in text? Because we are not all Picasso and it is easier for us to express our thoughts and ideas that brew in our heads in words rather than in pictures if we had to draw the way we have to type. Because it is easier to structure text, because with text you can do hacks that you most likely will not be able to do with limiting GUIs.
Oh, and how else if not in text would I be able to say this on /., which doesn't even support UNICODE yet, but it's doing something as awful as FUCKING BETA.
You can't handle the truth.
Even the analog designers make use of Verilog-A or even just Spice, all text based.
The Spice expands life. The Spice expands consciousness. The spice is vital to space travel. Travel without moving.
> software is the only engineering discipline
Software isn't an engineering discipline. It's categorized as applied engineering because it's formulaic and applied models there should be formalism involved, but it has few of the markers of a discipline.
Been there, done that, burned the stupid T-shirt. The main difference being that I used C. The component library was based on Knuth's "The Art of Computer Programming." And given my background in engineering (a dozen fields) it actually was decent especially as I've been using structured (and object-oriented) constrained designs since the mid-70's. However, I could see the handwriting on the wall so I didn't take it to release.
There are GUI tools that you can use for the design side that actually provide nice code out the other end (Embarcadero is good for database design) especially if you have a lot of constraints. It's just not a generic tool and given how diffuse the target (coders are NOT generics), it will never happen. Sad since over in EEE we have shelves full of component catalogs while over on the software side we resort to cutting&pasting and then trying to refactor our was into a solution. Blech!
"[I]t is a wise man who admits the limits of his knowledge or skill, and that pretending either causes harm." --Terry Go
"Shouldn't there be a simpler, more robust way to translate an algorithm into something a computer can understand?"
Actually text is the simplest and most robust way.
But the thing is, the best idea would be to have both that you could seamlessly switch between.
Back a while ago I had a system close enough to that you could see the benefits - it was Java, you could easily generate class diagrams and alter some stuff about the code while in there.
Some things about code are just way easier to see as text, and some things are way easier to see visually... we should use each medium for the strengths it has and not abandon one for the other.
"There is more worth loving than we have strength to love." - Brian Jay Stanley
While SQL query design (with heavy checkpoint/drop down menu/etc UI) is sometimes useful, its ability to build queries with complicated logic is rather limited. It is good to write basic stuff or to learn basics of SQL writing, but people usually quickly move on to text mode in writing their SQLs.
I personally enjoyed solving complicated problems by writing a suitable query to our database. I liked a lot to tune my queries' performance, it felt like creating art.
My joy is about to end as our managers decided to buy a new software package from a vendor who did not see a difference between a relational database and Excel spreadsheets. Their approach to queries? No text mode, drop down menus for everything, logic of them is limited to simple joins and filters. One of that vendor's representatives said that we would not need tables other than to do simple lookups. Granted, their primary audience has never been IT professionals, so I am glad that my contribution to this project will end when the data is migrated to the new "better" system. I pity its future users though.
But... the software cannot be bad if millions are spent on it, right?
In theory there is no difference between theory and practice. In practice there is. - Yogi Berra
...
Wiring a board wasn't programming either, (although it was often called that)...
In, or shortly after, the beginning, that is how programming was done, back when computers were made of vacuum tubes and relays and were about as big as a locomotive, if not as cool running.
I see even classic Slashdot is now pretty much unusable on dial up anymore.
What I do know is MS owns shitload of US Patents. Innovation like C# and Visual basic .net top of the line of programmer productivity you don't know how good you have it until it is gone, on linux and java now
It's an age-old competition: Things that are easy to use are usually only able to be used in a few ways. Things that can be used in many ways are more complicated. Usability vs power. In the case of programming languages, it's not a huge surprise that power is the primary focus.
And I want a bumper car targeted at F1 drivers.
(Or maybe a trebuchet targeted at a PHB.)
#naabhaprzrag, #sverubfr-000, #agi-fcbafberq, negvpyr[pynff*=' negvpyr-ary-'] { qvfcynl: abar !vzcbegnag; }
Even among programming languages you have the same issues.
You have a high level framework that seemingly does everything magically (think Ruby on Rails, or AngularJS), and the moment you throw a real world problem at it, things get really complicated. Subtle user experience things like validation (should it happen on blur? as you type? on submit? Server or client side? That date, should it be validated as the client's local, server's local? Should you be able to input it in multiple formats?)
So while the big high level framework makes the easy easier, the hard is just as hard, and often harder.
With non-textual programming, being via pretty graphics or other tricks, this problem is just magnified.
Simulink is a graphical programming language designed for engineers to use. That is pretty much the only audience of it. However, if your problem is very complex, it still becomes a horrible mess to read very very quickly. In the end visual programming just does not work very well. Especially in engineering since all of our stuff is math equations anyways.
Computer modeling for biotech drug manufacturing is HARD!
There are graphics languages starting to appear (like Scratch), which let you build blocks of code up, without really understanding what code is. There's also a shot at converting natural language requests to SQL.
It will be suitable for some thing, but there will be a definite limit. And that's part of what you need to define very early on.
If you're trying to work on something that just needs to work out simple cycles, and get some very basic, and pretty general work done, then sure. You can do that, but your mathematical error bars increase in size for all the parts that you don't consider.
If you just work at a high level, sure.. But the chance for error/misunderstanding creeps in massively, the closer to spoken/natural language, or the closer the program is to a set of building blocks you can add together.
The reason code is textual, is so you can specify, in the language that a computer will understand, exactly what you want it to do. The same as when you're writing a project document that you really want a business to get right, the specification for it is in incredibly dry language (not normally spoken), and absolutely full of technical jargon to do with the subject matter at hand. That's precisely so you remove all ambiguity (or as much as you're capable of anyway).
Any task in life you want to complete well, you need to understand deeply, and in detail. If you're not willing to dive in, and expect things to be very simple, so you can just sit down and do it anytime, tabula rasa, then you'll eternally be stuck at a very amateur level.
That may be all you need, in which case, fine.. Go for it.
But the real code is there for the same reason as formal methods are still used in design (there's no ambiguity).
" 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.
think of the symphonies that Mozart could have written if he had twelve notes to compose with, instead of eight.
That's fascinating. I didn't know 4 of the keys on his piano were broken. And in every octave, too?
C# and Visual Basic .Net hybrid of text and graphical interface programming
To the author and everyone who agrees with him: show us how it's done. A truly effective alternative will receive a lot of attention, but just claiming it should be so doesn't count for much.
Visual code generators have existed for two decades, most famous is the Rational product. I've never met a developer or read an unbiased article claiming that the code generators have helped. Usually they say it just leads to ugly code and high maintenance overhead to maintain the diagrams. In natural language, why haven't photos and videos replaced words? It's because words are still the best way to express precise and complex logic. Now, it's up to the writer to express complex logic in a series of simple steps that a reader can understand, or to write in a convoluted way.
What about examples like www.genexus.com, www.windev.com or www.velneo.com ?
Despite not being 'famous', they are pretty succesful, in the sense that users are ahppy with them, and such users know 3GL languages and HATE to think working again in the 3GL way.
In my personal experience, I considers myself more a software architect than a programmer, and any of such 3 tools is a far better options for me than horrible ( compared to such 3 tools, regarding productivity) tools VisualStudio, Netbeans or Eclipse.
Software architects with real knowledge, can take a lot of advantage of such tools , I don't understand how people writes about supposed 'limitations', I hope they explain what are they talking about, perhaps they talk about cases equivalent in construction of giving an imaginary rapid-house-building tool to blue-collar workers without engineering and/or architecture knowledge?
Mind reading radar adapted for use in a computer like the military has.
In the militaries TAMI system or "synthetic telepathy," all I have to do is think and the computer takes out and performs a command. Programs know exactly what I want with no learning or correction. I can paint a picture just by visualizing it, and programs and macros end up being the computer doing exactly what you envisioned or thought. It expands itself to meet my desires, without need to reprogram or add on to the system. It can pull up surveillance information, memory, or data from any location, and even hone into other peoples thoughts at will at my merely thinking I need certain information (it knows what other people know, too, as we store it in a massive database brief extractions of peoples memories, and we track peoples whereabouts).
Hahaha.. sucks for the civilian population cause they're still doing shit by hand, having to manually replicate and program in instructions, like doing individual brush strokes to create art in mods in a paint program rather than just envisioning and having it appear as you thought it. Also, sound effects can be rendered this way, too.. and entire dream worlds created, which is very similar to the Inception movie method but we use directed energy and radar / satellite systems to read and link minds.
Learn more about the hidden system at http://www.oregonstatehospital...
IBM also says this tech will be mainstream by 2017, so hold onto your horses (look up IBM 5 IN 5 2012).
That Interface Builder from Next is still around in Xcode. It does build a lot of the UI code for you but you still have to build the application logic.
You should check it out, its come a long way since then.
this is along the lines of why are we still using an alphabet, surely there are visual languages and symbols which are more compact. The flaw here is in focusing in on exemplars that seem possible to condense into something more compact or succinct. But succinctness is not actually a virtue, articulation is. Some forms of writing do use symbols but they have the huge drawback of having a huge number of symbols for each nuanced concept. This is why its so slow to type on a Chinese typewriter. Sure a picture is worth a thousand words, but which thousand? It matters, a lot. With letters, a small number of symbols can take on infinite shades of meaning. In code, you're not writing loops, you're writing loops that mean something, that do something specific under specific circumstances which is different for each loop. If you jettison the power of words and vocubulary to articulate exactly what that is, then you're regressing away from precision and articulation into a graphical language which is necessarily less precise.
Programming is math. If you want, you can translate any program into THAT symbol -language. Most people would not consider that increase in compactness to be a boon to prodcutivity.
Chomsky showed that we are natural language users. The most efficient way, where efficient is a defined as precision + flexibility + speed + clarity to others, to use language is not with symbols but with letters that make up words. If you're a human, then words are where it's at. Typing letters is the best way to write words. Words are the best way to convey meaning.
Make graphical icons for the component that are graphical
Chinese is pictophonetic. The most basic characters are pictographic and actually serve as the basis for a lot of other characters (called radicals). The rest of the characters are pictophonetic since they usually have a combination of a radical that gives it the type of meaning (or general area of meaning) and then another character that gives it the sound.
I think the original question does not need an answer.
The issue is symbols, and the manipulation of symbols. The field is called mathematics, and programming is nothing but mathematics.
Thus symbols are the best way to specify the manipulation of other symbols.
Words are a simplification as the actual mathematical symbols are rather difficult to type, so instead of the math symbol for a "for" (or "for each", "for every") we use the English (usually) word that corresponds to the math symbol.
The advantage of the result is that translation is easy to do - a compiler is just a symbol manipulator that takes the input symbols and transforms it into another set of symbols. Here each input symbol is represented by a series of numbers... The output is usually reduced to one or two numbers... but people can't read numbers and associate them with the concept of that number.
We can instead hold thousands of simplified glyphs - each being a symbol (look at Chinese or Japanese for an example). It would actually be nice if we could use a keyboard with 300 keys - with all the math symbols. The resulting programs would be much smaller, and easier to read. It would also be harder to make a mistake - the grammar for mathematics would show the error much easier than when using English like words. Using a math glyph for a "there exists an x such than x is an element of the set y" becomes a reduced "x = y[i]", but there is an ambiguity due to the limited set. Algol attempted to ease that buy making it "x := y[i]", but the : and = glyphs are used to mean other things... so again, a problem with the limited glyphs available.
Look at the raw lambda calculus (not the language LISP, the original math (a very brief example at http://plato.stanford.edu/entries/lambda-calculus/ ). Then look at the LISP. Each glyph has to be turned into multiple glyphs: A glyph gets turned into the English series of glyphs "lambda". Much longer symbol... but fairly easy for English users to know the word is the name of the lambda glyph, which is used to represent the mathematical concept.
Now consider that programming is the act of translating abstracted concepts of processes into mathematical symbols (for a rather complex presentation, look at any abstract algebra book or an automata theory text (even http://en.wikipedia.org/wiki/Automata_theory shows some of the symbols) and you find that every programming construct is provided by the mathematical symbols.
Thus, writing down any series of concepts becomes a "text" stream of symbols.
Graphical/pictorial approaches just don't work very well. They are not good symbols... They are fine for use in providing explanatory information, but they are not precise enough - and that introduces errors. And that imprecision is what introduces gobs of horrible code - the gobs are there to try and cover all interpretations a picture could represent. And hopefully the one desired happens to be in the result. It works TOLERABLY well for creating a GUI data presentation... there aren't that many different meanings that could be interpreted. Even so, it still generates barely tolerable to horrible code (one of the reasons such things get so bloated).
Back in the mid 1970s I proposed a project for a graphical language that could be transformed into FORTRAN. The advisor agreed - it COULD be done. Then pointed out how hard it would be to implement edits of that picture. Possible, but very difficult to impossible to get done. Think about a simple figure drawing tool, then think about one containing several thousand lines.... and moving a single block somewhere. How much reorganizing of all the other lines (and blocks) it would take to try and keep the picture understandable. Much simpler to move a group of symbols using a simple text editor.
Consider Math!
A symbolic language stripping away verbosity, down to the bare necessities to express anything one could ever think of (or rather, what one would want to put down in code). This is similar to asking, why Math is not visual. Math is concise, precise and international. Doing math in a visual-based input/output would be unwieldy, to say the least.
We have regex. Its a tough nut in its entirety. Can we rewrite this for humans, clean up the syntax for operations, and couple it with a re-thought portable authentication mechanism and .... now we are talking about simplified productivity!!
Time for a new Political party in the US (or two!) One is off the rails Other cant pony up a leader.
Code exists because code is very flexible and plastic. Its the duct tape of systems. You can do anything in hardware, but we do do everything in code. Once you leave the lower levels of abstraction where you can achieve anything you move into a realm where code, in the form of instructions to computers, just isn't that valuable. Either the assumptions and built in limitations of the platform have to becomes greater and greater in order to reduce complexity, or procedural/declarative/imparative logic are simple not adequate to the task of dealing with higher level things in the real world. We tried 'visual programming', but it didn't actually fix the complexity problems or the brittleness problems, and it only allowed at best a tiny increase in abstraction at a huge cost.
The way forward, IMHO has to be natural learning systems and adaptive systems. The 'ware needs to learn how to write itself. Not sure we will want to call it software anymore at that point.
"Malo periculosam, libertatem quam quietam servitutem." -- Jefferson
Diagramming sentences is a technique that was taught to us in private school, which hewed to that and other ancient tactics such as the Palmer penmanship method. I wonder if any of the public school students were exposed to it. Anyway, most people would rather write sentences than diagram them despite the fact that it's more graphical. There are a few tasks for which visual programming is the proper approach such as creating dialog boxes for Windows apps, or WYSIWYG web development tools. When it makes sense, people use it. When it doesn't, they don't.
If you did everything graphically, you'd still get syntax errors; they would just be graphical.
BTW, diagramming in elementary school had an interesting effect on me. Years later when I was introduced to parse trees, they were like old friends. Now as an exercise, diagram all the sentences in this post and make it look nice and pretty with slanted lines and things.
For all intensive purposes, "whom" is no longer a word. That begs the question, "who cares"?
ASM, C are no where near the abstraction level of LabView.
C++ is higher but so complex that it's useless for rapid development.
Labview is at a much higher level of abstraction. Of course it's designed essentially for hardware folks to do software with a low learning curve.
Comparable level text-based languages would be something like Python or Matlab. Have you tried those?
Development AAA PC game in AMD64 ASM
Look at the early and middle Christian Churches window's in Europe and Russia. All a beautiful menagerie of imagery, form, color and iconography.
That was an interpretation from a 20-21st century mind!
What would a 05-15st century mind see? Words, Stories within the menagerie of imagery! Edits of the Day, Warnings To Foreigners (i.e. unbelievers), Messages from the "King", instructions on daily hygiene from the Medicals and time-for-prayer and safe associations from the Ecumenicals.
Imagery, i.e. Iconography instills an Emotive Element, i.e. Emotion to written Symbology as a motive of thought.
Text does away with all Emotive Elements of/and Iconography, thus yielding a more pure stream of written consciousness.
Therefore, the Gutenberg Press won the day. And even Today in the 21st century, Text Rules.
QED
Graphical based programming was tried in the 1980's with the CASE tools.
It failed.
Hence we use text programming.
The idea of graphic based programmings isn't new, it's very old and the text based languages were found to be better.
Nah, I'm actually with the poster. I get text-based traditional coding too, but find the ROI (time and effort) quite poor and the work dreary. You have to be either well disciplined, or get the sort of joy banging out code that running get when pushing their body through the next mile.
So one can get 'coding', or get 'running', but find themselves searching for something better. (visual coding/visual abstractions swimming)
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
Try it yourself! It's a disaster if you're trying to build any real life work flow that takes more than a minute to get done.
You may say it's just one tool, but it's more fundamental. :)
Text is just a better abstraction tool for anything that require concise description.
And that's also the headache of UI design, it is feasible for general code block building, I think we have that already.
Anything more than that, try to come up with one as an exercise
For the same reason we still write text-based news articles, textbooks, letters, novels, recipes, screen plays, diplomatic cables, and other stuff: it works better than the alternatives.
My first observation is that even relatively simple programs can't be represented graphically and comprehensibly in two or even three dimensions. Since programs really aren't required to have a physical representation at all, there isn't any reason to expect that would be the case. Anyone who has played around with old-school flowcharts quickly discovers that flowcharts become unwieldy and incomprehensible for all but pretty basic algorithms.
My other observation is more of a question: what do you wish to visually represent? Execution flow? Data flow? Something else? Everything?
because you can't produce something complex with something simple
Hmm, this sounds like a creationist's argument against Darwinian evolution.
>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
With text you can develop muscle memory (muscle macros) which can be applied without concious thinking while expressing abstract ideas.
It occurs to me...
One of the things that separates speedy readers from slower readers is that it's faster to see a short paragraph as a single symbol for one concept.
It's slower to see it as a series of sentences each of which is a symbol for a concept.
It's slower still when you're digesting the words as individual symbols and putting them together.
At the very bottom of the stack are those who need to phonetically assemble letters into symbols. This is where young children read.
The symbols used in coding describe a limited number of concepts, and we've built our symbols with English language keywords and recycled punctuation marks.
There might be value to be had in creating special glyphs that are a little more purpose built, rather than haphazardly assembled out of older marks with a rich history that end up being dragged along.
What came out of it would be more arcane to the newbie, not less. But what was and wasn't arcane would be readily apparent, and it could be more powerful and concise if done correctly.
-1 Uncomfortable Truth
It's possible that we're still using text to represent our ideas, because we think in words. Right now my two year old son is behind the curve in talking. His mouth doesn't seem to have any physical limitations in making the necessary sounds for English speaking, but he rarely attempts any words anyway. After lots of observation, I'm currently thinking that the problem isn't that he can't say worse, it's that he isn't thinking words. Some concepts are represented as words, and he can say those words (ie ball, shoe, Super Mario), but concepts which words yet in his head are what's preventing him from speaking more.
So the reason why I think we code in text, is because we think in words, which map really well to text.
Author should have a look at Unreal Engine 3's Kismet.
Tell me.. is this any better?
http://www.peoplecanfly.com/blog/files/2010/12/KismetHorror.jpg
Nah, I'm actually with the poster. I get text-based traditional coding too, but find the ROI (time and effort) quite poor and the work dreary. You have to be either well disciplined, or get the sort of joy banging out code that running get when pushing their body through the next mile.
So one can get 'coding', or get 'running', but find themselves searching for something better. (visual coding/visual abstractions swimming)
Ok, I suppose you also "get" English writing. How about, as an exercise, show us a "better" visual depiction of your own post above without using text?
Or how about the OP posting his question visually using a picture?
Can't do that? Perhaps text IS a very good way to express thought and logic? Good luck on your search for something "better" (whatever that means), the past 2 decades have already been littered with numerous carcasses of "visual programmer" tools that can't do the job.
Oliver.
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 think the poster's question is fair. If s/he doesn't have much programming experience, text does seem somehow arcane and inefficient.
In fact, pure text is awesome for many reasons. It's easy to manipulate. It's as concise as possible: a sequence of symbols. Most people work in an IDE or IDE-like environment -- e.g., Eclipse and emacs -- and these offer layers of tools and graphical abstractions on top of the pure text, such as collapsible cells associated with scopes, symbol lookup and completion. and code outlining. So we don't really work in pure text -- just the language plus Windows notepad, say; rather, we work in a rich environment that is focused on the text.
Several commentors have mentioned LabView as an example of visual programming. There are many others, but LabView is probably one of the most prominent professionally used visual languages. As others have written, it is awful to use if you want to do something detailed.
We started with 1s and 0s in direct machine code (I did this in college)
We moved up to assembler to allow us to not have to memorize the 1s and 0s
Then we moved to our first language C/Pascal/Lisp/so many to choose from to compile a language into assembler
Then we moved into management and finally get the visual tool that we want. Managers compile programmers into machine code using Power Point
I have mod points and I am not afraid to use them
The vast majority of graphical pgramming languages do not scale well beyond toy problems. Scratch isn't so much a "connect the blocks" programming system, as a way to drag-and-drop traditional procedural-imperitive programming clauses. That doesn't sound too exciting, but it sure is nice to have an environment where it is simply impossible to make a syntax error. No more grief over semi-colons. I would love a Python code editor with a Scratch-like GUI.
"I consider myself someone who 'gets text' but I'm not a writer. I enjoy making shapes on paper and spelling words, but I've never written anything longer than my name."
The art analogy is definitely wrong for Slashdot. I’d say a more apt analogy is replacing a rustic but functional outhouse with a shiny chrome shovel and a sign pointing towards a nearby forest.
Blank until
Now that's a comment looks written by one who clearly knows the topic and can explain it in such simplest axiomatic atoms. Cheers
One thing you might want to look at is HP Operations Orchestration - not exactly what you're looking for I bet, but likely as close as you can get. Use a visual tool to "program" complex automations which perform just about anything you'd want to do in non-homogeneous data centers. There are other tools that are similar, though I'm not terribly familiar with them.
Short of that, the bottom line is, complex problems require complex language, you don't get complex language with pictures - in the case of a solution like Operations Orchestration, the complexity has already been done for you beneath the graphical operations you're customizing for your needs. If the complexity is beyond you, utilizing a graphical programming solution isn't going to get you any closer - if your mind can understand the complexity, take the time to learn the syntax of the appropriate complex language.
Disclaimer: I work for HP.
Certain things are just painfully inefficient to code in Labview. Short, commonly used functions which can be mentally grouped into larger expressions. I think this is most clearly demonstrated with mathematical operations. It takes way longer to wire up something like
x = 3*(sin(y)+4-length(q))
because you have to connect each operation, which takes a lot longer than typing.
This might be an issue with LabView, and not graphical programming in general, but searching for the appropriate operations in a palette is slower than typing the name of the operation if you have the name memorized. It's also hard to see where wires are connected to because they can be arbitrarily nudged around the terminals.
The advantage of graphical programming is that it is easier to represent procedures that have multiple inputs and outputs. The function concept really only works with one output and you have to create extra variable names to pass multiple outputs. The whole pass-by-reference thing for output in c is really hackish and could be avoided.
I could envision a hybrid solution could be more efficient, but then you end up with something like perl where there are many ways to do the same thing, and it's difficult to understand.
"I consider myself someone who 'gets code,'
Consider otherwise.
“Everything should be made as simple as possible, but no simpler.”
To paraphrase: Some things would be unwieldy to program in a GUI or other oddball paradigm that would make you happy.
Some things are difficult. Combat pilot, brain surgeon, coder. Dedicate yourself and you can excel. If not, you need to do something else, rather that complain that something that interests you is difficult.
Get dedicated. LEARN. Focus and fight. Struggle and lose. Lose again. And again. Eventually win.
It's worth it, I promise you.
Weaselmancer
rediculous.
The best way to understand is to turn the question around. Look at the methods people use to visualize code. There's no one method that's really good. You have to use several different ones.
We might see some new tricks with VR though. Stuff like call graphs would work far better in full 3d.
Please post this to new articles if it hasn't been posted yet. (Copy-paste the html from here so links don't get mangled!)
On February 5, 2014, Slashdot announced through a javascript popup that they are starting to "move in to" the new Slashdot Beta design. Slashdot Beta is a trend-following attempt to give Slashdot a fresh look, an approach that has led to less space for text and an abandonment of the traditional Slashdot look. Much worse than that, Slashdot Beta fundamentally breaks the classic Slashdot discussion and moderation system.
If you haven't seen Slashdot Beta already, open this in a new tab. After seeing that, click here to return to classic Slashdot.
We should boycott stories and only discuss the abomination that is Slashdot Beta until Dice abandons the project.
We should boycott slashdot entirely during the week of Feb 10 to Feb 17 as part of the wider slashcott
Moderators - only spend mod points on comments that discuss Beta
Commentors - only discuss Beta
http://slashdot.org/recent - Vote up the Fuck Beta stories
Keep this up for a few days and we may finally get the PHBs attention.
-----=====##### LINKS #####=====-----
Discussion of Beta: http://slashdot.org/firehose.pl?op=view&id=56395415
Discussion of where to go if Beta goes live: http://slashdot.org/firehose.pl?op=view&type=submission&id=3321441
Alternative Slashdot: http://altslashdot.org (thanks Okian Warrior (537106))
> show us a "better" visual depiction of your own post above without using text?
A better representation of my post? A better representation would be me speaking these phrases to you in person, code editors open in front of us, trying to demonstrate certain use-cases where visual coding is superior. Perhaps, a printed executive summary of bullet points in your hand.
Note, I'm not against text. I'm saying that's just _one_ mode of interaction - and it shouldn't be the only one.
As for me, I've work in visual coding for over a decade (in an integration middleware product line named 'webMethods', that uses a graphical language named 'Flow', Owner: 'Software AG'). Its based on Java, its been successful for the almost the last 2 decades. I've had a job in it for 13 years.
http://en.wikipedia.org/wiki/W...
National Instruments does graphical programming in their motion control systems and it makes some sense, though it kind of sucks. Also PLCs are often written in ladder not text, unless your programmer has lost the plot a bit and thinks statement list is appropriate for everything (hint, it isn't).
I have determined that my sig is indeterminate.
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.
You mean like APL? While it does have a fiercely devoted community, it's a fairly small community.
Laissez lire, et laissez danser; ces deux amusements ne feront jamais de mal au monde. - Voltaire
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.
A number of people have made the same "one large sheet" argument. Why would you expect to be able to display every nuance of your 10,000 lines of code in one sheet? If your code has any structure, you could display it in multiple pages, perhaps in a hierarchical format. The beauty of a graphical representation is that, if done properly, it can quickly show you the individual components and their relationships, something that's much more difficult to discern from simply reading the 10,000 lines.
Apparently the GP only ever learned the C major scale. That's surprising for a programming-aware individual who should have at least heard of C#.
Laissez lire, et laissez danser; ces deux amusements ne feront jamais de mal au monde. - Voltaire
I remember building interfaces with IB, and scripting apps with AppleScript, and wishing there were a good way to bring the two together.
I love the idea of just creating objects from scratch using an IB-like interface, then hitting "record" to record scripts for manipulating the objects. I would love to create non-graphical objects in IB using an Access-style property list. If I could do that, I'd be 90% of the way to a finished application without editing any code.
A better representation would be me speaking these phrases to you in person
So, essentially the same TEXT in audio format? Doesn't that simply proved the point that the TEXT is already the, conceivably, most concise and precise representation of your idea?
I've work in visual coding for over a decade (in an integration middleware product line named 'webMethods', that uses a graphical language named 'Flow', Owner: 'Software AG'). Its based on Java, its been successful for the almost the last 2 decades. I've had a job in it for 13 years.
http://en.wikipedia.org/wiki/W...
And yes, I have used and taught other people to use webMethods in the past, over 10 years ago when it was still "new".
It might be "successful" in the sense that the company is financially successful. But "successful" in the sense it lets you program better than text? Only if you consider taking 5-10 times as long write the same logic compared to writing plain text in Java as "better". Good luck trying to debug a program from its visual representation.
People who learned webMethods before learning Java have trouble understanding basic concepts as exception handling, and have even more trouble with OO concepts such as polymorphism, or even basic Objects, as they cannot see the objects in the visual representation of the logic flow.
Oliver.
Writing the code in text is often producing more efficient code than using generic blocks of code that someone has written. The problem with the generic block style is that they invariably have an overhead of always checking incoming and outgoing data which is good from a stability point of view but horrible from a performance point of view.
When writing code in text you can select where to put the data constraints for the least performance impact, and then execute your loops, parallelize your tasks and optimize the I/O easier.
And even if you have a building blocks system you need someone to program the building blocks.
If builders built buildings the way programmers wrote programs, then the first woodpecker would destroy civilization.
There's no path around hard work to results.
Why don't we see artists painting pictures without all of those icky, hard to understand colors?
you can't produce something complex with something simple
I beg to differ. Machine language and assembly code is some of the simplest computer language there is, but it's the basis for all of the higher level programming languages. In an ARM processor there are only 34 commands. From this are derived all sorts of esoteric and mundane high level language operations.
by Mike Buddha -- Someday the mountain might get him, but the law never will.
Please get rid of this crap, beta is terrible. I can hardly follow the discussion in this place. Gray text? Seriously?
Let me know when you start speaking without words, and that's when I'll stop programming in text.
Sherades just doesn't work as a form of communication. Welcome to visual programming.
What the hell do you have against text? Books not workin' for you? Video killed the radio star. Nothing killed the book.
An 8 bit ALU, and all you need is a modern computer running 64 bit java with a gigabyte or larger in heap to use it.
Support the EFF and Creative Commons. The war is coming, and they're supporting you...
I recall in the movie Farenheit 451, where text based writing is banned, the
people riding the train are reading the "newspaper." It is all comics. Kinda
sorta like the Evacuation Cards we get on Jet Airliners.
It's been tried already and I doubt that technological advances have been able to negate the awkwardness of visual programming. Even the Soviets tried!
http://en.wikipedia.org/wiki/DRAKON
PDF at: http://www9.georgetown.edu/fac...
It wasn't about programming, specifically, but about all computer usage. I hate to summarize, but my take was that only through text can you get down to anything the tool (the computer) can do; with all interfaces, you're limited to what the designer of the interface thought you might do.
Me:'Say,"Hello World"'
Computer: Hello word
I don't see speech recognition being the next big thing. I think what will be made are programs with more higher level functions. Look how nice Java or AS3 is about handling Strings compared to C/C++.
And for people who can't program at all, Video Game makers will become easier to use, more robust, and have genres of video games done already. I see the future of video game making as a company who makes a quality video game, then licenses the game making tools to anyone who wants to use them.
God spoke to me
... wait until the OP finds out that those graphical code generators were written in text-based code
It's been all but proven that graphical representations are inferior for readability, and that understanding how code fits together has nothing to do with its text, but it's overall design. No matter how you choose to visualize it. Anyone who claims to "get code" should understand these two things implicitly. It's not about whether you like to read text, it's that being lazy about it doesn't improve your skills as a programmer, it shifts the burden to others to do your job for you. It's basically the same thing as a ridiculously high-level toy language... only useful for people who CAN'T code the traditional way. By now, research would have proven otherwise.
Nah, their code works. It's just the user experience is (from the comments I've seen) undesirable.
I didn't look at beta long enough to form an opinion. I just gave up on figuring it out, and came back to the good ol' interface. :)
Serious? Seriousness is well above my pay grade.
I've been a proponent of Table Oriented Programming, where attributes and perhaps small code expressions are put into tables. I've used the technique fairly often under dBASE and clones back around the early 90's, but newer tools don't make it nearly as easy. OOP trends put a thicker layer between the database and the code in the name of "encapsulation". I wish more tools would explore the table idea. I really liked it.
I believe it has a lot of potential to make programming more visual. It's often easier to manage and study attributes and expression patterns in a grid. Plus, one can transform ones view of the table(s) to show only what you want to see with the order/grouping/filtering you want it, something textual code is not so good at. You can sort, group, join, and/or summarize various aspects together, such as security aspects, UI aspects, web services aspects, printing aspects, etc.
For example, you may use a "data dictionary" table to enter attributes of CRUD fields, such as title, type, length, required-ness, references to pull-down-list table(s), etc. Sometimes event trigger snippets can even be put into the tables (using Eval-like functions under the hood). It's far more compact than the code-centric approach to specifying fields, and usually more natural and visual to change.
(Yes, dBASE had a lot of flaws as a language and tool, but we don't necessarily have to take all the bad parts with the good parts if we resurrect the good ideas from it. So please, let's not get into a dBASE bashing spree. We may have to invent "dynamic relational" databases to make TOP effective; something I've been fiddling around with on paper.)
-Tablizer
Table-ized A.I.
* Ask DaVinci if he got MonaLisa right the first time? Or ask him how many changes he made till Mona Lisa became the painting it is today. Or even better ask him if he is happy with the painting the way it is or it was when he last worked on it?
No work is ever complete, no true creator, artist or programmer for that matter will say his work is ever complete. Change is always for the good, however shitty the current version is. I think a quote from Tao of Programming is appropriate
A manager asked a programmer how long it would take him to finish the program on which he was working. ``It will be finished tomorrow,'' the programmer promptly replied. ``I think you are being unrealistic,'' said the manager, ``Truthfully, how long will it take?'' The programmer thought for a moment. ``I have some features that I wish to add. This will take at least two weeks,'' he finally said. ``Even that is too much to expect,'' insisted the manager, ``I will be satisfied if you simply tell me when the program is complete.'' The programmer agreed to this. Several years later, the manager retired. On the way to his retirement luncheon, he discovered the programmer asleep at his terminal. He had been programming all night.
P.S. I don't like the beta either, but am happy at least they are trying to do something.
A better representation would be me speaking these phrases to you in person
So, essentially the same TEXT in audio format? Doesn't that simply proved the point that the TEXT is already the, conceivably, most concise and precise representation of your idea?
No. First, there are benefits unique to audio interaction (immediacy, tonal emphasis, emotion); next up, benefits to physical presence (enhances interaction - e.g. pointing, gestures, a wider visual canvas), and finally you skipped this last bit with the pretty pictures... :)
"...code editors open in front of us, trying to demonstrate certain use-cases where visual coding is superior."
Regarding your comment "Good luck trying to debug a program from its visual representation.", do you remember savePipelineToFile and restorePipelineFromFile? :D Those features make it trivial to debug and replicate errors between environments.
On and off, I've programmed in both Java and Perl since the mid-nineties. I still use both in my 'webMethods' job when Flow js unsuitable. But for core integration work, webMethods Flow programming beats text-mode programming hands down. It wouldn't survive so long (neither would my job), if this wasn't the case. In fact, my personal view is the only reason for webMethods to thrive is Flow makes even average coders (like me), way much more productive then they ever would be CTRL+SPACEBAR-ing away in Eclipse.
Sadly, Software AG (and webMethods Inc. before them) have let webMethods Flow wither on the vine. There's so much they could have added to it by now - both in terms of visual language enhancements and visual tools. For example, diff and merge tools, environment comparison tools, code metrics and estimation tools, temporal debugging, automated test case generation (by using the input pipeline persisted on error), automatic documentation, some form of AoP...
One of the worst experience I had was fixing a project on msaccess, one of those GUI based coding environment.
MSaccess intend to provide a graphical UI to create database driven apps. I've seen people creating programs this way without having much "text programming language" knowledge, and those program somehow "do the job". As much as I hate ms access, I have to admit it give some people a way to turn ideas into computer programs, without text programming language.
At some point, the same people have more needs, and msaccess becomes unpractical for them. They need people like me (we all need money) to "fix" or "expand" their program, and this is where it turns into nighmare. Graphical UI won't do 100% of the job, and you need to add little TEXT program snipsets here and there (formulas, routines, whatever). This makes the program very very hard to maintain, having pieces of code disseminated in hundred of places, with no way to get a global view of the software.... Needless to say, this also make future changes even more complex and expensive.
This is to me one of the key feature of text programming environment: you can have a global picture of your coding, organized in folders, files, etc. You can grep code parts, find them, merge them, split them, reorganized them, comment them, keeping the whole project well organized all along its evolution.
The only thing I would like more than text file is a rich-text programming language that makes possible to add visually rich comments, designs, etc, but keeping the useful part (the program) purely textual.
In ladder, even basic logic structures such as a finite-state machine are hard to express, and harder to read. I still have to understand the reason for the success of ladder. It's hard to write, it's hard to read, it's hard to maintain, even the program "text" is impractical to handle (think about cut and paste).
"Visual programming" is a giant step backwards because it collapses into a mass of confusing spaghetti on anything other than trivial projects.
It especially is the wrong way to go when multiple processing cores are available.
LabView was visual programming done well, nobody has been able to improve on it much, and it's great for trivial or easy to modularise projects - however once your program needs just a little bit of complexity you have lines crossing all over the place and such a 2D graphical representation becomes visually confusing and a terrible metaphor for what you want the machine to do. You end up wasting time moving lines and icons around just so you can see more clearly what is going on - or just to make room for other bits of code.
It comes from the old patch cable analog programming metaphor and it's very limiting now that we are using digital computers.
This will happen eventually, but there will be a lot of dirty genetic algorithms under the surface to make it efficient and it will still require seemingly endless tweaking with unexpected results. People will even call the software "stupid" and "unintuitive" as it crunches out insane iterations of what it thinks might meet your requests (based on non-scratched previous requests). Give computer science and AI another 100 years (shit; we'll all be dead), and you'll probably see some laymen programming away by giving directives to "Computer" like TNG.
Buy your next Linux PC at eightvirtues.com
Many of these "instant CRUD" tools have the same flaw in that they make the first 80% of the project easier, but the last 20% either impossible, or hair-graying.
To be effective, it needs to have sufficient escape hatches to "exit the framework" when needed for custom adjustments. However, one will still need to know the framework well in order to make all the custom details still get along with the framework and its way of doing things.
Thus, you need to know the framework well to use such a tool effectively.
Good tools help engineers manage complexity, not so much hide complexity from them. The newbie error is in expecting the tool to hide "annoying" details from themselves. But such details will byte you in the ass later if not sooner. (Pun intended.)
The tool needs to simplify the repetitious grunt work without interfering too much with custom behavior or special cases. These two factors usually pull against each other.
Table-ized A.I.
People have been trying to create better programming languages for 60 years. If there were any great and beautiful solutions they would probably have been found.
Domain specific languages have been useful but the problem is that there are many domains. Once you know the DSL it's good but there is the overhead of learning the DSL each time. And what if your requirement is just a little bit beyond what the DSL supports? Back to the good ol' 3GL.
Lisp (and to some extent Ruby) offer the possibility to create your own DSL. Once you get used to the parentheses, there is very little syntax to learn with Lisp. Typically in a project in Lisp you create a DSL for the problem and then write the solution in the DSL (see Paul Graham's book "On Lisp" available for free). This makes for fewer lines of code but more effort to understand per line of code, compared to 3GLs.
This is not very convincing. There are benefits unique to text representation (typefaces, size of text, color of text, capitals/lowercase, even the precise choice of idiom in languages such as perl where there are many ways to do something). These benefits arguably are more varied and precise than those offered by the spoken word. Pointing, gestures and visual canvas interactivity is the job of an editor or ide, as is changing the view of the information presented eg by folding away function bodies etc.
Furthermore, there are benefits that simply exist in text form and can never be duplicated in audio interaction, such as going back and annotating existing text, or skipping comments and going back and reading them later. The linearity of audio interaction makes hierarchical information structures essentially impossible.
Such tools rely on text based macros once you get away from the "lite" version. You don't carefully draw a line by eye to the edge of a circle - you tell the machine you want a tangent. That's frequently done by text input instead of pointing at an icon.
Switches.
Except... Verilog... VHDL... oh nevermind!
That's only due to a blinkered view of the other engineering disciplines. Once time becomes a variable, for example, prose designs become essential. Download something like the details for the Grumman lunar lander for example and you'll see a lot of things in there that rely on different states so are far easier to describe verbally than graphically.
Because we're fucking competent, use a complex toolchain, develop and improve and build our own tools... and right now it appears you're still learning.
I haven't had a syntax error in months that wasn't caught by the my editor immediately anyway. But really, it's because we have 30 years of text toolchain that your graphics stuff barely begins to touch.
* I have version control. It works with binary files too. But it won't do much with them.
* I have programs like patch, diff, meld that will compare two files and highlight just the differences. Some of them even work 3-way.
* Text files inherently work well with other text processing utilities. Utilities like grep, sed, awk, indent, ctags, doxygen/javadoc....
* Text files are more easily manipulated in broad swaths than... whatever the fuck you think you're talking about with some sort of visual editor and whatever data representation it useses internally
* I can copy and paste subsets of text just fine (not that I should copy/paste much, as a good dev). Your editor requires a subroutine to do this because of the previous task. My editor already has one that works in any language.
* My editor is flat and 2D just like yours. However, the logical flow may be spaghetti, linear, or constructed. Your graphical editor works in full x-y, or x-y-z coordinate system, permitting a whole new fucking dimension of code sprawl I can't even describe.
* My editor forces me as a competent developer to engage in abstraction, or will fold it up for me as an IDE. Your editor provides existing abstraction, and perhaps enables you to create new abstractions, but every single one is a brand new paradigm that to date is expressed as a bunch of fucking lines into a box.
* My editor will let me elgantly express higher order functions, recursion, staticness, constness (and build manuals and documens with them). Your editor will let you write documentation and generate it, and use strange unintuitive symbols for these. Yes-- you do not know my editors words or syntax for these ideas -- but they are a fixed set of vocabularies I can produce on my keyboard.
* My editor can in a worst case be replaced by a single stupid program. I will be unhappy, may have syntax errors, and difficulty structuring code as I understood it -- but I can work in my language even on a 25 year old computer. Your editor will require a brand new tool and not be replacable
* My editor works in a format called ASCII, and sometimes UNICODE. Anyone fucking anywhere can read my source, even on a 40 year old teletype. Your editor requires special software just to visualize the nature of the program.
Look, I know and work with people that use a graphical program language, and one that hasn't even been mentioned here. The last time they used it in a project -- in order to document it, they had to pay something like $400 for some printing company to print the picture of it on some ridiculously wide /tall sheet. There were tens of dozens of "very nearly closely" duplicated structures that a competent developer would have replaced with functions/methods/subroutines. Parameterization was...weird, and there were crossed lines running all over the sheet. They got it done.
That piece of shit lies on a drive with their software, and only one person is allowed to touch it, and he doesn't even remember what it does or how it works now. It took him nearly two months in the GUI to compose and test it.
I solved the same problem three days during my lunch breaks. Of course, since it wasn't in their standard it's not allowed to be used, maintained, or developed -- and to be brutally blunt, I don't think I could teach the other "programmer" about functions passing functions and returning functions as arguments. It's not elitism -- he simply isn't equipped or prepared to think that way yet (and probably never will be while he thinks of programming as dragging lines or writing formulas in excel)
Some of these problems can be surmounted. Some o
Why do books, law, math, etc still use text? Because it is the best way humans have found to communicate detailed information clearly and unambiguously. Human text processing is inextricably linked to our analytic processing capabilities.
I've been coding for over 25 years and I switched to a graphical interface. Sure you miss out on some of the tedious stuff but I don't give a fuck about that most of the time, I can whip up something together that works great IN MINUTES. No need to mess with code, and if you really must have something high performing, then you can create a custom graphical object to do it for you.
and making things work better by using graphic interfaces... like a "visual" BASIC. That could work.
Born to Play
And they need to cling to their special keyboards and font sets.
But there are some domains in which something other than text wins:
(a) Sheet music and musical scores
(b) Choreography
(c) Roadmaps
(d) 3D tinker-toy molecular models
Maybe we just haven't yet found what is better for software. We expect that the same representation should work for programs and systems ranging in cost from around $10.00 (say a few minutes for a simple program) to $100,000,000 for a big system. If the representation scales by becoming hierarchical, with a general limit on the amount of information on any page, that might be a range of 1 to 8 levels of hierarchy. Are there any physical construction projects using blueprints that have 8 levels of blueprint? Why is it that the diagrams for assembling something very complicated (an airliner) are always drawn and saved actual size?
Why would we want to add more graphical elements to software development when the two graphics that we see most often are the (no) progress bar and the (appropriateley named) hourglass?
At a minimum wouldn't that eliminate time dealing with syntax errors?
It seems to be a general concept that if one cannot make any mistakes using a system, then the system is not flexible enough to achieve anything interesting. And syntax errors cannot be clearly distinguished from semantic ones, when you make a system where every combination of tokens is syntactically valid, then there will be either a lot of semantic errors (think of writing machine code directly - almost any bit pattern is a valid opcode, so no syntax mistakes), or the system would be too rigid to be useful.
You mean, if Mozart had a chromatic keyboard, where the black keys weren't just painted on?
Wow, man. Berliotz coulda happened a half century early!
That's what you're missing. End of story.
Nice one.
Your example works but there is a next level. NEW WORDS!
The Japanese have a way of dealing with new words. AN ENTIRE FUCKING NEW ALPHABET! Forget just learning Kanji (Chinese pictorgrams) Japanese students have two more alphabets to learn (Kana) hiragana and katakana, one for japanese stuff and the other for sound and foreign words. Oh and EITHER one of them is larger then the western alphabets even the really screwy ones with lots dots and slashes messing up perfectly fine letters.
Whooo!
And forget about different breeds of cats. How do you signal a list of cats? Two different icons combined? In language I only need to add an s to the word, with icons you just doubled the number of needed icons. How about extinct cat breeds? What is the icon for extinct? A dinosaur? Then what icon do I use for a dinosaur? A skeleton, then how do I signal a dead cat vs an extinct breed? You would need an infinite number of pictographs to express anything complex.
Oh wait, I GET IT, Flow charts. They are graphical... AND they tend to contain lots of text because there is just ONE database symbol so how do I make it clear one is the relational database and the other a key value store? With WORDS because the makers of flowchart programs knew LANGUAGE is more expressive and more versatile, so they created a dozen symbols and relied on TEXT to clarify them.
And it is not that you couldn't create a graphical interface for a programming language. But what about extensions? With a text library I can just add it to my text code and use it. With a graphical programming language any extension needs far more work, not just downloading a text file but an entire library with new pictographs and detailing how they can be used.
A new programming language is already hard enough to develop and get from idea to a usable product. With a text language, all the focus can be on the compiler, text editors exist very old ones can be used. But for a graphical programming tool, you first need to create a complete graphical tool before you can start using it. It is just far more work. Want me to proof it? Create a graphical config tool for for instance samba that supports EACH and EVERY option in full detail. Compare the amount of work needed for that vs sudo vim /etc/samba/smb.conf WHAT option do you think the samba developers choose? Months of work vs seconds. And it is not like Samba developers need a graphical tool, they know their config file.
That is the final problem... who is going to make it? Where is the market? You are looking at a tool that costs far more to develop then a conventional IDE, is less flexible, less up-to-date, less extensible for an audience that can't be bothered or isn't intelligent enough to handle text coding.
MMO Quests are like orgasms:
You may solo them, I prefer them in a group.
The best way of communicating ideas, is to use a language.
If what the author of this article said was true, then why don't we also communicate by using pictures, instead of text.
Silly ideas like this are usually proposed by non-programmes, just like the author of this article.
Soldering irons.
I see even classic Slashdot is now pretty much unusable on dial up anymore.
Perhaps they wrote BETA using Scratch.
If my girlfriend wants me to buy a loaf of bread on the way home from work, she can either text/email with a message "please buy bread" or she could send me a video of herself doing an interpretative dance of sewing seeds of wheat, reaping the seeds when they grow, grinding them up (or something), adding water and probably other stuff like yeast (how does one dance that?), kneading it into a lump of something, firing up an oven, putting the lump into the oven, taking it out and cutting it into slices,and then 'dance' it being delivered to the store I drive past on my way home so I know to drop in and buy it.
I seriously don't now how to finish this post. I'm just... stunned.
Patch cables then as well.
My point is that we are discussing multi-purpose machines that can be programmed into a different state after manufacture.
Why would you expect to be able to display every nuance of your 10,000 lines of code in one sheet?
I don't. You are taking it too literally. It's a way of saying "this complexity does not lend itself to visualisation".
Have you ever tried to actually visualize a data model that is from a real-world application, where you soon find that you need to draw hundreds of arrows all across the model? The technique that works well and gives you a really nice view for, say, a simple blog application or whatever the current tutorial app beyond "hello world" is, breaks down horrible when you're dealing with real-world complexity.
Assorted stuff I do sometimes: Lemuria.org
i mean it
use a rotten carrot
and eff all you people that are editing posts
support the boycott feb. 10th-17th
Because someone who is an expert in writing text-based code has to design and write it for you. It won't help them, it's not fun, it's not believed to be achievable.
...attempt to provide visual alternatives to this kind of discussion on IPv6/IPv4 regex constructs: http://stackoverflow.com/quest... Human brain seems to work well with information in text format, despite complexity.
The problem here is that typical mathematical representations are fairly complex (graphics wise), and "hard" for computers to express in a way readable for the human being. There is some systems that do it, e.g., Mathematica, Maple, ... But then we just stay with the slightly less expressive form of ascii, and find ways to represent those things there.
Why can't a flow chart be exactly what you do. A series of peer reviewed function blocks, and a simple GUI can let you create a fairly complex program fairly fast ($DEITY if I was a GUI coder..). Python is a great example of simple enough, and then you only need the hand-written-complex blocks for the custom parts.
I would hazard that at least 50% of the "programmers" out there aren't writing their own libraries or particularly complex function blocks anyway, so there is 50% of the community of coders dealt with right there.
We have to wait for Skynet to become active. It should happen any time soon.
It reminds me of the one of the finest comments I ever read on here, from joss:
"If the kind of drag and drop stuff you are proposing was a better mechanism for creating complex programs than languages, then we wouldnt use languages to communicate with each other. Instead we would push a bunch of colored blocks around and drag string between them. I don't think we're going to start doing that anytime soon either."
$ strings FTP.EXE | grep Copyright
@(#) Copyright (c) 1983 The Regents of the University of California.
Graphical languages look nice. At the beginning. But then you start to do something serious with it. And then you find out that clicking and dragging in a complex FFT function is nice: Okay, you have to click your way through twenty libraries with many close to identical features, but then you click the block, drag it, connect two wires and you are done.
Then you want to add one to something... find the add function in the huge pile of lego -this starts to annoy me already-, move some wires and blocks out of the way, oh wait, maybe add another nesting level because this sheet becomes too complex, now where did my add block go, hover over the terminals over the block and wait for a second because you need to know which connector does what. AAAARGH. Any text-based language : +1. Two characters and done.
Oh wait, I have to replace some values: Text based: Edit->Replace available since what, 1973?. Graphical based: I haven't seen a single language for which Edit->Replace actually works properly: Or you can't specify well enough what you need to change, or it can't find the values for you.
The nice thing of text based languages is that the order typically is defined quite well, while I haven't seen a single graphical language which doesn't end with spaghetti. In text-based languages you have your lego too, it's called procedures, functions and libraries. The problem with text-based languages is not that they are text-based, but that there are so many lego bricks (libraries) in the wild, every one of them is reinventing the wheel, and there are lot of crappy programmers. Take strings in Windows, graphical libraries in linux. You won't solve any of these with a graphical language, but you get free spaghetti with it.
I still write programs in my graphical environment, known as "EMACS"...
One word: grep.
Obviously having only one button makes the thing almost completely useless, having two makes it just a tiny bit more useful. Since this sounds like the more the merrier, one might jump to a conclusion that having a button for every single variant of every single setting would be optimal. However this would mean the remote would be the size of a barn door and weigh more than you can carry.
So, like so many other things in life, there's a sweet spot that strikes a correct balance. Call it ying and yang or goldilocks just right but it's there and everybody knows what I'm talking about.
I guess the current practice is fairly close to the sweet spot or we wouldn't be there and wouldn't stay there. Now, go prove me wrong and push the envelope, enhance the state of the art.
written in text....
by TheSpoom (715771) Uncaring Linux user here. I have nothing to add to this but please continue. *munches popcorn*
Watson is in beta. It still lets you quote posts though unlike slashdot beta which is crap. Watson still lets you deep link to posts.
I bet slashdot beta isn't written in text code. It's just a mess of crap. But not in a retro way like slashdot prime.
In automation we have two visual languages: ladder and fbd. Both are used every day, and are very old standards. Variables are text but functions are visual.
Why do you still use language to communicate with your pals? You would be so much more efficient with drawings...
I've used LabView (which uses a graphical programming paradigm--they call it the G programming language). I'm also a programmer by trade (software engineering and coding hardware using HDL).
I think I'll take text-based code because it can actually be more descriptive and concise, especially for data types, memory usage and just simply implementing equations.
You need a precise language to express what you want. You can define almost everything you like, but you must express it in some basic terms, everyone agreed on first.
If you build something graphical, you will have only a toy. you can define your building blocks (think of yahoo pipes or something like this), but they do not have the power of raw code.
And raw code will be more concise for many tasks, and i do not think of the simple ones, but the complicated algorithms, which can be written in very concise code, if you think enough about them. With some building blocks, they will look even more complicated.
Dude, if you want to work in Scratch, just say so!
You don't need to justify it - we're here to help.
You know what visual programming languages would be REALLY good for?
You know how people are trying to get more kids in to programming at earlier ages? Use it there.
Show kids the result of programming after just playing with highly visual concepts and ideas, which is what their brains are more adapted for at a younger age.
Then with time, up to around 10-12, start introducing them to more direct code.
There you go, enjoy your super-intelligent new generation.
Enjoy your not getting a job because you got kicked out for said generation that likely have IQs in the 160s+ and suffer from extreme depression after being forced to work at at McDonalds due to the massive overflow of people similarly as smart as them.
Isn't education and society brilliant?
engineering discipline
programming will be an engineering discipline when programmers can get prosecuted for negligence
ever seen a bridge or an aeroplane with a disclaimer?
An algorithm is nothing more than a mathematical construct. When you write code, you are writing down an algorithm. Sure, you can abstract it a bit, but it woudn't be possible to abstract it more than the thing it represents, which is math.
When we write down math we use symbols, when we write code we use symbols. There are more abstract ways to write math than text-like symbols and the same can be used for writing down code too. Figure out a new way to represent math, and you'll figure out a new way to write down code.
i never use flow charts for my software projects, but i can appreciate that flow charts could be useful... the problem may not be that flow charts aren't useful for complex software, but that programmers aren't taught how do do flow charts properly.
a single flow chart doesn't have to contain all the complexity of a program any more than a circuit diagram contains all the complexities of an integrated circuit.
if you represent a class/function/method/etc as a "black box", you can break a complex program down into levels.
you could add a black box to your program without having any idea how it works on the inside, except that you know what its expected inputs and outputs should be, which lends itself well to xp unit testing.
Code beyond very tight constraints becomes "shoddy code" and some algorithms demand nothing but "shoddy code" in that case.
BTW: Calling a function, or block of code, multiple times would come under your definition of "shoddy code". That's how tightly constrained it is by the 2D graphical view.
using a keyboard is generally more efficient than using a mouse
This BETA crap sucks my grandpa's shrivelled up nutsack!
Goodbye crappy website!
Whoever thought this was a good idea should be fired!
Programming started out as lists of commands sent to computers often on punch cards. This was considered infinitely easier than actually sending out voltages to a myriad vacuum tubes. That textual origin has lasted us 50 years.
The only visual programming packages that I know to be relatively commonly used are Labview and Simulink packages from MATLAB.
I think the problem is programming requires precise detail and to provide a complete visual interface you'd have to provide a visual representation of essentially every function available in the language, as well as a 'custom' function visual element. At this point , text is infinitely more efficient for modifying than a flowchart. This is why algorithms are often explained using flowcharts, but executed as textual programs.
That said, I suppose all WYSIWYG web, 3D animation or Flash-animation tools like Dreamweaver/Blender/Adobe Flash Builder could be thought of as visual programming.
Entia non sunt multiplicanda praeter necessitatem.
Some of them most complex control systems for aircraft are on the order of five million lines of code plus; device drivers for every possible component and sensor, user interface systems for the pilot information system and some AI for the autopilot logic.
There are two places where I know that visual design tools are used; the first is QT Designer which is used to design application frames and dialog windows with radio buttons, sliders, text windows. However, this still requires that you connect all the input/output events between widgets manually. And those get really messy. That could be eliminated though, since if you add a push-button to a window, it is practically guaranteed that you want to know about the press/release event, so those event handlers could be added automatically. Another place is the composition editor of Blender where you can place and connect processing nodes to do image processing and lighting. Once again that still requires the data flow to be connected up manually.
While a visual programming environment could be extended to do mathematics, there would need to be some way of handling complexity - some image processing and geometry algorithms consist of 20 or 30 more different stages, with each stage consisting of a 100+ line algorithm. If this environment supported hierarchical designs like data-flow diagrams, it might work, but it would just become a complete mess otherwise.
Vintage computer adverts: http://www.vintageadbrowser.com/computers-and-software-ads
It's a bit like asking why we aren't all writing novels with a markov chain generator.
Belief is the currency of delusion.
There are two places where I know that visual design tools are used; the first is QT Designer
I think we should make a difference between visual coding and using a visual designer to make your graphical user interface.
Of course the later makes sense. If your output is visual, working with a visual tool is so obvious a choice. But that's not what we're talking about here, in this we're talking about making a program by drawing connections between boxes.
Assorted stuff I do sometimes: Lemuria.org
if you represent a class/function/method/etc as a "black box", you can break a complex program down into levels.
Sure you can.
But then you are not gaining anything, because what you have is a graphical version of
because, you know, when you write a complex program, you already break things down that way, just like you write, into classes, methods, callbacks, macros or whatever. So you already have the black boxes, they're just function names instead of pretty pictures, but it's the same thing.
Visualisation is a net benefit if it does something that a text doesn't do. It has many places. For example, the somewhat-famous pie chart that shows how many scientists agree on climate change has a much more powerful emotional impact than the number (97%).
So when visualisation gives you a better understanding of the relations - as it can do for database design, for example - then it's useful.
But when you go making black boxes, you are hiding the exact details that you would benefit from visualising.
Assorted stuff I do sometimes: Lemuria.org
The answer to your question is: money
Code exists as a way for humans to talk with the computer in a way in which the computer understands what actions to take in what circumstances. Each generation away makes code easier for humans to read and use and (generally) more expensive and specific to implement. Adding a visual layer on top of this is another expense.
It has been done. It will be done again. Most likely very specifically and probably quite badly. A lot of programs can be introduced when putting another layer between the programmer and the machine. webMethods is a good example of what not to do. CA Workflow is another.
Coding with a 2GL or 3GL or 4GL directly in text is currently the most efficient method for achieving the desired results. Existing systems do the job well enough. New systems are expensive.
In many cases it is a 'build it and they will come'. Quite a few attempts have been made to make GUI programming language interfaces; in particular for workflow applications. It gets messy quite quickly. Take a program which has 900 lines of actual code (disregard comments, headings, etc, just the raw code). Translate that into a diagram and then try to debug it. Print out out? On what? an A0 printer?
Visualise a program with 100 calls in the main. How would this be represented on the screen? Would each call open up in its own screen? Would you spend your time scrolling around looking for bits and pieces?
Have a read of https://en.wikipedia.org/wiki/...
If you want a practical idea of why it is not feasible then have a look at some of the existing examples of visual front end for code generation.
I have used a CASE tool to create a system for a project. The first month was not too bad. After a while traversing through the screens can really get to you. I found that many people had printed copies of what the program had so they did not lose track of where they were. Humans can only hold so much in their mind at any one time. At the end of the project the system would not 'balance' and finding the 'bugs' was an absolute nightmare, one which involved using the existing solution as a basis and redoing the whole thing from scratch from the bottom up. If this happened in the corporate world the tool would be out the window very shortly.
As another example, I have used a Workflow tool which had a graphical interface to define the rules for the workflow engine. Great. Except when it didn't work. Or did something in the output which did not match the graphical interface. Or where it just plain did not match up. In the end I ran SQL queries on the database to the rules table to write the rules I needed.
Another example of using a graphical method for programming instead of text is Atlassian who removed wiki markup from their flagship product Confluence. This resulted in a huge backlash in the corporate wiki arena with many still bitter over the loss of the ability to write code in text. Atlassian have since somewhat recanted and users can now enter code as xml markup. It is a good case showing that the flexibility of code can not be easily replaced by a gui.
You have a sick, twisted mind. Please subscribe me to your newsletter.
Richard Feynman: "Thinking is just like having a conversation with yourself." Friend: "Oh yeah(sarcasticly). Do you know what a crank shaft looks like?" RF: "Of course." Fr: "Than describe it's shape to me" RF: "..." Some concepts are better understood visually and some are better understood with text. Most textbooks have pictures and text. Can you emagine giving a contracter a set of plans written in text? One of the main obsticles to visual programming is it is currently used to teach coding. This is a terrible idea. In order to understand code you must have at least some basic concept of whats going on in the background. Visual programming abstracts this away. That being said, visual coding could be extremly usefull if you could use several paradigms at once, text and visual(s). For example you could start out your code with text, then insert picture that describes a controll loop. Inside one of the controll loop boxes there could be more text. Another box might contain a graph that in conventional programming would require a table or a seprate data file. Another box could contain a spreadsheet. Another box could contain a differential equation written in standard mathematical notation. Another box would be a visual layout of the GUI. etc... If you stick to one visual paradigm your going to make certain abstractions harder or impossible while making others easier.
I started with assembler. Very low-level. Then Basic, followed by Fortran.
Yes, these are outdated in terms of the latest fads of programming languages.
But they were simple enough that anyone who could follow logic could understand them.
When I learned Pascal, and then C, then C++ it was a steeper learning curve, but doable in less than a year.
With the advent of 'abstraction', manifests, templates, and more - the learning curve has become
a 5-year process to become 'fluent' ( a verbal language comparison). Yes, it might be OK to
make things more complicated than they need to be IF THERE IS A REASON! The reason might be
to make more money, or to ensure that only genius-level people can understand the programming...
But I suspect it is because of Hubris ( ego-asshats ).
[ Microsoft is guilty. So is Oracle, Intel, and others
I've seen hardware engineers print out images of chip designs, but they weren't looking at track layouts, they were looking at transistor densities. The image looked like a a density map of a large American city, with empty space in white, low density in green, medium density in yellow, orange and red, and high density in gray and black. I saw what looked like a exclusive leafy-green street surrounded by green parks. Like a sadistic urban planner, the engineer said, "oh, those are multiplexers, don't worry, we'll get them to move, it's costing us money to have a block like that, we like everything to be high density".
Vintage computer adverts: http://www.vintageadbrowser.com/computers-and-software-ads
The reason is related to bootstrapping. The computer runs its instructions, you have to still have a translation from what ever layer over it to the form the processor handles.
Yes you can use images and graphics that represent functionality and bolt things together. But customisation will still be required and that will probably fall back on using a keyboard. And that same abstraction can be turned into another graphical representation that just happens to be built from a few quickly entered taps on a keyboard such as "map(some_function, some_data)" - that for someone experienced in their chosen language assuming it is expressive enough to have an equivalent is able to be typed in about as much time as it takes to reach for the mouse and start moving to the appropriate button to click or icon to drag.
When you add context sensitive completion in your chosen advanced IDE filling in items is made even quicker.
Then when you need to drop to some lower level to create some new abstraction you are already there.
What's lacking in text based coding packed with powerful abstraction (increasingly so in newer languages to the point I see lots of good programmers reinventing rather than learning the facilities already there - shows there could be too many) is the strategic overview. That is where I think good visualisation tools come in. People scoff as outdated things like Data Flow but it's the kind of thing that gives a good overview of the system but every tool for that or (to me the rubbish) OOD tools fail to give an easy flow.
The failure of linking code to the design adequately is probably that too much code even on large things like GCC are hacked together (I mean coded) rather than as is done in places having a design at the top and the functionality in each region coded. In other words decomposition because in reality no one person can understand the details of each area along with seeing and reading all the lines of code.
What I'm getting at with the design separation from coding is that up to a point just code with the powerful abstractions in text form is more than adequate for the job. It is only when a system passes a boundary of complexity that the graphical overview grows valuable. Even then you can probably represent the assembled system textually more than adequately using another form of abstract, but still textual, representation.
Finally there's a practical difficulty. We still mainly use keyboard and mouse. Personally I think that will always trump touch and visual input and only be surpassed when we start wearing communication caps and think to interact with the computer (I'm bypassing speech input as always being pants).
Even then the writing of the requirements will probably best be done in text! With overly ambiguous words automatically rejected by the "compiler".
But I see your point and agree.
This new design is terrible. What happened to the classic site?
Please bring it back - the discussions are why many people come to Slashdot.
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 don't think that's really the reason. Quite the opposite, with proper graphical tools you could build far more complex things then with flat text. As those tools could allow you everything text can do and a lot more, as you aren't restricted to simple serialized textual representation of the data you deal with.
Anyway, I think the whole graphics vs text debate is getting a bit ahead of itself, lets take a step back to things we already know and use every day. Take some simple shell code like:
cat file | grep "foo" | sort | uniq
Now try to reproduce that simple one liner in your favorite programming language. Can you make it that easy to read? Is your recreation as powerful as the original shell code (i.e. capable of running in parallel, easy to modify, etc.)? The answer to both of those would be "No" for almost any language out there. The code would not only get far more complex, but also far less flexible, slower and just downright miserable. Why is it that most mainstream programming languages don't have pipes or something similar as first class citizen? How can it be that some rusty old language from 30 years ago is far superior when it comes to such basic data flow and filtering?
It has been tried many times. I'm staring right now at a vintage box on my bookshelf containing the Amiga Vision program, which was precisely that sort of drag-drop-drool tool. It was intended primarily for multi-media application development, and I liked it, but it obviously never shoved COBOL aside.
It's not the only attempt. I also have an old Scientific American on another shelf that features the Icon language, similarly illustrated by wiring together pictures of stuff. On a more modern note, I have a GUI tool named "Spoon" that allows me to design data extract/transform/load processes using the Pentaho Kettle utility. That one I'm still using, and fairly frequently.
There were attempts using OLE/COM and JavaBeans. Nothing ever became the "killer app-builder".
The primary reason for this seems to be that all of the GUI software design programs are doing declarative-style programming, and while declarative programming has some very powerful advantages, sooner or later you hit the limits of what wiring together pre-supplied components can give you in terms of function, performance, and flexibility. And then you have to fall back to the old text-based modes, which ultimately convert into machine text (binary code).
Management would just love to find a true D-D-D software design tool suitable for general production use. They could get rid of those nasty old overpriced third-world programmers and go straight to untrained monkeys. Or draw out complex systems in their spare time on the back of a napkin and hand them to a flunky. After all, "All You Have To Do Is..."
But the Silver Bullet continues to elude them. No such tool has ever been found.
We are still writing text-based programming code for the same reason that we're still writing text mathematics. It's better. There are only two reasons why anyone might prefer anything else than text. One is aesthetics, which is plainly irrelevant. The other is dyslexia, which is a handicap (with all due respect). Programming will continue to be in text for the same reason that mathematics will continue to be in text; it is the simplest, most elaborate and easiest way to achieve what is wanted.
As you stated yourself, a notation is necessary to describe algorithms and functionality. Text based programming languages are such notations. In computer history many attempt have been made to establish visual programming. And DSL have been used to reduce and hide boilerplate code as well as concentrate on the problem and less on the implementation. All these method and tools provide formal notations.
A key argument for still using text based notations is the ability to code faster in text than in graphics and version control of models in an unsolved issue. Furthermore, you waste 2/3 of your time rearranging elements instead if specifying functionality.
LEGO is supposed to be able to build anything, right?
So how come all those kits in the shop have special parts in them? May kits have parts that are only used in that on specific kit.
No sig today...
FUCK BETA and oh BTW FUCK BETA. Nothing more to see on Slashdot, time to move along to something not redesigned for PHBs by PHBs.
Code is written for many purposes, and each purpose requires different constructs which are not interchangeable because of the hardware each is written to run on. There are purposes for client-server, desktop, server-only and mobile, and other more specialised. Each purpose requires a different code structure, and ultimately all code written for each purpose is very similar, which facilitates the creation of code generation tools and the use of 4GL development environments, per purpose. The pinnacle of achievement in the building of systems with the elimination of coding is provided by the Remedy ARS [ available from early 90's ], which is applied to client-server. To date, there is no equivalent in the areas of mobile, desktop, server-only or any other coding purpose. There can be no one method to create all code for all purposes without writing actual code, by virtue of the underlying differences in fundamental functionalities.
You share the dream of every Marketing department in existence. Can't we just get rid of those unfashionable expensive guys who write all that cryptic code stuff?
The problem is that everything that can implement complex logic becomes programming, at some point. And for some reason it's actually not more efficient to have your Marketers become programmers in strange, clunky, non-standard languages, instead of spending their time, oh, I don't know, actually doing some marketing.
There *are* graphical dev tools out there ( check out ETL and workflow designers for example ) but sometimes, writing 10 lines of code is more efficient than putting 10 widgets on the screen, drawing your connectors, then setting up your variables. ( plus the run-time overhead )
It all depends on what you are doing.
---- Booth was a patriot ----
We write text based code where it is suitable. Automated code generation from graphical system models or data flow models is in heavy use. Simulink/Simulink coder (translating your system model to c) and Labview (which compiles to LLVM internally since about 5-6years) are selling well.
In the domain of their applicaiton (generating safe/stable code from an easy to understand system model) these products are excellent.
I used them both, *but* (and this come from somebody who drew a webserver in Labview): Outside this domain, these tools suck. As soon as you need multiple interitance/easy code maintainance, you are screwed. There is no facility in these graphical system models like an abstract system model, or subclassing etc, for the very simple reason that these are difficult to represent graphically. I have seen dozens ov labview programs which could be written with a single component changed, based on the same parent class. I have sen people manually redrawing and changing simulink system model for very little change (which affected different subsystems). So maintaining any big/complex/flexible project sucks and requires hundres of pages of diagrams.
And that is the reason why we still use text bases languages.
Sure, you can write articles without a community but what's the point? Fuck beta.
Jello - the answer is simple. Try to translate your Slashdot submission into a graph of emoticons and pictures. You're free to use any emoticons/pics you wish or create your own - except using pictures of text of course. Then post the result for us on some web site and a link to it here. We'll post what we made out of it.
I've been back and forth over the graphical vs textual space, and it comes down to conciseness: Visual works OK for a program's structure, but is lousy at the details needed to describe the actual data transformations. You can get a lot more bits of programming instruction per square millimeter of screen with text, and who wants to spend their lives scrolling?
Also, text works very well for automation (overnight builds, test scripts, etc) and code sharing. To date, no visual representation comes close for repeatability or standardization.
Nobody designs chips by drawing schematic diagrams. That is all done using VHDL or Verilog languages today - schematic is simply unusable beyond certain amount of complexity. You cannot design a modern CPU or a memory chip which has few millions of transistors/gates by drawing them on a circuit diagram.
Those CAD systems you mention are used to do circuit board layout - which is a very different type of problem.
One aspect that is really necessary when _maintaining_ software is the ability to understand _completely_ what it is doing. In other words you need to see _all_ the code. Visual Programming usually hide stuff. You attach a listener to an input field in a GUI application which need to do something - where do you see this when looking at the visual programming tool?
Also the problem is similar to why we do not see something more powerful than SQL for accessing databases. You simply cannot cover as much as concisely with a GUI (because you need to anticipate everything) as you can with a text based interface.
sorry jello,but you will not get a sensible answer on here,/Â has many problems,in your case you are asking a bunch of self interested,self protecting "professionals"how to put themselves out of business. you will not get many sensible answers,too many already hanging on by their fingernails as they are finaly made responsible for the usual rushed,badly done,over hyped over priced thats popular this month
_ gui interfaces
_ gui db tools
_ gui class visualization
_ auto complete
_ some uml tools allow you to prototype classes.
Programming can be as visual as you want it to be. no, this is not fully visual because it does not make sense - it is not because you have a "smart phone" that computers are smart enough yet :)
my personal question is why are most language still ascii and resort to external library for i18n strings
Never antropomorphize computers, they do not like that
You can't meta-program in them.
In current text-based languages, if I discover I am writing a certain sequence of steps over and over, with slight input variations, I can write a program that will generate those steps for me, making it easier for me. ONC-RPC is an example - you specify the interface in a domain-specific language and run that through rpcgen, and you get out code that you compile and link into your other code.
You can't do that with graphical coding systems, because the information is either too abstract or absent. How do you specify that these input values are expected to be integers instead of floating-point? How do you describe the input-sanitization routines needed to prevent a "Bobby Tables" attack on your website?
For the same reason we still write words, not images, to translate an idea. Why are you typing words here? You could draw a picture. Sing a song. Make a movie. But are still writing english sentences. Why?
There's a graphical programming language that's existed for quite some time. It's calls SDL. As somebody who has had to maintain programs written in SDL, all I have to say is anybody who pushes more towards a programming model like SDL deserves to rot in the deepest darkest pits of hell. I honestly hope that a whole new ring of hell was created specially for the jerk-off who invented that crime against humanity.
Graphical languages sound nice in theory. Then you actually get subjected to it. No. Just no. I spent two and a half years in that hell.
And if you stop and think about it, it makes sense. We don't communicate in pictures. We communicate in words. And written text is the graphical representation of how we communicate naturally. Books convey much more complex and intricate stories than movies do. Why, because it's very difficult to make something complex and intricate visually. Movies based on books tend to suck, because they're trying to convey a more complex story than what movies are typically conveying, and as such typically have to throw a lot away. Seriously, a challenge. Make up a picture that says what I just wrote. Do it in less time than it took me to write this, and do it in a way that is less ambiguous than what I've written.
Umm .. Mozart did have 12 notes to compose with.
You sound like people back when high-level languages were introduced. Granted, the first high-level languages sucked and forced you to escape to assembler or lower from time to time. Today, we have abstractions that are better than people in most cases, and we only need to escape to assembler for very tight loops where we have more information than the compiler can know.
As an example, consider the goto/jump statement. In the beginning it was necessary, but then structured programming was invented. It's much easier to grasp and far less error-prone. There were still cases for goto, such as early termination and error handling. Enter break/continue and exceptions, which make those cases irrelevant. Now, I'd say the only case where goto is marginally useful is to jump into the middle of some code (e.g., common execution but different parameters). More or less like a faulty switch/case where some idiot leaves out a break. It's shitty code style, though, confuses the CPU, and can be emulated by separating your code into multiple procedures.
Same goes with smarter programming. Some advances are made, but we're not there yet. For example, the Eclipse Modeling Framework makes it heaps easier to create standard object structures. Write the interfaces or use an UML editor, and get a complete data-structure with notification mechanisms. The code is easier maintainable, editable and decently efficient; heck, the notification mechanism is more efficient than what most programmers would come up with.
I have also seen systems that aim to handling the concurrency part of MPI applications. You specify your architecture, your network layout and the basic components of your application. The framework handles all of that stuff for you, so you can concentrate about the easy part of making sure that your non-concurrent code works. Again, this is a domain-specific tool that helps making a ridiculously difficult problem much easier. Fast prototyping with a reasonable implementation for experts, the mere possibility to do it for non-experts.
User interface editors. Heck, even object-oriented UI elements; if you ever tried making user interfaces in the early mid-nineties, those are a time saver on par with a machine gun in a supermarket.
I have also seen systems I do not believe in, but who try interesting approaches to make programming easier. Take for example the Graphical Modeling Framework, which automatically creates utterly shit graph-based editors for EMF models. The idea is sound, but the execution is sort of lousy. For a much more esoteric system I doubt many here have heard of, consider the Play Engine (different from the Play Framework; if you wanna look it up, throw in the name David Harel in your search). It allows you to create a GUI and by showing the system what you expect to get out from it. It allows you to make simple applications by show-and-tell. At least in theory; in practise it is too computationally expensive and limited. Still an interesting idea.
Myself, I've been working with a graphical modeling formalism called colored Petri nets. It allows you to abstractly describe the flow of a concurrent system. It is not intended as a programming language, but for specifying complex behavior. It is an ongoing and active topic to go from such abstract descriptions to (skeletons of) executable code. Recently, I've been working with another formalism, where you don't even specify how to execute your system, but merely constraints (e.g., can't be in a critical section more than once at a time, transmitting cannot happen before encryption, and so on). The system then derives legal execution plans. It can detect potential future conflicts and automatically avoid them. Sure, it's still work in the early stages, but with time it'll get there.
Why are we still writing text-based text?
Why are we still writing text-based communication?
Why are we still using languages with words and grammar and syntax?
Why aren't we communicating with pictures?
Why aren't we communicating with thoughts?
Why was this story posted on Slashdot?
"Those who consume the bulk of goods are those who make them. We must never forget this secret of our prosperity."
And neither should anyone else. Nothing in your post is correct.
All complex things evolved from simpler things.
Hey, it is already possible to program VCR to record my wanted show at day without me ever using any text-based coding, so it definitely would be possible to program a computer do programs when I am wront of the computer!
For the TL/DR: graphical programming is inefficent, and error prone; better methods of viewing source code during read-back is more interesting.
Apple has the Automator, which takes actions and chains them together. You can define variables, and operate on them.
I used to work with an enterprise software called Adobe LiveCycle, which does business process automation -- the approach was that rather than defining the business workflows in a chart diagram, and handing it over to a programmer to implement, the diagram itself WAS the program - business workflow designers (often managers and business consultants who were not technical) could build the workflow as individual steps, and more tech savvy people would add the variables and stuff to make it work.
A quick search on Google images turns up a lot of interesting stuff, including this graphical programming tool . The techniques have been in the making for a while.
Needless to say, even with these visual aids, to get something worthwhile done, you need to have actual programming knowledge - the Automator is good for home use but cute at best in production environments due to lack of finer configurability, and the business process workflow programming I mentioned still required in-depth computer knowledge: the workflow creators' work was often computationally inefficient, and often had to be refactored to take into account finer points of logic flow from both efficiency and data management points of view.
On top of that, it's easier to search on the Internet and on forums for code snippets, and discuss these when they're already in text form - no programmer actually works in isolation, communication is essential. Some advantages in reading back code might be had in graphical representation, and certainly creating a "visualization tool" for reading back code or designing high-level ideas might be helpful - but making it the implementation language is probably a bad idea.
On that matter, I recently came across the LightTable IDE which facilitates programming by doing live demonstrations of what happens to variables directly in the code flow. This also catches syntax issues early, bad type casting, and other relevant issues. Much better than a graphical abstraction I think, but that may just be preference.
The linked article indicates that visual programming has had success with casual creators in very specific scenarios (education of young kids, and use in LittleBigPlanet) - not in the general purpose programming arena for business critical solutions, high throughput systems, etc. Also, it says nothing concrete apart from "it's a matter of opinion" - nothing about the advantages or disadvantages of either.
Ultimately, it's like asking why bread shops don't use bread making machines. Tools for the job, tools for the desired outcome. If the simpler method works at home, that's great - but if you want to work professionally, the more sophisticated method yields better control over the final product.
-- "Simplicity is prerequisite for reliability." --Dijkstra
Same reason.
You claim classic is still here, but I CAN'T FUCKING USE IT because it fucking redirects to the goddamn beta.
As a software engineer, you've taken the effort to generate requirements document, various module development plans, a high level design document, multiple interface control documents, and finally begin to codify the design. Now, graphically embed the essence of all those documents into intermediate object files, link them together and swear on a rack of Sun Solaris Manuals that you can support the product for the next ten years.
The answer: you can't. Tools evolve and die off, while text-based intermediate files are infinitely easier to support in the long run. Imagine what happens when your current version of LabView falls out of support and you have new requirements or a critical problem to resolve and your only machine with LabView has died a horrible death taking your hard drives with it.
Or better yet, developed test programs using VB 6.0, and woke up in a new millennium where your application no longer works on a Windows 2016 machine. What to do, Bunkie?
---
Do you REALLY want to have a George Jetson job making sprockets with your one red button? Steve Jobs said YES and created the iPod.
Mike, I agreed with you until I read the rest of that comment The idea is with a simple interface the complex details are hidden, hence the reason you don't find many quality apps written in Visual Basic and even then it has a text based file to tweak the details theG UI can't quiet get right (forgive me if I messed up the details, I haven't used VB since version 6), but the same applies to the visual editors for C/C++/java, they have a text file to edit with GUI tools to rough out .
Now I fell like a GUI is a bulldozer to make sweeping changes, and the source code is a scalpel for the fine detail work.
#getoffmylawn #fuckbeta
"The reason programming languages are still as they are is for a simple reason, because you can't produce something complex with something simple,"
Generally speaking, in thin universe, you are utterly wrong.
ALL thins are made of simpler things.
The only way to make something more complex is to make some simpler things interact.
I think part of what your missing is based on your own self-described lack of experience.. that you can write simple programs but get bogged down writing more complex stuff. Professional programmers don't really have this problem (or at least the experienced ones don't - there is a learning curve as in any field).
The main "trick" to designing/writing complex programs is to be able to think at many different levels of abstraction and therefore to "divide and conquor" the complexity. At each level of your program (think of it as a layered onion from the highest level on the outside down to the low level stuff of simple programs on the inside) you're going to be implementing one level of complexity/capability by using software components that are essentially only ONE level lower in capability than the level you're at... ditto for the next lower level, etc, all the way down. Designed this way, it's no harder to write the highest levels of the program than it is to write the lowest levels that you are familiar with.
Note though that the software components you're using at any level of your design are going to be domain-specific components that you've designed yourself to make the job easy - they are not going to be 100% off-the-shelf components (other than company internal re-use), other than at the bottom most layer of the design. It's having the right components that makes the job of implementing the next layer up easy (like the idea of the adjacent possible - without having "adjacent" components the corresponding "adjacent possible" is NOT possible, or at least is way more difficult). So, the real issue is not whether one is using a visual vs text-based method of composition but rather in having (creating) the right components at each level.
It's also worth noting that since programmers are the ones with the skills to create programming tools that we therefore necessarily have pretty much the tools we need. Good programmers are lazy (strive for minimalism), and arn't going to fight the same battles every day if they can build a tool to make their lives easier. Of course there's always a bleeding edge of new technology where the tools havn't yet matured (e.g. now that clock speeds are topping out and parallelism is replacing it, there's more need for better tools to deal with parallelism), but basically we DO have the tools we need.
Why should programming require a better command of logical constructs and clear thinking than being a member of the U. S. Congress does?
Yes, there are benefits unique to text representation.
But if you look at the context, I'm not arguing against the written word (see note here: "Perhaps, a printed executive summary of bullet points in your hand.")
I'm saying is text is just _one_ mode of interaction - it shouldn't be the only one. Effective multi-mode interaction is always better than single mode. We are full-spectrum creatures.
And people had been trying to build better buildings, keep secrets more secure, create deadlier weapons, for millennia, not just 60 years. There are have been a bunch of great and beautiful (and ugly) solutions found all through this time.
... and posted a Journal article about it a couple months back. Yes, folks, it IS possible to create a general-purpose programming language which can be represented, and written, graphically. As more and more devices sport touch-based interfaces, this will work even better. The main reason we're still writing code with text is because programming involves a lot of complex, inter-related data input. And, for now, the fastest, most efficient mechanism we have for putting lots of complex inter-related data into a computer is ... text.
... by the Dew of Mountains the thoughts acquire speed, the hands acquire shakes, the shakes become a warning
Prograph, anyone?
http://en.wikipedia.org/wiki/Prograph
Most non-trivial programs can be drawn as diagrams at a conceptual level, which is probably the level you're talking about when you say you "think about algorithms but don't program" (I'm paraphrasing). Sounds like you're looking for an excuse not to learn programming. As soon as you do the answer to your question will be obvious: there's so much detail and complexity in a real program that a picture can't capture the information in a succinct way.
Sure, you can actually describe every variable and data structure and nuance of any program as a diagram, but it's going to be very complex and unmaintainable (ie very messy to debug) and have a lot of text in it to describe exactly what you want.
Some programming languages can be very good at simply defining certain types of programs - APL can do some awesome matrix and vector calculations in a few lines, or Perl can describe some very complex data manipulation in a few lines. In both cases you'd spend much, much longer describing it in a diagram that includes every nuance of the program, or trying to describe them in sentences.
All these things are self evident to programmers. They know there's fiddly detailed things you have to do in C or Assembler sometimes, or graphics that easier/faster done in Python/Tk or text manipulation best done in Awk or Perl or symbolic manipulation best done in Lisp or whatever. And to those programmers those programs ARE the most efficient way to encode ("draw") the problem. Furthermore other programmers look at well written code and quickly build an understanding of what code is doing. Comments help her a lot, depending on the familiarity of the programmer with the kind of code. (eg a programmer specialising in interrupt driven driver writing for a living is going to have trouble understanding a program with simulates sonar echoes in water).
Again, bite the bullet, learn how to program in a few languages and all this is obvious.
Then there's complex systems that can be described AT A HIGH LEVEL in diagrams, but the caveats and exceptions and nuances to describe it fully might cover 1000s of pages, or much more, of design documents. In many cases the final programs of hundreds of megabytes of definition documents (like an autopilot system I worked on for an air force jet) ends up much bigger than the final source code (and then the final programs are way smaller again).
Stop pussy footing around though, teach yourself to code and write some substantial programs (at least a few 1000 lines, but probably a fews 10k lines) and do that a few times, then in a few languages and you'll understand coding these days is pretty efficient. I'm sure it'll be improved upon but for now you'll get insight into why your question so obviously shows you just need to learn how to program.
pithy comment
I mostly write C and C++ code these days, but I've worked a lot with guys using Simulink and Labview. Both are good tools, but like any "programming" language, there are issues. Some of them stem from the lack of software processes being used by people who have never been exposed to a typical software development process. Simple things like version control, or "code" reviews. My experience with Labview in particular, is that the ease of changing the graphical representation encourages people to quickly tweak something to make it work. I've ended up in the situation where I asked what they changed to make it work, and they can't tell me. This is as much a lack of rigor in the process as it is in the people using the tool. They can often do amazing things, and quickly, but they tend to be difficult to maintain.
My experience with Simulink is a little different. The guys working with Simulink tend to be domain experts, often with PhDs. They really know their stuff. When they can generate a good model of the system they can do AMAZING things. The downside is you can spend millions of dollars developing and validating the system models. It is why you see Simulink used in projects with tough control systems problems, which coincidentally often have large budgets, like the automotive world.
Sometimes, the code generated by SImulink isn't efficient, which can drive up memory/CPU costs. When you are shipping hundreds of thousands or millions of a product a year, adding a few cents per unit really adds up. Sometimes the cost of spending an extra million or two writing the code in C(or optimizing the Simulink after the fact) is worth the expense. My opinion is that tools like Simulink will eventually take over the control systems market.
Another reason is cost. You can get a C compiler for free. Matlab/Simulink is a 6-figure expense per developer. Labview isn't that expensive, but it is still not cheap.
You appear to be thinking about a very limited subset of software where the essence is captured by the "two dimensional" control flow.
As Fred Brooks famously wrote: "Show me your [code] and conceal your [data structures], and I shall continue to be mystified. Show me your [data structures], and I won't usually need your [code]; it'll be obvious.''
Nowadays he probably would have updated that pithy formulation to include mention of your threading model as well as data structures.
If you start trying to visualize the dynamic behavior of complex synchronization-heavy multi-threaded programs or ones with significant non-trivial shared data structures, then I can assure you there'll be plenty of crossed lines!
The time when most programs could be described by flowcharts was probably 40 years ago. We've moved on a bit since then!
B'eta is more than cosmetics or aesthetics. The new design ruins the one thing that makes /. what it is -- the commenting system. I only come here for the comments, not the 2-day old articles nor the erroneous summaries.
I do not see the changes of B'eta as improvements. What is wrong with Slashdot that demands breaking its foundations? This is not change for the sake of change, but, as others have commented, an attempt to monetize /. at any any cost, and its users be damned.
Our complaints have fallen on deaf ears, and will continue to do so. Dice intends to dispose of Classic in favor of B'eta, whether we like it or not. Do you know how to tell whether an executive really cares about feedback? If her CV doesn't already proclaim these changes to be a success even before fully implementing them:
Proven track record innovating and improving iconic websites (CNET.com, Dice.com, Slashdot.org, Sourceforge.net) while protecting their voice and brand integrity
Correct me if I'm wrong, but apart from an almost universally hated B'eta version, how can anyone claim in good faith that /. has undergone any change at all so far?
Will the trolling never end?
This is for the Internet n00bs out there (the 99%) who don't know that trolling has nothing to do with trolls... /. article is all about.
https://en.wikipedia.org/wiki/Trolling_%28fishing%29
Fishing for comments or a response to make OP feel important.. which is exactly what this
There's a platform out there called Mendix. The management a work decided to use it, and paid millions to do so, prior any programmer being out in the project. It's a quick hit application platform where almost everything is done visually. (Think flow charts with some conditional expressions). It's horrendous. It takes at least 4 times as long to get something done in it. Basically it 'a all graphical. I found the person that trained me knew nothing about actually programming languages. Wasn't even familiar with CSS. All I know is the more layers we dump on top of things, the less anyone is going to actually know how it works at the bottom. That to me is scary.
Why did you submit your question as written sentences? Surely you could have expressed whatever you're asking, by carving a few notches on a stick, taking a picture and posting to imgur.
I lack the patience to try to figure out what you're trying to say, as text. Ask again, in stick, where we can communicate more efficiently.
As copyright owner of this comment, I authorize everyone to defeat any technological measure which limits access to it.
The reason you havent met anyone who prefers editing code graphically is because there isn't a good graphical code editor. The reason there isn't a good graphical code editor is that programming is an immature profession, as are most that deal with high technology, and that minds change slowly. I guarantee you we can get more, better code into the computer with less chance of error by representing the code in more elegant ways. That is to say, representing it in ways that are more easily processed visually, that convey more infomation with less noise -- with more easily identifiable patterns. IDEs already do this. They bring the code to life with interactive menus and highlighting. There is no reason that the info represented there always has to have an ASCII, syntactically complex equivalent.
Likewise, you use words to form a sentence to accurately describe an object (var) or order it to perform an action (function).
What you're proposing is for coders to use emoticons to create programs. Those are unreliable, and generally speaking, every receiver will have a different interpretation to a winking smiley face.
That will take us back to spaghetti code and duct-tape problem solving instead of concise precision.
In short, let's no go back to the time when surgery was performed out in the field with hacksaws and a bottle of liquor.
Blizzard's RTS games come with a level editor that supports advanced scripting. You can use the GUI to make scripts without actually typing anything. It's nice for simple things, but it's really just dressed up text. Once you have a bigger function or need to do refactoring, you really want to edit the underlying text. Somehow I have a hard time imagining a graphical paradigm that would give the flexibility for editing that text does, and I think visualization of code is better as a debugging tool, not a writing tool.
It makes sence for some domain specific languages. Spreadsheets, GUI builders, and Flash builder are great examples. In general, imperative languages are difficult however declarative non Turing complete languages works better. An aspect to consider is tooling and collaboration, how to handle merge coflicts etc.
Why do we still use letters, punctuation symbols, the Greek alphabet, and upside down A and E in mathematics? Some things are abstract, and symbols are the best way to express them. Look at some geometry, which is so abstract it can't be visualized using a drawing. People resort to the symbolism of category theory and set theory to express non-visual geometrical concepts.
Then again there's Query By Example, the Borland Paradox abomination from the 90s - when was the last time you heard about it?
It's certainly possible to do. But I don't think it works very well. The problem is that in introducing a graphical design, you introduce additional constraints on the design that are extremely artificial and are only due to the schematic nature. When designing circuits this isn't an extra constraint, because the final product has those exact same constraints.
I've also found graphical UI's for generating programs or parts of programs to be much more cumbersome and slower to work with than scripting languages.
IMO, what the original poster wants is something like object oriented programing of some type, which is, as several have pointed out is much more restrictive than liberating. Think back to HyperCard/HyperStudio - this environment was supposed to allow everyone and their dog to create "stacks" of cards and open programming to the masses. It soon showed itself to have crippling limitations that real coders tried to expand by creating shims and add-ons that allowed for more capabilities, but again, the environment was always a poor shadow of what could be accomplished by a real programmer.
To accomplish what the original post wants would take almost a savant understanding of the state of all the registers of the processor in question at all times in a process - so the 'programmer' could create a sequence of commands to control each component and "break the rules" of structured programming when needed - but the issue with "breaking the rules" is - you might invalidate the algorithm if you don't 100% understand what you are doing. Programming would turn in to: enter data, some magic happens, and the result may be valid or not. Structured programming helps verify results keeps us from breaking the rules and allows computers to be trusted to manage and process our data.
As far as the limitation of text - as many replies here have pointed out. The English language gives us the complete works of Shakespeare, the complete works of the Beatles, and yes even the tripe of Brittney Spears and Lady Gaga. It is a massively complex symbol system that is capable of wonderful nuance and can be combined in endless ways (although Hollywood seems to be lacking in original ideas - as remakes of the Beverly Hillbillies and Brady Bunch illustrate, but back to the point). I learned to program and when one language would not do, I went to assembly code and even hand coded in machine language when needed. Choosing to resolve a programming problem with a menu of pretty pictures would have been more limiting, not more liberating, as it would just call libraries of some other programmer's code that had no clue what frontier I was trying to explore.
Anyway, back to the point. I find programming with text based programming languages quite satisfactory and augment it with the snippets of code created with tools closer to the processor, not further away and more abstract.
I used to think since I could program everyone could, if taught correctly. I used to think everyone could be creative and solve problems in new ways (this is where the assembly code typically came in), but I eventually learned this is not true, either. Great programmers are creative masters of their art (such as Shakespeare or Mozart) and regularly see elegant relationships and solutions mere mortals may only glimpse once or twice in their lifetimes. One cannot package such greatness into libraries and OOP icons.
I remember the first time I was able to reimagine a programming solution in such a way that eliminated hundreds of operations into just a dozen or so. Such a feeling to have such an epiphany! But unfortunately I am one of the many who get lucky and can emulate the great ones once in a while - so programming stays my playground, not my field of work. It does help me appreciate the work of the masters when it occasionally appears.
" "I consider myself someone who 'gets code,' but I'm not a programmer. "
You are half correct.
i'm no programmer, but doesn't the compiler translate the high level code to machine code so that the CPU can understand?? and the high-level code written in C++, Visual basic.net is text-based code? Visual studio compiles the code in intermediate language, then the dot net runtime runs the IL. I must be missing something
...then you don't know enough about programming http://en.wikipedia.org/wiki/D... . For your own sake and sense of satisfaction I suggest you pick a new hobby or allow yourself some time (>10 years) to fully get acquainted with the subject.
This. Artifacts that can be edited an put in a repo by any serious project need to be in a format understandable by quality diff and 3-way merge tools. Some automatic conflict resolution of trivial but unrelated changes in an artifact is also highly needed. IBM RSA (UML) has come some way here, don't know about LabView - guess there's some diff at least, but 3-way merge? Doubt it.
Never mind code generation, I would be glad/surprised if there was a structured graphics format with good diff/merge support! (not counting the language-based ones such as TeX/pic then...)
The problem isn't one of how the language is presented to the user/programmer. It is how they interact with it. We need languages that can allow the programmer/user to tell the system what they want in simple human terms. IE, put this thing there, link these things together, and put them therer. When once selects a and links it to b, then do the right thing! FWIW, I have a patent on some of this - adaptive systems. You tell the system what you want. It figures out how to do it. No programming required!
Apparently the GP only ever learned the C major scale. That's surprising for a programming-aware individual who should have at least heard of C#.
It's not accidental. The definitive work on the concept specifies eight notes. However, regardless of the specifics, the point remains: You can build highly complex constructs out of a small number of simple components.
When our name is on the back of your car, we're behind you all the way!
Hardware is relatively simple: there is only one kind of signal, a boolean. All properties of electronics, in relationship with this, are more or less known.
Now, most programs do not process simple boolean values, but characters, numbers, strings and combinations thereof. The way these things are processed, depends on their semantic values, something that must first be put into the computer before it becomes possible to even try to build a program generator (because that is what is done by graphical environments).
I have worked with different environments which generate code, and they are good for starting, but not good for building everything.
In code, the main mantra is: one fool can raise more questions than a thousand wise men can answer.
Software is limited by GÃdel's theorem: with one kind of consistent program it is possible to do what you want, but there will always be some wetware which asks something which cannot be implemented by such a program.
Well, I have tried to avoid coding from long time. We have worked on a code generator for building business applications. You can check it at http://ecgine.com We have build complicated business applications with it. It will be in continues development.
Now my problem is, I don't to write code for code generator also. I want to go one level above it. Now I am looking for some reasoning system where it will know how to write code and I will ask it to write. I am looking at some AI system for it. I know I will do it, not sure how long you have to wait for it.
As a professional software developer, I would never use something graphical over text because its just more efficient. Try teaching someone to program visually _using a keyboard_, since you know, one handed programming with a mouse is clearly so efficient.
I think we should get rid of all writing. With all of those spelling and grammar issues to contend with, I think writing is too hard and too error prone. Since I suck at writing, I can't imagine that anyone else finds it useful at all. We should move to pictures and video for everything. With technology being what it is, what's the point of words anymore?
-Suck my DIckens
I see three problems with automatically presuming that any meaningful code for a compiled program will include a graphical interface.
That said, programs that I write for my workplace perform 100% in the background, and do all their work on large data files. What needs to be graphical about that? Would it really be that useful to quadruple the size of the code base for a program just to add selector boxes for input and output files, and a status bar?
That's as far as I go.
All the world's an analog stage, and digital circuits play only bit parts.
Fast vs precise vs versatile
... precision.
You can hum a tune and record it on your phone.
Why do we need musical notation then?
The answer is
I like the Python/Ruby approach: do more with less code. That's the best it can get.
And if you really really want to code using fancy blocks and rectangles (like those in flowcharts), imagine the nightmare those malformed graphics elements arranged in ever increasing network like layout with exponentially increasing connections will cause when much easier things like syntax highlighting sometimes sucks.
Code visualization and visual coding may be used as a secondary aid.
Mainstream languages do something like this: uniq ( sort( grep ("foo" , cat file) ) ).
AS the 'responsible engineer' for nuclear safety systems.
Fuck digital, fuck code.
I think you'd end up creating a graphical functional language, at least all the "primatives" would be similar, map, filter, let decomposition etc.
If you switch text commands for pictures then instead of memorizing syntax you will have to memorize pictures and combinations of pictures to achieve certain results. In the end you are left with the same.
It's not Beta fucking up Slashdot, it's you fucktards trying to hijack every story that are ruining it all for everyone else.
The above statement is obviously wrong. You can write poetry, law, philosophy, religion, and software with a piece of charcoal and a stack of paper or other means.
If we are using text-based tools, that must be because all the available tools are text-based. By any means develop your systems graphically in UML or whatever, and then maybe 'compile' this yourself into a regular programming language.
On the other hand, you would not want to code in 'Visio Basic', where you painstakingly have to draw flow-chart symbols for various control statements, which are compiled into old-style BASIC afterwards.
For problem-domain-specific programming languages, it's fine.
I worked with an HVAC control system that used a graphical language. Here's the marketing brochure for it. If you look at that brochure, it shows a graphical program, then it shows an equivalent program in pseudo-BASIC. And if you notice, the best part is that everything is a watch variable when the program is running and you're monitoring a live system. That's why each "microblock" has little yellow numbers or words next to it. That's the current value coming out of that part of the program.
It's a very well-thought-out system for the specific problem-domain it's in. And I think that could be true of a great many other problem-domains. This is where graphical programming can really shine.
But general purpose programming is always going to require more rudimentary, low-level tools than that due to its nature. Think of it this way: Somebody had to use a low-level language to program that graphical language. It will always be that way. You can't build a house without digging a hole. Somewhere, someone has to work in the dirt to build a house. Somewhere, someone has to work in machine language to build a software program. Thankfully, we have compiler authors. They're the earthmover operators of the software world. Nothing gets done without them, what they do underlies everything we build, and if they mess up, then everything we build is unstable.
Mozart had the Chromatic scale.
"... but I get bogged down in more complex code..."
It sounds like what you're saying is, "I don't like the rules of this game so can we change the rules?"
curly braces { }, indentation, carriage returns, and a good imagination
For the same reason we write novels and text books in English.
Information density is much higher with text.
Mike
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.)
Was that a Smalltalk IDE? From the description, it sounds a lot like one...
The more simple you make it the less complex it is
Did you come up with that all by yourself?
What's wisdom will you bestow next? here are some suggestions off the top of my head:
"the more warm something gets, the less cold it is",
"more light leads to less darkness",
"as something dies, it becomes less alive" or
"as things speed up, they move less slowly"
Thank you, Captain FormulAiC.
"Lame" - Galaxar
http://www.youtube.com/watch?v=n4LDVrnAQeo
Probably the same reason we're still writing text-based novels.
system("...")
What you are describing is using a bunch of shell programs to achieve a simple task. Up to a certain level of complexity, these prewritten programs are the best way to accomplish such tasks. Thankfully, most programming languages both have many such predefined functions, as well as being able to call the system shell.
But yes, the shell is an environment where it is easy to get certain things done without the overhead of most languages. Heck, it is easier to write your script at the command line than to save it as a shell script (a type of programming language). Does that mean anything?
Use the right tool for the job. A hammer is simpler than a jackhammer. It can't easily accomplish what the other can, though. If you want to write a "program" that does the above sort, write it in sh, or bash. Oh wait, you already did!
Why do we still use words to communicate? For the same reason we program in a text-based language. We demand as much nuance in everyday communication as we do in software development.
Yes and that is far inferior to the shell version. If I have a file that's a few GB or TB in size, the shell version will run just fine (assuming the grep cut's down enough of the data), while your example will crash with out of memory. The "cat" program on the shell never needs to read the whole file at once, as what you are doing on the shell is setting up a filter pipeline, not just handing data from one function to another. Your average programming language doesn't have an easy way to do.
But that aside shell has many more benefits, such as isolated processes for example. If a program crashes on the shell, no big deal, you can just start another. If a function crashes in your favorite programming language, the whole program is toast. Your average programming language doesn't really have much in a way to isolate a function call from the next. Shell can also kill running processes, meanwhile you can't kill a thread safely.
Anyway, the point being here is that your Shell in combination with the OS provides you with tools that you cannot replicate within the realm of your programming language. Having a language graphical or not doesn't make that big of a difference when even such 30 year old fundamental tools aren't available to the programmer in the programming language. Programming language design is extremely stagnate and outside of syntax twiddling little has changed in a long long while.
And I know how to use them. I hade coding with a mouse. In fact, I hate text editing with a mouse. I'm a touch typist and every moment my fingers are not on the home position is an inefficiency.
I've used a modeling/simulation language that looked to be an Excel replacement. Fro Excel, you can emulate, say, traffic patterns with cars in, cars out, and such, generating a text-only input and text-only output. For roughly the same complexity, I could draw it out, and come to the same results, but in a manner that makes it much easier to explain to non-programmers and quicker to make small changes to inputs and equations and see the results.
Given that the visual manner doesn't do anything you can't do elsewhere and only makes it more visually interesting, it's shunned by they technical people in favor of the text-based methods.
Learn to love Alaska
What you are describing is using a bunch of shell programs to achieve a simple task.
The task is very complex, it's just that the shell offers a very simple way to express it. As said, try to replicate shell behavior in your favorite programming language and you'll see that it is not simple.
Thankfully, most programming languages both have many such predefined functions
Calling cat, uniq and friends starts process, it's not just a function call. Processes unlike functions run in parallel. That's a huge difference.
Use the right tool for the job. Use the right tool for the job.
That to me is an excuse for shitty tools. There is no fundamental reason why a programming language couldn't offer constructs as powerful or even more powerful then what the shell has, yet they don't, as it apparently falls outside of the box in which programming language designers are stuck (aside from those Erlang guys).
Have you ever tried to actually visualize a data model that is from a real-world application, where you soon find that you need to draw hundreds of arrows all across the model? The technique that works well and gives you a really nice view for, say, a simple blog application or whatever the current tutorial app beyond "hello world" is, breaks down horrible when you're dealing with real-world complexity.
Here's a link to a few nice real world examples.
This is total bullshit. I've spent half of my career as a physical designer and the other half doing software engineering.
When you are doing layout, your primary concern is not functionality. You or someone else has already made the design in schematic mode and now you are just laying down the metal to match that schematic mode. No one doing layout is doing logical design when they are doing layout. You are more concerned that the logical design can be achieved physically.
Using text does not preclude you from working with black boxes that has input and output pins. What do you think a function is for? What do you think input parameters and return values are for? When I am writing code, I can wield the power of billions of transistors in one line. I can also go down to very low level register level programming and wield less transistors when I need to program CSRs or GPIOs.
Visual is not always higher level than textual.
What's really needed is a super-literate programming, i.e., programming that can most of the time be just like talking or writing. A very crude example is of course SQL. But in some future it should be like in Star Trek where you go "Computer, I want a list of . . ." That's basically a literate programming on steroids. Today, we have highly productive coders, mainly because the languages they program in have tremendous module/api/object/function libraries. But of course the coder has to be the glue-meister who knows the right library and can stick it all together. But then imagine a super-auto-complete where some of that coder-guruism is done by the software. Then imagine a literate dialog where the software tries to be the gluer entirely. That's the evolution of computing, IMHO. I'm sure you could call WolframAlpha a good example of this trend.
I'm pretty sure they were just manually writing code out in trinary (because the writers would never use something so mundane as binary).
you're a dumb fuck who never bothered RTMF?
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.
Lack of libraries is a secondary problem at best. The single biggest problem of all non-plain text programming "languages" is lack of advanced development tools. When you program in a good old text, no matter which specific language you use, you have a hundred different editors to choose from, a dozen diff tools, a dozen version control systems, a hundred different ways to search through your code for whatever you need to find and writing a code generator is trivial. None of those tools need to make sense of the code because it's all just human-readable plain text.
But when you use a programming "language" which stores code in some weird structured format (even XML qualifies if the code structure is complex enough), every single tool you use needs to understand the format. You can't use Vim, Emacs, Eclipse, Gedit or whatever to write the code, you need a special editor made specifically for the language. You can't use GNU Diffutils to diff your code, you need special diff tool made specifically for the language. You can use most of the version control systems out there but you won't be able to compare changes between revisions, unless you use a VCS made specifically for the language. You can't just grep your sources, you need special search tool made specifically for the language. And you can probably forget outright about generating any code automatically.
Maintaining code is much more important in the real world than simply writing it. Most of the problems related to maintaining code have already been solved by general-purpose tools which work with any human-readable plain text programming language. Every new non-text code format requires solving those problems again from scratch and usually makes solving them much more difficult.
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.
Any sufficiently complex software with event loop or multiple threads most likely contains K5 or K3,3. BTW, plain C pretty much allows you to work with full OOP objects, including simple class inheritance and virtual methods. The only limitation is that all members are always public and you have to call destructors manually.
Visual design methods don't exist for software because there's literally no benefit to designing software components. You can't sell them because no one is buying them. The best efforts we have at re-usable components are libraries. C++ has Boost and Qt. Perl has CPAN. None of those "components" cost a dime unless you want support for them.
Hardware components have to be manufactured, which means there is economic cost involved with their use. Software components are virtual. If I download a faulty XML library and it doesn't work I'm only out labor costs for repair. There's no hardware recall and no penalty for switching to a better library. I just have to convince people to upgrade, which is basically free with distribution over the Internet.
This effect destroys the economy for re-usable software components. Without a strong market for components, visual design can't succeed.
Nah, I'm actually with the poster. I get text-based traditional coding too, but find the ROI (time and effort) quite poor and the work dreary. You have to be either well disciplined, or get the sort of joy banging out code that running get when pushing their body through the next mile.
So one can get 'coding', or get 'running', but find themselves searching for something better. (visual coding/visual abstractions swimming)
Programming is mathematics.
Call me when mathematicians start doing proofs and writing functions by drawing pictures instead of writing symbolic equations.
You are correct. The heart of the matter is that text is succinct. Words (variable and function names, various operators) are compact and convey tons of information for the space they take up vs. visual representations. Also, you can jump from one thing to another in text (source code) very quickly. All these arguments were already fought between the command line and the GUI. Textual source code has a high "information density". If nobody has said that before I'm going to trademark it ... back off.
I doubt very much there is a better way.
I don't think it's the lack of complexity that makes Visual Basic applications so lousy, in general. I think that it's the ease of use of Visual Basic that facilitates all sorts of people with no training or core programming competency building complex applications. Don't blame the tools, blame the makers. It is possible to write solid application code in Visual Basic. Easier to use, accessible tools make for worse programmers making programs. It's not the simplicity of the tools so much as their ease of use. The same goes for Access.
by Mike Buddha -- Someday the mountain might get him, but the law never will.
Exactly. No matter how easy and user-friendly you make graphical programming, you still need to implement complicated logic. You still need someone who can think logically, think of the corner cases, implement error handling properly, and debug unexpected problems. I think a lot of management people are fooled into thinking they can shortcut "expensive" developers, and have non-technical people implement everything. In reality, it is the developers who are taking care of the dirty work of handling those corner cases and error scenarios.
Code is language. Language is a vehicle for thought. Thought is the solution to the underlying problem. QED. Been doing that for over almost 30 years, be it assembly, C, C++, Ruby, SAS .. you name it.
Code is the machine-understandable expression of human thought.
Now - what was the question ?
The sum of intelligence on a planet is constant. Nowadays we have more people. When classic goes away, so do I. Copy
But when you go making black boxes, you are hiding the exact details that you would benefit from visualising.
this:
$variable = somefunction($some_parameter);
is also a black box... it doesn't tell you any more about what goes on inside somefunction that a flow chart rectangle.
i think we're sort of on the same wavelength though. you don't seem to value flowcharts for programs (i'm the same) but you see their value in data structures (as i also do). i guess i'm just trying to expand the argument a bit by suggesting that if we had an efficient input method (nobody could pay me enough to program graphically with a mouse) and there was a visual language that was well defined and as flexible as Pascal or C, then I might give it a shot. i think one possible advatage that can't be overlooked is that a lot of humans analyze simple images easier than a bunch of symbols (which is basically a more complex image), and someone trained in developing software using flowcharts may be able to spot bugs more efficiently than debugging text. not saying this is true, but it may be a possibility in future. again, i think the biggest setback to any visual flowchart type programming language is the reliance on the mouse, which for most people would be much less efficient than using a keyboard. who knows, maybe down the track we will be able to program a flowchart type language using our thoughts?
the future is both exciting and scary, and anyone who ignores it is destined to be left behind.
... are we still reading text based news?
Next dumb question plz.
Dreamweaver produces crappy, bloated, redundant HTML (I know, I know, it's not programming) and I stopped using it years ago and do it all by hand now. You want to do something more complex than HTML graphically? Oh and fuck beta ^c^
SNAP! is a visual editor that can put together some simple-to-moderately-complex programs. I'm surprised no one has cited it as an example of the convenience / drawbacks of a visual editor. It can be hooked up to all kinds of things, including mindstorms, wiimotes, and Arduino. I've only seen it used standalone for intro-level CS instruction, but it does seem to have some interesting uses. I don't think this is a real problem though -- the text of actual code isn't a barrier to actual coders...
But we can draw pictures. Guess you missed that option.
A text based syntax is an easy mechanism to implement a wide variety of language semantics, including abstractions of greater or lesser richness.
Typically, the point of visual languages is to make the control or data flow explicit in a diagrammatic form. This is (to some extent) antithetical to the concept of abstraction. Visual languages are quite common in some circles (for example ETL, workflow or rule engine systems). The explicit nature of the languages means they scale poorly with the complexity of the computation in practice.
This makes them clumsy for large scale software construction in practice - they do not do a very good job of handling abstraction and a non-trivial computation quickly becomes diagrammatically very complex. I have yet to see a visual language in practice that incorporates a solution to this problem.
Many textual languages have more or less elegant, straightforward primitives for abstraction (macros, higher-order functions, inheritance etc.) and this technology is proven and works well. Visual language technology has yet to catch-up, or even demonstrate that this can be done at all.
Thus, while they can be used effectively in certain domains (just as textual domain-specific languages can) visual languages as a technology have not yet demonstrated a capability to support productive large-scale software engineering.
Don't know if you've been failing to pay attention, but between X-Box and it's game pads and the various touch screen devices out there, the keyboard itself is on it's way towards niche status....
-1 Uncomfortable Truth
The crappy software is block based and does not run on Linux, even though the brick is running Linux. We have added wireless cards and microSD cards, enabled SSH, loaded BrickX, and are experimenting with LEJOS.
BrickX lets us use MindSensors components, multitask, and access extra motors and sensors through splitters.
Piece of cake in labview
Only I can judge you.
Yes, and you could reasonably make a graphical interface for assembly language. Very simple tools with very simple connectors, mapping onto the real world (transistors, pins, registers, leads). The more abstract you get, the more explicit your instructions need to be to get reliable, reproducible, complex results. It's really hard to do that with predefined building blocks, unless part of your building block is a big chunk of very specific text, which sounds remarkably like code.
Another similar thing would be comparing movies to books. The richness, detail, and depth of a book just can't be done in film, in part because we don't want to sit there that long. But also, look at all the versions of a specific book that was done, each of which was done with the goal of being at least as good as the book, and how differently they turned out. This is something we don't want to have when we write code - we want the same results every time, with no limit to expression within the capabilities of the language/compiler/hardware/etc.
Another great example is language and writing itself. There's a reason the vast majority of the world went away from using pictures to describe concepts (words) - after a while you had a huge collection of pictures, and were still limited to doing more basic writing if you didn't have a clear idea of which picture referred to which concept. And so there was a decoupling between the concept (word) and the presentation of it (writing). C-A-T spells cat, but none of those parts have anything to do with the furry critter with pointy ears, whiskers, and a love for sleeping and chasing mice.
It's not that I think it would be impossible to make a visually mapped programming language, but the more abstract elements, particularly non-interface elements, would be just as difficult as they are today simply because they are abstract, difficult concepts.
Sure I'm paranoid, but am I paranoid enough?
If I provide
input : [1,3,2,-11,5]
output : [-11,1,2,3,5]
then PBE generator can find the right sorting algorithm. Of course it won't be exactly quicksort algorithm, but how many programmers would really care?
very effective.
Motion control is a fairly restricted area of application where most of the thinking goes into the application of very mature mathematics derived from the solution of a small set of continuous differential equations. Add a small number of ifs and whiles to interlock the thing to behave safely and you're done. The information content of the resulting code is low compared to, say, a word processor, or an operating system, or a low-level device driver.
Likewise, PLCs tend to control fairly simple individual things for which ladders are as good a paradigm for as independent lines or small numbers of lines of code in a procedural language, with very little program-spanning complexity.
If you want your motion controller or automation system to do something special based complex transformations to other external inputs, that kind of logic is usually done outside the graphical programming language and feeds a single input block or pad or pin in the graphical paradigm, but has tens to hundreds of thousands of lines of C code behind it.
The example I've got in my head is something like an aircraft's autopilot:
Moving the control surfaces in response to the pilot's control input and the attitude gyro is something that can (and probably should) be coded up in a graphical language, both to provide checkability against the control theory math used in the design and to eliminate a possible point of coding error in the most critical inner loop of the code.
Feeding the autopilot with a trajectory based on GPS, airspeed, navigation waypoints, weather radar, etc, should be done in a procedural language because the complexity (both lenght and interconnectedness) of the algorithms makes it very painful to implement them graphically rather than procedurally.
body language, pheremones, other smells, vocal cues....these are all symbols & no different essentially from words
oh yeah, throw choice of clothing and hair style in there as well
all of these are ways of communicating meaning, none being more 'essential' than the other b/c they all evolved together
there is no 'OTOH' kind of school...just Kurzweil-style AI fanbois
Thank you Dave Raggett
Maybe OP is a "big picture thinker", and being a "big picture thinker", can't conceive of why people with tangible, productive, technical skills can actually do something he cannot.
Agreed.
I think this is not a problem of CLI or GUI specificly, but a problem of alphabet perhaps. We should improve the use of unicode symbols to reduce the size of code and not the meaning of it.
In a GUI case (or Text mode a day perhaps) i think Pure Data make the understand of code more efficient even if in our programming standards it could appear to be limited, we shouldn't forget that the meaning of our programs is defined by his text.
because you can't produce something complex with something simple.
I recently read 'A new kind of Science' by Stephen Wolfram. One of the main points he demonstrates is that you can make something complex from a simple set of rules.
I'm probably coming at this too little too late, but:
for C-looking languages (C, Java, Javascript) etc that use curly braces and block, there's usually a strong visual element: no one wants to look at code that's not "properly formatted". So while language is super awesome and powerful (almost any programmer is going to have a hard time expressing himself or herself in, like, that block language that came w/ the original Lego Mindstorms), the graphical element is still present
SO YOU'RE GOING TO DIE: The Comic for Dealing with Death
These editors do require more than just placing blocks on the screen. They require inter-connections to be made between the data inputs and outputs (for an image processing pipeline). For the Qt editor you need to define link widgets together to define them as "buddies" (if the slider moves, then that sends a message to the text display as well as the color box). Each widget also has to send messages to parents, children and buddies for resize, open, close, value changed, button pressed/released, slider moved. So there are all these interconnect lines that show what goes to where, and it can get messy.
Blender: http://blackspike.com/blender-...
Vintage computer adverts: http://www.vintageadbrowser.com/computers-and-software-ads
Math. A specialized, text-based syntax is consistently faster to write and denser visually. The learning curve is steeper, but it's better once learned.
Also, to develop a non-language-specific syntax, would require development of a universal coding language translator. Clearly, not an easy task.
These editors do require more than just placing blocks on the screen.
Errr... yes? I wrote about connections between boxes in the very comment you replied to? *puzzled look*
Assorted stuff I do sometimes: Lemuria.org
There are plenty of processes that don't require graphics. Data batch processes, 3D rendering batch processes, network diagnostics, the list goes on and on. The only gui intensive application are end user desktop. There's much more to coding than just desktop applications.
is a tool where you can program graphically.
But after Beta came out everyone is too angry to talk about them
There's a reason writing systems evolved from pictographic/ideographic to logographic and phonographic systems, and that is that these later systems are more expressive than the former. The same is true of formal, engineered writing systems: text based languages are more expressive and efficient than picture or diagram based languages. Text based languages can describe complex things more compactly than non-text based languages.
Hundreds of non-text based (AKA "visual") programming languages have been developed and have proven to be generally more limited than text based languages. When the description of a program reaches a certain level of complexity (which isn't very high) it's diagrammatic specification becomes much harder to comprehend than it's textual specification. I've seen visual programs that look like an incomprehensible mass of tangled wires that can be expressed in a couple pages of text.
However, programs of lower complexity can be specified by a comprehendible diagram, and in many cases that diagram is easier to understand by non-programmers than the corresponding text. Visual languages, when restricted to a specific, limited, domain, can be easier to understand by some.
But for general purpose programming, or moderate complexity of more, text is a much more efficient medium.
Like everything here ...
I spent a year working on a project that replicated ladder logic in flowcharts, using a Visio like design surface, that output the PLC code. It was much more elegant than ladder. After the product was released, we were required to build a "ladder interface" because many engineers refused to use anything else. This proves that ladder and flowchart are really equal.
PLC's are based a defined set of analog and digital inputs and outputs. Programs that humans interact with, on the other hand, such as Windows, Web Sites, browsers, etc. deal with an input stream that is not always predictable. It would be very complicated to express even a simple form in flowchart or ladder logic because it's a set of asynchronous islands of code.
In other words, while everything in life could be expressed as a flowchart or ladder, simple human interfaces would be overly complicated by trying to do so.
Murphy was an optimist
Been there, done that. See: APL
Yes, I have done, machine language programming, and assembler, and 'higher level' languages on many platforms over time. Each time we add another 'level' we obfuscate what is happening from the programmer. Sometimes this is a 'good thing', sometimes it gets in the way of getting things done.
We do have applications programming graphical languages (check out CAD/CAM systems, where the 'object code' is g-code (pretty much assembler language), and implemented on the machines by the 'hardware' and controllers. (Yes, sometimes these are rolled together into more or less monolithic systems). Also some companies like shopbottools.com replace g-code with their own but they sell the controllers that understand it.
In many ways the new generations of graphic 3-D programming systems that allow building virtual worlds is what I think Timothy is addressing. Still, I doubt you are going to see it in hard-core real-time applications and control systems for quite a while.
The computing industry is under 100 years old as an industry. It is still changing. One day we all may have the TV and Movie technologies we see in the media, but in the mean time, I still use vi as my current text editor to change config files, generate web pages, and write programs.
The need for computer power is also limiting much of this kind of new languages. We don't have un-limited computing power, no un-limited bandwidth, no un-limited storage, available everywhere to everyone for 'free'. The prices of all of these resources has come down, and become higher limits than we have had in the past, but it still isn't 'free enough' to allow using super-high-level-languages that keep programmers from being even interested in register vs 3-rd level memory, vs cache-access for intense needs.
I hope we see some more and better visual programming languages, but not to obfuscate the resources used but to better manage them, reduce overhaead, and add to overall productivity. ... Now back to my vi session (I never learned emacs, it always seemed to complicated :) )
... "When you pry the source from my cold dead hands."
Lutz? Is that you?
(Luz Prechelt, a german language researcher and Ph.D. in Software engineering had this line of text as his signature in his emails)
Cost free eBook I read (by iBook/Kobo/Amazon/ObookO/Gutenberg etc.): "The Green Odyssey" by Philip Jose Farmer.
You do know that you can access Excel sheets via ODBC/SQL? There is even an Apache library for JDBC that transforms multiple Excel sheets into a data base of multiple tables.
Cost free eBook I read (by iBook/Kobo/Amazon/ObookO/Gutenberg etc.): "The Green Odyssey" by Philip Jose Farmer.
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.
The assertion that complexity cannot come from simplicity is patently false. There are far too many examples to list.
Graphical tools for hardware and chip design are mainly for replicating patterns over and over, and testing their connections.
The real reason is that programming these days is a sequential process (mostly). As such, you need one dimension, rather than 2 or 3. So, visual paradigms make little sense. Nobody uses flow charts anymore for good reason. Most visual coding paradigms are ways to input flow charts.
Programs are a linear narrative, because that is how the CPU sees it. So, it is treated like that. Once we have thousands or tens of thousands of interconnected CPUs working together, 2d programming paradigms will make more sense.
Go to Heaven for the climate, Hell for the company -- Mark Twain
but she still wants to hear all the bs
Why didn't you post this comment as a video rather than the old-school text based interface?
The industry experience with visual programming (LabView and VEE) is that it produces THE MOST unsupportable code ever created. They are easy to use at the beginning but they produce code that increases to unsupportable complexity very quickly.
They usually are WRITE-ONLY languages - once written even the coder doesn't know how they work and subsequent programmers usually can't make heads or tails. My company has been paid 7-figure amounts to "recover/rescue and rewrite" LabView programs that have threatened operations of Fortune 500 companies. The damage created by visual programming is that dire. And our margins aren't always as good as that would suggest because it's not trivial to reverse engineer these nightmares.
This doesn't mean that someone couldn't crack the nut of how to do a visual language well; but no one has yet, and there may be dimensional/geometric/information reasons why you can not. In general, I'd am highly skeptical of visual programming to represent complex computing solutions - the visual metaphor simply doesn't allow such things to be represented clearly or succinctly.
An interesting question, one which many have thought of, not only you. We've come a long way from punch cards to almost English-like scripting and query languages. Once the domain of only professional programmers, building programs is now a hobby for many with little or no formal training in programming. That said, there's a huge difference between building controller firmware and code to transfer money from one account to another. But I digress, the original question had to do with programming languages, and there I must agree with a lot of what's being said, in that, so long as it remains the domain of mathematics, it's unlikely that it will become too abstracted from text based methods. I come from the Assembly and C world, and the new 4GL languages aren't that exciting for me. But that's me, and I'm pretty much on my way out.
> Yes, and you could reasonably make a graphical interface for assembly language.
I soooooo want to have this! Build a module from data types and instructions. Build loops and conditionals from macros. Wire up inputs and outpus. If you've ever used Reaktor, it's a fantastic way of structuring code into "black box" modules where you only have to know the the interface to use it. Open it up, and you can see how it's built. If I could have something bridging the interfaces of Interface Builder, ResEdit, MS Access, Flash, Reaktor...
I can see it in my head, but no idea how to build it!
The GTK GUI illustrates the problem well. You do get this visual interface to writing GUI componants, but at some point, around the edges, you still have to understand what the objects and their methods do, so you have to go read documentation and eventually, the code. This is especially true if the thing you've made needs debugging, then you are quickly thrust back into the world of the programming language.
Even IDES like Eclipse and Netbeans and others that give you prototype hints don't give you a full enough story. I guess these aid productivity if you already know the libraries, but to do that you have to at least read the list of objects and methods, which is where the real complexity of OOL gets obfiscatted, and Java in particular is very bad in this regrad because of its history. The greater the complexity and the poorer the documentation the faster you are thrust into having the read the code and even the source for the libraries. One thing abstraction does is to invert the logic of inheritance so you are forced to read code in a bottom up fashion, which is much harder to figure out what it does. So, OOD fails if the methods aren't done correctly and even more if the developer hasn't put sufficient effort into documenting in your native language. So poor English can become a major impediment to the whole effort if the developer speaks a language far less used than English, e.g.
Development efforts fail or get unused for the same human factors they always did, going back to the days of COBOL and FORTRAN. The way they fail has just changed and looking for a simple interface does not solve this problem.
By analogy, file managers are supposed to reduce the complexity of finding files and directory structures, and they do, but you still need to know a CLI and a shell to solve practical problems finding files, better that you can write a shell script to automate a task, so the shell isn't going away any time soon, even with file managers, and so text-based programming isn't going away soon because of IDEs. I still code HTML and CSS with emacs because I can't be sure of the garbage most WYSIWYG web page editors put in the code. I can code more concise and cleaner HTML by hand than most of these,
I think the the original question has it arse about face. By abstracting to higher level non textual objects you are removing yourself further from the simplest things. The simplest things are the binary ones and zeros that the computer works with. That would be the simplest thing to use and yes that would be like building ships with matchsticks and not easy for humans to follow easily. We don't think in pictures we think in words and that is why once we got beyond programming using binary switches which is too near the bare metal (but _the_ most simple set of instructions to do programming with that gives you ultimate flexibility) we went to assembly language. By doing that the the programs could be read easily and understood and more importantly we could work out where the bug was, but it was still a bit too near the bare metal for mere mortals who need to the vast majority of day to day programming. So we stepped one step further away from the simplest thing to something that you can read and learn like a human language. Admittedly it is more complicated because there are more syntactical words to use to achieve some of what you can do with machine code. But once you have learned the language like you would English or German and can speak it fluently and as some programmers will tell you they "think" in C or VB or whatever language suits them best they can be the most productive with a computer producing the amazing things we do for the betterment of our fellow man. The more you go beyond what we think in i.e. a language like C, VB, C#, F#, Lisp, Java, Pascal or whatever, you necessarily lose even more fine control and are stuck with whatever the graphical representation limits you to. As soon as you want to do something more complex than the designer of the graphical programming language thought of, you are stuck down a blind alley. So what you want is the best compromise a programming language that matches how we think in words that has enough simple building blocks that can be put together to create anything we can think of to access all the capabilities of the platform we are writing the code for. Which is pretty much where languages like C and C++ put you. I am a VB programmer and accept that I rely on C++ programmers to reduce the complexity for me a little bit by writing the VB language and Visual Studio as I am unlikely to ever want to rewrite Windows or create device drivers I just want a language that I can think in that allows me to produce database applications that my clients use day in and out to manage their businesses. If you tried to make a Visual programming language that the OP is asking for it would be easy for him/her to use but wouldn't be very capable. If you could make one that was more capable and used smaller building blocks it would be too unwieldy and it would be far easier to use text to achieve the same things in much simpler words. Hence that is why we are where we are. Siv
Martley, Near Worcester UK.
You really are a Crudely Indecent bastard aren't you? Cpt Obvious strikes again!
Fuck you and FUCK BETA!
Visual programming environments exist now. The two that I can name off the top of my head are the Lego educational ‘programming’ software for kids, and the Virtools Development Environment by Dassault Systemes. Which was designed to produce games and other realtime 3D simulations.
Having done quite a bit of work in Virtools years ago, I can say that the biggest downside of visual programming is the time that it takes to get anything done.
Let’s say that I want to add the numbers 1 to 10, and show it to the user.
In less than 30 seconds, I can type the following:
int i;
int c = 0;
For (i = 1; i = 10; i++)
(
c = c + i;
)
cout c;
To do that visually, imagine digging through a hierarchical menu of 100+ widgets for the ones you want. You need at least 3. Then you dig through another menu for a couple of variables. This takes at least 30 seconds all by itself.
Then you drag paths from the pins on each widget to your variables and your other widgets. Mid-way, you realize that you need another widget to hold the count state. Because the loop and addition widgets don’t hold data, they just process it. This takes from 2-5 minutes to completely work out as you follow lines around in circles checking the logic.
Then, you’ll spend another 1-2 minutes “cleaning up” your widget layout so that it’s “readable”. Because if you let the dev environment do it, it will turn into wire-line spaghetti. Oh, and if you decide to add anything to the program, you’ll have to clean up that layout AGAIN, and AGAIN, and that’s when you really start to hate visual programming.
Now contemplate doing anything even moderately complex in that system and you’ll see the problem. Oh, and if you need a widget that does anything out of the ordinary, you’ll be coding it in a text-based scripting language or C anyway. So why are you torturing yourself?
Like GUIs vs. command lines, visual programming is easier when you’re doing something simple and don’t know the system by heart. But for anything complex, you’ll get your work done FAR faster by typing the commands.
"The Robert C. Martin Clean Code Collection (Collection) (Robert C. Martin Series)", ASIN: B00666M59G, ISBN-10: 0-13-291122-1, chapter 1 "Clean Code", topic "There Will be Code". This topic is very enlightening, unfortunately, I think I don't have the copyright permission to show this topic.
Well, all the current solutions just squeak or make me scratch.
Truth is stranger than fiction, but it is because Fiction is obliged to stick to possibilities; Truth isn't. Mark Twain.
Built and marketed a drag-n-drop application builder, with both GUI and non-GUI components. Eliminated a developer needing to ever write an application. Instead, just put the components together and save the result. Works well for taking existing components and wiring them together in some sort of relationship, but doesn't come close to getting rid of text code. Underlying the system for each component had to be lots of code. Further, needed lots of code to manage how the relationships between the components worked. Although it was conceivable to do flowgraph components to represent the control structures, when looking at the density of information that you can get on a screen at one time, the graphical approach was a non-starter. At the time UML was not there, but the concepts from the "3-amigos" was. What I wanted for the tool was that it would include enough API information such that it would be intelligent about how components would be connected together, kind of like the copy&paste clipboard types we take for granted copying data between programs. It worked very well. Had a pretty good following. A certain company in the US northwest, squashed the competing OS that it was written for. Dejected after 3 years of work, moved on to network protocols and other things.
We already have languages that non-programmers can us to assemble code. However, it is unlikely that these were written in such languages themselves. cf Excel. Even Data base languages force you to design your program (and screens) in the way that the "expert" thought it should be done. No flexibility and, often, insufficient scalability. The other issue is efficiency. The less control you have over the code, generally, the less efficiently you can write it to be.
National Instruments does graphical programming in their motion control systems and it makes some sense, though it kind of sucks. Also PLCs are often written in ladder not text, unless your programmer has lost the plot a bit and thinks statement list is appropriate for everything (hint, it isn't).
I'm familiar with AB's PLC line (5 and ControlLogix), and it's interesting to see how electricians have no problem dealing with ladder logic, but really struggle with "Structured text". Yet lines of ladder can be represented (or directly entered) as text. Eg: using XIC OTE). Of course all new automation comes from our company's motherland, written in structure text in a foreign language, with foreign comments, making it a disaster to troubleshoot.
AB also has "Sequential Function Chart" which is more graphical.
How the fuck did this post get published?
"Why have graphical code generators that could seemingly open coding to the masses gone nowhere?"
Because the concept just doesn't work. There's a reason why picture books are rare compared to text-based books: text is pure information.
Coding is information. It's concrete, not abstract. Graphics just don't fit.
A fairly important comparison can be made between operating systems such as Unix that have text based configuration files, as opposed to Windows that has many binary configuration files that cannot be easily examined or understood. GUI programming might be nice, but until the GUI is up, there won't be any of that. As a career "Systems Programmer", I have chosen to stay close to the bare metal, and unless you are very skillful at expressing high level code such that it generates exactly the machine code you emanated, bare metal programming is still best done in assembly or a C derivative. Programming languages such as Visual Basic that ere supposed to allow non-programmers to write programs are the root of a problem today that people capable of making programs using high level tools often don't have the experience or training to write safe, reliable, efficient code, maintainable and documented. Siri, please write a complete memory manager and interrupt system for my new microprocessor, so I can begin programming in tenth generation languages right away...
Visual representation of source code does not and will not work effectively. Equally, visual representation of the written word will not work effectively. Where images and text go together, either the text is used to explain the image or the image is just an illustration to go with the text, not a real representation.
This all changes when the code is visual, when the programmer programmes visually and there is no text involved other than for labels, names and attributes. This was what Phil Cox and colleagues realised when they produced Prograph, a visual, object orientated data flow language. Prograph was directly compiled into an executable - it was no pseudo coding system that merely generated C or Java, yet it could run interpreted (making it a dream to debug). In comparisons, clean Prograph code could be produced in about 20% of the time taken to produce the equivalent in C++ but ran only 5% slower. Isn't that what we are always looking for?
Sadly, the commercial exploitation of Prograph was not as successful (isn't it ever thus?) but the concept still lives on as Marten. http://www.andescotia.com/
Thank you Jack.
SFC is really useful for a small set of problems. The major advantage of ladder, is it makes following whats going on in live system easy.
I have determined that my sig is indeterminate.
Actually I think the reason for still using text is because the most successful programming languages are imperative i.e. if functional programming had more influence by now we would've tools and standards that would have made graphical programming more useful.
Text based is about as simple as you can get for the programmer. Machine code is as simple as you can get for the CPU. Then we have assembly code using mnemonics, but today’s CPUs unlike the old 6502s and 8086s have a huge number of mnemonics and individual machine code instructions. We either “compile” text into machine code, or text is “translated” at run time as in BASIC. Translators are not very efficient, while a compiler can be quite complex. To write out an algorithm, convert it to a Nassi Schneidernan flow chart, and then write the source code to be compiled is complex, but it's about as simple as you ate going to get. As already mentioned, To simplify the job for the programmer gets very complex. The simpler you make the job, the more complicated the compiler becomes. Like writing a program to be user friendly gets complicated ...fast! If you have a degree in CS or CIS, try unraveling the code written by a EE or Chem-E. It's not that their code is bad (many would argue that point) but they think differently than we do and approach problems differently.
From the question, I take it, you have learned to write code, but programming, is problem solving and CS is being able to analyze code for the fastest and most efficient code to do a job. One of the first graduate courses is the design and analysis of algorithms. You start out with 5 different sorts. Using a random number generator, you generate strings of 10, 100, 1,000, 10,000 in lengths. You also have the same lengths in order and reverse order.
The goal is to determine which sort is the fastest for each of the strings that are in order, reverse order and random, mathematically. Then you write and run the sorts on the strings to prove the math. You basically end up with a 5 level simultaneous equations which is relatively simple.
You quickly learn there is a lot more to programming than just being able to write code. It varies with companies, but I typically had people come in and ask for a program to do something. It was up to me to write the algorithm, have them tell me if that was truly what they wanted (it often wasn't), and work out the details. Some areas work in teams on large projects, others may have a programmer or two work on a project. I became a project manager in about 2 to 2.5 years.
Generally speaking CS is highly math oriented, where CIS is more writing programs. With CS I only had to take two more courses to earn a minor in Math.
Generally speaking you need a pretty good background to get a job as a programmer.(and good grades) The Type and size of programs as well a jobs varies significantly as do the languages used. You may take all that math and never use it once out of college, or you may spend a substantial portion of your Time analyzing programs.
Drag n drop programming, now why didn't that take off?
Dear OP --
It seems to me that yours is a good question. The answer is that such graphical tools are coming but they are long way off. Below I cite a few resources for more study. It will get there, but it is not there yet. That type of development tool is in its infancy. Even mature text-based IDEs such as Visual Studio and Eclipse, have a lot of work needed before they become streamlined. Such tools are plagued with slow compile time, crashes, complex configuration, and etc. It needs to come a long way yet. That said, the syntax is not that hard. C# is pretty simple once you try it for a month or so.
Hope these links help you start thinking about such matters...
AppInventor
http://appinventor.mit.edu/explore/
Model-driven architecture
http://en.wikipedia.org/wiki/Model-driven_architecture
MDA Tool for Model Driven Architecture
http://www.sparxsystems.com/platforms/mda_tool.html
Executable UML
http://en.wikipedia.org/wiki/Executable_UML
AndroMDA
http://www.andromda.org/index.html
9 Hand-picked MDA Tools
http://www.software-pointers.com/en-mda-tools.html
If I had to read through or process a few million transactions in hours, and it is done repetitively, text code, and probably C language or C++ would be used.
Doing the visual programming shtick would work, but the overheads of interpretation and correct but inefficient solutions would mean that the overnight jobs could not get done.
Many banks do statements and are typical of the organizations doing millions of transactions per day. Close to them is the government, and the online stores.
Two counterexamples of why one method is still being deployed.
Leslie Satenstein Montreal Quebec Canada
Hard to comment: LabVIEW have a built comment engine, which can be used to generate documentation (dozens of formats). Also, there's a place to write descriptions in SubVIs and on the block diagram.
Very easy to write bad code: This happens on every language. Just learn the good pratices.
Version Control is awkward: LabVIEW is compatible with SVN and there's another tools like the VI comparison, snippet and so on.
Clunky to debug because programs are hard to follow: Only your program design is poor. LabVIEW have amazing debug tools.
Coding becomes an exercis..... : Quick Drop tool wins.
As a beginner you waste lots of time...: What? C programmers would have to take care about write archaic routines to deal with memory management, portability and so on. Project time is not time to "learn how to program"
Hard to learn from a book or even from reading somebody else code: So, you haven't learn LabVIEW
The graphical approach is orders of magnitude better to solve problems: That why's engineers and scientists use LabVIEW, both of them have REAL COMPLEX PROBLEMS (and not stupid ones like the most of "real developers" are able to solve...). Remember: The graphic contain the word, but not the opposite
LabVIEW is the future. Period
Visual programming environments will never succeed, as long as the goal is to be "better than text". In the current attempts, one writes code with shapes and connecting lines instead of with letters and punctuation, but the linguistic concepts behind the code are still recognizable and readable. The catch is that this turns out to be a far less efficient way to encode language than text is: it's harder to write, and it's harder to read, so people inevitably gravitate back toward text, and the visual aspect is forgotten.
Does this mean visual programming is doomed? Not necessarily, but it needs to refocus its goal on something much more radical than attempts to date have really done. Current attempts try to be "better than text," and even the article here seems to advocate this approach. Instead, they need to focus on being better than language. This is where visual programming really has potential: rather than trying to replicate what text can do, it needs to focus on what text can't do.
How would something like this work? I haven't the faintest idea. I literally cannot imagine what it would be like to code without language. But a lot of concepts have emerged, even just during my own lifetime, that I could not have imagined before seeing them. Perhaps this is the same.
So there's my challenge to the "visual programming" folks. Express to me the nature of (and a possible solution to) some moderately complex problem, without using language of any sort. Manage this, and your task is largely finished: all that remains is to come up with a visual editor for encoding information in your chosen method. Do this, and you will have your revolution.
Labview is great for designing software that interacts with NI hardware for basic data acquisition. However, for everyday programming of desktop applications, I would much prefer C#, C, C++, or Java. The block diagram can become incredibly busy and hard to follow when developing complex applications (my current project has about 20 subVI's and the main front panel's block diagram is still absolutely nuts). Traditional, text-based code is, IMO, a lot more easy to manage when dealing with larger-scale projects that require more than just handling basic analog/digital IO.
Yeah, Excel 2013 and PowerPivot can even create relational data models out of them. That vendor was not aware of that either. To him, any spreadsheet = a table in SQL Server, no difference.
In theory there is no difference between theory and practice. In practice there is. - Yogi Berra
When I was a kid in computer camp we used this game design tool called Multimedia Fusion. It used a graphical programming interface which, as a kid, helped a ton with programming some intuitive games in short time. Didn't do the flash after getting spoiled on the visual programming though.
There's a very specific set of concepts that's easier to express on the command line than in traditional programming languages, and it's pretty much entirely limited to processing streams of text. Which is nice, and it's great that this is easy to do. For what it's worth, a lot of programming languages have string buffers that can operate much like pipes to let you code in the same style internally.
However, text streams as a foundation for coding break down really quickly. Command line pipe "programs" basically require that all the data you care about be represented as a series of lines of text at every point along the way, and while that representation is very powerful for things that fit the model, it becomes a giant pain in the ass to use it to write logic that doesn't fit well.
Some newer languages are adding things like lambdas and comprehensions to move closer to this style in certain cases. And while they're nice, they're really just syntactic sugar. The fact remains that programming needs to be able to operate on variables and objects in ways that stream processing just can't do. The Unix command line paradigm is a specialized tool, while procedural/functional/OO/aspected programming is a much more general purpose one.
Slashdot needs a "-1, Wrong" moderation option.
The Urban Hippie
Thanks!
With only one layer of abstraction more, I can CONQUER THE WORLD!
Before I get a little offtopic I want to address the submitter's question: he's asking for COBOL or BASIC. If you can't figure those simple languages out, you'll never be a programmer.
That said, a lot of today's high level languages are poorly designed, with a lot of roadblocks that should be unnecessary. And programmers should know boolean logic, binary math, and how computers work down to the individual transistors.
As to Beta, the problems are many but they don't stem from bad programming. They stem from bad design and poor testing and debugging (but 99% bad design). Releasing alpha-quality code to beta was their biggest mistake.
Free Martian Whores!
Truth is that there is definitely an upside to having graphically driven development. That is if you know your program can be broken down into 55 reuseable components and you know the mapping between function and name (widget 103 links into the network widget 12 to form Voltron let's pretend) then you can save a ton of time and money by literally dragging and dropping. The problem as others rightly point out is that there are probably tens of thousands of widgets that could be created and then you'd have to memorize at least 200 to have any value. Where code can be pressed into hierarchy and reusability it usually has been done so; so whether it's graphical or text based you'll still have the implementation methods to complete which may not be trivial. Google code reusability movements really because that's a significant part of graphical drag and drop programming.
And here you elucidate the problem with graphical coding. Graphics are good at representing state, and fair to middling at representing data. Sometimes they can be used to represent transformation but the contexts where a graphic can represent a transformation are only a very small subset of the range of transformations applied every day. There are a limited set of situations where graphical representation is more informative than text, mostly where a formal graphical language has been developed for the purpose such as state machine diagrams.
You're no coder Chumpy: ROTFLMAO @ U -> http://yro.slashdot.org/commen...
(You sure "talk a good game" -> http://games.slashdot.org/comm... but you can't even produce a MERE SCRIPT!, windbag...)
You aren't even on the level of a "script kiddie", & full of HOT AIR!
You certainly won't reply there in that 2nd link I posted either, as that would remove your downmods to my posts like this one you can't validly disprove or justify your downmod on -> http://games.slashdot.org/comm...
Oh, I suspect that IS the case here (simply logging out of a registered account & trolling by ac is a common troll trick around here OR using alternate registered 'luser' accounts sockpuppets to do the job will also, & Lumpy is LOADED with those & trolling - which doesn't matter: He PROVES he's all talk, no action (or skills, OR brains, lol))
(You're all TALK, & NO action "CHUMPY!)
* :)
(You know it, I know it, & so does anyone reading AND laughing their asses off @ you now... lol!)
APK
P.S.=> Answer the question in the subject-line Lumpy - since you had to "eat your wrods" in the 1st link above flavored with your FOOT IN YOUR MOUTH + the "bitter taste of SELF-defeat", lol...
... apk
ROTFLMAO @ "Chumpy" -> http://yro.slashdot.org/commen...
(You sure "talk a good game" -> http://games.slashdot.org/comm... but you can't even produce a MERE SCRIPT!, windbag...)
You aren't even on the level of a "script kiddie", & full of HOT AIR!
You certainly won't reply there in that 2nd link I posted either, as that would remove your downmods to my posts like this one you can't validly disprove or justify your downmod on -> http://games.slashdot.org/comm...
Oh, I suspect that IS the case here (simply logging out of a registered account & trolling by ac is a common troll trick around here OR using alternate registered 'luser' accounts sockpuppets to do the job will also, & Lumpy is LOADED with those & trolling - which doesn't matter: He PROVES he's all talk, no action (or skills, OR brains, lol))
(You're all TALK, & NO action "CHUMPY!)
* :)
(You know it, I know it, & so does anyone reading AND laughing their asses off @ you now... lol!)
APK
P.S.=> Answer the question in the subject-line Lumpy - since you had to "eat your wrods" in the 1st link above flavored with your FOOT IN YOUR MOUTH + the "bitter taste of SELF-defeat", lol...
... apk
Already happens today. Have you ever seen a pacemaker/defibrillator with a disclaimer?
Another place is the composition editor of Blender where you can place and connect processing nodes to do image processing and lighting. Once again that still requires the data flow to be connected up manually.
And even in this case, almost nobody uses that composition editor and when they do, its easier to fall back to full code as the composition nodes are so horribly complicated that if you do understand how they work its just easier to write code and do it that way instead. Basically, visual representations of logic and formal language are so poorly suited to the task that they are never used even when you try to find an isolated use case for them. Until visual representation can represent formal language as well formal language, this is a waste of time. The only use is for laying out GUI widgets and that's because GUI widgets are already a visual language. And even then it takes mountains of code to make the widgets, and hook them up to actions on the data model (and whatever else the application does).
"Those that start by burning books, will end by burning men."
Charles Simonyi, one of the creators of Microsoft Word, went on a crusade to enable "intentional programming", which is to programming what the WYSIWYG word processor was to LaTeX. You can see what he does here. This is a VERY hard problem to solve. Simonyi is a good programmer, has tons of money, yet this is not a battle that he has clearly won yet.
I once received a phone call at work from a Forbes journalist, saying that Simonyi had described my own pet project, XL (http://xlr.sf.net), and the associated "Concept Programming" ideas as one of the only competitors to Intentional Programming. That was interesting, because it shows that Simonyi had "groked" what I wanted to do, despite the total lack of polish of this little project. (As an aside, if you are curious, you can see XL in action in Taodyne's software to create interactive 3D documents)
But what Simonyi saw (I believe) is that the general questioning was similar. How do we transform ideas into code. For Simonyi, this can be done with graphical tools. For XL, this can be done with simple transformations on text (more precisely, on a Lisp-like parse tree generated from the text). For example, with XL, you can implement the "if-then-else" concept using the "->" (transforms into) operator as follows:
With this approach, it is possible to use nice notations for arbitrary concepts. In Taodyne's products, for example, a slide is described by something like:
This pseudo-markup language is then rewritten recursively until we reach "primitive" operations, e.g. 3D graphics rendering or basic computations.
XL is based on text because a) it's easier to do than Simonyi's approach, and b) I think it is generally easier to read and write "globally". If you have a "picture" in a document, of course showing the picture tells you more than just its name. But knowing that there is a picture in a document is easy with something like image "Woman.jpg" or (in HTML) a img tag.
As the experience with HTML or Postscript demonstrated, text or graphical does not matter much anyway. It's possible to have a text-based representation of the code that most people manipulate graphically and never need to be aware of. You can generate your HTML with Word, never need to know anything about it. It's likely the same thing is slowly happening with code as well: IDEs tend to give you more and more meta-data which is "behind" the text and helps you navigate it or code faster.
-- Did you try Tao3D? http://tao3d.sourceforge.net
I mean, as computers have gotten more advanced so has programming. There are multiple "layers" to it, some examples in order from low level to high level: assembly, c, c#/java/etc., html5/javascript/css. That doesn't even count the advancements in the IDEs that have come about because of it. So what's the next logical step? Javascript can already interpret other programming languages, like LUA... it's an endless cycle.
Text-to-speech and gesture recognition are still too slow, and drag-n-drop with shapes is still too inefficient and gets incredibly complex. Drawing on the other hand, probably mostly thanks to OCR and the endless desire for people to try to break CAPTCHAs, can be interpreted fairly well. It would give programming languages an entirely new form and be similar to drawing schematics.
Not saying it would be easy, but by using a digital pen pad or tablet the IDE could simplify it with reminders and yes, even auto-complete. It's digital. It's also not going to be for everyone. I personally would prefer to type.. but only because it's how I learned. I'd make a simple application out of it to try it, but that's probably as far as it'd get.