
The Wren Programming Language - api
https://github.com/munificent/wren
======
vvanders
This note on benchmarks/performance is a gem:

> LuaJIT is run with the JIT disabled (i.e. in bytecode interpreter mode)
> since I want to support platforms where JIT-compilation is disallowed.
> LuaJIT with the JIT enabled is much faster than all of the other languages
> benchmarked, including Wren, because Mike Pall is a robot from the future.

Looks like a nice embeddedable language.

~~~
tzs
I'm not an expert on this, but offhand I don't see anything fundamentally
different between the capabilities of Lua and the capabilities of Python,
Perl, Ruby, JavaScript, and other widespread scripting languages.

So why isn't there a PythonJIT, PerlJIY, RubyJIT, etc., comparable to LuaJIT?

~~~
riffraff
I think mostly because of missing a Mike Pall :)

Effectively though, Ruby/Perl are just much larger languages. E.g. ruby
has/had at least 5 different ways of controlling flow in a block between
throw/catch, next/break, raise/rescue, return/implicit-return and callcc. 99%
of the code uses the same small subset, but if you want to support "Ruby" you
need to implement all of those.

Likewise, Perl has maybe simple semantics underneat, but the sheer amount of
syntax-level elements is insane, also because of stratified version changes.
e.g. did you know that declaring a variable with "local" instead of "my" makes
it behave like a lisp-ish dynamic variable? I am fairly sure that does not
exist in Lua.

As for python, there is PyPy, but I think the retrospective view on Unladen
Swallow has some good points, basically: lack of enough interest from devs,
lack of enough interest from users.

[http://qinsb.blogspot.hu/2011/03/unladen-swallow-
retrospecti...](http://qinsb.blogspot.hu/2011/03/unladen-swallow-
retrospective.html)

~~~
oblio
Python also had Dropbox’s Pyston, that mostly failed:

[https://blog.pyston.org/](https://blog.pyston.org/)

------
jph
Wren is a gorgeous accomplishment. The speed gains are thanks to careful
design, such as emphasizing static definitions of classes, private functions,
constant slots, and computed jumps.

If anyone asks you "what does good code look like", Wren is a great example of
thoughtful tradeoffs and excellent explanations.

~~~
munificent
Thank you! <3

------
camgunz
This is from Bob Nystrom who's also behind Crafting Interpreters [1] and is a
general PL geek.

[1]: [http://craftinginterpreters.com/](http://craftinginterpreters.com/)

~~~
willtim
Unfortunately, Java is a poor choice to implement a programming language with
and there's nothing about implementing static typing in this book. I honestly
believe that most folks would be better off reading SICP or similar. What is
needed is a book that can make more modern ideas (and more modern languages)
accessible to industry.

~~~
msangi
The book is more about explaining how things work and showing how they're
implemented in a simple way. With this premise I think Java is a fair choice
because almost everyone knows it. If you're writing a book where you're
showing every single line of code of the implementation not having to explain
the programming language used is a huge benefit.

Regarding type checking, I believe it wouldn't be too hard to add it to the
language itself, but it would increase the page count of an already long book.

All things considered I think the book does a good job of explaining the
concepts in a very accessible way without handwaving any detail.

------
arthursilva
I understand the benefits of a single numeric type, but a type that doesn't
support full 64 bits is just painful. It makes documentation smaller and
benchmarks look good but often becomes a problem in real usages.

~~~
skybrian
Wren does support 64 bit _floats_. For 64 bit ints, I find it's most awkward
for interop with other languages, such as when using protobufs. If you control
both ends, you can avoid this.

------
api
Found this while looking for good embeddable languages and it looks almost too
good to be true: fast, relatively modern, secure, potentially concurrent,
lightweight, ... seems like it's got everything but a pony.

~~~
skybrian
Well, the one thing Wren is missing is static types. But then it probably
wouldn't be small anymore.

~~~
stevedonovan
Not necessarily. The _compiler_ would become larger, but the VM would not.
(I'm assuming that the VM can be decoupled from the compiler like Lua for
restricted environments).

Statically-typed 'scripting' is a very interesting niche - e.g Lily. Not to
underestimate the amount of thinking needed to devise a type system which is
sufficiently powerful to be (a) correct (for some value of 'correct') and (b)
as expressive as dynamic typing.

~~~
munificent
> The compiler would become larger, but the VM would not.

That's true in theory. But, in practice, if you ask your users to deal with
the cognitive load of static types, they (reasonably) start expecting the
performance of static types in return. At that point, you're doing a
statically-typed VM, which is quite a bit more complex than a dynamically-
typed one, I believe.

> (a) correct (for some value of 'correct') and (b) as expressive as dynamic
> typing.

Right. This is the big one, in my opinion. You can design a type system that's
simple, sound, and expressive. But you only get to pick two of those
adjectives. Today, because programmers are delightfully spoiled by a wealth of
nice, expressive type systems, I think they won't settle for simple and sound.

Dart tried simple and expressive, but the lack of soundness made tooling
_much_ harder and really confused users who felt like they were being
sufficiently penitent in their type annotations but still got punished for the
sins of unsoundness anyway — type failures that were only caught at runtime.

So I think if you're designing a type system for a language today, you end up
pushed pretty hard towards "sound + expressive", but now you're talking about
a really complex beast.

~~~
benhoyt
> Today, because programmers are delightfully spoiled by a wealth of nice,
> expressive type systems, I think they won't settle for simple and sound.

To me that basically describes Go's type system. Very simple, allowing my
brain to grok it, and part of what allows for Go's fast compile times. I'm not
entirely sure what's meant by "sound", however. Safe? What kind of safe?

------
SlowRobotAhead
I had considered it for embedding on an ARM micro for C code to be able to
download and run test scripts.

Abandoned because it seemed like a dead project with no official or community
support.

It’s suprisingly difficult to get a Turing complete scripting language for
micros that doesn’t take up 75k rom.

I’ll take another look, but for the most part I don’t know who has the time to
gamble on unknowns like this for anything but hobby.

~~~
api
GitHub seems active.

Lack of a big community can be explained by the language's role as a domain
specific embedded language and it simplicity.

------
tonyg
Previous discussion:

[https://news.ycombinator.com/item?id=8826060](https://news.ycombinator.com/item?id=8826060)

[https://news.ycombinator.com/item?id=11611661](https://news.ycombinator.com/item?id=11611661)

------
wodenokoto
the language manual is simple, easy to understand and very informative.

I am impressed!

[http://wren.io/syntax.html](http://wren.io/syntax.html)

