Design & Implementation Questions
winxordie
I - is it worth replacing C (for now)?
There's a C compiler for every device worth mentioning or some subset
of it and there's plenty of good work in languages that compiles to C.
When I read the language description, I immediately thought of bash-
inspired SAC (see http://www.sac-home.org/). There have been so many
languages that have attempted to kill the parallelism dragon (I'm
thinking SISAL) and obviously, none of them have succeeded in the
mainstream - even when they succeeded in their goals. Writing out to C
also allows for the addition of the horde of C libraries natively -
which though painful, is less painful than rewriting them all in ANI
to achieve the same speed; this is a general purpose language, right?
II - System language - JIT/incremental compilation?
It seems that with a piping framework that finding out when
optimizations can be done in runtime would be a lot simpler than in
other frameworks because unix processing is basically a giant pipe
graph; I'm a big fan of this particular innovation. Has JIT
compilation been considered via GNU lightning or dynasm? (from the
LuaJIT project)
I know the emphasis on the language is on performance, but you could
just replace the entire unix subsystem with a more efficient, unified
set of quickly produced, hot-swapped script-turned-bytecodes.
Just some thoughts. ;)
Daniel Kersten
On 17 February 2010 01:18, winxordie <winx...@gmail.com> wrote:
> This language is an interesting idea. Two questions:
>
> I - is it worth replacing C (for now)?
Of course it is. Never mind the fact that C is a horrible language[1]
which is waaay behind the programming state of the art, when isn't it
beneficial to develop new tools and technologies? Especially if they
try to bring an all too often overlooked paradigm to the masses.
Besides, C will never be able to provide what ANI aims to do: easy,
implicit, safe and guaranteed deadlock-free parallelism.
[1] I mean from a safety point of view, but also from what "high
level" features C supports and an ease of development view.
> There's a C compiler for every device worth mentioning or some subset
> of it and there's plenty of good work in languages that compiles to C.
True and this is the very reason why a lot of languages DO compile to
C. I don't think this makes sense for ANI, however, since ANI aims to
become faster than C. The features and semantics of ANI can be written
in C, but it would be complex and not nearly as fast as the native
runtime system which Adrian proposes.
> When I read the language description, I immediately thought of bash-
> inspired SAC (see http://www.sac-home.org/). There have been so many
> languages that have attempted to kill the parallelism dragon (I'm
> thinking SISAL) and obviously, none of them have succeeded in the
> mainstream - even when they succeeded in their goals. Writing out to C
> also allows for the addition of the horde of C libraries natively -
> which though painful, is less painful than rewriting them all in ANI
> to achieve the same speed; this is a general purpose language, right?
The problem with native C libraries is that they do not follow ANI's
runtime semantics and therefore any program which uses C libraries
cannot be guaranteed safe or deadlock free. Having said that, Adrian
has stated that he will support some form of FFI.
>
> II - System language - JIT/incremental compilation?
> It seems that with a piping framework that finding out when
> optimizations can be done in runtime would be a lot simpler than in
> other frameworks because unix processing is basically a giant pipe
> graph; I'm a big fan of this particular innovation. Has JIT
> compilation been considered via GNU lightning or dynasm? (from the
> LuaJIT project)
The proposed runtime does use a form of JIT compilation internally to
sequence code chunks on the fly. Theres a mailing list thread about
it, if your interested.
> I know the emphasis on the language is on performance, but you could
> just replace the entire unix subsystem with a more efficient, unified
> set of quickly produced, hot-swapped script-turned-bytecodes.
Actually, I really REALLY want a compiler option that will remove
optimizations and other nice to have, but not necessary compiler
features so that a mode exists where compilation is blazingly fast. My
logic here is that if the compile-and-run cycle is fast enough, nobody
needs ever know that the "ANI script" is actually AOT compiled. My
main use case is to build some form of exploratory development system,
but it could then perhaps be used kind of how you suggest. Maybe.
>
> Just some thoughts. ;)
>
--
Daniel Kersten.
Leveraging dynamic paradigms since the synergies of 1985.
Ultimus
> This language is an interesting idea. Two questions:
>
> I - is it worth replacing C (for now)?
> There's a C compiler for every device worth mentioning or some subset
> of it and there's plenty of good work in languages that compiles to C.
> When I read the language description, I immediately thought of bash-
> languages that have attempted to kill the parallelism dragon (I'm
> thinking SISAL) and obviously, none of them have succeeded in the
> mainstream - even when they succeeded in their goals. Writing out to C
> also allows for the addition of the horde of C libraries natively -
> which though painful, is less painful than rewriting them all in ANI
> to achieve the same speed; this is a general purpose language, right?
Dan's done an excellent job covering the important points already.
I'd just like to add that ANI is doing something very different from
SAC; ANI supports multiple asynchronous sends to the same object (it's
not single-assignment, nor is there even any true notion of
"assignment"), and unlike SAC, ANI advances implicit non-sequential
concurrent execution with full safety guarantees as a core language
concept in contrast to SAC's traditional "concurrency as an
afterthought" paradigm.