I'd argue we jumped that shark since the shift in focus to post training. Labs focus on getting good at specific formats and tasks. The generalization argument was ceded (not in the long term but in the short term) to the need to produce immediate value.
Now if a format dominates it will be post trained for and then it is in fact better.
All models released from those providers go through stages of post training too, none of the models you interact with go from pre-training to release. An example of the post training pipeline is tool calling, that is to my understanding a part of post training and not pre training in general.
I can't speak to what the exact split is or what is a part of post training versus pre training at various labs but I am exceedingly confident all labs post train for effectiveness in specific domains.
I did not claim that post training doesn't happen on these models, and you are being extremely patronizing (I publish quite a bit of research on LLMs at top conferences).
I claimed that OpenAI overindexed on getting away with aggressive post-training on old pre-training checkpoints. Gemini / Anthropic correctly realized that new pre-training checkpoints need to happen to get the best gains in their latest model releases (which get post-trained too).
If you read that as patronizing that says more about you than me personally, I have no idea who you are so your own insecurity at what is a rather unloaded explanation perplexes me.
Except Akka in Java and for the entirety of Erlang and its children Elixir and Gleam. You obviously can scale those to multiple systems, but they provide a lot of benefit in local single process scenarios too imo.
If I'm not mistaken ROOM (ObjecTime, Rational Rose RealTime) was also heavily based on it. I worked in a company that developed real time software for printing machines with it and liked it a lot.
I've worked on a number of systems that used Akka in a non-distributed way and it was always an overengineered approach that made the system more complex for no benefit.
Fair, I worked a lot on data pipelines and found the actor model worked well in that context. I particularly enjoyed it in the Elixir ecosystem where I was building on top of Broadway[0]
Probably has to do with not fighting the semantics of the language.
Really depends of the ergonomics of the language. In erlang/elixir/beam langs etc, its incredibly ergonomic to write code that runs on distributed systems.
you have to try really hard to do the inverse. Java's ergonomics, even with Akka, lends its self to certain design patterns that don't lend itself to writing code for distributed systems.
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.
Now if a format dominates it will be post trained for and then it is in fact better.
reply