timsneath

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.

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.

More details and application link at the link below: https://jobs.apple.com/en-us/details/200553741/product-manag...

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'.

Thank you for the compliment!

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.

[1] https://github.com/apple/swift-evolution/blob/main/visions/e...

[2] https://www.swift.org/blog/sswg-update-2024/

[3] https://www.swift.org/blog/mlx-swift/

[4] https://www.swift.org/blog/adwaita-swift/

[5] https://www.swift.org/blog/swift-everywhere-windows-interop/

[6] https://marketplace.visualstudio.com/items?itemName=sswg.swi...

I believe Dart has pattern matching, but not associated values of different types.

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.

For those who want to read more, there's a great archive site here: https://clp.bbcrewind.co.uk/history and an interesting book from MIT Press (https://mitpress.mit.edu/9780262034036/now-the-chips-are-dow...) which covers this period.

Conversely, we just ordered a Tesla Model Y yesterday for delivery within a month. Today they reached out to us to see if we'd like to take one from inventory this week. I literally paid the deposit using Apple Pay with TouchID on my MacBook. It was scary how easy it was.

You can attack an idea. I don't know why you think it assumes animus against the recipient.

If you haven’t seen them, Acorn Books in the UK have put out a lovely set of hardback reprints of some of the classic Melbourne House titles. Well worth a look: https://acornbooks.uk/retro-reprints/

Like many others before me, my occasional weekend hobby has revolved around writing a ZX Spectrum emulator as a way to better understand these primitive but fascinating machines: https://github.com/timsneath/cambridge. Nothing special, but a fun project nevertheless.

This is a lovely ode to the period in which I developed my love for computers. Although like many growing up east of the Atlantic Ocean, my computer of choice was the Sinclair ZX Spectrum. Without the budget to afford to buy much in the way of cassette-based professional software, like most I resorted to manually entering programs from magazines like Sinclair User[1] and Personal Computer World[2], which got me into the habit of reading others' code. When they were inevitably incorrectly entered, I was introduced to debugging techniques for the first time. After a while, I figured that I could write a computer program of my own; and not long after that, I realized I could submit my own program to a magazine and even earn money from it[3]! I don't think I would be working at Google now if it were not for this first-hand, somewhat unforgiving education I got in the 1980s.

That said, those who missed out on this era also missed out on quite how limited the available sources of information were. Without online services to consult, the primary source of information being trial and error, and one incorrect machine code instruction leading to loss of all data entered, progress was very slow going. A committed learner could certainly make far faster progress with a more modern environment.

For today's generation, I'm grateful for books like Charles Petzold's Code [4], which constructs a computer architecture from first principles. The joy is still there waiting to be found!

[1]: https://archive.org/details/sinclair-user-magazine-033/page/...

[2]: https://archive.org/details/PersonalComputerWorld1984-01/pag...

[3]: https://archive.org/details/sinclair-user-magazine-044/page/...

[4]: https://www.microsoftpressstore.com/store/code-the-hidden-la...

These are simply adorable. I want to make this my weekend project.

Does anyone have tips for this? What cardstock should I use? Is there a particular weight that is best suited for projects like this?

There are some good examples of why that's not sufficient in Russ' blog post, which is worth reading. They include performance regressions that may not be immediately visible, understanding cache utilization, and better optimizing the toolchain for real-world machine configurations. It's worth reading his article for a better understanding of the goals here:

https://research.swtch.com/telemetry-intro

(Disclosure: I work on developer tools at Google.)

There is a CLA, so that folk can attest that contributions are theirs, and that they're free to be used by others, and that everyone who uses Flutter can feel comfortable that there are no patent or IP rights reserved by contributors.

It's open source software, developed in the open under a permissive license. You don't have to work for Google to have contributor access or the right to approve others contributions. Google kindly sponsors a fair amount of infrastructure (testing labs, etc.) and pays for a lot of people to work on Flutter. If that doesn't meet your definition of "community", then fair enough -- but the spirit that we work under is that the "Flutter team" is everyone who contributes code.

We've got a guide here that covers some of these areas: https://github.com/flutter/flutter/blob/master/CONTRIBUTING....

For a lot of first-time contributors, improved documentation and added tests are a great way to dip toes into the water. We also have a 'good first contribution' tag on our issues log that might be a source of inspiration: https://github.com/flutter/flutter/issues?q=is%3Aopen+is%3Ai...

A good example of Flutter desktop is https://rive.app/downloads - curious on others' thoughts of how that compares to Electron or other choices that are out there.

Yes -- to be crystal clear, we're not targeting the DOM. We focus on use cases that can and should be expressed in a canvas. We prefer a WebGL canvas, but even what we refer to as our "HTML renderer" only emulates Flutter's canvas capabilities (e.g. layers).

If you are a web developer building with the canvas in mind, we aspire that Flutter is a useful tool. We encourage the use of one of the many other great frameworks out there (or no framework at all) if the DOM is the target. And we aspire to provide great interoperability and accessibility.

The web is bigger than documents. And that's why web standards are bigger than the Document Object Model. I'm sorry you see that as badmouthing the web, because it couldn't be further from the truth.

It's a little dispiriting to read a screed like this, because it doesn't represent the work we're doing. I think a slightly deeper evaluation beyond a skim-read of a Register article might be worthwhile before jumping to such strong conclusions.

In our talk, we explicitly say that today's web is the most amazing and pervasive platform ever built. And frameworks like Angular, React and vue.js serve the DOM-based model very well. Probably this will remain the vast majority of the web for the foreseeable future. But there are classes of apps like Rive (https://rive.app), Figma, or Google Sheets for that matter, that are hard to build on the web without using a technology like Canvas. I don't think that's "pushing pixels in people's faces" - it's simply using the right web standards for the job.

Canvas itself is a relatively low-level standard: it's good for drawing pixels. And so it might be useful to have a framework that enables animations and perhaps even some UI primitives here. Flutter's web work is an attempt at solving that problem, because we've already built a portable architecture for these capabilities. If you were building the next Figma or Rive, perhaps you'd see something useful in our open source toolkit. That's it. Nothing so nefarious as to be "deranged and anti-human".

I also can't let the accessibility comment go: that's a top priority for us, and we're very interested in reproducible issues there. It's been one of our biggest areas of investment to date.

Our early prototype demo (https://flutter-forward-demos.web.app) shows some examples of how we hope this will be integrated into a regular web page. (Disclaimer: this is built with our unstable branch, so may have some bugs.)

Disclosure: I work on Google's Flutter team.

We're using Flutter for plenty of apps internally. Just yesterday we showed off Google Classroom, which has just been rewritten using Flutter for both iOS and Android. Classroom also uses Flutter for the web-based practice sets. https://www.youtube.com/watch?v=JVJF_M9bgj4

(Disclosure: I work on the Flutter team.)

Obviously a tough week for everyone at Google. But we're looking forward to sharing our roadmap and plans at our Flutter Forward event later today: https://flutter.dev/events/flutter-forward#schedule

I'm a pedant, I know, but I can't deal with this being called B♭ (the enharmonic equivalent for A♯), instead of D♭ (the enharmonic equivalent of C♯). Is there another layer of the joke that I'm missing?

It seems that this is a common misperception for some reason.

There are certainly many charities that are ineffective at their mission, inefficient with their funds or working on a mission that few would consider worthwhile. (And there are also some great charities out there that are effective, efficient and important, such as https://givedirectly.org.)

But charities (of which non-profit foundations are a subclass) aren't a "tax dodge". Money that you give to a charity is untaxed, so you can claim a refund on income taxes you've already paid on that money. But you don't get new money that you haven't already earned from the IRS; every penny given is money that you already had, and the tax refund is purely of tax that is no longer due on that money.

It's possible to be cynical of the motives of some philanthropic gifts, but Gates (and others) aren't financially better off from their giving itself.

I don’t have canonical data to fall back on, but I suspect that DKIM and DMARC being set up are key to successful mail delivery these days, if you’re not using one of the biggest players like Gmail. I use Rackspace Mail for my personal domain (not the hosted Exchange variety) and with these two configured I’ve had no issues with mail delivery. But many mail hosting providers still don’t support DKIM: which is one reason I’m still relying on Rackspace despite all their broader woes.

Me too. It started a whole chain of events for me:

- I used the tutorial to write it in Dart (https://github.com/timsneath/dart_console/blob/main/example/...)

- I refactored the console pieces (raw mode, ANSI VT sequences) into a separate package (https://pub.dev/packages/dart_console)

- I wrote Windows interop code for the previously Unix-only parts of the editor

- I created a separate package for the Dart/Win32 interop pieces (https://pub.dev/packages/win32)

- I wound up growing and expanding this package to the full Win32 surface area

- Another OSS contributor took and extended my work to support the WinRT

Now there are tens of Dart packages that use the Windows interop work that all started with this little tutorial on a completely unrelated area. So thank you to the author!

Interestingly, that's exactly what is going on internally at the moment with Dart code, as we migrate the Google ecosystem to sound null safety, which was introduced in Dart 2 and will be the only mode in Dart 3. Adding a feature like sound null safety to a codebase the size of Google's is a large undertaking. It also brings a ton of benefit, both to the language itself and code that has migrated, since we can now provide guarantees around nullability that are not available in most other languages.

But all the tooling we built for that multi-million LOC migration is open source, and available to everyone as part of the core SDK (https://dart.dev/null-safety/migration-guide#migration-tool). It's sophisticated, migrates much code automatically, and provides a visual editor to help make decisions about other code. That should be evidence at least that we care about migration.

Every ecosystem goes through migrations at some point (Objective-C to Swift, Java to Kotlin, Win32 to UWP, etc.) Flutter isn't immune to that risk, but I don't think it's particular to Flutter either.

There's a lot here, so perhaps you'll forgive me for not responding point by point. But to the critique that we need to be more transparent, I just want to share that we've gone so far as to share our product strategy publicly: https://flutter.dev/go/strategy-2022

Modulo a few minor redactions, this is the entire document. I don't know of many other projects of our scale that has shared something like this. It's reasonable to have divergent opinions on whether we're successful or popular, or what that means about our developer base. But I hope you'll see that we're trying to be pretty transparent about what we're focused on. We're just trying to build something valuable and useful, and that benefits Google as well as the broader community.

(Disclosure: I lead PM/UX for Flutter & Dart.)

For sure, anything that I could say along the lines of "we're not shutting Flutter down" might be taken as having overtones of the Baghdad Bob meme. And indeed, why should you trust my word?

The reason you should feel confident to use Flutter is because it's strongly in our business interest to invest in it. Over 600,000 apps in the Play Store alone are already written using Flutter, to say nothing of the countless apps for iOS, Windows, macOS, Linux and web. The list includes big brands like Alibaba, BMW, eBay, and SHEIN. Neither Google as a whole, nor Android in particular would be better off if Flutter didn't continue to flourish.

Aside from that, there are thousands of engineers at Google who use Dart and Flutter internally to build a wide variety of apps. There are many millions of lines of code written that power everything from Ads to our internal CRM system. Google wouldn't be better off if we had to throw all that code away and start over.

Lastly, Flutter is very successful. It has a developer base of several million, is growing quickly, and developers tell us it makes them more productive (https://medium.com/flutter/does-flutter-boost-developer-prod...). Happy developers are a prerequisite for a wide variety of other Google APIs and services, so we have a vested interest in continuing that.

Even if it weren't for Google, there are more contributors to Flutter from outside Google than there are Flutter team employees. Those contributors include big companies like Samsung, Canonical and Sony, as well as prolific individual developers like @a14n (https://github.com/a14n).

We're working hard on lots of fun new stuff right now, including a rewrite of our graphics rendering engine. If you haven't seen it, check out https://wonderous.app, which is using the new engine on iOS. We think it shows the potential of Flutter well!

This is work that is 5+ years old. Before casually dismissing work that is long in the making, it's worth taking a moment to evaluate it. There are some amazing talks in the README that Herb has given. I particularly enjoyed his "Thoughts on Metaclasses" talk (https://www.youtube.com/watch?v=6nsyX37nsRs) which starts with a live on-stage user study.

Herb's thoughtfulness and care for tasteful evolution is manifest in the way he describes his work, and it's a shame to see it disparaged so easily.

Au contraire! We're actively investigating them here on the Dart team. We're finalizing the spec here: https://github.com/dart-lang/language/blob/98335746fb7f2dedf...