I find I still use the paid IDE's (RustRover and WebStorm), even when using LLM's for reviewing code and applying corrections. It's often just faster to do that, especially with an IDE which allows for quick non linear navigation through the files (following functions etc.). I think this is where JetBrain's IDE's excel. I can live with the high startup cost as long as it is quick afterwards.
I do feel however they have been neglecting anything non-AI for a while now. I in particular loved their auto complete, and with the new guesswork AI auto complete it's just not the same. I want deterministic behaviour from my IDE.
On the LLM side, I couldn't use the Anthropic subscription with their offerings, so I just use it from a harness outside the IDE, and switch to the IDE for review. This may not be JB's fault, but it still makes their offering useless to me.
I may be one of the few remaining but I also still program myself sometimes (I weigh it based on the task). The IDE has been pushing so much AI it has been getting in my way sometimes, and it is definitely using more resources for stuff I don't use.
I too am on the fence on whether I'll resume my subscription. Luckily for JB I dearly dislike VSCode's code navigation and interface, and would severely miss their debugging tools integration.
Just because something is publicly accessible doesn't mean you can use it for free, or that it gives you rights to do whatever you want with it.
I can access a public park, but that doesn't necessarily give me the right to also bike on its sidewalks, or walk on the grass, or take some of the plants home with me.
> ... or has been obtained illegally
Similarly, content that is _accessible_ publicly may be illegal to _obtain_, these aren't mutually exclusive.
On the internet, you'll find there are terms of services and licenses. These restrict how you can use even publicly accessible material. Public availability doesn't give you a license to use it however you want.
> Public availability doesn't give you a license to use it however you want.
Of course. You listed complex examples from the real world. A park where walking is allowed but damaging the plants is not, for instance. There it makes sense to distinguish various activities that can be done in there and treat them separately.
But a website offers not much activities that you can do with it. You can read it. And that is about it.
Regardless of actual use as an (embedded) browser, it is useful in the sense that it can be used to provide (another) source of validation about whether specs and WPT [1] tests are properly and clearly defined. That helps for long term browser compatibility.
Making a new browser engine hurts browser compatibility more than it helps it. It now becomes one more target that needs to be tested against, limitations need to be kept tracked of, etc. The best thing for long term browser compatibility is focusing resources into Blink. In regards to the standard we can use LLMs to cross reference the spec, with tests, and with the implementation to make sure all match.
One could argue that effectively Blink is also not open source. At any rate users don't have power over it, as witnessed by the manifest v3 stuff jammed down our throats.
> The best thing for long term browser compatibility is focusing resources into Blink.
That’s what makes Google more dominant, and if you think that’s a good idea you should really put down your LLM and go read up on a bit of history. Do you want to live in a world where a single company controls your access to the web? Are you eager to navigate through ad pages with a little bit of web? To have even more of your data mined?
Browser diversity may be a bit annoying for developers, but it is good for users, and developers are users too. When there’s a lack of diversity, everyone but the dominant player is squeezed.
Google's dominance comes from market share not from owning upstream. If a different fork took 90% market share that fork would have the dominance and power.
And that market share is maintained by integration with Android and low-key sabotage of others browsers, especially Firefox. Similar to how Microsoft maintained its monopoly decades ago.
That can only happen if we don’t all focus resources on Blink, which is the point. By definition, we can only have other engines if diversity is a thing.
The problem isn’t specifically Google (though they are a problem), but any one individual company having all the power.
>That can only happen if we don’t all focus resources on Blink
Why? What's fundamentally stopping Edge market share from going to 90% that would go away if they switched back to their own browser engine?
>but any one individual company having all the power.
Open source means that anyone can make any change at any time. Google doesn't have all the power over what a fork does. A fork is still in full control.
yeah in a perfect world google dictates how the standard will evolve, we kill all competition so we're sure that you have only one target to build your software against, I'm sure a monopoly will greatly improves innovation and not be used to stiffen competition. /s
It's easier maintaining a fork of Blink than an entirely different engine. Google being the primary maintainer doesn't mean that browsers can't make large forks.
>work on other browser engines is not duplicated or wasted.
How is having N engine developers implement some new addition to the EMCAScript or CSS standard for each of their engines not duplicated work?
> It's easier maintaining a fork of Blink than an entirely different engine. Google being the primary maintainer doesn't mean that browsers can't make large forks.
Maintaining a fork is not fun as taking patches from the origin repo becomes more complicated the longer the fork exists and the bigger the divergence becomes.
> How is having N engine developers implement some new addition to the EMCAScript or CSS standard for each of their engines not duplicated work?
It would be duplicated only if they all maintained, say, a Blink fork.
> - Under a playlist you get a list of suggested songs, the UI element looks like a "regular song", but unlike every other "song" element the user has been trained to recognize, the "swipe right to queue" does not apply to these elements. For some reason.
There's a ton of these inconsistencies. For example, the new releases albums where songs become available over time also do not have it. It's infuriating how inconsistent the UI is sometimes.
Not so long ago they also had two versions of the "swipe right to queue" UI, one with long swipe (the current one), and one with a much shorter one. I preferred the shorter (with the hard break) one because it is much clearer when a song actually gets added to the queue. What often happens when you're adding multiple songs to the queue, if you only swipe a little bit, it is unclear if it was enough to add it to the queue. With one song this isn't a problem because a message with "added to queue" is shown, but for multiple songs, the messages are shown on top of each other.
Not saying that LLM development isn't fast, but doing a re-implementation of something you know in-and-out is almost always going to be faster, as you skip the probably most time intensive step of product research and requirement engineering.
Absolutely, but that doesn’t discount that it’s now feasible to spec a feature once and have it built for me on both apps. I’m doing the same process on a new project I’m working on and it’s built both apps simultaneously as I’d hoped.
I had this almost exact discussion today. Adyen (the payment provider) provides merchants with webhooks so they can update a local modal of payment and payment modification data (checkout).
But there is no way (for a merchant) to get the latest 'true' state as held by Adyen. So you better hope your data is exactly in sync with the notifications you got from the webhook (which it never exactly is, because there are so so many points of failures, and unlike what this author says, the docs aren't thát well presented to hold the same model as the PSP does. It is often close enough though, but you are constantly gardening your implementation, because the model also changes on their end with little information in the changelogs).
The "latest state" data exists though! If you open the customer portal it is presented to you without problem.
I don't think the article tries to argue against the good sides.
In my opinion it asks us to not just look at individual gain of using LLM's (which can be powerful), but also place it in context how we as humans built long-term sustainable societies. Most societies are currently ignoring that part for the most part, because they fear missing out.
Probably the hardest problem of LLM's is their ethics. As the author put it:
> Modern multi-billion parameter AI models are scaffolded on and made possible by the largest heist in human history: theft of everything that could be scraped from every corner of the digital spaces we share. Without prevention of and justice for this damage caused by current models, their use is highly fraught, ethically. We, as human beings, have developed complex social forms of intelligence when it comes to dealing with things like credit and provenance, two things that modern models are incapable of.
No one currently seems to have serious solution for this. Solving it the right way would be choosing the hard path. While some artists or writers are fighting for their rights, us programmers are collectively ignoring the issue. It is funny how most companies (and some individuals) only want to use LLM's of they don't train on their code. But is just fine to use some 40 years of collective open-source without any compensation or even acknowledgement.
This side of the story doesn't make LLM's less technically impressive, nor does it make the tools themselves less powerful. But unlike the industrial revolution, which some like to compare the AI boom to, during the industrial revolution humans built stronger productivity solely on innovation without strip mining all intellectual property in human existence.
I can see the benefits of LLM's, enjoy the technical capabilities and be impressed by the technology, and at the same time find these tools wholly unethical in their current form.
In addition, there's about 2x year a 25% sale and you have a year to activate the passes.
The in southern Europe (e.g. France, Spain, Italy), required seat reservation is most common and most expensive.
I don't mind requiring seat reservations, but that it is separate from the ticket price and significant (eg 15€/seat reservation in Italy), feels like price gouging. It also feels different from say the optional (and way lower priced seat reservations in German ICE's (high speed rail)). I rather pay for a "high speed rail supplement" instead of seat reservation haha :).
I interrailed last year through Germany, Austria, Slovenia, Italy and Switzerland.
In Germany I was lucky, I only had a small delay on the way back.
Austria was exceptional in everything. On time, modern trains and facilities. I guess the food on the train was expensive and bland, but I've never seen a train where that's different.
Slovenia was the weirdest and had the most delays. Train cars for which I had seat reservations consistently didn't exist or arrive. They use old stock, but that also made it kind of fun and there were great views. I couldn't rely on the time table though.
Italy has lots of high speed rail, but required (paid) seat reservations. The problem is that for almost any medium-long distance there's no slower speed alternative. The normal speed stock is fine (can be taken to go to smaller cities) and was generally on time.
Trains in Switzerland are exceptional too. Funnily enough, I did have fairly significant delays 2/5 times.
As a Slovenian I’m always impressed when tourists take the train and make it through the country without huge delays or replacement bus service. The trains here are just awful, the main line (Koper-Ljubljana-Maribor) is the worst. Lots of construction work that never seems to end. There are still Yugoslav cars in use occasionally on some more remote lines.
> It also feels different from say the optional (and way lower priced seat reservations in German ICE's)
One has to add that most of the time when you buy a single ticket in Germany you have to (pay through the nose and) buy a ticket that is good for one specific train. Miss that train and your ticket is gone. This used to be different before the reform of the Deutsche Bahn after 1989; you used to buy a ticket for a 'communication' (connection between endpoints), not a specific train. TBF in like up to 200% of all cases Deutsche Bahn will route the wrong train in the wrong direction to a wrong station hours after the schedule in which case your Zugbindungsfahrausweis will fall back to work as a pre-reform ticket valid on all trains in that direction (sometimes even including an upgrade if an ICE is all there is, I think).
Yes, definitely always include the number of digits, but at your system boundary you still have to pray that whoever you're working with isn't silently dropping that number and re-deriving it from their own, almost-4217-compliant currency database.
Redundancy can be great, but it's not a panacea, since it's not guaranteed to be used in an optimal way.
I do feel however they have been neglecting anything non-AI for a while now. I in particular loved their auto complete, and with the new guesswork AI auto complete it's just not the same. I want deterministic behaviour from my IDE.
On the LLM side, I couldn't use the Anthropic subscription with their offerings, so I just use it from a harness outside the IDE, and switch to the IDE for review. This may not be JB's fault, but it still makes their offering useless to me.
I may be one of the few remaining but I also still program myself sometimes (I weigh it based on the task). The IDE has been pushing so much AI it has been getting in my way sometimes, and it is definitely using more resources for stuff I don't use.
I too am on the fence on whether I'll resume my subscription. Luckily for JB I dearly dislike VSCode's code navigation and interface, and would severely miss their debugging tools integration.
reply