What's so good about Felix? I need to know because its hard
to market something without a coherent explanation of why it's better.
1. Easy compilation.
Just saying "flx filename" is really cool. No makefiles or crap.
I plan to extend this capability to C/C++. At the moment, Felix + C++
compiler is supported on the command line but doesn't work.
It needs to be fixed, and some way to just make C++ code added.
It's pretty easy to add
//$$ Depend: packagename
to C++ files so you can auto compile and link the same was as Felix does it.
My target here: the whole Run Time Library is going to be installed
AS SOURCE and the actual binaries cached just like for
Felix code. In other words put Felix and C++ code in the same
basket. Unlike Ocaml, C/C++ translation units can be built
in any order. There are no dependencies.
2. Easy refactoring. You can just move stuff around. It's more or less
that simple. Try doing that in any other language. Split out a file?
Just respect scope, put include "./filename", and you're done.
Reorder code? Again, just respect scopes and you can reorder
any definitions (NOT variable initialisations or executable statements!)
Thanks to "setwise lookup", and the lack of "interfaces". Executable stuff
can be packed and interleaved as desired with definitions but not reordered.
3. Simple shellish script.
We're NOT there yet. It's still easier to write simple stuff in bash.
On unix, however the shell and tools are severely compromised
by a completely broken file system model, and a total lack
of coherent interfaces for the tools. Some progress here is
available with flx_cp, etc. These tools have a simple common
interface (being improved all the time) and a coherent view
of the filesystem via Perl regexps. There's great potential here
to improve the tool set, particularly leveraging the relatively
new stream iterator constructs.
4. A great balance between simple script and high performance.
Typical Felix code, even using high level (read SLOW) constructions
like stream iterators, closures, plugin objects, etc, has pretty good
performance compared with similar constructions in any other
scripting language. And you can rely on core calculations being
thousands of times faster, on par with C.
The result is you can do things like high level matrix maths,
and you don't have to split your code into Python for the
top stuff and NumPy or whatever for the core. One language
can do both. So it's extensible, whilst Python/NumPy is not.
No, it's not really suitable for kernel development and on the
other end there's no REPL. but it covers the territory in
between better than anything else.
5. Self documenting Code
This is in a very primitive form at the moment. It's possible to
write library modules with web-servable documentation.
It's possible to write unit tests with documentation and
expected results. That's about it. I hope this will extend to
something roughly like a Wiki based language, in particular
eliminating the need to install stuff (that's what "the web"
is for isn't it?) It's been done before (Perl/CPAN, TeX/CTAN)
and of course C++/Boost).
--
john skaller
skal...@users.sourceforge.net
http://felix-lang.org
------------------------------------------------------------------------------
The Go Parallel Website, sponsored by Intel - in partnership with Geeknet,
is your hub for all things parallel software development, from weekly thought
leadership blogs to news, videos, case studies, tutorials, tech docs,
whitepapers, evaluation guides, and opinion stories. Check out the most
recent posts - join the conversation now. http://goparallel.sourceforge.net/
_______________________________________________
Felix-language mailing list
Felix-language@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/felix-language
