Steel – An embeddable and extensible Scheme dialect • Hacker News Board

Re: Steel – An embeddable and extensible Scheme dialect

#111

Post by bitwize » Mon, Dec 04, 2023, 12:43 AM UTC

Jtsummers wrote: post #72

bitwize wrote: post #32

Earlier quoted context omitted.

Why would you want to do that? Lisp is dynamically typed and has a GC.

It's a joke that you seem to have missed. > We were not out to win over the Lisp programmers; we were after the C++ programmers. We managed to drag a lot of them about halfway to Lisp. Guy Steele on Java

I'm familiar with the Steele quote. The manner in which C++ programmers were "dragged halfway to Lisp" concerns primarily manual memory management and all the bugginess attending thereto (Java came out before the STL and smart pointers were widely adopted). Concerns about memory safety were a significant part of the impetus for developing Java in the first place. Steele was responding to complaints that he had turned his back on Lisp, by countering that he was instead bringing the C++ crowd closer to Lisp with a C++-like language that had Lisp-like memory management.

But the reason why Rust is such revolutionary computer science and, quite possibly, the most interesting thing to happen to PL design in decades is because with safe Rust you get all the memory-safety advantages of Java or Lisp, without a GC because the borrow checker statically guarantees object lifetimes. So Rust programmers don't need to be dragged halfway to Lisp the way C++ programmers were in the mid-90s, because Rust has the same memory-safety guarantees with none of the drawbacks of GC.

Re: Steel – An embeddable and extensible Scheme dialect

#112

Post by goku12 » Mon, Dec 04, 2023, 12:54 AM UTC

dboreham wrote: post #100

dkarras wrote: post #92

Earlier quoted context omitted.

used to be on the same camp. now I think I get it. the language is malleable. because it is homoiconic. so while developing software, you are simultaneously writing a domain specific language for your problem. because macros. in the end, if you like your craft, you end up with a "language" that is very suitable for solving the problem you have at hand, with very little noise. the downside is, probably most others wil…

Homoiconicity is a gimmick and it's a cult.

Homoiconicity is why Lisps have rich macros and legendary metaprogramming capabilities. You don't even have to deal with it yourself to feel its usefulness. Emacs use-package is an example.

Re: Steel – An embeddable and extensible Scheme dialect

#113

Post by zozbot234 » Mon, Dec 04, 2023, 12:55 AM UTC

bitwize wrote: post #111

Jtsummers wrote: post #72

Earlier quoted context omitted.

It's a joke that you seem to have missed. > We were not out to win over the Lisp programmers; we were after the C++ programmers. We managed to drag a lot of them about halfway to Lisp. Guy Steele on Java

I'm familiar with the Steele quote. The manner in which C++ programmers were "dragged halfway to Lisp" concerns primarily manual memory management and all the bugginess attending thereto (Java came out before the STL and smart pointers were widely adopted). Concerns about memory safety were a significant part of the impetus for developing Java in the first place. Steele was responding to complaints that he had turned…

> with safe Rust you get all the memory-safety advantages of Java or Lisp, without a GC

Safe Rust does not protect against memory/resource leaks when reference cycles are present. To avoid those, tracing GC is still needed - and most likely unavoidable in the general case. Note that avoiding reference cycles is a global concern that can't be localized to any single part of the program, so trying to ensure this statically is roughly as hard as proving that a random piece of C/C++ code does not corrupt memory.

You can of course stick to tree-like allocation patterns where object lifecycles nest cleanly, and that's what the borrow checker is all about. You can also use arenas/regions, and future Rust versions will hopefully make those easier to use.

Re: Steel – An embeddable and extensible Scheme dialect

#114

Post by ParetoOptimal » Mon, Dec 04, 2023, 12:57 AM UTC

schemescape wrote: post #109

NeutralForest wrote: post #89

Earlier quoted context omitted.

I would use Helix in the terminal if it supported Emacs keybindings tbh but I don't want to relearn another set of keybindings. Still I'd be interested in what it becomes.

Out of curiosity, if you’re familiar with Emacs, what’s your motivation for wanting to use Helix? Built-in LSP support?

I use it despite a very complete emaxs setup because:

- curiosity

- seeing if I'm missing anything

- haven't had time to get tree sitter stuff configured, and wanted to see how good it is

- see if I want to move back to meow from vanilla (tons of previous vim, evil experience)

Re: Steel – An embeddable and extensible Scheme dialect

#115

Post by adastra22 » Mon, Dec 04, 2023, 1:00 AM UTC

tmtvl wrote: post #88

adastra22 wrote: post #69

Earlier quoted context omitted.

I’ve written a large application in Lisp. Hated parentheses before, hate them even more now. It needlessly obscures code. Maybe it’s a personal issue, idk. But it’s not out of ignorance nor is code readability a trivial point.

Yeah it is a personal issue, there are people who really like Lisp syntax (I'm one of them). That doesn't mean anything bad, of course, some people like dark text on a light background, others light text on a dark background. Everyone is different and that's what makes the world so awesome. I see something like: some-var: I64 := a * b - c ^ d ^ e; ...and my brain gives out, while I find: (let ((some-var (- (* a b) (^…

How do you look at the latter and know the code structure? Are you counting parentheses? Or are you relying on conventions around white space indentation. If the latter, are you not concerned a misplaced parentheses might make the code different from it appears? There could be bugs not shown in the indentation.

Most lispers I know code in eMacs or other smart editors that provide auto code formatting and colored parens. But why not just make the indentation (or whatever that you really rely upon) the actual syntax, so there CANNOT be hidden bugs of that sort?

Edit: to expand on this, I think it is no coincidence that most lisps remain untyped to this day. Strong typing is about having the compiler enforce type rules so you the developer can’t fuck it up. Weak typing is more convenient, but ultimately a source of bugs. Lisp has, effectively, weak syntax. I don’t like weak syntax for the same reasons I don’t like weak typing.

Re: Steel – An embeddable and extensible Scheme dialect

#116

Post by mattparas » Mon, Dec 04, 2023, 1:04 AM UTC

SushiHippie wrote: post #75

Can someone explain these scheme and lisp languages to me? Every time I look at these languages, I can't grasp what you can use them for. And why one would use them. I always feel like I'm missing something. In the example scripts and code snippets, I can see that you can define functions, that you can use lists, mathematical operations, you can build some algorithms, you can print text, but it never goes further tha…

At least for me, there is a certain appeal in building the world. With scheme you get a very small set of functionality, but you use that to implement the rest of the language, and build abstractions on top of abstractions. Seeing how the whole system can be built from a small set of functionality is pretty cool, and also very satisfying. There is a talk from Andy Wingo, one of the maintainers of Guile, where he describes working on Guile as akin to tending to a garden, and I think its an apt comparison. Something about it feels very organic and personal, which is part of the appeal.

The syntax itself doesn't _really_ matter, it just makes it easy to do so - functions and syntax visually look the same, so it makes it easy to build.

Its not for everyone, but I think its worth exploring for a little bit. Similarly I think its worth really learning any language just a bit, if not to just expand your tool kit. The parenthesis do disappear at a certain point and you learn to read it, but if its not your thing that is fine.

Re: Steel – An embeddable and extensible Scheme dialect

#117

Post by adastra22 » Mon, Dec 04, 2023, 1:05 AM UTC

mtlmtlmtlmtl wrote: post #99

adastra22 wrote: post #69

Earlier quoted context omitted.

I’ve written a large application in Lisp. Hated parentheses before, hate them even more now. It needlessly obscures code. Maybe it’s a personal issue, idk. But it’s not out of ignorance nor is code readability a trivial point.

You're clearly the exception though. It's almost always just ignorance in my experience. That's why I used the word probably. I assume if someone asked you what you thought about Lisp, you'd have a lot more interesting stuff to say than just "ew, parentheses", right? That's my point, is all. As for readability, I don't think it's trivial at all. I just don't think syntax has all that much to do with it. It plays a ro…

No, the horrible syntax of lisp is pretty much all I have to say on it, honestly. I don’t care for lisp for the same reason I don’t care for perl: write-only languages are a bigger hinderence to software maintenance than whatever advantage might be obtained. And the advantages of lisp have long since been obtained by other languages.

Re: Steel – An embeddable and extensible Scheme dialect

#118

Post by duttakapil » Mon, Dec 04, 2023, 1:11 AM UTC

mattparas wrote: post #12

This is a surprise! Steel is my project, happy to answer any questions anyone might have

May I ask, what is your personal journey of learning to code? Did you also discover Lisp/Scheme through SICP? And what have you professionally used Scheme for?

I am currently going through SICP, and I am also interested in Rust, so this project is a great discovery! Maybe I can contribute to it also.

Re: Steel – An embeddable and extensible Scheme dialect

#119

Post by nikolay » Mon, Dec 04, 2023, 1:16 AM UTC

bobbyskelton41 wrote: post #64

nikolay wrote: post #48

Earlier quoted context omitted.

That's ridiculous!

I saw your comment on the thread. A. Most WebAssembly implementations are bigger than Helix itself. B. WebAssembly is immature. C. Lisp is perfectly fine. Even if you don't like it, it's not the end of the world if you have to use it to configure Helix.

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.

Re: Steel – An embeddable and extensible Scheme dialect

#120

Post by nikolay » Mon, Dec 04, 2023, 1:19 AM UTC

NeutralForest wrote: post #91

zozbot234 wrote: post #84

Earlier quoted context omitted.

Turing-completeness in a config file is an anti-pattern. Write an external program to generate the config file instead.

Why? Emacs has Emacs Lisp and Neovim has Lua, it's great to be able to configure, write plugins and helper functions, in the same language.

So, if I use an editor config off the Internet, I need to inspect it for malware, because it's code, not configuration? Yes, there are languages for configuration - Jsonnet, Starlark, Dhall, which are execution safe - unlike Lisp and Lua!