miffy900

It's also a solved problem that literally no human should have to bother with anymore. Like it was solved with SOAP APIs back in the 2000's.

Not to mention the fact that documentation is still always hand-written - which can have mistakes or typos in it, then downstream developers will have to translate that into hand-written client code, which can also have those same mistakes or bugs in it. And when the mistake is corrected, the dev needs to go back to where the correction was made in the docs, re-read and interpret the correction and then correct their client code. With API specs and code generators that entire process is automated now.

Now imagine bringing together approximately 6 different APIs into a single app, 5 have API specs while 1 doesn't. Now 80% of your time is spent on that 1 API where you have to read the docs to keep your client code up to date. Oh that 1 API vendor doesn't bother letting you know when their API is updated! So you have to F5 their website every week! This is literally my life right now.

Anyway, in this case, it was my mistake not to read until the very bottom where they had an OpenAPI yaml spec link there.

I'm reading the API docs https://enterprise.wikimedia.com/docs/

And they don't have an OpenAPI spec available to download? So they seriously expect developers to just manually write their own client code by reading and translating those example CURL commands by hand??!

Seriously it's 2024! Not having a spec to download and insepct for any API is a sign of incompetence. When tools like Postman or https://github.com/OpenAPITools/openapi-generator-cli exist and save hours of time, you can't seriously expect devs to write all this connecting code by hand anymore.

Nope - that would be a massive undertaking. Someone tried reimplementing SwiftUI but it was abandoned quickly after realising how much work it would entail: https://github.com/Cosmo/OpenSwiftUI

> Apple is already supporting Swift on other platforms, however, developer experience is not as good as on macOS and I don't think that can/will be solved by Apple

Yes it can. It's just Apple can't be bothered - most of the work to do that doesn't benefit Apple - it does benefit the Swift ecosystem and community of devs, but not Apple - the venn diagram of Apple vs the Swift dev community overlaps but doesn't completely close.

Swift came out in 2014 - Windows support for the compiler came out in 2020. That's it. They haven't bothered to upgrade the tooling support in VSCode or any other app because most VSCode users aren't Apple devs. The ball is literally in Apple's court - no one elses.

> Very often, especially in startups, when the new app is created, it is first created for iOS and then for Android. Having proper Swift support would reduce effort for bringing apps to Android/Windows.

I mean, this is just absurd logic. How is the lack of Swift support on non-Apple platforms somehow up to Google or Microsoft? The burden to support more platforms is on the language developer, not the platform dev.

This isn't the first Swift implementation ported to Windows. RemObjects Silver has had swift on windows (as in, develop and build/run on Windows) for at least a few years now, though it's not open source. https://www.remobjects.com/elements/silver/everywhere/

> why Microsft has ceased anything beyond legacy support for it

That is not true at all. DirextX is COM, UWP was COM based, WinRT is still COM, WinUI and the Windows App SDK is again based on COM. C++, C#, Python and Rust are all supported programming languages for the Windows App SDK thanks to - you guessed it: COM. The C++, C# and Rust language projections for it are still being constantly updated: https://github.com/microsoft/xlang

When they started Project Reunion (code name for Windows APP SDK) back in 2021, just before Windows 11's release, they decided to double-down on COM. Like hard.

https://github.com/microsoft/WindowsAppSDK/blob/main/docs/fa...

> Practically speaking, any language & runtime that can handle COM objects can support Windows App SDK

MSVC is not LLVM based, but C++ MSbuild projects can optionally use clang/LLVM as the C++ compiler instead of MSVC.

Microsoft is still actively maintaining MSVC

> JNI worked it just wasnt as ergonomic as it could have been - which was on purpose

There's a reason they're calling it the 'FFM' API and not JNI v2. The API devs were correct in rethinking the approach to native interop.

This just proves my point; being crappy ON PURPOSE is why it's a dead end; it's very difficult to improve something that's been deliberately designed badly.

Besides that, no Java dev in their right mind is going to continue to use JNI once they upgrade to Java 22 and realise FFM exists.

> This is similar, except more boilerplate and much, much slower.

That's JNI, which really was truly terrible. Java 22 introducing FFM is finally an admission that JNI was crap and a dead end.

The YT title was 'The worst product I've ever reviewed...for now.'

It doesn't mention Humane or the AI Pin, there's also no brand logo in the thumbnail. Just a pic of the device itself. If you had no foreknowledge of the video or device itself, or what he was talking about, you'd have to watch at least 1 minute into the video itself to know the company and device name. The YT video title on its own can't possibly 'kill someone's nascent project' or 'cause harm' on its own.

The tweet in question I'm guessing you're referring to is this:

> I find it distasteful, almost unethical, to say this when you have 18 million subscribers.

> Hard to explain why, but with great reach comes great responsibility. Potentially killing someone else’s nascent project reeks of carelessness.

> First, do no harm.

It's pretty clear they're not referring to JUST the headline/title of the YT video.

> "Multiply an insane amount of stuff" is not an interesting point in complexity-safety-performance space.

So in other words, Java is bad at scaling a basic math operation like multiplication?

> "In many ways Java is running rings around C++ performance"

The AI-space is proof positive of that being false. C++ is kicking Java's butt, squeezing literally trillions of ops per second of performance, all of this happening before the Java runtime can even startup.

The first transformer-based language model was built with PyTorth; imagine if PyTorch was a python wrapper for Java code instead of C++ code? It'd be garbage. I mean how freaking long did it take for Java to even get a basic Vector API? C++ devs have been writing SIMD optimized code for years now. And besides that, try getting a Java program to scale at tens or even hundreds or thousands of GPUs for a large language model. You'd need GPUs with literally 20-30% more RAM just to accommodate the GC.

So I'm someone who's lurked /r/politics on Reddit since its early days (2008), I'm convinced the reason it is so left leaning is because right wingers in general took too long to start using the internet. If you were young in the 2000's and up to mid 2010's you were more likely to use the internet, and be left leaning. Even just 10 years ago, conservatives/right wingers seemed to have a minority presence on the internet in general, let alone social media or a site like Reddit. In fact I think it was social media like Facebook etc, that helped conservatives realise this internet thing wasn't going away.

What you've written does nothing to disabuse any reasonable person of the notion that LLMs cannot reason; if anything you've explained how LLM's reason, not that they cannot do it.

> Maybe some people do not learn from their mistakes :)?

Maybe some people do learn, and in this case it's Microsoft, who are not repeating the same thing with Blazor as they did with Silverlight.

SwiftUI is just it's own distinct nightmare, and only supported on one platform. MAUI is meant to be cross platform so it makes perfect sense to use a neutral language that isn't tied to a specific programming language.

> Christian Laettner is quite clear that Swift was a reinventation of Objective-C, and most Objective-C 2.0 improvements and latter ones, were already with Swift interoperability in mind.

Yeah, I'm sure he said that at the outset in 2014 when Swift launched, but in 2023, that's not where Swift ended up.

> As for C remark, our computers have long stopped being a PDP-11 clone.

There is absolutely no need for a language like Swift to be as complex and bloated as it is; browse the language spec, and about 50% could be discarded and you'd still have a very complex langauge.

The Swift team would do well to take inspiration from C and keep it simple; just stop adding new langauge features and let the existing language breathe. Full stop. Each new release keeps adding new features without any regard to how new ones negatively interact with previous ones. It's a language being designed by compiler engineers and not app developers.

And don't get me started on the bloated language parser - editing Swift projects beyond a certain size in Xcode still gets abysmally slow. All they need to do is lock down a core subset of the language and just fix bugs; make the compiler engineers speed up the parser. That's it.

They tried to reinvent C++, when really they should've reinvented C and sprinkled Obj-C classes and protocols on top.

No it's YAML's fault - the fact that type coercion was once part of the serialization spec and not part of an adjacent schema spec is a tragic mistake. Now there's a bunch of outdated parsers that exhibit the issue and some that have it fixed. Meaning even more inconsistency and frustration. In an ideal world, YAML just shouldn't exist.

It's also sad that they're even considering this. They first considered this 20+ years ago before they launched the first Xbox; it was more plausible back then, compared than now, considering Nintendo's strengths with the Switch. Imagine if MS had succeeded with acquiring Nintendo back in the 2000's - I'm certain the Switch would never see the light of day.

Yeah but by virtue of MS having already acquired AB, the FTC would be less likely to approve a Nintendo acquisition.

> You’re welcome to go work at a software union shop, like Boeing.

> Writing low quality software that kills people, great job security even if you are at fault for peanut pay. I’ll take my non union job any day.

Boeing primarily manufactures and designs airplanes. The odds of dying while being a passenger on an airplane is about 1 in 200,000. Compare that to being a cyclist, which is 1 in 3,500. Or a pedestrian which is 1 in 485.

https://www.sbs.com.au/news/article/how-safe-is-flying-heres...

Putting your stupendously bad comparison aside, I'd say most software devs/programmers don't really need to unionise, aside from video game devs. 80+ hour work weeks, constant burn out, consistently underpaid compared to most other devs who just program boring line of business apps; they just get treated very poorly.

That wasn't the main reason though - UIKit v1.0 was pretty barebones not because they needed more time, but Jobs vetoed work on it for so long because he genuinely thought native apps were a bad idea.

The way generics are implemented is definitely not the reason why the CLR has a non-existent language ecosystem. The real reason is because .NET Framework for years was a Microsoft/Windows-only thing, and is still perceieved that way despite .NET being cross-platform now; yes Mono existed since 2005, but why would anyone invest time in writing a whole new programming language for a platform that was Windows only until 2016? This, despite the technical facilities that allow for multi-langauge implementations in the CLR. All the langauges that support the CLR are Microsoft developed ones: C#, VB.NET, F#, and C++/CLI, the last one still being Windows-only. Even then VB.NET and C++/CLI exist because Microsft internally needed to support old code for a bunch of already existing projects at Microsoft anyway.

Also generics in the CLR isn't mandatory - you can implement a language without buying into the CLR-way of generics. For instance in C++/CLI, you can mix and match templates with CLR generics, but it's in no way mandatory. You can still write C++/CLI code using C++'s native template system: https://learn.microsoft.com/en-us/cpp/extensions/generics-an...

React definitely did not copy WPF. It copied XHP: https://docs.hhvm.com/hack/XHP/introduction which was another Facebook thing, but that itself was inspired by E4X: https://en.m.wikipedia.org/wiki/ECMAScript_for_XML

I'm very pessimistic; MS tried this back in 2012 with Windows 8. Everything from Windows to SharePoint to Office and Visual Studio tried to adopt the whole Metro design stuff, but they ended up creating many inconsistencies. They made some minor changes when they refreshed it again with Windows 10 in 2015 and from then until 2022 (Windows 11), they had settled on Windows 10's design language, but now this attempt to refresh will just introduce more inconsistencies.

Microsoft has even more user-facing products in 2023 than they did in 2012, so it's probably going to be even worse.

I'm on a 12th gen Intel i5 4 p-cores and 8 e-cores, 16-thread, 16GB RAM Lenovo laptop and it's lagging. Poor showing on MS's part that their flashy new design system is this slow.

Yes it was better than 8.0, but 8.x definitely did not sell as well as Windows 7.

Windows 7 got 3 years of ESU (extended security updates), which MS did not bother with Winodws 8 because there wasn't the install base worth the effort (https://support.microsoft.com/en-us/windows/windows-8-1-supp...).

It was the same with Vista - it's predecessor, Windows XP, was supported until 2014, which was 2 years more than Vista got

And yet, Obama has:

- ZERO indictments, unlike Trump

- ZERO impeachments, unlike Trump

Also none of Obama's lawyers have ever been tried + convicted of a crime either, unlike Trump.