On 10/2/2012 5:48 PM, Pascal J. Bourguignon wrote:
BGB <[email protected]> writes:
On 10/2/2012 12:19 PM, Paul Homer wrote:
It always seems to be that each new generation of programmers goes
straight for the low-hanging fruit, ignoring that most of it has
already been solved many times over. Meanwhile the real problems
remain. There has been progress, but over the couple of decades
I've been working, I've always felt that it was '2 steps forward,
1.999999 steps back".
it depends probably on how one measures things, but I don't think it
is quite that bad.
more like, I suspect, a lot has to do with pain-threshold: people will
clean things up so long as they are sufficiently painful, but once
this is achieved, people no longer care.
the rest is people mostly recreating the past, often poorly, usually
under the idea "this time we will do it right!", often without looking
into what the past technologies did or did not do well
engineering-wise.
or, they end up trying for "something different", but usually this
turns out to be recreating something which already exists and turns
out to typically be a dead-end (IOW: where many have gone before, and
failed). often the people will think "why has no one done it before
this way?" but, usually they have, and usually it didn't turn out
well.
One excuse for this however, is that sources for old research projects
are not available generally, the more so for failed projects. At most,
there's a paper describing the project and some results, but no source,
much less machine readable sources. (The fact is that those sources
were on punch cards or other unreadable media).
a lot of things are for things which are much more recent as well.
so, a blind "rebuild starting from nothing" probably wont achieve
much. like, it requires taking account of history to improve on it
(classifying various options and design choices, ...).
Sometimes while not making great scientific or technological advances,
it still improves things. Linus wanted to learn unix and wrote Linux
and Richard wanted to have the sources and wrote GNU, and we get
GNU/Linux which is better than the other unices.
well, except, in both of these cases, they were taking account of things
which happened before:
both of them knew about, and were basing their design efforts off of, Unix.
the bigger problem is not with people being like "I am going to write my
own version of X", but, rather, a person running into the problem
without really taking into account that "X" ever existed, or without
putting any effort into understanding how it worked.
it is like trying to convince other language/VM designers/implementers
that expecting the end programmer to have to write piles of
boilerplate to interface with C is a problem which should be
addressed, but people just go and use terrible APIs usually based on
"registering" the C callbacks with the VM (or they devise something
like JNI or JNA and congratulate themselves, rather than being like
"this still kind of sucks").
though in a way it sort of makes sense: many language designers end up
thinking like "this language will replace C anyways, why bother to
have a half-decent FFI?...". whereas it is probably a minority
position to design a language and VM with the attitude "C and C++
aren't going away anytime soon".
but, at least I am aware that most of my stuff is poor imitations of
other stuff, and doesn't really do much of anything actually original,
or necessarily even all that well, but at least I can try to improve
on things (like, rip-off and refine).
even, yes, as misguided and wasteful as it all may seem sometimes...
in a way it can be distressing though when one has created something
that is lame and ugly, but at the same time is aware of the various
design tradeoffs that has caused them to design it that way (like, a
cleaner and more elegant design could have been created, but might
have suffered in another way).
in a way, it is a slightly different experience I suspect...
I would say that for one thing the development of new ideas would have
to be done in autarcy: we don't want and can't support old OSes and old
languages, since the fundamental principles will be different.
But then I'd observe the fate of those different systems, even with a
corporation such as IBM backing them, such as OS/400, or BeOS. Even if
some of them could find a niche, they remain quite confidential.
yeah. the problem is, "a new thing" is hard.
it is one thing to sell, for example, an x86 chip with a few more
features hacked on, and quite another to try to sell something like an
Itanium.
people really like their old stuff to keep on working, and for better or
worse, it makes sense to keep the new thing as a backwards-compatible
extension.
On the other hand, more or less relatively recently, companies have been
able to develop and sell new languages/systems: Sun did Java/JVM and
it's now developed by Google in Android systems; Apple promoted
Objective-C on iOS, both with quite a commercial success, and
third-party developers.
FWIW, Java was a bit naive in a few ways, but did have something going
for it:
it still retained a lot of its core syntax and semantics from C and C++,
albeit in a simplified form.
for as nasty as it was, Objective-C still built on C, and iOS still
builds on a Unix-like base.
C# is also moderately successful, and also largely resembles both Java
and C++.
so, for example, even though C# is a new language, it would be a bit
hard to claim that it was developed blindly (without knowledge of stuff
which came before).
early on, I saw hype essentially claiming that Java was going to be the
death-blow for C and C++ and so on, but this didn't really happen.
instead, Java and C ended up mostly in different domains, with neither
really being "better" than the other.
so, it is one thing to create a language and have it be used, and quite
another for it to "kill" or "replace" peoples' use of C and C++.
so, in my case, I sought mostly to make my language play well with C, as
after all, I am mostly a C developer anyways.
but, OTOH, there are some use-cases that C and C++ just don't really
handle very well, so neither is the "end-all be all" of languages either.
it is possible that the notion that use of one programming language
necessarily comes at the cost of another language, may be itself flawed.
So one could imagine than after having developped a good kind of
language and system, a corporation could embed them in a user plateform
with some commercial success, and the corresponding popularity amongst
third-party developers.
yes.
Then once you're a billionaire, you also have this opportunity, beside
backing Ubuntu or Mars colonization.
Let's keep our optimism!
yeah, as for Ubuntu:
I have recently been wondering how long MS will hold on as the dominant
OS supplier;
some recent trends don't really seem to be looking good for their position.
the issue wasn't claiming that new things can't be made, but rather
there is a problem with people thinking that just because they have made
it fresh, it will automatically be superior to all the "old / crufty"
stuff which came before.
for example, in my case, I have this ugly beast:
a WAD variant shoved into a PE/COFF image and used to store a bunch of
bytecode-objects and metadata databases. ( functionally, it is about
halfway between a .NET/CLR image and a JAR file. ).
I am left to realize that, yes, PE/COFF is ugly, and jury-rigging a
hackish WAD variant into it (often post link) isn't exactly all that
much better (note: it also supports combining with ELF, and being
standalone).
even something as simple as the current directory entry structure:
struct ExWAD_DirEnt101_s
{
u32 rva_data; //RVA of (compressed) data
u32 dsize_data; //uncompressed size of data
u32 csize_data; //compressed size of data
byte type; //file/entry type (0=default, 1..255, special members)
byte method; //compression method (0=store, 8=Deflate, 9=Deflate64)
u16 flags; //special flags
u32 dir; //parent directory
byte pad[12]; //padding
byte name[32]; //name, inline, or with the first 4 bytes as the name RVA
};
in some sense, this is an ugly way to structure a directory entry.
just going under my own personal preferences, I would have preferred
variable-length codings for the various fields, and probably some sort
of self-identifying tags to simplify adding additional attributes, ...
or, maybe at least, having parent directories "contain" their contents
(rather than having the contained files/directories back-link to their
parent directory), ...
but, for example, a lot of the above would have come at a drawback:
it would have been necessary to essentially "unpack" the central
directory into a big array before being able to make use of it (the
format was designed to be reasonably straightforward to be used in-place
from a loaded PE/COFF image). (they are also actually mounted by walking
the list of loaded DLLs and checking if each contains an ExWAD image).
otherwise, random access to variable-length members is fairly costly
(there is a strategy which .NET uses for metadata, but it is complicated
and awkward).
so, as horridly arbitrary and kludgy as a lot of this may seem, it was
done this way for a reason (including the choice not to use a ZIP-based
packaging like JAR or APK).
but, then again, a lot of the VM is this way, stuff which is just nasty,
and stuff which could have been implemented better, ...
everything from things like handling operators and operator overloading,
to things like the use of prefixes to indicate the types for bytcode
operations (this is related to type-inference, no prefix and dynamic
type-checking is assumed), ...
(note: I intended originally for things to be more like CIL with backend
type inference, but this was proving impractical for the interpreter
backend, so the type inference was moved to the frontend, at the cost of
adding type-hint prefixes to the bytecode).
so, I am left to realize that, in many ways, it is not very good, but at
the same time, I wouldn't really benefit much by switching over to some
other option either.
but, at the same time, many people would also not benefit much from
using any of my stuff either, and it probably doesn't have a whole lot
of value in a general/global sense either.
or such...
_______________________________________________
fonc mailing list
[email protected]
http://vpri.org/mailman/listinfo/fonc
