In practice the system is such that 'everyone' doesn't really seem to include the people making a lot of money they are effectively outside the system the rest of us have to deal with.
It sounds more like a depression and stress brained reduction to me. Tends to put you in a very binary and extreme thinking mode in my lived experience.
Also I inherently disagree with the idea of meaninglessness the author presents there. Meaning is relative to man, man makes meaning. There is no objective meaning and so you have to choose it for yourself.
Easiest to have different agents or turns that set aside the top-level goal via hooks/skills/manual prompt/etc. Heuristically, a human will likely ignore a lot of warnings until they've wired up the core logic, then go back and re-evaluate, but we still have to apply steering to get that kind of higher-order cognitive pattern.
Product is still fairly beta, but in Sculptor[^1] we have an MCP that provides agent & human with suggestions along the lines of "the agent didn't actually integrate the new module" or "the agent didn't actually run the tests after writing them." It leads to some interesting observations & challenges - the agents still really like ignoring tool calls compared to human messages b/c they "know better" (and sometimes they do).
We shouldn't ban social media we should ban algorithmically curated feeds that push any specific type of content. Outrage sells and so platform curated feeds have curated outrage and extreme content.
In practice I haven't seen much useful political discourse by the average person, but as long as we don't selectively amplify voices through machine signals and they NATURALLY accrue followings then whatever I guess.
MetroUI in Windows 8 was pretty universally panned. I thought it was pretty good on tablets and such, but it left a lot to be desired on desktops and hid a lot of functionality, it went too mobile for a lot of people's tastes.
Disclaimer: I was one of the dozens who used a windows phone. The Nokia Lumia 920 was great, you can fight me.
Wrong. There was full app compat of WP7 apps in WP8 and Win10 Mobile, and for WP8 apps in W10M. The only full backward app compat break was from WM6.5/WP6.5 to WP7.
I'll give you the benefit of the doubt and assume you're thinking of the lack of device OS upgrades: from WP6.5 to WP7, from WP7 to WP8, and from older WP8 devices to W10M. So no forward compat, but absolutely yes to backward compat.
That's not what they mean. As a developer, the API you used to develop your app was now deprecated with no migration path. That meant your app was deprecated, with no migration path.
For an app platform already a distant third place and struggling to attract developers, pissing off the few devs you do have TWICE was not a smart move.
Even then, that happened at most twice as you say, not three times as the other poster said.
And I disagree with your implicit claim that the WP7 & WP8 Silverlight -> Win10 UWP transition had no migration path. There was >= 90% source code similarity, bolstered if you had already adopted the Win8.1/WP8.1 "universal" project templates. And Microsoft provided tooling to ease the transition. Sometimes it was literally just s/Microsoft.Phone/Windows.UI/g.
Games were a different matter, I'll admit. XNA as an app platform had no direct replacement that was binary compatible with Win10 desktop, but even then, not only was DirectX already available from WP8.0, but Microsoft invested in MonoGame as an XNA replacement precisely because they knew the end of XNA would hit hard. (In fact it was the Windows Phone division that had essentially kept XNA on life support in its final years so that WP7 games would not break.)
"the API you used to develop your app was now deprecated with no migration path."
Seems that's the standard now for .NET desktop dev. Every 2 or 3 years MS crank out a new XAML based framework that's not compatible with the previous and never gets completed before a new framework comes out.
Nobody in their right mind should be touching any Microsoft provided API that isn't already well established (like Win32 and Direct3D).
I'm happy they're at least maintaining (to a limited extent) Windows Forms and WPF and updating their styles to fit with their fancy Fluent design.
But even that is a pretty sad state of affairs, since Windows Forms should be able to get that info from uxtheme (which Microsoft fumbled) and WPF should be able to get that info from the style distributed with the system-installed .NET framework (which Microsoft fumbled and now only exists for backcompat).
For the company with the best track record for backwards compatibility (with Windows), they sure suck at developing and evolving the same API for long.
You joke, but I honestly wonder if this period and projects didn't involve a bunch of Microsoft employees who got a little overexcited when they were told that they didn't need to maintain the insane, sometimes bug-for-bug, compatibility layers with 20-40 year old software that they had had to deal with their entire career there.
Must have felt incredibly liberating, and maybe they got a little too into the whole idea of "fresh start"(s).
I really love my qd-oled but the eye strain over the last 2 years when using this particular monitor is quite a bit more than my previous monitors. I just recently got better backlighting and went through some settings tweaking but it's still a bit harsh.
The tradeoff is worth it in a lot of scenarios, but I've been thinking about getting a "coding only" monitor that I use for long sessions instead.
There are plenty of musicians here saying this is useful for them or would be useful while learning.
As meta commentary, those not in a subgroup sometime fail to see utility of a thing built for that subgroup and it's easy to feel a sense of superiority "oh how dumb and trivial this thing is", but it may be better to first have curiosity and see how the intended audience responds. Often it's not dumb or trivial, you're missing context and experience to see the value.
I've played the piano for years. Your immediate conclusion that my dislike must stem from inexperience instead of a more nuanced place strikes me as the exact kind of thing you're lamenting in your comment.
As the other poster said, your comment didn't really leave any room for nuance, it was "ai bad". And it's also clear you're too egoistic/defensive to reflect on it.
Other commentary is you're not owed courtesy you yourself didn't give.
It’s the typical “engineer thinking they’re smarter than everyone else” trope. From my experience, engineers fall squarely in the middle of the bell curve. The AI hate is just used as justification, so I don’t even take it that seriously. And fwiw, as someone that played piano when I was younger, this is 100% a useful tool. In fact, during quarantine I was learning to play guitar and used tools like this to learn which string is which by ear.
It's flat wrong to suggest SO had the right answer all the time, and in fact in my experience for trickier work it was often wrong or missing entirely.
The example wasn't even finding a right answer so I don't see where you got that..
Searching questions/answers on SO can surface correct paths on situations where the LLMs will keep giving you variants of a few wrong solutions, kind of like the toxic duplicate closers.. Ironically, if SO pruned the history to remove all failures to match its community standards then it would have the same problem.
"But losing SO means that we're getting an idiot friendly guy with a lot of credible but wrong answers in place of a grumpy and possibly toxic guy which, however, actually answered our questions."
For the record I was interpreting that as LLMs are useless (which may have been just as uncharitable), which I categorically deny. I would say they're about just as useful without wading through the mire that SO was.
>> Eventually I tried with something else, and found a question on stackoverflow, luckily with an answer. That was the game changer and eventually I was able to find the right doc
Read carefully and paraphrase to the generous side. The metaphor that follows that is obviously trying to give an example of what might be somehow lost.
Yes, it does answer you question, when the site lets it go through.
Note that "answers your question" does not mean "solving your problem". Sometimes the answer to a question is "this is infeasible because XYZ" and that's good feedback to get to help you re-evaluate a problem. Many LLMs still struggle with this and would rather give a wrong answer than a negative one.
That said, the "why don't you use X" response is practically a stereotype for a reason. So it's certainly not always useful feedback. If people could introspect and think "can 'because my job doesn't allow me to install Z' be a valid response to this", we'd be in a true Utopia.
It entirely depends on the language you were using. The quality of both questions and answers between e.g. Go and JavaScript is incredible. Even as a relative beginner in JS I could not believe the amount of garbage that I came across, something that rarely happened for Go.
I'm not sure he intended it as an insult. Despite not using LLMs for HTML or JavaScript often (if at all), I was under the impression that it was one of their strong areas.
In my experience, at least in circles I've been around, I have found other developers who are a little too high on their own supply so to speak use "hurr durr web dev" as the "easy not real dev" insult.
So I both wanted to shame that in case they were and also categorically show otherwise.
Yes, exactly: I'm not saying everyone loves to paint or cook or whatever, but that a lot of people do, and it's weird and bad for the response to this kind of article, in which someone shares that they are losing something they enjoyed, to be some form of "well, not everyone enjoys that."
To some people this is a gain, to some people this is a loss. Objectively it is changing things, and I can agree on having empathy for those who it changes something for negatively.
I feel like we are in a period of low empathy, understanding and caring for others as an aside from just this piece.
That's the premise behind Lit (using the custom elements api)! I've been using it to build out a project recently and it's quite good, simpler to reason about than the current state of React imo.
I just evaluated Lit for work and while we didn't go with it, it was very nice. I love the base custom elements API regardless of using Lit or not, turns out that's all you really need to make intricate UIs that feel seamless.
Something about Lit/web components that's not written clearly on the label is the hoops you have to jump through to style elements. If you're using tailwind in the whole app, you just want to pull it into your custom elements without much boilerplate. My main app compiles a single minified app.css, it felt not so modular to now include that in every single component. The alternative is create a subclass that injects tailwind into Lit components. It'd be perfect it just had a switch to inherit everything the page already has.
By default, Lit renders into shadow DOM. This carries benefits like encapsulation (including the style encapsulation you mention). If you prefer global styles, you can render into light DOM instead with that one-line switch.
However, shadow DOM is required for slotting (composing) components, so typically what I'd recommend for theming is leveraging the array option of each component's styles:
static styles = [themeStyles, componentStyles]
Then you define your shared styles in `themeStyles`, which is shared across all components you wish to have the same theme.
oh nice! I didn't know that you can just make it use light dom.
protected createRenderRoot() {
return this;
}
And that's what it takes! I like using tailwind/utility classes so for the styles I'd need to have layers of compiled css files rather than one giant one.
The major downside of using light DOM is that elements cannot compose neatly since there's no delineating between what the component itself rendered and child content.
When you need to re-render your component, how does the component know not to replace the child content you rendered, Vs the child content it rendered into the light DOM. That's why the shadow DOM and slots were necessary, because then there's no intermingling of your content Vs the component's
This may not be a problem if you don't intend to compose your components. But if you do you will hit limits quickly
While you can easily turn rendering to shadow DOM off on a per-component basis, that removes the ability to use slots. It only really works for leaf nodes.
Pulling a stylesheet into every component is actually not bad though. Adopted stylesheets allow you to share the same stylesheet instance across all shadow roots, so it's quite fast.
Interesting, I'd be curious to know why you all decided not to go with it if you're open to sharing! Minimally to know if I should look at any other promising frameworks.
I see a good case for my company to use Lit for creating complex components such as highly interactive panels/widgets to be shared between React/Angular apps in our large ecosystem. However the decision was: 1. Prefer sharing plain JS/TS over framework code so try that first and 2. if the component is so complex and tricky to get right, it probably needs to be re-implemented in each framework anyways (or some sort of wrapper)
My secondary concern with Lit is the additional complexity of using shadow and light DOM together in long lived React/Angular apps. Adding a new paradigm for 75+ contributors to consider has a high bar for acceptance.
Ah yeah, definitely a much different equation when introducing this across many apps as a shared component library. Mixing different DOM abstractions together could get tricky for sure.
And yes attempting to add a new paradigm for that many people is I am sure quite the task. More political than technical in many ways as well.
reply