I haven't tried it, but there is Janet (https://janet-lang.org/) that seems pretty well suited for building small scripts. It was submitted a few times recently here on HN.
I use it to connect to my chess server! I play on freechess.org and xboard is my client for it, but I launch it from an emacs shell that becomes my console to interact with freechess. I also added some elisp commands so private chats have their own buffers.
There was a discussion on array programming languages here recently where someone proudly showed off a K language solution to a simple problem, stating that the K solution was efficient because it could solve it in 1.2 microseconds. I used Rust to solve it in 5.5 nanoseconds, which is nearly 200x faster. Both used "brute force" with no cleverness, but there's "bad" brute force and "good" brute force.
I've had a similar experience at university while using Haskell. It's a very elegant lazy pure functional language, but it's glacially slow. The natural, low-friction path is very inefficient. The efficient path is unidiomatic and verbose.
I hear people making similar observations about F# also. It's fast to program in, but if you also need performance then it is no better than more mainstream languages -- in fact worse in some ways because you're "going against the grain".
I think that the nuance here was perfectly obvious, if not explicit, to everyone who wasn't busy burying it under a pile of whataboutism.
I would also say that I wouldn't be at all surprised if idiomatic Python is actually quite a bit faster than idiomatic Haskell in some interesting use cases. Which does not at all mean that the opposite is true. There are always interesting cases that make good fodder for "what about" comments, but getting carried away with them doesn't really make for particularly edifying discussion. Just mentally append "in my experience" to everyone's comments and move on.
> I would also say that I wouldn't be at all surprised if idiomatic Python is actually quite a bit faster than idiomatic Haskell in some interesting use cases. Which does not at all mean that the opposite is true.
I'd be utterly amazed. Haskell is orders of magnitude faster than Python for "typical" code (having to do a hash lookup for every method invocation ends up being really costly). It's not a slow language by any reasonable definition. And the fact that you're suggesting it is suggests that the nuances are not at all obvious.
(Not trying to hate on Python - performance is a lot less important than most people think it is - just trying to put Haskell's performance characteristics in a familiar context)
It's not that much of a nuance, TBH. It's just that Python has largely become a high-level language for gluing together libraries that are mostly written in much faster AOT-compiled languages such as C, C++, Fortran, or even Cython. For example, I prefer to stick with Python for a lot of the number crunching things that I do because, while you certainly can beat numpy's performance in other languages, in practice it turns out that doing so is generally more work than it's worth. Especially if you're using the Intel distribution of numpy.
So, yeah, it's true, you do a hash lookup for every Python method invocation, and also you've got to worry about dynamic type checks for all the dynamically typed references. But the practical density of method invocations and dynamic type checks can be surprisingly low for a lot of Python's more interesting use cases.
Haskell doesn't treat all lists as linked lists. It treats linked lists as linked lists. It also has Seq (finger trees), boxed and unboxed arrays and various streaming libraries.
> I've had a similar experience at university while using Haskell. It's a very elegant lazy pure functional language, but it's glacially slow. The natural, low-friction path is very inefficient. The efficient path is unidiomatic and verbose.
Well, if you run a Haskell program on a "C-Machine" of course a comparable program in a "C-Language" will be faster — as it don't need to bridge any gap in execution semantics.
The point is: Mostly all modern computers are "C-Machines". Modern CPUs go even a long way to simulate a "PDP-7 like computer" to the outside world, even they're working internally quite different. (The most effective optimizations like cache hierarchies, pipelineing, out-of-order execution, JIT compilation to native instructions [CPU internal "micro-ops"], and some more magic are "hidden away"; they're "transparent" to programmers and actually often not even accessible by them). So not only there's nothing than "C-Machines", those "C-Machines" are even highly optimized to most efficiently execute "C-Languages", but nothing else! If you want to feed in something that's not a "C-Language" you have to first translate it to one. That transformation will almost always make your program less efficient than writing it (by hand) in a "C-Language" directly. That's obvious.
On the other hand running Haskell on a "Haskell-Machine"¹ is actually quite efficient. (I think depending on the problem to solve it even outperforms a "C-Machine" by some factor; don't remember the details, would need to look through the papers to be sure…). On such a machine an idiomatic C or Rust program would be "glacially slow", of course, for the same reason as the other way around: The need to adapt execution semantics before such "no-native" programs could be run will obviously make the "translated" programs much slower compared to programs build in languages much closer to the execution semantics provided by the machines hardware implemented evaluator.
That said, I understand why we can't have dedicated hardware evaluators for all kind of (significantly different) languages. Developing and optimizing hardware is just to expensive and takes to much time. At least if you'd like to compete on the status quo.
But I could imagine for the future some kind of high level "meta language" targeting FPGAs which could be compiled down to efficient hardware-based evaluators for programs written in it. Maybe this could even end the predominance of "C-Languages" when it comes to efficient software? Actually the inherently serial command-stream semantics of "C-Languages" aren't well fitted to the parallel data-flow hardware architectures we're using at the core now since some time (where we even do a lot of gymnastics to hide the true nature of the metal by "emulating a PDP-7" to the outside world — as that's what "C-Languages" are build for and expect as their runtime).
To add to the topic of the submission: Are there any HW implementations of APLs? Maybe on GPUs? (As this seems a good fit for array processing languages).
You can make it! There is already lishogi.org for shogi (Japanese chess) and lidraughts.org for draughts. They took the code for lichess and tweaked it for their respective games.
Thank you for pointing out this out and making it click in my head that what they're doing could be done for other games.
I've got one or two game designs of my own that I could probably make something like this with, but it didn't really click I could use this code as a reference until then.
Will probably be a while before that happens, if it happens, but I'll put down your email just in case.
I do have other game designs I'm working on and a different version of the game I'm thinking of that is aimed at a bit more of a casual audience (even putting Twitch streamer friendly things in there), but I do hope to get to a point where there can be some real data on how to play well in the game, and it is basically a board game anyway (I have a physical prototype for the board game version made, but it's never been published).
I use wget (on the command line) to save a webpage. It has an option to save recursively all the links on the page as well, or only the links from a certain ___domain.
The flight itself should take about an hour, but with the trip to and from the airports, the luggage and passport controls and the need to arrive before the plane takes off, I would say the travel time between two offices in Amsterdam and London will be at least two hours if not three.
Plenty of people in London have pushing two hour commutes anyway, and City Airport is so quick they don't bother with priority queues. I've stepped out of a Taxi at City and been sitting down in the plane in under 15 minutes, although I wouldn't count on it. If you miss one and have to wait for the next plane the bar does pretty good Eggs Benedict.
That's not my life anymore and I don't actually know the Schiphol end myself, but that's what it's like.
I remember back in 2016 when I woke up after a party, at 2 PM, and my flight was at 3:00. It was going to be my first time flying out of the City, so I immediately assumed I wouldn't even be able to check in my luggage on time. Then I remembered it was a last-minute business airport after all, so checked the check-in cut-off times on BA website and couldn't believe my eyes: 20 minutes before the flight. Managed to pack, get a cab from Dalston, get to the airport, check-in and still had time for a quick "breakfast". The smoothest experience ever, barring the hangover. And the views are astonishing!
