> The pessimistic one is that most of what needed building gets built, and the remaining work fits in fewer hands.
I don't think that's true, mainly because if it were true it would have happened a long time ago. We will never settle on one version of a thing (let it be messaging, recipes, notes, image galleries, etc...). New variants emerge over time, the only thing AI does is accelerate this.
There are countless games and applications in the app stores these days. Almost all of them are money losing ventures. The vast majority of these variants are going to go extinct and earn negative revenue for its creator. The big problem comes in when creators stop running into any variants that can earn them a living at all.
>We will never settle on one version of a thing
This depends on how well a monopoly can fit into the equation.
>We will never settle on one version of a thing (recipes)
Here is an example of missing the whole elephant because you're looking to close. While the number of recipes are booming, the number of food distribution companies has collapsed into just a few mega corporations. And those corps are massively controlling the prices all of us must pay.
You can't make money playing a guitar and warbling into a microphone anymore either. Hasn't stopped my local bar from hosting local musicians who are in it for the craft.
I don't think that's really an apt comparison. Most software people who are in it purely for the craft are deep in open source, and open source doesn't necessarily build the most user-friendly tooling. If it did, you'd see apps like GIMP seriously challenging Adobe, etc. So much of the software layer built for enterprise and consumers relied on VC. I can only speak for myself, but I'd be willing to bet that 95+% of developers I've worked with would not build user-facing software for free. We are all in it for the money.
I'm willing to be that 95% of developers you've worked with are, but how representative that is of the broader group is indeterminate. Apple is full of developers who give a shit about design, or at least, had to pass an interview that pretends that they pretend to give a predend shit... look, at some level you just have to buy that people are who they say they are. Even if you're in it for the money, you're going to conferences and speaking about it to people, so it's you.
Let's hope you're right, but you might be underestimating the "$200 per month (robo)engineer can only do it like this, therefore this is the way to do it" factor.
It's nice to see that we are converging on the same syntax I came up for Mint (https://mint-lang.com) 8 years ago (feels strange to write it down). I saw Ripple some time ago its syntax has the same structure more or less (component, style, render, state, etc...)
Ah I missed the previous threads about your language, because they didn't follow the title convention I was searching for. I've put https://news.ycombinator.com/item?id=17161533 (the first one) in there now. It would be better if it just said "The Mint Programming Language" though (and I'm not above fudging that retroactively!)
It's very similar to Mint (https://mint-lang.com/) which I'm building for some time now.
Looking at the samples, it seems Ripple is going the same direction as Mint:
- explicit component definitions
- inlined control flow in HTML tags
- component based styling
- explicit white space handling for element content
- syntax for setting references
I'm not sure why they based it on TypeScript instead of creating a new language completely, since there are a lot of new syntax added (and they have their own extension as well).
If you are looking for something similar, give Mint a try, it has a lot more features, and I'm looking to release 1.0 in the near future.
Obvious reason would be that all major js libraries have ts definitions available now and if the language is TS based they can all be used without compromising with type-safety.
I'm still waiting to evaluate Zed because I work with/on my programming language which has LSP Semantic Highlighting, but Zed doesn't https://github.com/zed-industries/zed/pull/39539 once it's merged I'll give it a go because it looks like a modern Sublime Text (which I still use). I just wish they would focus on basic editor features instead of adding AI and other non-related features.
I switched from Sublime Text (still keep for navigating huge files).
But I love the thought put into Zed and it looks great (this is important to me).
I don't use their AI features but it does come in handy when I need an quick alternate answer or perspective. I use Claude Code in a separate terminal.
Still working on the Mint programming language (https://mint-lang.com/) with a 1.0 release in January :). I'm happy with the current feature set, so I'm just polishing and optimizing where I can and giving the documentation a throughout look.
IMHO, Marko and Mint target different things. Mint was specifically made to create Single Page Applications, whereas Marko seems like more for general all things web.
- There is a single root dependency somewhere which gets overtaken
- A new version of this dependency is published
- A CI somewhere of another NPM package uses this new version dependency in a build, which trigger propagation by creating a new modified version of this dependency?
I think so. It’s that third step that I can’t figure out. Build systems are configured to pull the latest version of a dep automatically, without review, and then publish. It seems the poorly configured pipelines are what enable these attacks. Fix your pipelines
The challenge was to make it seamless enough that so it doesn't look like that we tried to mash languages up, but to make them form a different language that is consistent and simple at the same time.
Your Mint language looks awesome! You’ve done a great job making it very seamless between the 3 languages. I had a couple thoughts regarding your css/styling though:
1. The one feature I prefer in Marko when compared to Mint is Marko’s nice ID and class syntax, rather than your custom selectors, so you can just use regular CSS (which seems to be advancing faster than the JS & HTML specs combined). You could get the scoping using shadow roots for your components (I’m sure this has flow on consequences, but given you own the language it’s probably better case than many others.)
2. Interpolating values directly in CSS blocks is something that a lot of HTML templating systems sort of give up on (see Astro going out of it’s way to make interpolating variables super verbose [0]), so I’m glad to see you do it. Does the value interpolation compile to CSS variables that are set on the component root (or somewhere else I suppose) as in Astro [0], or is it just simple interpolation? Additionally, I can’t help but notice your hash symbol would conflict with ID selectors, so is CSS nesting available?
Please don’t take this as criticism! I really like what you’ve done here and am very curious.
1. Inside style blocks it's pretty much regular CSS except for interpolation and if/case expressions, so you can create a style for the root element and then use ids and classes if you desire, but it won't be optimized.
2. CSS definitions without interpolation compile down to static CSS while the ones with interpolation compile down to CSS variables which are set on the element where the style is assigned. This also allows for passig arguments to styles [0].
CSS nesting is supported and the interpolation doesn't conflict with the id selectors because interpolation is not supported in selectors.
It's there a way to define routes in a nested, hierarchial fashion, preferably across multiple modules?
For example, with react-router, my root route object array I define by spreading out other route object arrays that I've imported from other modules in my project. And each of those do the same thing, recurring as necessary until I get to the full depth of my route tree.
I don't think that's true, mainly because if it were true it would have happened a long time ago. We will never settle on one version of a thing (let it be messaging, recipes, notes, image galleries, etc...). New variants emerge over time, the only thing AI does is accelerate this.
reply