zerr

It's getting harder to pick between Pharo vs Eiffel for a new project :)

It never was a priority I believe. As opposed to C, the main target audience of C#/.NET has always been LOB CRUD app shops.

Isn't Crystal significantly more expressive than Golang?

Maybe it is intended for LLMs? For writings of more than a page, most readers are going to use LLM summarizations anyway.

Well, there is just horse riding as well, done for fun. I think this is a better analogy.

I wonder how much did it cost.

For the backend, any plans switching to Raku (Perl 6)?

I was expecting some Turbo Vision based TUI IDE.

This is common in Lisps.

Articulating about architecture (as opposed to engineering (as opposed to programming)) is a part of coping I believe. Yes, LLMs do architectures as well. I think the vibe-coding is the more precise term, also considering that less and less human reviews are being done.

> // Copy the position of every entity into the MultiMesh buffer

So, is a zero-copy impossible due to world (C++ vs Godot) boundaries?

You apply for regular jobs and negotiate part-time hourly or daily rates. Stay away from freelance platforms, maybe just for finding leads, then contact them directly.

I've stumbled upon DOS on the LCD screen of the otherwise seemingly modern gas station.

> it does take some skills, judgement, taste, knowledge, time and effort to build things

As of now, but we are talking in a perspective.

So the keynote mentions that in a perspective you are going to be a "maker of things" rather than a coder. But, nobody is asking, in a perspective, why would anybody use the stuff you "make" rather than using AI directly? All of the notion of apps disappears, in a perspective.

Yes, you have to draw everything. Not exactly "SetBkColor" :)

> nobody uses Win32 scroll bars

Because it is impossible to change its color. It was/is not uncommon to see custom/dark skinned Windows apps with ugly gray scrollbars looking at you. Even today, only Light and Dark themes are supported, impossible to set a custom color.

Since vibe-coding solved the issue of manpower, why stick to Electron and js frameworks?

I believe it would be helpful for those who would want to continue development, contribute to the project.

Pro-AI people now argue that the code is ephemeral nowadays, we should not look at it like we don't look at generated assembly (most of the devs). So in this regard, sharing only the "assembly" doesn't make sense, it's like sharing only the binaries and calling that open source (before LLM days).

For vibe coded open-source projects, I believe the prompt session/history should be shared as well.

I mean, is it OpenGL, Vulkan, Metal? etc...

What do they use for graphics and audio?

Not sure how long the current subsidized pricing would last. Also, the vast majority of software shops can't afford those subsidized prices anyway.

If you are product-driven why not go into Product Ownership roles? It certainly will be more satisfying compared to prompt "engineering" clerk "career".

I have an opposite concern - how do you find companies that don't force devs to become prompt engineers?

You are doing it right. Publicly shaming them on HN is the only way to get a real customer service.

If we follow that logic, I believe it means that you would be quite happy in the Product Owner role, or in the role of a client who outsources the actual development activities. I wouldn't.

Yes, engineer experience/happiness is part of the equation. The company also thinks that agentic workflow will clutter the codebase.

As an engineer, the enjoyment from the process is not less important, or should I say more important, than the enjoyment from shipping a final product.

I code by hand (sigh) and copy paste some snippets once in a while from a web chat LLM. This also means every single line of such snippets gets reviewed and anaylzed. Usually, these are some arcane Win32 API usage where otherwise I'd have to dig into old forums. I don't want to become a prompt engineer so I stay away from "agentic" workflows.