Scripting languages of the future | Hacker News Reader

Scripting languages of the future

jntrnr.com

95 pointsslyall69 comments

Tossing my hat in for Passerine [1]. Gorgeous ML inspired syntax. Written in Rust, and I suspect scripting Rust libraries is in the cards.

Dreaming here: Lua is a fantastic scripting language, but the Rust FFI isn’t as ergonomic as it could be. Enter Luster [2], which is basically LuaJIT rewritten in Rust.

Embedding a scripting language in a Rust application gives you tons of power (e.g. scripting Rust structs from Lua [3]), and setting this up isn’t terribly difficult.

[1]: https://github.com/vrtbl/passerine

[2]: https://github.com/kyren/luster

[3]: https://git.sr.ht/~ioiojo/kiwi

Sadly, Luster project is either on hold or completely abandoned. I tried to use it, it's interesting concept but right now of no use at all.

For anyone interested in languages written in Rust, here’s a list: https://github.com/alilleybrinker/langs-in-rust

> Tossing my hat in for Passerine [1]. Gorgeous ML inspired syntax.

I work on Passerine, cool to see the language mentioned in the wild, glad you like it!

> Written in Rust, and I suspect scripting Rust libraries is in the cards.

We have a rudimentary FFI to Rust already in place. We're also working on a proc macro lib for creating high-level bindings to Rust types/functions/crates (currently unreleased). Also working on an algebraic-effect-based system-injection engine, which will replace the FFI in the 0.10.0 or 0.11.0 release :)

Don't get too focused on "scripting". making one today and you learn quickly, that scripting/compiled is blurred. Eventually, both will borrow a little of the other to be more performant or useful.

---

I'm building on the side one (https://tablam.org) that is focused in the "crud" kind of apps and exist a lot of low-hanging fruit there. Simple stuff like making the paradigm relational/array from the start, support for decimals (and money and quantities?), in-built auto-vectorization (that comes almost for free when adding a bit of array languages) and a lot of other stuff I can't even explored yet.

Current scripting languages are not there yet in ergonomic or features to the kind of apps we actually do (ie: The popular ones, you bet niche experiments like mine are there on way or another).

---

And the challenge is even harder today!. In the article is mentioned better support for IDEs, that is more thought that I have expected!. This requiere a more sophisticate parsing pipeline and not much experience there around...

Also: Concurrency/parallelims. I don't think exist a truly nice ergonomic there. Sure, async/await is a little better, but none of the things I have experienced (with exception of SQL and magic) is something I could give to a "scripting user". You still need a complicated understanding of this, plus how express that in code.

Plus: Performance. Is possible to build very fast "scripting" languages! But is VERY hard to be fast across many workloads :(

And is terrible, because the kind of developers don't use them (C/c++ cough) will complain LOUDLY how terrible them are, and how you must not use them, when certain workload is not as optimal!

> scripting/compiled is blurred

“scripting” is an application domain, and a scripting language is one focussed on that domain (and, yes, its a domain with blurry boundaries.)

“interpreted/compiled” is a (blurred, sure) implementation distinction.

scripting languages tend to be interpreted, but talking about scripting vs. compiled is conflating two different axes of description.

I like the "application domain" angle. It fits well...

Aren't scripting languages normally JIT:ed nowadays?

Js has been for years but I thought both Python, PHP and Ruby were working in that direction. That sounds like all the major ones to me.

Not all, and some "JITs" are not of the "make assembler" version. You can "JIT" on top of your own bytecode. Or not have a bytecode and compile to lambdas...

That's cool. Reminds me a little of Perl6 (now called Raku), but you use English syntax instead of all the operators and hyperoperators and stuff.

The author seems to basically be describing Dart 1, which wasn't actually all that successful. It was a dynamic language with optional typing and it excluded some of the hard to optimize parts of e.g. Ruby, JavaScript or Python. Whether it wasn't successful because of technical reasons or other reasons is perhaps hard to untangle, but the philosophy seemed very close to what this post argues for. Dart moved away from that though and went for static and sound typing instead with Dart 2 and seems to have carved out more of a niche that way.

The type inference of Dart 2 pretty much gets out of your way. Dart is very much a joy to use.

For scripting, a shout out to Dart CLI:

https://pub.dev/packages/dcli

Another language that comes to mind is Groovy. Types are optional, but when used, they are checked at runtime, or compile time with `@TypeChecked` or `@CompileStatic`.

Groovy is absolutely phenomenal for scripting. Optionally typed, has the entire Java ecosystem of libraries available (with no extra download or build files neccessary), very good IDE support, mature, extremely rich common library, great performance.

I've built entire prototypes in Groovy at amazing speeds and then gradually replaced individual files with Java/Kotlin code and made sure the entire thing still worked. When I had grabbed everything of value I copied the resulting Java/Kotlin files to the real codebase and deleted the prototype. I could've left them in Groovy, too, as it is quite performant enough, alas customers preferred Java/Kotlin.

It truly baffles me why Dart never picked up(ignoring flutter since it's in it's core). It is magnitudes better thought out than js, it is consistent and it comes with a ton of features baked into it by design(package management, statically typed, null safety, built-in linter and so on, all of which are available but as afterthoughts in js).

The main issue was that it was seen as Google pushing a language that people would have to support forever that wasn't really that much better than JavaScript.

That argument turned out to be more or less nonsense - if supporting language features forever is really an issue why have so many features been added to JavaScript?

But even so I think it was probably a good thing it didn't become a web standard because Dart has become way way better than it ever could have been had it been standardised.

Modern Dart is great. The problem now is that so is modern Typescript. Especially if you use it via Deno - in a lot of ways it is better than Dart.

I really like Dart and I wish it was more popular but I think it's too late for it to have any hope of beating Typescript.

Having watched the videos about Roc [1], I can't wait to get my hands on that language. It's similar to Elm, but not restricted to the front end.

[1]: https://www.roc-lang.org/

Exactly the same experience. "Elm on the server" was on my dream list before choosing Elm over Typescript, but Roc seems to be so much more. Very exciting!

Some of the OP's observations are why I wrote Empirical [1].

- I wanted static types that felt dynamic, which meant being able to infer types from a file as long as the file path can be determined at compile time.

- I wanted Dataframes to be a first-class container since the high-level of abstraction leads to great performance when doing analytics.

Therefore, I created a language with statically typed Dataframes. Empirical can infer a CSV's type at compile time, namely because it performs compile-time function evaluation automatically. The result is a language that runs easily in a REPL but can be used for long-running scripts without worrying about common programming errors.

[1] https://www.empirical-soft.com

I sometimes wonder to myself: what programming challenges would come up in something like the starship Enterprise (any of them) and what new language constructs (if any) would be required to address them?

What challenges have you come up with?

I think there will need to be work with things that essentially are what we think of as speculative execution today. This is because I’m sure there will be need to interact with considerably more systems, threads, messages, instructions whatever in the scope of an interstellar starship.

And no doubt some advances will be necessary in terms of AI to handle the calculations. I don’t know what those calculations are, but I’m sure they’re difficult :)

I think about the voice interface to the various computers. Really complex interactions. Always on. Rapidly changing contexts. Historic conversations. Different languages.

I’m sure storage is an issue. Something to do with compression algorithms. And decompression. Probably encryption and security.

Challenges in redundancy might be hardware or materials problems.

Most of them are hard for me to even articulate plainly :)

I would read a whole wall of text of these .

Thanks for answering!

In star trek they just tell the computer what they want to do in a very high level way like "computer, can you average the natural disaster data on Proxima 5's moon"? There is no file handles to open a .CSV file and find the right column and so forth.

How would you program such a computer and what challenges would the engineers face while working on this system?

A sophisticated AI-powered UI maps your voice commands to an execution graph composed of assorted php functions, single-purpose node packages, and sandboxed excel worksheet cells. Generations of engineers have devoted themselves to rewriting it all in one of several incompatible versions of hyperrust.

Well, this is Star Trek here where they can go faster than the speed of light, go back in time, and completely disassemble a person molecule by molecule and build them back up somewhere else (transporter). So I assume it works in some similarly hyper advanced way that would seem like magic to us.

That's not the point of the question.

I was just clarifying the GP comment

> I sometimes wonder to myself: what programming challenges would come up in something like the starship Enterprise (any of them) and what new language constructs (if any) would be required to address them?

The point of the question is to imagine that you are part of the team building this system. What sort of programming techniques would you be using? Is it going to be Python? Modern C++? Probably none of these things as they are incredibly inadequate for such a system.

Ah, I couldn't quite tell. I've asked myself something similar.

If done today I think it's more than one technology. The missions critical stuff could maybe be Ada? The AI stuff maybe logical programming based like Prolog? I assume there's a big database in there.

The way things are done today, such a system would implode before it reaches anywhere near a usable state.

The federation is post scarcity though. You only work on what you're interested though, so unless the Klingons/Borg/Romulans are threatening an all out war, I bet you could take things slow and make sure it's done right.

I guess Wolfram Alpha is the closest we have so far. They have written about the challenges.

https://www.wolframalpha.com/

The history of scripting languages is that they were really just a total joy for many C or C++ programmers that were tired of all the minutiae and ritual involved with those languages. Many picked one up, usually Perl or to a lesser extent at the time, Python, and enjoyed the heck out of either of them for web development, and scripting out file or text processing tasks.

That origin has really been lost, and people went on to give scripting languages a life of their own.

For me C++ is C#, and while I generally try to apply this language everywhere, my Perl equivalent would probably be Powershell. For some it might be C++ and Ruby, or Rust and Python.

I think there's enough work to be done in this field that there's going to be room for plenty of Python, Javascript, and other scripting language codebases.

New languages are all going to look pretty similar to what came before, because those raised on them are going to borrow elements that they're familiar with. Just like for me how the ideal programming language is or would look a lot like C#. As long as a language fits your technical needs on maintenance and performance grounds, and has the abstractions and keywords to properly express your ideas, it really doesn't matter what it looks like.

If .NET AOT experience had been a proper one, instead of just NGEN, and there wasn't so much politics between WinDev and DevDiv, I bet we would be enjoying it much more on Windows, but so is life, we get COM toys to wrap ourselves to call from .NET instead.

I guess they are just helping us to keep our C++ skills up to date. /s

Also, I would think a mention of Julia would have happened in the tunability section.

You could literally just use F# for scripting.

Not optionally typed but global type inference is arguably better anyway.

Ah scripting languages..

All the code has to be revriten every few years when a new language version and a new language of the week becomes popular, and the code written in Perl in 1994 still works.

Perl isn't a scripting language? At one point it was surely the canonical example.

My Python 2.7 code still runs in Python 2.7 so I'm a little unclear on your point in general.

I think they were criticizing rewrites such as Perl > Python or Python 2 > Python 3 as happening too often. Python 2.7 still runs but it’s not officially supported and will be harder to maintain.

I was just saying (technically making fun of) that everything except perl gets rewritten every few years :)

Not for want of trying! Perl is the granddaddy of the ill advised big rewrite ;)

I still have a perl book from 1994 (perl 5.0), and scripts written from the 90s to now, that still work without any issues, even on modern distros :)

That's not the point I was making. I was alluding to the Perl 6 story.

Thought Deno would be mentioned in the article. It's a language I want to try use more especially since it seems like TS with a nice built-in CLI tool and deploy ability.

> Thought Deno would be mentioned in the article. It's a language

Its not, though, its a JS/TS runtime. JS and TS are the languages, not Deno.

For me the two Achilles's heels of JavaScript performance are the lack of easy parallelism and creating new objects in instances where they could mutate existing ones.

These could be solved with a sufficiently smart JIT. but the task is not a trivial one.

    var data = [[2,3],[4,5],[6,7],[8,9]];
    
    data = data.map(([a,b])=>{let l = Math.hypot(a,b); return [a/l,b/l];});

In instances like this it should be possible for a JIT to modify data in place without allocating any new objects. Similarly should data be large enough A JIT could process the transformation on multiple cores.

A reference counting Garbage collector would have an edge. Alternatively a language could crafted to provide more context for the JIT to do it's work. Having a clear distinction between mutable and immutable and being able to specify that functions are pure. These would assist a great deal.

You might find https://www.microsoft.com/en-us/research/uploads/prod/2020/1... interesting; not a JIT, but lets you get a similar optimization.

There's a proposal for immutable records and tuples: https://github.com/tc39/proposal-record-tuple

Theoretically they would use structural sharing for their implementation which should reduce the overhead of creating a whole new array of objects like that

I believe koka has done a bunch of work making re-use happen automatically. Some really interesting ideas in there.

So scripting languages of the future are pretty much programming languages. Stallman was right once again: https://vanderburg.org/old_pages/Tcl/war/0000.html

Surely you mean the programming languages of the future are scripting languages? Written the other way around doesn't make sense.

I think this doesn't quite grapple with the idea of what "The Future" is. Remember that we were supposed to have flying cars in the 1980's, because that's what "The Future" was to people in the 1950's/60's. The problem was that everybody was still thinking in terms of personal vehicles you could drive around, and not flight patterns, traffic control, navigation, propulsion, training, fuel, the expenses of development and production. I think our scripting languages will be basically the same for the near future, if only for the fact that "hand-crafted software" sounds like the development of cars before Henry Ford.

The scripting languages of the future I see more in things like Unreal Blueprints.

Meanwhile webdevs reinvent things from 40 years ago and struggle to build 2D form apps.

> The scripting languages of the future I see more in things like Unreal Blueprints.

A lot of people have an aversion for anything visual programming. Usually when someone mentions Blueprints (here or on r/gamedev on reddit) I see a whole slew of replies talking about how bad it is, how nobody makes any real things with it[1] and how visual programming is terrible. Of course, they're all programmers who forget that textual programming isn't for everyone and that visual languages are extremely successful in other fields (especially for artists and musicians).

I'm a programmer with ~20 years of textual language programming under my belt, but I spent a few months with Max/MSP and personally, I loved it. I'm a very visual thinker, I often think on paper or whiteboards with boxes and lines and I found that when using Max, I could skip this thinking step and go directly to code. Sure, its not for everyone, but for me, it was a very pleasant experience.

Yes, Max isn't a good replacement for a general purpose programming language and Blueprints apparently also has its warts, but they are extremely useful and successful and I do agree that we will see more like this in the future. I do feel that a good general purpose visual language could be created[2] Even Blender is moving that direction with its "nodes everywhere" thing.

[1] Despite projects like this being written entirely in Blueprints: https://www.youtube.com/c/RaymondCripps Also the Bloodborne PS1 demake: https://www.youtube.com/channel/UCaxcBWED_UhcjhoG7nUeUoA

[2] At the time, my big complaints with Max were lack of general purpose data structures (and reference types allowing you to build stuff like trees yourself -- although you could write C/C++ extensions and presumably create such things there), no tools for unit testing etc, afaik its added a bunch of data structures since so maybe its a lot closer now?

ReScript is also a nice language. It's a bit less verbose and more sound than TypeScript.

But TypeScript is good enough for me right now. It's like writing JavaScript without the constant need to keep everything type related in my head at all times.

The JavaScript syntax is a hard spot, having spent time with the visually lighter (maybe?) Python these years.

The gradual typing is onto something, as it lets us migrate from the quick-n-dirty "science project" up to a non-trivial codebase.

IDEs seem like a "maybe". We want to generate code gracefully as text files.

Yet, I haven't seen a language include real amounts of Unicode in its syntax. With an IDE to enter/render more expressive characters, we could see code that is more explanatory at a glance (short of a full APL experience).

> Yet, I haven't seen a language include real amounts of Unicode in its syntax.

Raku does in terms of built-in operators (but all of them also have ASCII n-gram names), which aren't quite syntax (because Raku is a language where operators are not syntax but identifiers.) Agda uses Unicode fairly freely (again, for built-in identifiers, not syntax per se.)

Let's not forget interoperability. Scripting languages are nice because you can throw some stuff together on the fly. Therefore you need either a rich standard library or a package ecosystem. With some languages you grow that in time, but I bet you could cheat and interoperate with a different language's packages. Call me lazy but I don't want to use a scripting language where I have to write my own server, json parser, JWT encoder, SQLite interface...

> What TypeScript showed is that you could join together the idea of a flexible lightweight (and optional!) type system onto an existing programming language, and do so successfully.

> The question then is - what if you created a programming language from the start to have this kind of support? No need for transpilers, while also having stronger engine integration and maybe even better runtime errors?

You mean like Python 3?

PHP might be a better example. Really great gradual type system that is much simpler than TS. You also get runtime errors based on types. And since 8.1 we finally got proper Enums.

Now if only something could be done about its schizophrenic standard library and built-in functions.

Things are done about them in cases where people feel there is strong reason to do so. It just that breaking backwards compatibility might not be worth it many cases.

Personally I never understood the complaint. The standard library is pretty decent and well documented. Sure there is lots of historical cruft and inconsistencies but I would be way more annoyed if it got changed.

While I agree wrt backwards compatibility, some sort of per-file way to disable the crufty parts so they don't accidentally sneak into new code might be nice.

This would be good enough for me.

This talks a bunch about the "good run" of current scripting languages, including for example JavaScript.

But JavaScript, as an actual scripting language, has been pretty primitive. It is only now starting to become a real candidate for actual scripting. There's imo crufty not very great options like shelljs[1]. But by adding a tagged-template string for system() for calling things, and a little bit of standard library, the recent ZX has made JS a much more interesting & competent scripting language[2].

I like the idea of the topic, exploring it. But the author feels off in a number of places.

> What TypeScript showed is that you could join together the idea of a flexible lightweight (and optional!) type system onto an existing programming language, and do so successfully. . . .The question then is - what if you created a programming language from the start to have this kind of support?

Personally I just don't think languages matter very much. They're very similar, by & large. They have different tooling, packaging, somewhat different looks/feels for executing code, and their standard libraries are different. But TypeScript is popular & fast at least 90% because it is JS, because it works with JS things. Arguing that we should try to recreate TypeScript apart from JS sounds like a mind blowing waste of time. Also, Deno has good integrated TypeScript support.

On the topic of easy parallelism, JavaScript promises are imo quite easy to stitch together & use & quite available.

One of the main issues I see with easy-parallelism is that it's too easy: there's too many cases for uncontrolled parallelism. Throwing tarn.js or other worker-pools at problems seems all too common. But one is still left stitching together each pool/stage of work. I'd like to see SEDA[3] like architectures emerge, and perhaps get added to something like ZX standard library.

[1] https://github.com/shelljs/shelljs

[2] https://github.com/google/zx

[3] https://en.wikipedia.org/wiki/Staged_event-driven_architectu...

I’d love to see a version of python where bash was completely legal, and it could be easily mixed together for the ultimate shell scripting language with backwards compatibility. I’d call it pash.

The closest would be xonsh: https://xon.sh/

Pash was an open-source third-party PowerShell implementation for Linux. Now that the original PowerShell has been open source and available on Linux for some time now, the real risk of the name collision is probably low.

Reply on news.ycombinator.com