Live data from Hacker News

The Monkey Programming Language

monkeylang.org

11–20 of 37 posts

Re: The Monkey Programming Language

#11
post #5

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…

Have you seen Wren?

https://github.com/wren-lang/wren

Re: The Monkey Programming Language

#14
post #11
post #5

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…

Have you seen Wren? https://github.com/wren-lang/wren

Wren is small, and the language is aesthetically appealing, but it's small in the specific way of its C implementation being a small SLOC while implementing nifty features, not "anyone could study this codebase and port it to a new environment". It relies extensively on the preprocessor.

(I speak from experience.)

Re: The Monkey Programming Language

#15
post #8
post #5

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…

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

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.

Re: The Monkey Programming Language

#16
post #10

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

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

Username checks out

Re: The Monkey Programming Language

#19
post #10

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

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

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/

Re: The Monkey Programming Language

#20
post #17

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

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

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.

Post reply on HN