Why do language designers continue to insist on semi-colon terminated lines?
Felix - a fast scripting language
51–60 of 88 posts
Re: Felix - a fast scripting language
#52Earlier quoted context omitted.
are you referring to the "The fastest scripting language on Earth" tagline? i saw that as a way to say "look, this is a compiled language that you can use as a scripting language" with a touch of whimsical humour.
Interesting. If that's the way it is intended I missed it completely; I'd definitely be much more receptive to that line of meaning.
Re: Felix - a fast scripting language
#53I'll stick with Lua. I wouldn't give up the dynamic aspects of a language like Lua just for a bit more speed. LuaJIT is more than enough, and if you are doing the hard number crunching that makes speed an issue there's a good chance it's not trivially harder just to write it in C++ to begin with.
For raw number crunching, LuaJIT is plenty fast anyway (when you use the FFI to instantiate native types), so unless you need something real special (SSE perhaps), it may not even buy you that much to use C++ over LuaJIT.
Re: Felix - a fast scripting language
#54how does this compare with haXe (haxe.org)? I see that it's billed as a "C++ code generator" and as a "scripting engine".... Does it generate C++ code that I could use without Felix afterwards?
There is actually an option of flx, --bundle=dirname, which puts the generated C++ in a single directory, to make it simpler to ship the generated C++ to another platform.
This does not do a full bundle, i.e. it doesn't package all the run time support code as well. That's on the TODO list, so you could literally copy the target directory to another machine and run "make" or something and only need a C++ compiler to build it.
There's another aspect to your question: if by "use" you also mean "modify" then the current state is that Felix generated C++ is a bit hard to read. The code is "good enough" to add debugging prints but not much more. It would be good to improve this so the code is more readable.
Re: Felix - a fast scripting language
#55While I enjoy reading about new and interesting languages (note: Felix has been around for over ten years), I really wish that language designers would put example code for something like FizzBuzz right on the front page to give people a flavor of the syntax. I can't remember how many times in my life I've done a link expedition through a website or docs just to see a simple programming example.
for var i in 1 upto 15 do
println$
match i % 3, i % 5 with
| 0,0 => "Fizz-Buzz"
| 0,_ => "Fizz"
| _,0 => "Buzz"
| _ => str i
endmatch
;
done
Did I get the job?Re: Felix - a fast scripting language
#56They are smoking crack if they think anyone will use a scripting language that doesn't have a functioning REPL. My goto-languages for quick development are Perl 5, Clojure and Javascript. All 3 are adequately fast for real tasks. All are cross-platform, and all 3 support a REPL that allows doing real work interactively. These conditions are the absolute minimum to be viable as a scripting or sketch/prototyping langua…
I agree this is not the same as a REPL with line by line interactive execution/editing with an environment that saves well defined symbols. Ultimately this would be tough to see through because Felix binds functions statically and lookup is setwise (like function scope in C) not linear, so recursive definitions cannot be introduced one at a time.
Re: Felix - a fast scripting language
#57Re: Felix - a fast scripting language
#58Earlier quoted context omitted.
Interesting. If that's the way it is intended I missed it completely; I'd definitely be much more receptive to that line of meaning.
Python and Lua are both compiled languages, almost all languages are compiled these days. They compile to bytecode rather than native machine code, then run an interpreter which may well do on-the-fly compilation to machine code (JIT). Bytecode target makes the compiler platform independent. Felix does the same, except the "bytecode" is ISO Standard C++.
For some strange reason, certain misconceptions in CS/programming have half-lives measured in several decades, such as this annoying distinction between interpreters/VMs/compiled languages. We're at least 20 years out from interpreters being meaningfully distinct from VMs and compiled languages.
Re: Felix - a fast scripting language
#59The web page rubs me the wrong way. How can you claim to be the fastest anything without a single benchmark? How can you claim to be a "scripting language" when you're statically-typed and compile to C++? What does "scripting language" even mean then? How can you say things like "it will be a bit slow the first time but subsequent runs will load much faster than any VM." Any VM? Are you really "much faster" than: $ t…
~/felix>flx --test=build/release --static mt
~/felix>time ./mt
real 0m0.004s
user 0m0.001s
sys 0m0.002s
~/felix>time ../lua-5.2.1/src/lua mt.lua
real 0m0.006s
user 0m0.001s
sys 0m0.003sRe: Felix - a fast scripting language
#60Earlier quoted context omitted.
How is int*int*int*int*int or even int^5 better than a plain int[5]? To me, the use of mathematical operators * and ^ causes dissonance.
If you're coming from a type theory background (which, granted, few are), this operator is actually perfectly natural. http://en.wikipedia.org/wiki/Product_type