in reply to Re^7: Steve Yegge on how to build IDEs and improve speed of dynamic languages
in thread Steve Yegge on how to build IDEs and improve speed of dynamic languages

Oh. I completely agree with you about non-optional mandates. Regardless of whether it's that stupid f'ing hairgrip that I suffered exactly 3 times before I hacked my corporate client's locked down workstation so that I could use wordpad to produce specs and stuff compatible with their expectations, but never have to see that triumph of marketing over common sense, ever again.

I don't use an IDE. And haven't done so regularly since PWB nearly twenty years ago. But that's only because these days they tend to produce makefile equivalents (in XML for dog's sake!), that don't work with command line tools, couch everything in stupid terminology, and otherwise impose stuff rather than offer it.

But, what does it tell you that you need a program to manage your project?

I read the entire OP-linked article and don't recall seeing any reference to needing an IDE anywhere. Maybe I missed it? But a question: could you work without gVim? And if you can, would you want to?

I think there is a big difference between preferring to use a toolset that you are familiar with and find benefit from, and being unable to do anything without it.

That said, I still make a habit of washing my car by hand, which draws--shall we say inquisitive:)--looks from my immediate neighbours who both use power washers. I met a similar thing in the supermarket when I disputed the bill and declined the offer of a calculator to check the items. And I can quite see maps, and the skills required to read them, being a niche market thing 10 or so years from now. With satnav reducing to commodity prices, who needs them.

Did you ever watch Norm Abrams, Master Carpenter in the TV program "New Yankee Workshop"? My carpenter father would have cringed to watch him making mortise & tenon joints using a router and jigs, but there is no doubt that he turns out workpieces much faster than my old man could. Could he do it by hand? Probably. The question is, why would he? And if the next generation of Master Carpenters can't, will their work be any the lesser for it?

I remember a neighbour I worked with back in my apprentice days in a car factory, bitching that the skills required to 'wipe' visible body panel joints with molten lead were being replaced, by the then 'modern', epoxy products. He felt that using 'plastics' was a cheapening of the body finishers art. When he died 20 years ago from renal cancer, it wasn't proven that his many years exposure to lead fumes was responsible, but it probably didn't help.

It's inevitable that as new tools and processes become available to any set of skilled workers, that some old traditions and skills will decline, and even be lost forever. The question is, does that inevitably mean an inferior product?

Like many of my generation, I started out coding in assembler. and still do occasionally through choice. I don't know how your assembler skills are, but (if they aren't your best skills), I doubt you'd be best pleased if I accused you of being less of a programmer because you can't hand optimise a routine to do overlapping memmove operations. (Or whatever).

The simple fact is that modern compiler technology can usually do a far better job of optimising code that stretches to more than a few dozen lines, simply because computers don't forget things when humans do. They can easily juggle and remember to take account of tens, hundreds or even thousands of concurrent parameters whereas the average human can manage 5 or maybe 7. They don't get bored, or get distracted by the football scores, or the need for coffee or the loo. They are infinitely patient and meticulous to a fault.

Now imagine all the ways those skills could be employed in the work you do?

Do you ever use one of those SQL gui's? I do. Bloody marvelous things. Catches 100% of my typos by offering keyword and variable completion. (You use tab completion in your shell don't you?) Reminds me that I have to add a Group by clause if I've used an aggregate function. Almost makes using SQL bearable.

The Perl world is moving toward the use of declarative syntax for Class definition. (P6 Moose et al.) Now what if your DE reminded you when you coded a call to a method that it was still virtual and hadn't been implemented anywhere yet. Or that you just assigned a non-numeric constant value to a variable that later gets passed to a subroutine that will attempt to use it as a number. Sure, you'll find that out later when you compile or run the code, assuming that you exercise that particular path. But wouldn't it be nice to be notified as you did it Friday evening, rather than find out on Tuesday morning after the long weekend, when you try to integrate it with a bunch of other peoples code?

In essence, imagine that all the things that your compiler & linker, or interpreter, discover and record when they are run as a command line (batch job), happened right there inside your editor as you type. Instead of you typing, saving a source file to disk, invoking the compiler that converts your code into a AST, discovers incompatibilities, converts those into file/lineno/error/context descriptions and outputs them to another file, that you load into your editor and use it to (manually or automatically) move to the appropriate point in your code in order to work out a corrective action. It all happened as you type right there in the editor. By the time you've finished typing your code, the editor can write out an object or bytecode file directly.

Then take that one step further. Instead of writing your program to disk as either a source file or object file, it saves the AST directly into your source control database. Instead of diffs being done at the source code level, they are done directly on the AST itself. Rather than pretty dumb matching that flags whitespace, bracket placement and other source level variations as significant differences, it understands the structure of the code and far more accurately reflects only the semantic changes to the code.

And when your colleague comes along to work on your code, his editor will expand the AST in a way that reflects his preferences for tab settings or brace placement Coding standards, or at least the code layout elements of them, become redundant because each person views the code in whatever way makes most sense to them. The code need never exist as conventional source code at all. Unless you choose to print it out, or perhaps move it into another DE.

And once your toolset understands the semantics of the code, and doesn't have to bother re-parsing it over every time it is accessed, think of the possibilities for cross-module dependency checking and cross-referencing; automated documentation generation; automated testcase generation; automated test data generation.

The limits are only what you can imagine, but only once we programmers collectively open our minds to the possibilities, and abandon our need to retain absolute control of our source code, by keeping it in the primitive unstructured data format called 'source files'.

Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.
"Science is about questioning the status quo. Questioning authority".
In the absence of evidence, opinion is indistinguishable from prejudice.
"Too many [] have been sedated by an oppressive environment of political correctness and risk aversion."
  • Comment on Re^8: Steve Yegge on how to build IDEs and improve speed of dynamic languages

Replies are listed 'Best First'.
Re^9: Steve Yegge on how to build IDEs and improve speed of dynamic languages
by chromatic (Archbishop) on May 14, 2008 at 04:36 UTC
    (You use tab completion in your shell don't you?)

    You had me with that.

[reply]
Re^9: Steve Yegge on how to build IDEs and improve speed of dynamic languages
by CountZero (Bishop) on May 14, 2008 at 06:07 UTC
    Did you ever watch Norm Abrams, Master Carpenter in the TV program "New Yankee Workshop"? My carpenter father would have cringed to watch him making mortise & tenon joints using a router and jigs, but there is no doubt that he turns out workpieces much faster than my old man could. Could he do it by hand? Probably. The question is, why would he? And if the next generation of Master Carpenters can't, will their work be any the lesser for it?
    When in the Army I was one of the last generations of artillery forward observers who were trained to their jobs with nothing more than binoculars, a map and compass. Now they use laser-rangefinders, GPS and electronic calculators and guess what happens when the batteries run out (and they always run out of batteries; it is the Army after all!)? You have to suspend the war until you can go out and buy fresh batteries.

    The point I'm trying to make is that with all this assistance you risk loosing some basic skills "I don't have to learn the syntax as the IDE will correct my errors anyhow" and then you loose your grasp of the finer points of any language.

    CountZero

    A program should be light and agile, its subroutines connected like a string of pearls. The spirit and intent of the program should be retained throughout. There should be neither too little or too much, neither needless loops nor useless variables, neither lack of structure nor overwhelming rigidity." - The Tao of Programming, 4.1 - Geoffrey James

[reply]
      The point I'm trying to make is that with all this assistance you risk loosing some basic skills "I don't have to learn the syntax as the IDE will correct my errors anyhow" and then you loose your grasp of the finer points of any language.

      Well, could you check and correct your cars wheel alignment without one of those computer controlled, lasar guided dodads that costs several grand to install? I did it once after fitting uprated struts. It took me nearly 4 hours, but I was dead chuffed with some of the ad-hoc tools I made out of bits of fencing wire and and a couple of straight edges to guide me, and was pretty convinced it was right. Of course, as soon as it had been through the government test station, I ran down to the local tyre place and had it checked. The technician told me that the toe-in and alignment was within some very small margin of being spot on...except that it was all skewed 1 3/4 degrees asymetric about the centre line. In other words, the car was driving down the road sideways.

      The point. Modern life is full of things that mean we cannot do without technology. If your battries run out you can't use your laptop. If the power goes out for long, you can't use your desktop. Computers don't make much sense without electricity.

      As for "you loose your grasp of the finer points of any language". I'm forever being berated around here because I use the full power of Perl. "It can't be maintained by 1st year post graduate after a 4 days Perl course", they complain. 80 or 90% of the code I write is bog standard stuff. If the tools can save me time in writing that majority chunk and leave me to concentrate on the 10 or 20% that needs to be a bit trick, then that's all the good to me.

      Even better, if the some smart guy can write a bit of JIT that takes the non-trick version of that 10% and reliably turn it into trick code transparently, then so much the better. The whole point of HL and VHL languages is to allow the programmer to productively and effectively concentrate upon the big picture, and let the langauge take care of the details.

      Just like Norm and his jigs. He chooses how many and where to put the tenons. He lets the tools take care of making each one fit its corresponding mortise properly.

      Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.
      "Science is about questioning the status quo. Questioning authority".
      In the absence of evidence, opinion is indistinguishable from prejudice.
[reply]
        I fully agree with you that one should use the tools when they are available, but OTOH one should not be restricted by them. When given the chance (and the batteries) I can put down a artillery fire on a target in 1 minute flat with only one ranging shot. But if the tools desert me, I can still do it in 7 minutes with 5 ranging shots at the most.

        Both you and Norm and me know how to do the job without the fancy tools.

        CountZero

        A program should be light and agile, its subroutines connected like a string of pearls. The spirit and intent of the program should be retained throughout. There should be neither too little or too much, neither needless loops nor useless variables, neither lack of structure nor overwhelming rigidity." - The Tao of Programming, 4.1 - Geoffrey James

[reply]
Re^9: Steve Yegge on how to build IDEs and improve speed of dynamic languages
by dragonchild (Archbishop) on May 14, 2008 at 10:11 UTC
    I don't disagree with you regarding the march of technology. I remember discussing this very idea a couple years back after Paul Graham wrote his Hundred-Year language essay. And, if I've given you the impression that I'm somehow looking to just work with old-style tools because the new-fangled crap is too darn modern, then I've explained myself poorly.

    The Perl world is moving toward the use of declarative syntax for Class definition. (P6 Moose et al.) Now what if your DE reminded you when you coded a call to a method that it was still virtual and hadn't been implemented anywhere yet. Or that you just assigned a non-numeric constant value to a variable that later gets passed to a subroutine that will attempt to use it as a number. Sure, you'll find that out later when you compile or run the code, assuming that you exercise that particular path. But wouldn't it be nice to be notified as you did it Friday evening, rather than find out on Tuesday morning after the long weekend, when you try to integrate it with a bunch of other peoples code?

    It is exactly this kind of thing that is leading me away from Perl 5 and towards languages like Haskell with their ability to do static analysis. I want this kind of checking. I try to write my code so that it (mostly) self-checks itself. I work as much with intelligent objects as possible so that I don't have to think about this crap.

    This is what drew me to Perl in the first place, the fact that whole classes of bugs just cannot happen. Dangling pointer? Nope. SQL injection? Nope. Now, I'm looking for a tool that will eliminate even more classes of bugs, particularly bugs that don't fail quickly. Dangling pointers fail quickly - the whole thing dies. Type mismatch errors fail slowly. Things that fail slowly suck.

    I guess what I'm saying is that I consider an IDE to be an indication of a language failing. If I need an IDE, that's because there's something screwy about the language I'm using and the way I'm using it. Given the plethora of languages out there, I should probably find a better language for what I'm doing. A language that doesn't have the failings I'm running into. In other words, I'm looking for Blub. Perl + IDE != Blub.

    My criteria for good software:
    1. Does it work?
    2. Can someone else come in, make a change, and be reasonably certain no bugs were introduced?
[reply]
      Now, I'm looking for a tool that will eliminate even more classes of bugs, particularly bugs that don't fail quickly. Dangling pointers fail quickly - the whole thing dies. Type mismatch errors fail slowly. Things that fail slowly suck.
      Type mismatch errors happen, but they don't happen all that much. Personally I think the way Java/C/C++ etc try to catch those errors isn't worth the even 10% of the effort. I've heard good things about ML, but I haven't tried it, mostly because, as I said, type errors are really not that common (in my code at least). Especially not in perl, with its "hard" coercion mechanisms (and SBCL is also pretty good at catching this kind of thing at compile time)

      I guess what I'm saying is that I consider an IDE to be an indication of a language failing. If I need an IDE, that's because there's something screwy about the language I'm using and the way I'm using it. Given the plethora of languages out there, I should probably find a better language for what I'm doing.

      The "big problem" nowadays seems to me that everybody equates IDEs == static analysis == C/C++/java-style rigid type/class systems.

      That's just not true (and the OP's link explicitly agrees with me). It's quite possible to have a development environment for dynamic languages that's as least as good as, say Eclipse, but it requires runtime inspection. And that is *not* a drawback in general - though to make the best use of it, you have to structure your programs accordingly, runtime inspection gives you tons of interactivity that static analysis just can't do (example: break on an exception, inspect the state, recompile a function from your editor into the running program and restart from the exception point - how cool is that? And all that's been common in serious Lisp development tools for decades). For a fairly good example, see SLIME - that really opened my eyes to what's possible (even though it's far from perfect/complete).

      update: here's an interesting video on SLIME. you may want to start at about 8 minutes in if you don't care about how to set it up over over multiple machines.

      "What should it profit a man, if he should win a flame war, yet lose his cool?"
[reply]
      It is exactly this kind of thing that is leading me away from Perl 5 and towards languages like Haskell with their ability to do static analysis.

      Well. Good luck with that, but you're sure gonna miss Diagnostics when you make the move and start encountering stuff like: 

       
ghc.exe: panic! (the `impossible' happened, GHC version 6.2.1):
         Malformed predicate

      [download]
      I guess what I'm saying is that I consider an IDE to be an indication of a language failing. If I need an IDE, that's because there's something screwy about the language I'm using and the way I'm using it.

      Que? If you use a Komodo with perl 5.10, the language hasn't changed one jot. The IDE simply adds a few tools that you don't get with a bare command line. Some of them, maybe all of them, you already get from gVim. Does your use of gVim make Perl a failure?

      That's like branding the Beetles music crap if someone, somewhere listens to it on a iPod.

      Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.
      "Science is about questioning the status quo. Questioning authority".
      In the absence of evidence, opinion is indistinguishable from prejudice.
[reply]
[d/l]

In Section Perl News