bloomca

Maybe Android has its own libc? So they compile it for Android, but not for general Linux.

Also curious about this.

Windows APIs docs for older stuff from Win32 is extremely barebones. WinRT is better, but still can be confusing.

I think AI is really great to start with the systems programming, as you can tailor the responses to your level, ask to solve specific build issues and so on. You can also ask more obscure questions and it will at least point you at the right direction.

Apple docs are also not the best for learning, so I think as a documentation browser with auto-generating examples AI is great.

I have an M2 Macbook Air with 8GB and it struggles even without the light development part, and latest macOS made it all much worse. To be honest I am impressed how fast the experience degraded as there was a lot of headroom.

Apple seemed to copy this one exactly as iCloud asks you the same all the time. Honestly these days Linux feels like the only sane platform as you can customize it properly.

System Settings is so slow for the amount of contents it has that I have to say it is probably the worst offender per content capita

The rise of Electron was purely because you can share the codebase for real with the web app (for lots of apps it is their main focus) and get cross-platform support for free.

Native apps are not bad to develop when using Swift or C#, they are nice to use and their UI frameworks are fine, it's just that it requires a separate team. With Electron you need much less, simple as that.

> As for the rest: minor variations in traffic light positioning and corner radii are topical but hardly indicators of decaying platorms.

I think it shows how important the platform itself is to the company. The system settings app on macOS is literally slow to change the topic (the detail page is updated like ~500ms after clicking).

I personally love to develop desktop apps but business-wise they rarely make sense these days.

I don't think it's worth to include the session -- it would bloat the context too much anyway.

However, I do think that a higher-level description of every notable feature should be documented, along with the general implementation details. I use this approach for my side projects and it works fairly well.

The biggest question whether it will scale, I suspect that no, and I also suspect it is probably better to include nothing than a poor/disjointed/rare documentation of the sessions.

I think a lot of companies are going to get burnt on these things. Sure it is easy to one-shot something which looks close, but then you are responsible for releasing/maintaining/improving.

Not to mention that you'd need to integrate it with lots of other vibe-coded products. It can be great for some use cases for sure, though, but identifying them can be tricky, as big orgs are pretty terrible at formulating what they need clearly.

You can pay to have better/more machines, while you can't do the same with your clients

You can't buy client performance, so it is just more visible. It's not like there are a lot of people with Rust/C++ back ends outside of some very critical pieces.

I agree, LLMs definitely sand off a lot of personality, and you can see it in writing the most, at this point I'm sure tons of people are subconsciously trained to lower the trust for something where they recognize typical patterns.

With the code, especially interfaces, the results will be similar -- more standardized palettes, predictable things.

To be fair, the converging factor is going on pretty much forever, e.g. radio/TV led to the lots of local accents disappearing, our world is heavily globalized.

If the models don't get to the point where they can correct fixes on their own, then yeah, everything will be falling apart. There is just no other way around increasing entropy.

The only way to harness it is to somehow package code producing LLMs into an abstraction and then somehow validate the output. Until we achieve that, imo doesn't matter how closely people watch out the output, things will be getting worse.

I think this is the logical next step -- instead of manually steering the model, just rely on the acceptance criteria and some E2E test suite (that part is tricky since you need to verify that part).

I personally think we are not that far from it, but it will need something built on top of current CLI tools.

All your thoughts are and experiences are real and pretty unique in some ways. However, the circumstances are usually well-defined and expected (our life is generally very standardized), so the responses can be generalized successfully.

You can see it here as well -- discussions under similar topics often touch the same topics again and again, so you can predict what will be discussed when the next similar idea comes to the front page.

I personally never seen anything as bad as XCode, but granted, I haven't used really old IDEs (always preferred just editors). Last year I built a few small apps using both XCode/Swift and Visual Studio/C# and using MS stack felt like you are living in the future, despite WinUI having a very dated UI syntax.

I think fundamentally this approach is flawed for anything more complex than a simple endpoint. AI is already really good for throwaway code, that is very clear, it is also decent if you watch it like a hawk.

However, the complexity is still not handled super well, as you need to spend more time in code review and testing to make sure all edge cases are covered and the general module interconnection is decent. Ideally we want to modularize and make the breaking surface very small, but often it is not possible.

I think the next step is to fully remove people as accepting changes manually is just too brittle; I also think it is probably possible to do with the current tools but needs a very different approach from the current meta of highly specific docs.

> I don't know what jobs have been impacted yet, but there will likely be pressure for all content creators and knowledge workers to use the tools to get more work done.

You claimed that it already happened to illustrators and artists, and while I am sure they use it one way or another, I don't think it transformed the industry. Now, I am not saying that it won't amount to anything in software, I just don't think it is ready as of right now outside of greenfield projects, mostly because the scope is limited.

I am pretty positive that at some point we'll have a tool which will automate the generation -> code review -> fixing (multiple loops) -> releasing without people. Currently people are the bottleneck and imo a better way is to exclude people completely outside of initial problem statement and accepting the result. Otherwise it is just too janky, that 10x comes with a huge asterisk that can unironically slow you down after all said and done.

Wait, what, WASM has native GC now?

> JavaScript can only survive this because there’s no other option in a browser.

JS 100% respects compatibility, they even avoided some methods because some popular libraries in the past used to extend the Prototype for arrays

The summary is often incorrect in at least some subtle details, which is invisible to a lot of people who do not understand LLM limitations.

Now, we can argue that a typical SEO-optimized garbage article is not better, but I feel like the trust score for them was lower on average from a typical person.

But in a lot of cases you can't know all the dependencies, so you lean on the community trusting that a package solves the problem well enough that you can abstract it.

You can pin the dependency and review the changes for security reasons, but fully grasping the logic is non-trivial.

Smaller dependencies are fine to copy at first, but at some point the codebase becomes too big, so you abstract it and at that point it becomes a self-maintained dependency. Which is a fair decision, but it is all about tradeoffs and sometimes too costly.

Pretty much finished my photo gallery app for Windows -- https://github.com/Bloomca/Piktosaur. It is a pretty standard gallery viewer, the main feature is that you can point it at any folder and it will recursively search nested folders for extra images, e.g. an external hard drive.

Really happy with it as I wanted exactly that for myself.

---

The next idea I am going to work on is the audio player. I already wrote a Rust library to read TOC + raw track data from audio CDs (https://github.com/Bloomca/rust-cd-da-reader) and a CLI tool to do so + convert to FLAC and embed metadata from MusicBrainz (https://github.com/Bloomca/audio-cd-ripper).

I've been researching this topic and while my background is related to digital signal processing, I think I will use a library, there seem to be too many edge cases to work with WASAPI and such directly.

> Bleak, we are oversimplifying existence itself and it doesn't lead to a nice place.

We are already on this path for many-many years, certainly decades if not centuries, although availability was definitely spotty in the past.

It is also kind of impossible to hop off this train, while it is individually possible to reject any of these conveniences, in general they just become a part of life. Which is not necessarily a bad thing, but just different.

Yeah I am reading through this thread and it does feel that things can go wrong here. With alcohol/drugs it is very likely to be an extremely positive change (at least for the majority), but some people shared videogames, and while they can totally be addicting, I personally place them on the same level as books/shows/movies, and losing interest in all of that is definitely a big change.

Do you need to pay the license to keep your apps in store? Or did they deprecate some APIs and therefore removed your apps?

Honestly wild if you need to upkeep the license just to have it in store once it is published.

You have a very long way between assembly and RN/Flutter. I do agree that it helps to know these things, but you need to learn a lot more before it becomes more generally applicable.

React is not pure at all, and has a few gotchas related to updates. That being said, the JSX and composability of it is unmatched and I think the main reason React "won".

I think a logical continuation of this model is something like Solid.js, where there is no concept of re-rendering, just atomic DOM updates when observables change their values, but somehow this approach didn't get critical traction.

macOS warns you literally about every downloaded app not from MAS (signed!), unless you build it yourself or remove quarantine manually.

I think it is mostly about expectations, macOS trained people that it is relatively safe to install signed apps. If your app is unsigned, Gatekeeper will refuse to run it.

It is not that hard, DOM model is amazing, that's why there are so many frontend frameworks in the first place.

However, you'll inevitably end up with your own after some time. Even if you try your best to stay away from it, you'll need abstractions for:

  - components and lifecycle
  - some sort of templating
  - connecting your app's data and components

But you can have minimal layers for that.

Yes, you can download the form 1040 and fill it by yourself, you'd need a few Schedules attached. They all have instructions available online, your work has to send you a copy of everything they paid you and into the IRS (regular jobs always err on the side of overpaying), and while it is not hard, it definitely looks intimidating and takes time to understand, especially the deductions.

You can also just not file your taxes, if you don't owe anything (and as I said, jobs always err on the side of overpaying) they won't bother you, but most people end up eligible for the tax refund, so it is more beneficial to pay for that service.