I know right. I’m glad DSLs have fallen out of fashion. Just use the platform.

I can understand why developers might not care for DSLs, especially when they force a choice between entirely different toolsets and toolchains.

However, I feel people often miss the real value of a good DSL: it's not about the syntax, but about providing hardened semantics that can bolster or guarantee desired qualities. Elm, for instance, provides value insofar as it makes producing runtime exceptions significantly more difficult.

Personally, I hope languages like Lean, which provides exceptional support for creating DSLs within the language, renew interest in semantically sound DSLs, especially if we insist on using LLMs.

I recently learned about that too, how Lean provides ways to create new language syntax and DSLs, which is (on the surface) similar to Lisps like Racket. It's like operator overloading but way more flexible and general purpose. I'm wary of such language features, convenient for specific purposes (like working with vectors or matrices) but I'm afraid it's too powerful for normal usage, if everyone starts building their own DSLs and syntaxes, it would likely make the typical codebase difficult to read and understand. For example, the C++ template metaprogramming madness, it can be used responsibly but in my opinion it was detrimental to the language ecosystem.

And then there are sealed DSLs...

Byte encoder/decoder in Elm are opaque, so their implementation is hidden. A smart compiler, such as the one I am writing, can take advantage of that with compiler intrinsics that replace the implementation with something that the compiler itself optimizes.

Besides the new form factor, resizable apps are also meant to further bridge the gap between macOS and iOS right?

More than that, it forces iPhone-only devs to get with the program and make their apps usable on larger screens too.

I wouldn’t be surprised at all if next year they dissolve the iPhone/iPad distinction on the App Store altogether and maybe even remove the Catalyst toggle on the Mac App Store. If you make an iOS app, it’s also a full fledged iPadOS, macOS, and visionOS app too.

I certainly wouldn’t mind. On my Mac there are some needlessly heavy electron apps I’d swap out for their iOS counterparts in a heartbeat if that were possible, as well as some games that would run fine on macOS but their devs don’t tick the checkbox for unclear reasons.

> I wouldn’t be surprised at all if next year they dissolve the iPhone/iPad distinction on the App Store altogether

I hadn't thought about it but it makes sense and it makes me wonder how far this would reach throughout the rest of the OS. If the iPhone can fold out into an iPad Mini, will it get the rest of the iPadOS features? The iPad used to run iOS but they rebranded the version that runs on iPad to iPadOS to distinguish that it has a handful of unique features only for big screens, mainly pertaining to multitasking. But if the line is being blurred and iPhones will have big screens with multitasking, will they go back to just calling it iOS on all mobile devices?

You're just arguing about marketing. Apple has moved to a One device, one OS dichotomy they will not rethink because the foldable iPhone gets a version of the iPad's multitasking. And engineering-wise, when they moved the naming to iPad OS, nothing changed behind the curtain. The iPad still runs the same codebase it did before the marketing switch. They didn't fork anything.

I think they’re going to continue to make some features device-specific. They probably want to position the foldable iPhone as a midway compromise device rather than a full iPad and flagship iPhone replacement, targeting customers who prefer breadth over depth and capability when it comes to features.

At the very least, this is needed for iPadOS and macOS, since both have resizable windows.

I'm currently working on a responsive app in Swift and had to develop my own responsive layout system. SwiftUI simply isn't up to the task, except for one very specific, generic layout.

I'd guess that they're meant to bridge the gap between iOS and iPadOS, if anything.

The article does not come from someone who relies of Figma for a living. It's easy to call it a "proposal doc" when you're working on a specific issue for a specific product. There are still millions of designers who use Figma to define and maintain design systems that span across products and platforms, where Figma is the source of truth.

Incoming rust rewrite branch ready to merge: +1,009,257 -4,024

Well put. SQL gets put in this category of foundational technology that has passed the test of time when in reality it’s more like an example of path dependence.

“A screaming comes across the sky. It has happened before, but there is nothing to compare it to now.”

The devs doing these kinds projects no longer think of the code as maintainable, but disposable. It's quite the 180 for a community obsessed with reusable npm packages and not reinventing the wheel. Last year Cursor bragged about ditching their CMS in 3 days: https://x.com/leerob/status/1999513884382597485

It’s not a 180

It’s measuring time to iterate/ship, cost reduction and independence, which is really all that matters

Reusable was great because it used to be the fastest. The fastest now is vibe/slop > iterate > iterate > iterate > ship > iterate > ship etc…

The first sentence being "I was not planning to write this article" is the cherry on top.

I’d start with the immense packaging waste and shameless overconsumption tricks that are banned in basically any other industry.

Honestly i prefer my macbook frosty

Sir, this is a Wendy's