java. ruby. python. c#. dylan. bah.
that last word isn't a language, but rather the expression of my disatisfaction with the language fetishists of the world who go on constantly about how cool their languages are. or how about "common language runtimes". oooh, aaaah!
i've worked with a number of languages in my career and it's true that there are some really great powerful languages (e.g. c++) and some really fun and consistent ones that make development quick (e.g. ruby) and ones that just suck (e.g. lisp or fortran).
(how long until i get my first "but lisp is amazing, you insensitive clod!" email? to be honest, even if i overlook the obsessive use of parenthesees, i just have a hard time thinking functionally the way lisp wants me to. it's doable, just odd.)
but it isn't the language at hand that has always been the biggest hurdle for me, it's been the way we still write code. it really hasn't changed much in the last, what, four decades? we open up text files in text editors and pound away at the keyboard. we've given writers tools like word processors, typesetting apps and even screnwriting programs that have freed them from pounding on typewriters, but have yet to really free ourselves from the prison we have invented for ourselves. and most of us are hardly aware of it, i think.
we happily continue to create header and implementation files, or come up with different ways of splitting up classes into manageable sizes (gotta love those 15k line files!). and let's not even get started on directory layouts.
but we must realize this sucks, because we've invested innordinate amounts of time building text editors that do funky syntax highlighting, block collapsing, bookmarking and more and then throw those inside complex environments which manage projects and pull apart the code symantically to give us code completion and the ability to jump around semantically such as by class.
and when we want to re-use code? or refactor large bodies of it? well, we search through the text files! so we've built source code search engines and tools to autogenerate api documentation and on and on and on ...
and what about revisioning and unit testing? yep. yet more external tools.
at what point do we step back and go: "wtf?! we keep making flat files, but we don't really want flat files. instead we keep trying to make them into relational databases and semantic webs because that's actually how we work." apparently we haven't reached that point.
now, before get the wrong idea: i'm not leading up to saying we should program visually. that's a load of crap suitable for only the most encapsulatable and simple of tasks. textual programming is fine. how we store and manage that text isn't.
so all you language fetishists and ide developers .... how about concentrating on the thing that really makes programming suck? build an environment that puts all the pieces of the code as i type it into a semantic web and shove it all into an indexed database somewhere.
revisioning, unit testing, build conformance, api documentation, code cross referencing (and thereby code completion), design recovery, searching, re-use and refactoring ... all of this would be so much easier, faster (as in fewer cpu cycles and fewer tools to set up and master) and natural if the data was stored the way we use it.
i have a dream, and in this dream there are no more flat files sitting on my hard disk full of code as if it were 1970 all over again. in this dream my unit tests are run when i commit code which happens when i save the file and mark it as "final" in my editor without me having to set up one darn thing. and in this dream it doesn't take a server to provide the horsepower needed for indexing and api documentation flows as a natural course of creating the code. and in this dream when i make a change to trunk/ porting it back to 3.4 and then porting it forward to 4.0 isn't a pain in the ass that takes up a bunch of my coding time.