Five bucks says the species doesn't know what it's talking about yet. Admitting this is probably very healthy... it's a good way to avoid thinking that the ideas we have now are perfect or complete, an attitude I see a lot in industry.
My favorite is the this-language-is-better-than-that-one. Such a dead horse, and having this argument leads not to thinking about language in new ways, but to affirming what we think we know about the languages we understand already. Debates about operating systems can end up in the same trap pretty quickly. One ends up with something more like religion than science. The field is young. A lot of young people I end up working with have some trouble grasping that. There aren't enough people with real experience or knowledge of history around the trenches, it would seem. But then again, I'm _dead certain_ that I don't know what I'm talking about, which is why I'm only betting five dollars;) On Fri, Aug 19, 2011 at 3:04 PM, BGB <[email protected]> wrote: > On 8/19/2011 11:05 AM, DeNigris Sean wrote: > > Alan, > > I'm thinking more deeply about computers and language and have realized that, > after programming for 15 years, I still have no idea what I'm talking about :) > > > just offering my opinions here. > but, yeah, maybe many of us don't really know what we are talking about. > > I think the problem is that it is very hard to know in advance what is best > or how things will go, so better probably to try out ideas and see what all > works and doesn't work, and use these to guide and refine possible future > technologies. > > > > After reading many of the LISP suggestions (thanks), the primary features > seem to me to be: > > > - parsimony (again you got to me and I finally looked it up; "extreme > unwillingness to spend money or use resources") > - little syntax - you can learn the language in 5 minutes > - uniformity - everything from variables to procedures are treated the > same. > > > both points are "double-edged swords" though. > > > the minimal syntax makes many constructions overly verbose and operations > are often not "visually distinctive", which slows down reading and thinking > about code (the contrast is a "glyph soup" strategy, where particular > glyphs/operators/... will more often stand out). > > granted an "ugly mass of glyphs" is not exactly an ideal strategy either. > > building on common experience is another possibility to reduce the learning > curve (many things will retain a familiar look and feel), but granted a > strict/dogmatic adherence to convention might be overly limiting, so there > are tradeoffs. > > > uniform treatment of variables and functions also has good and bad points. > for example, it is possible to easily get/set methods, ... which can be very > useful. > > some languages, such as Java, lack this ability (ability to get/set > functions or methods), and it is painfully obvious from the POV of someone > who is used to languages with this capability (namely: most non-Java > languages...). (having to use an class instance for sake of, say, a > callback, is just nasty...). > > ( Java then had later added anonymous classes/... to partly work around > some of this, but personally I feel that using anonymous classes to make up > for the lack of first-class functions/closures and ex-nihilo objects and > similar to be "not a very good strategy". ) > > > a downside though is that most languages don't generally support overloaded > variables, meaning that the uniform treatment of variables and methods will > often come at the cost of being able to overload them (may be hacked around, > but often these have worse drawbacks). > > a common result is that assignable functions are often explicit in the > language and may not be overloaded, and that typically getting a function > handle will require it to not be overloaded (more common, say, in C++), or > require an explicit cast to indicate the desired signature (C#). > > a downside of C and C++ style function pointers is that they don't > (generally) capture binding state (nevermind GCC and C++0x, which add > support for "closures", but which are limited to the lifetime of the parent > scope). sadly, general-purpose state-capture then requires using an object. > > however, in the common case of using function pointers to implement > getable/setable methods, the lack of state capture isn't too much of an > issue (hence, C++ ends up still being somewhat more convenient than the > level of hassle required to do similar in a language like Java). > > > > > - power - a meta-system where you can change anything e.g. the order the > arguments are processed in, what syntax is legal, etc. > > > yep, this is a nifty feature. > sadly, the Lisp macro system is not something which can be faithfully done > in notably different languages. > > another biggie problem is that a lot of this may conflict with the use of > late binding (and a delegation-based scoping model), since by design macros > have to be early-bound, making them potentially a "sore thumb" in a language > design sense. > > they may also risk exposing some implementation "nastiness", or may be used > in confusing and/or counter-intuitive ways (since there may not be any > obvious way to tell them apart from built-in functions or similar). > > > some of what could be done in using macros can be done in my case using the > "quote" and "unquote" keywords, but these are sort of a "lame joke" vs > macros. > > for example: > unquote foo(quote x+3); > would be (sort of) similar to: > (eval (foo '(+ x 3))) > > although possible could be to do similar with the syntax: > foo<x+3>; > I don't really like this option (I don't really like the <...> syntax for > sake of it creating ambiguities). > > "foo!(...)" or "foo![...]" could also be possible. > also: > "foo:(...)" but this would create a whitespace sensitive operation. > "foo::(...)", could also work, and is not *too* ugly. > > note that, ideally, this would be a cached operation, rather than naively > rebuilding the code-fragment on every execution (or being a "one off" static > operation), but this leads to another problem: > how to make this semantically-transparent?... (I lack ideas for an obvious > flushing/invalidation mechanism in this case). > > this could lead to several edge cases: > a case where it is preferable to have it be one-off; > a case where it is preferable to dynamically re-build the expression. > > > > > - I'm not sure where, if at all, security comes in > > doesn't really appear to me that Lisp was really designed with security in > mind. > > > <snip> > > I can't really comment on a lot of this (too far outside my area). > > > _______________________________________________ > fonc mailing list > [email protected] > http://vpri.org/mailman/listinfo/fonc > > -- Casey Ransberger
_______________________________________________ fonc mailing list [email protected] http://vpri.org/mailman/listinfo/fonc
