hresvelgr

> Congratulations, you have now increased the cognitive load to be productive on your team and increased the SQL injection attack surface for your apps!

Maybe I am speaking from too much experience but writing SQL is second-nature to me and I would wager my team feels similarly. Perhaps we are an anomaly. Secondly, most if not all SQL connector libraries have a query interface with all the usual injection vectors mitigated. Not saying it's impossible to break through but these are the same connector libraries even the ORMs use.

> ORMs exist for a reason. And if I were a new senior or principal on your team I’d be worried that there was now an expectation for a junior to be a wizard at anything

ORMs exist to hide the complexity of the RDBMS. Why would any engineer want to make arguably the most critical aspect of every single IT business opaque? ORMs may imply safety and ease, but in my experience they foster a culture with a tacit fear of SQL. Sounds a bit dramatic, but this has been a surprisingly consistent experience.

I'm sure you could get even greater speed by removing Prisma. All you need is a migration tool and a database connection. Most recent example in my work where we removed an ORM resulted in all of our engineers, particularly juniors becoming Postgres wizards.

I somewhat mirror this opinion, but I would like to point out that there are scant alternatives that meet the intersection of attributes ImGui possesses. The best alternative I've seen as of late is Slint[1]. It's early days but it's looking very promising and is light enough to work on embedded systems.

[1] https://slint.dev/

While this does appear to be getting worse, I'm in the camp of letting it happen. The Node/JS ecosystem is imho completely unsuitable for serious work and this is merely the natural consequence. Let it burn, and perhaps something better will come from the ashes.

This could genuinely be a very useful tool for digesting pull requests. A tiny language model could probably do a decent job of ranking hunks by importance to enable replaying back in a more coherent order.

Looks promising. Where I think Notion really succeeds is letting people easily make attractive live documents. Where they've meandered off imho is trying to shoehorn in an RDBMS. If you can enable people to make pretty pages, and keep your document format simple, you'll be off to a very good start.

Someone can debug your program over a remote session with no extra configuration.

> men just want to be safe, satiated, and friendly to each other

I would argue AI fundamentally changes nothing in this respect. I think what we all want is freedom of pursuit, which is afforded to all as a birthright. What we are so concerned with is everyone's starting lines, and those starting lines are the consequence of an unjust society. Rand said it best in The Fountainhead:

"Civilization is the process of setting man free from men."

> Godot is nearly 25 years old. I'm sure it was awful back in 2003.

Sure, but that's kind of my point, modern software is endemic of a mindset that most things are "fast enough" that we can reinvent the wheel, repeat old mistakes, and more or less get away with it, instead of using something better suited and more purpose built.

I left a comment in the previous thread about reserving judgement until the cause is identified as it's quite common to run into weird performance issues in very complex systems (games typically being so) and its very easy to say: "modern software bad." Now that it's been elucidated, I can pretty confidently say: "modern software bad." I strongly doubt this would happen in love2d, Godot, or any other engine/framework.

The thing that made me go "oh damn" was finding out the debugger is multiplayer.

It's probably worth reminding everyone here that it's possible to write slow code in "fast" languages and fast code in "slow" languages. The state of software as it stands today is horrendous, but seeing as no one here (author included) seems to know why it's slow it's probably worth reserving judgement.

While I tend to agree, I think there's still an undercurrent of React-like paradigms being strongly preferenced in the training data so assuming LLMs continue to get much better, if you were to build a simple UI toolkit with an LLM, there's a strong chance that over time with accretion you will end up remaking React or any one other framework unless you're particularly opinionated about direction.

It's solving problems that are so far down on the list of priorities of a video game project that it will never evolve beyond a mere toy unless they really wise up. "My performance is bad because I didn't design this in a data-oriented way" is a different problem when 65% of your game is finished as opposed to solving it at "Hello, world." Hell, you can't even solve that problem unless you understand what your actually real game is doing at a data level in the first place.

Before software can be reusable it first has to be usable. There is a good reason why every existing popular engine was purpose built for a game in its infancy.

I understand trying to improve popular technologies that have issues, but for a text format with mass ubiquity, JSON has very little wrong with it to the point where I believe that projects like this are a profound waste of everyone's time.

I am all for people experimenting and making things they like, but a domain was purchased so I can only assume a serious intent to make something of this and my only reaction is that I hope this is not taken seriously and disappears.

Inflexibility is the quality I desire more and more as I get older. I don't want to force my software to do dumb shit, I want my software to force me into avoiding dumb shit. This is how you keep a system understandable. That quality is far more precious than the ability to connect complicated enterprise spaghetti machines into each other.

This seems distinctly in opposition to what I believe makes Obsidian a great program, providing an excellent editing environment and extensibility for markdown. The more it ventures into these types of features, the more they're going to lose to applications that designed for this from day dot, like Notion and Anytype.

I would argue the majority of one's time spent developing is verifying that the thing being built actually works as intended. AI has diminishing returns for the same reason your fancy text editor setup has diminishing returns, it's 10% of the job at best.

In terms of treatment, I'm under the impression that "normal" is the minimum bar of commercial productivity and psychiatry/psychology is primarily used to curtail social deviancy to maintain this.

The lovable aphorisms we had for people with character quirks were largely from our original support systems. What no one is talking about is the reason therapy-talk has become so pervasive is because all those support systems: family, friends, and local communities (religious or otherwise), have all degraded so severely for most that therapy is the only option for reaching out and getting help.

While I believe there is scant value in being a critic, a good point is nevertheless made: it should be made by practicing artists.

Elaborating on both points, as a practicing artist, paying attention to what you like is important as it shapes your tastes. Critique is useful only insofar as it allows one to create more of what perfectly embodies one's taste, whatever that may be. To be a public critic is to believe one's taste is superior. In my opinion, the only important taste is one's own to one, and should be cultivated by unabashedly following what you find intriguing.

If you're not a practicing artist, like what you like earnestly. Plenty will bemoan the state of the art crumbling, but there's a reason people still enjoy the greats of old to this day. What's good will persist.

That's a massive infrastructure change to pay out what would likely be peanuts to users, put a massive maintenance burden on the platform (payments are a nightmare system), and disproportionately benefit a law firm profiting off of the lawsuits and the good will of the brand. Seems like a shit deal to me.

> I'll bet you anything, the average ear won't care.

"Don't set out to raze all shrines - you'll frighten men. Enshrine mediocrity - and the shrines are razed."

> ECS is basically the realization that relational databases are a pretty damn good model.

A pretty darn good model for what though and to what extent? For processing millions of objects, sure. For gameplay logic, using ECS for everything? I don't know about that. What I was implying with my comment is that ergonomics are the most important trait of a good game engine.

I reach for an ECS as a last resort when the performance of a gameplay system demands it, not before. Even before that I will tweak my gameplay code to be less wasteful.

I think this has less to do with Rust and commercial game engines being better and more of a fetish that game programmers seem to have for entity component systems. One does not have to look far to see similar projects repeated in C++ years prior.

While Microsoft is certainly in the wrong for removing the copyright notice, I think the author has zero basis for complaint otherwise. If you're going to release software with one of the most permissable licenses, you need to accept that for all it entails. Consider what you're comfortable with and pick an appropriate license relative to your values.

The people I've met who have made similar remarks about C have authored some of the most heinous pointer tomfoolery I've ever seen in my life. It's a remark indicative of a hubris that has remained unchecked or worse, in denial.

> It would have been a far better language.

I like Tcl and I think it has some very admirable traits. That being said, I don't even want to picture the hellscape of an ecosystem that would have flourished if it became the language of the web. JS was the better timeline I will admit begrudgingly, and that includes the Scheme timeline as well.

I'm taking about extracting value from consumers. Capitalism/communism is a straw man here. It's the attitudes that motivate product development.

I think Mittelstand is perhaps misdirecting away from a more interesting conversation. Reading between the lines, this highlights an inherent bias in the majority of American companies to provide service to extract value as opposed to providing service for public benefit. Simply put, it's "move fast and break things" versus "WE DO NOT BREAK USERSPACE."

If you want to dig deeper, this is a consequence of America beginning in recent history as a frontier settlement, primarily attracting aggressive, adventurous go-getters to make their fortune. Extracting for personal gain was baked into the culture from the beginning and is an artifact that has persisted to this day.