A link that attempts to differentiate NT from Aspie programming styles:
http://www.rdos.net/eng/it.htm

Not to say that all NT programmers are like this (good programmers aren't), but it is interesting. I know that I relate to this very well. It sickens me to see 5,000 line programming modules using only global variables (especially when the language is LISP!).

Here's an analogy:

When I write a program, it is like I am building a machine. There are various fundamental components, such as nuts, bolts, cylinders, etc. It can be taken apart and be modified.

When most of the people I work with do programming, it's more like pouring plastic into a mold. It works well, but you're stuck with it.

Well it used to be that you used a global variable if you used it in many functions. This was mainly because it rediuced the amout of code, and you save a few clock cycles by not passing anything to a functions and just using golbals. A long time ago when you wrote MSDOS programs in C, it was a common tactic to use all global variables in an attempt to get a little extra performance out of the program. It worked, but nobody bothers with that anymore...

Tight code, VS a functional style is a matter of style , really. I used to write very tight code and sometimes still do, but a functional approach is much nicer because it gives you a clean structured set of building blocks to use to make a big program work in a sane fashion.

If you are someone like me who learned to code in the 70's you learned to write very tight code to save on memory and cpu cycles.. You packed a lot of functionality into a very small amount of code... it was also hard to modify and maintain because any change in tight code will often break it badly and you end up with a total rewrite to mod the code even a little. Today machines are so fast nobody cares about a few clock cycles so a looser, more functional approach makes more sense.

ME :D


A link that attempts to differentiate NT from Aspie programming styles:
http://www.rdos.net/eng/it.htm

Not to say that all NT programmers are like this (good programmers aren't), but it is interesting. I know that I relate to this very well. It sickens me to see 5,000 line programming modules using only global variables (especially when the language is LISP!).

Here's an analogy:

When I write a program, it is like I am building a machine. There are various fundamental components, such as nuts, bolts, cylinders, etc. It can be taken apart and be modified.

When most of the people I work with do programming, it's more like pouring plastic into a mold. It works well, but you're stuck with it.

Yes, I can definately see that, especially for many function calls. In assembly language programs, what you describe is typical (along with passing variables over registers as opposed to the stack). But the key here was for speed. There was a good reason for doing such.

I see this type of programming in modern systems, in languages like LISP and Visual Basic, where speed is of little concern. Maybe the programmers are older?

Well it used to be that you used a global variable if you used it in many functions.


Well, I think this is still common. I do it myself. Its quite normal to see a few global variables in a program. There are programs with all variables being global (no passing between functions) that I've seen (in LISP!)

Yah they might be older. I still tend to want to tighten up my code and have to make myself not use globals sometimes...I still worry about cpu cycles and memory use. Old ways can be hard to unlearn. I also cringe when i see a 2000 line program that I know could be done in 500 lines.

I think a lot of programmers are not taught style, and they are not taught reasons for using a particular style. Conserving memory and cpu time are still important, but most programmers don't know how to do that and are not taught much about it.

When I was in college we were pretty much left to our own as far as style was concerned. All the prof worried about was did the program meet specs, etc...so there was a big variance in the waqys peole arriverd at solutions... Of course this take us back to aspie programming style vs linear thinker's programming style.... etc.

It would be interesting to know if there was a difference. I somehow suspect that there is a big variation in programming style among aspies.... I don't know how I would prove it.

ME :D



Yes, I can definately see that, especially for many function calls. In assembly language programs, what you describe is typical (along with passing variables over registers as opposed to the stack). But the key here was for speed. There was a good reason for doing such.

I see this type of programming in modern systems, in languages like LISP and Visual Basic, where speed is of little concern. Maybe the programmers are older?



Well, I think this is still common. I do it myself. Its quite normal to see a few global variables in a program. There are programs with all variables being global (no passing between functions) that I've seen (in LISP!)

It took me a while to wrap my head around object-oriented programming, but it seems natural now. It took me even longer to "get" Prolog's recursion-oriented programming. :) I really only "got" it after learning some higher logic.

About "tight" code: I really can't see any use for that kind of programming style today.


Modern compilers remove a lot of the overhead anyway, by automatic inlining, omitting frame pointers, etc.
Programmers cost too much to pay the extra time in development/maintenance of this kind of code
For most of any program, those extra clock ticks aren't going to matter. The best way is to write good code, profile your program, and "tighten up" the parts that need tightening. Four hours spent shaving 5 msecs off a function that is called once a session would be better spent implementing some new functionality.
Therefore, the role of the programmer should (IMHO) be to write good algorithms, and leave the low-level stuff to the compiler. In places where performance is an issue, try tightening things up, but profile to make sure you are doing what you think you are doing. You might even need to rewrite some places in assembler.