-------- Original Message -------- Subject: Re: [fonc] Software and Motivation Date: Sat, 19 Feb 2011 04:01:22 -0700 From: BGB <cr88...@gmail.com> To: Fundamentals of New Computing <fonc@vpri.org> CC: David Harris <dphar...@telus.net> On 2/19/2011 1:06 AM, David Harris wrote:
Here is a very interesting 'cartoon' of what, in general, motivates people - certainly applicable to what you are talking about. http://www.youtube.com/watch?v=u6XAPnuFjJc David
yep, interesting... I have before noted that, personally, it is difficult to really care that much about money... money is there, something for some people to idolize, and something for others to screw over each other to try to get more of, ... but, personally, my efforts were not motivated as much by this... after all, I work mostly with compiler, VM, and some language-design stuff, and it is unlikely there is a whole lot of money to be made here... and, yes, a lot of it is fairly dull and boring as well... although it may seem like it, my goal isn't really to spend away all my time implementing "yet another generic language exactly like all those that came before". or even "spend all my time implementing yet new bytecode interpreters and JITs and performance-tuning the things...". rather, it is more that, doing all of this allows one to try their hand at chipping away at long-standing problems, in ways that simply using a VM or bug-fixing/maintaining the thing would not (as then, one has to swallow the existing architecture full-force, and there is no real room for experimentation...). one knows the architecture, one knows all its merits and flaws, but at the same time something is missing... so, it may well be a more satisfying experience to try ones' hand at making things, even if very possibly in the end it may well all just amount to nothing. granted, I don't really buy as much into the cult of novelty or originality either, as the existing forms and traditions make a good starting point, and are, in many ways, powerful tools worth leveraging. often, what real merit is there in "purity" and "paradigm"? wouldn't it be better to just do something a little more familiar and friendly, even if in some cases it would seem to involve slavish adherence to technically pointless traditions and minutia?... this is really the cost one pays, but it is at the deeper levels where one is more free to try out some of the possibilities. but, at which point one is ruled by their tools, rather than the other way around, something has gone wrong. it is like the folly of traditional VM/"Platform" architecture: they don't so much aid the user to do new and interesting things, so much as they tend to enslave the developer into whatever set of tools and development mindsets and application domains as were deemed important to the original developers. one is far better IMO just writing apps in C, as even if they get some of the ire and disdain from the Java and C# people, one is far more free when writing in C. but, it doesn't need to be this way, as there are still some interesting things worth observing and learning from these architectures, and maybe one may even go as far as to try their hand at improving on them... so, yeah, I am implementing a new VM and language... yes, the language sort of resembles a mix of Java, AS3, C#, and a few others, but the design motivations and underlying architecture differ notably, and this may well effect things more notably than the syntax. so, the syntax is a starting point: it defines a sort of baseline for what the language is expected to be able to do; but, syntax alone is not a limit on what a language can do (a syntax can do far more than the set of functionality usually exported for a language, although sadly many have also fallen into a sort of "cult of syntax sugar", where syntax sugar is far more prominent than actually addressing core deficiencies). in fact, a language with a "novel" syntax may well hide most of its deficiencies: there is less expectation for what things are possible (or "should be"), and so many piles of "trivial limitations" will pile up, and then the problems will be hidden under the carpet. but, with a more traditional syntax, many such issues are a little more obvious, as then people will note "I can do task X in language Y", and missing a basic capability will often stand out somewhat notably. granted, one is more open to criticism this way, as then, to claim to be better than something, it will in-fact have to be better, and an unsubstantiated claim will tend to be more readily apparent. but, OTOH, is this really a bad thing?... it may well force the creation of a better product overall, and people don't necessarily lose out. a product with novelty and a lot of overt features may seem to be less deficient than something else, but even if one can hide these things from being seen, they will still be "felt" by those who use the system, as the matter of "why is there no good way to do X or Y" may sit in the back of one's mind (or why seemingly simple tasks should need such ugly and complex workarounds...). and, no, hype and promoting warm fuzzy feelings about the product is not the solution, as eventually people will still be left cold. not that a language can or even should try to provide for every possible use-case, as this is itself going in the wrong direction. a well-designed system shouldn't even really need to worry about use-cases at all, as nearly any task should be able to be represented and performed reasonably adequately (regardless of whether the "architects" thought about it or not). granted, it is a problem how much "good design" is such an elusive thing. eventually, some level of trial and error is needed to separate out what works and what does not (as one has to find out what works well, and allow bad ideas to be put to rest). one doesn't spot good designs by how great or impressive they seem at the time, but rather that they often "just work" and tend to have a high degree of "staying power". they are not so often "the next big thing", but rather, "the thing one can't put away"... or such...
_______________________________________________ fonc mailing list fonc@vpri.org http://vpri.org/mailman/listinfo/fonc
