I wrote a car management (for vehicle hire) system in COBOL on a VAX mini. It was probably one of the most enjoyable computer programs I ever wrote.
I was quite young at the time 'tho. There was none of the complexitity one finds in so-called modern development. Just me, a term and a keyboard (and a manual!).
It's one of the reasons I like working with Clojure, it reminds me of that experience.
@dharrigan im with you. Although in my case it was turbo pascal on a 286. And later web applications (we just got forms support in html) with CGIs implemented in perl. Perl4 is still the closest for me when it comes to matching clojure's experience. Maybe because it also was data driven and not oo
And the perl ecosystem was similarly rich. On one hand fundamental strong data libraries with lenses, advanced data structures etc. on the other hand no worries when you needed to translate ebsdic encoded string and call some AS400 interface.
A little bit like strong clojure libs and the huge number of java lib available.
I'm curious about how a Clojure solution to that tweets example would look like, @simongray high level. I also wonder if it could be something one could apply to parsing of Clojure text as it is being entered in the editor...
I find modern development quite mentally burdensome (here's looking at you javascript and web development!). Similarily, whilst I used to find Spring liberating, it's gone up it's own ass and become a complex set of frameworks itself.
with Clojure, it's just data manipulation with transforming functions (and a few side effects) thrown in
I'm probably over simplifying it a bit, however, that's what it feels like to me ๐
@dharrigan the problem with modern web development as I see it is that everything is way more complicated. The features in the browsers, security and even scalability. I wonder if we end up at something like the concept of an "operating system" once was to easy the access to the ever growing features of "hardware" back in the days.
There's mostly nothing in computer science that can't be solved by yet another layer of abstraction ๐
So true. ๐ ๐ ๐
except for performance problems, usually
Morning
although one could argue that by abstracting assembly in a higher level language and more clever compilers, things actually got faster than with hand-written assembly, so it's not always the case that more indirections result in less performance
Morning!
True.. but that also created an โinduced demandโ effect where, given the ability to work at a higher level and still get performant code, people immediately used that bandwidth to set about building n layers of additional abstraction on top of that. There have been articles floating around for the past few years on how user interface latency (time between keypress and onscreen visual change) has actually gone down since the early 80s, as more cruft is layered in.