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.
> 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!
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.
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).
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`.
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.
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?
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.
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
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.
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.
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.
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 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.
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?
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.
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.
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.
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.
[+] [-] atweiden|4 years ago|reply
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
[+] [-] slightknack|4 years ago|reply
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 :)
[+] [-] xvilka|4 years ago|reply
[+] [-] alilleybrinker|4 years ago|reply
[+] [-] unknown|4 years ago|reply
[deleted]
[+] [-] mamcx|4 years ago|reply
---
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!
[+] [-] dragonwriter|4 years ago|reply
“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.
[+] [-] 7thaccount|4 years ago|reply
[+] [-] hencq|4 years ago|reply
[+] [-] axegon_|4 years ago|reply
[+] [-] wstrange|4 years ago|reply
For scripting, a shout out to Dart CLI:
https://pub.dev/packages/dcli
[+] [-] brabel|4 years ago|reply
[+] [-] davidkunz|4 years ago|reply
[1]: https://www.roc-lang.org/
[+] [-] vivab0rg|4 years ago|reply
[+] [-] chrisaycock|4 years ago|reply
- 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
[+] [-] theshadowknows|4 years ago|reply
[+] [-] 7thaccount|4 years ago|reply
[+] [-] jbergens|4 years ago|reply
https://www.wolframalpha.com/
[+] [-] pvinis|4 years ago|reply
[+] [-] BuckRogers|4 years ago|reply
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.
[+] [-] pjmlp|4 years ago|reply
I guess they are just helping us to keep our C++ skills up to date. /s
[+] [-] LasEspuelas|4 years ago|reply
[+] [-] james777|4 years ago|reply
[+] [-] pharmakom|4 years ago|reply
[+] [-] ajsnigrutin|4 years ago|reply
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.
[+] [-] andybak|4 years ago|reply
My Python 2.7 code still runs in Python 2.7 so I'm a little unclear on your point in general.
[+] [-] nikivi|4 years ago|reply
[+] [-] dragonwriter|4 years ago|reply
Its not, though, its a JS/TS runtime. JS and TS are the languages, not Deno.
[+] [-] Lerc|4 years ago|reply
These could be solved with a sufficiently smart JIT. but the task is not a trivial one.
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.
[+] [-] richeyryan|4 years ago|reply
Theoretically they would use structural sharing for their implementation which should reduce the overhead of creating a whole new array of objects like that
[+] [-] remexre|4 years ago|reply
[+] [-] mst|4 years ago|reply
[+] [-] bitwize|4 years ago|reply
[+] [-] pwdisswordfish8|4 years ago|reply
[+] [-] 0xbadcafebee|4 years ago|reply
[+] [-] arcanon|4 years ago|reply
Meanwhile webdevs reinvent things from 40 years ago and struggle to build 2D form apps.
[+] [-] k__|4 years ago|reply
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.
[+] [-] smitty1e|4 years ago|reply
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).
[+] [-] dragonwriter|4 years ago|reply
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.)
[+] [-] hardwaregeek|4 years ago|reply
[+] [-] civilized|4 years ago|reply
> 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?
[+] [-] cardanome|4 years ago|reply
[+] [-] rektide|4 years ago|reply
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...
[+] [-] azinman2|4 years ago|reply
[+] [-] BiteCode_dev|4 years ago|reply
[+] [-] sidpatil|4 years ago|reply