• Anonymous Coward (unregistered)

    What happened to the original FORTRAN version?

  • Anon (unregistered)

    I don't get it.

  • (cs)

    If it ain't broke, fix it until it is!

  • (cs)

    Yes, managers everywhere really are stupid enough to do a C++ to Fortran conversion without any consideration.

    It's not really a rare thing for a project manager to be blind to consequences in order to switch to the tools they prefer. I was recently on a project where we upgraded a fairly complicated ASP.NET 1.0 project (C# 1.0, VS.NET 2003, SourceSafe, some third party components) to ASP.NET 2.0 (C# 2.0, VS.NET 2005, and Team Foundation Server) all at the same time, while adding off-site workers to the project, in order to hit a deadline two weeks away. Same mistake, smaller magnitude.

  • nobody (unregistered)

    Why do I think many of the stability problems were due to the difference between FORTRAN arrays (1-based) and C++ arrays (0-based)?

    One time, I had to work with C++ code ported from FORTRAN, and got an array out of bounds error because of this (loop over 1 to 4 instead of 0 to 3). Unfortunately, the obvious fix wasn't acceptable, becuase the results couldn't change. No matter that the results might have had random errors

  • jrwr (unregistered)

    They should of just kept it as FORTRAN and shipped it.... maybe he still will as OSS

    Captch: Knowhuntimean ( ??!! )

  • (cs)

    I think Pap hit it on the head nice and succintly.

    Acquire and destroy! No, wait, that's not it...

    Again, unfortunately, not at all uncommon approaches to the software business. Amazing that we as an industry don't seem to learn...

  • teacher (unregistered) in reply to jrwr
    jrwr:
    They should of just kept it as FORTRAN and shipped it.... maybe he still will as OSS

    Captch: Knowhuntimean ( ??!! )

    I feel for The Professor - maybe if he had built it out of coconuts...

  • (cs)

    Ahhh ... I am once more vindicated.

    Engineers deploy, marketing destroys.

    If it works ok, leave it like that ... unless it is something like that COBOL-under-emulation-under-C-under-windows frankenstein thingy in one of the previous articles (can't remember what that was).

    But this one seems like it worked as it should.

    Addendum (2007-01-10 13:15): Ahh... I found it ... It's this one!

  • flatline (unregistered)

    This story is pretty sad - despite the occasional rumor, most professors are actually very smart (though generally too lazy or intolerant to go commercial). Now there's a professor somewhere who's had all his nightmares confirmed :)

  • justsalt (unregistered)

    What a shame. Good CAD programs on the Mac are pretty scarce.

    Especially ones I can afford.

  • Cody (unregistered) in reply to nobody
    nobody:
    Why do I think many of the stability problems were due to the difference between FORTRAN arrays (1-based) and C++ arrays (0-based)?

    One time, I had to work with C++ code ported from FORTRAN, and got an array out of bounds error because of this (loop over 1 to 4 instead of 0 to 3). Unfortunately, the obvious fix wasn't acceptable, becuase the results couldn't change. No matter that the results might have had random errors

    Couldn't you just subtract one from the array pointer so that newArray[1] == oldArray[0], allowing you to loop from 1 to 4?

  • JLuc (unregistered)

    Yup, reminds of a client/server project 10 yrs back where part of the first iteration involved writing some fancy batch scripts in PL/SQL. The business users were pretty sure what they wanted to do, but the details needed working out. Took me about 6 weeks to write the prog, using frequent interview/code/test cycles.

    Then the rest of the dev team is turned loose and writes all their batches in 2-3 weeks. I felt pretty dumb. However, it turned out their programs weren't tested very well and had a tendency to crash.

    So, for the next iteration, the brilliant tech lead blames it all on PL/SQL and opts for a more robust, standard, database batch programming language. Obviously, C++. I thought PL/SQL was fine, but suggested COBOL as a more appropriate alternative than C++. Yeah, that got a few snickers.

    When I left the project, in the middle of the next 6 month iteration, the newly hired C++ programmer was still figuring out how to write OO classes to do Oracle batch programs. And, of course, the users' reasonably imprecise specifications were just a joy to code, as C++ is just so easy to prototype with.

  • (cs)

    "1) Tweak & Clean-Up; 2) Brand and Market; and, of course, 3) Profit"

    Ah, so that's what Step 2 is supposed to be.

    /Step one, collect underpants...

  • Scott (unregistered)

    Shouldn't the program have belonged to his university

  • (cs) in reply to Anonymous Coward
    the packages ended up getting sealed away in a US Post Office warehouse somewhere. Who knows, they might even be there to this day ...

    They have top men working on it.

    Top men.

  • nobody (unregistered) in reply to Cody

    No, I couldn't just change the loop because it might change the results! And they were picky; they'd complain if the error was in the 6th digit of precision, about as good as you can get in a standard float. Actually, I had it go from 1 to 3 and that didn't change the results in the final tests.

    I want to avoid mentioning the company or the industry so I don't get sued.

  • Ryan (unregistered) in reply to tharfagreinir
    tharfagreinir:
    the packages ended up getting sealed away in a US Post Office warehouse somewhere. Who knows, they might even be there to this day ...

    They have top men working on it.

    Top men.

    Haha, yes. The first thing that popped into my mind when I read "wherehouse somewhere" was that scene.

  • non-believer (unregistered)

    A CAD program in FORTRAN with a usable GUI by someone who didn't realize it.

    I wrote and maintained a lot of FORTRAN in my day, but I don't believe this one.

  • Impressed (unregistered) in reply to Ryan
    Ryan:
    tharfagreinir:
    the packages ended up getting sealed away in a US Post Office warehouse somewhere. Who knows, they might even be there to this day ...

    They have top men working on it.

    Top men.

    Haha, yes. The first thing that popped into my mind when I read "wherehouse somewhere" was that scene.

    Best... Comment... Ever...

  • akatherder (unregistered)

    I had a witty comment, but the captcha distracted me and I forgot what I wanted to write.

    captcha: hotdog

  • Jim Steichen (unregistered)

    Things like tool-tips, help buttons, friendly menus, and grammatically correct messages would need to be added in to make the program commercially viable. When did all this extra crap become an acceptable substitute for proper training and knowledge about how to draft schematics, mechanical drawings, etc? Marketing seems to want to ensure that any IDIOT can use a given program (perhaps rightly so), but someone needs to bash some common sense into such people.

  • BBT (unregistered)

    Well, it's pretty obvious why they failed. They forgot the "?????" step.

  • Really Old Dude (unregistered) in reply to Impressed

    Why, you young whippersnappers don't know how easy you have it. Back in The Day, we used to debug with Oscilloscopes and jumper wires! Web? Hah! High level langauges? Hah! Debuggers? Don't even get me started...

    We had NOTHING! Not even Marketing people! Ahhh, THOSE were the (Good Ol') days....

  • (cs) in reply to Scott
    Scott:
    Shouldn't the program have belonged to his university

    In most cases it is not owned by the university. If anything the institutions that gave him research grants could claim ownership, but this should be clearly defined in the grant itself.

    The professor I work for retains owner ship of all the software developed by his research assistants through a shell company.

  • Nobody (unregistered) in reply to non-believer
    non-believer:
    A CAD program in FORTRAN with a usable GUI by someone who didn't realize it.

    I wrote and maintained a lot of FORTRAN in my day, but I don't believe this one.

    You never worked on anything from CV have you.

  • Kooky Koder (unregistered)

    There are two kinds: The fat rat and the hungry rat. The fat rat is happy with things the way they are, the hungry rat wants to change everything to "make it better". At the very least, he wants more food. The fat rat notices that things are NOT getting better, and asks you to stop trying to change things. The Hungry rat notices that things are NOT getting better, and asks you to change more things faster. Progress. Got to love it.

  • (cs)

    Ah, yes. Reminds me of the time when I started the new job with a company at the beginning of developing version 2 of an ASP (application service provider, not active server pages) app.

    They wanted the release out in 2.5 months with a boatload of new features.

    And, oh yeah, we were changing:

    • the OS
    • the DB platform from an open-source to commercial DB
    • the language of the application
    • the web server

    Doomed to failure? Nah...... what makes you think that?

  • (cs) in reply to non-believer
    non-believer:
    A CAD program in FORTRAN with a usable GUI by someone who didn't realize it.

    I wrote and maintained a lot of FORTRAN in my day, but I don't believe this one.

    One word: anonymization.

  • (cs) in reply to tharfagreinir

    LMAO!

  • (cs) in reply to Impressed
    Ryan:
    tharfagreinir:
    the packages ended up getting sealed away in a US Post Office warehouse somewhere. Who knows, they might even be there to this day ...

    They have top men working on it.

    Top men.

    Haha, yes. The first thing that popped into my mind when I read "wherehouse somewhere" was that scene.

    Cut to USPS worker wheeling a wooden crate through a huge warehouse full of similar crates. The worker puts the crate in its place, and leaves. The camera zooms in on the side of the crate.

    Suddenly, the hand-written words "CAD Softwar" burn themselves onto the outside of the crate.

    Roll credits.

  • Dustin (unregistered)

    So they convert from Fortran to C++... That made it unstable and that's not surprising, but slower?

    Anybody else here done this sort of conversion with that outcome?

  • jbl (unregistered) in reply to non-believer
    non-believer:
    A CAD program in FORTRAN with a usable GUI by someone who didn't realize it.

    I wrote and maintained a lot of FORTRAN in my day, but I don't believe this one.

    The later FORTRANs were quite capable. FORTRAN-77 (my god, it's 30 years old!) had lots of features that gave one access to an OS, as I recall.

    Myself, I was a lot better with FORTRAN IV (and FORTRAN II).

  • pete23 (unregistered) in reply to Dustin

    Why would a C++ version be faster? FORTRAN has had 30 years of optimisation effort thrown at it for a very specific class of problems - those involving lots of number crunching. C++ is a general purpose language supporting abstraction, and has a number of overheads.

    The Blitz++ guys - see http://www.oonumerics.org/blitz/whatis.html - have had to resort to a horrific amount of template metaprogramming and careful jiggery pokery to get similar performance out of C++. f2c (the automatic Fortran-to-C converter) just doesn't cut it.

  • Dustin (unregistered) in reply to jbl

    [quote user="jbl"][quote user="non-believer"]Myself, I was a lot better with FORTRAN IV (and FORTRAN II). [/quote]

    I don't even remember what FORTRAN I was taught and haven't used it since. I can't even remember if it was interpreted or compiled. So I don't really know what a mid 1990s FORTRAN compiler was capable of.

  • Jeff Bell (unregistered) in reply to Dustin
    Dustin:
    So they convert from Fortran to C++... That made it unstable and that's not surprising, but slower?

    That's not surprising that it's slower. Even C is slower than Fortran if there are lots of array operations. That trick of treating arrays as a special kind of pointer was cheap on a PDP-11, but hinders what the compiler can do.

  • JRock (unregistered) in reply to Impressed

    Fools!

    One of the top 5 movies ever.

  • (cs) in reply to quamaretto
    quamaretto:
    It's not really a rare thing for a project manager to be blind to consequences in order to switch to the tools they prefer.

    Nor for developers, of course. Although there a slightly better chance those actually know what they're doing and why. Of course in your case both the existing deadline a mere two weeks away as well as the apparent need for additional staff would be fairly huge warning signs not to.

  • (cs) in reply to Dustin
    Dustin:
    So they convert from Fortran to C++... That made it unstable and that's not surprising, but slower?

    Anybody else here done this sort of conversion with that outcome?

    Generally, whenever such a conversion is done, chances are that performance decreases unless someone spends a big lot of time to do the things in the way of the new programming language. In many cases, to make the conversion less painfull, the constructs of the old language are - as far as possible - transfered to the new language, even if there is a much better way to do it. For example, if you convert from a language that doesn't support templates to C++, chances are that you do not use templates in the C++ version either.

  • Abscissa (unregistered)

    I can understand them wanting to port it to C++: They want to avoid having to deal with maintaining and updating a program written in an antiquated language. Plus that would require retraining the development staff in said antiquated language (Anyone not like it being called "antiquated"? Good language or not, fortran has been pretty much cast aside - deal with it). So that part of it was a good management decision.

    The small WTF is classifying the language port a "minor tweak". But only a small WTF, because language ports aren't necessarily non-trivial: if the program is small and well-written, and it's ported to a similar language (ex, Java <-> C#, or C <-> D), then it can be a very quick and painless process. Of course, porting a CAD from FORTRAN to C++ isn't quite so trivial, which pushes this into WTF territory.

    The REAL problem here is that the developers doing the port were too unskilled to translate the code properly. If you know how to write reliable C++ code, and you properly translate any speed/reliability details from the original, then there's no reason the C++ version should be slower or less reliable. So the real WTF is hiring crappy programmers and then assuming they knew what they're doing.

  • Anonymous (unregistered) in reply to Really Old Dude
    Really Old Dude:
    Why, you young whippersnappers don't know how easy you have it. Back in The Day, we used to debug with Oscilloscopes and jumper wires!
    We still would, but scopes that run at 800mhz (~FSB speed, maybe) and jumper wires that connect to ultra fine pitch tracks are hard to come by :)
  • (cs) in reply to Jeff Bell
    Jeff Bell:
    Dustin:
    So they convert from Fortran to C++... That made it unstable and that's not surprising, but slower?

    That's not surprising that it's slower. Even C is slower than Fortran if there are lots of array operations. That trick of treating arrays as a special kind of pointer was cheap on a PDP-11, but hinders what the compiler can do.

    Come on people, remember Alex anonymizes everything.... The original app could have been C and the new app was Smalltalk or who knows what. The point is the company rewrote the whole thing in another language and felt this was a "small change" not the specifics of the language.....

    Basically it boils down to:

    1. We have a working app that needs some polish.
    2. Throw everything away.
    3. Write another app like the first app, but with shiny new bytes.
    4. When new app fails, blame first app.

    -Me

    Step 3 is profit! Yeah, yeah, yeah, but what about step 2? Step 1 is collect underpants Oh, I get it. No you don't Cartman!

  • (cs) in reply to flatline
    flatline:
    This story is pretty sad - despite the occasional rumor, most professors are actually very smart (though generally too lazy or intolerant to go commercial). Now there's a professor somewhere who's had all his nightmares confirmed :)

    It should serve as a lesson to the original professor. Use the program for academic purposes and don't get corrupted by thoughts of riches. Though legally, I assume the Univerity would get all the money (it was the students' work not the prof's, and done in the course of teaching while using University equipment and facilities).

    Better to just take the software and put it on the net for free (which is how the web got started).

    There are also too many people like that Apple sales rep - baffled and confused when they see people not trying to make money off of their software.

  • (cs)

    Rather OT, but a few benchmarks for those whose experience in fortran comes from DOS-based interpreters or mythology:

    http://forum.doom9.org/showthread.php?p=887714#post887714

    Not that I disagree that converting to a language more than 1% of the world's programmers are conversant in is a good idea. But even though standards have lagged behind, modern fortran is not as horrible as the perverse language than bred the original BASIC.

  • anon (unregistered) in reply to darin

    Or perhaps the lesson should have been, if you're a programming professor, don't hire bad programmers to help you sell your program. Hire a marketing team.

  • Aoun Somny (unregistered) in reply to non-believer
    non-believer:
    A CAD program in FORTRAN with a usable GUI by someone who didn't realize it.

    I wrote and maintained a lot of FORTRAN in my day, but I don't believe this one.

    I suspect that the "FORTRAN" is part of the anonymization; if this was really for the Mac, I'm betting the language involved was actually Pascal, since Apple was pushing Pascal when the Mac first came out, and only later switched to C. (If you look through the old Toolbox API for C, circa 1995, you'll see lots of functions declared as "pascal void" or whatever, and of course the Str255 data type was all over the place. Even today, a lot of programmers subconsciously assume that a piece of text will never exceed 255 characters, so you get things like dialog box layouts that chop off text after three lines, etc.) A lot of schools which used Macs had Pascal long after everyone else abandoned it. When Apple stopped producing a Pascal version of the Toolbox headers, there was a cry of anguish, almost exclusively from academia.

    Yet another reason Mac users should be glad for Mac OS X. Of course, now we have other built-in assumptions to make up for the lack of Pascal-ness...

  • Mike (unregistered) in reply to Abscissa
    Abscissa:
    I can understand them wanting to port it to C++: They want to avoid having to deal with maintaining and updating a program written in an antiquated language.

    The right tool for the right job.

    There are still many mathematics intensive programs out there who profit from the speed that Fortran compilers gives them. And why change a winning team? You will still need to train your C++ Programmers some Fortran so they can read the code, why not train them to maintain the code in Fortan?

    Captcha: Zork, as in the good ol' times

  • (cs) in reply to Aoun Somny

    In the author's place I would have anonymized it as Dylan and Java. :)

    Of course, since the software is from academia and this is probably in the late 80's/early 90's, Dylan isn't totally out of the question...

  • The cow says.... (unregistered) in reply to quamaretto
    quamaretto:
    Yes, managers everywhere really are stupid enough to do a C++ to Fortran conversion without any consideration.

    It's not really a rare thing for a project manager to be blind to consequences in order to switch to the tools they prefer.

    Sure...

    It's the project manager who decided that it had to be ported to the language de jour because software always always always has to be written in the coolest available language. Developers never decide that it is better to "upgrade" the system rather than sullying their minds with some supposedly antiquated language like FORTRAN (or COBOL or C or whatever they think only dinosaurs would use).

    Yeah, it had to be management making that call.

  • Rowland (unregistered)

    Shame the URL breaks the RSS feed...

Leave a comment on “It's CAD-tastic!”

Log In or post as a guest

Replying to comment #:

« Return to Article