I find this paper false/misleading. They just translated one algorithm in many languages, without using the language constructs or specificities to make the algorithm decent performant wise.

Also it doesn’t mean anything, as you aren’t just running your code. You are compiling/transpiling it, testing it, deploying it… and all those operations consume even more energy.

I’d argue that C/C++ projects use the most energy in term of testing due to the quantity of bugs it can present, and the amount of CPU time needed just to compile your 10-20k lines program. Just my 2 cents

Thanks for the idea, I’ll try to add a comparison page soon!

The vertical alignement is now fixed, I got lucky with bootstrap ; it looks way nicer, thanks!

Also, just to check, do you have a time limit set for the Playground so that people do not over-tax your system?

I double-checked, and it seems my timeout command was incorrect. I set it up again (with additional testing), and it now properly kills the container(s) after 20 seconds.

Thanks for your comment!

That’s a tough question, because it often boils down to preferences. I think a beginner developer or even someone fed up with the complexity of modern languages could be interested in the language, as it is very small but still more than usable. Only 9 keywords, no hidden meaning, everything follows the same rules : open a paren, then the first thing is a function call, the rest are arguments. I think the « lisps have too many parentheses » is a false problem only used by trolls. I won’t say that you have to understand the flow or fall into the matrix to use it and avoid the parens, it’s more about having a consistent coding style so that you don’t have to care about the closing parentheses. Plus with a modern editor, parentheses groups have different colors and are easy to match, you can navigate to the starting / closing paren with a keybind (% in vim, command/ctrl M in jetbrains IDE).

I’m no frontend dev, so I battle a lot with it so it displays how I want ; I tried with flex to center vertically the « getting started » section, will have to try again.

Yes, there is a time, cpu and memory limit to the playground, no worries! I started the playground about a year ago but only just recently managed to compile to wasm, I’ll see in the future if I can swap the docker integration for it.

First of all, the language is lisp inspired. ArkScript has s-expressions and code as data via its macros, its reads the same (left to right, prefix notation).

Keywords wise, we are not the same, which is a small but striking difference when comparing them side by side.

ArkScript has no classes nor structures, and no quoting/quasiquoting.

AFAICT both ArkScript and Common Lisp (a big lisp contender) have lexical scoping, so no real difference here.

ArkScript has strong dynamic typing too, like many other lisp.

The big advantage I would say ArkScript has, is its embedded capabilities. You can very easily use it in a project, as its C++ API has been designed for this.