basically, the same thing as before, but I encountered this elsewhere
(on Usenet), and figured I might see what people here thought about it:
http://www.codingthewheel.com/game-dev/john-carmack-script-interpreters-considered-harmful
yes, granted, this is a different domain from what the people here are
dealing with.
BTW: I was recently doing some fiddling with working on a new JIT
(unrelated to the video), mostly restarting a prior effort (started
writing a new JIT a few months ago, stopped working on it as there were
more important things going on elsewhere, this effort is still not a
high-priority though, ...).
not really sure if stuff related to writing a JIT is particularly
relevant here, and no, I am not trying to spam, even if it may seem like
it sometimes.
On 3/2/2012 10:25 AM, BGB wrote:
On 3/2/2012 3:07 AM, Reuben Thomas wrote:
On 2 March 2012 00:43, Julian Leviston<jul...@leviston.net> wrote:
What if the aim that superseded this was to make it available to the
next
set of people, who can do something about real fundamental change
around
this?
Then it will probably fail: why should anyone else take up an idea
that its inventors don't care to promote?
yeah.
most people are motivated essentially by "getting the job done", and
if a technology doesn't exist yet for them to use, most often they
will not try to implement one (instead finding something which exists
and making it work), or if they do implement something, it will be
"their thing, their way".
so, it makes some sense to try to get a concrete working system in
place, which people will build on, and work on.
granted, nearly everything tends towards "big and complex", so there
is not particularly to gain by fighting it. if one can get more done
in less code, this may be good, but I don't personally believe
minimalism to be a good end-goal in itself (if it doesn't offer much
over the existing options).
Perhaps what is needed is to ACTUALLY clear out the cruft. Maybe
it's not
easy or possible through the "old" channels... too much work to
convince too
many people who have so much history of the merits of tearing down the
existing systems.
The old channels are all you have until you create new ones, and
you're not going to get anywhere by attempting to tear down existing
systems; they will be organically overrun when alternatives become
more popular. But this says nothing about which alternatives become
more popular.
yep.
this is a world built on evolutions, rather than on revolutions.
a new thing comes along, out-competes the old thing, and eventually
takes its place.
something new comes along, and does the same.
and so on...
the most robust technologies then are those which have withstood the
test of time despite lots of competition, and often which have been
able to adapt to better deal with the new challenges.
so, if one wants to defeat what exists, they may need to be able to
create something decidedly "better" than what exists, at the things it
does well, and should ideally not come with huge costs or drawbacks
either.
consider, a new systems language (for competing against C):
should generate more compact code than C;
should be able to generate faster code;
should not have any mandatory library dependencies;
should ideally compile faster than C;
should ideally be easier to read and understand than C;
should ideally be more expressive than C;
...
and, avoid potential drawbacks:
impositions on the possible use cases (say, unsuitable for writing an
OS kernel, ...);
high costs of conversion (can't inter-operate with C, is difficult to
port existing code to);
steep learning curve or "weirdness" (should be easy to learn for C
developers, shouldn't cause them to balk at weird syntax or semantics,
...);
language or implementation is decidedly more complex than C;
most of its new features are useless for the use-case;
it poorly handles features essential to the use case;
...
but, if one has long lists, and compares many other popular languages
against them, it is possible to generate estimates for how and why
they could not displace it from its domain.
not that it means it is necessarily ideal for every use case, for
example, Java and C# compete in domains where both C and C++ have
often done poorly.
neither really performs ideally in the others domain, as C works about
as well for developing user-centric GUI apps as Java or C# works well
as a systems language: not very well.
and, neither side works all that well for high-level scripting, hence
a domain largely controlled by Lua, Python, Scheme, JavaScript, and so
on.
but, then these scripting languages often have problems scaling to the
levels really needed for application software, often showing
weaknesses, such as the merit (in the small) of more easily declaring
variables while mostly ignoring types, becomes a mess of
difficult-to-track bugs and run-time exceptions as the code gets
bigger, and one may start running into problems with managing
visibility and scope (as neither lexical nor global scope scale
ideally well), ...
more so, a typical scripting language is likely to fail miserably as
systems languages.
so, it also makes sense to define which sorts of domains a language
targets.
...
for example, although my own language is working some on features
intended for increasing scalability and performance (and some use in
the "application" domain), its primary role remains as a scripting
language, generally for apps written in C and C++ (since C remains as
my main language, with C++ in second place).
in my case, assuming it is "good enough", it may eventually subsume
some areas which are currently handled mostly by C code, but
development is slow in some ways (and "change" often happens one piece
at a time). things are still far from perfect (and I often use caution
in these areas, as lacking sufficient caution long ago ended up
costing me a fair amount of code...).
or such...
_______________________________________________
fonc mailing list
fonc@vpri.org
http://vpri.org/mailman/listinfo/fonc
