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

Steel – An embeddable and extensible Scheme dialect

github.com

Post reply on HN
Print view View original

181–190 of 192 posts

Re: Steel – An embeddable and extensible Scheme dialect

#181

Post by nikolay »

bobbyskelton41 wrote: post #157
nikolay wrote: post #119

Earlier quoted context omitted.

A. It's true that Wasmer is bigger, but even my phone has 16GB of RAM and 1TB of storage space. B. There are probably more computers running WebAssembly loads today than Lisp ones. C. Lisp is a mature language, almost too mature. I used it extensively in the '80s and it served me well then, but that was 40 years ago. At least have the decency to use a more modern language like Lua, which is what Neovim uses.

A. Sure, but it isn't sufficiently beneficial for the cost. B. WebAssembly is immature for developing a plugin system because of the lack of a sufficient ABI: https://github.com/WebAssembly/component-model C. There aren't any other languages that meet the criteria. Lua was a no-go from the start. The maintainers did not like the language, and it necessitated adding more C code to Helix which could complicate building…

A Lisp, a weird dialect of Lisp, is not better than Lua. Why use Rune [0]?!

[0]: https://rune-rs.github.io/

Re: Steel – An embeddable and extensible Scheme dialect

#182

Post by lostdog »

xigoi wrote: post #148
darthrupert wrote: post #141

Earlier quoted context omitted.

The things I'm looking for in language syntax these days are 1. That it's unambiguous enough that my editor can format it correctly every time (provided the code is correct, obviously). Indentation-based languages like Python fail this. 2. That its elements and keywords are distinct enough that my editor can apply colours on it. I sometimes feel that S-expression languages fail at this because of their small number o…

What is ambiguous about Python’s syntax?

    if a:
        print("foo")
    if b:
        print("bar")
Or wait, maybe the copy paste didn't work exactly right and "if b" was supposed to be inside "if a"

Re: Steel – An embeddable and extensible Scheme dialect

#183

Post by xigoi »

lostdog wrote: post #182
xigoi wrote: post #148

Earlier quoted context omitted.

What is ambiguous about Python’s syntax?

if a: print("foo") if b: print("bar") Or wait, maybe the copy paste didn't work exactly right and "if b" was supposed to be inside "if a"

That’s a problem with your editor, not with Python.

Re: Steel – An embeddable and extensible Scheme dialect

#184

Post by jerf »

klibertp wrote: post #163
goku12 wrote: post #153

Earlier quoted context omitted.

I'm also an Emacs evil user (neovim too). I think the kakoune editing model has the potential to surpass even the vim/evil model. Its default object-verb order makes it easy to preview and change selection before proceeding with the action. That's not possible with vim's normal mode. Vim does have the visual model. But then kakoune model also uses multiple cursors, making it more powerful. I really wanted to try kako…

> Sadly, multithreading is an afterthought for Emacs It is, but it's usable. I'm actually amazed that, even after three major versions, the built-in threading is not used by the community. Yes, the threads currently are not usable for number crunching in the background. And yes, there are bugs, and trying to do many things from the background thread doesn't work, sometimes in unexpected ways. You can still block the…

"Yes, the threads currently are not usable for number crunching in the background. And yes, there are bugs, and trying to do many things from the background thread doesn't work, sometimes in unexpected ways. You can still block the main thread from the background thread since some things block the event loop, no matter where they were started."

Many dynamic languages have bodged on threading over the past decade. (I don't think dynamic languages are intrinsically unthreadable or anything, but their interpreters were pretty deeply based on not having threads.) What that has shown is that 90%-effective threading is useless, and 99%-effective threading is superficially appealing but always, always blows up at any sort of scale.

You really need threads that don't come with all those caveats.

I expect it will get there, but another thing we've learned from previous efforts is that telling the community it's ready before it's ready causes "$LANGUAGE threading" searches to be filled with posts telling people how bad it is, even years and years after it has actually been fixed. It's probably a blessing in disguise it's not something the community is pervasively trying to use.

Re: Steel – An embeddable and extensible Scheme dialect

#185

Post by bobbyskelton41 »

nikolay wrote: post #181
bobbyskelton41 wrote: post #157

Earlier quoted context omitted.

A. Sure, but it isn't sufficiently beneficial for the cost. B. WebAssembly is immature for developing a plugin system because of the lack of a sufficient ABI: https://github.com/WebAssembly/component-model C. There aren't any other languages that meet the criteria. Lua was a no-go from the start. The maintainers did not like the language, and it necessitated adding more C code to Helix which could complicate building…

A Lisp, a weird dialect of Lisp, is not better than Lua. Why use Rune [0]?! [0]: https://rune-rs.github.io/

Rune is not mature and is developed by a handful of people. Please check the thread I linked, literally everything you could say has already been addressed.

Saying "X is better than Y" or "Why not Z?" is not constructive at all.

Re: Steel – An embeddable and extensible Scheme dialect

#186

Post by darthrupert »

xigoi wrote: post #183
lostdog wrote: post #182

Earlier quoted context omitted.

if a: print("foo") if b: print("bar") Or wait, maybe the copy paste didn't work exactly right and "if b" was supposed to be inside "if a"

That’s a problem with your editor, not with Python.

But it's what ambiguous about Python's syntax. And I can make it a bit worse:

    if a:
       print("foo")
     if b:
        print("bar")
This is not a huge problem, but problems with syntax never are (in non-joke relatively modern languages). But it's still something I prefer that languages fix in their syntax if I get to have a choice.

Re: Steel – An embeddable and extensible Scheme dialect

#187

Post by xigoi »

darthrupert wrote: post #186
xigoi wrote: post #183

Earlier quoted context omitted.

That’s a problem with your editor, not with Python.

But it's what ambiguous about Python's syntax. And I can make it a bit worse: if a: print("foo") if b: print("bar") This is not a huge problem, but problems with syntax never are (in non-joke relatively modern languages). But it's still something I prefer that languages fix in their syntax if I get to have a choice.

The example you just posted is a syntax error, as it should be. And I still don’t get what is ambiguous about the syntax, the specification clearly states how indentation corresponds to a syntax tree.

Re: Steel – An embeddable and extensible Scheme dialect

#188

Post by klibertp »

jerf wrote: post #184
klibertp wrote: post #163

Earlier quoted context omitted.

> Sadly, multithreading is an afterthought for Emacs It is, but it's usable. I'm actually amazed that, even after three major versions, the built-in threading is not used by the community. Yes, the threads currently are not usable for number crunching in the background. And yes, there are bugs, and trying to do many things from the background thread doesn't work, sometimes in unexpected ways. You can still block the…

"Yes, the threads currently are not usable for number crunching in the background. And yes, there are bugs, and trying to do many things from the background thread doesn't work, sometimes in unexpected ways. You can still block the main thread from the background thread since some things block the event loop, no matter where they were started." Many dynamic languages have bodged on threading over the past decade. (I…

Well, threading - shared-state parallelism, more precisely - is hard to do well, and retrofitting it into a program that wasn't designed with that kind of threading in mind is even more challenging. I don't think any popular languages solved this, save for Java. Especially in the recent versions, with the new virtual threads - as much as I dislike Java, I have to say they did an excellent job on this. Other languages and platforms (that I know of; what's the .NET story here?) are all shitshows to varying degrees, trying to catch up and failing over and over again.

I think the only sensible way to offer parallelism in Emacs is to exclude the "shared-state" part, the way Racket (places) and OCaml do it. I think Python also tries to do it with subinterpreters? Let another instance of the interpreter run in the same process and communicate via message passing. That's probably still a huge undertaking, but at least it seems more viable than going through the whole codebase and adding locks everywhere...

Still, the "threads" in Emacs, as incomplete and half-baked as they are, can be useful. And if nobody uses them, there's no incentive for the developers to improve them. So I think we need at least some early adopters if we want the threading support in Emacs to get better.

Re: Steel – An embeddable and extensible Scheme dialect

#189

Post by neonsunset »

klibertp wrote: post #188
jerf wrote: post #184

Earlier quoted context omitted.

"Yes, the threads currently are not usable for number crunching in the background. And yes, there are bugs, and trying to do many things from the background thread doesn't work, sometimes in unexpected ways. You can still block the main thread from the background thread since some things block the event loop, no matter where they were started." Many dynamic languages have bodged on threading over the past decade. (I…

Well, threading - shared-state parallelism, more precisely - is hard to do well, and retrofitting it into a program that wasn't designed with that kind of threading in mind is even more challenging. I don't think any popular languages solved this, save for Java. Especially in the recent versions, with the new virtual threads - as much as I dislike Java, I have to say they did an excellent job on this. Other languages…

On concurrency, Java is the last to the party. Many languages had solved it in various ways before:

- async/await camp with C# and F#, Swift, Rust, Python, TS/JS (yes, I know, event loop)

- Erlang/Elixir and BEAM family

- virtual threads and/or coroutines - Go, Java, Kotlin

Generally, I don't feel like in 2023 concurrency and parallelism are problematic areas anymore aside from existing aged stacks. From a perspective of mainly .NET ecosystem resident, it has been a shitshow outside of it for a long time indeed with many architectural choices throughout the industry paying for the Java sins (e.g. Kafka) and imposing limitations that seemed nonsensical and embarrassing even 7 years ago.

Re: Steel – An embeddable and extensible Scheme dialect

#190

Post by klibertp »

neonsunset wrote: post #189
klibertp wrote: post #188

Earlier quoted context omitted.

Well, threading - shared-state parallelism, more precisely - is hard to do well, and retrofitting it into a program that wasn't designed with that kind of threading in mind is even more challenging. I don't think any popular languages solved this, save for Java. Especially in the recent versions, with the new virtual threads - as much as I dislike Java, I have to say they did an excellent job on this. Other languages…

On concurrency, Java is the last to the party. Many languages had solved it in various ways before: - async/await camp with C# and F#, Swift, Rust, Python, TS/JS (yes, I know, event loop) - Erlang/Elixir and BEAM family - virtual threads and/or coroutines - Go, Java, Kotlin Generally, I don't feel like in 2023 concurrency and parallelism are problematic areas anymore aside from existing aged stacks. From a perspectiv…

We're talking about parallelism here, not concurrency. async/await solve concurrency, not parallelism (on their own). Kotlin coroutines solve parallelism only because they piggyback on Java threads. I'm not sure about Go, but it's probably M:N concurrency (so with parallelism) like what you get on the BEAM. Then again, on the BEAM you don't get to "share" anything (other than binaries, IIRC).

I'd say concurrency is largely a solved problem, yes; limited parallelism (e.g., with message passing) also mostly works. We don't need to worry about the "C10K problem" anymore. But shared (mutable) state parallelism is, I think, still far from solved - if it can ever be "solved", which is a pretty big assumption :)

Post reply on HN