The bundle size is, by definition, much smaller as it doesn't include the browser engine.

This benefits people and teams who prefer to build UIs with html/js/CSS.

Are you arguing that people who are against this law and its implementation in the UK are against it because they're addicted to porn?

Yes. There are legitimate reasons to dislike the law, its implementation, or its impact on privacy. But 99% of people dislike it simply because they are heavily addicted to porn. The fact there have been much more privacy invasive laws introduced in the UK over the last decade which face little widespread outrage is the tell.

I think it's rather that OSA actually visibly affects people in their day-to-day lives whereas other laws don't. I constantly hit age verification pages on Reddit and Twitter and I don't use either for porn. I'm fundamentally against giving Reddit or Twitter or a 3rd party processor my ID just to view content someone somewhere deemed potentially harmful to minors. At least Twitter is done on a post-by-post basis; on Reddit entire subreddits are gated behind age verification.

It's hard to keep this conversation in good faith if you're just gonna throw in some statistic you just made up.

It's very obviously a figure of speech and not intended as a statistic.

That's not the point I was trying to make. You believe that almost all people who have issue with the law do so because of porn addiction. You haven't shown any data, it's just your belief, from which you're informing and repeating your world view as fact.

I remember seeing Mint quite a few years ago. I love the idea, I really like the language design, but I agree 100% with your take on the drawback. It's hard to sell that to teams.

What's surprising to me is how many alternatives exist in this space. Between elm, imba, svelte, and mint, and probably more that I don't know about, I wonder how many devs in the world are shipping to prod using them.

edit: have you thought about including Form Validation to the core lib?

> have you thought about including Form Validation to the core lib?

There is a module for that in the standard library (https://mint-lang.com/api/Validation). Moving the functionality into the language level is intriguing.

I meant to say more than validation, something like this feature set:

https://www.react-hook-form.com

React Hook Form is beastly.

Reading through the example, it seems like it doesn't do reactivity, as the user code must call render() manually on state changes. Did I miss something?

No, that's correct. I did it that way deliberately as a design choice.

Is that not still considered reactivity? If so then I'll update the docs.

I'm definitely not the authority on the definition of that word, but in my view I expect reactivity to mean that the UI reacts to state changes "automatically".

I disagree completely with that, at least for software engineers.

The work queue is infinite, measuring output with any sort of precision is almost impossible for a lot of the work (maintenance, actually necessary refactors, security, mentoring juniors, managing stakeholders, etc etc etc). There's no "I've finished my work for today".

I'm not saying that I like it, or that it's a good thing, but in my understanding engineers are paid to be available doing work roughly 40h/week.

All of what you mentioned is quantifiable.

If a portion of the team is remote, then the whole "remote team" apparatus and culture are necessary. Same with hybrid offices in which the WFH days are random instead of set for everyone.

I fully understand that this is a polarized personal preference issue. I don't think there's a way to make both work in the same company.

Maybe you're correct about windows vs macos, but I find it hard to believe that the current distribution of android vs iphone users in the world is much different for musicians.

I've programmed in Clojure professionally.

People like GP often repeat that talking point: "code is data so that's amazing because of macros".

In practice, by and large, with very few exceptions, macros are frowned upon in the same way that using metaprogramming in ruby is. Macros are only fun to the person writing them (and not even the author when they have to maintain it).

Macros can almost always be expressed with a simple function and remove all the unexpectedness without losing anything. Again, there are some exceptions.

> In practice, by and large, with very few exceptions, macros are frowned upon in the same way that using metaprogramming in ruby is. Macros are only fun to the person writing them (and not even the author when they have to maintain it).

I'm not sure "frowned upon" is the right expression, but I'm not a native speaker.

The way I've internalized it, is basically "Avoid macros unless there is no other way", which basically means use functions/anything else whenever you can, but if you absolutely have to use a macro for something (like you wanna read the arguments before they're parsed), then go for it.

Thank you for posting this.

I always looked at these features of being able to extend the language beyond some commonly accepted practices as detrimental to the language. I've spent way too much time debugging issues with operator overloading or complex templates (C++), or obscure side effects in DSLs. So, (re)defining language constructs in a project seems nightmarish to me to support in production and therefore I never even attempted anything serious in a functional programming language.

But... looks like the professional community knows this and so maybe it's time to take a deeper dive :)

> So, (re)defining language constructs in a project seems nightmarish to me to support in production and therefore I never even attempted anything serious in a functional programming language.

It can be, but also not. If you isolate them into libraries with clear interfaces, you can kind of avoid that. I think clojure.core.async is an excellent showcase in something you couldn't do in other languages, where asynchronous channels were possible to add to the core language without changing anything in the core compiler itself, and because of the small interface, you can still use it without ending up with nightmares :)

Understood. I was more referring to a case where a project would start defining its own language constructs and if each project would do that then every single project would come with a very high cognitive load.

Dunno about the Clojure communtity but for Emacs Lisp and Common Lisp there are certain broadly accepted idioms where macros are accepted:

1. "with-context", where there is a need to control resource allocation/deallocation or things in the context of code in question. 2. use-package dsl that simplify configuration in a predictable way 3. object definition helpersresource

Then, there are core language extensions and std libraries suggested for the main implementation. This is where macros are fine as they always get good documentation and plenty of additional eyeballs.

Fully agreed with your examples. As a rule of thumb macros should be kept inside libraries, not application code.