• ed (unregistered)

    What do those variables fire?

    10mm explosive tipped caseless hex codes. Standard light armour piercing round. Why?

    Well do you see where your primary keys are? They're right under the primary heat exchangers.

  • (cs)

    In his late nineties, Eric started on his journey from being an engineer to being a programmer.

  • Hired Gun (unregistered) in reply to Adam
    Adam:
    The way I see it: C is the truck, VB is the motorcycle, scientific programming is the boat.

    And where did "scientific programming" get defined as "The boat?"

    Getting back to the requirements, and not just the prejudices: Where did VB get invalidated? What task was not achievable in VB.

    You have to evaluate the requirements (both current and anticipated) of the task against the language you are developing in. Anything other than that objective comparison is just prejudice.

    Admitting my prejudice, I'd probably have started in C++ on this project, but not necessarily. Today, I'd probably use C#. C++ is still a more efficient and productive choice, but the talent pool is deeper with C#, and there's nothing in a cursory glance that would invalidate C#, so that would be my choice.

    Sorry, but that's how it is.

  • Alt (unregistered)

    Engineers are a dangerous breed. Keep them the hell away from computers. I say this as a former engineer.

    I remember once back in school when a professor in an engineering course decided to give his students some code as an example. It was one long function written in MatLab that consisted of exactly 3 variables: n, m, nn. He used this code to perform several complicated stress calculations and constantly redefined each variable every 10 lines or so. No comments, no line spacing. It wasn't even working on the same calculation the whole time. It was actually doing 5 separate things in order but just looking at the code you would never have thought that. And this was given to students to show them 1. how to do these calculations and 2. to write their code for a project.

  • none (unregistered) in reply to Hired Gun
    Hired Gun:
    Anonymous:
    Using VB for scientific computing is like hiring a 3rd grader as a research assistant.

    Oh, come on. Do you REALLY think that the language an application is written in makes any difference?

    Yes. How else could you have generated that list of language selection criteria, if the language doesn't matter?

    Sure, there are multiple languages that could work, just like there are multiple libraries that could work to. Selection is certainly a design choice. However, that doesn't mean that all languages are appropriate, and honestly VB just isn't appropriate for all that much.

  • RandomUser423689 (unregistered) in reply to Hired Gun
    Hired Gun:
    Anonymous:
    Using VB for scientific computing is like hiring a 3rd grader as a research assistant.
    Oh, come on. Do you REALLY think that the language an application is written in makes any difference?

    Yes, there were a lot of things that couldn't be done in VB that were available in C, but that doesn't invalidate VB as a platform.

    ...

    Enough of this prima-donna "My language is better than yours" crap. We're supposed to be programmers, not evangelists. Anyone who knows what they're doing in programming should be able to function in anything from Q-BASIC to assembly, if given time to learn the syntax.

    I don't see where Anonymous ruled out VB as a platform. He merely points out the VB (6.0 and lower) is beyond sub-optimal for heavy number crunching. It has it's place; tight, non-UI loops is not it.

    You may be able to "meet the requirements" as long as they are loose enough, but it is likely the users will be happier with a faster and more responsive system than would be possible in VB. (If you're not a regular reader/commenter, please bear in mind that I am usually on the defending team for VB.)

  • (cs) in reply to Hired Gun
    Hired Gun:
    Yes, there were a lot of things that couldn't be done in VB that were available in C, but that doesn't invalidate VB as a platform. My motorcycle can't pull my boat, but my truck can. That doesn't invalidate my motorcycle as a method of transportation, does it?
    Great analogy. Using VB for heavy lifting makes it likely that you will spin your wheels, fail to achieve traction, and never come close to actually launching anything. However if you just want a vehicle for transporting Visual Basic code, then yeah, it's suitable.

    Seriously? I mean it's possible to write Mathematica in assembly, sure, as long as you want to pay top programmers lots of money for a very long time to do it. But that would be silly, because you could instead code the whole thing in transistors that cover the entire surface of the moon just to prove that it can be done. And if you realize halfway through that the people you've hired are not actually capable of remembering the layout of all 8e20 connections on the circuit board, and have consumed the entire remaining fossil fuel supply of both planetary bodies travelling from node to node, then you can just head go a bit further out into space and hire some aliens who can get the job done.

  • Slicerwizard (unregistered) in reply to Hired Gun
    Hired Gun:
    What task was not achievable in VB.
    Is that a question.
  • (cs) in reply to Adam
    Adam:
    Hired Gun:

    My motorcycle can't pull my boat, but my truck can. That doesn't invalidate my motorcycle as a method of transportation, does it?

    It invalidates your motorcycle from effectively pulling the boat, but you can still try.

    The way I see it: C is the truck, VB is the motorcycle, scientific programming is the boat.

    My motorcycle has more horsepower than a V-8 Dodge RAM 1500. It also has enough traction to wheelie in the rain. Does this mean VB can do scientific programming well?

  • (cs) in reply to zidar
    zidar:
    Yaos:
    The engineers were just making the program memory efficient, back in those days memory was expensive. Why take up memory for a background color and a variable when you can use both to do the same thing?
    Yea, just think of how much memory would be saved if all variables were saved like that. Each var being one pixel, and the color would be its value.

    That would make for some really pretty programs and easy debugging!

    The real benefit is in speed: you can harness the power of the graphics processor to manage all those memory accesses.

  • (cs) in reply to Jaime
    Jaime:
    My motorcycle has more horsepower than a V-8 Dodge RAM 1500. It also has enough traction to wheelie in the rain. Does this mean VB can do scientific programming well?

    I think that means that you should never ride your motorcycle in the rain. Also be awarded the overcompensation award in the Crotchrocket category.

  • Anonymous (unregistered) in reply to SenTree
    SenTree:
    Anonymous:
    Er, right... I'm in safety critical so I'm rigorously certified in... well... you know what, I write flight control systems and I have absolutely no certifications of any kind. Sure I have a CS degree but that's pretty much all theory - I certainly don't have any certifications to prove that I can actually put it into practice. Anyway, enjoy your next plane journey.
    DO-178B or equivalent ? If not, name of company so I can never set foot on their aircraft !

    [Edit] Hah! Just noticed the previous comment which beat me to it.

    Don't worry, the company I work for is DO-178B certified. But that's the company - personally, I'm not certified in anything.

  • iToad (unregistered)

    Speaking from long bitter experience, a lot of technical types believe that any monkey can write software.

    The result is software that looks like it was written by monkeys.

  • fw (unregistered) in reply to Anonymous
    Anonymous:
    Not really a WTF. Screwing up is not inherently a WTF, it would only become one if management forced them to use the new system or poured extra resources into trying to fix it. Instead they took the pragmatic route, dumped the prototype and figured out a workable solution using the software they already had. Sounds like reasonable management to me, not really a WTF.

    VB though, WTF?

    and the background colours?!

  • fw (unregistered) in reply to java.lang.Chris;
    java.lang.Chris;:
    Broken Sarcasm Detector:
    Buddy:
    When I saw the specs, I immediately thought to write an interface to access the application remotely. Glad to see they (eventually) came to the same conclusion. Hope they hide those HP-UX boxes somewhere safe and secure with a good UPS. Everyone's happy.

    Let's have a vote:

    Who else endorses this solution?

    Me. They could have still done something "enterprisey" without creating a total WTF, by adding an RPC layer on top of the old application, and having a lightweight front end communicating with it from the engineers' desktop machines.

    erm... so actually you don't endorse it?

  • You Nicks (unregistered)
    one had to go to the "UNIX Room" where a handful of aging HP-UX stations were set up for the engineers to share...and there was always a waiting list of engineers queued up
    That doesn't sound quite right. Unix was gracefully handling large numbers of concurrent remote users back when MS was still over-promising and under-delivering with a half-baked CP/M clone. Oh, and you didn't need 2GB of RAM to successfully log in, either.

    But I have faith -- MS will get around to properly supporting multiple users any decade now...

  • Jer (unregistered) in reply to Jumble
    Jumble:
    Background colors! FTW!

    FTFY

  • Xenon Xavior (unregistered) in reply to Jim

    I thought the original reason to port to Windows was so that all the engineers could run their own copy of the software...

  • Jay (unregistered) in reply to JamesQMurphy
    JamesQMurphy:
    One example of something we had to fix: At times, the software needed a Yes or No answer from the user. Rather than put up a MessageBox with Yes and No buttons, they put up an input box and required the user to type either a Y or an N. In capitals. And anything else crashed the program.

    Ah, I see the problem. It should have accepted "Y", "N", or "FILE NOT FOUND".

  • Goo Eeek (unregistered) in reply to Remy Porter
    Remy Porter:
    I presume the legacy application is written in C, so the "right" answer would have been to just take the C code and recompile it for Windows
    But you don't understand! That wouldn't give us the dancing cartoons and bright candy colors. Dammit who cares about 3.334 vs. 3.335 that's just nerd stuff but I need my gee whiz bells and whistles!
  • Anon (unregistered) in reply to OldCoder
    OldCoder:
    Remy Porter:
    Given the constraints of budget and schedule, it's a serviceable solution.

    I presume the legacy application is written in C, so the "right" answer would have been to just take the C code and recompile it for Windows, which probably wouldn't have required all that much modification. Less work than coding a new one from scratch in VB.

    Even if it weren't in C, so long as it wasn't written in Assembly, it probably could have been ported with less effort than writing a VB version.

    These people are engineers. The legacy system was almost certainly written in Fortran.

    Right, because it's impossible to find a Fortran compiler for windows.

  • Ralph (unregistered) in reply to java.lang.Chris;
    java.lang.Chris;:
    hiring extremely bright people with experience in disciplines that only occasionally touched on programming.
    Sounds like a couple places I used to work.

    1. Most of the "developers" strutted around proud of their manufacturing industry certification. Problem is, we weren't manufacturing software, we were coding software for manufacturing clients. And nobody knew diddly about proper coding disciplines.

    2. Vice President of somethingorother at a publicly-traded retailer knew retail, but routinely hacked "fixes" into running production code while the complaining user stood by and watched -- never mind that if you screw up a decimal place in your warehouse program you'll get 40 semitruckloads of product instead of 4 -- and have to pay for them.

  • (cs) in reply to Ike
    Ike:
    Homer:
    Back in the 90's, you didn't need to study computer science to write code. These were simpler and hopeful times where you could raise millions of dollars in investment capital just by prepending an ancient idea with the letter e. Code didn't need to be regression tested, or even show that it could perform its intended task in any way.

    The culmination of this philosophy, of course, came with Windows ME.

    Thank goodness those days are over. Now, of course, only those who have passed a rigorous certification process are allowed to write code. The end result? Windows Vista.

    That's an ironic example, because the vast majority of Vista compatibility issues were due to the use of "pending deprecation" practices in XP products. That is, the one thing that rigorous certification should actually have prevented.

  • Bay Sick (unregistered) in reply to Hired Gun
    Hired Gun:
    Yes, there were a lot of things that couldn't be done in VB that were available in C, but that doesn't invalidate VB as a platform. My motorcycle can't pull my boat, but my truck can. That doesn't invalidate my motorcycle as a method of transportation, does it?
    OK but a unicycle is pretty much only useful for clowns.
  • Anonymous (unregistered) in reply to Bay Sick
    Bay Sick:
    Hired Gun:
    Yes, there were a lot of things that couldn't be done in VB that were available in C, but that doesn't invalidate VB as a platform. My motorcycle can't pull my boat, but my truck can. That doesn't invalidate my motorcycle as a method of transportation, does it?
    OK but a unicycle is pretty much only useful for clowns.
    Awesome comeback my friend, plain awesome.
  • Calli Arcale (unregistered) in reply to Anon
    Anon:
    Right, because it's impossible to find a Fortran compiler for windows.

    I'd be more worried about timing issues and dependencies in the code. Never mind the language; we're talking about modeling software, and that's usually resource hungry. And that in turn means it's probably dependent on quirks of the underlying system. The porting effort would be more than just recompiling; you'd have to hunt down those kludges and hacks and replace them with Windows equivalents (or, better yet, generic solutions).

    Still should've taken less time and effort than what the "senior engineers" attempted, and been far more successful. WTF indeed.

  • Anonymouse (unregistered) in reply to Remy Porter
    Remy Porter:
    I presume the legacy application is written in C, so the "right" answer would have been to just take the C code and recompile it for Windows, which probably wouldn't have required all that much modification. Less work than coding a new one from scratch in VB.

    You may be surprised.

    The actual algorithms would likely be easy to move. I/O, especially terminal based, would have been a royal pain. Many unix systems had a curses library, but nothing was terribly standardized then. There is also the availability of certain libraries (eg, linpack and lapack).

    Nowadays, porting is mostly a non-issue. The timeframe of the article was from when there were still big differences between SysV and BSD derivities, pre-ANSI C compilers were still around, and having the GNU toolshain wasn't a given.

  • Rodger Combs (unregistered) in reply to ipeet

    The image is the Mac OSX Terminal icon.

  • (cs) in reply to Anonymouse
    Anonymouse:

    The actual algorithms would likely be easy to move.

    Nowadays, porting is mostly a non-issue. The timeframe of the article was from when there were still big differences between SysV and BSD derivities, pre-ANSI C compilers were still around, and having the GNU toolshain wasn't a given.

    I was more thinking of the algorithms. Also, I was doing ANSI-C in the late 90s, and so that just colors my view of the era. And it was on a SysV, now that I think about it. Although I did port some code to VMS, which, well, that was fun.

  • An Onymous (unregistered)

    ... but what happened to Eric?

  • (cs) in reply to zidar
    zidar:
    Yea, just think of how much memory would be saved if all variables were saved like that. Each var being one pixel, and the color would be its value.

    That would make for some really pretty programs and easy debugging!

    You think you jest?

    I point you at the famous game Elite from the mid-80s. On the original BBC-B micro version - where it had about 14 KB of available normal RAM - some of the data was stored on the screen instead, as coloured pixels. However, this wasn't obvious because the code did a palette switch just before the relevant scan lines were displayed, turning all colours black, and reverted the palette immediately afterwards.

    (It also did a screen graphics mode change at that point as well, going from a 2-colour high-def mode to a 4-colour low-def mode. It was possibly quite the most impressive hack I've ever seen, and it worked remarkably well.)

  • Someone like Kevin (unregistered) in reply to Hired Gun
    Hired Gun:
    If you can't think critically and solve problems, then you can't program. If you can solve problems, then the language doesn't mean squat as long as you learn it.
    +1
  • Andrew Baker (unregistered)

    *Cries, I'm in the middle this right now.

  • Anonymous (unregistered) in reply to Hired Gun
    Hired Gun:
    Where did VB get invalidated? What task was not achievable in VB.

    It's right there in the article. VB has problems with basic rounding.

  • JP (unregistered) in reply to Hired Gun
    Hired Gun:
    C++ is still a more efficient and productive choice, but the talent pool is deeper with C#, and there's nothing in a cursory glance that would invalidate C#, so that would be my choice. Sorry, but that's how it is.

    There's also a corollary to this theory. If you select a platform based on number of developers available on that platform, then you'll attract any goofball who calls himself a programmer and has seen that language. With C# this isn't as much of an issue... but if you select VB based on the fact that the developer pool is deep, you'll get 100x more resumes - and it will be that much more difficult to sort out the idiots and incompetents from the experts. This is doubly-so because the experts tend to self-select away from VB.

    For an example of this, see "Django + Python + PostgreSQL" vs. "Any Framework + PHP + MySQL". Those who are smart enough to choose the more elegant solution generally produce better products (i.e. the distribution favors experts over idiots), whereas those who just goes with "the next big thing + PHP + MySQL" have an equal distribution between idiots and experts.

    There's a reason many of us who work with legacy code in VB won't put it on our resumes - because without fail, EVERY VB project we've been put on is an unbridled mess. No reason to attract more mess - there is no such thing as elegant VB code.

  • fnord (unregistered) in reply to Homer
    Homer:
    Back in the 90's, you didn't need to study computer science to write code. These were simpler and hopeful times where you could raise millions of dollars in investment capital just by prepending an ancient idea with the letter e. Code didn't need to be regression tested, or even show that it could perform its intended task in any way.

    The culmination of this philosophy, of course, came with Windows ME.

    Which got it so backwards that they put the 'e' at the end of the name, instead of the front.

  • Gorbeh (unregistered) in reply to KittyKat
    KittyKat:
    So are they going to next embed an emulator of the actual machine to run the program?
    Grab Cygwin and deploy.
  • Quirkafleeg (unregistered) in reply to Bellinghman
    Bellinghman:
    zidar:
    Yea, just think of how much memory would be saved if all variables were saved like that. Each var being one pixel, and the color would be its value.

    That would make for some really pretty programs and easy debugging!

    You think you jest?

    I point you at the famous game Elite from the mid-80s. On the original BBC-B micro version - where it had about 14 KB of available normal RAM

    19KB (disk) or 21¾KB (tape), in both cases taking into account 256 bytes for user-defined graphics, 1KB of language ROM workspace and 2KB freed by reducing the display mode width.

    Plus part of zero page, plus…

    - some of the data was stored on the screen instead, as coloured pixels. However, this wasn't obvious because the code did a palette switch just before the relevant scan lines were displayed, turning all colours black, and reverted the palette immediately afterwards.

    (It also did a screen graphics mode change at that point as well, going from a 2-colour high-def mode to a 4-colour low-def mode. It was possibly quite the most impressive hack I've ever seen, and it worked remarkably well.)

    Ah yes, the 6845…

  • Paula (unregistered)

    1.) Change desktop background color. 2.) ????? 3.) Profit!

  • Fedaykin (unregistered)

    The real WTF here is VB, and I say that not only becuase it's a toy language, but because it's not a language appropriate for scientific calculation.

  • JP (unregistered) in reply to Someone like Kevin
    Someone like Kevin:
    Hired Gun:
    If you can't think critically and solve problems, then you can't program. If you can solve problems, then the language doesn't mean squat as long as you learn it.
    +1
    Factually, you are correct. But here's how I think of it.

    Some people get to work in a florist shop around sweet-smelling flowers all day. Other people have to work in a sewage treatment plant and deal with shit all day. It's the same basic idea - working with organic matter - but one is much better on the senses than the other.

  • Lego (unregistered) in reply to Bay Sick
    Bay Sick:
    Hired Gun:
    Yes, there were a lot of things that couldn't be done in VB that were available in C, but that doesn't invalidate VB as a platform. My motorcycle can't pull my boat, but my truck can. That doesn't invalidate my motorcycle as a method of transportation, does it?
    OK but a unicycle is pretty much only useful for clowns.

    You win. Awesome comment!

  • coyo (unregistered) in reply to Bub

    One thing that was left out in the story is that the database stored a single row. Due to the corruption, the database had a backup copy.

    This gave the impressive tally of two databases/row.

  • coyo (unregistered) in reply to An Onymous

    I'm getting better! I think I'll go for a walk.

  • RandomUser423689 (unregistered) in reply to Anonymous
    Anonymous:
    Hired Gun:
    Where did VB get invalidated? What task was not achievable in VB.
    It's right there in the article. VB has problems with basic rounding.
    I'm pretty sure the rounding issues discussed in the article were related to the users on the legacy version.

    Also, VB doesn't have problems with basic rounding. Programmers who ignore the well-documented "round-even" rounding behavior of VB, and blindly expect "round-larger" or "truncate", have problems with basic rounding.

    If you can believe Wikipedia, "round-even" is commonly used in bookkeeping, which is... (wait for it)... one of the environments they had in mind when creating VB.

  • Massive Debt (unregistered) in reply to Broken Sarcasm Detector
    Broken Sarcasm Detector:
    Buddy:
    When I saw the specs, I immediately thought to write an interface to access the application remotely. Glad to see they (eventually) came to the same conclusion. Hope they hide those HP-UX boxes somewhere safe and secure with a good UPS. Everyone's happy.

    Let's have a vote:

    Who else endorses this solution?

    HP-UX is a Unix dialect. It's easy to upgrade the hardware using a newer Unix OS.

    This is an engineering program, probably written in C or Fortran. Most ANSI Standard languages like C & Fortran can be ported to other Unix OSes, quickly, including Linux.

    It would have been far easier to upgrade the hardware & Unix OS than to re-write the code for Windows. Then, it could support any increased use over terminals.

    So, yes, I endorse this solution.

  • (cs) in reply to RandomUser423689
    RandomUser423689:
    Anonymous:
    Hired Gun:
    Where did VB get invalidated? What task was not achievable in VB.
    It's right there in the article. VB has problems with basic rounding.
    I'm pretty sure the rounding issues discussed in the article were related to the users on the legacy version.

    Also, VB doesn't have problems with basic rounding. Programmers who ignore the well-documented "round-even" rounding behavior of VB, and blindly expect "round-larger" or "truncate", have problems with basic rounding.

    If you can believe Wikipedia, "round-even" is commonly used in bookkeeping, which is... (wait for it)... one of the environments they had in mind when creating VB.

    Yup. Also, in VB.Net you use the following line of code to round:

    x = Math.Round(12.5)

    It rounds to the nearest even whole number. In C#, the equivalent code is:

    x = Math.Round(12.5);

    It also rounds to the nearest even number. If you want to round to up, use:

    x = Math.Round(12.5, MidpointRounding.AwayFromZero)

    Of course, in C#:

    x = Math.Round(12.5, MidpointRounding.AwayFromZero);

    I fail to see any eveidence that VB is a toy language because it doesn't round properly and C# is a professional language because it rounds properly.

  • coyo (unregistered) in reply to Jaime

    DIM X as variant DIM Y as variant X = true; Y = true; if( val(X) = val(Y) ) THEN MSGBOX("Visual Basic is AWSOME") END

  • coyo (unregistered) in reply to coyo

    WTF?

    DIM X as variant DIM Y as variant X = true; Y = false; if( val(X) = val(Y) ) THEN MSGBOX("Visual Basic is AWSOME") END

    (should quit while I'm ahead)

  • (cs) in reply to RandomUser423689
    RandomUser423689:
    Anonymous:
    Hired Gun:
    Where did VB get invalidated? What task was not achievable in VB.
    It's right there in the article. VB has problems with basic rounding.
    I'm pretty sure the rounding issues discussed in the article were related to the users on the legacy version.

    Also, VB doesn't have problems with basic rounding. Programmers who ignore the well-documented "round-even" rounding behavior of VB, and blindly expect "round-larger" or "truncate", have problems with basic rounding.

    If you can believe Wikipedia, "round-even" is commonly used in bookkeeping, which is... (wait for it)... one of the environments they had in mind when creating VB.

    BTW, "round-even" is used to eliminate the aggregate effects of consistently rounding 5 up. With "round-even", half of your 5s will round up and half will round down. This method also has the advantage of being determinate. Altenatives are "alternate rounding", where each 5 does the opposite of what the previous one did and "random rounding", which has obvious problems.

    To add to my previous comment, Math.Round behaves properly for financial environments, but doesn't behave properly for display purposes. Fortunately, you aren't supposed to use Math.Round for display, you are supposed to use:

    String.Format("0:0", 12.5)

    This rounds to 13 as you would expect. This behavior is also consistent between C# and VB.Net.

Leave a comment on “A Terminal Condition”

Log In or post as a guest

Replying to comment #:

Log Out

« Return to Article