Can you draw such a clear line? I put out some thing to experiment with an idea and then iterate over it till i get a solution and then spend time trying to polish that for production use. Thinking and coding are very rarely two separate states for me.
It's not that clear and still involves coding. But as I start coding and modules/APIs/classes take shape, it gets to a point where I say "ok, from here on it's just filling in the blanks".
But filling in the blanks can still involve a lot of grindy, time consuming work where you iterate through collections, build parameters for other APIs, check invariants etc. All of that stuff is boring to me.
What I'm trying to say is that most coding tasks require "senior level thinking" and "intern level thinking". The latter can sometimes be the majority of the work and I don't want to do that anymore.
We used to give presentations about the average life of pages on the internet before it 404ed. It was cited from a SciAm article which was offline at the time and the only way to get the stat was via. the mirror on the Wayback Machine.
I'm in the middle. I've been using Python since the early 2.x series.
The good parts are that the inbuilt data structures and their apis are efficient and clean enough to write code that's mostly readable. Most of the heavy lifting is done in hand tuned C and performance intensive external modules are also written in C. There are several good projects that are written using it and while it's not theoretically perfect, it's useful enough. Like Stroustrup said - there are 2 kinds of the languages, ones that everyone complains about and ones that no one uses.
The bad parts are that it's very easy to use. Almost in a Visual Basic "producing crap just takes a squeeze" kind of way. It opened up programming to a lot of people (the genesis of Python was in the CP4E project - where this was the aim). This resulted in a lot of bad patterns, inefficient code, badly written but popular libraries. Also, the indentation idiom and other restrictions resulted in a lot of convoluted APIs.There's also a lot of baggage from the pre multi-core CPU era (threading etc.).
I still think of it as a great glue language. If there are libraries that are fast and can run well, a good FFI or wrapper which Python can leverage will amplify the reach and usability of the library.
On the overall, a language that's older than the venerable Java which people are still using (and hence complaining about) speaks to its longevity. So, atleast by that definition, it is successful.
It's a beautiful house and I'm very happy for them.
My own memories of lan parties were much messier. People bringing their own assembled machines and running cables around the place to get this to work somehow, swapping cards etc.
The barrier and time between idea and usable implementation is almost zero now. I don't have to imagine. I can just write something and see it work before making larger decisions. I really like this. Many of my ideas were abandoned because I needed to study some obscure library. Now, I can learn the parts that I find interesting and just have the AI chew through the grunt parts easily. That's the good.
I started coding with a line editor on a small Casio handheld "computer" and used to keep programs in my head. I more or less knew what happened on each line without seeing the line. With larger programs, I had a mental model of what was going on where and a big part of the input to that was the effort of writing everything by hand. That's gone. It's not really important as far as the output of usable programs is concerned but there's a certain feeling of satisfaction that came with digesting a larger codebase and having it surrender it's secrets to you that's missing.
I think the first instance of games being separated from the "engine" so that you could make the game and it would run on all platforms that the engine ran out without porting was Infocom's Z-machine. http://maher.filfre.net/if-book/if-4.htm
There was an interesting article which I read a long time. It's linked to from the post above called "How to Fit a Large Program into a Small Machine" published in 1980.
AGI, SCI, Scumm etc. were all larger and more capable versions of this.
Z-Machine is also useful to point out because it's one of the clearest lines to draw from it to the modern JVM and .NET CLR. Whereas AGI/SCI/SCUMM all have very game specific virtual machines, Infocom's was Lisp influenced and even built it with business/enterprise apps in mind, though Infocom's one attempt at doing exactly that with their database app Cornerstone was a market flop. (It's heavily enhanced fork of the Z-Machine was also only released for a fraction of the machines the game Z-Machine supported.)
I still think it's an interesting question if Infocom had not tried to keep the Z-Machine proprietary "secret sauce" if it would have been a larger platform of general computing for much longer and broader than Infocom's own lifespan and primarily games focus. If Infocom had taken a Sun-like stance on the Z-Machine being a JVM ahead of its time and building a broader compatibility ecosystem "write once, run everywhere" might have been an earlier part of computing.
I remember an old company called "Access software" that had something called "Realsound" with which they played really high quality audio on the PC speaker. Their games were things like Countdown, Martian Memorandum etc.
Yes but going really far down that path has given us sterilized UIs that have no character and no personality. Every website and app looks more or less the same. I, for one, enjoy a thriving baroque culture of weird interfaces with different levels of usability. Given the nature of the people who write these (usually for themselves or their teams), I'm sure usability was important and good atleast for their own audiences.
reply