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.
Interesting article this, just not for the slashdot crowd. /. crowd). /. users like their summary shorter then the article, mikejuk did his best!).
Why? The subject is OK, it has to do with programming (so no discussion on whether YRO or similar is interesting to the
The problem is the 'article' itself: it is almost shorter then the summary (and:
The reason the article can be this short is that it links to a video. No problem you say? Surely in a few posts someone puts a transcription online.
The moment I am writing this, this could be first post. Not that I think it will: it takes me too long too write.
But at least I am sure that I will be BEFORE any one with an important comment on the article, AS IT TAKES 1 HOUR TO SEE THE VIDEO.
And yes, the article says that it is somewhat slow to begin with, so the interesting bit is probably somewhere beyond the first 20 minutes or so.
Why this rant? The article looks interesting, and I was planning to read it. Until I saw the 1 hour remark, surely slashdot editors do not expect us 'No-I-did-not-read-the-article-and-even-skipped-part-of-the-two-paragraph-summary-regulars' to actually view the video? It would be hilarious if after 10 minutes of the video it suddenly turned into something else, only no one on /. will actually get this point.
Now go program me a nuclear reactor control system with this.
A debugger the cloud? to help us solve NP-Hard problems?
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.
No sig. Move along - nothing to see here.
Sounds like he (The guy in the video) spends too much time thinking about other things and not enough time actually coding.
Every other month someone comes up with yet another Silver Bullet. It is so boring, so fscking boring.Don't /. editors have a little bit more clue than posting such rubbish as news?
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.
Do they have any idea how many hours there are of "the one video you must see this year" on YouTube. I wager at least 2 years worth.
It sounds like they have a REPL, possibly with a GUI standing in for readline. Unless somebody has an executive summarty that refutes that, I'm not wasting my time.
... and I started to feel like a programmer when I stopped needing to check the effects of my work every other 5 minutes.
"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
Its enough to watch first few mines. IMO this approach is completely invalid. It is nice to see immediately changes to the code on the screen, but this applies only to GUI and only to variables which can have arbitrary values. In real life you cannot iterate over an array and skip some element, transfer money from user with random uid, call not existing function, etc. Also executing invalid (not-yet-completed) code can destroy your data easily and waste your time.
Second part starts in 18:00 and is more interesting, but it won't work in real programs for two reasons:
1) function arguments are usually complex objects and defining one (for testing purposes) is often much more complicated then just writing the method
2) you still need unit tests which do pretty the same
But all in all a debugger which shows variable values for several lines of code could be interesting.
The much-hated VB offers much of what you're looking for. Like it or hate it, it is really good for prototyping and for rapid development. The only drawbacks is that it encourages bad code and marries you to Windows.
The Christian Right is Neither (Christian nor right). See: Matthew 23, Matthew 25, Ezekiel 16:48-50
... 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.
The conjecture that the tree that you are watching is the result of the code you are pointing in the wrong direction: the tree is a representation of the code. ,Green 1989) . So we are fucked up again. But if you can find a complete-enough single-dimension representation of your sw domain than you are able to enter the golden kingdom of visual rapid prototyping.
In this way you may start to forsee how this may be related to programming related to non-UI stuff.
Representation of SW is already a candidate silver bullet in The Mythical Man-Month(Brooks , stuff to read) . The problem with sw rapresentation is that as long as sw has multiple concerns its representation should have multiple dimensions. So we invented multiple dimensions for software representation using different charts to represent different dimensions (think about UML) . Guess what? multiple dimensions are mind consuming and counter-intuitive , you may describe them as very viscous notations (Cognitive Dimensions of Notations
Usualy you can only afford to design for requirements that can be proven wrong or correct by a disciple of Dijkstra but you are not able to design for something like beauty. You can not design in the engineering sense to cope with ambiguous or vague requirements BUT you can prototype for it. And if you can rapid-prototype it 's not bad at all.
the extension of this idea is to use evolution-style techniques. from an automated perspective, that means deploying genetic algorithms to improve the code. unfortunately that means that good tests have to be written in order to verify that the code so (eventually) generated is actually "correct". many people would fail to go to the trouble of writing good enough tests.
yes - the alternative is seen to be to "read every line of code and make it run in your head".
i can't handle that. a) i can't be bothered b) i have some strangeness going on in my tiny brain that makes line-by-line logic rather hard to do. so there's an intermediary style - one in between the line-by-line and the genetic algorithms approach - that i've use for programming, successfully for 20 years: accelerated development cycles.
in essence it's incredibly simple: pack in as many compiles into a day as you can possibly manage. optimise the development environment - and the code structure - such that this is possible. install ccache, install distcc, get a compile-farm, don't do complete rebuilds but make sure that the Makefiles are properly structured to detect changes to source files etc. etc.
by increasing the amount of times that the program is run and tested, you automatically increase the productivity, just as TFA says.
HOWEVER, there is a CAVEAT.
as i found out when the samba team dismissed the work that i had spent three years developing (and proving to my satisfaction by having run tens of thousands of tests over that three year period) if you follow the above development technique it is almost IMPOSSIBLE to actually explain how a particular solution was derived.
the reason is because you literally don't know. you know that it works, because across the entire set of parameters under which the code is utilised, you KNOW that it works. but the actual bugfixes? when presented with your *own* code and asked "why did you do it like this??" you can't exactly answer "well i tried 50 iterations of modifying the code and this was the one that actually worked" when you're expected to answer "the technical answer is that this algorithm is an implementation of a well-known algorithm that is described on page N of K&R's recipes on c programming: let me take you through a line-by-line code review and walk through it with you".
the key here is that the person who is asking you to justify the coding decisions is expecting you to be ABLE to do a line-by-line code walk-through, but because you've never done one of those in your LIFE let alone on the code that you wrote only a few weeks ago...
but the real problem comes when you've developed 5 to 10x more code than anyone else in the group, through this type of technique. not only does it show up your peers as potentially seeming to be incompetent, but it also means potentially that you wrote code that is very very difficult for the average programmer to understand.
that makes for a massive maintenance headache.
there was a survey done over 10 years ago, of the productivity vs salary across several professions. most professions, the ratio of salary to productivity for a range of employees varied by a factor of about 1.5. e.g. one person paid $10k could have a productivity metric of say "2.0" but their colleague paid $20k could have a productivity metric of say "6": (20/6.0) / (10/2.0) = 1.5
but for programmers, the variation came out at a whopping 10 to one discrepancy. in other words, someone who was paid only double the salary of one of their peers could be TWENTY times more productive than their lower-paid colleague.
it would be very very interesting to redo this survey, specifically for programmers, but this time taking into account the *techniques* that they use to develop code.
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).
The hard part about programming is understanding and decomposing the problem. If you're not any good at that, then no matter what language you use, you're going to struggle and produce crap.
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.
so there is definitely something to learn here. but my god if imperial college had tried to get me to read jane austen instead of teaching me object-orientated and parallel computing architectures i would have hit the roof. mind you if they'd asked me to scan the book in and do some parallel processing on its contents then.. hmmm.... :)
I can't even bring myself to watch this, and I'm generally a compulsive bring-myselfer.
Dijkstra spins in his grave. Somewhere out there, Lamport is guzzling Guinness by the barrel and swinging his underwear around his head, while Knuth plays organ dirges.
The plural of anecdote is performance bonus. That was the VB business model in the late 1990s. This won't work twice. To obtain twice as many programmers at half the price there's now India and China. And they can do math.
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.
It's an hour long, and I don't have the patience to sit through someone gibbering on for that long. Is there a transcript?
Terrible ideas that would transform coding time to 98% on the oooh-aaah-slider and setup for endless runtime tests vs 2% of actual coding. This is worse than time wasted dealing with various Android incompatibilities! Inspirational software engineer gibberish! His approach: a different way is a better way. Sell it. Sell it. Uhm, ok. Let's see some real world exmples of software projects using more than javascript joke code. "It's the specs that Kosinski sent us. In my opinion, sir, they're gibberish."
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.
But this is only useful in his simple program that has no abstraction. This is firebug for canvas, basically.
Everyone who watches movies knows real programmers bang on the keyboard 300 wpm while mumbling and making
"efforting" faces while the monitors around them rotate and zoomify 3-D objects, Mr Tony Curtis.
A few moments in my life can be considered life changing, very rare, very seldom... ...but this video was one of them. He is totally SPOT ON! Instant and LIVE feedback on programming, changes EVERYTHING.
Let me explain where I come from, so you understand why I react the way I do to this if it sounds weird or foreign to you, but I was the kid in class who asked too many "dumb" questions, the teachers couldn't answer, I wanted to know WHY X and Y was what they where, and not just accept that they where there. The teacher wasn't creative enough to explain why, and told me to just accept that it was there....
that made me feel dumb for 15+ years, until I actually discovered that I was smarter than any of those teachers, and had an IQ way WAY above average (yep..that explains why I didn't need manuals...duh!)
The point of the case is, not how intelligent I am, but the way I LEARN THINGS! Such as the video demonstrates very elegantly.
I'm a tech nerd, I have a room filled with Test-Instruments, you know...oscilloscopes, multimeters, rf-generators, spectrum analyzers etc....I don't have a heavy theoretical science background, but yet I'm very capable of building and constructing robots and advanced circuitry (much to the confusion of my educated friends), but the truth of the matter is - these instruments.. ...yes...here comes the point of the video as well... ...provided me with a VISUAL FEEDBACK ON WHATS GOING ON!
Did you get that, slashdot audience? Visual feedback is what it's all about (to certain visual persons like me), we're no dummies because we can't just accept or visualize data inside our mind based on eg. traditional math such as you know it, but have a different...visual mind)
Benoit Mandelbrot comes to mind....if I'm not mistaken...
Get it?
What this world is coming to - is for you and me to decide.
This guy have not used c# and visual studio. With Visual Studio you can debug, modify code during debugging, drag current instruction pointer back and re-execute code. You can write program as you debug and see results right away. Of course it is unavailable on Mac.
This is one of my favourite things about using Unity to learn programming - you can leave the game running while making changes to your code. Unity will recompile and reload them without having to restart, and it's both fun and extremely useful - especially when I was working on the GUI.
Why didn't anyone ever tell me to try running my programs at intervals while I develop them?
You guys just blew my mind.
Is this the beginning of a new wacky religion?
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.
I would usually re-compile and re-run my codes at least four times to make sure that the compiler is not lying to me before I think to re-visit my broken codes.
Kidding aside, maybe this free online course from Peter Norvig will prove useful to someone.
CS212
This sort of epiphany evangelism is just fluff, and does not contribute anything at all. IDE's have been trying to do this sort of thing for the last 15 years, the attempt has brought us a few nice features (powerful inline debuggers, RAD tools, gui drag n drop, code generators), and also sometimes brought a few nightmares. Ultimately it has not removed the need for traditional coding, and there is no sign of it happening any time soon. The bottom line is that a system that removes coding will have to make assumptions about the nature of the problems it is trying to solve, the nature of the inputs and outputs. The ecosystem changes relatively rapidly in the programming world in the last 2 years for example there has been a massive shift to broweser/client side processing with jquery, around eight years earlier there was a shift from desktop to web. Anything that makes too many of these assumptions becomes quickly redundant. Traditional code has many advantages, it is very flexible, context independant, readily testable, easy to extend/supplement and keep stable.
Unless somebody wants to give a better executive summary, there's no way I'm weeding through an hour of video.
That's your loss. The guy behind these ideas is, IMHO, one of the most interesting researchers in the field of computing today. Go ahead and check out Bret Victor's home page directly if you don't like the blogspam link. He has many other ideas about the interplay between visualisation, mathematics, and software development.
There are way too many people in this Slashdot discussion whose only contribution is either "TL;DW" or "it's a dumb idea that only applies to GUIs". Those people obviously haven't understood the fundamental ideas that Bret is suggesting, and I suspect didn't even bother to watch the whole presentation before diving in and criticising. It's sad.
Genuinely interesting and innovative ideas are rarely conveyed in 140 characters, or in a three-paragraph echo chamber blog post with 5 Google Ads attached. You have to invest a little of your own time if you want to do anything worthwhile. I recommend that you do invest some of your own time in studying this guy's work if you're at all interested in what's wrong with maths and/or software development today and some ways we might improve it. Or you could just spend the same hour reading another five troll blog posts about things like whether it's the year of Linux on the desktop yet and then getting involved in the inevitable more-heat-than-light comment threads, I suppose.
If you disagree, post your argument. (-1, Overrated) isn't your personal censorship tool for views you don't like.
Many of the complaints here about his ideas were less than an hour after the slashdot post. Problem is the video is an hour long. Blah blah I'm new to slashdot, but before you tear down someone else's idea learn what their idea really is.
I set up a separate script in another window that, in a loop, keeps trying to compile and run my program. If it fails, it immediately tries again (I was thinking one day I should make it detect if the code has changed, or not, but then, I figured, I have too much computer power so it needs to be wasted). If the program compiles, and then runs, then it sends me an alert (making loud grunting noises and such). So all I need to do is sit there and randomly code stuff I have no idea about, and keep trying until I hear the grunting noise. Then I'll know it's done, and release the beta version.
now we need to go OSS in diesel cars
Where is the ability to download Bret's software? He worked for Apple, why isn't this in Xcode already?
Jonathanjk.com
3D graphics programs like Maya and Houdini have a nice little set of features that comes quite close: they do not forget operations that you make, but instead can repeat them for you again and again. In fact, this mechanism exists to allow the user to go back and change parameters for old operations. The program then reruns the entire history (effectively a program) and displays the result. This works even for quite complex contraptions. In a way, this is just that same kind of visual debugging. Once you understand that a graph can be a representation of a program, that is. Animation features allow you to go back and forth in time and there are also features to trace out the complete paths of objects on the screen so that you can see it all at once.
Spreadsheets also come pretty close: if execution were allowed to loop and branch properly (to become Turing-complete), you would be able to create an instant visualization with them as well. Actually, the program would be its own visualization.
http://www.moonlight3d.eu/
Reliance on tools of this nature will reduce the quality and clarity of the source code. The programmer will have little motivation to use descriptive variable names or constant definitions.
This is evident in the video. You can see the use of integer literals everywhere instead of symbolic constants.
You didn't watch the video. It's not about removing coding. It's about getting instant feedback on what's being coded.
Well actually it's about much bigger issues than that, but that's the heart of it.
He means interactively, he is talking about immediate feedback and interactive design. Leaving aside that these things are know and already worked on, why could he title his conference after what he is actually talking? Why did he had to make it appear as if he's breaking some philosophical ground and why did he had to inkoe great creators from the past? Oh yes he's an Apple guy, the company that used 1984 imagery to insult IBM, the company that used the ghost of communism to sell themselves, the company that abused images of Ghandi to sell you questionably priced equipment.
But... the future refused to change.
REPL?
With the little tree, and the little leaves, and the nice little sun, and it is all very simple and friendly with lots of colours? Even the voice of this guy has this monotone, almost hypnotising Bob Ross quality, and it looks all very harmless and friendly, but somehow you get the feeling that you can't take it too serious and that the method is fine for him and his little tree, but that you couldn't use it to make anything much different.
I was thinking more C/C++ where failed assert statements generally mean pretty fatal behavior.
XML is like violence. If it doesn't solve the problem, use more.
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.
"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." - by AdrianKemp (1988748) on Sunday March 11, @03:29PM (#39319623)
Agreed, agreed, agreed, 110% - that is, unless what I wrote is not good to begin with (happens, even though I usually think often for DAYS before writing anything).
In fact, once I 'map out in my mind' what the program needs to do, based largely on spec requirements (either ones I do myself for personal code, or ones given me for business work (mostly MIS/IS/IT work here, the 'steady-eddy' money that's usually around because no business really EVER does things the same as the next one))? I know what it has to do, & I start building it, piece-by-piece.
Now, I don't know about you guys, but like "Wayne & Garth" said in "Waynes World" (while garth held is UNIX book no less, lol) - "WE FEAR CHANGE"...
I.E.-> Usually around the 10k-20k lines mark (compiled code that is built by the IDE & compiler engine) & 5-15k hand-written lines in smaller apps for example?
Well... If it's working well, and it usually is for smallish type projects (think freeware/shareware apps)??
IF I get a 'smart idea', such as what you see when you 'refactor' an app OR start to @ least (& I do that 'oldschool' by hand, spotting repetitive routines that could be trimmed out into a single function you pass parms into etc./et al, after profiling the 'slow' areas with hi-res timers @ start & termination of procs/subs/methods/functions etc.)??
I do it!
HOWEVER, but often RELUCTANTLY...
That's right!
Just because I get a bit 'scared' that my idea isn't going to pan out though it "looks good in theory" in my mind!
Yes, it happens, did to me recently!
I 'burned a LOT of time on it' in fact & I was rather let down (was working with stringlists, but their frigging limitations on assigning them to visible controls isn't always perfect, ie-> sometimes if say, they're sorted? No dice for removnig elements etc. or their limits on records possible etc.)
We've all been there saying 'oh yea, that's better & will work' until you open a can of 'whoop ass worms' on yourself doing it...
Again, I ran into recently in fact on a freeware app (I'm doing now in fact & began submitting it to places for distribution once it passes muster/antivirus tests, etc.-et al) - it's been nearly 7 yrs. since I was into this (was from 1995-2004 or so pretty bigtime, decent side money, some notoriety, & just GOOD practice too).... "You've been asleep CAP, for almost 70 yrs." lol, human time vs. internet time that is.
Anyways/anyhow:
I'd burned a lot of time on an algorithm/engine that SOUNDED good mentally @ first, until I hit crap in the details in stringlists... it's always THAT!
I.E.-> Some SMALL detail I overlooked in fact or I didn't know about since I'd never tried it before ('the devil' truly TRULY are in the details in this work & we all know it).
---
"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." - by AdrianKemp (1988748) on Sunday March 11, @03:29PM (#39319623)
ABSOLUTE 110% AGREEMENT here, for sure... lol, imagine a blindman leading folks along a path on a cliff is what I just thought of reading what you wrote!
APK
P.S.=>
"It's just another "wouldn't it be great if computers programmed themselves" video by someone too stupid to tie their own shoes." - by AdrianKemp (1988748) on Sunday March 11, @03:29PM (#39319623)
Sometimes I feel that way too: BUT, I try to 'stop myself' (that is unless that person starts 'busting my balls' too hard, & then like most fo
luckily I am old enough to still benefit from ignorance. I am able to visualize such things while coding without aide. It has always been a competitive advantage. If you generalize it via a video component to all coders, it levels the playing field. The gifted super coders, who I suspect can all do this visualization in their head, will simply be rendered normal. Unfortunate, but predictable in the long line of jarring advancements. Bravo! The really interesting part of this to me is I bet that is how most great coders think implicitly. I bet that is why a great coder is 10 or more times more productive with fewer errors than average. Let's call it visual coding and whether it is computer aided or God given, it is very productive.
How is this not paint?
the time spent writing / compiling / etc is not just about getting the thing to work.
its about organizing it in some half-way logical and elegant manner so that other people can understand it and work on it later.
its like composing a poem (minus the emotional considerations or the search for truthful depictions of the human condition).
yeah, fracking shale gas is wonderful way to get rid of 'terrorist oil'.
for me this looked like something we learned even before we wrote our first program in school at a computer.. debugging on paper..
Before you even started debugging on paper, remember to draw out the flow chart
Muchas Gracias, Señor Edward Snowden !
Just be the code Danny, be the code...NA...NA...na...na...na...na.......
When someone says "I want a programming language in which I need only say what I wish done," give him a lollipop.
from: http://en.wikiquote.org/wiki/Alan_Perlis
Lisp has been able to do this for just a little while. A few decades.
Grab that spare Model M, some duct tape, and presto: The keys to the Lamborghini!
http://www.youtube.com/watch?v=kTYFsyFFfPs
PS. Why the hell is this video unlisted? Made it really hard to find.
Its about: just do it and along the way we meet great serendipitous moments of insight. Bret victor has a couple of great vimeo vids which show his great teaching ideas. Whatever discipline, programming is just one of it.
This is fun for what he show's, but it doesn't work for everything.. Also we already have stuff like that since Visual basic 6.0.. In the end it does do compile, the only difference is you don't have to hit the compile button..
This was a 1 hour talk talking about a "general principle" and "a better way to program". If he had instead titled it "A cool hack for GUI programming" or similar and proceeded with a 5-15 min talk about how it works and some examples only it would have been fine. It's a neato little tool/idea that can be used in some specific situations such as GUI/Games programming as he showed.
It's when he generalises the talk into something more than a hack into a "general principle" and "a better way to program" that the talk becomes complete bullshit. It's not a general tool/principle. It's a specific tool/hack/idea and it's a simple one at that and not very new/revolutionary. It's been done by people everywhere.
Also, he didn't show any examples of where it's not very useful although he had a whole hour (disingeniously implying that it works for everything).
As a programmer working on difficult and abstract problems, his method is not that usefull. The example was good for a single simple problem. But that is not really the problems you have when working on difficult problems. And writing visual-feedback software for complex problems would be like writing book authoring software that creates a movie from the book you are writing. It is a good and obvious idea. But absolutely unrealistic for real world problems.
Where it is *very* useful though is for programmers designing software. If we can make our software work like that in their limited domains, then it is a terrific way to solve our users problems.
Max M - IT's Mad Science
His principle is perfectly applicable to the programming of networking protocols. Imagine working on IPv6. You have the network sniff in one window. You can rewind the timeline, make changes in the kernel module and see live the changes in the sniff, including the differences in the peer's replies. That would be an incredible productivity tool. And it seems feasible to implement something like this with virtual machines. As you change the code the framework transparently compiles it and runs the protocol exchange again in the virtual machines, updating the sniff to match. The problem is performance, so I don't see this happening today, but the principle seems sound.
You have JSP, JSTL, and EL code with JavaBeans emitting HTML, CSS, JavaScript, and jQuery with AJAX calls, driven by Struts with form beans and Actions, talking to a back-end object model that uses Spring, Hibernate, MQ, and DB2. When he does a video explaining how to visualize that, I'll watch. Extra credit if he explains how to visualize any and every Java library on the list breaking its own configuration syntax between point versions. More extra credit if he visualizes Hiberbate with legacy databases.
When I'm "creating" (I'm a creator XD) in OpenGL for example and I want to see what effect some set of variables have visualy I simply change their vallues using the keyboard when running the program. When I`m programming a html page I change style values using firebug. Eclipse compiles everything you type in and show you bugs making the whole IDE unusable while on it (I can't stand text editors that sometimes take more than a second to type in something I keystroked - vim for the win).
If you want to create a IDE that gives you instant visual feedback of some kind of code, cool but no way it will have a big scope, or number of functionalities. And good luck with that.
Several minutes I'll never get back.
When in first year at the university we were introduced to functional programming as the first paradigm to learn. we would make fun at it and hate it, you'd thought they would start with something simple and low level like C (which by the way is assembly++, like BASIC).
But Caml, an ML variant, had its charms. strong typing, as in perfectly strong typing. type inference as in, it looks at the code and perfectly infers what the input and output types are. it was so picky that you add "+" for addition between ints and "+." for addition bewteen floats. so you would try and input your damn recursive fonction, hit keypad-enter and the damn interpreter would inform you of type mismatch, or accept your function which would mean it should mostly work, and prints out the types (such as int -> int or list of int -> list of ints) . running on windows NT4 on 32MB ram computers at the time, which was impressive - a real OS in not much ram.
That ultra-strict strong typing bitch was awesome too, if your function could deal with any kind of element or list then you would get a truly polymorphic function without any special syntax.
yes, it's my programming style. And I choose the tools enabling me to do it. ...
That means, screw the compiler, or have a really fast one.
Basic, assembler, awk, bash, perl, javascript
All those languages can give you quickly a response if your little modification has an impact. :-) That code saved some projects from being canceled. Yes it's bad code but it's doing the job. Usually it gets later fixed by a rewrite: keep the functionality, make code maintainable.
I call it iterative programming. One step after the other.
Result is of course lovely spaghetti code
Seeing the results of what you write is what debuggers are all about.
The only problem is that debuggers have universally horrible documentation and are difficult to get hooked up, so most programmers don't bother.
Make a debugger with easy to understand documentation ( don't hire the tech writers from Oracle ) that is easy and fast to set up.
The talk was not about revolution in programming. It was about a person defining a principle and using that to guide what they do. In this case, the speaker, decided that creative designers need feedback, and he created these demos to show how feedback can improve some simple situations. If you didn't watch the video, you look very stupid criticizing it. This discussion is one of the worst I have ever seen. You may be a great programmer, but you have a closed mind and made a bad decision to post about something you know nothing about.
The point of the video is not to show some new technology that will take over development in any field. The eye candy at the beginning was just to garner some attention from the audience for his follow-up point. He believes that there exists a problem where people think of ideas and cannot realize them due to lack of technical skill. The tech demos are just him following through on trying to fix the problem he believes exists, which, by his definition, is living/working on a principle.
This is a life lesson talk, not a tech demo. You just have to watch the whole thing to get it.
Hmm. This reminds me about Winforth, how you can edit the source code in realtime, and is also very practicable esp in Artificial Intelligence. I'll be looking forward to this feature in c++ and some other languages.
As more processing power is available, compilers are getting smarter. At least working with C#, it highlights errors long before I have to compile the code to see what the results are and other systems are trying to catch issues long before they are built and shipped.
The idea of "realtime" software development will make sense in the near future, why not build an application while it is running so you can see the side effects of the code immediately, both good and bad.
However the problem isn't "conceptualization", its in testing. Programs are only as good as the testing done on them. Anyone can whip up software, but bugs are found from usage without adequate testing.
What is needed is not an "easier" way to develop software, but a smarter way to test it. If a compiler could be invented that would automatically generate the test cases to throw against your code that would solve the problem of buggy code once and for all. Today test driven development is still broken by the idea that humans have to write test cases. If a test case is not properly written with adequate code coverage, it can still produce code that fails. If an automated process could throw every conceivable scenario where your code could fail rather then just "compile" and execute it, that would be the future of bug free software.
I haven't thought of anything clever to put here, but then again most of you haven't either.
How can you possibly know how to extend it when someone changes the requirements, or new hardware becomes available, or you need to port it to another OS?
I've been coding for over a decade. I can prototype something and get it working fairly well in a relatively short amount of time. Making it bulletproof takes 10x as long. If I just make it work for my initial conditions, I'd be 10x as productive....but pity the poor slob that needs to come in later to fix it when conditions change.
His point isn't the interactive language per se. Nor is it the interactive Flash editor. Nor even the interactive ciruit diagram. They're just examples that he's using to get his message across. He even starts his talk pointing that out (at 62 seconds in to the talk).
His message is that you should try to find a guiding principle to guide your work. A sort of focus, I guess one could say, rather than working on random problems. (In a sense, his talk really begins at around 34 min.) The point of the talk actually has nothing to do with programming at all, but because of his background that's the direction that he's coming from.
His own guiding principle is that creativity is stifled when you can't get immediate feeback. So he wants to find ways beyond that. Thereof his examples.
Yes you do need a video for it.
For f7cks' sake man, reading comprehension. This is what I wrote with bolds to emphasize:
You don't need a 1hr long video as the sole measure with which to convey a technical point.
Now, regarding this:
It would not be conveyed by static text and diagrams.
Not even the gist of it. Are you telling me that no amount of proper technical writing can capture the gist of the idea, that it is impossible to write a summary of it? What, is it so trascendental that it escapes description, that it defies summarization in a written language? Do you realize the monumental absurdity behind that sentence? The only circumstances I've ever seen such a thing is when dealing with meta-physics snake oil salemens (or snake oil salesment in general.)
Lemme sell you a bridge, no no, the idea is to grand/complex/<insert appropriate adjective> to be described in a written summary or presentation. Come to our <insert time length in hours or days> lecture/video/meeting/whatever so that you can see why you must buy my bridge.
Can you spell "bullcrap"?*
* - btw, the sarcasm is not directed to the people who made the video (by all accounts, they could be right.) It is directed at this absurd post of yours.
I think the example of the binary search is a bad one for reasons already pointed out. But that example differs from the others by being a problem for which you know exactly what it is supposed to do. I hope there are still people believing that just trying out something -- be it a doodle, a physical experiment, some code or a circuit -- is an important process in the discovery of new things.
Sounds like he's more interesting in finding the thing that will give "meaning" to his life, than actually caring whether that "thing" is sensible or practical. Go find love Bret, have kids and program stuff that makes a difference to other people's lives. That works for most of us...
May be this will make monkey coders inventors...
This was known decades ago. I remember projects devoted to partial compilation to provide interactive feed back on what your code is doing.
The problem isn't how fast you get feed back -- it's getting any at all.
Unless you instrument your code or run it through a debugger, most code doesn't generate any output, so you don't know what it is doing!...
To instrument it generates nearly 100% overhead and running debugger can easily take 10X as long or longer to run the same code. Neither is a great tradeoff.
If the computer could take old and new and show us differences in execution flow -- or just SHOW us execution flow, that would be useful. Even today -- tools to show *static* execution-flow are rare and complicated to use -- not to mention difficult and expensive to develop.
With the cost for development tools being pushed toward 'zero', fringe benefits like visualization seem like a frill I'll never see and is unlikely to be developed unless vendors deem code excellence to be a much higher priority than it is now: today, mediocre, is more than good enough as long as it gets something in the customer's hands.