basically, the same thing as before, but I encountered this elsewhere (on Usenet), and figured I might see what people here thought about it:

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<>  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
Then it will probably fail: why should anyone else take up an idea
that its inventors don't care to promote?


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.


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

Reply via email to