> In his mind, (and I think in yours as well) computer languages are more > like mathematical notation than a form of technology. And as such, > evolution is slower - not at the pace of the changes in the underlying > technology.
However I'm sometimes in the mood to not draw this line between notation and technology, looking at language as technology, as tools. And yes, different technologies evolve at different rates. Bucky kept saying the lead time from prototype to mainstream was a key variable, and in electronics might be about 3 years, whereas in housing it might be at least 10 if not more. So he figured housing prototypes in the 1940s might pan out in the 1960s, and to some extent they did (and didn't). Plus he kept making prototypes, as did his students (J. Baldwin and Joe Clinton come to mind). > > Though certainly not uninfluenced by those developments. The most > important technological development he seems to point to is the > increasing raw power and speed of processors, which allow languages > to design away from a preoccupation with performance issues. However it's also important that, given this opportunity for faster physical cycling, per the silicon chip computer, software engineers were able to rise to the occasion and give us VHLLs like Python, i.e. were able to take advantage of those extra fast cycles and yet still make the language parsable and machine friendly enough for a CPU (which is ultimately nothing more than a fast arithmetical/logical unit, no matter how fast it goes). > He thinks - though without great confidence in his intuition here - that > Java is an example of a language headed down a dead-end evolutionary path. > Than so must too be C#. > A language has a half life. Big expensive systems that aren't broken don't need to be replaced, only tinkered with, so you have this long aftermarket for language skills, even when the language itself is "officially" dead. FORTRAN is a good example. At the OSCON/Stonehenge party this year, Jeff Zucker (a Perl saint) and I met up with a FORTRAN guy who to this day works on optimizing FORTRAN compilers, to run more effectively against today's chips. Because lots of big fancy computer models still perform useful service and make heavy use of FORTRAN. > Despite having some understanding that it must be annoying to hear > high-fallutin theory from someone at my level in this domain, I persist. > > And it seems to me that the evolutionary successful language will include > in its approach clear and concise constraints on its ambitions. > So far you haven't said anything I disagree with. Just adding emphasis: software had to meet the integrated chip designers at least half way, and computer languages aim for a layer in a long term archeology that could include working bits for centuries, if not millennia -- just as centuries old math notation still expresses algorithms in useful form today (your original point). > If I am understanding "properties" mostly correctly, and in fact their > reason for being is to allow for a fundamental midstream redesign of a > program without alteration of that program's API, I am thinking something > to the effect that it is only possible to do the impossible in half- > measures, and half-measures are only half-measures and who wants to work > in an environment of half-measures. In Java, you should probably work out ahead of time if you want to use private variables cloaked in protective getters/setters, so that you might continue fiddling with the guts indefinitely, even as your users experience and enjoy a simple attributes-based API that hardly ever changes (like the front panel on a TV: channel and volume, yet no tubes inside (not even a picture tube these days)). In Python, you have more liberty to wrap what used to be a simple attribute in a property, and so maybe don't have to hard code so many design decisions up front. Java coders may be more likely to practice "defensive programming" than Python coders and make everything private and method-protected up front. This philosophy is manifest throughout the language (with its private, protected, and public attributes -- whereas in C++ you also have friends [1]). Some say Python is a "consenting adults" language, with permissions by convention vs. enforced by a nanny compiler (I'm not saying the latter can't be a nice experience also). > I don't think mathematical notation, for example, includes the concept of > the half-measure. > > Whatever. > > Art For me, non-executing math notation needn't be enshrined as the ideal. So much about math involves insulating one's self from having to deal with real world complexity (only to discover it later, one hopes in some manageable form). Computer languages ventured off into the wild west and took on whatever features we needed to do real time accommodation of client wishes. So I'm not nostalgic for the good old days, before we had computer science. I don't pine for a "math rules" world, wherein more machine oriented languages are second class and pitiable. There's nothing pitiable about a Perl, Ruby or Python. They're just tools that do what they're supposed to. They're not here to whine about not being mere "math notations" as if that would be an improvement. Kirby [1] http://www.faqts.com/knowledge_base/view.phtml/aid/24762/fid/163 _______________________________________________ Edu-sig mailing list Edu-sig@python.org http://mail.python.org/mailman/listinfo/edu-sig
