On 3/1/2012 10:12 AM, Loup Vaillant wrote:
BGB wrote:
there is also, at this point, a reasonable lack of "industrial strength
scripting languages".
there are a few major "industrial strength" languages (C, C++, Java, C#,
etc...), and a number of scripting languages (Python, Lua, JavaScript,
...), but not generally anything to "bridge the gap" (combining the
relative dynamic aspects and easy of use of a scripting language, with
the power to "get stuff done" as in a more traditional language).
What could you possibly mean by "industrial strength scripting language"?
When I hear about an "industrial strength" tool, I mostly infer that
the tool:
- spurs low-level code (instead of high-level meaning),
- is moderately difficult to learn (or even use),
- is extremely difficult to implement,
- has paid-for support.
expressiveness is a priority (I borrow many features from scripting
languages, like JavaScript, Scheme, ...). the language aims to have a
high-level of dynamic abilities in most areas as well (it supports
dynamic types, prototype OO, lexical closures, scope delegation, ...).
learning curve or avoiding implementation complexity were not huge
concerns (the main concession I make to learning curve is that it is in
many regards "fairly similar" to current mainstream languages, so if a
person knows C++ or C# or similar, they will probably understand most of
it easily enough).
the main target audience is generally people who already know C and C++
(and who will probably keep using them as well). so, the language is
mostly intended to be used mixed with C and C++ codebases. the default
syntax is more ActionScript-like, but Java/C# style declaration syntax
may also be used (the only significant syntax differences are those
related to the language's JavaScript heritage, and the use of "as" and
"as!" operators for casts in place of C-style cast syntax).
generally, its basic design is intended to be a bit less obtuse than C
or C++ though (the core syntax is more like that in Java and
ActionScript in most regards, and more advanced features are intended
mostly for special cases).
the VM is intended to be free, and I currently have it under the MIT
license, but I don't currently have any explicit plans for "support". it
is more of a "use it if you want" proposition, provided "as-is", and so on.
it is currently "given on request via email", mostly due to my server
being offline and probably will be for a while (it is currently 1600
miles away, and my parents don't know how to fix it...).
but, what I mostly meant was that it is designed in such a way to
hopefully deal acceptably well with writing largish code-bases (like,
supporting packages/namespaces and importing and so on), and should
hopefully be competitive performance-wise with similar-class languages
(still needs a bit more work on this front, namely to try to get
performance to be more like Java, C#, or C++ and less like Python).
as-is, performance is less of a critical failing though, since one can
put most performance critical code in C land and work around the weak
performance somewhat (and, also, my projects are currently more bound by
video-card performance than CPU performance as well).
in a few cases, things were done which favored performance over strict
ECMA-262 conformance though (most notably, there are currently
differences regarding default floating-point precision and similar, due
mostly to the VM presently needing to box doubles, and generally double
precision being unnecessary, ... however, the VM will use double
precision if it is used explicitly).
If you meant something more positive, I think Lua is a good candidate:
- Small (and hopefully reliable) tools.
- Fast implementations.
- Widely used in the gaming industry.
- Good C FFI.
- Spurs quite higher-level meaning.
Lua is small, and fairly fast (by scripting language terms).
its use in the gaming industry is moderate (it still faces competition
against several other languages, namely Python, Scheme, and various
engine-specific languages).
not everyone (myself included) is entirely fond of its Pascal-ish syntax
though.
I also have doubts how well it will hold up to large-scale codebases though.
its native C FFI is "moderate" (in that it could be a lot worse), but
AFAIK most of its ease of use here comes from the common use of SWIG
(since SWIG shaves away most need for manually-written boilerplate).
the SWIG strategy though is itself a tradeoff IMO, since it requires
some special treatment on the part of the headers, and works by
producing intermediate glue code.
similarly, it doesn't address the matter of potential semantic
mismatches between the languages (so the interfaces tend to be fairly
basic).
in my case, a similar system to SWIG is directly supported by the VM,
does not generally require boilerplate code (but does require any
symbols to be DLL exports on Windows), and the FFI is much more tightly
integrated with the core language (which itself can work directly with
most C structures and data-types, such as pointers and C-style arrays).
in many regards, it is an experience a little closer to using 'extern
"C" { ... }' in C++ (and is generally bidirectional, supporting both
importing from C, and exporting to C, though the latter case requires
using a code-generating tool).
as-is, this interface can be used for accessing things like the Win32
API and OpenGL and so on, but generally this is not what I use it for.
sadly, it is not currently possible to directly make use of C++ classes,
as these pose more complex issues (which I have not yet tried to
address), so it is necessary for fall back to a C-style cross-language
interface (all this is on an eventual "to do" list though, among fixing
up some remaining limitations with the C FFI, ...).
or such...
_______________________________________________
fonc mailing list
fonc@vpri.org
http://vpri.org/mailman/listinfo/fonc
