Slashdot Mirror
A Better Way To Program
mikejuk writes "This video will change the way you think about programming. The argument is clear and impressive — it suggest that we really are building programs with one hand tied behind our backs. Programmers can only understand their code by pretending to be computers and running it in their heads. As this video shows, this is increadibly inefficient and, as we generally have a computer in front of us, why not use it to help us understand the code? The key is probably interactivity. Don't wait for a compile to complete to see what effect your code has on things — if you can see it in real time then programming becomes much easier."
Seems like it mostly only applies to GUI programming or programming with results expressed through a GUI. What about, say, kernel programming?
Here's an implementation of Bret's ideas in Clojure.
Yeeehaaa! ;)
The tough problems aren't about running the code and seeing what happens, they're about setting up very specific situations and testing them easily.
"Malo periculosam, libertatem quam quietam servitutem." -- Jefferson
Until someone actually creates this new mythical language that is proposed by Bret, than this is all conjecture that a hyper-efficient, overly intuitive programming language that can provide immediate feedback would be hyper-efficient, overly intuitive, and provide immediate feedback.
Basically, the video referenced by the article is no different than "wouldn't it be nice if we were no longer dependent on foreign oil... that would make so many things so much easier!"
Thirty four characters live here.
Someone re-invented scripting languages ?
Religion is what happens when nature strikes and groupthink goes wrong.
Now go program me a nuclear reactor control system with this.
Just replying to myself, did not plan for the post above (yes, a first post!) to be made anonymous...
Unless somebody wants to give a better executive summary, there's no way I'm weeding through an hour of video. Do they have any idea how many hours there are of "the one video you must see this year" on YouTube?
For all intensive purposes, "whom" is no longer a word. That begs the question, "who cares"?
I've been doing this for years with Python's interactive prompt. I write code and test it on a line by line basis as I'm programming when working with unfamiliar libraries. The code that works is then put into a permanent file for reuse as a script or compiled to an executable for distribution to my end users.
If you need to "run" code, either in your head or on a computer, in order to see what it's going to do, you're probably not really programming and you're definitely not an engineer.
Would be a better post if you explained the "right way", hopefully its not mysticism.
Whats wrong with processing this line of perl in your head according to the rules to figure out what it does? (admittedly I have no idea why the heck you'd want to do this, but its the simplest example I can think of using about 3 key perl concepts...)
s/(.*):(.*)/$2:$1/;
The other aspect has to do with new code vs maint (even maint of my own code). If I have no idea what I'm doing with my own freshly written code, thats just wrong... but old code always has some element of intense CSI work to figure out what it does before I can modify it..
"Science flies us to the moon. Religion flies us into buildings." - Victor Stenger
"I remember how, with the advent of terminals, interactive debugging was supposed to solve all our programming problems, and how, with the advent of colour screens, "algorithm animation" was supposed to do the same. And what did we get? Commercial software with a disclaimer that explicitly states that you are a fool if you rely on what you just bought."
From http://www.cs.utexas.edu/~vl/notes/dijkstra.html.
It is the most worthless, dumbass thing I've ever had to sit through.
It's just another "wouldn't it be great if computers programmed themselves" video by someone too stupid to tie their own shoes.
I know what the code I'm writing is going to do *before* I start writing it, as I hope for the love of god most programmers do.
In fact, the biggest plague on programming ever has been this concept that changing what you want fifteen times along the way is perfectly okay and we just need to adapt methods to that idiocy. You don't need any of this crap if you just know what you want ahead of time.
It's called Python. I use the interactive interpreter to test snipets of code al the time. This makes me 4 times more productive than Java, for example.
'nuff said
Looking at your expression I do not think I "ran" it in my head. Rather i "understood" it the same way I look at an equation.
Generally I do not find myself simulating the running of code when I look at a program. I only do that when the code is overly complicated and hard to understand. Or if it is a clever algorithm that I do not already understand.
This is even more true for functional languages. Looking at some Haskell program it is not even always clear how the computer is going to "run" it. You look at it as a set of equations.
I'd guess it slips a $1 and $2 bill into a stripper's titties by the looks of it.
... in the creative coding community.
Patchers like Max and Pure Data allow for realtime graphical programming and live coding environments such as Fluxus exist for realtime graphics and sound. Max was originally written by Miller Puckette in the mid 80s for realtime control of DSP for computer music at IRCAM and Pure Data, started in the mid 90's, is his open source take on addressing some of it's design issues. Fluxus originates from around 2000 as is a live 3d engine for performance using a Lisp varient as the on screen scripting language.
Yet another case of artists/scientists providing a working solution to a particular problem not apparent to other disciplines. Too bad Bret dosen't cite these examples. Perhaps he dosen't know of them?
Bret's argument that realtime feedback is important to creative flow is spot on. I don't think he's calling for the use of this approach as a panacea. Naturally it won't work in all cases but anything that helps with problem solving is welcome in my book. It's not a replacement for deep understanding but really allows you more creative freedom which, as other posted have noted, is useful in creative graphics/sound programming.
We already have something like it: IDEs for typed languages with strong inspections.
When I'm writing something my IDE helps me by highlighting possible errors or undesirable effects. That's not the 'visualization' stuff the author's talking in the article, but it's actually useful.
Sure, you can do that in your head. They got to the moon with an abacus and some slide rules, so why do we need computers again?
That you can make it in your head doesn't mean that you should. Human brains are incredibly slow and error-prone at recall and logic, the primary strengths of computers. On the other hand our brains are evolutionary-level good at recognition and pattern matching.
This should make obvious the conclusions in the video: letting the computer do the recall and logic inferences, and the human the thinking and pattern matching, will produce a much more efficient system, two or three orders of magnitude higher than having the engineer produce all the derivations in his head.
It's a shame to the profession that so many slashdotters will laugh and dismiss the idea, and a sign of how incredibly conservative are programmers when it comes to the tools of their trade. In special because these ideas were already implemented and tested in academai before our current batch of business tools (C, Unix and IDEs) were developed, and then abandoned only because they were more difficult to teach even if they were more powerful to use. There, I have said it.
Singularity: a belief in the "God" idea with the "demiurge" relation inverted.
We have languages that force you to define the allowed range of an integer every time you define it (like ADA), and static analysis tools that find many of these problem. Entering this information into a dialog box wouldn't be any faster than typing it into the source code. The problem is that programmers consider these languages to be too cumbersome, and using such tools on other languages has too many false positive. They would rather have freeform languages like python, which are faster to program and easier to read, but don't catch these types of errors for you, and instead require more discipline in unit testing (which is good to have anyway).
It was in the firehose a few days ago and I down-modded it because (1) the idea was stupid, (2) the article did not give anything but the vaguest hand-waving of explanations, and (3) there is no way someone is going to sit through an hour video if the blogger can't even bother to provide a half-decent summary - which is why I labeled it as binspam ... it's just link bait.
Let's call it what it is, Anti-Social Media.
Most programmers think, that coding takes the most part of the development. In some cases they would admit that testing is also very time consuming. But the real issue is the understanding of the problem. A lot of programmers design while their code. This results in strange development cycles which also includes trying to understand what the program does. As this can be done with a debugger, an interpreter or a trace analysis tool. The real issue is the problem description. First, understand the problem and its borderline cases. Second, come up with a solution for that problem. And third, try to implement it.
BTW: Most programs of today do not contain that many surprising new algorithms. They collect data, the validate data to some constraints, they store data, they provide an interface to query the data. In desktop applications like Inkscape or Word the data is stored in in memory models. And there exist serializers and renderers for the content. So the code as such is not hard to understand, as we all know such structures.
I'd guess it slips a $1 and $2 bill ...
Oh so close. She dances over to you with somebody elses one dollar bill in the left cup and a two dollar bill in the right cup and this magically swaps the $1 into the right cup and the $2 into the left cup without using a third cup, or even a hand. So it is essentially the popular internet meme "1 Girl 2 Cups". Even worse, a sharp eye can see the process involves a colon in the regex... This is going downhill fast...
Three obvious ? perl concepts and the pitfalls surrounding them are:
1) You're operating on the default variable $_. If a single variable chugs thru a dozen processing steps you don't have to name it each time. This is a complete statement, not just the right side of an equation.
2) s/"before"/"after"/ is the simple search and replace operator. Guess how many times it S+Rs? There are options to control this other than the default and noobs always assume the default for s is what they want and it never turns out that way...
3) If your regex matches something in parenthesis, later on you can access whatever that found using positional variables $1, $2, you get the idea. This is why perl is not amused at the idea of user variable names beginning with digits. Why does perl count regex matches from $1 instead of $0 like you'd expect? Well $0 means something completely different, thats for sure...
"Science flies us to the moon. Religion flies us into buildings." - Victor Stenger
The article completely misses the point. The talk starts out awful, but after about five minutes of blithering, he gets to the point. He's set up an environment where he's running a little Javascript program that draws a picture of a tree with flowers, with mountains in the background. As he edits the code, the picture changes. There's a nice user interface which allows selecting a number in the code and then changing it with a slider. This immediately affects the picture. There's an autocomplete feature which, when code typing has reached a limited number of possible choices, offers options like drawCircle, drawRect, etc. Mousing over the selections changes the picture.
It makes sense if you're drawing pictures with programs. Something like this should be in editors for Renderman shaders and Maya programs, and maybe for some game engines. It also makes sense for HTML editors, and there are HTML editors which do that. Beyond that, it may not be too useful.
You approach makes lots of sense for writing mathematical of physical code, where you have a perfect model of the world that is the basis of the problem to solve. Your ancient Slashdot ID seems to indicate that this is the kind of that you have experience with; that, or the essential infrastructure for big businesses, which is similarly model-based.
But when your program is for a specific business flow application, for which there is no model and the logic and corner cases must be elucidated from the client by showing a partially working prototype, the only way to extract all the requisites for the program is to throw in a few lines, show it to the user and ask what it's missing or how the current version is wrong, and then fix it; because the program's behavior has not been fully defined yet when the first version was written, it's d^Hrefined as a reaction of the working code.
Singularity: a belief in the "God" idea with the "demiurge" relation inverted.
Congratulations, you are an idiot.
"Tests", no matter how numerous, cover an infinitely small fraction of possible instances of your code being used (that would be an infinite number of, unless you take into account the maximum lifetime of the Universe). They are supposed to assist a developer finding some faults in his reasoning, nothing more than that.
Contrary to the popular belief, there indeed is no God.
I'm wondering whats really new about this video?
The traditional "good programming" method is actually a horrible programming method, if you can't read and understand your code like reading a book then your not really a "good programmer" and your not really a "talented programmer".
A compiler is one of the last steps in the process, you should know before you compile if your code will work. Interacting programming just helps people learn better programming. You can write C or Assembler and if you truly are a talented programmed you know well writing your code what will happen. When schools or even work places teach programming they teach it in a structures and very formal way, code like any language is an expression and it should be taught in the same way.
Would you teach an artist to paint by following numbers? Would you teach an english student to write but following a script? Then why teach programming by teaching strict methods and formal standards?
Good programming means looking past the code and writing code like you write book or paint a picture, you need to picture whats happening 10 steps ahead of where you are and how to get around problems before they occur, I don't think this video / article is new but I do think it might finally make some of the trolls on this site who cry and moan about structured coding a mute button.
Interactive programming can be made interactive by the programmer and a "good programmer" can write any language interactively by thinking ahead of where they need to be. Programmer who can't really do have one arm behind there back but not tied! I do know some classic programmers who are jedi's in the art, but most programmers who can't preform interactive programming are programming with a blind fold on and with one hand, it's not pretty.
* is a greedy "match as many as you can", and the first
So the result of -- $_ = "foo:bar:baz:qux"; s/(.*):(.*)/$2:$1/; -- would be "qux:foo:bar:baz".
Ah, arrogance and stupidity, all in the same package. How efficient of you. -- Londo Mollari
at least one of the specific situations needs to be the input of a random number generator doing crazy stuff.
You're by far not the only person to reach this conclusion.
140 characters may not be enough; but an hour of vid is too much. Can you add anything to TwinBee's post above? I think he answered my question the best. To reiterate, there are a lot of great researchers out there, and a lot of people like yourself who will tell me their ideas deserve my attention. Your whole line of reasoning is "this one is special". Sorry. That's just an assertion.
Personally, I think Manfred Von Thun who you may not have heard of is really great for having shown us the Joy programming language. That doesn't mean I'm going to tell you "it's your loss" because you don't want to spend the better part of a week reading his papers.
You could read the Wikipedia article on it very quickly instead.
For all intensive purposes, "whom" is no longer a word. That begs the question, "who cares"?
there was a report a few years ago about an entrepreneur who *refused* to employ computer science majors. he only employed english language majors. the reason was he said that it was easier to communicate with english language majors in order to teach them programming, and they were more effective and also worked better when introduced into teams, than the people who had been taught programming at university.
I think there's a reason we don't all know this entrepreneur's name and abbreviated life history.
Note to ACs: I usually delete AC replies without reading them. If you want to talk to me, log in.