Wow. All that from 'cool','clever', and 'flexible'. Man I think you have some other issues at play here which is explained in the last line of your code. I can dig that, I had a bad experience with fish one time, I don't eat it now, but I don't go yelling at everyone who does calling them idiots. Bad analogy? Perhaps, but you stretched quite a bit in your little rant too so I think it is fair. "I've been down this road and got burned so no one should ever go down that road" is pretty weak as an argument. If you had someone redefine a function on you in the middle of debuging then be mad at that person, not at anyone who rights 'cool','clever', 'flexible' code.

As a side note I would call code 'cool' if it did something in a quick clever fashion that i immediatly understood. Code I can't understand wouldn't be called cool, and code I could do simpler another way wouldn't be called cool.

Clever would be code that uses an approach that isn't obviously found, but is easily understood. Ever learned the different sorting techniques and gone...wow thats clever!

Flexible to me would mean that while the code has one specific goal in mind, it was written with the ability to extend its functionality and use it in as yet unforseen ways. The sort function in perl is pretty darn flexible and will let you do cool and clever things with it ;)

Thats my two cents, take it, leave it, whatever.

If you had someone redefine a function on you in the middle of debuging then be mad at that person, not at anyone who rights 'cool','clever', 'flexible' code.

You did notice that this is exactly what the Original Poster's self-proclaimed "cool" code does, right?

The point of his code is to let you add, define, and redefine attributes and methods at run time; this lets him completely alter the entire meaning of a entire class at any point in the program you he so desires.

In short, he's destroyed the regular expectation about how classes and objects will behave. He's said doing this just because it's "cool" to do so. He outright admitted that he felt that he was using bad programming practices, but somehow felt that being "cool" justified bad programming.

Do you wonder that I complained about this attitude? I think I am getting mad at the right person; the person who is about to redefine the codebase under me again, and the person who is teaching others to go do the same, without tempering "cool tricks" with the need to ensure that they're used carefully and correctly, and only when necessary.

The point of his code is to let you add, define, and redefine attributes and methods at run time; this lets him completely alter the entire meaning of a entire class at any point in the program you he so desires.

The point of his code is to let you add, define, and redefine attributes and methods at run time; this lets him completely alter the entire meaning of a entire class at any point in the program you he so desires.

So any use of runtime redefinition is bad? Even when it lets you abstract duplicate code, do like better testing, etc.?

Throwing away a useful programming tool because some people misuse it is like throwing away electric drills because some idiot uses it to mix their smoothie and manages to put a hole in their hand.

I'm tempted just to say "what BrowserUk said". But, I have something of my own to add:

Good code is not "cool", because ego is not involved. The code is correct, and works. How the programmer *feels* about the code is irrelevant. Good code and good practice stands on it's own merits; "cool", and other subjective, emotional metrics do not.

I simply wish to call BS. I have my reasons:

1. Good code can be cool code too. "Cool" can mean a lot of things: innovative and interesting among them. Innovative approches to solving problems can fall well within best practices -- and even when they don't, sometimes they are such an improvement that they become best practices. Object-oriented methodology was novel "cool" code at one time -- and it broke the rules of procedural programming that were generally accepted. Yet it's become so useful that it's become a best practice in many organizations.
2. Ego -- that is, pride in one's work -- is incredibly important to writing good software. Developing software certainly has disciplined aspects to it, but it's also a creative endeavor. So is designing a suspension bridge. Any master of any discipline will tell you that experience develops intuition. Intuition is nothing more than seeing something and knowing it's got potential (or not) because it "feels right" (or wrong). Granted, you should always back up such feelings with evidence before you go production, but that emotional process is essential to creative problem solving and efficient work.

Yes, there are times when "creative" or "cool" solutions are inappropriate, but it is not (as you suggest) always inappropriate. It only becomes a problem when the niftiness of the solution begins to outweigh practical considerations -- when "cool" becomes more imporatant than "good".

See, "cool" and "good" are not mutually exclusive.

Have you ever seen footage of the 1950s office space? Row after row of identical desks, identical chairs, and identical typewriters; all rigidly aligned to the ordinals of the office walls and a regulation distance apart. No plants. No personal photos. Nothing to make one desk stand out from another apart from a discrete "g4" or similar. And of course the physical differences in the statutorily, near-uniformed apparelled occupants.

Those practices evolved on the basis of the notion that each cog in the industrial office space was interchangable, and that any and all demarkation between cogs was a distraction from the process of work and the overall efficiency of the machine. Deskill the tasks, train lots of cheap competents and use them as components. Remove all ego, personality and variability from the equation and, the theory went, you arrive at a cost efficient industrial machine.

Do you know why you don't see this type of office much beyond the early '60s? Why the Silcon Valley giants have jakuzies and sleeping rooms and one or two man offices? And why this is how the big name/success story in software development over the last 10 years r so goes about attracting new staff:

Students, imagine if you will...

A cafeteria where the food is plentiful, delicious and, yes, free.

A workplace where dogs are welcome and there's no dress code.

A workspace where the technology sitting on top of it is powerful enough to work through any computational challenge you can devise.

A lunch table where you sit down and learn your tablemate is the world's leading authority on a problem you were only vaguely aware existed – and the guy next to her wrote the textbook you used last semester.

A campus that offers not just free meals but also a gym, an endless pool, a volleyball court, razor scooters, massage therapy, laundry rooms and dry cleaning, and (of course) valet parking.

With us so far? Now's when the fun starts. Working at Google means making a positive difference in tens of millions of lives every day. Do you love to critique the design of everyday things? Do you dream of working for an innovative, world-class organization? Are you looking to work with engineers to create products that improve the lives of millions? If so, Google may have a place for you. We hire exceptional people, at all degree levels, BS, MS, and PhD. We have offices all over the world including Mountain View, California; Santa Monica, California; Kirkland, Washington; New York, New York; Switzerland; India; and Japan, all working on the same cutting edge solutions. The people at Google love to work on innovative products and believe passionately in our mission: to organize the world's information and make it universally accessible and useful.

It's because if you deskill a job; take away a workers pride in the job they do; eliminate personal innovation, flair--and yes--ego from the workplace; you get the cheapest per-hour labour bills, because you end up with the dregs of the profession. Those with low skills, no motivation to improve, that "occupy" theirs desk for the statutory minimum hours to fulfill their job descriptions, whilst turning out the bare minimum of lowest quality work they can get away with. Combine the low productivity with the high turnover and subsequent initiation and training costs and those low pay rates suddenly become a completely false economy.

Until you can replace your humans with robots as the car industry did on their production lines, you'd better invest in training your programmers to a high standard, and valuing their innovations, skills and yes--egos. Show me a programmer who does it only for the money, and I'll show you someone who will be working for your rival next week or the week after.

Anyone can fix simple code, good or bad.

Oh good, the second great fallacy of maintainable software. I eagerly await your mother's patches to my vector-space text correlation engine.

I eagerly await your mother's patches to my vector-space text correlation engine.

Step 1: Read the specification of the algorithm from which you coded said engine. Step 2: Fix your coding flaws (the difference between what the algorithm says to do, and what your code does instead). Step 3: Profit. ;-)

Note carefully: coding is NOT the same thing as developing new domain knowledge. Coders write down existing domain knowledge written in English, and translate it into steps simple enough for a computer to understand, in a way that is clear, obvious, and correct.

Sometimes, in their hubris, coders make the fatal error of inventing their own domain knowledge instead of consulting the experts; this is a primary source of both coding errors, and badly re-invented wheels.

To further confuse the issue, in some rare cases, such as the realm of mathematics, the coder may in fact BE the local domain expert, but make no mistake, the roles are distinct.

A good expert still double checks his expertise; mathematicians peer review their algorithms among as many experts in the field as possible. Physicists don't trust an experiment until it's been duplicated multiple times. Engineers wait several years for a new concept to "stand the test of time" before they adopt it. Outside an R&D lab, people do what's been done before, and is known to be correct, and they rely on the knowledge of trained experts to accomplish it. For coders, that task is one of a highly specialized form of technical writing called "computer programming".

If my mother was a PhD in Mathematics with a specialization in vector spaces, I doubt she'ld have much trouble debugging your flawed implementation; but only if that implementation was laid out in a way she could read and understand.

Also, if my mother has access to a domain expert, and can understand what the expert is saying, she can fix the code, if it's well written. To do this, she needs good communications skills, and a minimal ability to read and write code in a uniform, obvious way. A basic understanding of the problem domain may also be of benefit.

To me, it isn't a fallacy that anyone with a basic grounding in coding can fix code flaws, given sufficient documentation and clear code. The real mistake seems to be the notion that experts aren't needed, domain knowledge is irrelevant, or the insidious notion that arises in certain circles which suggests that coders are more important than the thing coded...

And your mother is obviously going to be writing well written and easily maintainable code using good programming practices with no training whatsoever, because is just that easy.

After all, it takes a degree in computer science before you can screw up programming.

The real mistake seems to be the notion that experts aren't needed, domain knowledge is irrelevant...

That was precisely and simply and exactly my point. I don't care if a novice can't maintain my vector space categorizer because it uses some advanced programming techniques. If you hire a novice without domain knowledge to maintain that code, your problem is completely exactly not that he might, gasp horror, encounter a closure in my code.

..How the programmer *feels* about the code is irrelevant...

Exactly. The "coolness" is irrelevant when determining the quality of the code. Which means "Cool is not an antonym of good practice".

Flexible is not an antonym of well defined.

"This function is ultimately flexible, just like a Turing machine!!! In fact, it emulates a Turing machine!" Which means, means, by definitiion, that it's impact on the problem to be solved is vaguely defined; absolutely nothing has been specified about the behaviour of how the final result will be generated. Running one turing machine inside another is the ultimate in power, flexiblity... and pointlessness.

Besides the fact this is a blatant straw man argument, Turing machines are also well defined. Which means "Flexible is not an antonym of well defined".

Clever is not an antonym of simple.

Clever code requires thought to understand, because it's clever and tricky, and showcases the ego of the programmer. Simple code instead seeks to document the program requires, even as it fulfills them.

I totally agree. "Tricky is an antonym of simple". Don't know why you brought it up as part of "Clever is not an antonym of simple" though.

Besides the fact this is a blatant straw man argument, Turing machines are also well defined. Which means "Flexible is not an antonym of well defined".

1) That's not just some straw man. Unfortunately, that's an example from real life. I've maintained code that had a finite state machine to emulate function calls embedded in... Perl, which does function calls: that is, a general state machine calling another general state machine. The author maintained that adding the list of functions to be called (with different names) as a list instead of "recursive function calls" was somehow easier to understand. He was proud of how flexible and dynamic it was. He's one of many bad Perl coders I wish I'd never met. :-(

2) The machine is well defined. It's operation is not; it varies depending on the input, which is not specified. Is that specific enough for you?

It is a straw man argument because you chose a single easy example where something was flexible but ill defined to refute the claim that flexible is not an antonym of well defined.

All you did was show that flexible is not a synonym of well defined, but that was never assertion.


The author maintained that adding the list of functions to be called (with different names) as a list instead of "recursive function calls" was somehow easier to understand.

So he was doing exactly what you are arguing for: Removing the cleverness. In his mind, instead of using the fancy-dancy clever recursive function calls, he used a simple-straight forward state machine. Anyone can understand a state machine! You can always break it down into a series of boolean logic statements, what's simpler than that?

Its exactly what BrowserUK is pointing out. What is "clever" and what is "simple" depends entirely on your level of understanding, and your training.