well it's not uncommon for late adopters to leap frog technologies. for example, in china, land (telephone) lines are more expensive than plopping down a basestation and giving everyone in town a cellphone.
there are similar economics w/ PCs vs PDAs. the functionality of a PC is hindered by its distribution channel (box tied to the wall, w/ many moving parts, etc etc). it's very attractive to get the same kind of functionality in a different package.
educate the users! show them that "customization" is a degenerate (in the mathematical sense) form of programming. make them into programmers. join us!
although the dichotomy is false, it is not completely false. it's true that there will always be conflict, both internally and between members of a group. resolution will never be towards any extreme, but in compromise at very basic levels. protocols that allow asynchronous communication foster social buffering as well. some people bemoan the atomization of society; perhaps they have not yet learned to control the buffering.
in the US, one is oppressed by advertising, glop franchises, suburban sprawl, repressed ethnic mistrust, cultural blandness, forfeited privacy, and so on. thus, the US is considered advanced. but maybe this is like "advanced disease".
ummm, every "new" feature brought up has been included in some LISP or another for the last 30 years. and as for application domain: AI, game theory, etc -- where do you think that stuff came from? rather ironic that the author completely dismisses functional languages.
as for practical aspects, game development requires performance, and now that you can compile LISP (and other languages), the only excuse for not using LISP is willful ignorance.
an interesting thing to note is that circuits are exactly like functions, and many EDA tools are written using some LISP dialect. the future of programming involves conflating hardware and software design into "design", and realizing an implementation on the fly (what's the difference between a scripting language and reconfigurable hardware?).
in conclusion, i think the author misses the point entirely.
well, one way to look at it is that people should have the freedom to make their own mistakes. if they make a mistake and don't understand why they made that mistake, perhaps they are not ready to learn after all.
those points are actually called "quality-control". quality assurance has more to do w/ the process than the product (in this case the process of accepting patches and incoporating them into the source tree).
no worries, most people get this wrong. industry is like that.
heh, the organizers slam `make' and then require python? does anyone else see the irony of this?
a good chunk of the FAQ is spent defending this decision, w/ the crux of the answer being along the lines of "we feel python is the best compromise...". too bad, one would think the most viable approach is to educate new developers rather than dumbing down the tools.
does anyone else find the teenager analogy disturbing? perl5.003 binary incompatible w/ perl5.005, kind of like "oh that group is so rad" today and "so yesterday" tomorrow. (s/rad/your-groovy-terminology/g you punks.)
i had the opportunity to maintain perl code at cobalt. whether it was the startup (hectic) environment or the startup (harried) people, the result was some pretty funky looking software artifacts. i think the image of "teenager puking on a mural" described it. hopefully things have changed since then.
you are poorer for espousing the reading of anything (including vapid maniJESTos) to further education. you are richer for caring. pity for most folks the roll of the dice makes the opposite true.
Slashdot Mirror
sometimes, though, it is nice to disconnect. if your trip is a vacation of sorts, you may wish to consider that alternative.
--thi
wasn't one of the old PDP's asynchronous?
text rules, no doubt about it. nuff said.
--thi
there are similar economics w/ PCs vs PDAs. the functionality of a PC is hindered by its distribution channel (box tied to the wall, w/ many moving parts, etc etc). it's very attractive to get the same kind of functionality in a different package.
--thi
--thi
--thi
--thi
--thi
as for practical aspects, game development requires performance, and now that you can compile LISP (and other languages), the only excuse for not using LISP is willful ignorance.
an interesting thing to note is that circuits are exactly like functions, and many EDA tools are written using some LISP dialect. the future of programming involves conflating hardware and software design into "design", and realizing an implementation on the fly (what's the difference between a scripting language and reconfigurable hardware?).
in conclusion, i think the author misses the point entirely.
--thi
--thi
--thi
no worries, most people get this wrong. industry is like that.
a good chunk of the FAQ is spent defending this decision, w/ the crux of the answer being along the lines of "we feel python is the best compromise...". too bad, one would think the most viable approach is to educate new developers rather than dumbing down the tools.
--thi
--thi
--thi
dreams are hollow, but the pursuit of dreams may take many paths, and is indeed Your Life.
bill gates being chief software architect is like all the disasters happening at once. one pities the usloth-blinded users.
oh wait, someone named rms already did that w/ that five-letter program...
i rather hope you aren't implying my alma mater should be a diploma mill. certainly Phaedrus would not approve.
i had the opportunity to maintain perl code at cobalt. whether it was the startup (hectic) environment or the startup (harried) people, the result was some pretty funky looking software artifacts. i think the image of "teenager puking on a mural" described it. hopefully things have changed since then.
--thi, (just another perl lacker)
i see your initials are the name of a popular brand of whiskey.... beware the lawyers!
you are poorer for espousing the reading of anything (including vapid maniJESTos) to further education. you are richer for caring. pity for most folks the roll of the dice makes the opposite true.
ummm, moderators too drunk to notice this is flamebait? insightful my ass.
hey mozart was big w/ strings.... thought you'd appreciate that as a perl guru. (grin)