4 ms·
NekoVM / Neko Programming Language
- JoelMcCracken 17y agoWhy should I care? (I'm not saying that I shouldn't care. It just isn't immediately apparent what the reason is for me to care.) There are lots of non mainstream languages out there. I love to learn about them, but I must be told why it should interest me.
- swah 17y agoNeko -> Haxe -> Cool flash stuff Related: http://ncannasse.fr/blog/physaxe http://ncannasse.fr/blog/physaxe [edit: oops, I think Haxe doesn't need Neko if you're targetting Flash]
- riffraff 17y agoI'd say he most interesting thing in neko is the idea of using a full featured simple language as the base for multi-language-same-vm interoperability. Contrast to, for example, parrot, clr.
- est 17y agohow is neko compared to lua today?
- swah 17y agoTotally different? IIRC, Neko is based on Ocaml, which is on the other side of the spectrum from dynamic languages like Lua... So... what do you mean?
- est 17y agohttp://nekovm.org/lua http://nekovm.org/lua > Lua is maybe the Virtual Machine that is the most similar to Neko in terms of goals, architecture and performances, it is interesting to compare the choices that the two VM are doing.
- deleted 17y ago[deleted]
- judofyr 17y agohttp://nekovm.org/lua http://nekovm.org/lua
- est 17y agothanks but I already knew that wiki. I wonder what the situation is TODAY, especially after LuaJIT2 came out.
- fab13n 17y agoIt seems that it can be summed up as "Neko is pissed that the niche it targeted is totally taken by Lua". The Neko/Lua comparison is mostly about implementation details and unsubstantiated efficiency claims (even before LuaJIT, the proper way to optimize Lua was to write critical stuff in C). Generally speaking, Lua totally steals the show for all conceptually simple and efficient languages with a mainstream syntax. It makes several hobbyists' projects, including Neko, definitely obsolete.
- silentbicycle 17y ago> even before LuaJIT, the proper way to optimize Lua was to write critical stuff in C Also, Lua has a refreshing modesty in that it's convenient for prototyping, but makes moving stuff out to C extremely easy. Unlike (say) Python, the language is designed around the assumption that most of your project may be in C.
- silentbicycle 17y agoWhen talking about mutable strings, he says that Lua's immutable strings make reading a file "quadratic and [...] prohibitively slow for even files of a few kilobytes.", which is demonstrably false. Sure, if you read a byte, nondestructively append a byte to what you've read, looping through anything, then you're screwed, in any language.* Large files should be read a line, a block, a megabyte, etc. at a time, anyway, though - the IO call overhead will dominate otherwise, no matter what you do. * Joel Spolsky calls this "Shlemiel the painter" behavior. Difference lists are another direct solution for this, but not many languages have them. He notes that, "Lua offers a facility, table.concat, to alleviate this problem; but it still bites programmers on occasion.", but using table.concat for large strings is both 1) one of the first things mentioned about working with strings in PiL (including explaining why doing appends naively is quadratic), and 2) incredibly common, so it's really not an issue in practice. In my experience, having immutable and interned strings is usually a net win, even if they're a second data type (Lisp and K call them symbols, Erlang and Prolog call them atoms, etc.). Lua merges string, atoms, and raw byte arrays into the same type (albeit with a cute trick for large strings), but it also has the C API as an easy escape hatch.