Live data from Hacker News

Felix - a fast scripting language

felix-lang.org

51–60 of 88 posts

Re: Felix - a fast scripting language

#51
post #21

Why do language designers continue to insist on semi-colon terminated lines?

Two choices dictate a terminator: (a) free form 1D language like C vs 2D language like Python or Haskell, and, (b) support for assignment statements x = y and the like as in C vs all statements starting with a keyword as in say ATS. I personally do not like the semi-colons either.

Re: Felix - a fast scripting language

#52
post #42

Earlier 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.

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++.

Re: Felix - a fast scripting language

#53

I'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.

Just a small clarificatation: the 2.x version of LuaJIT only compiles floating point operations to SSE2 (http://lua-users.org/lists/lua-l/2010-03/msg00142.html). I'm not sure, however, whether it does vectorization or just operates on one float at a time.

Re: Felix - a fast scripting language

#54

how 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?

Yes, provided you collect all the required library headers and either sources or binaries: the generated C++ still requires run time libraries and the top level driver if it's a program.

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

#55

While 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

#56

They 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…

There is an alternative: a quick start GUI mini-IDE which allows you to type in and edit the code and press a button to run it. Such tools are mandatory on Windows anyhow: Ocaml and Python both have this for example. Most Unix editors like Vim or Emacs could be programmed to do this fairly easily I guess. I even wrote such a tool once using Tcl/Tk.

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

#57
I find it definitely a nice language proposal, but there are a few issues, I guess. A first one is that many of the distinctions introduced (such as proc,fun,gen) are all optimization issues. I would appreciate if it were possible to do that long after you're done with just making the program work. The language may force the developer way too early in the process to think of things that do not matter at that point. In the best case, it will matter later on, when the program truly works. Another issue I have is that the "simplifications" introduced initially lead to introducing lots and lots of additional symbols such $ and #, just because the simplification was apparently not leading to something simple. So, the language suffers from enforcing a premature optimization mindframe as well as from overly complex administrative simplification.

Re: Felix - a fast scripting language

#58
post #52

Earlier 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++.

Python and Lua are both compiled languages, almost all languages are compiled these days.

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

#59

The 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…

Macbook Pro:

  ~/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.003s

Re: Felix - a fast scripting language

#60

Earlier 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

Aren't product types just tuples, whereas arrays correspond to list types? The '^' operator can only construct arrays whose elements are of a single type, right?
Post reply on HN