I guess.
Though I can't say I find there to be much consensus out there about what language features truly make for robust software development from group or community efforts.
There's a long history of coders seeking consensus, but not arriving at any set in stone answers (no carved tablets at the Smithsonian), in part because the backdrop is always shifting, in terms of languages and technologies.
Interesting to read Paul Graham's article "The Hundred-Year Language" which - as noted in the article heading - was derived from his keynote at PyCon 2003. http://www.paulgraham.com/hundred.html """ Languages evolve slowly because they're not really technologies. Languages are notation. """ 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. 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. 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#. 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. 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. I don't think mathematical notation, for example, includes the concept of the half-measure. Whatever. Art
Arthur wrote:
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.
I don't think mathematical notation, for example, includes the concept of the half-measure.
OK, how about this explanation. If I am providing software support to a group of scientists running experiments, I can give them an API and the fastest-to-write code that passes tests. Once I've done that, they can get to work using the software while I go about the work of making the software more reasonably designed and responding to efficiency problems that they actually encounter. We use the API as a "treaty point" -- they stick to using it, and I stick to providing it. This structure can also be used to provide the "for free work-alike" and the "pricey efficient" versions. Properties allows me to determine later (perhaps after watching how they actually use the API) whether I should precalculate the triangle angles, recalculate them each time, or find an even fancier version where I compute them each the first time on demand and re-use those results, invalidating the angles whenever a side is changed. If I have to make those design decisions up front, I have to assume a pattern of use. If I wait until I have actual users, I can get real statistics on how the use the API. We decouple our work this way. --Scott David Daniels Scott.Daniels@Acm.Org
----- Original Message ----- From: Scott David Daniels <Scott.Daniels@acm.org>
If I wait until I have actual users, I can get real statistics on how the use the API. We decouple our work this way.
But in my look of it, properties are a "solution" to one of a nearly infinite set of these kinds of possibilites. And in that sense a half-measure. Certainly many areas will remain where our API and our design are irretrievably coupled. All I can try to do is offer the perspective of of a mid-brow developer, who tries. Again, in the case of the development of PyGeo - and willing to refactor until the cows come home - the solutions to problems seemed to be mostly a process of discovery. When I found a better way to do something than I had before, I knew it was better and I knew why it was better. And Python as a languagfe and as as disclipline seemed more than cooperative as a partner, and guide in the process. "Properties" being a rare distraction. Art
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
participants (4)
-
ajsiegelīŧ optonline.net -
Arthur
-
Kirby Urner -
Scott David Daniels