Kuro5hin.org: technology and culture, from the trenches
create account | help/FAQ | contact | links | search | IRC | site news
[ Everything | Diaries | Technology | Science | Culture | Politics | Media | News | Internet | Op-Ed | Fiction | Meta | MLP ]
We need your support: buy an ad | premium membership

[P]
Only 35% object oriented

By ucblockhead in Technology
Wed Apr 16, 2003 at 11:24:29 PM EST
Tags: Software (all tags)
Software

One reason why I'm leery of the buzzword of the day. A project gone bad.


About twelve or thirteen years ago, I worked for a small Point of Sale company. Their original product was written in very poor C code and during my first stint there, I had made my opinions on that system well known. Eventually, I left that company, partly because I tired of writing old K&R style C for a Z80, and took a job writing more standard C code.

About a year later, I was hired back to take a lead position on a new Point of Sale project. The project was to be an entirely new Point of Sale system, designed from the ground up to be flexible and easy to maintain. It was written in C++, but by C coders. The choice of language mostly had to do with C++ being the "hot" language. (And part of this had been because I'd been selling the management C++ when I had previously worked there.)

I was brought in for a couple reasons, partly political, and partly because though I'd never done C++ code professionally, I had done a bit with it in college, and was known as an advocate. At the time, very few coders had much experience. C++ compilers had only existed for the PC for a couple of years.

At the time, the system was not complete. The base design was there and my job was to take the project to the customer release. That mostly meant developing particular features needed for the first installation, along with general debugging. There was also a mandate from on high to "make sure it is object oriented" for reasons that were not made clear.

The code was quite good. The C coders had, I thought quite rightly, played it fairly conservatively, using C++ mostly as a better C, being cautious about what language features they used. As a result, the system was very C like. But it worked well, and was relatively bug free. It was a data-driven system, so that most of the functionality of the system could be changed by database entries.

We made our first deadline, delivering the first customer release on the expected date. During that time, I had personally worked on adding new classes, where it made sense. (I still remember the first classes I added, as part of the SQL interface.) This went fairly well, and soon the C coders where doing real C++ on their own, following my examples. But despite this, the program still had a lot of C-isms. But we weren't particularly concerned, because the system otherwise met our goals. It was quick. It was lean. And most importantly, given our particular market, it was flexible. Most common changes could be done without even hitting code, and by product managers, not coders.

At the time, about ten man-years had been invested in the product. We estimated that with another ten to fifteen man-years, we could complete the entire thing as a generic point of sale system. We also figured that we'd slowly improve the OO (object oriented) nature of the system. (The word "refactoring", of course, did not yet exist in the programmer's lexicon.) Since the first customer release (a two man-year task) came right on time, to the day, I'm confident that this estimate was accurate.

We were a small company, with small company money issues. Our CEO managed to sell our new project to a very large company. This very large company also had a point of sale system near the end of its lifespan. So we sold our not-yet-complete system to be the basis for their new one. They were in a hurry. They wanted the project completed in a year.

No problem, we thought. The five of us were flown out to meet with the thirty to forty people they had to work on the project. Given the scope of the project, this should be a snap. The only fly in the ointment being that none of their people knew either C++ or object oriented design. Still, we figured, thirty people, ten man-years, no problem. We'd managed to keep things on time in the last release despite the C++ learning curve.

They also wanted it to be "object-oriented". They did a code audit on our stuff, which came up mostly positive, but with the caveat that it was "only 35% object oriented".

The big company then decided that this wasn't enough. They were going to instead design their project from scratch, not using our working version, but using us for our expertise in the language. At the time, I found this a bit paradoxical, simultaneously telling us that they wanted us for our OO skills, and that our work was not OO enough.

But we were not the only OO expertise on the project. They wanted object oriented design expertise. So they brought in some Smalltalk guys from another branch of of the company to teach us object oriented design.

"But we have a working product!", we said...

The Smalltalk guys didn't like C++'s object model, so they immediately set about to using this odd design methodology called "exemplars" to try to force dynamic class creation on C++. Of course, none of the original coders had a clue about all this. I was the most experienced OO guy, and I barely did. Still, it was interesting...but the sort of thing I'd play with for a year or so before using it in real work.

We then proceeded to spend the next three months arguing about what should be classes. Our group argued that much of the knowledge should be stored in tables, and not in code, but we were constantly overruled by the Smalltalk guys, who did not seem to understand the concept. (We later learned that these guys had little production experience, and mostly worked in more academic arenas.) They wanted every little thing in the code, so that, for example, to create a system to take an American Express card, you'd make a subclass of the CreditTender object. (As opposed to our system, where you'd just add a table entry.) "But that's not OO!", they'd say, as if that were the only constraint.

Of course, this directly contradicted one of the design goals, which was to create a system that could be modified by non-technical people, so there was lots of fudging. I once even heard it suggested that the product people could be taught to program!

Anyway, after three months of this, nothing had been produced. Nothing. Not even a design document. Just lots of wrangling about what the "right" object hierarchy was.

Then they sent us packing. Our company went under, taking our working, but not completed, POS system with it.

The big company did not make its one year deadline. It was well over five years before it released an initial version. (With forty people...we'd created something salable in two years with five people.) That version was just slightly more functional than our original one, and was far less flexible. You had to recompile to make almost any change. Want to take layaways? That's a recompile. What to take JCB cards? That's a recompile.

The product was a marketplace failure.

Buzzwords are not goals. If you let buzzwords overrule your requirements, you are in for a world of hurt.

Sponsors

Voxel dot net
o Managed Hosting
o VoxCAST Content Delivery
o Raw Infrastructure

Login

Poll
Is your current project
o Object Oriented? 35%
o SOAP compliant? 1%
o .NET? 9%
o Client Server? 8%
o Three Tier? 8%
o Doomed? 35%

Votes: 295
Results | Other Polls

Related Links
o Also by ucblockhead


Display: Sort:
Only 35% object oriented | 250 comments (233 topical, 17 editorial, 0 hidden)
Another paper I read (4.00 / 1) (#5)
by KWillets on Wed Apr 16, 2003 at 06:32:18 PM EST

I have a book of papers about next-generation database design.  One of the funniest ones was about a "real-life" OODB project.  It was kind of the same thing; it had lots of hooks for object-orientation, but no query language, and it was very hard to maintain.  The performance bottlenecks were also a rude surprise, and they ended up wasting a lot of time on unexpected problems.

One question might be:  how was the "OO" used?  Did you have a high-level data model to guide the object structure, or was it roll-your-own classes?

roll-your-own classes (5.00 / 1) (#8)
by ucblockhead on Wed Apr 16, 2003 at 06:40:20 PM EST

We were cautious, so it was mainly a matter of people looking at a piece of code, saying "this could be better with classes", and then changing it.

As an example, originally SQL access was C-like. You got structures from the SQL interface. We put a layer on that, where you instead got classes back, with methods like "update".

One roadblock was that a lot of the "natural" objects in the space we were working in were entirely in data. Truth is, "35% object oriented" was being generous. I'd have rated it lower.
-----------------------
This is k5. We're all tools - duxup
[ Parent ]

Replicating the data model (none / 0) (#12)
by KWillets on Wed Apr 16, 2003 at 07:00:56 PM EST

It sounds like you were using the previous data model and translating some entities into objects.  It's not a bad idea, but I don't see why people didn't do a formal design, especially with 40 developers.  

[ Parent ]
They tried! (4.00 / 1) (#14)
by ucblockhead on Wed Apr 16, 2003 at 07:07:24 PM EST

They just sucked at it. They were trying to do formal OO design, and just had no concept of it. (Even the OO design guys.) It was all this babble about finding some platonic ideal representation of everything in the target area.
-----------------------
This is k5. We're all tools - duxup
[ Parent ]
To Paraphrase Husserl (none / 0) (#15)
by KWillets on Wed Apr 16, 2003 at 07:14:50 PM EST

An abstraction is a real thing with some of the attributes removed.  

They just didn't remove enough.  A few walkthroughs with users might have given a good reality check.  You don't even need code, just images of screens to show how the system should work.

[ Parent ]

Users (4.50 / 2) (#24)
by ucblockhead on Wed Apr 16, 2003 at 09:26:09 PM EST

Part of the problem was there were two divergent sets of users. It's kinda like scoop. You've got the people who visit scoop. Those are the ultimate users. But you've also got the people who need to maintain and modify scoop for their particular site. Those were the users that were getting short shrift here. But since our company was the ones originally doing the modifications for each installation, we were essentially that second set of users. As such, we knew the requirements real well.

Traditionally these modifications were made through C code. Our first product mode much of this to a set of data screens that a product manager could use, without programming knowledge.
-----------------------
This is k5. We're all tools - duxup
[ Parent ]

Funny thing, OO decended from data modeling (none / 0) (#52)
by lukme on Thu Apr 17, 2003 at 01:10:16 AM EST

Just listen to how you data modeler speaks. You will here many OO notions (as well as several which are database specific).


-----------------------------------
It's awfully hard to fly with eagles when you're a turkey.
[ Parent ]
Well Yes (none / 0) (#59)
by KWillets on Thu Apr 17, 2003 at 01:29:39 AM EST

I used to be a data modeller, during the economy.

90% of data modelling is the same, whether based on relational, OO, or otherwise.

[ Parent ]

C++? Meh. (3.60 / 5) (#16)
by egg troll on Wed Apr 16, 2003 at 07:18:07 PM EST

Everyone knows the future belongs to Objective-C!

He's a bondage fan, a gastronome, a sensualist
Unparalleled for sinister lasciviousness.

sure (5.00 / 1) (#21)
by zephc on Wed Apr 16, 2003 at 09:12:05 PM EST

once they get proper (automatic) memory management in the runtime (I'm thinking OS X's ObjC runtime system here)

[ Parent ]
Yeah that bugs me too (none / 0) (#33)
by egg troll on Wed Apr 16, 2003 at 10:07:12 PM EST

I really do hate the retain/release system of memory management. Having to manually keep track of my object count is a little annoying. But that dynamic binding sure is purdy!

He's a bondage fan, a gastronome, a sensualist
Unparalleled for sinister lasciviousness.

[ Parent ]

And malloc/free is better? (none / 0) (#99)
by lowmagnet on Thu Apr 17, 2003 at 10:30:20 AM EST

I like retain/release. There are also automatic releases too.. it's not *that* bad

[ Parent ]
Which is what we all say (4.75 / 4) (#155)
by Fountain Pen Converter on Thu Apr 17, 2003 at 03:57:06 PM EST

... once we get used to the 'features' of our languages of choice. For me, those currently include Java, Python, and when I get the chance to use it, Scheme.

Scheme
  • Forcing explicit structure through parentheses is a Good Thing - and besides, it's not that bad once you have an editer that matches parens for you.
  • Functional programming isn't that bad - it's pretty easy to understand if you come from a math background.
  • your peeves here

Python
  • Whitespace as block delimitor forces good coding conventions - and it's not that bad if you edit in an editor that displays tabs consistantly.
  • It's not so bad that slice notation looks a lot like array access - just remember the colon.
  • et cetera

Java
  • It's not that bad that Sun doesn't open up the language to standardization groups - we can trust them, right?
  • Nobody really needs multiple inheritence, and even in cases where it might be easier, the workarounds aren't that bad.
  • The primative datatypes are really useful for small-footprint programming, and converting in and out of the wrapper classes isn't that bad once you remember that you have to do so for most of the built-in complex datatypes in java.lang.*.
  • oh, don't get me started

In fact, it seems like "it's not that bad" is what people say about the broken aspects of all manner of complex systems that they have come to know and love. Certainly it seems the case that once RPG twinks learn cracks in their favorite systems, they are unlikely to give them up in future editions - D&D 3rd Edition is a huge case in point.



----------------------------------------
Always striving to have a point.
[ Parent ]
That's because it all sucks (5.00 / 1) (#238)
by epepke on Mon Apr 21, 2003 at 01:18:17 PM EST

There is no memory-management model that does not suck.

Retain counts are simple and fast, but they suck because they cannot handle circular structures.

Batch mark-and-sweep garbage collection is fast, takes no stack space, and only requires one bit per pointer, but it sucks because you can't do anything else during a garbage collection, and a collection has to look through all the allocated memory.

Generational garbage collection sucks because it takes more bits and time and is only heuristic.

The train algorithm sucks because, while it guarantees an upper bounded time per step, the total time per unit of memory is huge, and you need a lot of bits.

And they all suck because all modern processors are basically C machines without any hooks to make the stack understandable in the context of memory management.

And conservative ways of looking for memory in the stack suck because there's always the chance that random garbage on the stack will make much of the heap unusable and you'll sometimes have to recode for weird processors.

Of course, it isn't just memory management. Pretty much everything in CS sucks.


The truth may be out there, but lies are inside your head.--Terry Pratchett


[ Parent ]
In this case it would have been better (none / 0) (#89)
by Per Abrahamsen on Thu Apr 17, 2003 at 08:55:37 AM EST

They tried to implement a Smalltalk design in C++, which is silly.  The Objective-C object model is much closer to Smalltalk.

[ Parent ]
No no no (2.00 / 1) (#119)
by CodeWright on Thu Apr 17, 2003 at 12:03:12 PM EST

C#

--
"Humanity's combination of reckless stupidity and disrespect for the mistakes of others is, I think, what makes us great." --Parent ]
No, not really (none / 0) (#219)
by Dr. Zowie on Fri Apr 18, 2003 at 02:30:03 PM EST

The problem with Objective C is that C++ is too entrenched. Dynamic objects in C++ still drag a bit but the fact that they exist eliminates most of the dichotomy of the olden days (early 1990s), when C++ was still basically a lexical preprocessor for C. Last I checked, there's no "killer app" for Objective C over C++, so it's not that likely to come back strongly.

I spent a summer in those early days learning THINK Objective C for the Mac -- it was a pretty cool framework, and the THINK class libraries were very useful. I wrote a telemetry monitor for a sounding rocket. We debugged it and the rocket flight software together over about five months, then everything ran beautifully at the missile range (for 14 minutes). Then the mission was over, we mothballed the computers, and THINK folded up their operation. I think that Macintosh objective C continued for a few years after that, but it eventually lost out to the Metrowerks C++ compiler. Ever since then I've always thought of Objective C as a cute also-ran in the language wars.

[ Parent ]

The Curse of Apple (4.00 / 1) (#220)
by egg troll on Fri Apr 18, 2003 at 04:24:12 PM EST

To me, Objective C is to C++ as the Apple is to the PC: a better designed product that never received the praise and popularity it deserved.

He's a bondage fan, a gastronome, a sensualist
Unparalleled for sinister lasciviousness.

[ Parent ]

Objective-C not a game language.... (none / 0) (#237)
by slur on Mon Apr 21, 2003 at 04:46:18 AM EST

I like Objective-C for implementing desktop applications, and I might even write a bit of music software with it, but for games I'll stick to C++. C++ may not be as eloquent or compact as Obj-C, but it has the advantage of hardly any runtime overhead, and it's much quicker to shunt C functions into C++ classes than it is to do the same thing with Obj-C.

All languages have their strengths and weaknesses, so I can't get religious about any one language. Each one has its appropriate uses.

|
| slur was here
|

[ Parent ]

These quotes will live on in my nightmares ... (4.40 / 5) (#19)
by blackpaw on Wed Apr 16, 2003 at 07:32:33 PM EST

They also wanted it to be "object-oriented". They did a code audit on our stuff, which came up mostly positive, but with the caveat that it was "only 35% object oriented".

one of the more moronic comments I've ever heard - 35% ? what kind of metric is that ? <shudder>

they wanted every little thing in the code, so that, for example, to create a system to take an American Express card, you'd make a subclass of the CreditTender object. (As opposed to our system, where you'd just add a table entry.) "But that's not OO!", they'd say, as if that were the only constraint.

Were these guys fresh out of college ? sounds like they thought they were still doing CS projects for their classes.

I'm actually a C++ nut, almost all my work is C++ (or Delphi), but I would have given those guys the boot if I could have - I certainly don't believe in objects for objects sake, I still write C and assembler or VB when its called for.

Consistency metrics (5.00 / 6) (#72)
by CaptainZapp on Thu Apr 17, 2003 at 04:54:39 AM EST

one of the more moronic comments I've ever heard - 35% ? what kind of metric is that ?

I can top that. When I worked for the professional services department of a database vendor we got a request for proposal from a company, whose name i'll withhold for obvious reasons.

One section stated that it is a requirement, that the database is 80% consistent at all times

[ Parent ]

I imagine (none / 0) (#95)
by xL on Thu Apr 17, 2003 at 09:29:49 AM EST

Some lawyer or other droid at that company really thought he was being smart adding that. Isn't that sad and funny at the same time?

[ Parent ]
Let's put it that way (none / 0) (#246)
by CaptainZapp on Tue Apr 22, 2003 at 01:26:49 PM EST

Proper project management training taught me a few things:

  • Stay away from projects, which scope and functionality you can not properly assess, especially when it's a fix cost project
  • Avoid projects where there is no clear sponsorship (this means one and exactly one sponsor who has the yes and no say on the project) and get it into the contract
  • Leave projects which begin with such a request for proposal cheerfully to the competition...

    [ Parent ]
  • Crazy softwaqre (3.50 / 2) (#20)
    by obsidian head on Wed Apr 16, 2003 at 09:00:30 PM EST

    It reminds me of a recent experience.  The customers were VCs.  The product was Java + XML.  Classic dot-com scenario which was basically a legal crime.

    It used the worst possible combination of Java and XML.  Take the worst parts of Java and combine with the most inexpert usage of XML.  Mix with internet as glue.

    The inevitable death was by no means a tragedy.  I was glad it happened and knew it before I joined.

    I wonder why though, your CEO decided to bet the farm on these guys.  Was he failing to find other customers?  He should have been charging them out the wazoo for tying up his development team.

    Could you be more specific [OT] (none / 0) (#26)
    by schwong on Wed Apr 16, 2003 at 09:36:01 PM EST

    ...about what they were doing wrong with Java and how they were using XML inefficiently? I'm working on moving a relational database to a more web-friendly Java/XML model and I'd be interested to know what mistakes they made -- but more than that, it sounds like a great story.

    [ Parent ]
    XML (4.00 / 1) (#28)
    by ZorbaTHut on Wed Apr 16, 2003 at 09:45:53 PM EST

    While I don't know much of Java, I know a bit of XML . . . the issues are that there's no easy way to either randomly seek inside an XML file or modify it. Since it's all text, changing a single field near the beginning of the file can require rewriting the entire thing. The only "solution" is to read the entire thing into RAM and work with it from there, which works fine if you've got 5k files and fails miserably if you're trying to play with hundreds of megs of data. (And even more so if your database is on the multiple-gigabyte level.)

    Without knowing more about what you're doing, you might not be vulnerable to these problems or you might have cleverly sidestepped them. I personally use a stripped-down XMLish format for a lot of things, but anything that needs to be large gets stored in binary files.

    [ Parent ]

    Not the only solution (none / 0) (#40)
    by kraant on Wed Apr 16, 2003 at 11:49:03 PM EST

    The only "solution" is to read the entire thing into RAM and work with it from there,

    OTOH You can also handle the XML as a stream and use a sausage grinder mechanism to parse the XML and make changes without loading the whole lot into memory.
    --
    "kraant, open source guru" -- tumeric
    Never In Our Names...
    [ Parent ]

    True (none / 0) (#48)
    by ZorbaTHut on Thu Apr 17, 2003 at 12:40:51 AM EST

    I was thinking about it in terms of a relational database, where you'll have lots of random accesses and modifications. But yes, if your process can be done serially, you can indeed do it that way.

    [ Parent ]
    Hrrrrrm. (none / 0) (#67)
    by kraant on Thu Apr 17, 2003 at 03:16:45 AM EST

    Well then what about having more than one XML file and then having a separate index? But yeah I see your point, XML all the way through is kinda silly. As long as you can input XML, and emit, it that should be good enough.
    --
    "kraant, open source guru" -- tumeric
    Never In Our Names...
    [ Parent ]
    Re: Hrrrrrm. (none / 0) (#203)
    by warrax on Fri Apr 18, 2003 at 05:30:47 AM EST

    Well then what about having more than one XML file and then having a separate index?

    You've just described a database. :). This is well known territory and you can find relational databases for every possible application. Now, the problem may not lend itself to relational databases easily and I'm not familiar with any hierarchical databases, but I'm pretty sure that alternatives that are way better than indexed XML exist. Anyway, indexed XML can still cause problems when you want to modify the data.

    But yeah I see your point, XML all the way through is kinda silly. As long as you can input XML, and emit, it that should be good enough.

    I find that XML is a useful input format if you're going to let users edit the input manually. It's not ideal, but it avoids having to write your own (buggy) parser, and escaping, nesting, etc. are all standard. What I really want is something like this which is both terse syntax-wise, but also easy to read/understand. Unfortunately, it doesn't seem to have stabilized quite yet.

    -- "Guns don't kill people. I kill people."
    [ Parent ]
    What's good about XML (none / 0) (#208)
    by kraant on Fri Apr 18, 2003 at 10:14:25 AM EST

    YAML looks interesting...

    looks a bit like LISP S-Expressions without the parenthesis...

    Or am I barking up the wrong tree?

    To be honest the best thing about XML is that everyone is using it...

    That whole network effect thing.
    --
    "kraant, open source guru" -- tumeric
    Never In Our Names...
    [ Parent ]

    Sure, but I doubt it applies to your case (5.00 / 2) (#85)
    by obsidian head on Thu Apr 17, 2003 at 08:47:05 AM EST

    First, this is a forum message I think is more useful to you:
    http://discuss.fogcreek.com/joelonsoftware/default.asp?cmd=show&ixPost=38648 &ixReplies=9

    I mentioned my company sold Java + XML, and I tried to mean that it didn't matter what app it precisely was, from the VC perspective.  It could have been any blob of Java + XML.

    • Java:  used a clientside front-end using Swing, which is the notoriously troublesome part of Java (in enduser terms; but it's nice to code in, and is good on the Mac).  Especially since it was meant to do pretty detailed graphics work for designers.  The Java servlet + Oracle backend was fine, though Oracle was certainly overkill here.

      JProbe's mem debugger saved me once when I had to hunt down someone's memleak.  Turned out to be a thread which kept accumulating objects.

      You probably know this, but Ant is the standard for making builds.  Bugseeker is a good debugger, if you like to use them.  Everyone but me used the JBuilder IDE, and its debugger was extremely slow, so Bugseeker was used.

      Jython is a great tool, though I wasn't able to use it much.  If you don't trust your coworkers though, you'll probably want them to suffer under Java's S&M.

      Tomcat is an extremely frustrating servlet implementation to configure, though it's ok when you get it to work.  I hear Resin is far, far better, though I haven't personally used it.

    • XML:  XML, used properly, isn't very deficient.  It's really better for transmitting data than persistently storing it.  Caching solved performance problems.  The only problem was they kept the data API too closely wedded to its first internal representation.  For example, it made the assumption that all data would be nested exactly 3 levels deep.

      I switched to Electric XML, the author of which seemed to have a religious commitment to quality.  (It probably still comes with sourcecode.)  It was small, fast and very bugfree.


    The main downfall of the company was that the CEO kept making mistakes everyday, and it was contagious.  All the classic problems:  sales had poor communication with devs, people who were paid less often got lied to and shouted at.  Many ended up suing.  And they threw away hundreds of thousands on servers and redundant bandwidth, though the right strategy is to start out inexpensively and then scale up.  There were like 4 customers at most.

    As you can see, the real problems were social.  I'm sure you'll do great banging out a good first sketch and then profiling to find any performance/scalability problems.  I only suggest you stick with a subset that is understandable and stable.

    [ Parent ]

    Holy crap man... (none / 0) (#242)
    by schwong on Tue Apr 22, 2003 at 02:23:46 AM EST

    ...talk about going above and beyond. Thanks.

    [ Parent ]
    This would have never happened if... (3.55 / 9) (#23)
    by SleepDirt on Wed Apr 16, 2003 at 09:24:16 PM EST

    They had just used the power of .NET and C#

    "In a closed society where everybody's guilty, the only crime is getting caught. In a world of thieves, the only final sin is stupidity." - Hunter S. Thompson
    Behind on buzzwords (4.00 / 3) (#25)
    by dark on Wed Apr 16, 2003 at 09:28:37 PM EST

    What is this "Three Tier" in the poll?

    Distributed application architecture (5.00 / 5) (#34)
    by CaptainSuperBoy on Wed Apr 16, 2003 at 10:07:31 PM EST

    The components of an application are often described in tiers. Ideally the tiers should handle the tasks that are best suited to them, for instance you may not want the same code to be drawing on the screen and managing data storage.

    In a three tiered app, traditionally your first tier is the user interface which should do as little processing as possible. This allows you to separate the application's logic from its implementation - so the logic goes in the second tier, which is probably some kind of distributed objects. Could be EJB, or an XML web service, or whatever. The goal there is, if your business objects are done right you can use anything as a front end without worrying that all your implementations are correct. Your third tier handles your data storage. Many people like that level of separation because they can release a single product that works with multiple database backends.

    --
    jimmysquid.com - I take pictures.
    [ Parent ]

    buzz words had nothing to do with this (4.25 / 8) (#30)
    by scatbubba on Wed Apr 16, 2003 at 09:46:46 PM EST

    Poor management decisions and incompetent technical leadership was the cause of this disaster. Lots of people deploy successful, true OO solutions.

    OO (4.11 / 9) (#36)
    by ucblockhead on Wed Apr 16, 2003 at 10:31:11 PM EST

    Yup, me too! My goal wasn't to knock object-oriented programming so much as show how a project can get derailed when people focus on the latest buzzword rather than rationally and conservatively applying techniques with the real goals in mind. The project was not a disaster because of object orientation. It was a disaster because the people running the project though object orietantation was a goal, whereas it is only a means to and end.
    -----------------------
    This is k5. We're all tools - duxup
    [ Parent ]
    bad management decisions (none / 0) (#217)
    by bolthole on Fri Apr 18, 2003 at 01:23:15 PM EST

    Actually, letting management make ANY design decisions about the code, particularly "it will be in this language", and "it will follow this style", is already a bad decision. that stuff should be left to the project (technical) leads.

    [ Parent ]
    Keeping it simple (4.66 / 6) (#31)
    by mstefan on Wed Apr 16, 2003 at 09:47:46 PM EST

    This is the problem that many developers seem to have; that urge to over-design and use all of the latest 'gee-whiz' features of a language, or even worse, of a specific compiler. Simplicity in design and implementation is the cornerstone to stable, portable and maintainable code.



    The tricky part... (5.00 / 4) (#41)
    by enthalpyX on Wed Apr 16, 2003 at 11:49:30 PM EST

    ... is determining what is involved in keeping it simple. While it's certainly a good maxim to hold to, what will make life the simplest is not necessarily obvious all the time. Oftentimes there are tradeoffs involved between short-term simplicity and long-term simplicity.

    I think this is mostly intuition-- and only comes from experience-- propped up by the scars of trial and error.

    [ Parent ]

    keeping it simple (3.66 / 3) (#44)
    by ucblockhead on Wed Apr 16, 2003 at 11:59:56 PM EST

    Part of "keeping it simple" is being cautious when applying new technologies. It never pays to be on the bleeding edge.
    -----------------------
    This is k5. We're all tools - duxup
    [ Parent ]
    Well (none / 0) (#74)
    by greenrd on Thu Apr 17, 2003 at 06:00:08 AM EST

    Someone has to be. Not all new techniques/technologies are equally dangerous. AspectJ is pretty safe, for example, I think.


    "Capitalism is the absurd belief that the worst of men, for the worst of reasons, will somehow work for the benefit of us all." -- John Maynard Keynes
    [ Parent ]

    why the bleeding edge can be dangerous (4.66 / 3) (#77)
    by hardcorejon on Thu Apr 17, 2003 at 07:55:43 AM EST

    The problem with bleeding-edge technologies is not that they are inherently bad, or even that, being young, they tend to be immature.

    The problem is that if the tech hasn't been around a long time, there aren't many people that truly understand all the nuances, trick, traps, pitfalls, and typical design issues involved in using it. Or, perhaps most importantly, there are few people who really understand the situations when the tech is applicable versus when some other, less "sexy" technology will provide a simpler, easier, and generally better solution.

    So the tendency can be to overuse or misapply the technology. But as I said, it all depends on your team, this is a people/experience problem related to using very new tech, not an inherent problem in the tech itself.

    - jonathan.

    [ Parent ]
    Simplicity is always the most complicated part (5.00 / 1) (#76)
    by porkchop_d_clown on Thu Apr 17, 2003 at 07:42:39 AM EST

    Having the vision to see how to make it simple. That kind of clarity is rare. When I pull it off, I always feel a rush..

    Well, all right. I only felt that rush once but I'm pretty sure I'd feel it again if I managed to find the simplicity...


    --
    Tablet is the wrong medicinal analogy: suppository more adequately describes the Smart Display experience. - Rupert Goodwins


    [ Parent ]
    Unfortunately (5.00 / 2) (#108)
    by dachshund on Thu Apr 17, 2003 at 11:21:26 AM EST

    This is the problem that many developers seem to have; that urge to over-design and use all of the latest 'gee-whiz' features of a language, or even worse, of a specific compiler

    Unfortunately, you're caught between a rock and a hard place. On one side, you've got a group of developers who are all most comfortable with their own pile of (often) outmoded or inappropriate tools. On the other side, you've got management pushing for the use of another group of totally inappropriate tools.

    The project I'm working on right now is a nightmare mess of legacy Awk and Perl combined with new Java code. Most of us don't code Awk these days, some don't do Perl, and yet it never seems to make sense to write and compile Java code to handle something that a two-line script should be able to deal with, just because Java Enterprise components are the big new thing that excites management.

    The lack of strong technical management is the bane of most companies' existence. Someone has to take control of the mess and say "hey, this is the way we're going to do it, because it makes the most sense."

    [ Parent ]

    Re: Poll (4.00 / 1) (#32)
    by Canthros on Wed Apr 16, 2003 at 09:54:48 PM EST

    Err... none? Well, I take that back. The current (itty-bitty ASP) projects are somewhat OO, but probably only by incident of using VBScript and ADO. Pretty much all of it might as well be done without objects (or even OO).

    --
    It's now obvious you are either A) Gay or B) Female, or possibly both.
    RyoCokey
    Check out the poll results (4.85 / 7) (#37)
    by smallstepforman on Wed Apr 16, 2003 at 10:40:23 PM EST

    As of this writing, 60% of the readers who voted in the attached poll consider that the current software project that they're working on is doomed. This raises so many tragic questions. +1

    42% and falling? (5.00 / 3) (#66)
    by dclinton on Thu Apr 17, 2003 at 02:45:44 AM EST

    It's come down now. Perhaps all it shows is the pessimistic nature of many programmers. OTOH, I also see a lot of projects where the management are so concerned with making sure their asses are covered when the project fails that they won't take the risks needed to make it succeed. The whole problem of project failure feeds off itself. Not surprising when I think of the number of first-timers I've met on projects that were doomed. If your first project was a huge failure that's not a good role model for future projects, it it?

    One of the reason I like agile, iterative development methodologies is that very early on you deliver a success, albeit a small one. You then continue to deliver more and more small successes until success is the norm, not the exception. In addition, I've not met a customer yet who, as long as you were delivering robust, reliable software that met the requirements every two weeks to three months, gave a damn about whether you were following the process to the letter. Process adherance is what teams fall back on when the situation is so broken all they can do is fall back on process as a shield.

    [ Parent ]

    Doom (none / 0) (#141)
    by Sloppy on Thu Apr 17, 2003 at 01:35:50 PM EST

    "Doomed" is open to interpretation. The story in this article was a doomed project that failed both technically and commercially. But I voted Doomed regarding a project that I'm working on, not because I think it will fail commercially (I think it'll scrape by) but because I know that it will always be expensive to maintain (far more than it should) and it will keep customers from ever being able to upgrade to modern technology. It's doomed in the sense that it will never "not suck." But it's already deployed and selling enough to keep me busy (for now, at least). The app will be around for a decade or two, and if the sales keep up, so will I.

    So maybe some people are just being liberal with their usage of "Doomed."
    "RSA, 2048, seeks sexy young entropic lover, for several clock cycles of prime passion..."
    [ Parent ]

    all you need is love (1.21 / 19) (#39)
    by A Proud American on Wed Apr 16, 2003 at 11:31:19 PM EST



    ____________________________
    The weak are killed and eaten...


    new paradigm (4.60 / 5) (#42)
    by gdanjo on Wed Apr 16, 2003 at 11:50:21 PM EST

    This is what happens when you introduce a new paradigm without limitations - it gets misinterpreted and misrepresented by people who latch on to buzzwords because that's what has given them a job for the last blah years.

    Someone should turn out a "hit" programming language and patent parts of it and ching! ching! off to the bank they go. (aspect oriented computing is attempting this...)

    Geeks falling for a new fashion industry. Who woulda thunk it?

    Dan ...
    "Death - oh! fair and `guiling copesmate Death!
    Be not a malais'd beggar; claim this bloody jester!"
    -ToT

    Buzzwords (none / 0) (#105)
    by dachshund on Thu Apr 17, 2003 at 11:12:19 AM EST

    Most managers don't understand the issues, but they can learn buzzwords. And even if your manager does understand the issues, in most larger companies he will be corrupted by a more ignorant boss at a higher level. It's a disaster.

    I've had good and bad managers who came from a coding background. But I've almost universally had bad management from people who didn't come from a coding background. Unfortunately, I've spent the last few years in the Telecom industry, which is about the best way to guarantee that your manager's expertise will be in an area outside of software development.

    [ Parent ]

    That so much reminds me of a '95 experience. (4.76 / 13) (#43)
    by lazloToth on Wed Apr 16, 2003 at 11:52:27 PM EST

    I was hired not long out of school to be 'the C++ guy' on a project staffed by Ada people (it was DoD stuff, yes). It was a sort of pilot project to attempt software development using OO and C++.

    A particularly headstrong lifer there had worked with some special framework created by some academics from Carnegie Mellon for a simulator using Ada. This framework was used on one, maybe two DoD projects, then disappeared forever.

    He decided all code he wrote for the rest of his life would follow this framework, regardless of the problem or programming language. He particularly hated the idea of using classes. 'Just because C++ has classes,' he told us, 'doesn't mean you have a gun pointed to your head meaning you have to use them'.

    When he said this, the veins in his neck bulged, and his face was red. It was intimidating to my new-to-the-world self. Actually it turned out the veins in his neck always bulged, and his face was always red; perhaps these were lasting effects of a pre-engineering stint as a fast-food manager, where more often than not he ate two meals a day.

    Much time and energy was wasted trying to shoe-horn Ada conventions and ways of doing things into C++. Deadlines were slipped. Eventually I ran away screaming when another job presented itself.

    It's amazing I continued to work in software development after that, for many reasons, but I did.

    Later I encountered a complete and utter abomination written in C++. It was converted from COBOL by COBOLers and was one ugly 10,000 line monolithic piece of crap class after another, an unmaintainable monstrosity that should have died a horrible death early on but somehow refused to.

    Strangely, I kept doing software after that (elsewhere, actually somewhat enjoying it for a while).

    It must be the money. So many projects are doomed almost from day 1.

    were they any good to begin with? (5.00 / 1) (#116)
    by Robb on Thu Apr 17, 2003 at 11:50:52 AM EST

    My experience is that C++ is pretty easy for a good Ada progammer to pick up. The biggest problems I and others I knew encountered was that it took a very long time for things like exceptions and templates to work consistently across C++ compilers. Makes me wonder if the Ada programmers were any good to begin with. Ada best practice was to use packages like classes and only encapsualte a single type or a principle type and some supporting types. This translates very cleanly to C++.

    [ Parent ]
    Good points (none / 0) (#146)
    by lazloToth on Thu Apr 17, 2003 at 02:34:16 PM EST

    Some of the programmers were quite good, as I recall.

    We had a bad scene, what we probable needed was an Ada AND C++ person who could bridge the gap in ways you describe.

    Other big problems were the aforementioned stubborness, severe personality conflicts, territorial p*ssing matches between facilities - all those totally non-technical things that can bring any project down like the Hindenburg.

    [ Parent ]

    OO Purity (4.18 / 16) (#45)
    by hardburn on Thu Apr 17, 2003 at 12:02:34 AM EST

    The one thing I've noticed about pure OO languages is that few people use them in practice.

    I suspect this is because OO, while looking great from a purely academic standpoint, often does not model to real-world problems as smoothly as it appears on paper. This is not to say that OO is useless. But we should keep in mind what the ultimate goal in OO is: lowered development time through code reuse.

    All those big words that the OO people use, like polymorphism, refactoring, and inheiritence, all go back to code reuse. Yet I constantly see OO purists pushing OO into places where code reuse makes no sense.

    Java's primitives are a prime example. Integers are simply a bunch of bits. Integers are not objects, because intergers do not need to be objects. Why, for example, would you ever want to subclass an integer? So you can change its behavior? Yeah, you never know when you want all the integers on your system to send you an e-mail on your birthday. If there's no point in subclassing it, you lose most the advantages of using OO in the first place. Sun didn't make integers into objects to begin with because it would bloat the language for no good reason. That language is bloated enough.

    Every time I hear an OO purist talk, I want to pick up my bat object, come to their house object, and start bashing their skull object.


    ----
    while($story = K5::Story->new()) { $story->vote(-1) if($story->section() == $POLITICS); }


    Flower Speak (3.25 / 4) (#50)
    by lukme on Thu Apr 17, 2003 at 12:57:38 AM EST

    Your confused by the "big" words that OO people use because they are used incorrectly.

    C++ and Java have an advantage because they really force you to concentrate on designing a good interface. When OO is used correctly, the program is simpler to write, modify and, most importantly, maintain. Additionally, there are problems that can be more easily solved using structured programing which one can use C++ to code these parts as well.

    Now for those big words, what do they really mean.

    Polymorphism - The class contains a pointer to the appropriate function to call that can handle the class specific data. This is done so to provide a consistant interface. Now in C++ this is done by using the virtual keyword, and in Java it is done by default.

    Inheiritence - You are right about this one, this is done for reuse.

    Refactoring - This is about going back through your code to make it more consistant or read better or use more recently developed macros or ... . This is important to do reguardless of language. As an example, your writing a set of modules. The first module you write is probably not going to be as well done as the last one. Well, you can use the notions you develop for the last module, and work them into the first. Additionally, if you notice any variables that are misnomer, you fix them. Basically, when you have down time on a project, you continue to familarize yourself with the code and you continue to improve it. This is done to make maintenance easier (as well as to maintain the code).

    These are my working definitions, I hope they are rather clear (I know that they are clearer than the Flower Speak of the "educated" OOP community).

    PS: In one job interview, I heard on prospective intern give a 3 or 4 minute definition of Ploymorphism. This definition had nothing to do with reality, that is to say nothing as to how it is implemented or how it should be used. However, his definition impressed the interviewer.


    -----------------------------------
    It's awfully hard to fly with eagles when you're a turkey.
    [ Parent ]
    Does not mean what you THINK it means... (none / 0) (#58)
    by BenJackson on Thu Apr 17, 2003 at 01:22:50 AM EST

    Your confused by the "big" words that OO people use because they are used incorrectly.

    C++ and Java have an advantage because they really force you to concentrate on designing a good interface.

    I'm confused when OO people use words like "force" in that context. Unless you mean the thing with the dark side and the light side where only the few are gifted and the masses lack the mitochlorians necessary to design a proper interface.

    [ Parent ]
    Sounds like you have alot of repressed anger. (none / 0) (#63)
    by lukme on Thu Apr 17, 2003 at 02:21:20 AM EST

    I'm confused when OO people use words like "force" in that context. Unless you mean the thing with the dark side and the light side where only the few are gifted and the masses lack the mitochlorians necessary to design a proper interface.

    Are you serious, are you just trolling, or did you just have a bad day at work because you lack some "mitochlorians"?

    I will assume that you are serious. There is no magic bullet to designing a proper interface - it just requires work.

    Let's agree that the first cut at the interface you design for an object may not resemble the final cut. However, the interface should contain all of the functions that you expect to operate on the data. As the project matures, you will gradually add potentially useful functions, eliminate/deprecate unuseful functions and fix bugs within the code of the objects.

    Would you code something like this

    class string_list
    {
    ....
    public:
    int Add(void *data); //returns TRUE if successful
    string &fetch(key k);
    void rm(string &data); //throws an exception on failure
    };

    I have actually seen an interface like this, and even worse ones while programming C. I have no idea what the guy's problem was, however he would have made his life so much simpler (as well as mine) if he had put a slight bit more effort into the interface.

    It's things like this that will blow your foot off while doing C++.

    Now, as far as your repressed anger, could you please seek professional help.


    -----------------------------------
    It's awfully hard to fly with eagles when you're a turkey.
    [ Parent ]
    Professional Help (5.00 / 1) (#144)
    by BenJackson on Thu Apr 17, 2003 at 02:00:27 PM EST

    C++ "forces" you to declare your variables before you use them, to separate statements with semicolons and to initialize constant class members with special syntax. It doesn't "force you to concentrate on designing a good interface". You provided an example of that yourself. There are other languages which do have more structure to encourage good interfaces. Isn't that one of the goals of Ada?

    As for professional help, well, thank god you got to me with your dimestore psychoanalysis in time!

    [ Parent ]

    Polymorphism and pointers (5.00 / 1) (#129)
    by codemonkey_uk on Thu Apr 17, 2003 at 12:47:25 PM EST

    Polymorphism - The class contains a pointer to the appropriate function to call that can handle the class specific data.
    Umm, polymorphism has nothing to do with pointers, and everything to do with the relationships between types. Pointers are just an implementation detail of how C++ compilers commonly implement the dispatch. But it doesn't have to be done like that.
    ---
    Thad
    "The most savage controversies are those about matters as to which there is no good evidence either way." - Bertrand Russell
    [ Parent ]
    Eh ? (4.66 / 3) (#51)
    by bugmaster on Thu Apr 17, 2003 at 01:07:35 AM EST

    I use OOP all the time; in fact, I cannot imagine doing my project any other way. I don't use inheritance/polymorphism because it's some mystic buzzword; I use it because it is the easiest way to make a generic "view objects" page in my web application. I am sure this could be done with C as well, but it will take 10x more time and will be 100x harder to debug.

    Same thing goes for GUI design -- something I haven't worked with recently, but still. Yes, you can write a GUI API (say that three times fast), and in fact Microsoft has done so. Which is why no one in their right mind would use the bare Win32 APIs without some sort of an OOP wrapper, home-brewed or official (such as .net, Borland's OWL, MFC, etc.). It's just too hard otherwise.

    OOP is not good for everything, of course. When I was writing a program to communicate with our accelerometer through the serial port, I used plain old C like god intended. The article author is right -- OOP has its uses, plain old C has its uses, there is no "best" approach.
    >|<*:=
    [ Parent ]

    Exactly my point (none / 0) (#96)
    by hardburn on Thu Apr 17, 2003 at 09:54:00 AM EST

    Yes, exactly. OO should be put to use where it maps to the problem easily. There are plenty of times when it doesn't. Yet the OO purists try to drive their square nails into round holes anyway.


    ----
    while($story = K5::Story->new()) { $story->vote(-1) if($story->section() == $POLITICS); }


    [ Parent ]
    Java Primitives (4.00 / 1) (#53)
    by bugmaster on Thu Apr 17, 2003 at 01:10:37 AM EST

    Sorry, forgot to mention:

    You are right about Java primitives. The Integer class is an artifact that arises from the need to store collections of primitives without having templated types. C++ solves this problem innately; hopefully, Java eventually will too.

    No language is perfect; there is no One True OOP Implementation (tm), just as there is no One True Procedural Programming Implementation (tm). What, you don't think C has any quirks ? Anyway, you choose the best tool for the job, you don't sit there waiting for the perfect tool to arrive. That's how most programming is done, IMO.
    >|<*:=
    [ Parent ]

    Sure there is (none / 0) (#103)
    by pattern on Thu Apr 17, 2003 at 10:41:53 AM EST

    There is One True OOP Implementation(tm), and it is ruby.

    Feel the love



    [ Parent ]
    Generic Java (5.00 / 1) (#191)
    by Work on Thu Apr 17, 2003 at 11:24:59 PM EST

    Already there. Sun shall be officially supporting this soon.

    [ Parent ]
    java.lang.Integer (3.50 / 2) (#54)
    by pheta on Thu Apr 17, 2003 at 01:10:38 AM EST

    If you want a primative integer in java, you use int. It is not a class at all. Why would you ever want to use java.lang.Integer? Well, for one when you want to use an integer argument to a method that accepts java.lang.Object. It is also a very convient place to put helper methods that involve integers. Want to convert a string to an int? Just check out java.lang.Integer, you will find what you need there.

    As for subclassing java.lang.Integer, its final... you can't subclass it. So don't worry about it =)

    [ Parent ]

    Why would you want to subclass an integer? (4.50 / 2) (#61)
    by der on Thu Apr 17, 2003 at 02:15:03 AM EST

    Well, just off the top of my head, a "bound integer" that stays within a given range when incremented/decremented is something that pops up in code often enough. Take a point on a 640x480 screen for example:

    BoundInt x_coord = new BoundInt(0, 640);
    x++;

    is alot nicer than

    Int x_coord = new Int();
    x++;
    if (x > 640)
        x -= 640;

    especially when you do that sort of thing many times in a program.

    P.S. Let's leave operator overloading out of this. ;)



    [ Parent ]
    Re: Why would you want to subclass an integer? (5.00 / 1) (#78)
    by spakka on Thu Apr 17, 2003 at 08:10:58 AM EST

    Why would such a BoundInt benefit from being a subclass of Integer (in whatever language). It doesn't fulfil the basic properties of integers.

    [ Parent ]
    OO purist here! (3.00 / 3) (#79)
    by greenrd on Thu Apr 17, 2003 at 08:11:41 AM EST

    I'm afraid that's wrong. Common mistake. Aside from the typos (x_coord and x?), more importantly, your BoundInt class doesn't adhere to the contract of the base Integer class.

    I'm designing a new language now which tries to support this kind of rigorous "behavioural subtyping", and this is actually quite a subtle issue.

    If you have:

    public class Integer { ... public ThisType add(Integer y) { ... } }

    (Where ThisType is a polymorphic parameter which evaluates to the type of the current object.) Any non-empty postcondition on Integer.add (i.e. like the obvious one "returns the sum") will be broken by some instance of your wrap-around BoundInt.

    And methods without any postconditions don't make sense (they have no semantics, they are just nonsensical strings of letters!) So that's not valid for an OO purist like me.

    In fact, that's going too soft on it. That's painting it like my objection is mere pedantry. But if a method has no postcondition on it at all, that's just insane. Why would anyone want to call a method with undefined semantics? (*cough*Microsoft*cough*)

    This is probably the "best" solution, off the top of my head - this relies on some elementary mathematics:

    public class RingElem {
    ...
    public ThisType add(ThisType y) { ... }
    public ThisType multiply(ThisType y) { ... } }

    public class Integer extends RingElem { ... }

    public class WraparoundInt extends RingElem {
    ...
    public ThisType add(Integer y) { ... }
    public ThisType multiply(Integer y) { ... }
    }

    (Note that I've changed the argument types of Ring.add and Ring.multiply - you can't add members of arbitrary rings to each other, because that simply doesn't make sense.)

    You would have to use explicit methods or constructors to convert between Integers and WraparoundInts. But that's as it should be! WraparoundInts do not behave in the same way as Integers!

    Thanks for provoking me to think this out properly!


    "Capitalism is the absurd belief that the worst of men, for the worst of reasons, will somehow work for the benefit of us all." -- John Maynard Keynes
    [ Parent ]

    Oops (none / 0) (#80)
    by greenrd on Thu Apr 17, 2003 at 08:20:24 AM EST

    Damn, got my rings and my fields and my semigroups mixed up. How embarrasing.

    The integers themselves certainly don't form a ring under addition and multiplication - never mind a subset of the integers.

    You'd have to use something really quite weak as a common superclass, like Semigroup. Which is of questionable utility for simple applications. But anyway, my point that BoundInt shoudln't be a subclass of Integer still stands.


    "Capitalism is the absurd belief that the worst of men, for the worst of reasons, will somehow work for the benefit of us all." -- John Maynard Keynes
    [ Parent ]

    Why don't you think the integers form a ring? (nt) (none / 0) (#81)
    by spakka on Thu Apr 17, 2003 at 08:23:22 AM EST



    [ Parent ]
    Hmm. (none / 0) (#82)
    by der on Thu Apr 17, 2003 at 08:29:12 AM EST

    Rules this, semantics that, silly little paradigms this....

    Implementing it as a subclass makes logical sense (ie "common sense"), is clean, simple, fast, small, and I can't possibly conceive of a scenario where it would confuse somebody. Yes, it has different behavior than an int. That's why it's not an int. ;)

    Besides, here in the Real World ints actually do wrap eventually, they can only be so big. So there, they DO behave the same as an int. Kinda. :)

    Considering a real Integer class with gobs of functionality, you actually think it would be better to reimplement ALL of the functionality in that Integer class??



    [ Parent ]
    Re: Hmm. (4.00 / 1) (#88)
    by spakka on Thu Apr 17, 2003 at 08:55:10 AM EST

    Implementing it as a subclass makes logical sense (ie "common sense"), is clean, simple, fast, small, and I can't possibly conceive of a scenario where it would confuse somebody.

    What if that somebody wrote their generic Integer-handling code some years ago before your BoundInt was even conceived of? What if they live on the other side of the world and will never meet you or hear about your code? Will their code still work with BoundInt? That's the promise you're making if you subclass Integer.

    Considering a real Integer class with gobs of functionality, you actually think it would be better to reimplement ALL of the functionality in that Integer class??

    Implementation reuse is no reason at all to subclass.



    [ Parent ]
    Umm, no (none / 0) (#167)
    by Vulcannis on Thu Apr 17, 2003 at 04:33:59 PM EST

    If implementing it as a subclass breaks the logical constraints and principles by which the subclass abstraction is defined, then it by definition doesn't make logical sense.

    If on the other hand it meets your definition of common sense, then thank Dijkstra I've only had to read your ignorant ramblings and not deal with anything you've coded.

    ---
    If it's not black and white, you're not looking close enough.
    [ Parent ]

    Bleh (none / 0) (#185)
    by der on Thu Apr 17, 2003 at 09:24:23 PM EST

    Walking out the door this morning, I realized... wrap the fucking integer. I am indeed retarded.



    [ Parent ]
    The integers... (none / 0) (#100)
    by gzt on Thu Apr 17, 2003 at 10:32:14 AM EST

    Are an ordered integral domain in which the positive elements are well-ordered. Of course they satisfy the ring axioms under multiplication and addition. I can also cite a few subsets of the integers which are rings.

    [ Parent ]
    Sorry (none / 0) (#148)
    by greenrd on Thu Apr 17, 2003 at 03:08:22 PM EST

    I really should think more carefully before posting - especially about math.

    I think I'll stop digging myself a deeper hole...


    "Capitalism is the absurd belief that the worst of men, for the worst of reasons, will somehow work for the benefit of us all." -- John Maynard Keynes
    [ Parent ]

    templates (5.00 / 3) (#87)
    by ucblockhead on Thu Apr 17, 2003 at 08:52:25 AM EST

    This is where I'd use a template:

    template<class T,int MIN,int MAX>class ranged
    {
    public:
        ranged(T d) : Data(d)
        {
            if( Data > MAX || Data < MIN )
                throw bad_range_exception();
        }
        operator T()
        {
            return Data;
        }
        operator ++()
        {
            if(++Data>MAX)
                Data=MIN ;
        }
    ...
    private:
        T Data;
    };

    ranged<int,2,254> Foo=5;

    -----------------------
    This is k5. We're all tools - duxup
    [ Parent ]

    don't you mean (5.00 / 1) (#122)
    by R343L on Thu Apr 17, 2003 at 12:27:08 PM EST

    template<class T,T MIN,T MAX>class ranged
    {
    ...

    Then you're compare Data (type T) with MIN and MAX of the same type. Then it would also work with any time that defines a partial order using < and > operators.

    Or can you even do that? I'm not much of a template expert...

    Rachael
    "Like cheese spread over too much cantelope, the people I spoke with liked their shoes." Ctrl-Alt-Del
    [ Parent ]

    Yeah.... (none / 0) (#126)
    by ucblockhead on Thu Apr 17, 2003 at 12:34:37 PM EST

    Yeah, that'd probably be better. That was just whipped out off of the top of my head.
    -----------------------
    This is k5. We're all tools - duxup
    [ Parent ]
    Bad syntax (none / 0) (#127)
    by codemonkey_uk on Thu Apr 17, 2003 at 12:38:44 PM EST

    You are right in that the upper and lower bound should be of the same type as the value. But your example is not syntactically correct. Templates can only be parameterised on types integers, and pointers with external linkage. Not values. Passing min and max in on construction would be one solution.
    ---
    Thad
    "The most savage controversies are those about matters as to which there is no good evidence either way." - Bertrand Russell
    [ Parent ]
    No, his code is fine (none / 0) (#142)
    by spakka on Thu Apr 17, 2003 at 01:47:50 PM EST

    But it's also true that non-type template parameters need to be integral types or pointers. Huh? An example may help:



    template <class T, T max, T min>
    class Bounded
    { };

    int main()
    {
    Bounded<int, 0, 1> b0; // fine
    Bounded<double, 0.0, 1.0> b1; // oops!
    }


    [ Parent ]
    I stand corrected! (nt) (none / 0) (#150)
    by codemonkey_uk on Thu Apr 17, 2003 at 03:30:32 PM EST


    ---
    Thad
    "The most savage controversies are those about matters as to which there is no good evidence either way." - Bertrand Russell
    [ Parent ]
    Cool! (none / 0) (#154)
    by R343L on Thu Apr 17, 2003 at 03:52:42 PM EST

    I knew that you could do some type of actual value templatization because of this neat example in a book. In the first Game Programming Gems book (pretty good actually despite the name) there is an example for using templates to calculate various common values at compile time. It was kind of neat, although it was basically at the roof of my head.

    Rachael
    "Like cheese spread over too much cantelope, the people I spoke with liked their shoes." Ctrl-Alt-Del
    [ Parent ]

    Lack of OO Purity (4.50 / 4) (#64)
    by dclinton on Thu Apr 17, 2003 at 02:36:30 AM EST

    Actually, not making the primitives objects has led to one of the few areas of bloat in java and one of the most annoying things to deal with. As a result of that decision, each primitive is duplicated with an object (e.g. Integer, Float, etc) to deal with those situations where you need your primitives to act like objects (collections are a prime example).

    In fact, it is quite easy to write primitive classes that behave as efficiently as the non-class version. You do this by making them a special case in the compiler, rather than in the syntax of the language.

    [ Parent ]

    I gave you a 5, but... (4.50 / 2) (#75)
    by porkchop_d_clown on Thu Apr 17, 2003 at 07:26:41 AM EST

    with a caveat - the problem isn't that OO doesn't work in the real world. The problem is that there is more than one problem.

    Applying a single model to programming is like trying to implement all of math with set theory. Sure, you can do it - but Newton and Liebnitz (sp?) didn't waste years of their lives inventing calculus for no reason...

    There are definitely programming problems where data flow is the core concept - for those problems, DFD is the way to go. For other problems, OO is the obvious win, or procedural is or, more likely the problem isn't a clear candidate for any model and you have to pick the best fit.

    The worst thing you can do, from a maintainence view point, is mix and match within a component. In a large project you can define your interfaces between regions and switch models as you cross the interface - but you still have to be careful.

    BTW - Java doesn't require you to use the Integer class, it has perfectly good primitive data types. The purpose of the Integer class (and the Boolean class and so on) is to "bundle" your methods for operating on them and to allow you to hide (by subclassing!) the fact that your "DatabaseReferenceHandle" is really just an array index...


    --
    Tablet is the wrong medicinal analogy: suppository more adequately describes the Smart Display experience. - Rupert Goodwins


    [ Parent ]
    Primitive types (none / 0) (#84)
    by Kruador on Thu Apr 17, 2003 at 08:40:13 AM EST

    My take is that Java has the Integer and Boolean class (and their kin) for one reason: you need an object (derived from Object) rather than an instance of a primitive type to place in generic collections.

    .NET Framework has the general concept of a user-defined 'value type' which can be allocated on the stack rather than the garbage-collected heap. As such, it can't, in advance, know about all the possible value types and doesn't have the integer/Integer pairings. Instead it has two operations in the virtual machine, 'box' and 'unbox' for converting a value into an object and vice versa.

    Your example of a DatabaseReferenceHandle is poor; most current OO material recommends use of inheritance only where necessary, preferring composition (having a member variable, in C++ parlance). Since Integer has no methods that can be overridden, apart from those inherited from Object, there is no need to use inheritance here.

    [ Parent ]

    Composition vs. inheritance (none / 0) (#163)
    by Vulcannis on Thu Apr 17, 2003 at 04:26:14 PM EST

    "Most" OO materials recommend favouring composition because it is easier to give that simple rule than to explain the actual reasons for the inheritance abstraction and what it models.  And since composition is generally a simpler abstraction than inheritance, poor code using composition is usually easier to handle for the still-learning developer than poor code using inheritance.  But stopping at that point or claiming it to be conclusive is doing a disservice to everyone trying to learn from such material.

    Oh, and the reason for the Integer and Boolean classes is because both Java and C# make the distinction between reference and stack right in the language.  Thus any need to use a variable of one sort in a manner of the other sort requires a conversion.  In Java it is totally opaque, requiring the developer to manually wrap or unwrap.  C# automates this a bit.  Generic collections are but one application that requires such conversions, though perhaps the most common.

    ---
    If it's not black and white, you're not looking close enough.
    [ Parent ]

    C# (none / 0) (#166)
    by ucblockhead on Thu Apr 17, 2003 at 04:33:40 PM EST

    C# automates it so much that you sometimes forget you are doing it. It's hard to keep yourself from littering the code with Integer when integer would do, as they are almost entirely interchangable with implicit boxing.

    I sometimes wonder why they didn't just take the extra step and make it entirely transparent.
    -----------------------
    This is k5. We're all tools - duxup
    [ Parent ]

    alternate analogy (none / 0) (#111)
    by Robb on Thu Apr 17, 2003 at 11:33:58 AM EST

    Applying a single model to programming is like trying to implement all of math with set theory. Sure, you can do it - but Newton and Liebnitz (sp?) didn't waste years of their lives inventing calculus for no reason...

    There are definitely programming problems where data flow is the core concept - for those problems, DFD is the way to go. For other problems, OO is the obvious win, or procedural is or, more likely the problem isn't a clear candidate for any model and you have to pick the best fit.

    I view the situation as being more like positional notation versus roman numerals. Postional notation, of which our decimal number system is an example, is far better than roman numerals for operations like multiplication and division yet for operations such as addition and subtraction it is only marginally better.

    Similarly I believe that in some cases OO solution are clearly better while in others they are only marginally better. In these marginal situations a good procedural solution is often better than an average OO solution. However, I still contend that a good OO solution will be better than a procedural solution.

    [ Parent ]

    They didn't know enough Set Theory (4.00 / 1) (#201)
    by Fountain Pen Converter on Fri Apr 18, 2003 at 02:30:03 AM EST

    Besides, the point of building arithmetic out of sets and set theory is to demonstrate solid formal foundations to the whole of mathematics. Which is a Good Thing - it means we can actually trust math, instead of just hoping that it works.



    ----------------------------------------
    Always striving to have a point.
    [ Parent ]
    Purity, yeah! (2.75 / 4) (#92)
    by Stavr0 on Thu Apr 17, 2003 at 09:18:29 AM EST

    Every time I hear an OO purist talk, I want to pick up my bat object, come to their house object, and start bashing their skull object.

    That won't do. You're not using the house namespace and bash( const & skull ) hasn't been declared friend inside the skull class definition.
    - - -
    Pax Americana : Oderint Dum Metuant
    [ Parent ]

    Thank you for the sig! My first one ever! [n/t] (none / 0) (#97)
    by belldandi on Thu Apr 17, 2003 at 09:54:49 AM EST


    Every time I hear an OO purist talk, I want to pick up my bat object, come to their house object, and start bashing their skull object. -- hardburn[ Parent ]
    Oh! My Goddess! (none / 0) (#140)
    by dasunt on Thu Apr 17, 2003 at 01:29:52 PM EST

    Shouldn't your handle end in a y? At least if we are going with the English-version of the series....



    [ Parent ]
    Ah! My Goddess (none / 0) (#250)
    by belldandi on Mon May 19, 2003 at 01:45:01 PM EST

    If I wasn't trying to make sure the nic wasn't already picked, yes, I would have :).
    Every time I hear an OO purist talk, I want to pick up my bat object, come to their house object, and start bashing their skull object. -- hardburn[ Parent ]
    subclassing an Integer... (none / 0) (#114)
    by pb on Thu Apr 17, 2003 at 11:46:50 AM EST

    ...might be a good idea if you wanted to implement arbitrary precision numbers of some sort...
    ---
    "See what the drooling, ravening, flesh-eating hordes^W^W^W^WKuro5hin.org readers have to say."
    -- pwhysall
    [ Parent ]
    re: subclassing an Integer... (5.00 / 1) (#123)
    by codemonkey_uk on Thu Apr 17, 2003 at 12:32:52 PM EST

    I disagree. Integer is a concrete class (ie, final in Java or C#). It implements what it implements. What you want is for integer and your imaginary arbitrary_precision type to have the same interface so that they are interchangeable. You can do this be deriving from a common abstract base class, or an interface (in Java), or by using compile time polymorphism (templates in C++) - all of which are better ideas than deriving from what should really be left as a leaf node in the type hierarchy.
    ---
    Thad
    "The most savage controversies are those about matters as to which there is no good evidence either way." - Bertrand Russell
    [ Parent ]
    blah... (none / 0) (#128)
    by pb on Thu Apr 17, 2003 at 12:42:46 PM EST

    As the original author mentioned, final classes completely negate the benefits of code reuse. If I have two classes that have the same interface (and could possibly share some code...), then I should probably derive one from the other, or have them share a common base class.

    ...and if Java had proper operator overloading, you could even implement arbitrary precision numeric types that used the standard operators for manipulating numbers.  But that would be both way too convenient and powerful, so they left that out too...
    ---
    "See what the drooling, ravening, flesh-eating hordes^W^W^W^WKuro5hin.org readers have to say."
    -- pwhysall
    [ Parent ]

    final (5.00 / 2) (#130)
    by codemonkey_uk on Thu Apr 17, 2003 at 12:55:24 PM EST

    Final does not "negate the benefits of code reuse", it limits your points of customisation. A "final" class can be used in composition to create new classes. "Final" is only a problem when you have poorly designed hierarchies that have 'missing' ABCs / interfaces.

    You show me a situation where "final" ruined your day, and I'll show you where the missing interface/ABC should have been in the type hierarchy!

    To summarise: In a numerical types hierarchy the "Integer" and "Arbitrary Precision" should both be subclasses of a "Number" or "Scalar" type. There is no good reason to make "Arbitrary Precision" a subclass of "Integer". It just doesn't make sense.
    ---
    Thad
    "The most savage controversies are those about matters as to which there is no good evidence either way." - Bertrand Russell
    [ Parent ]

    fair enough... (none / 0) (#133)
    by pb on Thu Apr 17, 2003 at 01:05:35 PM EST

    I'm all in favor of having a sane class hierarchy too...  :)

    I don't have to use Java these days, so I haven't run into anything annoying lately, but a lot of people complain about the String class in Java...
    ---
    "See what the drooling, ravening, flesh-eating hordes^W^W^W^WKuro5hin.org readers have to say."
    -- pwhysall
    [ Parent ]

    Reason why String is final (none / 0) (#138)
    by obsidian head on Thu Apr 17, 2003 at 01:20:58 PM EST

    Apparently this is mainly for security reasons.  If you can pass a String somewhere and it passes a security test, then you may be able to modify the string in between the test and use.

    Seems weird to me too... I suppose they didn't want to go the route of copying a string and then doing the test.

    [ Parent ]

    possible reasons... (none / 0) (#145)
    by pb on Thu Apr 17, 2003 at 02:18:17 PM EST

    I've heard that it has to do with the actual implementation of the String class (messy), and of course final classes can offer better performance as well. These are all possible reasons, but I hope they didn't do it because they thought it was perfect--because it isn't. :)
    ---
    "See what the drooling, ravening, flesh-eating hordes^W^W^W^WKuro5hin.org readers have to say."
    -- pwhysall
    [ Parent ]
    dont overuse inhertance... (none / 0) (#153)
    by pheta on Thu Apr 17, 2003 at 03:47:03 PM EST

    A lot of people think of inheretance everytime they want to construct new behavior that is related to an existing object (ie Integer). This is a missuse of inhertance. If you cant say X is-a Y, then X should not inherit from Y.

    an arbitrary precision number CAN be implemented as a sublcass of Integer, but that is not good design. Composition is what you are looking for here (class X should contain Integer's as members and manipulate them internaly).

    Favor composition over inheretance when the is-a relationship doesn't hold. Don't be too eager to use inhertance... if you find you want to do something for the coolness factor of the design, think weather or not that design helps you achieve better code. Just because its cool, doesn't mean its better.

    [ Parent ]

    so... (none / 0) (#176)
    by pb on Thu Apr 17, 2003 at 04:55:36 PM EST

    You're saying that an integral quantity of arbitrary length isn't an integer? Maybe I should brush up on my math!

    Seriously, I already know more than I ever wanted to about inheritance and composition, and yet I don't use either one very often, as I don't do that much object-oriented programming, if I can help it. But this is one of the cases where I think inheritance would be more appropriate, especially within a well-designed hierarchy.

    Coolness factor? OOP isn't that cool. That is, unless you have some sort of serious buzzword addiction that convinces you otherwise.
    ---
    "See what the drooling, ravening, flesh-eating hordes^W^W^W^WKuro5hin.org readers have to say."
    -- pwhysall
    [ Parent ]

    Integer object (5.00 / 1) (#190)
    by Work on Thu Apr 17, 2003 at 11:21:20 PM EST

    java uses int primitives for calculations. Integer objects are used to serialize things to make it easier to store them in various ways. ie, it makes it real easy to save one in say a session, as well as a vector or a list or any other datatype that may want to be serialized later.

    There's a bunch of other reasons for it as well.

    [ Parent ]

    Re: Integer object (none / 0) (#202)
    by warrax on Fri Apr 18, 2003 at 05:11:07 AM EST

    java uses int primitives for calculations. Integer objects are used to serialize things to make it easier to store them in various ways. ie, it makes it real easy to save one in say a session, as well as a vector or a list or any other datatype that may want to be serialized later.

    Be that as it may, but why could the compiler not just automagically convert between the two representations when it needs to? It's easy to tell when an int is used where an Integer should be used (the compiler tells me when I'm doing it, so presumably it can tell...) and vice versa.

    There's a bunch of other reasons for it as well.

    I'd be very interested to hear them, because I have never come across a good reason for the int/Integer divide. (Or char/Char, float/Float, etc. for that matter.)

    -- "Guns don't kill people. I kill people."
    [ Parent ]
    look in the java doc's (1.00 / 2) (#209)
    by Work on Fri Apr 18, 2003 at 11:26:21 AM EST

    You'll find dozens of methods under the integer objects for converting between datatypes, as well as comparators. More than simple casting.

    The STL does similar things in C++ when storing data by wrapping a primitive up and storing it as an object so the STL's comparators can work with it more uniformly.

    [ Parent ]

    er.... (5.00 / 1) (#213)
    by ucblockhead on Fri Apr 18, 2003 at 12:24:52 PM EST

    The STL does nothing of the sort!

    The STL is a template library...essentially a code generator. When you say something like vector<string>, it generates dynamic array code for dealing with strings on the fly. The STL uses the class's own < for comparison. No wrapping occurs.
    -----------------------
    This is k5. We're all tools - duxup
    [ Parent ]

    function objects (1.00 / 1) (#215)
    by Work on Fri Apr 18, 2003 at 12:50:58 PM EST

    It's been a couple of years since I used STL extensively, however...

    STL is much more than just a code generator. It can use the < and == thats overloaded in whatever class you're saving, but it also can use function objects for comparing. There are wrapper functions for converting to these objects if you want (tend to be kind of buggy in many compilers, I found)

    Whichever way you use it, there is some wrapping going on in the background to make it work uniformly with the various iterators and so you can use these function objects for doing comparisons. Check out the code for it, if you dare. I found the STL's source to be the most illegible crap and best example of why C++ needs to start fading away..

    [ Parent ]

    uh.... (5.00 / 1) (#216)
    by ucblockhead on Fri Apr 18, 2003 at 01:11:59 PM EST

    There is no wrapping in the background. The STL containers have place certain requirements on the classes they can be used with. There must be a <. There must be default constructors and (I believe) copy constructors. There are temporaries created, but these all are of the stored type. There is NO wrapping.

    (Unless you are thinking of std::pair...but that's just an artifact of the requirement of having both a key and a value in collections like map. there are ancillery types like this, after all, pretty hard to have a tree without a next pointer, but the objects themselves are not wrapped at all when stored.)

    The reason the STL can use overloaded operators (just <, actually...it does not use anything else) is precisely because it is just a template library, and therefore just generates code.
    -----------------------
    This is k5. We're all tools - duxup
    [ Parent ]

    I have, but... (none / 0) (#214)
    by warrax on Fri Apr 18, 2003 at 12:41:50 PM EST

    You'll find dozens of methods under the integer objects for converting between datatypes, as well as comparators. More than simple casting.

    I don't see how this couldn't be taken care of automatically by the compiler. For example, I can't think of any reason why 5.asFloat() (or whatever it's called) shouldn't work; it's just a matter of providing automatic conversion from the primitive type to the Integer class. (And the same goes for all the other methods).

    The STL does similar things in C++ when storing data by wrapping a primitive up and storing it as an object so the STL's comparators can work with it more uniformly.

    I'm certainly no expert on the STL, but I don't think it does what you think it does in this case. AFAIK, it simply defines a template, e.g. less<T,comparator>, for the general case where the user supplies a comparator class, and defines "specialized" comparators for all the builtin types (using the "<" operator in the implementation), so that you don't have to define the specialized comparators yourself. It doesn't actually wrap the ints in class instances or anything like that. (At least as far as I know.)

    -- "Guns don't kill people. I kill people."
    [ Parent ]
    Wrong (none / 0) (#225)
    by codemonkey_uk on Sat Apr 19, 2003 at 12:36:32 PM EST

    The STL does similar things in C++ when storing data by wrapping a primitive up and storing it as an object so the STL's comparators can work with it more uniformly.
    No it doesn't. Perhaps you should read this before you start trying to talk about a topic you clearly know nothing about.
    ---
    Thad
    "The most savage controversies are those about matters as to which there is no good evidence either way." - Bertrand Russell
    [ Parent ]
    Then you should be happy (none / 0) (#200)
    by delmoi on Fri Apr 18, 2003 at 01:45:53 AM EST

    Java's primitives are a prime example. Integers are simply a bunch of bits. Integers are not objects, because intergers do not need to be objects. Why, for example, would you ever want to subclass an integer? So you can change its behavior?

    Well, then you should be happy. Java's Integers, bytes, chars, shorts, longs, floats and doubles are all bit arrays, and used exactly the same as in C and C++.

    In practice this actually annoys a lot of people, since you cant stick ints and assorted bitsets into container classes. In C#, you can and the majority of people who actually know what they are talking about consider it an improvement.
    --
    "'argumentation' is not a word, idiot." -- thelizman
    [ Parent ]
    Another web scripter bashing OO? (4.00 / 2) (#222)
    by coljac on Fri Apr 18, 2003 at 05:54:20 PM EST

    Your remarks don't strike me as particularly knowledgeable about OO. There's nothing especially academic about it when used in everyday work. Of course, the "purists" in ucblockhead's example were bad software designers, but that's not an indictment of OO.

    Polymorphism and inheritance have millions of everyday uses. You don't have to be a "purist" to take advantage of these features. In java terms, every Serializable object, every Servlet in fact, is an example of polymorphism in action. And there's nothing "OO" about the concept of refactoring.

    The point about primitives has merit only because it highlights a flaw in the Java language design, that there are primitives in the first place. They should all be objects. The reasons are many - possible subclassing is only one. In any case, despite the size of the data (32 bits for an int) it still makes sense to have methods associated with it - hence all the methods on the wrapper classes.

    An OO language would be a shoddy choice in many situations, but it's the way to go (for now - until a better paradigm comes along) for nearly all serious software projects.



    ---
    Whether or not life is discovered there I think Jupiter should be declared an enemy planet. - Jack Handey
    [ Parent ]

    Everyday uses (none / 0) (#227)
    by hardburn on Sat Apr 19, 2003 at 07:09:23 PM EST

    Sure, I use polymorphisim everyday (because of the way Perl does subroutines, its functions are polymorphic by default). Nothing about polymorphism ties it to OO principals. It just happens that it is usually taught alongside other OO concepts.

    Inheritance, OTOH, is very much tied to OO. How do you "inherit" from something thats not an object?

    Let me say this: I love Perl, but its object system is probalby the worst of any language in common use. Not so much for applications programmers (what difference does it make if you say "my $obj = Object->new()" rather than "Object obj = new Object()"?). Its the people building new objects that are banging their heads against walls about it. Little things like automatic passing of $self (the referance to the object that the method is a part of) or doing bless() on a referance (causing that referance to be attached to a package, and therefore become an object). Some even say that inheritance should be avoided in Perl5. Hopefully, many of these problems will be fixed in Perl6.

    A programming language should never constrain you to a particular line of thought. Forcing everything into an object forces you to think along OO thought patterns. I can hardly believe that we managed to strike on the One True way of programming alfter about 50 years of human study of CS. I have little doubt that there will be a new way of programming that will surpass OO in many ways. In such a case, languages (and their programmers) that have tied themselves into OO will go the way of COBOL. Meanwhile, languages (and their programmers) that have kept themselves liberal in their thinking will absorb the new way and add it to the rest of the ways that have been picked up over the years. In some cases, they might do so without adding any new syntax to the language (how's that for code reuse?)

    I use objects almost every day, both as an applications programmer and as a creator of new objects. I just don't think that OO fills the problem domain so perfectly that everything else should be discarded. My main problem is with OO purists, not OO itself.

    Also, please define "scripting language" for me. I have yet to see a definition that is either so broad that it manages to include C, ASM, or machine code, or it that is so specific that it doesn't include Perl or Python.


    ----
    while($story = K5::Story->new()) { $story->vote(-1) if($story->section() == $POLITICS); }


    [ Parent ]
    To hell with C++ (2.60 / 5) (#46)
    by fluxrad on Thu Apr 17, 2003 at 12:25:58 AM EST

    Procedural programming rules!

    Now if only I knew how to actually *design* my code. Speaking of which, does anyone know any good primers on software design (O'Reilly maybe)? I know C, Perl, and...well..that's it, but my code is generally thrown down on the fly, and when I go back to try to figure out what I was doing...well, it's like trying to decipher a PGP-encrypted email with the fucking rosetta stone.

    --
    "It is seldom liberty of any kind that is lost all at once."
    -David Hume
    Re: Software design (3.50 / 2) (#47)
    by smallstepforman on Thu Apr 17, 2003 at 12:36:15 AM EST

    How do you learn good software design?  Analysis, Design, Program, Refactor, Repeat until you see the light.

    Seriously, only with time will spaghetti turn into a marble masterpiece.  You need to practice, and be open to criticism.  Eventually it will just **click**.

    [ Parent ]

    Learning some design basics (5.00 / 1) (#112)
    by cdyer on Thu Apr 17, 2003 at 11:34:50 AM EST

    I'd recommend starting with Structure and Interpretation of Computer Programming. It bent my mind in funny directions, taught me many neat tricks, and showed me what makes code clean. It's done in scheme, so a lot of the functional programming stuff won't apply to your C programming, but you actually can use a lot of it in Perl, and many of the concepts work well outside fp.

    It's not that you can't learn good design from a book. It's that the book won't learn it for you. You still have to put the work in. Which means (as the gentleman said) practice, practice, practice.

    Cheers,
    Cliff

    [ Parent ]

    Video lectures for that book! (5.00 / 1) (#131)
    by obsidian head on Thu Apr 17, 2003 at 01:00:09 PM EST

    http://www.swiss.ai.mit.edu/classes/6.001/abelson-sussman-lectures/

    [ Parent ]
    Primers in software design? (none / 0) (#143)
    by tkatchev on Thu Apr 17, 2003 at 01:48:57 PM EST

    Experience, sadly... :(

       -- Signed, Lev Andropoff, cosmonaut.
    [ Parent ]

    a good one (none / 0) (#181)
    by YelM3 on Thu Apr 17, 2003 at 08:03:58 PM EST

    Is Code Complete, A Practical Handbook of Software Construction by Steve McConnell. It's from Microsoft Press, but it's good, I swear.

    [ Parent ]
    decent, but this ones better... (none / 0) (#248)
    by osq on Thu Apr 24, 2003 at 01:09:56 PM EST

    The Pragmatic Programmer, by Andrew Hunt & David Thomas.

    [ Parent ]
    Smalltalk and C++ Don't Mix (4.28 / 7) (#49)
    by Baldrson on Thu Apr 17, 2003 at 12:46:06 AM EST

    I ran a programming contest as part of a fairly large ($100M) software start up. We basically had a whole bunch of code to write and I didn't want to pick a bad paradigm within which to do it. The choices were Nextstep's Objective-C (C++ for the elites -- it spawned Java) and Smalltalk. The Smalltalk paradigm won easily after attempting to implement a whole bunch of forms and get them sitting on a database with model-view-controller. When I say easily I mean like a factor of 5 more productivity. (Unfortunately the Objective-C system was chosen, despite the obvious inferiority of the development environment, and there was a huge over-run.)

    On the same project were some guys who had attempted to take a Smalltalk application and convert it to C++. These were the Xanadu guys. They kept trying and trying to get things to work right and it seemed they never could get the whole system to work right.

    -------- Empty the Cities --------


    didnt use EOF or DBKit ? (none / 0) (#91)
    by hmspgh on Thu Apr 17, 2003 at 09:18:23 AM EST

    apparently you didnt use DBKit, the forerunner to the Enterprise Objects Framework. EOF lets you almost transparently access an underlying datastore with very, very minimal changes to your code. Plus, via Interface Builder you can test out your UI with real data -- everything works except for the custom business logic, since that requires code. But your forms will get pre-populated, pulldown menus will have data, etc etc. Immensely useful.

    Personally, I've used EOF and WebObjects (WOF) to rewrite an ISP billing system originally written in C. Although the end result was never deployed, it was a lot more extensible, stable, and maintainable than the C version.
    ---
    "Aldous Huxley's 1983 has arrived." - Arthur Spada, CT Public Safety Commis.
    [ Parent ]
    The Nextsteppers Used EOF (none / 0) (#124)
    by Baldrson on Thu Apr 17, 2003 at 12:32:55 PM EST

    The guys doing the Nextstep implementation did use EOF, albiet the 1995 version.

    -------- Empty the Cities --------


    [ Parent ]

    The greatest danger (4.20 / 5) (#55)
    by marcos on Thu Apr 17, 2003 at 01:18:01 AM EST

    In my opinion comes from the managers. And their evil often manifests itself as feature creep, or initial designs that are too large, too complex, or have too many features.

    I believe that one should always have a small featureset to initially aim for, while keeping in mind that new features are soon coming. That way, the programmers have a smaller goal to aim for, and knowing they will have to extend an improve the software shortly after the release will help them design it properly.

    Enterprise software (4.00 / 7) (#56)
    by MSBob on Thu Apr 17, 2003 at 01:18:11 AM EST

    Enterprise class software requires top notch development talent to pull off anything beyond a sipmle online store successfully. For some reason it seems that the large company did not employ competent developers for the task at hand.

    Unfortunately this is just all too frequent that mediocre developers end up being branded "enterprise developers" once they learn a bit of SQL and PowerBuilder.

    I don't mind paying taxes, they buy me civilization.

    luckily (5.00 / 7) (#68)
    by martingale on Thu Apr 17, 2003 at 03:24:49 AM EST

    The mediocre Enterprise Developers are usually easy to spot. They're the ones wearing the red tunics, and they usually die before the end of the episode. Now blue or beige tunics rule, but nobody gets to wear green except the captain.

    [ Parent ]
    they had it all wrong... (4.50 / 10) (#57)
    by pheta on Thu Apr 17, 2003 at 01:22:06 AM EST

    There is nothing inheritly wrong with OO... there are very few projects that can not be implemented well with OO given a little thought.

    Take for instance your credit card problem. I agree that their implementation of subclassing some credit card object is silly... in general you want to get the most functionality out of your code without adding more code.

    This credit card problem is solvable very cleanly using OO concepts. Create a CreditCard class. Its public inteface should be operations like 'isValidCreditCardNumber(...)', 'validateTransaction(...)', 'commitTransaction(...)', ect. Then, create CreditCardFactory that understands how to go to some external data source (database, xml config, properties file, ini, whatever) and construct CreditCard objects.

    I suspect your first implementation did something similar, was that not OO enough for them? Just because it doesn't use inheritance doesn't mean it isnt OO. In general I have found that many levels of inherentance makes things more complicated than what it is worth. Try to keep your inheritance tree as shallow as possible. Keep your public interface as simple as possible... and you design will be a pleasure to work with =)

    code size (4.85 / 20) (#60)
    by Shren on Thu Apr 17, 2003 at 01:53:54 AM EST

    It's strange - I've programmed in lots of different languages and by lots of different schools, and I find that I can almost tell when I'm going down the right path when the code shrinks. It's almost eerie. When a smaller block of code can do the same job as a larger block, the smaller block almost always seems to be better (more flexible, clearer, less buggy, more reusable) than the larger block. (Note: using language syntax doesn't count for what I'm discussing (ie, perl))

    Like today. I'm working on code to do something and it's starting to push a hundred lines when I realize that I'm doing a handful of problems seperately that are actually the same problem, slightly different. So I rip out the good bits and generalize it and bang - it's 60 lines and finished instead of a hundred lines and growing.

    It's like what the article author describes - anyone who's done a production enviornment knows that putting credit cards in a table is the 'right' answer and making them code objects is the 'wrong' answer. And I bet the code's a lot smaller, too.

    I've tutored a couple CS students (friends, mostly. I'll read a book on thier couch and they'll yell when they really need help with the code) and told them that - that smaller is generally better - and they seem, when all is said and done, to agree.

    Anyone else find this to be true? When you find the 'right' design your code size plummets?

    Yup, (3.00 / 1) (#70)
    by Akshay on Thu Apr 17, 2003 at 04:37:55 AM EST

    ... me too. I've always thought my (good) code grew organically; which is to say, it usually starts off big, but then goes on to get moulded into a certain shape.

    [ Parent ]

    For many reasons. (4.40 / 5) (#71)
    by jjayson on Thu Apr 17, 2003 at 04:46:09 AM EST

    I have seen the light and small code is good. Besides the obvious few bugs and less code to maintain, there is also an understanding facet to it. If you can fit the code on a page it makes it much easier to later understand. Obviously there is less to understand (always a good thing), but you don't have to keep track as much in your head that is off screen.  You don't have to scroll around the code, instead you can just sit there and stare at it without concentration interruptions. Algorithms become more lucid when you can do that and bugs jump out at you much quicker.

    (yet another excellent reason to use K )
    _______
    Smile =)
    * bt krav magas kitten THE FUCK UP
    <bt> Eat Kung Jew, bitch.

    [ Parent ]

    on the other hand (4.83 / 6) (#73)
    by Delirium on Thu Apr 17, 2003 at 04:58:41 AM EST

    Even after reading your article about K and looking through some K code, I can't fathom how anyone could possibly understand an entire screenful of K code without very carefully reading through every character and basically hand-parsing it. A step up from reading machine code in a hex editor. :P

    [ Parent ]
    "code size" (5.00 / 1) (#117)
    by ucblockhead on Thu Apr 17, 2003 at 11:56:27 AM EST

    It is important to understand that a good "code size" metric does not measure the number of bytes.

    if Item.Taxable == true then
        Item.Price := Item.BasePrice * TaxRate
    else
        Item.Price := Item.BasePrice

    is the same size as

    Item.BasePrice = Item.Taxable?Item.Price*TaxRate:Item.Price;

    Really, it's code complexity that's the issue, not pure code text.
    -----------------------
    This is k5. We're all tools - duxup
    [ Parent ]

    I don't agree (2.00 / 2) (#156)
    by jjayson on Thu Apr 17, 2003 at 03:57:40 PM EST

    The ability to see more signal at once is great for debugging and just trying to understand a segment of code. Although the first four lines are semantically equivalent to the other single line, the single line ir preferrable to me. It says what needs to be said in the shortest, clearest way. Code complexity is important, but so is code size.

    This extends to be even to silly things like brace placement. I cannot stand this new way of giving each block enclosing brace its own line. There winds up being nothing on the screen except whitespace.

    The second example is clearly better, I think.
    _______
    Smile =)
    * bt krav magas kitten THE FUCK UP
    <bt> Eat Kung Jew, bitch.

    [ Parent ]

    parsing (5.00 / 2) (#164)
    by ucblockhead on Thu Apr 17, 2003 at 04:27:33 PM EST

    Your brain doesn't parse any quicker because there are fewer characters.
    -----------------------
    This is k5. We're all tools - duxup
    [ Parent ]
    But... (none / 0) (#169)
    by codemonkey_uk on Thu Apr 17, 2003 at 04:39:05 PM EST

    It does parse quicker if there are fewer tokens.
    ---
    Thad
    "The most savage controversies are those about matters as to which there is no good evidence either way." - Bertrand Russell
    [ Parent ]
    Yes... (3.00 / 1) (#171)
    by ucblockhead on Thu Apr 17, 2003 at 04:46:05 PM EST

    But don't the two examples have the same number of tokens?
    -----------------------
    This is k5. We're all tools - duxup
    [ Parent ]
    I'm being pedantic, but ... (none / 0) (#174)
    by codemonkey_uk on Thu Apr 17, 2003 at 04:51:31 PM EST

    No, by my count the first has 14 'semantic tokens' (13 ignoring the redundent 'then'), the second only 9. The first has two assigments, the second only one.
    ---
    Thad
    "The most savage controversies are those about matters as to which there is no good evidence either way." - Bertrand Russell
    [ Parent ]
    Ahh... (2.33 / 3) (#175)
    by ucblockhead on Thu Apr 17, 2003 at 04:53:17 PM EST

    Yeah...you're right about that. Bad example, that.
    -----------------------
    This is k5. We're all tools - duxup
    [ Parent ]
    in this case, there's a big difference (5.00 / 2) (#192)
    by martingale on Fri Apr 18, 2003 at 12:08:10 AM EST

    I find that there is a qualitative difference in the way I read the two versions of this code. While the end effect is the same, the parsed object is different, namely:

    The if/else code represents a dynamic procedure. First check one thing, then try the other. I think of it as steps in an algorithm.

    The ? code however represents a function. It just so happens that this function is computed by the same steps in this case. I think of the function as a whole, some sort of property mapping (obviously).

    The function is parsed more quickly in my case, for the following reason as far as I can tell: as soon as I recognize the function paradigm, I expect to parse the function body at a later date if and when it becomes necessary. I use a preliminary inference of what the function does by reading the name of the assigned variable. Trusting the naming conventions may cause trouble, but only rarely in practice.

    The procedure is parsed more slowly, because I am forced to work through the details of it. In particular, I have to keep track of all the common variables used in both branches, before I can figure out what the full procedure does.

    [ Parent ]

    brace placement (4.00 / 1) (#170)
    by codemonkey_uk on Thu Apr 17, 2003 at 04:44:43 PM EST

    I agree. What is it with people these days? Why don't people use the One True Brace Style anymore.
    ---
    Thad
    "The most savage controversies are those about matters as to which there is no good evidence either way." - Bertrand Russell
    [ Parent ]
    Brace alignment (none / 0) (#218)
    by ajf on Fri Apr 18, 2003 at 01:36:00 PM EST

    I like my closing brace to be in the same column as the opening brace. I've found that I have to concentrate noticeably more to read OTSB code, because I can't immediately see where the blocks start and end. Oddly enough, I don't have this problem with Python at all, even though it looks very similar.

    Anyway, my editor is about 50 lines high. I avoid writing functions that don't fit on one screen; in the project I've been working on for the last six months, I've only written one such method (it came to about 150 lines in the end, and it was using BCEL to generate bytecode, which handled a lot of fiddly special cases and had a ridiculous number of local variables which made it difficult to break things out into separate functions). So I rarely find the extra line having any effect at all on reading my code.

    "I have no idea if it is true or not, but given what you read on the Web, it seems to be a valid concern." -jjayson
    [ Parent ]

    Pattern recognition (5.00 / 3) (#207)
    by Znork on Fri Apr 18, 2003 at 08:29:09 AM EST

    You also have to consider the way the human brain normally performs pattern recognition. This is usually done by recognizing word shapes rather than the individual characters, while parsing natural language. This creates a problem with compacted code; you have to slow down and tokenize the separate parts and you risk getting tricked by your brain which sees what it wants and expects to see, not what is actually there.

    I personally prefer the more elaborate version, as it takes me far less time to read and interpret than the compact version. The compact version would be far more acceptable to me with some use of whitespace in the right places.

    I agree with you when it comes to brace placement, preferring K&R style bracing. I do consider always bracing conditionals and loops to be good practice tho, even if they're one liners.

    [ Parent ]

    Yes and no (5.00 / 3) (#86)
    by Per Abrahamsen on Thu Apr 17, 2003 at 08:51:35 AM EST

    It is often the case that the code shrink when you replace a design that is a poor fit for the problem with a design that is a better fir for the problem, so a shrinking code base is often a sympton that you are doing something right.

    But it is important to be careful not to make compact code a goal in itself.  There is a real danger in being too clever, and write code that is very compact but hard to understand.  Just like you should always use simpel algorithms unless you have a good reason not to, you should also use simple abstraction techniques unless you have a good reason not to.

    For example, with C++ templates you can write very compact code that very few C++ programmers will be able to understand.


    [ Parent ]

    Absolutely. (4.50 / 4) (#98)
    by Rocky on Thu Apr 17, 2003 at 10:01:13 AM EST

    There a general rule I tend to follow when writing code:

    Write it once, understand the problem and realize what you wrote was poop, and throw it away and write it again.

    The second time, the code will be smaller, clearer, and better.

    Sometimes the two passes blend so I don't have to throw out the first one.

    If we knew what it was we were doing, it would not be called research, would it?
    - Albert Einstein (1879 - 1955)
    [ Parent ]

    this is acceptable? (none / 0) (#180)
    by YelM3 on Thu Apr 17, 2003 at 07:54:31 PM EST

    Is this kind of thing (writing code twice) a normal thing? At least while in school, they don't really give you time to write your assignments twice, so I don't know how it is in a production environment.

    [ Parent ]
    re: this is acceptable? (4.00 / 1) (#187)
    by ZorbaTHut on Thu Apr 17, 2003 at 09:48:02 PM EST

    Depends on the production environment. Some environments will insist that you get it right the first time. Some will let you take the time you need to get it right. I'm just finishing up "Distributed Computing Network, version 2.0" - you can guess which environment I prefer ;)

    Note that there are things in this server that I never even thought would be desirable when designing the first one. Planning can't beat experience, and no matter how much your boss wants it, you're not always going to be able to deliver a perfect design the first time.

    [ Parent ]

    is it acceptable? (3.00 / 1) (#195)
    by Shren on Fri Apr 18, 2003 at 01:02:44 AM EST

    I know few artists who start big projects without preliminary sketches. Think of it, if you will, as preliminary sketches. Starting on the project gives you insight into the final form. And with programming, a little bit of cutting and pasting and your preliminary sketch work goes in the final design.

    Besides - you're in school. By and large every program involves doing something new or for the first time. Not to scare you off from programming (if you want to be scared off read this), but in the average programming job you will relish the chance to do something new, because most of the time you won't be. You'll be doing something so mind-numbingly dull that you can do it with your mind closed - and thus, you'll do it faster.

    [ Parent ]

    Yes! (5.00 / 4) (#212)
    by ucblockhead on Fri Apr 18, 2003 at 12:18:15 PM EST

    I almost always do something like that, to a greater or a lesser extent. First, I bang out some complete piece of crap, without error checking or worry about minor bugs. That tells me what the real issues are. Then, I either through it out entirely, or use it as a framework for the real system, refactoring to improve.

    The advantage of this is that you solve all the difficult problems first, long before the deadline, and leave the less surprising stuff for the end. That way, you get no last minute surprises. It is also very helpful for showing flaws in design that you haven't thought of.

    When you get in this habit, it doesn't really take any more time, and in fact can make you more productive as the first draft goes incredibly quick and the second goes faster because of what you learned from the first.

    One of the biggest beginner mistakes in programming is to be afraid of deleting code. When a piece of code is bad, it can easily suck down for more hours of debugging than a rewrite from scratch would.
    -----------------------
    This is k5. We're all tools - duxup
    [ Parent ]

    Amongst developers, yes (4.66 / 3) (#224)
    by barzok on Sat Apr 19, 2003 at 10:11:36 AM EST

    Management, in general, doesn't understand.

    I tend to work everything out on paper or a whiteboard before I write a single line of code. I spent most of yesterday afternoon staring at my whiteboard. The other developers around me understood exactly what I was doing. Had some of the less clueful members of management come by on multiple occasions, they would have made comments. I have been known to spend most of the night (6 PM to 1 AM) over sheets of paper scratching things out before committing them to electrons.

    Generally, after I've thrown out half a ream of paper or used 3/4 of my whiteboard marker, the actual code is pretty solid.



    [ Parent ]
    right and wrong (5.00 / 1) (#107)
    by Robb on Thu Apr 17, 2003 at 11:12:50 AM EST

    It's like what the article author describes - anyone who's done a production environment knows that putting credit cards in a table is the 'right' answer and making them code objects is the 'wrong' answer. And I bet the code's a lot smaller, too.

    My first rule of design is do not fight the technology. Whatever technology or language you are using there is usually a best practice solution. It is completely wrong to do something much more complex just because it is more OO or it is the way it is done in Smalltalk.

    There must be a clear distinction between a solution that is "best practice" in a particular environment on one hand and the more theoretical "best solution" that is independent of the environment. Real programmers do not have the luxury of spending very much time worrying about this theoretical concept of "best solution" because they need to produce something that works.

    Those issues aside, it is not difficult to handle credit card transactions in a 100% OO design both cleanly and elegantly. There is persistent infomation so ultimately this is stored somewhere such as a database or a file but how persistency is implemented is best encapsulated and hidden from the rest of the system.

    From the limited information in the article I assume that the Smalltalk programmers wanted to use the class hierarchy to differentiate different kinds of credit card transactions. If the credit tender process was fundamentally different for each credit card then this would be a good solution. However, in my experience they are not fundamentally different and having separate subclasses is a bad solution as it adds unecessary complexity, cost and tends to limit flexibility (because adding classes on the fly is far harder than adding instances --especially in C++). This is a classic mistake.

    [ Parent ]

    heh. (4.00 / 1) (#113)
    by pb on Thu Apr 17, 2003 at 11:43:48 AM EST

    I always try to write my code like that, and it amazes me how much code people can end up writing to solve a simple problem. Unfortunately many of them just don't know any better, because no one showed them the right way to do things, and they haven't figured it out for themselves yet.

    One thing you implied in your explanation is that you actually had some similar yet still redundant code; that's probably the most common source of code bloat IMO, especially when people cut-and-paste code because they don't know of a better way to do it.

    I've seen some very bad introductory programming assignments where students are expected to, say, input and average 20 numbers as part of a program to calculate their grade in the class--before they know anything about loops or arrays. Perhaps it's designed to make them appreciate how handy these features are, but I think it's more likely to turn people away, teach them to cut-and-paste code, or reinforce any impressions that programming is just technological busywork (which it often can be, in an academic environment).

    Therefore, I think it's much more important to teach people the right way to solve problems, rather than forcing them to do things the wrong way.
    ---
    "See what the drooling, ravening, flesh-eating hordes^W^W^W^WKuro5hin.org readers have to say."
    -- pwhysall
    [ Parent ]

    Cut & Paste (none / 0) (#230)
    by tjb on Sun Apr 20, 2003 at 12:44:34 AM EST

    Now, I do a totally diffferent kind of programming than most people here (embedded DSP code, entirely in assembly), so I may be way out in the blue on this one, but...

    I find that most cut and paste comes from taking something that works elsewhere, modifying it slightly, and getting it to work where its needed right now.  ITs not a matter of "not knowing better" - everyone knows this is stupid - but rather a matter of "I'm trying to get this fucking thing to work, and I know this works, and its pretty similar".  So you take the working code and drop it in, make the needed slight modification, and then it works and you declare victory.

    Only that last step is wrong - after it works, the goal should be to generalize the solution for every place you did the cut&paste.  In the work I do, you tend to do this eventually anyway due to code-space constraints.  In "normal" programming, however, 50 lines of mostly redundant code doesn't make your stuff stop working because you exceeded memory limits, so the shit builds up and leads to a maintenance nightmare.

    Tim

    [ Parent ]

    Bonehead homeworks... (none / 0) (#241)
    by Gooba42 on Mon Apr 21, 2003 at 07:20:17 PM EST

    My shell programming class was doing awk and we were supposed to run through this datafile with campaign donations one line per contributor, 3 donations each.

    The instructor's example ran on each line comparing each contribution to the other two for a min & max report i.e.
    if $3 > $4
      then if $3 > $5
        $max = $3
      else
        $max = $5
      elsif $4 > $5
        $max = $4

    I took it and went with an array holding the contributions like so:

    @array = $3 $4 $5
    foreach item in @array
    if $item > $max
      then $max = $item
    if $item < $min
      then $min = $item

    His ugly code was so convoluted it was difficult to look at it and not try to clean it up. To my eyes it was "who cares if $3 is greater than $4? I really only care if it's bigger than the biggest I've seen"

    My solution was based on a) knowing a bit of a couple other languages and b) reading ahead 2-5 pages in the textbook. I don't understand why we want to introduce people to programming in such a way as to produce inelegant solutions.

    I had similar frustrations in my C++ class that was taught like "Programming For The Computer Illiterate". Such compelling topics of discussion as "How To Use The 'Close Window' Button" and "Why Can't I Compile My Program.doc File?".

    [ Parent ]

    caveat (5.00 / 1) (#168)
    by codemonkey_uk on Thu Apr 17, 2003 at 04:35:47 PM EST

    Yes. This is generally good advice, but take care to think about the bigger picture. A change that makes the code smaller here might well make it bigger there. This is especially true when it comes to library code, where it can make sence to do a lot more code in order to make a small saving for the end-user many times over.
    ---
    Thad
    "The most savage controversies are those about matters as to which there is no good evidence either way." - Bertrand Russell
    [ Parent ]
    Code size (5.00 / 1) (#188)
    by ZorbaTHut on Thu Apr 17, 2003 at 09:53:22 PM EST

    I do a programming competition pretty regularly, and one of the things that's almost a rule is that the higher-ranked competitors write a lot less code. The key is avoiding nasty special cases, not duplicating anything, and brute-forcing things rather than trying to be clever when speed isn't an issue.

    When you've got 75 minutes to solve three complex problems, bugs are truly ghastly :P

    So you look at lower-ranked coders and they've got three, four pages of code for their solutions - the higher-ranked coders have one page, and half of that is functions they wrote (and debugged!) before the competition even started.

    [ Parent ]

    It's a motherfucker (1.00 / 28) (#62)
    by medham on Thu Apr 17, 2003 at 02:18:11 AM EST

    Don't you know
    push that button, your ass got to go!

    The real 'medham' has userid 6831.

    Uhm... Me, too (3.80 / 10) (#65)
    by kwerle on Thu Apr 17, 2003 at 02:40:38 AM EST

    Hey!  I once worked on a project that was poorly managed, and it failed, too!

    Oh, and I've worked on a well managed project and it succeeded!

    I'm leery of bad management and idiots.

    What object oriented? (3.44 / 9) (#69)
    by United Fools on Thu Apr 17, 2003 at 03:35:58 AM EST

    We always emphasize the importance of people. You should be people oriented. That's good for your career. Object oriented? You are a person, not an object. Don't believe in objects, they are not good for you.
    We are united, we are fools, and we are America!
    Someday... (4.33 / 6) (#83)
    by wiredog on Thu Apr 17, 2003 at 08:33:27 AM EST

    I'm gonna write the article about the project from hell I was on. If I can find the source code. Heck, maybe if I can't, but having source to show the horrors would make it easier to explain.

    It was C code, written to run on an 8088, ported to the 486. The 16 to 32 bit issues, etc. Plus, it was a DOS program! Remember the 64k segment issue? The 640k code+data limit?

    It was never rewritten. Every time a new feature was needed it was bolted on the side.

    I will never forget the comment the original coder had put in the code, just before a particularly obscure bit of code:
    /*Why did I do this?*/

    Wilford Brimley scares my chickens.
    Phil the Canuck

    Commenting as I read (3.00 / 7) (#90)
    by Stavr0 on Thu Apr 17, 2003 at 09:08:21 AM EST

    They did a code audit on our stuff, which came up mostly positive, but with the caveat that it was "only 35% object oriented".

    I'm commenting as I read this so I don't know the rest of the story... This is the point where I'd run like hell and find another job. 35% OO? WTF? These people are idiots.
    - - -
    Pax Americana : Oderint Dum Metuant

    well thank god they are working for a living (2.75 / 16) (#93)
    by turmeric on Thu Apr 17, 2003 at 09:28:29 AM EST

    ok see this is what im fucking talking about. janitors and counter-help people get payed shit. and yet, they actually fucking do something that is necessary and contributes to society. these 'code sorcerers' like your cohorts, and frankly, your idiot manager who sold out to this conglomerate, are all a bunch of genital slapping morons... who have their position in life solely by accident. they were born into good schools or the right family or whatever. as we all know, alumni can get their kids into a school easier than anyone esle. and so there you have it.

    these computer useless turd balls you are 'working with' who in fact, sat around for several months DOING ABSOLUTELY NOTHING AND GETTING PAYED FIVE TIMES AS MUCH AS MOST PEOPLE. . . . they are the priviledged of our stupid ass american caste system. the useless are rewardewd. the hard working are kept at the bottom. the cheating sleaze bags are given lots of money, and everyone thinks that they are 'upright, upstanding, contributing, smart, etc',,,, meanwhile people who are actually doing hard jobs and contributing to society, they get crapped on as 'stupid', 'lazy', etc.

    america you are a soulles rotting empire and if you dont fix this bullshit you will go down in your own bile and vomit you will choke on.

    I hear you !!!@@@ (4.40 / 5) (#120)
    by phred on Thu Apr 17, 2003 at 12:07:55 PM EST

    ok see this is what im fucking talking about. janitors and counter-help people get payed shit. and yet, they actually fucking do something that is necessary and contributes to society. these 'code sorcerers' like your cohorts, and frankly, your idiot manager who sold out to this conglomerate, are all a bunch of genital slapping morons... who have their position in life solely by accident. they were born into good schools or the right family or whatever. as we all know, alumni can get their kids into a school easier than anyone esle. and so there you have it.

    Absolutely!

    However, nothings written in stone. I don't know if you remember my contribution to one of k5's many techno-wanko-ubernerd storys, I posted my mistaken notion that you needed many years of hard systems programming to be a good software architect, and got a bit shot down. I was upset by this, here I, a top notch customer service representative at a leading consumer convenience franchise, was getting dissed by one of these same 'code sorcerers' you mentioned just because I was honest enough to give my background.

    But I got over this fast, examined my initial premise in some detail, and decided what the heck, if advanced knowledge in the finer elements of computer science wasn't needed, why couldn't I sleep on mattresses filled with money like the so called computer elite? So I went job hunting...

    these computer useless turd balls you are 'working with' who in fact, sat around for several months DOING ABSOLUTELY NOTHING AND GETTING PAYED FIVE TIMES AS MUCH AS MOST PEOPLE. . . . they are the priviledged of our stupid ass american caste system. the useless are rewardewd. the hard working are kept at the bottom. the cheating sleaze bags are given lots of money, and everyone thinks that they are 'upright, upstanding, contributing, smart, etc',,,, meanwhile people who are actually doing hard jobs and contributing to society, they get crapped on as 'stupid', 'lazy', etc.

    I know what you mean, I feel your pain, well, at least I used to, cause turned out, based on my knowledge of TRS-80 architecture and decent typing skills, I am now an apprentice applications engineer, and let me tell you, this sitting on my ass being a mouse pilot for mad-money is not too bad a deal. I'm now web-enabling mission-critical customer-driven revenue-enhancing, uh, somethings, and at the same time reducing down-time and TCO, thus enabling management-information and decision-support, er, well, basically pointing and clicking for more money than I've ever made in my LIFE!!!!!

    america you are a soulles rotting empire and if you dont fix this bullshit you will go down in your own bile and vomit you will choke on.

    I know! Aint it great?!?!?!

    [ Parent ]

    Yikes. (none / 0) (#178)
    by YelM3 on Thu Apr 17, 2003 at 07:43:01 PM EST

    I rated this comment a 5, but it really disturbs me. I will be done with my ubernerd degree in a couple years and I will be faced with the choice that everyone who is educated about our economical/political system has to make: a) ignore your conscience, live it up. b) live in the system for awhile and then try and do something about its problems once you've "made it" to some degree, or c) resist!

    I dunno what option C really entails, especially for a college graduate (we already ARE the System). But it is a very serious issue, one that I think is central to any thinking being who is aware of the vast oppression and exploitation that American capitalism promotes. Sure, I can made good money, but every dollar I make is just one dollar less for some starving family. The fact that CS people make good money makes it even worse... I will be contributing to the ever-widening gap between the uber-rich and have-nothings. (or depending on how Marx you want to get, I am perpetuating the myth of the middle class!)

    Maybe this issue deserves a front-page story.

    [ Parent ]

    Exploitation. (5.00 / 1) (#206)
    by tkatchev on Fri Apr 18, 2003 at 08:22:40 AM EST

    Exploitation is inside the head. Meaning, before "resisting", the very least you could do is to stop huffing crack.

       -- Signed, Lev Andropoff, cosmonaut.
    [ Parent ]

    Some advice (none / 0) (#211)
    by adingle on Fri Apr 18, 2003 at 12:17:18 PM EST

    "The fact that CS people make good money makes it even worse... I will be contributing to the ever-widening gap between the uber-rich and have-nothings. (or depending on how Marx you want to get, I am perpetuating the myth of the middle class!)"

    Well, I think this depends on how you spend the money that you earn.  If you donate virtually all the money you make to charity, and live in poverty yourself, clearly you won't be widening the gap between the rich and the poor.

    My personal theory is that the real cause of poverty is inefficiency. (i.e. many people working long hours for things that nobody really needs).

    As I see it, the bottom line is that when people's labor and the world's physical resources are put to good use, it is good.  When they are wasted, it is bad.  

    Perhaps a better question to be asking yourself is not whether you deserve that high paying job or not, but whether you can trust yourself to put the money that you earn at it to a good use.  (i.e. will you support enterprises that efficiently use labor/resources to actually benefit the human race? (such as by providing food to that starving family))

    With reguards to C, I think that the first and most important step of resistance is to educate yourself about just what exactly you are resisting.

    Best luck.

    [ Parent ]

    Ideas (none / 0) (#240)
    by Jman1 on Mon Apr 21, 2003 at 03:27:20 PM EST

    "but every dollar I make is just one dollar less for some starving family."

    First, it's not a zero-sum game. Your dollars aren't necessarily taken from some starving family. Second, you could of course give some of your money to a starving family should you choose. Third, you could earn that money (according to your conscience) by doing work which is worth your salary or more to humanity/the country/your city/a starving family. Say you are writing software to help with protein folding and you contribute to saving lives. Or your software helps make an insurance company more streamlined, with some of the money saved (hopefully) going to millions of clients. Etc.

    [ Parent ]

    "Doing nothing" take a lot of effort (5.00 / 2) (#125)
    by chro57 on Thu Apr 17, 2003 at 12:33:05 PM EST

    >DOING ABSOLUTELY NOTHING AND GETTING PAYED FIVE >TIMES AS MUCH AS MOST PEOPLE. . . . they are the >priviledged of our stupid ass american caste >system. I am one of those. (but not in your countries.) I once was a brillant student. Doing nothing is extenuating. Producing smoke as job is soul-eating. And my unproductivity is in fact really usefull for my employers. The only constraint is that I must have a nice smile, wear an extensive suit, and know most buzzwords and majors software vendors propaganda to explain it to the clients. I am selling poison technology, but I couldn't find any other job correctly paid. beuark. I don't understand our economy. Please, someone explain it to me.

    [ Parent ]
    so the fuck what? you dont get an A for effort (none / 0) (#186)
    by turmeric on Thu Apr 17, 2003 at 09:36:40 PM EST

    you get an A for results. unless of course you are high up in the caste system and get 70 grand a year for shittin poo on a powerpoint slide. yes you can break into the 'real workers'. its hard. fast food is a bigger business than all our media combined. if you are a vegetarian you are out of luck. however it is still possibe.

    [ Parent ]
    70 grand a year. (none / 0) (#205)
    by tkatchev on Fri Apr 18, 2003 at 08:21:28 AM EST

    ---> You've still got room to grow, and how.

       -- Signed, Lev Andropoff, cosmonaut.
    [ Parent ]

    there you go - OO == TOOL OF THE BOURGEOIS !! [nt] (none / 0) (#139)
    by zzzeek on Thu Apr 17, 2003 at 01:25:24 PM EST



    [ Parent ]
    "american caste system" (5.00 / 10) (#165)
    by epepke on Thu Apr 17, 2003 at 04:31:46 PM EST

    Come on, you can do better. This is an article about O-O. It's the American Class System, driven by inheritance and private data with restricted public access that you can't see unless you're a "friend." And the proletariat are treated as objects.


    The truth may be out there, but lies are inside your head.--Terry Pratchett


    [ Parent ]
    That is the way of the Social/Pack Animal (none / 0) (#245)
    by cryon on Tue Apr 22, 2003 at 10:08:01 AM EST

    This is a common dynamic with social animals. THe powerful use their power to get more power, and to keep down those who have less power. It is all relative when it comes to power and social status with pack animals. It is not what you have, so much as it is how much you have compared to everyone else.
    HTGS75OBEY21IRTYG54564ACCEPT64AUTHORITY41V KKJWQKHD23CONSUME78GJHGYTMNQYRTY74SLEEP38H TYTR32CONFORM12GNIYIPWG64VOTER4APATHY42JLQ TYFGB64MONEY3IS4YOUR7GOD62MGTSB21CONFORM34 SDF53MARRY6AND2REPRODUCE534TYWHJZKJ34OBEY6

    [ Parent ]
    Quote from Amadeus (4.00 / 9) (#94)
    by Stavr0 on Thu Apr 17, 2003 at 09:29:41 AM EST

    Only 35% OO... Reminds me of a quote from Amadeus.

    Joseph II
    Your work is ingenious. It's quality work. And there are simply too many notes, that's all. Just cut a few and it will be perfect.

    Mozart
    Which few did you have in mind, Majesty?
    - - -
    Pax Americana : Oderint Dum Metuant

    OO = Good? Not! (4.57 / 7) (#101)
    by Robb on Thu Apr 17, 2003 at 10:32:15 AM EST

    There is far less hype than there used to be but too many people mistakenly thought that OO was synonymous with good. My experience is that OO is better all things being equal but in real life all things are not equal.

    In my experience with student software engineering projects the best students produced OO designs that were about twice as complex as they needed to be and the average was about three times as complex. The typical problem was relying on the class hierarchy to make all the important distinctions rather than using attributes.

    For example in risk there is a deck of cards with one of three symbols (cannon, soldier, calvary). Almost every team modeled this with a class RiskCard having three subclasses CannonCard, SoldierCard and CalvaryCard. This was totally unecessary but it was praised by the person handling the design phase because it was more OO (ironically she also had a background in Smalltalk). One class was not only sufficient --it was far simpler and from an engineering standpoint was to only reasonable solution.

    Another problem was adding unecessary flexibility. One team implemented the map in such a way that each continent was a class and you could add a new continent by adding another subclass. There was nothing wrong with how they solved the problem other than the fact that it didn't need to be solved.

    My experience with OO projects from industry usually involved the opposite problem. They don't use the OO facilities in situations where they offer clear advantages. If they are writing high quality code then this isn't too bad; in fact it is far better than writing really bad OO code. Some people suggested that a "pure" OO language should be used to force them to write OO code but in my experience this is the path to failure.

    Ultimately, it is about the expertise of the people you have available. If you have the necessary expertise in analysis and design then, in my opinion, OO is the way to go. If you don't then either you need to get it or make do with what you have. Often making do with what you have is the right decision from an engineering point of view.

    Student projects (5.00 / 3) (#115)
    by epepke on Thu Apr 17, 2003 at 11:50:30 AM EST

    It isn't completely fair to use student projects as an example. Students interpret them as an opportunity to demonstrate their understanding of the concepts presented in class in the context of an artificially dumbed-down situation that wouldn't call for that kind of approach in the real world. The reason they interpret them this was is that is what they are.


    The truth may be out there, but lies are inside your head.--Terry Pratchett


    [ Parent ]
    Re: Student Projects (5.00 / 1) (#121)
    by Robb on Thu Apr 17, 2003 at 12:20:39 PM EST

    I have two points:
      1) These were semester long projects done in groups of 4 or 5 students. There was a lot of work in creating projects that could realistically be completed in the given time and required the teams to demonstrate a sufficient undrestanding of the concepts they had learned in their previous 4 semesters of programming courses. These projects were not dumbed-down. What was unrealistic was artificially imposing a waterfall development model (makes it much easier to teach the course), requiring them to work in large teams and use a much heavier development process than necessary.

      2)Invariably the students wound up slaving long hours at the end of the semester to finish the project. I thought we should have provided more support during the design phase but on the other hand we let them suffer the consequences of their bloated designs when they had to implement them.

    Invariably the teams with more minimal designs did better because they could spend more time polishing the software and documentation.

    [ Parent ]
    You've been in academia too long (5.00 / 1) (#132)
    by epepke on Thu Apr 17, 2003 at 01:01:45 PM EST

    I forgive you; I was in academia for a long time, too.

    These projects were not dumbed-down.

    An implementation of the "business logic" of Risk is not only dumbed down, it is way the hell dumbed down to the nth degree and can't conceivably be otherwise. The basic structure of Risk is a weekend hack for any reasonably bright 16-year-old. Now, if it were about designing an artificial intelligence player or a usable interface, that might have some meat on it.

    Invariably the students wound up slaving long hours at the end of the semester to finish the project. I thought we should have provided more support during the design phase but on the other hand we let them suffer the consequences of their bloated designs when they had to implement them.

    Well, it's school; they're supposed to learn something about what happens when you make stupid design decisions.


    The truth may be out there, but lies are inside your head.--Terry Pratchett


    [ Parent ]
    inexperienced designers (5.00 / 1) (#152)
    by Robb on Thu Apr 17, 2003 at 03:39:32 PM EST

    My original point was that a poor design can easily double or triple the size of a software system and in general 35% object-oriented is better than 100% object-oriented but bloated.

    You claimed that "it isn't completely fair to use student projects as an example". After reading you post (except that last sentence :-) I assumed that by project you meant the assignments students are given in programming classes where there are 6 or so a semester. I assumed this because you mistakenly assumed the students were still being taught new language concepts However, I agree the kinds of projects students get in programming courses are very artifical and are what I consider to be dumbed down because they are meant to teach specific concepts and not effective use of the language as a whole. I then explained that the project in question was not "dumbed down" because it was a software engineering course that focused on larger software issues as well as effective use of the entire language.

    If I said that it was a semester long project for teams of 4 of 5 students then a reasonable inference would be that it includes at least the interface and probably an AI opponent as well.

    Initially the students thought like you did: that it should be a weekend project for a bright student. From experience I can tell you that a single skilled programmer could implement the project in a little less that a person week (I took about 35 hours of development time including testing). Note however that there was no documenation beyond comments in the code and the specification provided was complete, clear and stable.

    However, the students had quite a few extra difficulties. The next best design was over twice the size in terms of number of classes, which more than doubles the amount of time it takes to implement the design. The students had considerably less skill with the language and less experience in testing so they had more bugs in the software and it took them longer to track them down. They were also unfamiliar with some of the libraries made available to them so this also took more time. They were working in teams so they had to talk things over which can easily consume a phenomenal amount of time. Students often said they were suprised how much time they spent taking decision.

    I would agree that the complexity of the project was trivial compared to the kinds of software systems I do in industry but it was not artificially dumbed down. What the students were doing was fundamentally similar to what goes on in industry.

    The major differences were, as I noted, they had to work in teams that were too big for the scope of the project, they had to use a development process that was much heavier than required and we essentially forced them into a sequential development process. However, I has seen situations in industry where exactly the same thing happened and they didn't have the excuse that they were trying to teach the programmers something. Another difference was the students had a well defined, stable specification which as we all know almost never happens in industry. They also didn't even think about things like user acceptance, training and rollout.

    I disagree with your assertion that it "isn't completely fair to use student projects as an example" because I am seeing more and more of those same mistakes at work in an industrial setting during code inspections. In my opinion design bloat is a classic mistake in object-oriented systems because many programmers do not fully understand the kinds of tradeoffs they are making.

    [ Parent ]

    OK (none / 0) (#160)
    by epepke on Thu Apr 17, 2003 at 04:16:38 PM EST

    If I said that it was a semester long project for teams of 4 of 5 students then a reasonable inference would be that it includes at least the interface and probably an AI opponent as well.

    Whether the inference is "reasonable" or not, was it or wasn't it? The reason I reacted as I did was that you focused on what I consider a rather trivial detail. Whether a card is subclassed three times or not is on the level of what I consider a two-hour refactor at most.

    Initially the students thought like you did: that it should be a weekend project for a bright student. From experience I can tell you that a single skilled programmer could implement the project in a little less that a person week (I took about 35 hours of development time including testing).

    At least that's in the ballpark.

    The students had considerably less skill with the language and less experience in testing so they had more bugs in the software and it took them longer to track them down.

    Now I'm confused. It wasn't an introductory language course, but the students didn't have skill in the language. What happened? Or was that a deliberate curve ball?

    They also didn't even think about things like user acceptance, training and rollout.

    I'm even more confused. How can one possibly design an interface without being concerned about user acceptance?

    I disagree with your assertion that it "isn't completely fair to use student projects as an example" because I am seeing more and more of those same mistakes at work in an industrial setting during code inspections.

    We'll just have to agree to disagree, then. If you see those things in industry, fine, write about that. There are certainly plenty of bad programmers in industry. But student projects are necessarily artificial.

    In my opinion design bloat is a classic mistake in object-oriented systems because many programmers do not fully understand the kinds of tradeoffs they are making.

    That I have to agree with. I've noticed a lot of programmers don't have an understanding of tradeoffs, period. But then again, I'm an old fart--I remember punched cards and having to run from the line printer to the card reader to punch Stop if there was a compile error so that the link didn't make the System/360 require the operator to halt the program.

    I've been having some retro fun recently writing code for the Palm OS. You can use C++, but you have to be careful and understand what the compiler is actually generating, because the stack and heap are so tiny.


    The truth may be out there, but lies are inside your head.--Terry Pratchett


    [ Parent ]
    bad instructor... (4.80 / 5) (#118)
    by pheta on Thu Apr 17, 2003 at 12:01:02 PM EST

    The benifits derived from an OO design are NOT deep inheretance heirachies. It is abstraction! Only expose interfaces that are needed, keep it simple, and you will have an API that is nice to work with. That is the benifit of OO. If the instructor is emphasizing that you should create a class everywhere possible that inherits from many base classes to increase code reuse, then that instructor needs to rethink why they are teaching OO in the first place.

    I realize that you agree with me, but apperently there are professors/ta's out there that don't. =(

    [ Parent ]

    Well... (none / 0) (#199)
    by delmoi on Fri Apr 18, 2003 at 01:29:42 AM EST

    For example in risk there is a deck of cards with one of three symbols (cannon, soldier, calvary). Almost every team modeled this with a class RiskCard having three subclasses CannonCard, SoldierCard and CalvaryCard. This was totally unecessary but it was praised by the person handling the design phase because it was more OO (ironically she also had a background in Smalltalk). One class was not only sufficient --it was far simpler and from an engineering standpoint was to only reasonable solution.

    If you want to be able to add cards that behave in different ways later, then this is actually beneficial. Besides, having three small classes isn't actually 3x as complicated as having one class and 3 if statements to determine the difference. In fact, the amount of code is exactly the same. The only difference is where it is. Also, adding cards is less painful because you need to modify less code to add them, ideally you shouldn't need to touch any of the code that actually handles the cards.
    --
    "'argumentation' is not a word, idiot." -- thelizman
    [ Parent ]
    attributes or hierarchy (none / 0) (#221)
    by Robb on Fri Apr 18, 2003 at 04:39:00 PM EST

    Of course there are situations where a hierarchy is necessary but the deck of cards in Risk is not one of these situations. The algorithms are actually more complex if the kind of card is not an attribute. If you actually write the code you will see that it is in fact more than 3x as complicated as a single class. This is because you need to write extra methods if you have subclasses that are not necessary if you use an attribute.

    [ Parent ]
    You obviously aren't a Java coder? (5.00 / 2) (#243)
    by 4ntifa on Tue Apr 22, 2003 at 05:16:49 AM EST

    Using inheritance or an interface has some very real advantages in the described scenario. First of all, no silly if/switch blocks based on an attribute. Second, type-checking. Third, the code itself is clean and simple, if done right, "client" code doesn't have to care about the different implementation classes in most cases. Simply use the superclass/interface to refer to any subclass/implementation. Come to think of it, personally I'd also throw in "typesafe enum" pattern here, just to make the code as safe as possible. Good OO design can prevent a lot of potential programming errors and bugs. It's not just a different way of programming the desired functionality, it's also a way to improve program robustness.
    -=- 4ntifa -=-
    [ Parent ]
    Doesn't apply here (5.00 / 1) (#247)
    by zakalwe on Thu Apr 24, 2003 at 12:18:53 PM EST

    In the situation he describes (Risk cards), there are no such gains. The individual cards have identical functionality - the action taken depends on what your entire collection of cards is like. There is no case where an individual CannonCard can distinguish itself from a CavalryCard except as regards its type.

    The situation he describes is like making each individual number (One, Two, ...) a subclass of Integer. Its confusing functionality with state - the correct time to subclass is where the interface or functionality will change. . I will agree that good OO design can prevent a lot of potential programming errors and bugs - but this is not good OO design.

    [ Parent ]

    Reminds me of a chip project I was on (4.00 / 1) (#102)
    by stodd on Thu Apr 17, 2003 at 10:34:41 AM EST

    I was working on a chip project a couple of years ago where we had to construct a chip which could support a number of audio and video standards. The requirements were being driven by a marketing guy who lived out of the country, and every time he met with a customer, he added some new requirement. Before all was said and done, we were expected to support at least one standard that wasn't even finalized, and several more which were not widely used. The project was eventually cancelled.

    Promises to Client (none / 0) (#229)
    by cam on Sat Apr 19, 2003 at 09:10:59 PM EST

    The requirements were being driven by a marketing guy who lived out of the country

    I was on a project a few years ago where the bloke pitching to the client agreed to several things that were out of scope. It was the right thing to do, we secured their business which has since grown. I cussed his agreeance pretty blue at the time. But we delivered on time ... just.

    I have no problem with making the codebase keep up with the changing business processes or the perceived needs of the ultimate client, I think it is the software version of the client is always right. With that project I dont have direct contact with the ultimate client so any requests for enhancement come from the client through our people to us.

    The supporting a standard that isnt finalised is a bit rough.

    cam
    Freedom, Liberty, Equity and an Australian Republic
    [ Parent ]

    OOPS (3.50 / 4) (#104)
    by Cro Magnon on Thu Apr 17, 2003 at 10:59:12 AM EST

    It's a little hard to take something named after a mistake seriously! :)

    I'm fighting a similar problem at my job. We've been trying to convert our old COBOL software into Java for a long time, with little success. We keep getting hung up in the design phase, and we've started over from scratch several times.
    Information wants to be beer.

    OOPS is right (none / 0) (#235)
    by prong on Sun Apr 20, 2003 at 07:54:59 PM EST

    I'm guessing by "convert", you mean "rewrite". Not exactly a trivial task, particularly for older systems where the design docs have long since disappeared. The other possibilty is "port", which is an even worse alternative.

    I relate my own experience with this: I was working for a major telco (which has been absorbed by an even bigger telco since) where the IT management made the decision to convert all systems to OO. Consultants were brought in, industry-specific class libraries were purchased, and a number of small, proof-of-concept projects were undertaken successfully. For the first big project, the carrier settlement system was selected for conversion. The system, in a nutshell, decides who owes what to whom for calls that transverse networks and was written primarily in COBOL, with CICS for user interaction and IMS as the database back end. All on great, honking, blue hardware. A real dinosaur, even then, but a damn speedy dinosaur at an average of 13 million+ transactions a day. The target environment was C++, Motif, and Oracle on H-P hardware (distributed, of course).

    The project went through about 3 seperate efforts to salvage it, including decisions to dump the design phase and attempt to port from one language to another, and the movement of the (increasingly large) project team to another location, away from the people who understood what should be happening under the covers.

    The end result? Management pushed the new system through the development cycle, got a good initial test, and switched it on in production. It promptly failed under load. The old system was switched back on, and the company scrambled around to restaff the maintenance and enhancement team.

    My point is this: the project didn't fail because of the technologies involved. It failed because some B-school graduates thought that they'd found a the solution to their development backlog and product cycle times, and hamfistedly tried to pound a square peg into a round hole. The combination of OO, relational DBs, distributed processing, and a rewrite of a major system was simply too large to accomplish inside the 2 year time frame management wanted.

    [ Parent ]
    I agree (5.00 / 1) (#106)
    by khakipuce on Thu Apr 17, 2003 at 11:12:40 AM EST

    It's about the right tool for the job. I went strongly down the Java/OO route in 1996 and stuck with it until last year. I delivered some good maintainable products but the projects were always heavy, requiring lots of design and lots of coding base classes (nothing for the client to see) prior to building the UI.

    Now I work in a team that does small, tactical web work, mainly intranet, and we code just what we need, pretty much directly on the web page, no classes, beans, components. It's quick the clients see it early and give feed back early. I wouldn't do a heavy weight TP system this way, but there is no way my current clients would pay for full blown OO

    I think improved hardware makes your approach win (none / 0) (#189)
    by duffbeer703 on Thu Apr 17, 2003 at 11:10:09 PM EST

    In many cases, the speed of developing multiple, smaller-scale point solutions makes up for any performance or other advantage that you get from a design-heavy language like Java or C++.

    I wrote a prototype of a key section of a very, very large project in Perl about 4 years ago. It took me  and an assistant about two months to get it up and running. That prototype, with some modification, remains in production after several attempts to put "official" C++ replacements in place.

    The funny thing is, with faster and faster hardware, applications written in interpeted languages like Perl or Python or even PHP perform to acceptable levels. To me, it's difficult to justify the high cost of traditional development in most cases.

    [ Parent ]

    K. I. S. S. (4.75 / 4) (#109)
    by vetgirig on Thu Apr 17, 2003 at 11:22:10 AM EST

    Keep it Simple Stupid. Always, always, always. The smaller the code the better the code. Keep it Simple Stupid. But it is like they say a fortran porgrammer can write a fortran program in any language. One should not let smalltalk designeer design a C++ program and vice versa. All those manager who think that by applying the latest buzzword they will get better performance. You always get better programs if those that know what they are doing are doinng the work - not some manager who does not know anything about the code. A good manager know when to listen to the programmers judgemnet ...

    Marketing and XML, my experience (5.00 / 3) (#110)
    by daragh on Thu Apr 17, 2003 at 11:25:06 AM EST

    I used to develop ASP-driven, web based content managment systems. Our marketing people sold our "product" to the most important government department in Ireland. One of the big buzzwords they used in the sale was XML. The result was that we were told to build a system and make sure that it had XML in it somewhere. Of course, there was no XML experience AT ALL in the company, except for having read 3 chapters of a book.

    Needless to say it was a disaster. The project took twice the time it would have, and still was delivered with 53 major bugs.

    Although there were other reasons it was such a terrible system (I came accross one page with a 1500 line function for example!), the buzzword focus definitely took its toll.

    My current project has two buzzwords, .NET and the Grid. However, this I find that .NET is living up to its hype, in terms of being a good platform to develop software on. As for the Grid part, well, we'll have to wait and see...

    No work.

    .NET Experience (5.00 / 1) (#182)
    by MyrddinE on Thu Apr 17, 2003 at 08:10:02 PM EST

    Have you encountered bugs so far in the .NET runtime that you have to 'work around'? That was the biggest thing that frustrated me when working with most languages was all the compromises needed here and there... I started going to school for programming, and ended up deciding it really wasn't for me.

    I still program, but as a hobby, since I could never take the grind of doing it as a job. I can quit a project if it gets too frustrating.

    I've recently started working with .NET, specifically C#. I'm finding the experience pleasant so far... I had far less then pleasant experiences with Java, trying to make things that were truly cross platform... running into runtime errors and incompatible environments. shudder

    Just curious if I should be looking forward to similar issues with .NET. :-)

    [ Parent ]

    Not yet, at least (none / 0) (#204)
    by daragh on Fri Apr 18, 2003 at 08:19:02 AM EST

    I've not come accross any bugs in the runtime as yet, but it's only been two months. If you find any, please alert me! Overall, I find the entire framework to be very clean, no workarounds required in the majority of situations, which isn't like a lot of previous MS initiatives. They've really done a fine implementation of a great design this time round. And they've explicitly dealt with things like versioning problems with the notion of assemblies.

    If you are just starting out, I recommend the following. www.thecodeproject.com has lots of coding resources for all MS tools, and the book Applied .NET Framework Programming by Jeffry Richter is a very comprehensive and detailed introduction to the intricacies (and possible bugs, I've not read it all yet!) of the runtime and framework classes.

    No work.
    [ Parent ]

    Bugs (5.00 / 2) (#210)
    by ucblockhead on Fri Apr 18, 2003 at 12:02:26 PM EST

    We've run into a few. Unfortunately, .NET still calls the old Win32 API underneath, and this causes problems. One frustration is that some objects basically dispose themselves even when you attempt to keep a reference to them. (Registry keys are one.) You have to go through all sorts of rigamorol just to get them to hang around.

    The design itself is indeed pretty good, but I really wish they'd rewritten it at a deeper level.
    -----------------------
    This is k5. We're all tools - duxup
    [ Parent ]

    My (very limited) .NET experience (5.00 / 1) (#231)
    by MSBob on Sun Apr 20, 2003 at 11:07:15 AM EST

    I have very little experience with .NET and can't really speak too much about it. However, I do have quite a bit of Win32 experience and I hate that API with passion. When I looked at the C# class libraries I could readily tell which C# classes called which Win32 methods. C# class libraries provide some wrapping for the old microsoft legacy but it's a very thin wrap, not that much better than the venerable MFC.

    Java Runtime on the other hand is one of the best designed APIs for a C++ like language that I've seen. The only API that can compare in terms of its "niceness" is Qt and some proprietary class libraries that I came in contact with.

    My point is that as far as developer "friendliness" is concerned I see Java being miles ahead of C# and its runtime. I don't know why, but in my opinion, Microsoft just doesn't have a knack for designing clean APIs.

    I don't mind paying taxes, they buy me civilization.

    [ Parent ]
    Cheers for the pointer (none / 0) (#244)
    by daragh on Tue Apr 22, 2003 at 09:16:05 AM EST

    I suspected that this was the case, but thankfully I've not been doing anything that has caused me to run into problems with this. I guess a deeper rewrite may be forthcoming once the platform is accepted more widely.

    No work.
    [ Parent ]

    Code reuse != OOP (4.00 / 3) (#134)
    by obsidian head on Thu Apr 17, 2003 at 01:06:48 PM EST

    I don't believe code reuse is a feature of OOP.  Code reuse comes from not laying people off every year and using opensource software.

    I think the OOP sold reuse because it's the holy grail of software eng, ever since that 1968 NATO conference where "software engineering" was coined.  The way to sell OOP to government and large companies is to shout REUSE and to emphasize inheritance much more than it deserves.

    Bingo (4.50 / 2) (#151)
    by Vulcannis on Thu Apr 17, 2003 at 03:37:17 PM EST

    Reuse was hype that sold OOP and more specifically C++ to the managers and bosses.  Widespread, general reuse of any code not specifically designed for that purpose is a fairy tale.  Hell, reuse of code designed to be reused is difficult enough. :P

    I don't see the connection between reuse and inheritance, however.  Inheritance is perhaps the least understood and most misused OOP concept, but any blame for that lies squarely with the practitioners not the concept(s).  Just because the  implementation of inheritance in one language's object model sucks doesn't mean it sucks in another language, nor that either models the concept the way it is researched.

    ---
    If it's not black and white, you're not looking close enough.
    [ Parent ]

    Implementation inheritance (3.00 / 1) (#157)
    by obsidian head on Thu Apr 17, 2003 at 04:11:18 PM EST

    As I understand it, implementation inheritance allows you to reuse the code of superclasses.  Maybe I am confusing "inheritance" with "implementation inheritance"?

    [ Parent ]
    Heh (5.00 / 2) (#172)
    by Vulcannis on Thu Apr 17, 2003 at 04:47:22 PM EST

    It all depends on the object model in question.

    Implementation inheritance commonly refers to cases where inheritance is used mainly to reuse code, in an effort to avoid copy-and-paste.  Some people swear by it, others (such as I) swear at it.  The problem is that most implementations (C++, Java, C#...) of inheritance always create a subtype relationship when a class is subclassed.  Such dual-natured inheritance can create more problems in a program than implementation inheritance tries to solve.

    Some languages (Green, etc.) separate subtyping from subclassing, introducing two constructs.

    ---
    If it's not black and white, you're not looking close enough.
    [ Parent ]

    templates (4.00 / 1) (#173)
    by ucblockhead on Thu Apr 17, 2003 at 04:50:22 PM EST

    One nice thing about generics is that you can get the same sort of code-reuse without offending object purists.
    -----------------------
    This is k5. We're all tools - duxup
    [ Parent ]
    Bingo. (none / 0) (#184)
    by LukeyBoy on Thu Apr 17, 2003 at 08:20:44 PM EST

    You're right, code doesn't have to be object-oriented to be reusable.  Take a look a the CPAN project - I'm sure a lot of the modules are OO-style, but thousands upon thousands are not.  And CPAN is the most beautiful example of code reuse I've seen.

    Well, actually that's false; the best examples of code-reuse are KHTML and Gecko - both of which are object-oriented.  But my first point still stands! :-)

    [ Parent ]

    oh those smalltalk guys.... (3.66 / 3) (#135)
    by zzzeek on Thu Apr 17, 2003 at 01:11:23 PM EST

    yours is not the only day they have ruined in the past !

    "this is the paradigm WE like.  YOUR paradigm sucks [because we have never learned it or used it and we don't know how to please our boss with it/avoid getting upstaged by you].  so we will force YOUR langauge to match OUR paradigm.  Then YOUR language will be good.  Like we said.  Oh but YOU can do all the actual work [with our crappy idea, and when you screw up, we'll tell the boss YOU dont know how to code.]  Good luck !"

    but continuing... (2.25 / 4) (#136)
    by zzzeek on Thu Apr 17, 2003 at 01:19:40 PM EST

    from what you wrote, it doesnt seem that OO or a committment to making the code "object oriented" is what caused it to fail.  It was a bunch of academic numbskulls who dont know how to get working code done on time, regardless of design paradigm.  You CAN do your code completely OO but still have things that belong in a database be in the actual database, you just make sure there is an object layer to completely shield all developers and users from the "evil" non-OO database structures.

    it would not behoove my good mood to get started on stories of academic weenies charged with architecting applications....

    [ Parent ]

    Many, many issues (4.80 / 5) (#137)
    by epepke on Thu Apr 17, 2003 at 01:19:54 PM EST

    This article raises many issues.

    First and foremost is the square peg in the round hole thing. Making a package "object-oriented" just for the sake of it is obviously a counterproductive management decision. A close second is the buzzword versus the ding an sich. It seems apparent to me that the management had no clear understanding of what they meant by "object-oriented." This leads to an auxiliary problem: what is "object-oriented?"

    Alan Kay once said something like "I coined the term 'object-oriented,' and C++ wasn't what I had in mind." Even this, though, conflates the problem. There are object-oriented design and implementation techniques. There are also languages that are intended to facilitate these techniques. They are not the same.

    One can do nicely object-oriented design in a completely procedural language. It may not be convenient, but it can be done. Similarly, one can do procedural programming in an object language.

    The original philosophy of object-oriented programming, popular amongst Smalltalk programmers, has not made it over to C++. This is for a variety of reasons. One is re-implementation of legacy code. Another is that C++ imposes some costs on dynamism. It's still possible to write decent O-O code in C++; it just isn't very common. Java has fared somewhat better, but not much.

    Instead, what happens usually in C++ is what I call "class-oriented programming." Classes become like robots or glorified modules.

    The example I usually use is the one used by a lot of textbooks. If one is to write a bank account, the C++ way is to have a BankAccount with member functions like deposit(float amount). The Smalltalkey/original O-O way would be to have objects that represent money (100 dollars or 90 euros, say) and have them controlled by transaction objects that only then interact with account objects.

    Which is better I'm not going to argue here. Both have their place, as do functional programming, procedural programming, etc. But although it is certainly possible for the same person to understand both ways of doing things, throwing together a bunch of Smalltalk gurus and C++ people is just a recipe for disaster.


    The truth may be out there, but lies are inside your head.--Terry Pratchett


    OOP in non-OOP languages (3.00 / 1) (#147)
    by Symmetry on Thu Apr 17, 2003 at 02:47:07 PM EST

    One can do nicely object-oriented design in a completely procedural language. It may not be convenient, but it can be done. Similarly, one can do procedural programming in an object language.

    Heck, in intro to CompSci at MIT they made us do object oriented programming in Scheme (a Lisp varient). It wasn't pretty, but it worked fine.


    Never attribute to malice what can be explained by stupidity. Don't assign to stupidity what might be due to ignorance. And try not to assume you opponent is the ignorant one-until you can show it isn't you. -M.N. Plano
    [ Parent ]
    SICP OOP (5.00 / 1) (#158)
    by jjayson on Thu Apr 17, 2003 at 04:14:24 PM EST

    At Cal we have a very similar intro to CS class and the OOP work done is beautiful. It exposes what is meant by "message passing" in a very simple, clear way. Inheritence and delegation are compared and constasted in the lucid teaching object system, along with other important topics, and I think it has given me a better understanding of OO principles. This was my very first programming experience so I had no previous conceptions of what a language should look like or what an object system was.
    _______
    Smile =)
    * bt krav magas kitten THE FUCK UP
    <bt> Eat Kung Jew, bitch.

    [ Parent ]
    I'm not saying it was bad... (3.00 / 1) (#179)
    by Symmetry on Thu Apr 17, 2003 at 07:52:35 PM EST

    I certainly learned quite a lot from it, and I think I understand OOP better for it. But you have to admit that implamenting OOP that way is a little bit...akward.
    Never attribute to malice what can be explained by stupidity. Don't assign to stupidity what might be due to ignorance. And try not to assume you opponent is the ignorant one-until you can show it isn't you. -M.N. Plano
    [ Parent ]
    Scheme (3.00 / 1) (#161)
    by epepke on Thu Apr 17, 2003 at 04:24:55 PM EST

    One of the projects I'm working on is a Scheme with objects, embedded in a much larger thing. At first, it was just LISP-like memory management with object extensions. But then I realized that the object structure resembled a Scheme environment, and everything just dropped out like magic.


    The truth may be out there, but lies are inside your head.--Terry Pratchett


    [ Parent ]
    heck indeed (none / 0) (#198)
    by delmoi on Fri Apr 18, 2003 at 01:22:33 AM EST

    Given that Scheme is not a procedural languages. Given the fact that functions are first-class objects (i.e you can pass them around like any other data items) it's not very hard to do OO. Especialy if you use define-datatype.
    --
    "'argumentation' is not a word, idiot." -- thelizman
    [ Parent ]
    How ironic... (4.00 / 2) (#149)
    by Vulcannis on Thu Apr 17, 2003 at 03:24:29 PM EST

    ...referring to classes as glorified modules.  Some people, such as Bertrand Meyer, believe that classes are the mechanism for modularity in OOP and that there is no need for additional abstractions, such as Java's package.

    Of course, this just highlights how ridiculous it is for anyone to point to OOP and say it is "this and this and this, not this and this and this."  Many concepts are described as OO, but there is no overriding definition of what exactly OO is, unlike other techniques such as imperative, functional, etc..

    ---
    If it's not black and white, you're not looking close enough.
    [ Parent ]

    Java packages (none / 0) (#183)
    by LukeyBoy on Thu Apr 17, 2003 at 08:17:27 PM EST

    Packages in Java serve the important purpose of namespacing groups of related objects.  Distinguishing between the thousands of class libraries out there becomes important, and the package accomplishes this.  I wonder how Bertrand would justify not using this.

    Some people use the package keyword to allow package-only access to certain members of a class (like the friend keyword in C++), but I rarely see this.

    Maybe I'm totally off base though, who knows.

    [ Parent ]

    Yah (5.00 / 1) (#194)
    by Vulcannis on Fri Apr 18, 2003 at 12:53:55 AM EST

    I can't see not having some kind of additional packaging mechanism either.  Who knows, perhaps Eiffel has one now just not originally.

    I never did like the special status that Java allowed to be given to package members though.  It strikes me as too course, though it is a big improvement over C++'s friend of course.  I think Eiffel's way of doing things is superior, where each method is given a list of possible classes that have access to it.  So granting access to ANY (the common base class) is equivalent to public access.  Granting only to the defining class would be equivalent to protected.  Gives much finer control than either C++ or Java.

    ---
    If it's not black and white, you're not looking close enough.
    [ Parent ]

    You would have subclasses, I guess. (5.00 / 1) (#197)
    by delmoi on Fri Apr 18, 2003 at 01:20:54 AM EST

    I'm guessing you would have something like a root level 'graphics' object, would have sub-objects like 'graphics.buffer' 'graphics.line' etc. The code would look exactly the same as if you used fully qualified names package names (i.e. java.awt.Graphics g = new java.awt.Graphics();).
    --
    "'argumentation' is not a word, idiot." -- thelizman
    [ Parent ]
    Classes should not be modules (5.00 / 1) (#223)
    by p3d0 on Fri Apr 18, 2003 at 10:39:55 PM EST

    I believe Bertrand Meyer has said a great many smart things, but I don't agree that classes should be the only unit of modularity.

    IMHO, a "module" is a unit of software that stands on its own as an interchangeable building block. To me, a natural consequence of this is that there cannot be cyclic dependencies between modules: if A depends on B, and B depends on A, then neither can be "interchanged" without the other, so they don't qualify as modules. Instead, both A and B belong to the same module.

    On the other hand, it is frequently useful to have circular dependencies among classes. Ergo, an OO language needs a module construct separate from its class construct.
    --
    Patrick Doyle
    My comments do not reflect the opinions of my employer.
    [ Parent ]

    C++ doesn't impose a penalty on dynamism (5.00 / 2) (#226)
    by fluffy grue on Sat Apr 19, 2003 at 02:08:35 PM EST

    Instead, it provides a major boost for staticism.
    --
    "Is not a quine" is not a quine.
    I love you.

    [ Hug Your Trikuare ]
    [ Parent ]

    Doomed from the start ... (4.50 / 4) (#159)
    by nicodaemos on Thu Apr 17, 2003 at 04:16:08 PM EST

    I don't think you really had a snowball's chance in hell of creating a good product at that large company.  The biggest issue seemed to be that you had technical leadership who was more interested in mental masturbation than actually producing a product.  But then, you already know that.

    What I will give you is a suggestion on how to handle the whole data driven versus business rules in code argument in the future.  By the way, OO methodology has nothing to do with it.  The real crux of your problem was that you wanted the business rules in the database, whereas the smalltalk guys wanted them in code.  OO doesn't care where you put your business rules.

    You shouldn't go away with this experience thinking that OO is bad and procedural/data driven is good.  Both approaches have their place, sometimes within the same application, but the key is knowing when and how to apply each one.  The lesson you should walk away from this with is that smalltalk guys talk big, but are really compensating for their small*****.  ;-)

    Anyway, if you've identified something like where business rules are stored as 1) being very important to the success of the product and 2) a topic of contention amongst the technical staff, I would recommend bringing it back to your product managers or sponsor and getting them to help set requirements.  If you have a requirement that your business analysts (product people) are able to change rules by modifying the database, then you get your design the way you want it.  The smalltalk guys get overruled.

    Use your customer or sponsor to play the bad guy once in a while.  Less wear and tear on you.  After all, they are the ones who have to live with the ramifications.


    Handling it (3.50 / 2) (#162)
    by ucblockhead on Thu Apr 17, 2003 at 04:26:10 PM EST

    Fortunately I work for good managers these days. :)
    -----------------------
    This is k5. We're all tools - duxup
    [ Parent ]
    Cool (4.00 / 1) (#177)
    by nicodaemos on Thu Apr 17, 2003 at 05:35:30 PM EST

    I think it takes having a few bad managers to really appreciate the good managers when they come along.

    Congrats on your find!


    [ Parent ]

    why is this not in the queue? (2.00 / 1) (#193)
    by delmoi on Fri Apr 18, 2003 at 12:52:17 AM EST

    a very intresting story.
    --
    "'argumentation' is not a word, idiot." -- thelizman
    note to self: pay more attention (5.00 / 1) (#196)
    by delmoi on Fri Apr 18, 2003 at 01:06:19 AM EST

    I thought I was reading the diary section. Please ignore the above comment : P
    --
    "'argumentation' is not a word, idiot." -- thelizman
    [ Parent ]
    Most Important Coding Philosophy Ever (none / 0) (#228)
    by theshunt on Sat Apr 19, 2003 at 07:59:56 PM EST

    If: the program was difficult for you to write

    Then: the program should be difficult for your successor to comprehend.

    Ban comments and subroutines!!! Hail monolithicity!



    Gaff! (3.00 / 3) (#232)
    by The Devil on Sun Apr 20, 2003 at 12:11:05 PM EST

    Eeek. Your team fell for worst play of all times: the Sword & Shield. This is when a company wants to do something computer related and since they have the underlying belief that all computer people are no good charlatans bent on ripping them off, the company sets a mandate to have a sword and shield (two teams with adverse objectives, where both are held in place by the fear of the other).

    So your code was 35% OO. Did they share with you how the hell they came up with that number? Or did the other team 'assess' you and come up with it? You claim they brought in the other Smalltalk group after the code audit? Who performed the audit? Bah it doesn't matter. It seems to me that what you needed to do was have more meetings with the people who would receive the final product and have them spell out the design for you better. If they could not do that, then you have a problem with the customer that is really scary.

    Something else occurred to me reading this. You need to read Scott Adams' "The Way of the Weasel". And by God, get a more fierce band of weasels working for you in the future. Because you're a tech guy - you are automagically at a disadvantage to high level business types that will steer your project into the ground.

    ancient history (3.00 / 2) (#233)
    by ucblockhead on Sun Apr 20, 2003 at 12:47:56 PM EST

    Keep in mind that these events happened in 1991. This was long, long ago, and I have since moved on to greener pastures.

    The code audit was done by and independent third party. I believe the percentage came from the number of lines of code in classes vs. the number of lines of code not in classes, which is obviously pretty silly.

    One of the ironies was that the company we were involved with couldn't get more "computer related". Think "very large company that goes by a three-letter acronym". Think "written under OS/2".
    -----------------------
    This is k5. We're all tools - duxup
    [ Parent ]

    Dollars (3.33 / 3) (#234)
    by The Devil on Sun Apr 20, 2003 at 01:25:08 PM EST

    I'm going to bet dollars to donuts that the independent 3rd party hoped to be hired to take over for you guys. Lines of code in classes vs. lines of code outside of classes? I think I read a Dilbert comic about this once!!! Hmm... How did it go? I forget. Oh hell yeah. The pointy haired boss accused the engineer of stealing money from the company by making the code slow, and his idea of why was because of how many lines of code weren't classed properly. He then went on to describe verbatim why interns were classed as office furnature, and he then tried to use this as a method to prove he was correct about the code-kiting.

    Ahhh the famous company that can't be mentioned for legal reasons ala NDA. I guess this explains why they nearly flopped around 1993, eh? But they seem to have learned their lesson recently. I blame Colin Powell for that one.

    [ Parent ]

    Do we really need OO (4.00 / 1) (#236)
    by ssethu on Mon Apr 21, 2003 at 03:22:38 AM EST

    "I have a cat named Trash. In the current political climate it would seem that if I were trying to sell him (at least to a Computer Scientist), I would not stress that he is gentle to humans and is self-sufficient, living mostly on field mice. Rather, I would argue that he is object-oriented." -Roger King

    two obvious mistakes... (4.00 / 1) (#239)
    by gps on Mon Apr 21, 2003 at 02:15:52 PM EST

    (a) you sold a small functioning company to a much larger one and expected it to go well on its own.  oops.  if it wasn't in your sale contract that they were buying you to fund finishing your project in your own way using your already existing functional team structure that's asking for a screwing...

    (b) academic/theory minded people have a place.  that place is not on the front lines of finalizing the design/development for a project that's already made major progress.

    Object orientation wasn't the real issue here.  It was just a convenient focus for someone to screw up on.  It could just have easily been, "but your product is only 35% green in our syntax highlighting editor.  we'll have to repaint the whole thing.  using intercal."


    Moron Alert! (none / 0) (#249)
    by levsen on Fri Apr 25, 2003 at 11:03:52 AM EST

    Nothing against the explicit conclusions of this article, but certain expressions (OOP being called a "buzzword") as well as some comments make me think that there is an implicit conclusion too: OOP is mostly wrong.

    What has to be said here is what I said about multithreading in a comment to another k5 article: OOP widens the gap between smart and not-so-smart programmers.

    And those who find themselves on the wrong side of that gap eagerly grasp onto any anecdotal evidence that OOP was a bad idea after all.

    Folks, OOP is not XML. Why I have seen XML being abused beyond my wildest imaginations, I yet have to see any code that does not benefit from being OOP.


    This comment is printed on 100% recycled electrons.

    Only 35% object oriented | 250 comments (233 topical, 17 editorial, 0 hidden)
    Display: Sort:

    kuro5hin.org

    [XML]
    All trademarks and copyrights on this page are owned by their respective companies. The Rest 2000 - Present Kuro5hin.org Inc.
    See our legalese page for copyright policies. Please also read our Privacy Policy.
    Kuro5hin.org is powered by Free Software, including Apache, Perl, and Linux, The Scoop Engine that runs this site is freely available, under the terms of the GPL.
    Need some help? Email help@kuro5hin.org.
    My heart's the long stairs.

    Powered by Scoop create account | help/FAQ | mission | links | search | IRC | YOU choose the stories!