Well, ML is apparently NOT machine language and C++ is just like C except you can comment out multiple lines easier. Or it is in some of the books I never finished reading.
Actually, it sounds like we should be on the same page. What I’m saying is that choosing the established and tried and true, combined with leveraging the knowledge and experience of your programmers, is IME much better than chasing after the “leet” new language that comes up. When I say “inelegant”, I mean “solid, stable, works, easy to maintain - but doesn’t use all these reputedly neato features that the trade journals and online pundits who haven’t written more than 100,000 lines of code their entire lives tell everyone they should be using.”
In my office, the word “elegant” is used derisively by both experienced programmers and the managers to describe people who reply on “neat” tricks and shortcuts in exchange for longer, but more stable and straightforward code. And example is using the silly C conditional one-line if-else, instead of the normal, readable way. I’ve also seen “elegant” programmers waste thousands of dollars avoiding using a “goto”, simply because it was anethema for them to use it. When there was no real downside or drawback to it at all. I’ve even had one refuse categorically to do a job porting some complex FORTRAN math code because he could see no way to do it without using goto statements, and he simply would not do that. So he walked off a project, rather than lower himself to the inelegance of the goto.
So I did it, and it works. But then, I’ve never been called “elegant”.
Don’t get me started on the person who flushed $20k down the toilet making a new CString class, adding no new functionality, just because he “didn’t trust Microsoft to do it right”. :rolleyes:
Ah, I’ll agree with that, then. Heck, even Donald Knuth has been known to use GOTOs, in those rare cases where they offered true benefits.
Mind you, I do like to use UML, design patterns, templates and a variety of other nifty tricks. I also devour books on good C++ style (in particular, the works of Scott Meyers and Allen I. Holub). However, there definitely comes a point where these techniques can be a hindrance instead of a help.
I think your situation, as you described it, is rather unusual. In my experience, the vast majority of companies and programmers devote far too little attention to matters such as maintainability and elegance of design. It doesn’t help that managers typically value quick results over long-term stability. << Sigh >>
The best description I’ve ever heard for C++ was “It’s C with object-oriented programming bolted to the side.” 
And speaking as someone who’s not only sat through software peer reviews, interviewed applicants, and developed coding standards from scratch, I’ll just say any programmer who relies on “clever” coding tricks, three-letter variable names, and believes comments are unnecessary because someone can just read the code and follow along will have a very short career around me…
I agree with what you have been posting.
When I started out many years ago, I worked with a small group of very talented technical people including the owner of the company. They were talented in the sense that they were not only technically savvy, smart and clever, they were also practical and knew that everything we did was really an optimization of today’s cost/benefit ratio vs the longer term cost/benefit ratio.
Sometimes we did stuff very quickly and not very elegant because we knew the customer just needed a short term solution and did not want to pay for elegance.
Other times we did stuff elegantly because we knew the system would be in use for years as well as being a base for other projects.
But during the years of working with these people that were all on the same page, once in a while new employees would come through that just didn’t get it. Either one end of the spectrum (don’t ever worry about elegant design) or the other end of the spectrum (create Graceland when you need a tool shed), and it typically cost us.
Sorry it took so long to answer these messages.
Yes, you are right, of course: Management doesn’t assign new languages willy-nilly. But when they decide there is a good reason for us to use a new language for a particular job, we are expected to learn it quickly. To be honest, it hasn’t happened that often. In the past eleven years I’ve been required to learn C, C++, Java, Perl, and Python. But in each case the principle was the same: I had to learn the language if I wanted to keep my job.
It’s actually kind of funny nowadays. When I most recently had to learn Python, my boss told me, “You’re a quick learner – you’ll figure it out in a couple of days.” Well, it took a LITTLE longer than that to become good at it.
Ed
Because a real software engineer is an engineer who codes, not a coder who engineers, right?
I agree. If you want something that’s going to work in a week, fine, I can meet that deadline. I can write something quick that’ll work a week from now, that’ll be of the ‘It compiled; SHIP IT!’ style of programming. If you want me to design a good program, a solid program, one that will last a long time and have minimal bugs in a year or two, I need more than a week to write it, in any langauge.
I think that’s exactly the opposite of what I was taught inelegant means. The elegant solution is simple, solid, stable, works well, and can be picked up and maintained by everyone. It does not attempt to squeeze in the superfluous bells and whistles that are available in a particular lanaguage just because ‘They are there. We might as well use them.’
I think you’re the first engineer I’ve ever heard use the term ‘elegant solution’ to mean the worst one. I prefer to use the direct route, rather than what my first engineer referred to as the ‘Tokyo method.’ He stated that one can get from Pittsburgh to Cleveland many different ways, and all of them would be correct. The simplest and most efficient way to get there was the elegant solution (think Little Black Dress) and the worst way was what he called the ‘Tokyo method’ - go from Pittsburgh to Cleveland via Tokyo.
I agree with the substance of your posts, I was just somewhat surprised to see that you use the terms ‘elegant’ and ‘inelegant’ 180 degrees out of phase with the ways I’ve always heard them.
As it is where I work now, I’m spinning my wheels dying for something that requires me to actuall engineer something, and they want me to write bad HTML and Perl. Whiskey. Tango. Foxtrot.
Sorry, Catsix. My use of the terms confused a couple of people. Your use is the more correct one; my use is a slang particular to my office, mocking a large group of programmers who essentially held us hostage for about 3 years and who always espoused “elegant” solutions that never worked, yet spent all the budget.
there is definitely horrible code to be written at either end of the spectrum. i work for a research group, and one thing that occasionally happens is we put together a piece of software for a demo or a conference, and someone hacks it together to get it to work without any major difficulties in front of a bunch of people. somehow, this would become part of our general library of code.
another thing that has happened is we had someone working here who worked as a software engineer before he worked here, and completely over-engineered everything. the layers of abstraction (including several functions that had but one line, such as an AbsoluteValue function that returned fabs()) made the code almost impossible to work with. also, i’m a big fan of the c++ stl, but does one really need to look for some obscure function that’ll fill ten items in a vector, when you can just use a nice, easy-to-read, for loop? we would joke and say “ah, this must be so-and-so’s code.” i’d never seen anyone typedef an iterator for a list of a certain type of objects to the word “iterator” before, and boy did that annoy the hell out of me when i saw it. “is this some kind of weird general iterator class that i don’t know about?” no, it was typedef’ed in a buried header, and it took me half an hour to figure it out.
both people involved in each of these types of things have since stopped working here, and i inherited their projects. it’s all i can do some days not to scratch my eyes out while reminding myself that a complete re-write is probably a bad idea.
I’ve always been a firm believer that engineers have to understand on a fundamental level that the purpose of business software is to make money. Otherwise, they’re useless at best and probably worse.
That’s quite common, I’ve seen it plenty of times. It’s quite useful when you have a container of containers, for example.
From a maintainability standpoint, it’s probably better to use a composite-decorator pattern for that case.