This video is fantastic! I'm going to take this with me to work:) On Feb 19, 2011, at 10:39 AM, BGB <[email protected]> wrote:
> > > -------- Original Message -------- > Subject: Re: [fonc] Software and Motivation > Date: Sat, 19 Feb 2011 04:01:22 -0700 > From: BGB <[email protected]> > To: Fundamentals of New Computing <[email protected]> > CC: David Harris <[email protected]> > > 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 > [email protected] > http://vpri.org/mailman/listinfo/fonc
_______________________________________________ fonc mailing list [email protected] http://vpri.org/mailman/listinfo/fonc
