BGB,
I love this quote from you
"sometimes, the new thing can be simpler overall, even if initially or
conceptually more complex."
This resonates with me big time. A lot of effort to build infrastructure
that will make things simpler
P
On Sun, Jan 22, 2012 at 10:08 AM, BGB <cr88...@gmail.com> wrote:
> On 1/21/2012 8:11 AM, Peter Franta wrote:
>
> VPRI answer to their Government and Private Funders, not those of us who
> have the fortune to observe as they go.
>
> It is my understanding the deliverable is not a "product" but "lessons
> learned" to go and do it for real! Not ideal for us but then they're not
> serving us.
>
> Clearly this doesn't match your expectations. This is frustrating to you
> but are your expectations their concern? Where do these expectations come
> from?
>
> Popular/Successful <> Better. It all depends on your pov and what you
> value.
>
>
> yeah. I am just a random observer as well, and operating in the far more
> mundane world of "spewing code and trying to make it all work..." (and
> wondering if/when/where I will ever make an income).
>
> there is some amount of "experimentation", but most of this is itself much
> more mundane, and not really a central focus (it is more of a "try various
> things and see what sticks" experience).
>
>
> likewise, it can be interesting to gather and try out ideas, and see what
> all works.
> sometimes, the new thing can be simpler overall, even if initially or
> conceptually more complex.
>
>
> for example, at a basic level, dynamic typing is more complex than static
> typing (which can be seen as a type-checked variant of an untyped system).
> once things start getting more complex, and one is dealing with less
> trivial type semantics, then dynamic typing becomes much simpler (the main
> difference is that dynamic typing is not well-supported on current
> hardware, leading to complex/awkward type inference in an attempt to get
> reasonable performance).
>
> but, then there is a tradeoff:
> static types work better in the simple case for finding many types of
> errors (even a good type-inference algo with type-validation may, with a
> loose type-system, accept bad input and coerce it into a
> semantically-valid, but unintended form).
>
> dynamic type-systems work better when the types are less trivial, and/or
> may become, well, dynamic (at which point, many good old static languages
> lead either to overly complex mechanisms, or a need to "strong arm" the
> type-system via lots of casts). even in an otherwise well-developed static
> language, there may end up being stupid/arbitrary restrictions which don't
> follow from either the implementation or the conceptual semantics (such as,
> in several languages, the inability to pass/convert a generic-container for
> a subclass into a generic container for the superclass, ...).
>
> in these cases, it may well make sense to leave it up to the programmer
> which semantics they want to use.
>
> for example, in my own language, if a declared type is used, it is treated
> more like in a static language (coercing if needed and the types are
> compatible, or potentially making an error otherwise).
>
> some other languages treat things more loosely, making me wonder what
> really is the point of having type annotations in this case. what is gained
> from annotations if the compiler does not enforce the types and the types
> don't impact run-time behavior? in terms of optimization, in this case,
> they offer little more than what could have been reasonably gained by
> type-inference. there only real obvious merit is to serve as a hint for
> what type the variable "should" be (if people so happen to be look at the
> declarations at the time).
>
> granted, when one has both static and dynamic type-semantics, this is
> potentially more complex than either case by itself (although, having both
> does allow some potentially interesting semantics, such as the ability to
> handle semantics which would likely be slow in a dynamically-typed
> language, but which would be overly complicated or not possible to
> represent with traditional uses of generics or templates, such as
> conditional or "evaluated" types).
>
>
> but, who knows, maybe there are better ways to deal with all this as well?
>
> how much of the concept of 'types' is itself real, and how much is an
> artifact of the existing implementations? how much of existing programming
> practice is "real", and how much is essentially cruft?
>
> simple example:
> there are fields and there are methods;
> sometimes we want to access fields directly, and sometimes to limit such
> access.
>
> so, then the public/private notion popped up, with the usual convention
> being to keep all fields as private. then, people introduced getter/setter
> methods (and there is then a whole lot of "obj.getX()" and
> "obj.setX(value)").
>
> then, languages have added properties, so that the extra notation can be
> shaved back off (allowing, once again, "obj.X" and "obj.X=value;"), and
> have similarly allowed short-hand dummy property declarations, such as
> "public double X { get; set; };"
>
> although there are sensible reasons behind all of this, one can also
> wonder: "what exactly really is the point?". couldn't one, say, just as
> easily (assuming the language handled it gracefully) declare the field
> initially as public, and if later it needs to be trapped, simply change it
> to private, drop in the property handler, and call it good?...
>
> or, alternatively, if one declares a property without its associated
> variable, why not just "infer" that said variable needs to exist and,
> y'know, create it?...
>
> granted, some people have asked the same of other sorts of variables, but
> the usual issue is that referring to an undeclared variable leaves it very
> ambiguous as to what sort of scope the variable should have, or if it
> should exist at all.
>
> granted, I personally see little "real" need though for why direct static
> visibility should be mandatory, and so I tend to leave open the
> possibilities of indirect static visibility and also for dynamic visibility
> (this has been disallowed in certain cases in some of my language designs,
> but my implementations have thus far not bothered checking for them).
> typically, the variable needs to exist "somewhere" though.
>
> practically, I suspect that the issue is that this case would be fairly
> complicated in a traditional early-bound VM, and that a lot of stuff I have
> read doesn't really allow for the possibility of there to be a
> statically-determinable "gray area" between traditional early-bound
> semantics and dynamically-handled late-binding... I guess, maybe it is
> because it is seen as something roughly akin to inlining virtual methods or
> similar.
>
> sadly, I know of more possible nifty edge-cases than my current
> implementation bothers to exploit (most of the time, lacking lexical
> visibility, it will just fall back to using dynamic late-binding).
>
>
> but, there are probably endless such things around I guess.
>
> or such...
>
>
>
> Regards
> P
>
>
> On Sat, Jan 21, 2012 at 9:11 PM, Loup Vaillant <l...@loup-vaillant.fr>wrote:
>
>> Le 1/21/2012 2:52 AM, Reuben Thomas a écrit :
>>
>>> I have just skimmed VPRI's 2011 report; lots of interesting stuff
>>> there. The ironies of a working system that the rest of us can only
>>> view in snapshot form grow ever-stronger: the constant references to
>>> active documents are infuriating. The audience would like to see the
>>> active document, but instead we only get a printout. It's as if,
>>> waiting for a new film, we got only reviews of trailers rather than
>>> the trailers themselves.
>>>
>>> The irony is then compounded by a code listing at the end of the
>>> document (hint: a URL is shorter and actually useful; this is not the
>>> 1980s).
>>>
>>> And then just when we thought it was going to end, the agony
>>> continues: you've pushed the deadline back a year.
>>>
>>> I wish you all a joyful and productive 2012; unlike many projects,
>>> it's clear that with this one the question is not whether what is
>>> finally released will be worth the wait, it's whether it'll ever
>>> actually be released.
>>>
>>> You do shoot yourselves in the foot at one point: "The Web should have
>>> used HyperCard as its model, and the web designers made a terrible
>>> mistake by not doing so." Yes, but the web shipped and revolutionised
>>> the world; meanwhile, you lot have shipped stuff that, at best, like
>>> Smalltalk, has inspired revolutions at one remove. Many of the lessons
>>> of your work are decades old and still not widely learned. Contrast
>>> with Steve Jobs, who spun an ounce of invention into a mile of
>>> innovation, by combining a desire for better computing with the
>>> understanding that without taking people with you, your ideas will die
>>> with you. It's a shame and an embarrassment that to the world at large
>>> he's the gold standard.
>>>
>>> Please, no more deadline extensions. Whatever you have by the end of
>>> this year will unquestionably be worth releasing, for all its
>>> imperfections. It's high time to stop inventing the future and start
>>> investing it.
>>>
>>
>> The FONC Wiki mention subversion repositories here:
>> (stable) http://piumarta.com/svn2/idst/tags/idst-376
>> (trunk) http://piumarta.com/svn2/idst/trunk
>>
>> I haven't tried yet, but it seems we outsiders can already play with it.
>> Maybe that'll do as an actual "trailer"?
>>
>> Loup.
>> _______________________________________________
>> fonc mailing list
>> fonc@vpri.org
>> http://vpri.org/mailman/listinfo/fonc
>>
>
>
>
> _______________________________________________
> fonc mailing listfonc@vpri.orghttp://vpri.org/mailman/listinfo/fonc
>
>
>
> _______________________________________________
> fonc mailing list
> fonc@vpri.org
> http://vpri.org/mailman/listinfo/fonc
>
>
_______________________________________________
fonc mailing list
fonc@vpri.org
http://vpri.org/mailman/listinfo/fonc
