
The Monkey Programming Language - azhenley
https://monkeylang.org/
======
fernly
This is remarkably similar to the Lox language and the book Crafting
Interpreters[1] by Bob Nystrom, which I only just read about on HN like two
days ago. (Edit: one major difference is, Nystrom's book is free.)

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

~~~
pseudoramble
I had the same thought while reading through this site! I've started working
through Crafting Interpreters a few weeks ago. I have been loving it. I'll
generally read a chapter one evening, and then write the code from it the next
day and re-read bits of the chapter to clarify the code. It's been really
enjoyable.

One thing I want to do next is to try and implement the tree-walking
interpreter again in another language (probably F# in my case) and maybe share
it if I finished it up. This site is basically a concrete version of that
small thought in my head.

Funny how things work out!

------
robbrit
Bit of bait-and-switch here: thought I was learning about a new programming
language when it's more a pitch for books about making programming languages.
Creative advertising on the part of the author though!

~~~
ptrott2017
A little bit = but personally happy to see a website for the language - there
are a lot of implementations out there now ,so its good to have a source
point.

If you have not read the books they are a really good practical introductions
to building interpreters and compilers.

------
adamson
Thorsten Ball very recently gave an interview on Software Engineering Radio
[1] where he discusses the books and the language and his thinking on each.

[1] [https://www.se-radio.net/2019/05/365-thorsten-ball-on-
buildi...](https://www.se-radio.net/2019/05/365-thorsten-ball-on-building-an-
interpreter/)

------
Crinus
I thought this was Mark Sibly's Monkey language.

[1] [http://monkeycoder.co.nz/](http://monkeycoder.co.nz/)

------
jedisct1
I initially thought it was about the Monkey C language:
[https://developer.garmin.com/connect-
iq/monkey-c/](https://developer.garmin.com/connect-iq/monkey-c/)

~~~
qrohlf
As a Monkey C developer, I'd say Monkey C is a better example of how _not_ to
design a programming language.

~~~
asark
Making it OO on a system with so little memory available to apps was an
especially weird basic decision, I thought. There were cases where memory use
was unavoidably bloated for no good reason, and meanwhile there wasn't enough
space to actually _do_ any architecture-astronaut OO stuff.

I wished the whole time they'd just given me a somewhat locked-down C, and I'm
only a C-dabbler so that's not a preference I'd have due to great familiarity
or anything.

It was overall somewhat more unpleasant, but less weird, than writing code for
Roku. Most of the Roku weirdness was just because they had some new very-much-
halfassed XML programming system you had to use for new apps at the time,
which forced you to define public interfaces for objects in XML for no good
reason while doing the actual work in Brightscript, which isn't gonna win any
language design awards _ever_ but is at least usable. Plus it's obscure so
figuring all that out was tons of _fun_.

------
sideb0ard
currently working my way through this book, and implementing it in C++ - very
good book! I'm really enjoying it.

------
mntmoss
I was looking for this and didn't realize it. I'm designing a fantasy console
and wanted to include a modern-syntax, small, interpreted language that has
many independent implementations - a new BASIC or Pascal. Lua comes close to
this but attention is really centered around the PUC-Rio and LuaJIT
implementations and not on being easily reimplemented, and every "classic"
option one might think of(including Lisps and Forths) falls a bit outside
today's mainstream.

I may be getting the book soon...

~~~
snazz
I would argue for a Lisp. If you’re asking the user to use a language they’re
not familiar with, it might as well be one that will expand their horizons,
despite the potentially offputting syntax. It would be really cool if you
added a key that switched from s-expressions to Sweet expressions[0] (and
vice-versa). Forth is painful to use for anything more than a toy and no
matter what language you choose it would be awesome to see a live-updating
(graphical?) REPL.

[0] [https://readable.sourceforge.io](https://readable.sourceforge.io)

~~~
mntmoss
Expanding PL horizons is not a goal for this project. The goal for this
specific usercode layer(of which there are four: WASM bytecode, the I/O memory
map, the lower level operating system language, and the higher level
interpreted language) is to achieve a mix of sustainability and familiarity. A
language defined by a book explaining its implementation, while also being in
the "looks-like-an-Algol" ballpark, falls very close to that mark.

If you want a Lisp, it's possible, just rewrite the OS layer.

------
chrismsimpson
Much more thought needs to be given to the AST and the public API(s). See
here:
[https://github.com/chrismsimpson/Meta](https://github.com/chrismsimpson/Meta).

If it's going to be 'the final system' there really has to be legion
compelling reason to switch. I just don't see it.

Also, and I honestly mean no offence, but do we really want to call it Monkey?
It's a tad childish. We're going to be asking Governments, Banks, public
services etc. to being using this thing.

~~~
Quarrelsome
You're telling me you wouldn't use NSSM? Its awesome.

~~~
chrismsimpson
No. For the non tech literate, this will become a fundamental issue of safety.

~~~
Quarrelsome
Non tech literate shouldn't be making these choices. This is why they'll miss
out on Cockroach DB, eh?

~~~
chrismsimpson
Umm.. says who? You?

------
yokohummer7
This is another language whose syntax is similar to Rust's. I wonder why the
author chose it, in spite of its Go heritage.

~~~
zero_iq
Also yet another language called 'Monkey'.

There's already Monkey C used to develop for Garmin devices, and the
Monkey/MonkeyX/Monkey2 family by Mark Sibly (of Amiga Blitz Basic fame).

~~~
adamredwoods
I originally thought this post was related to Mark Sibly's trans-compiler,
which I used in the past and enjoyed quite a bit:
[http://monkeycoder.co.nz/](http://monkeycoder.co.nz/)

------
wildduck
Seems very similar to ES6

------
_bxg1
It seems every new C-like has Rust's expressive if/else and implicit returns.
And why not? They're strict improvements on the syntax. Makes me wonder why
they didn't become prevalent many years ago.

~~~
hybrids
Both of these things were invented by Lisp. The reason C didn't include them
was because C and its ancestors was designed to be easy to write a parser for
(well, "relatively" anyway, it's not exactly as barebones as sexps) and to be
usable with a preprocessor macro system, so you end up with a language
designed with a lot of syntactic cruft (braces, semicolons, ternaries, etc.)
meant as aids to compiler authors.

~~~
lifthrasiir
> you end up with a language designed with a lot of syntactic cruft (braces,
> semicolons, ternaries, etc.) meant as aids to compiler authors.

Many of those are not just for the easiness of implementation but also for the
quality of partial parsing, frequently required for today's compilers. I do
agree that they are not intentionally designed in that way.

------
ngcc_hk
Clojure version, any?

