After all my 27 years of writing code for a living (and 34 since I wrote my first line of code) the one thing matters most to me in choosing what to write code in is how quickly I can get the job done.
In my first job at a defense contractor, I met a couple guys (I thought they were old but they were probably my age now!) who had been writing code since the late 50's and then writing batch applications on an IBM mainframe. Since they could only compile/run once per day (and get the printouts the next day) they would work on 6-8 projects at the same time and weren't concerned when these projects might take years to complete. After two weeks on this I was ready to go insane and got switched to working on a supermini which at least had a realtime operating system. I could write code, compile it and run it at the same time. The only drawback was we had 7 people sharing one terminal at the start. Suggestions that each programmer get a terminal were laughed at initially. Being productive in such a limited time was really hard.
After a couple years I switched to working on PCs (which were just out) and having my own "computer" was wonderful. Working in Pascal and assembly still wasn't fast yet but at least I had my own space.
Then I got Turbo Pascal and life was forever changed. I could write, compile and debug applications virtually instantly and my need for speed has never looked back. Even on the compared-to-today crappy hardware I never really found another environment as fast until I started using PHP this year (which of course has no compilation).
Later when I started Mac coding in C we started off with a dreadful C compiler/linker that took 20 minutes to do its thing. When Think-C came out it was almost a Turbo moment again. Eventually it began to get slower and slower and we swtich to Metrowerks Codewarrior which was fast but the applications were getting so big that it still took 30-60 seconds to build sometimes.
When I moved to Java in 1998 compiling and linking still took a fairly long time until the IDEs (and the JVM) began to catch up to the hardware. Still nothing was ever as instant as Turbo had been, despite the hardware being 100x faster. One problem was that the environment the code ran in became so much more massive; loading your code into an appserver often took longer than the build did.
Why am I such a speed freak that any of this mattered? It goes back to the way I learned how to code, even in my first Basic programs in high school, I've always written a tiny bit of code, then desired to test it thoroughly; rinse, repeat. This bit at a time method has stuck with me through all the years of changes in languages, environments and targets. Anything which slows me down between the code change and the test directly messes up my productivity terribly. The more I am forced to batch up my changes the more effort it takes to produce a quality piece of code.
When it got really slow to do any work I thought I was going back to the "old" guys working on the mainframe.
At one job (forever captured in WTF Stories #2: Here Little Virus, Virus ) I spent 3 months trying to write Java code in an environment where the virus checker would unpack and check ever .jar file everytime you touched it. Opening the IDE took 20 minutes, deploying an app to Weblogic took 2 hours. Basically coding virtually came to a standstill. So to get my work done I switched to writing naked Ajax applications; mostly javascript will only data access code written in Java. This meant I could get work done without triggering the virus monster. I began to have that Turbo feel again (except when I had to compile the Java code, then I had to wait 30 minutes).
At my last job every project seemed to take forever to complete (in the 10 months I was there only one app actually was completed). Althought process in the company (waterfall) had a lot of blame, the standardized development environment (rigidly enforced) and the complicated set of Java technologies in use made sure nothing ever was accomplished.
I finally said to hell with it and switched to PHP. Despite its shortcomings I haven't gotten so much done since, well, the Turbo days. I can manage 6 projects at once, deploy stuff as I fix it, follow my a bit at a time development process and actually enjoy getting stuff done.
Now I am working on an iPhone app which means XCode (shudder) and compile/link cycles (not to mention loading up the simulator) so it's not all rosy.
For web coding though life is good; no more delays and both my productivity and my quality are way up again.
Why anyone would choose to pick complexity over productivity is beyond understanding. Of course not every type of application can be done in a language like PHP, Python or Ruby (to name a few) but with the speed of today's computers, it seems so lame to have to work with something that is way slower than writing Turbo Pascal on an 8088 IBM XT. You would think after 25 years things would be faster today but often they are not.
This may be the "I want it now" generation today but I've always wanted it now even then.
Just keep me away from the overnight batch runs!
toast 10/05/2008 21:09
your link to the WTF article is broken for users who aren't on your lan, FYI
ian 10/05/2008 23:56
What's wrong with Xcode? I use it and my compile/link cycles are near instant.
Dalius 10/06/2008 00:01
Correct link should be: http://thecodist.com/article/wtf-stories-2-here-little-virus-virus
Good article.
Turbo 10/06/2008 00:06
You should try Delphi.
creaothceann 10/06/2008 00:21
That's my programming style too, having done my first "real" work with TP. :)
Ricky Clarkson 10/06/2008 05:24
So I suppose your typical cycle is:
Write code. Run code. Find bug at runtime.
This is probably going to be slower on average than:
Write code. Compile code. Find bug at compile time.
Of course, you might have to use a language that has static typing for the second case to happen more often than the first case. And even then, you'll have to use the static typing, rather than doing the minimum the compiler allows.
n 10/06/2008 05:27
It's true that with Java the app server restarts seems to be the speed killer. That's why I value hot code replace. I use MyEclipse's app server deployer/launcher, and a lot of Java code changes don't require a server restart (but many do unfortunately, like any changes to interfaces). Things like JSP file changes don't require a restart. But there are tons of things that do require a restart if you're using things like Spring, Hibernate, iBatis, etc. On my Mac Pro I have a project that restarts in 5 seconds, but my machine at work is a lot slower and my projects are larger.
I do a lot of unit tests which run quickly, but the real test is loading things up in the app server of course.
I'm also doing a little iPhone development. I'd rather be using Eclipse than XCode, but the IDE isn't slowing me down and compiles are quick in my currently small project. It's the simulator that seems to always hesitate when loading the app, like its really simulating what the phone is like (maybe even slower than the phone!).
robvas 10/06/2008 06:50
I remember Turbo Pascal 2.0, fit on one floppy, bright yellow text on a black screen, compiled/ran in lightning speed on a Tandy XT much less a 286 or 386-16
VB is about as close to 'turbo' as you will get these days.
Compile/run every 5 minutes works for some people but slows a lot of people down. There are many arguments for it being bad practice, but I guess you could say that about anything.
codist 10/06/2008 07:31
Oops on the link, still getting used to my new engine.
Paul R. Potts 10/06/2008 14:45
When I was younger the style of development you talk about was called "undisciplined." Now that I'm older it's called "test-driven development" or some variant of "Extreme Programming." You're in good company -- a lot of the most famous programmers actually work like this.
Shadow 10/06/2008 17:24
Java is actually decent. A standard swing application takes about two seconds to launch, while a TCP server process can cope with only one. The incremental compilation of Eclipse is also finally working reliably and mostly unnoticeable.
Packaging an EJB and deploying it on a JBoss application server however takes at least two minutes, even for trivial changes, and whenever you mistype some magic method name, you're in for a full cycle again.
--
When a friend of mine and I started working at our new company, they presented us exactly that: The full Java Enterprise stack and a misconfigured, overaged Windows, up to and including the hanging virus scanner.
We played along cautious and receded to coding some support libraries first. Three months later it was finally inevitable to start working on the main application.
After some politics, some arguments, and several pointless meetings, we basically said "screw you" (right into the face of the relevant manager), wiped the drives, installed Linux and kept using standard Java.
They gave us a an icy stare and went home to headquarters. This was four months ago.
Evil Otto 10/06/2008 20:45
I have one word for you: REPL. Ok I suppose technically it's 4 words (one acronym) but that's where you want to be if you like to write a line of code and see what it does. A number of languages use it as their standard way of interaction (lisp and forth being probably foremost, along with tcl, python, and others) and some others (perl, php) can have it grafted on top pretty easily. These languages often do behind-the-scenes compilation, typically about as fast as they can read the files. Compilation, linking, and cross-module optimization is great for hardcore efficiency freaks, real-time rendering, and scientific computing, but by the time you're done with that level of optimization there's a faster generation of hardware out that runs the non-optimized version just as fast.
Throw off your chains, and throw away your (separate) compiler!
Someone struggling with JSF/JPA 10/07/2008 08:42
Nice post, you successfully described what I've always been feeling (particularly regarding Java).
aLe 10/07/2008 10:02
I've used the real good Turbo Pascal at school. My first job was on IBM AS/400 with RPG where I knew old people who develop with punched card. The development process is very good thanks to PDM, SEU and RLU. Then swithced to web application on Unix/Apache with C/PHP write with Vim debug with Firebug (if needed). Now working in Java/JBoss with Hibernate/Struts under Eclipse, and yes, I didn't seen a finished project in 18 months! Everytime a JBoss restart is needed I can take a trip to Pechino and back, by feet...maybe with bicycle Without Hibernate/Struts and Vim instead of Eclipse things are much better, you can modify the source (java or JSP) files and refresh you browser to see modificaion in few second. Everytime a restart of the server is needed when deploy the entire application to the production environment. What I'm feeling is that people objective is not finish a project but start it in a J2EE environment. some humor http://www.thehumorarchives.com/joke/JavaprogrammersvsMicrosoftprogrammers
cowardly dragon 10/08/2008 09:34
How the hell did Turbo C/Pascal do its magic? Granted in DOS it is doing everything in memory, but I have 4GB system ram now. Is it simply the disk? You'd think caching would take care of it.
A 10/09/2008 12:05
Holy! You just carved my thoughts into words with your post. I use the exact same style of coding. One little function at a time. I need to see it work before I can even start writing the next one.
And yes - Java sucks for REPL style coding. I love firebug for the exact same reason. REPL.
Energy drink 10/10/2008 00:58
I understand your points. But I think that with Java you can get something similar if you use a different approach. If you use Eclipse, e.g., it copiles for you in the background and you can save a lot of time cause it tells you of any syntax error in advance. Then it depends only on how you organize your classes: if you do it propelry your business logic is really confined in restricted areas of code that you can control easely. Working with automatic testing can help as well. If you do XP as they tell you to do, i.e. you write test classes for all of you work from day one, you have that the system is tested in background while you code. I have instead the opposite problem: when I use dynamic languages (not strongly typed) I get little support from the IDE (this is gettin g better now) and it is extremely easy to do silly mistakes (referencing something that tdoes not exists e.g.) and take a while to debug it.