• Ross (unregistered) in reply to Spivonious

    Your kidding right?

  • Grammar nazi (unregistered) in reply to Ross
    Ross:
    Your kidding right?

    No, actually, that was my kidding.

  • me_again (unregistered) in reply to The_Assimilator
    The_Assimilator:
    Buddy:
    SetPriorityClass(GetCurrentProcessId(), BELOW_NORMAL_PRIORITY_CLASS);

    or like this in multi-threaded apps:

    SetThreadPriority(GetCurrentThreadId(), THREAD_PRIORITY_BELOW_NORMAL);

    This kind of thing you'll never see in a .NET or Java application. Just not part of the mindset.

    Since I have used the below code numerous times in .NET apps, I think you should shut the fuck up about things you obviously know nothing about.

    Process.GetCurrentProcess().PriorityClass = PriorityClass.BelowNormal;

    Thread.CurrentThread.Priority = ThreadPriority.BelowNormal;

    Addendum (2009-12-31 06:21): Also, you fail at trolling.

    +1 for the win

  • PinkFloyd43 (unregistered) in reply to you're-not-getting-it

    I seen your real programming code and it's typically about 500 lines of code to get the date! Great job! But wait, you chose to verify the date by making calls to external atomic clocks around the world adding another 1000 lines and taking into consideration latency, which is still another 1000 lines, on and on!

  • (cs) in reply to 50% Opacity
    50% Opacity:
    tgape:
    I believe Mason's point was that the resulting compiled program runs directly, through an abstraction layer.

    Erm… Maybe you wanted to say one abstraction layer (instead of several)?

    No, I meant to say 'rather than through an abstraction layer'. Of course, if the processor uses microcode to implement the machine language it normally handles, then it's through one abstraction layer - and that's kind of a WTF (IMHO, if you're going to make a smaller, faster machine language, why not have the compilers cater to it directly? Yes, I know, this is generally done for purposes such as x86 compatibility. I still don't understand why someone wanting to compile specifically for machines running that processor shouldn't be able to compile to its real language.)

    This is what I get for posting too late and attempting to respond to an oversized response with a single response.

  • (cs) in reply to nobody
    nobody:
    Mason Wheeler:
    And now they're starting to teach Java and .NET in "programming" classes in colleges. It makes me shudder when I think of the future.
    Um. You've been where for the last 15 years? They're moving past Java already.

    Writing code. So what are they teaching now?

  • Max (unregistered)

    Yeah, the code sucks.

    But TRWTF is the consultant - his JOB was to bring these guys up to speed with a new platform and show them how to do things. But instead of doing that, he just walked.

  • (cs) in reply to 50% Opacity
    50% Opacity:
    If you're a real-time embedded systems guy, you absolutely need to know assembler. Heck, you should know your way around with an oscilloscope.

    If you're a GUI-app developer on any reasonably recent OS, you mostly don't, it's a lot more important to know your libraries in and out.

    Agreed. Especially since, as has been pointed out here, some of the real-time embedded systems guys make oscilloscopes. ;)

    50% Opacity:
    If you're a Java or .NET or PHP or whatever guy who's mostly coding business logic with a bit of output, what makes you a good programmer is rigorous discipline and clean structuring ability (+ knowing your libraries), since an internally consistent and (business-)logically bug free app is much more important than a wasted CPU cycle or two.

    Good, but not great. You probably need to know a bit more than this to be a great programmer. Of course, if I'm hiring, I'm generally not looking for a great programmer. If I find one I'll probably to hire him, if the position isn't too junior. But what I'm looking for is good programmers. (And yes, I know, in the current economy, few positions are too junior - but we've never been hiring in a down economy.)

    For what it's worth, however, I do take issue with the phrase "a wasted CPU cycle or two", given the context. If we're talking Java, C#, PHP, Perl, Python, Ruby, SmallTalk, or some similar high level language, we've firmly declared individual CPU cycles to be irrelevant. An app written in one of those languages probably will not be considered a failure if it wastes an entire CPU second - assuming that the language choice was not one of the first failures. Individual routines generally would not be considered problematic if they wasted milliseconds per app invocation.

    Note: if you want your PHP, Perl, or similar language pages to run faster than that, you use something like mod_php or mod_perl, which save the results from their initial load, which is usually the most expensive part of a small script. Then you average the performance loss across invocations, and probably find that the average is much less than a second - but the total will be well over a second for an active page, and it's not considered a problem. If the average is still over a second - it may be an issue, it may not, depending on how active the page is. For example, we have a page at work that takes, on average, about 15 seconds to load. Most of that time is "wasted cycles", as it's written in Perl, by someone who was still learning Perl when he wrote it. The page is loaded, on average, about once a day, and so probably will not be optimized any time soon. (Of course, if it suddenly becomes "mission critical" and thus much more active, that would change.)

  • Quirkafleeg (unregistered) in reply to you're-not-getting-it
    you're-not-getting-it:
    […] "Real programming" involves not being an ass-tard code monkey who actually understands how to write optimized routines […]
    Er, surely that's exactly the sort of code monkey that you want (to be). At the very least, you'd want to understand these things…
  • Quirkafleeg (unregistered) in reply to Nakke
    Nakke:
    Now what the hell was he thinking? Rewriting that code with .NET could have provided him hundreds of hours of work and thousands of dollars in cash.

    Standing up and walking away to the nearest bar was real WTF.

    Bar humbug.

  • Brian White (unregistered) in reply to ObiWayneKenobi
    ObiWayneKenobi:
    Some thoughts:
    1. Classic ASP is a wretched, wretched beast that should die a thousand deaths and be condemned to rot in the ninth level of Hell for all eternity. Even PHP is better, since while PHP can be turned into complete shit by novices, hacks and wannabes, it's at least really object oriented and you could at least use real software principles on PHP projects. With Classic ASP, it's almost like the language forces you to produce slop. Even the better Classic ASP code is still garbage due to the limitations.

    If classic asp is so horrible, why is it that the brand new ASP.Net MVC code closely resembles classic ASP code? Classic ASP is perfectly fine if you are 1) an expert application programmer, 2) an expert database developer, 3) an expert front-end html/js/css developer. ASP.Net, pre-MVC, is crap in comparison because it was developed for people who don't know and don't want to know HTML, CSS, Javascript and the like.

  • EngleBart (unregistered)

    TRWTF: He forgot the most important component of any ASP program

    <!--#include virtual=/Code/MaybeINeedingLater.asp -->
  • Brian White (unregistered)

    I don't freakin' believe it. Page 3, and not one person has yet pointed out the true WTF. TRWTF is that he is using ARRAYS instead of XML. Yes, someone suggested text files, but come on. This is the 21st century. If you are going to replace a database with a poorly implemented homegrown solution you do it with XML. Then you don't even need to know arrays. And you can implement this awesome suggestion quite easily in .Net, and you don't even need to manage the formatting all manually.

  • Ryde (unregistered) in reply to tgape
    tgape:
    Of course, if the processor uses microcode to implement the machine language it normally handles, then it's through one abstraction layer - and that's kind of a WTF (IMHO, if you're going to make a smaller, faster machine language, why not have the compilers cater to it directly? Yes, I know, this is generally done for purposes such as x86 compatibility. I still don't understand why someone wanting to compile specifically for machines running that processor shouldn't be able to compile to its real language.)
    1. Since a machine instruction maps to multiple microcode instructions, you can fetch more microcode instructions from RAM and store more in cache by working at the machine instruction abstraction level than if your programs were compiled directly to microcode.
    2. The machine instruction - microcode instruction abstraction allows you greater freedom to change the underlying CPU architecture. An Intel Core 2 Duo and Pentium 4 have different architectures, but still use the same machine instruction set.
    3. The abstraction can allow you to deploy firmware bug-fixes to work around errors in the CPU design.

    In other words, the abstraction is like any other abstraction - it has benefits and drawbacks, and was implemented to solve certain problems.

    Making broad statements about abstractions and assuming that they're there just to baby the developer is idiotic. A software developer should understand why they are put into place and whether they are appropriate to use.

    P.S. Java and .Net are actually JIT-compiled, and that compiled machine code is cached by the runtime environment. Its likely that a given Java/.Net program is running directly off of machine code. In fact, you can pre-generate the machine code for .Net using ngen. More evidence that so-called "real programmers" don't know what the fuck they're talking about.

  • (cs) in reply to AA

    @AA

    {Q} The primary audience who comments here are programmers who want to feel good about themselves because "at least I'm not that bad". {Q}

    Are you saying I shouldn't be here? Because I've looked at some of my code, and it IS just as bad as some of the WTF's I've seen posted. Sometimes worse. If I could only afford a couple billion lines of code offsets.......

  • Thomas (unregistered) in reply to Brian White
    Brian White:
    If classic asp is so horrible, why is it that the brand new ASP.Net MVC code closely resembles classic ASP code?

    It isn't that close and .NET is still a type-safe, compiled environment. Technically, you can do anything classic ASP that you can do in ASP.NET. The difference is that to do something right in classic ASP requires orders of magnitude more effort than in ASP.NET

    Brian White:
    Classic ASP is perfectly fine if you are 1) an expert application programmer, 2) an expert database developer, 3) an expert front-end html/js/css developer. ASP.Net, pre-MVC, is crap in comparison because it was developed for people who don't know and don't want to know HTML, CSS, Javascript and the like.

    Spoken by someone that is completely clueless. Standard non-MVC ASP.NET requires just as much knowledge about CSS and javascript as MVC or classic ASP (or PHP or any other web development platform).

  • (cs) in reply to Brian White
    Brian White:
    ObiWayneKenobi:
    Some thoughts:
    1. Classic ASP is a wretched, wretched beast that should die a thousand deaths and be condemned to rot in the ninth level of Hell for all eternity. Even PHP is better, since while PHP can be turned into complete shit by novices, hacks and wannabes, it's at least really object oriented and you could at least use real software principles on PHP projects. With Classic ASP, it's almost like the language forces you to produce slop. Even the better Classic ASP code is still garbage due to the limitations.

    If classic asp is so horrible, why is it that the brand new ASP.Net MVC code closely resembles classic ASP code? Classic ASP is perfectly fine if you are 1) an expert application programmer, 2) an expert database developer, 3) an expert front-end html/js/css developer. ASP.Net, pre-MVC, is crap in comparison because it was developed for people who don't know and don't want to know HTML, CSS, Javascript and the like.

    The real wtf is that we created all of these kludges to cater to attempting to write statefull applications to run in a stateless environment, rather than designing a proper environment to begin with and THEN implementing the means to develop applications to run on THAT.

    And, seriouslym I don't WANT to learn HTML, CSS, or JAVASCRIPT, and I shouldn't have to. Well, I should learn them, in order to understand the underpinnings, but I shouldn't have to manually manipulate 5 different layers of abstraction simultaneously to get a working product. Give me a good WYSIWYG GUI designer, and a good multi-language IDE. I have more important business rules to implement, and impossibly complex business processes to design around. The last thing i should have to worry about is how to make a pop-up box appear on the screen.

  • Duke of New York (unregistered) in reply to you're-not-getting-it
    you're-not-getting-it:
    "Real programming" doesn't involve stupidly bloated baby languages like VB, C#, and Java. "Real programming" involves not being an ass-tard code monkey who actually understands how to write optimized routines and can deal with the inner workings of the system without the necessity of 500000000 layers of abstraction so they don't hurt themselves on the sharp things (see what I did there).

    If you don't get the difference, you are not a real programmer.

    electrical engineer found

  • mwanaheri (unregistered) in reply to Mason Wheeler
    Mason Wheeler:
    Because of code monkeys who rely too heavily on abstractions without understanding what's really going on and how much it costs in system resources. And now they're starting to teach Java and .NET in "programming" classes in colleges. It makes me shudder when I think of the future.
    what always strikes me is the enormous role of database abstractions. It's not really hard to use a prepared statement (eg.in Java) to make a database query and use the result set to get the data. Yet, it seems so much of a horror to many programmers that even for minor stuff they use an abstraction layer and then have all the trouble with the configuration.
  • History Teacher (unregistered)

    Definitions of Real Programming:

    • Any Real Programming task needs to be done only twice: First time to do it for one piece of code, 2nd time to add it to a library. Doing it 3rd time is already Stupid Programming.

    • A piece of code that only calls lower level code is Real Programming. A piece of code that calls other code that is same or higher level of abstraction is just assembling existing pieces of code produced by earlier Real Programming.

    • Regular GUI or CLI programming is never ever real programming. Clarification: parser programming for text input used to be Real Programming, but these days it's almost certainly Stupid Programming.

    So, as time passes on, there's less and less Real Programming left to do. It all is either re-doing earlier Real Programming, and thus just Stupid Programming, or it's just "mechanically" assembling other code and therefore not Real Programming.

    It also follows, that most software has at least a tiny bit of Real Programming in it (some parts of the "business logic" code at least), and almost no modern software contains only Real Programming.

  • brad (unregistered) in reply to me_again

    Why do so many retards use the captcha phrase? It makes me want to choke on my own tongue when I read it in a comment. It makes me say wtf every time I read it. Also, for those that ask what the real wtf is... just a hint... you are the real author of the wtf. Try looking at the code for an extra 10 seconds to figure it out.

  • hoodaticus (unregistered) in reply to Medezark
    Medezark:
    @AA

    {Q} The primary audience who comments here are programmers who want to feel good about themselves because "at least I'm not that bad". {Q}

    Are you saying I shouldn't be here? Because I've looked at some of my code, and it IS just as bad as some of the WTF's I've seen posted. Sometimes worse. If I could only afford a couple billion lines of code offsets.......

    Don't be so hard on yourself. The WTFs here are truly awful. I'm sure arguments can be made on your behalf in each instance. Especially if you're a student.

    Otherwise, welcome to the learning experience! This site is a great way to learn what not to do.

  • hoodaticus (unregistered) in reply to Medezark
    Medezark:
    And, seriouslym I don't WANT to learn HTML, CSS, or JAVASCRIPT, and I shouldn't have to.

    I'm going to give you the benefit of the doubt and just hope that that is a very, very bad example. You need to know HTML and CSS and JavaScript because they are each an implementation of a concept that you need to know to be a well-rounded programmer.

    HTML covers presentation of documents in a web format. The internet is pretty darn important. For printed documents, see: XSL:FO, DocBook, LaTeX.

    CSS covers styling a document in a way that is independent of the data in the document itself. It's a holy grail of the publishing world and is a very useful tool. For more generic implementations of this concept see: XSLT, RDL (SSRS).

    JavaScript covers adding functionality to the elements in the HTML Document Object Model. Don't you want to be able to do things in a web browser other than render static pages?

    Learning these things is good for you and good for the world that you are coding in.

    CAPTCHA: (Just kidding!)

  • (cs) in reply to Buddy
    Buddy:
    Mason Wheeler:
    ...

    Why? Because of code monkeys who rely too heavily on abstractions without understanding what's really going on and how much it costs in system resources. And now they're starting to teach Java and .NET in "programming" classes in colleges. It makes me shudder when I think of the future.

    What's gets my blood boiling in Windows is when a long running background task doesn't set itself to a lower priority - e.g. Windows or Outlook search, Memeo backup, Norton scanning, etc., etc., etc. A fix can be as simple as one line, something like this in services:

    SetPriorityClass(GetCurrentProcessId(), BELOW_NORMAL_PRIORITY_CLASS); [...] By the way, when I wrote Memeo about it, they "fixed" it by setting the UI to a lower priority but kept the backup engine as-is. Now in Memeo the UI takes forever to show but the background engine still runs at full priority slowing your machine to a halt. I decided not to talk to them any more.

    This doesn't fix the problem either, if the background task is I/O bound. You need to assign I/O priorities. You also need to use batched I/O that can be sorted by the kernel to minimize the time the disks spend seeking. What's worse is popular platforms generally have spotty/inconsistent support for that. Just as you can usually expect to have full gamut of sync primitives on any decent OS these days, the I/O is still usually done the same way as it would be done on CP/M.

    You can have a windows process that takes 1% or less CPU, only a kb or two of memory (yes!) yet brings the system down to a halt. That's what you get when you use the raw NT kernel calls from an executable written in assembly, and you simply seek and read tiny chunks of data across the drive. The whole thing is maybe 300 lines long. I have to dig it up. A friend of mine showed it to me in good ole NT 4 days, and it still works!

  • (cs) in reply to hoodaticus
    hoodaticus:
    CSS covers styling a document in a way that is independent of the data in the document itself. It's a holy grail of the publishing world and is a very useful tool. For more generic implementations of this concept see: XSLT, RDL (SSRS).
    I would hardly call it the holy grail of anything, much less publishing world, unless by publishing you only mean online publishing. CSS is a hack. It's something we all have to put up with, but it is full of ommissions and short-sightedness. Just what you'd expect from a consortium-based process.

    Paper-based publishing has been long running just fine on postscript and PDF as the portable intermediate form. Whatever higher level is used to be filtered down to postscript, it's not HTML + CSS, unless you use your own code to do the processing, essentially creating your own "quirks" mode on top of HTML+CSS.

    Heck, I can't think of a webpage that couldn't be rewritten in display postscript while becoming more readable, more maintainable, and better looking. That's one heck of a lot to be said for an obsolete technology that's full two decades old now. Oh, and you could get rid of all of javascript and flash at the same time.

    Soon after the Berlin wall fell, an acquaintance of mine had managed to get a NeXTStation into Poland -- with all available development tools, full documentation, etc. Quite a feat back then, but then it was a guy who always had quite a few goodies in spite of COCOM embargo etc in the 80s.

    It was quite mind boggling what it could do back in the day. He learned a lot of the APIs quite well. I remember him showing me some of the demos he wrote. It was a good few years later that similar functionality was somewhat provided by Flash. Never mind that DPS was trivial to reimage for the printer, and both outputs looked quite darn good.

  • Bim Job (unregistered) in reply to Kuba
    Kuba:
    hoodaticus:
    CSS covers styling a document in a way that is independent of the data in the document itself. It's a holy grail of the publishing world and is a very useful tool. For more generic implementations of this concept see: XSLT, RDL (SSRS).
    I would hardly call it the holy grail of anything, much less publishing world, unless by publishing you only mean online publishing. CSS is a hack. It's something we all have to put up with, but it is full of ommissions and short-sightedness. Just what you'd expect from a consortium-based process.

    Paper-based publishing has been long running just fine on postscript and PDF as the portable intermediate form. Whatever higher level is used to be filtered down to postscript, it's not HTML + CSS, unless you use your own code to do the processing, essentially creating your own "quirks" mode on top of HTML+CSS.

    Heck, I can't think of a webpage that couldn't be rewritten in display postscript while becoming more readable, more maintainable, and better looking. That's one heck of a lot to be said for an obsolete technology that's full two decades old now. Oh, and you could get rid of all of javascript and flash at the same time.

    Soon after the Berlin wall fell, an acquaintance of mine had managed to get a NeXTStation into Poland -- with all available development tools, full documentation, etc. Quite a feat back then, but then it was a guy who always had quite a few goodies in spite of COCOM embargo etc in the 80s.

    It was quite mind boggling what it could do back in the day. He learned a lot of the APIs quite well. I remember him showing me some of the demos he wrote. It was a good few years later that similar functionality was somewhat provided by Flash. Never mind that DPS was trivial to reimage for the printer, and both outputs looked quite darn good.

    Pop quiz:

    Would you rather work with CSS or PDF?

    Worse is Better, so there's a sea of idiots who think that CSS is somehow "superior." (I've worked with it. Nice rounded edges to the table. Well worth two hours of my time, and yet unaccountably instable.)

    I think it comes down to the fact that CSS is embedded into InterTubes standards, and PDF is not. To be fair, CSS is a sticking-plaster. HTML was never meant to be the basis for a shop front, and CSS does its feeble and unplanned little best to shove something up on the screen that looks like a shop front.

  • Roy T. (unregistered) in reply to you're-not-getting-it
    you're-not-getting-it:
    web-programmer:
    So the definition of "real programming" is something that doesn't use HTTP/HTML/JS as a front end?

    I thought one of the selling points of .net was that you could build a single set of libraries and expose them to various different front-ends, so does that mean if I build a library and create a windows forms or CLI front-end I'm doing "real programming" and if I create a web based front-end to the same thing then I'm not?

    I don't quite understand how building a front-end using web technologies (and dealing with cross browser problems , latency issues etc) is somehow magically easier than building a GUI for windows or Java Swing (both of which have graphical drag and drop editors).

    Surely the reason that there is more "web programming" is because in most cases having a web application is just more useful in this day and age as it then becomes trivial to make the application accesible to large numbers of people accross the globe using different computing platforms.

    Think google, basecamp , facebook , hotmail etc would you say that the people who built these don't know how to do "real programming"?

    "Real programming" doesn't involve stupidly bloated baby languages like VB, C#, and Java. "Real programming" involves not being an ass-tard code monkey who actually understands how to write optimized routines and can deal with the inner workings of the system without the necessity of 500000000 layers of abstraction so they don't hurt themselves on the sharp things (see what I did there).

    If you don't get the difference, you are not a real programmer.

    I guess you are either brilliant or not a programmer. Real programming is thinking of efficient algorithms and being able to implement them in the language that fits the problem.

    You'd be an idiot if your simple database front end is made in C(++) which gives you extra performance but has a higher bug per line ratio and is more expensive to develop (C++ developers are more expensive, and it takes more time to write the same code). In such a case JAVA and the .NET language are more valid approaches, you can create an application in no time, have fewer bugs and you don't need super performance if all the computer has to do is show a simple form and do "UPDATE..." once in a while.

    Of course C++ is sometimes the answer, but so are JAVA and the .Net languages (and all other programming languages).

  • s.mart (unregistered) in reply to Anonymous

    2009-12-30 10:37 • by Anonymous I think it's clever.

    I think you aren't.

  • illtiz (unregistered) in reply to Man behind the scenes
    Man behind the scenes:
    you're-not-getting-it:

    "Real programming" doesn't involve stupidly bloated baby languages like VB, C#, and Java. "Real programming" involves not being an ass-tard code monkey who actually understands how to write optimized routines and can deal with the inner workings of the system without the necessity of 500000000 layers of abstraction so they don't hurt themselves on the sharp things (see what I did there).

    If you don't get the difference, you are not a real programmer.

    Call me a cynic, but I'm not inclined to believe that this guy is some open-toed-sandal wearing, assembler-coding dinosaur. Isn't it more likely that he's someone who's wetting himself laughing right now at how many of you fell for the wind-up...

    Come on now, surely these kind of people became extinct in the profession long ago (Please God, let it be so...)

    TRWTF is so many people taking that comment at face value. Original poster apparently aced his sarcasm check.

  • Highly Paid Consultant (unregistered)

    What a load of rubbish all these arguments are. The real WTF is in the story.... How NOT to develop a system that requires persisted and editable data... Muppets!

  • schultz (unregistered) in reply to you're-not-getting-it
    you're-not-getting-it:

    "Real programming" doesn't involve stupidly bloated baby languages like VB, C#, and Java. "Real programming" involves not being an ass-tard code monkey who actually understands how to write optimized routines and can deal with the inner workings of the system without the necessity of 500000000 layers of abstraction so they don't hurt themselves on the sharp things (see what I did there).

    If you don't get the difference, you are not a real programmer.

    I don't know what you talking about... REAL Programmers use Punch Cards.... :)

  • Rabiator (unregistered) in reply to Man behind the scenes
    Man behind the scenes:
    you're-not-getting-it:

    "Real programming" doesn't involve stupidly bloated baby languages like VB, C#, and Java. "Real programming" involves not being an ass-tard code monkey who actually understands how to write optimized routines and can deal with the inner workings of the system without the necessity of 500000000 layers of abstraction so they don't hurt themselves on the sharp things (see what I did there).

    If you don't get the difference, you are not a real programmer.

    Call me a cynic, but I'm not inclined to believe that this guy is some open-toed-sandal wearing, assembler-coding dinosaur. Isn't it more likely that he's someone who's wetting himself laughing right now at how many of you fell for the wind-up...

    Come on now, surely these kind of people became extinct in the profession long ago (Please God, let it be so...)

    Yes, some people here have seriously broken irony detectors.

    I don't call myself a social genius by any stretch of the imagination, but it was still obvious that "you're-not-getting-it" was making fun of "real programmers" ;-)

  • oheso (unregistered) in reply to Zylon
    Zylon:
    Holy mother of god you idiots are easy to troll.

    QFT

  • pm100 (unregistered)

    THis solution seems fine to me.

    Its a lookup table, and the fact that its generated automatically is good

    I bet it performs better that a whole bunch of SQL

  • Nick (unregistered) in reply to ih8u

    A keyboard for REAL programmers:

    http://www.geeks3d.com/public/jegx/200808/keyboard-for-real-coder-big.jpg

  • quisling (unregistered) in reply to ObiWayneKenobi
    ObiWayneKenobi:
    Some thoughts:
    1. At least he used a directory structure to somewhat componentize the classes.

    2. Should have used a Dictionary or something to make it easier to read e.g. STORRAY_Products(1,"Name") = "Black & Decker"

    3. Classic ASP is a wretched, wretched beast that should die a thousand deaths and be condemned to rot in the ninth level of Hell for all eternity. Even PHP is better, since while PHP can be turned into complete shit by novices, hacks and wannabes, it's at least really object oriented and you could at least use real software principles on PHP projects. With Classic ASP, it's almost like the language forces you to produce slop. Even the better Classic ASP code is still garbage due to the limitations.

    4. The "brain" was obviously an intelligent person, but a total nimrod when it comes to the real way to do things. Seriously, why do none of the people in these stories take a moment after thinking up these brillant ideas and ask themselves "Is there a better way?" instead of just plodding along? I guarantee this person was smart and just too lazy to learn "that newfangled SQL/ADO stuff"

    @3: Well, sort of. Classic ASP -- or ASP.old, as it's properly called -- could also be written in JScript (with proper error handling!). Which means you could choose to write object-oriented or procedural or functional code, or a mix of all, depending on your needs. Oh, and as a result of that, you could also apply any manner of "real software principles". But, hey, whatever, you're not the first (what's that douche up the stack calling us again?) "ass-tard code monkey" to miss that nuance. ;}

    @1,2,4: damn straight! sing it from the mountain!

  • Anonymous (unregistered)

    "Web programmer"... ha ha ha! That oxymoron will never get old!

  • Reflective (unregistered)

    WTF, nobody suggested reflection?

  • Hugo Garcia (unregistered) in reply to ih8u

    48692c207265616c2070726f6772616d65727320646f6e7420757365206173636920636861726163746572732c20746865792075736520484558

  • Anon (unregistered)

    Cool Storray, bro.

  • ... (unregistered) in reply to Scott Simmons
    Scott Simmons:
    "At the requirements meeting, the brain behind the engine gave a quick summary: it's like having the benefit of a database without ever having to use SQL, ADO, or any of that stuff; just simple arrays. Then they dove into the code." The point at which Steve should have headed to the bar for a stiff drink or two, was between sentence one and sentence two above. It's foolish to even glance at code that someone who would make the first claim is proud of, other than through a heavy alcohol-induced haze.

    I once build something that would fit this explanation....

    Don't worry. It was a wrapper around SQL, you'd access it like this:

    SQLarray acc(<conninfo>);;
    ...
    acc[0]["column"] = newval;
    

    This assigns newval to column column in row 0. It's SQL with the simplicity of arrays. It's easy and fast.

    Captcha: haero ; Something the storrayengine is not.

Leave a comment on “Classic WTF: The Storray Engine”

Log In or post as a guest

Replying to comment #:

« Return to Article