LaserFiche wrote an article on How You First Programming Language Warps Your Brain. An interesting read that got me thinking and wondering where my biases for both strongly typed languages and my overall architectural views come from.
Technically, my first language was the numeric keyboard encoding on the HP25C, capable of 49 instruction memory. I learned a lot about code optimization. 
I then moved up to the HP67, which I think offered 200 instruction memory, then the HP41C. One thing that stood out for me as a kid with regards to the HP products was the documentation – high quality, the programs that came with calculators were explained in concise and clear language. That became a guiding influence in my programming / documentation style.
Somewhere in the middle I was doing BASIC programming on a teletype on a PDP-11, where I finally wrapped my head around the idea that when you tell the computer a = 5 and later say print a+1, there’s some memory somewhere that contains 5, a reference somewhere that a refers to that memory cell. That actually took a while.
When I progressed to the Commodore PET, the world opened up to hardware, registers, and 6502 assembly language. Not to mention early concepts of a BIOS. Again, the quality of documentation, but this time for the hardware, was very influential.
Doing a lot of assembly programming kept teaching me skills like code optimization, DRY principles way before the acronym was invented, good documentation and variable / entry point naming skills, and most certainly, good debugging skills.
I also got introduced to parallel processing in a Pascal-like language called SAIL, which was sort of a mind-bender because line numbers and goto / jmp (in assembly) disappeared. I really had no concept of a stack yet at that point, and when, in a summer class I took at Stanford by a guy that would pick his zit scabs and eat them (I kid you not, it was 
and his classes were being video-taped!) I simply could not wrap my head around recursion, stack-based variables, and ended up spending my time in front of the computer playing Star Trek instead of writing the quicksort algorithm that was our homework. Heck, I didn’t even know what question I should be asking, my programming brain was so oriented around linear-sequence programming. I’m not sure I finally grokked the concept of a stack vs. a heap until years later.
My introduction to C was one of “run away”. All those ridiculous symbols and weird behaviors, like i++ vs. ++i. Really? Who invented this horribly confusing language to write and read? Pascal was my buddy by then, courtesy of Borland’s $99 Turbo Pascal.
So I basically skipped C, but really like C++. It made sense — classes, encapsulation, polymorphism. But I got “base class” wrong. It’s a BASE class right? So like the base of a pyramid, it’s at the bottom of the derivation hierarchy, right??? I wrote a whole app that way. Templates were amazing, they also made so much sense.
In many ways, C++ very much refined my ideas of separating code into isolated blocks of code. Still, I found that there was too much inter-dependency between classes. Re-use was a myth, not a reality. Tight coupling of code made the code monolithic. It was only by careful planning and using higher level architectures, like a publisher-subscriber pattern, that I began to disentangle the monolithic nature of applications. This also lead me down the path of loading DLL’s dynamically at runtime and separating out declarative aspects of the code from imperative ones. XML didn’t really exist, so I wrote my own XAML-like syntax for rendering UI’s with MFC.
Other things became apparent too – the tight coupling of the data access layer (and embedded SQL statements) that were rampant at that time. Again, a custom scripting language to separate out the SQL statements from the application had a direct impact on how quickly code could be changed to deal with changing / new requirements. Everyone’s jaw would drop when I could run a C++ app, change some declarative markup and SQL, and have new functionality, without compiling a line of code (heck, without even exiting the application.) I had one coworker tell me “I don’t think I can ever go back to the way everyone else does programming!” Another coworker refused to use my framework on the grounds of “What? Am I supposed to put on my resume that I used Marc Clifton’s framework?” An educational moment for me, that I was starting to walk down a lonely path. Then again, looking back, yes, he could certainly have put that on his resume!
About that time, the Design Patterns book hit the streets and everyone was yammering about DP’s, and I thought, wow, this is so old hat!
Also about that time I read Vital Dust[^] which changed how I thought about programming forever. It’s quite fascinating that a book about the roots of life changed my thinking about programming – something no programming book had (and has) ever done. Around that time, I discovered Code Project (was using a 64K ISDN modem at the time) and so, on May 26 2002, I took my ideas from Vital Dust and the experiences I had gained and wrote my first article, Organic Programming Environment[^]. (Years later, the concept was revisited again with HOPE[^] originally posted exactly (-1 day) 12 years later!)
And then C# appeared. The rest was history. C# has so greatly influenced my programming and thinking style that I cringe whenever I have to use another language (which usually consists nowadays of Python and Javascript.) And it continues to do so, with functional aspects, LINQ, etc.
And certainly, my history of compiled, strong typed languages has bent my thinking, such that script, duck-typed languages are, to be frank, something a joke (and a bad one at that) in my opinion.
So I continue on the path of further refining the ideas of decoupling code and creating modular data-driven rather than imperative workflow-driven applications, and where concepts like dependency injection are, in my opinion, totally the wrong direction to go, (I can’t believe people still use DI), and to the ire of the people that look at my code and the supporting framework, who don’t get it and never will get it.
Over the last 30 years, my exposure to a certain path of languages and a certain path of problems has led me to a particularly lonely corner of the programming universe! But thank God for Code Project, where you can at least peek under the bed to see what monsters lurk in the bedroom of my programming mind.
The downside to this particular path is that I pretty much march the beat of my own drum. Sure, I use frameworks like .NET, EF, DevExpress, jQuery, Bootstrap, Knockout, Backbone, etc., but I rarely use them in their native form — they always get wrapped in what could loosely be called an “automation layer” but is actually my way of decoupling dependencies, optimizing re-use, and always working on trying to make my work repeatable and robust.
Marc Clifton 