This is an incredible labor of love and historical record. The technical articles alone have a depth that goes further than the documentation for any living project that I know of. I can only imagine how much work has gone into this. He gives a talk on his disassembly work here, which deserves a wider audience: https://www.youtube.com/watch?v=orP_0aQo-Pc
Lox must have the highest ratio of (implementations : production usage) of any language on the planet. And I mean that as the highest praise -- it's proven a fantastic teaching language, and your book is infectious at encouraging others to jump in and follow along in various different languages.
I've also found the exercise of implementing Lox in another language as highly instructive in learning how to write idiomatic code in that language. I continue to learn more about the best way to express patterns as I work on my own implementation. I'd recommend the journey to any professional developer for this side-benefit alone.
> Lox must have the highest ratio of (implementations :
> production usage) of any language on the planet.
It's probably up there, for sure! But I'd guess that there are a million toy Lisp implementations, and more people are interested in writing a FORTH interpreter than actually using one in production. So I'd guess if we tried to get statistics it wouldn't be at the top.
Though there's probably a similar claim to be made for the Monkey-language from Torsten Bell, via his books on compilers and interpreters.
On a more serious note, have you thought about trying to aim lightning at the same spot again and write another book about implementing something most programmers take for granted?
I've definitely thought about writing a third book. I don't know if it would be about "something most programmers take for granted". I'm more interested in writing about whatever happens to excite me the most at that time.
I may be projecting, but I feel like the kind of person to get excited about crafting interpreters wod also get excited about crafting databases or OSes.
Apple | Sr Product Manager, Swift & SwiftUI | Cupertino | Onsite
Hiring manager here. Looking for a skilled product manager to focus on developer technologies like Swift and app frameworks like SwiftUI. To be successful at this role, you'll have a mixture of hands-on skills as a developer as well as proven experience as a storyteller and communicator. You'll work with other Apple engineers to define the features of Apple’s next generation of tools, and then launch these products at WWDC.
This is my dream job! I love SwiftUI and I love pitching. I've raised about $100k for past startups through pitch competitions, but I'm really in love with the technical side of product development.I just submitted my application through the link, my name is Ben.
I don't want to spray too much on a public forum, but I'd love to tell you about what I've worked on in the past.
Nice idea. But looks like this is unreliable, with some indeterminate cut-off point after which it stops working. I created 100 paragraphs of Lorem ipsum which I pasted into the textbox. It didn't show any error, but when I pasted the URL into a different window, the textbox just shows 'undefined'.
We're working on improving its support for other use cases, with work to better support embedded[1], server[2], and AI[3] use cases, along with Linux[4] and Windows[5] support.
We're also putting a lot of energy into improving support for these scenarios in Visual Studio Code [6].
Would love to hear more about scenarios folk are looking at, as well as specific gaps that are blocking you adopting Swift for non-Apple platforms. We're building a roadmap now and would love to make sure our work items are comprehensive.
Something I'd love to see is being able to use the VSCode extension for iOS / macOS development. I wouldn't expect all the bells and whistles of Xcode obviously (e.g. previews, run integration). However I'd love to use VSCode because I prefer their tradeoffs to Xcodes.
The advantage for Swift would be that potentially more developers use the VSCode extension which would hopefully improve the quality and incentivise more of them to maybe contribute to it.
If it's already possible then maybe a section in the readme on how to achieve this? (e.g. how to open an iOS project folder and get completions for Apple's frameworks).
What works quite well for iOS/macOS apps is breaking the project into a barebones Xcode project plus a Swift package that contains all of the code. SPM projects work well with VSCode and you get full auto-complete support with the official Swift plugin.
Thanks for the suggestion, I'll give that a try. Obviously this will not work with large existing codebases; but for new projects I'll try how well it works.
We already have a NeoVim plugin [0] that makes replacing Xcode somewhat possible. It's not perfect and requires that you have Xcode around for certain scenarios but I have been using it as my daily driver for the last month.
I think you would only need xcode-build-server [1] in order to get autocompletion in VSCode.
Overall it should provide a better experience than Objective-C even with GNUStep, never managed to offer without the NeXT or Apple's frameworks and IDE tooling.
So far, every time I play a bit with it, the experience doesn't seem much better, as naturally most packages assume Apple platforms, and VSCode isn't XCode.
Has the issue with manually reaching out for OS APIs instead of Foundation already been fully sorted out? Having samples directly referring to Glib and similar, instead of standard Swift, wasn't that interesting.
Also the lldb issue with Python bindings not being found seems to still exist, even on the container images.
However, I also acknowledge that many things seem to have improved, so there are also quite a few positives.
I think if you could honestly use Swift outside of Xcode it would already be a massive improvement. I know you "can", but you really can't. It's painful. The experience would have to be at least 1-to-1 in terms of developer experience. When I use cargo/rust-analyzer in vscode, I feel at home and empowered. When I try to write Swift in vscode, I feel handicapped
SwiftUI is an incredibly powerful paradigm. It feels like the future compared to most GUI programming today. It is also possibly the most easily seen and best-known value of Swift today. Enabling and empowering the community to create similar abstractions outside of Mac OS/iOS would go a long way to making the language more commonly used, but I understand that's a responsibility that doesn't fall squarely on the Swift team. Case in point, the adwaita-swift and the swift-everywhere-windows-interop projects. The first looks fine (although it is just a "Counter" sample project) but the latter looks DOA/unviable. As a dev, I wouldn't even consider the latter and adwaita has the disadvantage of not being cross platform
Look at the sheer number of tools, languages and frameworks trying to solve the modern day "write once, run anywhere" of declarative guis. Tauri/Dioxus, React Native, Flutter, iced-rs (my personal favorite)... the list goes on. There's a real need here that Swift could help solve without forcing people into JavaScript or Rust. The former being too browser-focused (for better or worse, but I argue worse) and the latter having too steep a learning curve
I feel like a lot of the Swift-outside-of-Apple effort has been on server/embedded work, but in those domains, why wouldn't I choose Python/Node+JS or C/C++/Rust which already have a strong foothold, respectively? That's a much harder battle to fight from an adoption perspective IMHO
I’d love if Swift supported easy cross compilation in the same way that Zig does. The fact that I can just download Zig and everything will just work without tinkering is nice
In Dart you use class hierarchies instead, rather than enums (which in Dart are way to define a compile time constant set of values). So the original example becomes:
sealed class MySomething<T> {
}
final class One extends MySomething<Never> {
}
final class Two extends MySomething<Never> {
final Child child;
Two(this.child);
}
final class Three<T> extends MySomething<T> {
final T value;
Three(this.value);
}
final class Four extends MySomething<Never> {
final int Function() callback;
Four(this.callback);
}
And then you can exhaustively switch over values of MySomething:
The declaration of a sealed family is considerably more verbose than Swift - and I really would like[1] us to optimized things for the case when people often declare such families. Macros and a primary constructors will likely provide reprieve from this verbosity.
But importantly it composes well with Dart's OOPy nature to achieve things which are not possible in Swift: you can mix and match pattern matching and classical virtual dispatch as you see fit. This, for example, means you can attach different virtual behavior to every member of the sealed class family.
When I canceled Prime a couple of years ago, I thought our family would really miss it. In practice, we have barely noticed. I don't trust Amazon any more for electronics; the books I ordered more recently were badly packaged and often dog-eared; and we now spend less time idly browsing Amazon for purchases we don't need, which is good all round.
Everyone has different needs, but I'd encourage more people to try canceling it. The world would not be harmed from a little less Amazon shopping.
There's an irony that this comment is posted on HackerNews, where the entire page of comments is hosted in a big <table> for layout. Not sure if this is good or bad!
Agree. She was a polarizing figure in the UK, but the newly-installed Conservative government of the early 80s certainly moved fast to respond to both the threat and the opportunity of the coming information revolution. In partnership with the BBC, they instituted the Computer Literacy Project which comprised education, television programs, subsidized computers for schools, and of course the BBC Microcomputer.
reply