Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Little languages are the future of programming

chreke.com

Post reply on HN
Print view View original

201–210 of 216 posts

Re: Little languages are the future of programming

#201

Post by williamcotton »

origin_path wrote: post #200
williamcotton wrote: post #173

Earlier quoted context omitted.

Proper debugging, syntax highlighting, language servers, security audits. These are things that engineers in the real world expect a language to have, and each little language would have to reinvent each of them. I don’t always see this as the case and this might be a very fruitful area for research. What I mean is, much like how we have tools like bison, antlr, and the k framework, I could easily see this notion ext…

It is a fruitful area for research! Truffle is an example of the sort of framework you mean. Implement a parser+interpreter using Truffle and you get JIT compilation, GC, debugging, profiling and more stuff for free on top of the JVM.

Thank you for introducing me to Truffle! Off to write some DSLs I go!

Re: Little languages are the future of programming

#202

Post by Abishek_Muthian »

girvo wrote: post #194
AlotOfReading wrote: post #168

Earlier quoted context omitted.

CMake is pretty simple internally. Every "keyword" is a function call. Every function call is implemented as a class. The simplest way to hijack it would be to have a function that calls out to your external interpreter/tool with the state you want. I could see doing that in a couple of ways: * Add a builtin command [1] that takes a string or filename and calls the interpreter with any additional data you want to pas…

Champion! That’s exactly what I’ve been looking for haha I’m trying to remove the need for external commands to compile Nim when used with ESP-IDF for embedded firmware development, which is dependent on CMake. Going to take a crack at this today :)

Have you replaced writing C code for ESP with writing Nim and compiling it to C instead?

Re: Little languages are the future of programming

#203

Post by girvo »

Abishek_Muthian wrote: post #202
girvo wrote: post #194

Earlier quoted context omitted.

Champion! That’s exactly what I’ve been looking for haha I’m trying to remove the need for external commands to compile Nim when used with ESP-IDF for embedded firmware development, which is dependent on CMake. Going to take a crack at this today :)

Have you replaced writing C code for ESP with writing Nim and compiling it to C instead?

That’s exactly what we’re doing, yeah. --compileOnly gets pretty far, and I’d love to remove the need for having to run that compilation step separately before CMake builds the firmware from the generated C sources

Re: Little languages are the future of programming

#204

Post by Abishek_Muthian »

girvo wrote: post #203
Abishek_Muthian wrote: post #202

Earlier quoted context omitted.

Have you replaced writing C code for ESP with writing Nim and compiling it to C instead?

That’s exactly what we’re doing, yeah. --compileOnly gets pretty far, and I’d love to remove the need for having to run that compilation step separately before CMake builds the firmware from the generated C sources

Excellent, I've been hearing good things about Nim. I'm eager to try it out soon for a embedded project.

Re: Little languages are the future of programming

#205

Post by girvo »

Abishek_Muthian wrote: post #204
girvo wrote: post #203

Earlier quoted context omitted.

That’s exactly what we’re doing, yeah. --compileOnly gets pretty far, and I’d love to remove the need for having to run that compilation step separately before CMake builds the firmware from the generated C sources

Excellent, I've been hearing good things about Nim. I'm eager to try it out soon for a embedded project.

You'll find me (and some others) in the #embedded channel on Nim's Discord/Matrix if you have questions!

Re: Little languages are the future of programming

#206

Post by Abishek_Muthian »

girvo wrote: post #205
Abishek_Muthian wrote: post #204

Earlier quoted context omitted.

Excellent, I've been hearing good things about Nim. I'm eager to try it out soon for a embedded project.

You'll find me (and some others) in the #embedded channel on Nim's Discord/Matrix if you have questions!

Yay! Thank you.

Re: Little languages are the future of programming

#208

Post by [deleted] »

packetlost wrote: post #159
Verdex wrote: post #133

Earlier quoted context omitted.

> Every API is itself a "little language" I came to this conclusion early in my career. It went something like this: A - "To do this, just create this object, fill in these properties, and call these methods." B - "Okay, I did that, but it crashed." A - "Yeah, it's because you set the properties in the wrong order. This property relies on this other property under the hood. Set them in this order." B - "Still crashes…

DSLs and API are fundamentally the same thing, they're making decisions for the user so they can be sped up and reduce cognitive load. The only difference is the manner in which it's expressed. It turns out functions and interfaces are a pretty good way to express... most things you want to do in a program. Lisp acknowledges this and runs with it. IMO we need a language (or library?) that forces builders of an API to…

[deleted]

Re: Little languages are the future of programming

#209

Post by sargstuff »

packetlost wrote: post #159
Verdex wrote: post #133

Earlier quoted context omitted.

> Every API is itself a "little language" I came to this conclusion early in my career. It went something like this: A - "To do this, just create this object, fill in these properties, and call these methods." B - "Okay, I did that, but it crashed." A - "Yeah, it's because you set the properties in the wrong order. This property relies on this other property under the hood. Set them in this order." B - "Still crashes…

DSLs and API are fundamentally the same thing, they're making decisions for the user so they can be sped up and reduce cognitive load. The only difference is the manner in which it's expressed. It turns out functions and interfaces are a pretty good way to express... most things you want to do in a program. Lisp acknowledges this and runs with it. IMO we need a language (or library?) that forces builders of an API to…

> "IMO we need a language (or library?) that forces builders of an API to make incorrect behavior hard or impossible." ...

Think that would over complicate the electrical off switch.

Re: Little languages are the future of programming

#210

Post by sargstuff »

cies wrote: post #85
BiteCode_dev wrote: post #64

Earlier quoted context omitted.

Indeed. That's why we have languages with functions now, because people didn't want to manually do a register dance in assembly. That's why we have name spaces, because naming conventions only take you so far. That's why we have map and filter (or equivalent) because that's what most loops are doing anyway. Generation after generation, we discover that we all use common abstractions. We name them design patterns, the…

> Small languages either become big, or are replaced by things that are big, for the same reason most people prefer a car to a horse to go shopping. So why are shell languages still around? Why are they not replaced by C#, C++, Java or another big (=general purpose) language? I find your horse->car comparison more akin to the sh->bash->zsh transition. Zsh is not as small as sh, but still it is in the small league is…

gawk compiled via webassembly to allow for running in browser allows 'modern' gui input / output beyond the command line interface while still retaining the ability to be just a cli program.
Post reply on HN