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
<mailto: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 <mailto:fonc@vpri.org>
http://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
