Live data from Hacker News

Pocketlang

github.com

31–40 of 63 posts

Re: Pocketlang

#31
post #19
post #2

This is pretty neat. I’ve been tinkering with Lua on ARM, so I’m curious to know how it compares to LuaJIT.

Like regular Lua, Pocketlang uses a bytecode interpreter. AFAIK LuaJIT is still the only small language implementation that provides a JIT compiler and not just an interpreter. I don’t know why that is - maybe there just isn’t much of a niche for a lightweight JIT compiler.

Probably because a JIT conflicts with the goal of most embedded languages to be small and simple. LuaJIT does manage to be relatively small, but it (meaning the implementation) certainly isn't simple.

Re: Pocketlang

#32

Earlier quoted context omitted.

Sounds like https://dhall-lang.org/

It's close. I also want something that is going to be syntactically familiar to humble programmers (my target users, myself, etc); Dhall's syntax is clearly Haskell-adjacent which is an obstacle for many of us. I'll probably just roll my own using a Rust-like syntax.

If you don't mind, what is it about the syntax of Dhall that you find hard?

In my experience, Haskell's syntax is much simpler than the syntax of any of the popular languages. The "hard" parts of Haskell come with all the abstractions people make (esp. how it encodes side effects), the laziness, and the language extensions. Dhall has none of those.

Re: Pocketlang

#34
Stuff like this is so cool.

I have this desire to create a (maybe domain-specific / not Turing) programming language. I have some use cases involving constraint satisfaction but basically it's a rock'n roll dream kind of thing for me.

Re: Pocketlang

#35

Earlier quoted context omitted.

Sounds like https://dhall-lang.org/

It's close. I also want something that is going to be syntactically familiar to humble programmers (my target users, myself, etc); Dhall's syntax is clearly Haskell-adjacent which is an obstacle for many of us. I'll probably just roll my own using a Rust-like syntax.

Would your users be ok with something like this? Python syntax, rust concepts and transpiles to rust (and 6 other languages)

https://twitter.com/arundsharma/status/1407229297392115713

Re: Pocketlang

#36

Earlier quoted context omitted.

It's close. I also want something that is going to be syntactically familiar to humble programmers (my target users, myself, etc); Dhall's syntax is clearly Haskell-adjacent which is an obstacle for many of us. I'll probably just roll my own using a Rust-like syntax.

Would your users be ok with something like this? Python syntax, rust concepts and transpiles to rust (and 6 other languages) https://twitter.com/arundsharma/status/1407229297392115713

All of your comments are just spamming this library that nobody uses.

Re: Pocketlang

#37

Stuff like this is so cool. I have this desire to create a (maybe domain-specific / not Turing) programming language. I have some use cases involving constraint satisfaction but basically it's a rock'n roll dream kind of thing for me.

Do write it. It is easier then it sounds and quite pleasant programming task.

Re: Pocketlang

#38
post #15

> Pocketlang is a [...] functional language written in C. What features make this a functional language?

That's always a fun subject for a late night argument at the pub. When I was in school (1990s), simply having first-class procedures was good enough for most people to consider a language functional. I'd assume that's roughly the definition being used here. But you go back to 20 years before that, and it wasn't totally unheard of to see higher-order functions in procedural languages (such as Algol 68) and object-orie…

I thought Miranda/Haskell were much more in the vein of Lisp/Lambda Calculus than Backus's ideas, which were more radical and not widely adopted to this day [1]. I always thought of Haskell as simply what Lisp would be if it had implemented a typed lambda calculus rather than an untyped one.

1: https://en.wikipedia.org/wiki/Function-level_programming

Re: Pocketlang

#39
post #32

Earlier quoted context omitted.

It's close. I also want something that is going to be syntactically familiar to humble programmers (my target users, myself, etc); Dhall's syntax is clearly Haskell-adjacent which is an obstacle for many of us. I'll probably just roll my own using a Rust-like syntax.

If you don't mind, what is it about the syntax of Dhall that you find hard? In my experience, Haskell's syntax is much simpler than the syntax of any of the popular languages. The "hard" parts of Haskell come with all the abstractions people make (esp. how it encodes side effects), the laziness, and the language extensions. Dhall has none of those.

It seems to be a very polarizing topic. People who like Haskell's syntax find it very readable, others don't. In my estimation, there are a lot more in the "others" category than in the Haskell category. Whether my target audience has trouble with Haskell syntax because of some inherent property of the syntax or merely because their background isn't in Haskell doesn't ultimately matter--the requirement is that my users can quickly be productive (minimal learning curve, etc).

To be very explicit, I'm dodging the question because it's ultimately subjective and people come out of the woodwork with the same predictable talking points ("syntax doesn't matter", "but it's VERY readable! look how few characters!") and I don't have the energy this morning.

Re: Pocketlang

#40

Earlier quoted context omitted.

It's close. I also want something that is going to be syntactically familiar to humble programmers (my target users, myself, etc); Dhall's syntax is clearly Haskell-adjacent which is an obstacle for many of us. I'll probably just roll my own using a Rust-like syntax.

Would your users be ok with something like this? Python syntax, rust concepts and transpiles to rust (and 6 other languages) https://twitter.com/arundsharma/status/1407229297392115713

The syntax seems generally fine (Python's type annotation syntax is shoe-horned to minimize changes to the parser--if you're allowing yourself to rewrite the parser, why not improve the type annotations? Indeed, why not stick to a more Rust-like syntax in general?). I would want the ability to restrict the standard library and builtins (no I/O) a la Lua. Also, if the type system involves a borrow checker, I'll pass (borrow checking is cool but it doesn't make sense in what is ultimately intended to be a configuration language).
Post reply on HN