![]() Later still I would take the leap to THINK C.īut I will always look back on Turbo Pascal and remember it with fondness. Later I would learn of and move on to THINK Pascal - a much more Mac-centric IDE. My first few apps were Turbo Pascal implementations of algorithms from the Computer Recreations column of Scientific American (thankfully requiring little UI - a window and a few buttons typically). No ResEdit, but the odd R-Maker app that expected you to create a Macintosh resource as a text file and then run it through the tool to create the resource fork. It had the manual, thankfully, but very simply tools for Macintosh development. By chance there was a classified ad in the college newspaper for a copy of Turbo Pascal for the Mac - some professor was selling it for like $40 or something. In college I used a student loan to buy my first Apple computer, the Macintosh Plus. (I have come to find Turbo Pascal was more of a PC thing.) Weirdly, Turbo Pascal was my first high-level programming language and it was on my Macintosh Plus. It was a really cool setup, at least through Delphi 7 or so. It's a shame Borland left the grassroots devs behind in their quest for the enterprise market, and more or less killed any growth in community adoption. I had so much fun playing with both VCL and the IDE itself. But at the time the idea of a component library and coding environment that was easily extensible in its own language was pure magic. Nowadays it's normal to have IDE plugins to the point it's a dealbreaker if they don't exist. ![]() That, in turn, led to a job at Borland testing the Kylix and C++Builder IDEs. When I went to college for CS in the early 90s, they were still teaching the first year of classes in Borland Pascal so that turned out to be very useful experience.Ī few years later, my Pascal background sailed me into a half-decade stint as a custom app dev working with Delphi. Turbo Pascal was the first "real" programming language I learned past 6809E ASM, structured basic flavors and batch/shell back in the very late 80s. And even if the developers care, then the companies that employ them don't mind saving money that way. A lot of developer convenience comes at the cost of the end-user, imo. What I find a more compelling argument for the majority of this increase in software size and CPU usages is that letting the software bloat and slow down the level that the customers tolerate is a form of externalizing costs for developers. It is really, really easy to underestimate just how much faster and bigger computers have gotten in the last thirty years. I do think that there is truth to that, but to be honest I think that in an ideal world that would account for some these orders of magnitude, but leave out the majority of them. What you're arguing seems to be "you think you just wanted a banana, but it turns out the customers needed various banana sizes, levels of ripeness, even special alternative hypoallergenic banana breeds, so instead you get a gorilla to fetch you the right banana from the jungle for each situation." ![]() Still, it feels like it could be generalized to software bloat, rigth? That's a very catchy metaphor, although he was talking about C++ style OOP with bloated classes. Joel Armstrong once said "You wanted a banana but what you got was a gorilla holding the banana and the entire jungle.".
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |