Knowing How Code Works

James Robertson wrote that Scoble was hurting Visual Studio marketting by saying (openly no less) that he was writing C# in notepad. Note that I’m not too sure how serious James was because he comments on smalltalk….



I of course, have something to say about this 🙂


Doesn’t even matter whether VS is good, bad, or indifferent – it’s a perception thing. Have influential people visibly not using your development tools, and it makes people wonder.



Scoble responded defending himself and rightly so. However, one of the remarks in his comments got my goat.



Y’know, the “simple text editors are best for learning” meme is one of the most rediculous ideas that has taken root in computer science. I suspect if Microsoft didn’t make the most popular (and arguably best) IDEs, this nonsense would never have caught on, and only survives as a tagalong to “Microsoft is Evil” meme.



Syntax highlighting, autocompletes, and forms designers are absolutely necessary to get work done in a reasonable amount of time. The first two are available in any good text editor (which Notepad is not), but the last takes a full-fledged IDE.



This seems to be the typical Microsoft (and in fact, US government, but I’m going to ignore that for now) point of view. “Don’t worry about it little guy, it just works, go ahead and use like we tell you to.” Also, if I remember right, Borland made the most popular IDE for a long time, it has not always been Microsoft (much as they’d love you to think that).


When I was at UCFV I I took the “Advanced Pascal” course (yea, it was a while ago) in which we were taught about memory management, dynamic allocation, pointers, de-referencing, strings, null termination, and all sorts of other things. I have to admit I didn’t do well. I could never remember how to reference or de-reference, or when it was needed. I think I ended up with a C/+/- in that class.


The next semester we took assembler, which I think was probably the best class I took while in school. Not because I did well, or it particulary impacted my working life, but because it taught me how things work. Being shown “the bare metal” and being shown what I was actually doing was absolutely invaluable to me. Knowing what I was doing when I de-referenced something, or how strings are stored and why they need to be null terminated. You can survive without that information, but knowing it will do nothing but help.


Some might argue that you don’t need to know how an internal combustion engine works to drive a car, and I agree. But being a programmer or learning to program is not being a casual driver. Even if you don’t know how your engine works, having at least an understanding of what happens when you hit the gas and brake will put you ahead of the other people who are just blindly hitting pedals. If you are a program there is no reason not to learn, or at least attempt to learn a bit about the internals of the system. If you are learning to program in notepad you get to see it all. You don’t understand what is going on by clicking through a new class wizard or some such shit. Having things hidden may make people who know what is going on more productive because they don’t have to worry about the details. If you know that the code from the wizard is correct and does what you want (or how to fix it if it doesn’t) then you have less work. But until you know what the nice pretty GUI is doing, you can’t be sure where the problems are, and if they are your fault or the programs.


The first thing that I do when I try to learn a new language or toolkit is to re-type the examples out. Even just me typing (as opposed to copying and pasting) gives me (probably different for other people) a better idea of how to use it.

2 Comments on “Knowing How Code Works”

  1. Aside:
    ‘Syntax highlighting, autocompletes, and forms designers are absolutely necessary to get work done in a reasonable amount of time. The first two are available in any good text editor (which Notepad is not), but the last takes a full-fledged IDE.’
    He’s wrong about the last requiring a “full-fledged IDE”. It does if you take the traditional MS approach of generating code which the user then edits; this approach is quite simply insane, IMO 😉
    The more appropriate approach is what Gnome’s GLADE (iirc) and (prior to that) Marimba’s “Bongo” GUI-builder did — generate an XML file which is interpreted at runtime, which just has to list the names of functions or object/method combos it calls back to. That way, you (a) get less risk of the IDE scribbling on your hand-crafted code; (b) get less risk of you accidentally screwing up something in the IDE-generated code; (c) achieve a cleaner separation between the two.
    The app that generates the XML file is a simple UI builder, not a fully-fledged IDE, since it doesn’t need to know about how to highlight code, indent, parse C/C++/Perl/Python/Java/.Net/whatever — it just needs to know how to allow dragging and dropping of GUI elements around a window, and how to load/save that from/to XML.
    BTW I hear MS are planning to have such an runtime-parsed XML-driven GUI engine for Longhorn, which is nice.
    Aside^2: Marimba’s Bongo was a fantastic tool, which they then shelved to concentrate on their “push technology” product. It was way ahead of its time. While “push” came and went, the Java community (and Sun) came up with Swing — a truly grotesque lump of over-engineering that still doesn’t come with a GUI builder tool.
    In the meantime, I don’t think it’s even possible to get hold of Bongo anymore, which screwed me over (for one) since I had written a couple of commercial apps using it as the GUI layer. Chalk another one up for the foolishness of relying on non-free software…