Check out Progress 4GL - it lets you access database records and fields from the same language/IDE (etc) as you use to output reports or GUI or whatever. I wouldn’t want to write a compiler with it, but for business apps where 99% of the work involves trundling through the database, I can’t see how the Java/C#'s/Rubys of the world can possibly compete.
Disclaimer: I am not involved with Progress and I hate them in some ways, but I would still rather use them (for business apps).
I would love to hear Martin Fowler, Uncle Bob, or someone of like caliber and experience weigh in on this discussion.
Please revisit topic in light of LINQ to SQL and Visual Studio 2008 (and Entity Framework beta releases). kthx!
are there any non oop languages left apart from C
I bet perl 6 (if it ever ships) will be more oop orientated.
It’s oop, whether you like it or not. Doesn’t seem to stop overruns, bad code, and software disasters though
Heh, you predicted LINQ to SQL.
You don’t understand OOP. Admit it. You have problem creating domain models. Admit it.
I bet Your projects all look like C program with Main function containing all code. Milions of if-s, case-s.
Let’s take example like yours with Customers but with Employees. There are different kinds of them. How do You calculate pay for them? You iterate rows, check flag (column) and then calculate pay based on it? Are you kidding me? What if calculation should base on other tables (timecards, commissions)? You iterate other tables, check if they contain rows for Employee.Id and include them in calculationa? Are You kidding me?
Your database management system should manage your data. It almost seems like that’s the exact purpose they were designed for or something. Maybe that’s why its right there in the name?
The name Database Management System states that it manages the database. If it would manage the data, then the name would be Data Management System.
You don’t understand OOP there is nothing funnier than this statement. The fact that one programmer can justify obvious suckiness by a lack of understanding on the part of another means that there is definitely some kind of hidden deficiency in the paradigm.
Domain models are as the name states models. they were never meant to be autonomous programs.
Just my opinion, after coding in everything form assembly to multiple high level languages, from procedural to OOP style.
I’ve noticed that I can pretty much do 98% any complex problem coding using just arrays (with custom data types).
I’m not saying OOP doesn’t have its place, but its probably not the best tool in every situation.
Re: “Let’s take example like yours with Customers but with Employees. There are different kinds of them. How do You calculate pay for them?”
No, in practice there are NOT different “kinds” of employees. You are thinking in terms of hierarchical taxonomies. Hierarchical taxonomies are poor at modeling most business domains and domain objects. Modeling employees with sets of features or attributes is more realistic and more flexible. But OOP get’s ugly when it tries to handle sets. It’s not designed around sets, but rather physical objects and hierarchical taxonomies or nesting of physical objects.
If you are modeling physical objects, that’s fine, but in the biz domain one is modeling intellectual and conceptual things and relationships such as laws, management decrees, and customer and vendor inter-relationships; not so much physical things. OOP can’t give decent examples of how great it is without resorting to physical analogies. This is a sign of the weakness, the “physical problem”.
An important aspect of software development is being able to manage complexity. We see this everywhere in IT. One example is layered architectures, where higher layers don’t care about how lower layers are doing their work, etc. This is all about managing complexity. Can you imagine how difficult it would be to try and implement TCP/IP without a layered approach? In many business domains, OO programming languages are very good at helping to manage complexity. OO design patterns, when applied appropriately and correctly, can very elegantly solve complex problems, and help developers understand and maintain that underlying complexity. There is a very good reason why OO has become increasingly popular over the years, and why it is now the norm in a countless number of industries.
OO design patterns, when applied appropriately and correctly, can very elegantly solve complex problems
A very true statement, but vague enough to be true of any paradigm. It seems to me that relational, procedural, semantic(www.w3.org/standards/semanticweb), rule-based, pipeline (*nix shell),prototype-based and functional methods of process and data abstraction are all very useful; just like OO. Ideally we would use whichever abstractions (or lack thereof) suited the problem domain best, but we don’t for a few reasons:
Ideally I would use simple, extensible languages to model a problem in the most precise and elegant way. Given that it takes a better programmer than myself to do that well, I will continue to rely on ready made abstractions like OO and relational modeling. What is important to look out for is when our abstractions fail us (http://sites.google.com/site/steveyegge2/decision-time) . OO may be effective but it is not the most general or flexible means of modeling. It is represented by Trees or Acyclic Digraphs, whereas the Semantic Web and rule-based programming spans Graph theory in general. Relational algebra depends upon set theory which was considered for a while to be the foundations of mathematics. With category theory (more foundation that set theory) being of interest to language researchers, who knows what more flexible abstractions we might see?
Hi Jeff,
I just stumbled across this blog post now, ten years later, and I was wondering if you still feel the same. I intuitively think there is a lot of validity, but as a non-programmer who likes to write code with coffee for fun before work, I am not aware enough of the current landscape to have a valid opinion. Do Objects Still Suck?
I am reading this for the first time. In 2015. I also would like to know where you stand on this concept now. Currently I’m leaning towards relational database for things like user/address/phone etc and then a second database, an object oriented one for pictures and music etc. Then i’d have to somehow tie all this together. It’s about knowing the right tool for the job and your writings here have got me thinking about the appropriateness of whatever technology I happen to be using for whatever task
+1 for an update on this, or a confirmation…
I came from the future just to ask if you still have the same opinion. I’m curious about what may have changed in the last 17 years about the object-relational mapping problem.
Well I missed this topic back in 2004 when I had very strong opinions about this, having spent the last few years studying relational theory. FWIW, I still do. So since I’ve been triggered I might as well reply. (Admittedly, 60% of the triggering was someone with my name immediately replying with the kind of thing I would say about something else.
Let’s start with the brilliant, that had me literally laughing out loud:
The OO advocates (of which I used to be one!) come out in force, of course:
It’s worth mentioning that I used to be one of those, up until I started reading C. J. Date and realised that there’s a lot more going on in math than just OO. And, while we’re at it, that Smalltalk owes as much to functional programming (and particularly Lisp) as it does to Simula. The “problem” with OO is well described here too:
Haskell programmers know. :-)
To give a taste for those not in the know, Haskell has no for, while, or anything like that. In Haskell iteration of various and sometimes weird kinds is not something you need in the language because you write functions to iterate: for and while are library routines. (This is over-simplified, but you get the idea. Monads do much, much more than this.)
Nothing. The object-relational mapping problem remains a problem of OO, and is still easily solved within that by realising that the result of a SELECT has a heading that is essentially a class description that needs to be created on the fly. I would write more about this, but it’s going to need a blog entry that I’ve been meaning to do for more than twenty years now, and I hope to get to one day.
Try reading C.J. Date. He won’t weigh in in this forum, but in part because even by about 2004 he had said what there was to be said.
When you asked this in 2008 I’d already written a successful high-frequency trading system in Haskell (a very much non-OO functional programming language) and was about to do a presentation about it at a major academic conference. And these days, of course, we have Rust.
For the rest, we have the crazy people who do not understand even the most basic things about DBMSs, much less relational theory, weigh in:
So you’re saying that when I say that e-mail address is a unique key somewhere, that’s not a business rule? I’m sorry, but that actually is, and the whole point of an RDBMS (note: RDB “management system,” not “storage system,” even if you never had any idea why Codd pout that “relational” word in front of it) is to enforce such rules, so that when your software goes awry, it doesn’t corrupt the data.
Quite the opposite. If you’re sorting the full list, it will be anywhere from slightly to massively faster in the RDBMS because it has control over the I/O you need to do that. What do you think is going to happen on a host with only a terrabyte of memory trying to sort a five-terrabyte relation the RDBMS is returning? Whereas if you have an index (or moral equivalant) that lets you go through it in key order, it’s just a read from disk.
A classic case of misunderstanding by someone who’s clearly never done any serious work with network protocols. There’s a reason, a very good one, why HTTP/2 multiplexed requests over a single HTTP connection, and if that’s not instantly obvious to you, you don’t know sh*t about networking.