Laurie Voss

I agree, Doctrine has performance problems. I did some microbenchmarks too. But you could try to optimize (or write your own custom) mapping code, or maybe you could load less entities or write a better ORM. Sometimes you have to use SQL queries too (when the result of a query cannot be mapped to entities).

The "SQL and arrays" approach is much worse and doesn't scale. Without ORM and classes you will get undocumented JSON trees (or arrays) passed around.

> http://solnic.eu/2015/09/18/ditch-your-orm.html

It seems to me that author wants to replace complex approach (OOP and ORM) with even more complex one. So instead of having one object representing an entity we can have ten objects representing the entity at different moments in time. So we have to find out which one is the latest. And we will need even more memory to keep them.

He writes:

> There is no User but it’s very likely there is SignupUser.

And soon there will be LoginUser, GuestUser, ProfileEditUser, UserForReport and others. And a bunch of methods to convert between them.

I don't understand what is the problem with mutable entities. They are supposed to be mutable. I never had problems because of functions modifying arguments given to them.

I don't believe functional programming can be use instead of OOP. Can you represent a DOM tree, collection of GUI widgets, a graph of related database entitites, a form with validation rules with functional programming? You will just end up emulating classes and…

Mendix http://www.mendix.com/ (Rotterdam, The Netherlands) is on a hiring spree.

Looking for:
- Software Development Manager
- Devs (JS, C#, Java, Scala)
- Cloud Engineers (*nix, Puppet, Python, DNS, HTTP, etc),
- System Engineers (Hardware, Networking, etc)

Mendix is a fast growing Agile PaaS (100%+ per year revenue growth for the last 7 years) with HQ in Boston and R&D in Rotterdam.

We're not some startup that's hoping to score a big hit, we're trying to change the world of software development.

If you've read "Blue-collar knowledge workers will save the economy" (http://seldo.com/weblog/2012/08/30/software_developers_can_save_the_economy), well, that's basically what we are doing.

We cater mostly to large businesses and deliver applications through our network of partners.

We're looking for a Software Development Manager to orchestrate R&D (25+ people) and report to the CTO.

You should:
- have a hands-on mentality
- be a great fit with the team
- have at least 10 years of experience in software
engineering, including hands-on programming skills
- think that Agile/SCRUM is a good idea
- speak Dutch

This is a tough job but the salary will match.

We're also looking for very good developers / system engineers.

We work with the languages listed above, but if you're very good you can probably learn them soon enough.

Our team is great and we've had multiple international developers, however, relocation is required.

You can contact…

She makes a bunch of great points, but as someone who has worked on several projects with a properly implemented ORM, I find that I have to disagree with the post.

It sounds like a lot of people who are Anti-ORM in the comments (here, and on her blog), are focusing on the saturation of relational databases, and touting that NoSQL style data stores are a better fit for certain problems.

No argument here

But in a relational DB, assuming you are using it for its intended purpose (storing relational models, and not "objects"), I don't see why anyone would want to eschew the use of a proper ORM, with the exception of incredibly small projects with minimal database access.

For medium to large projects, I've never once regretted using an ORM. Not having to write my CRUD statements? Having all of an objects relational data lazy-loadable and at my finger tips? Sign me up! Just my experience.

I feel as though this author has worked in environments with other developers who didn't "get" the benefits of ORMs, and thus the implementations of those ORMs suffered. This is just my opinion from what I've read. I could be wrong here.

Death by a thousand queries, however, is a completely valid complaint. In fact, it's my one of my only major gripes with ORMs. But maybe I've just never run into these cases that the author has that makes ORMs so unbearable to use. Maybe i'm just lucky?

Also, she re-blogged this from several months ago:…

Doctrine 2 also often spends 10x the time on post-processing the data from the database as it does actually making the database calls itself (it's not fixable without dropping to straight SQL out of the ORM). Its query language is atrocious and unnecessary. Their ideas of joins and internals are absolutely horrific. The boilerplate is 1/3 of my app. But even if it was the perfect piece of code (it's exactly the opposite: total and utter shit), I'm not going to slow down all my DB queries 10x for anything, not to mention the incredibly slow development speed of now having two query languages and a million wrong ways of making simple queries and no ways of making proper advanced queries. Everything with Doctrine takes many times longer than with straight SQL even after years of working with it. I have yet to find an ORM that doesn't have egregious failings like Doctrine 2. It is inherent in the stupid concept of ORMs that implementations fail. See:
http://solnic.eu/2015/09/18/ditch-your-orm.html
http://seldo.com/weblog/2011/06/15/orm_is_an_antipattern
and most importantly, see benchmarks for ORMs like Doctrine and observe their destructive effects on programmer productivity.

Cool story. A more marketing-oriented person being CEO is a better choice for a community-oriented organization, and should have been made by the board in the first place. This [1] puts it succinctly. "The mistake made was not made by Brendan Eich" and "The people who messed up here are the board of the Mozilla Corporation." This is Mozilla's board doing what they should have done all along, except that Brendan Eich can't be CTO anymore.

1: http://seldo.com/weblog/2014/04/04/on_brendan_eich_equality_and_freedom

Yeah, the "generative" in "generative AI" gives a little bit of a false impression. I like Laurie Voss's take on this: https://seldo.com/posts/what-ive-learned-about-writing-ai-apps-so-far

> Is what you're doing taking a large amount of text and asking the LLM to convert it into a smaller amount of text? Then it's probably going to be great at it. If you're asking it to convert into a roughly equal amount of text it will be so-so. If you're asking it to create more text than you gave it, forget about it.