• Anon (unregistered)

    Classic Comment: Frist

  • Bored (unregistered)

    All these web programming stories are really depressing. Is there anyone left in the world that still does some real programming?

  • Right Wing-Nut (unregistered) in reply to Bored
    Bored:
    All these web programming stories are really depressing. Is there anyone left in the world that still does some real programming?

    Yeah. But our code doesn't end up here...

  • sadwings (unregistered)

    Can one of you smart fellas explain to me what it it he's doing so I can get the jok?

    I sort of see the fundamental issue, but I don't understand the implementation.

  • highphilosopher (unregistered)

    Can one of you not so smart fellas query what the real WTF is so I'll have a chance to explain it?

    Oh wait, someone already did!!!

  • Spivonious (unregistered)

    I'm not a web programmer, but aside from the fact that this would be more straightforward with a database, why is this one a WTF? Is it a security risk by having the product information in an asp page?

  • the_real_bored (unregistered)

    I like how you refer to anything outside of web development 'real programming', you sir are TRWTF. So I will take a guess your name is Vijay?

    http://thedailywtf.com/Comments/The-Proven-Fix.aspx

    captcha:vereor

  • (cs) in reply to Spivonious
    Spivonious:
    I'm not a web programmer, but aside from the fact that this would be more straightforward with a database, why is this one a WTF? Is it a security risk by having the product information in an asp page?

    This re-creates nearly every problem a relational database was designed to correct.

    Think: Reinventing a wheel. Only your new "wheel" is square. And it only works in a very specific set of circumstances. And it explodes if it moves more than 10 mph. You get the drift?

    This is a catastrophic fail. They would be better using Excel for their data repository and controlling it with 10k lines worth of VBA.

  • Scott Saunders (unregistered)

    Isn't this how CouchDB works?

  • Drew (unregistered) in reply to Scott Saunders
    Scott Saunders:
    Isn't this how CouchDB works?

    Even if it was, wouldn't it be better to let CouchDB do it rather than designing it yourself?

  • Engival (unregistered) in reply to Spivonious
    Spivonious:
    I'm not a web programmer, but aside from the fact that this would be more straightforward with a database, why is this one a WTF? Is it a security risk by having the product information in an asp page?

    I'll just throw out some random ideas, not in any order:

    1. Every HTTP request forces a copy of your entire "database" into memory.
    2. asp.net is a compiled language. By changing the source code, you're forcing a recompile all the time. (I never use windows hosting or .net, does IIS call the compiler automatically, or do you have to compile it yourself?)
    3. File locking; He's overwriting a source file directly on the web server. If another request happens while he's rewriting it, the other thread will have an interesting time. (Also, if the thread crashes for some reason, perhaps he ran out of memory processing new heavy http requests, he loses his database)
    4. A single "row" update turns into a massive operation that rewrites his ENTIRE 'database' from memory to disk.
    5. You get no benefits of SQL. You have to manually loop through the array to find data, without the benefit of an index (unless you create one yourself). His solution is really way more complicated than just using a proper database, and hundreds of times slower.

    That said, if he absolutely wants to avoid SQL (maybe it's a db of 10 items), there's STILL better ways to do it. Dump your data to a text file as a csv or some kind of serialized array. You don't just go generating new source files on a whim, that's dumb.

  • web-programmer (unregistered)

    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"?

  • Wheaties (unregistered)

    Hey, wait a minute:

    MyJunk_(1,1) = "I Cn do that too." MyJunk_(1,2) = "What's real programming?" MyJunk_(1,3) = "I'd like fries with that."

    Oh crap, I misspelled "Can." Guess I have to recompile.

  • you're-not-getting-it (unregistered) in reply to web-programmer
    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.

  • Azeroth (unregistered) in reply to web-programmer

    Yes, yes, now calm down and go build a "lightbox" or "share this" button or something.

  • storray expert (unregistered)

    Comment(16,0) = "WTF."

  • ih8u (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.

    Yeah, you sissies. If your keyboard has more than a 0 and a 1 button on it, you suck. If you're not writing for a specific CPU in machine code, you're a baby. In fact, you are the worst people ever.

    I spend all day doing what a high level language, a competent (non-real) programmer, and a decent compiler/interpreter could do in 10 minutes.

  • me_again (unregistered)

    'Real programming doesn't involve stupidly bloated baby languages' snip

    but it sure does pay well ;)

    Go back to manual memory management and don't let the 21st century hit your ass on the way out.

    captcha:ingenium : Not this guy

  • Anonymous (unregistered)

    I think it's clever.

  • web-programmer (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.

    Aha I understand, so it's nothing to do with "web programming" it's all about high level languages.

    So if your job does not involve writing err device drivers with pherhaps the odd embedded system or graphically intesive app/game isn't actually a programmer.

    So when we need to add an important feature to something by the end of the week we should promptly tell the boss that he must have mistaken us for "ass tard code monkeys" who use the languages taught in most universities and asked for by the most jobs and we really need to think about "the inner workings of the system"

    What about someone who codes a high-load application that uses a web GUI but drops into C code for performance critical stuff, where do they sit?

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

    Ah, so that's why I'm now a "developer"!

    Instead of reinventing the wheel to get trivial speed increases that could be done more efficiently by upgrading the hardware at the expense of bugs and security leaks, I pick an appropriate existing language or product where most of the weaknesses are documented and use that instead.

    I get things done quickly, safely and cheaply. I'm a developer not a "real programmer". Thank fuck for that.

  • bethatway (unregistered) in reply to web-programmer

    The main difference between web programmers and so-called "real programmers" is that web programmers will still have a job in five years.

  • Sanity (unregistered) in reply to Scott Saunders
    Scott Saunders:
    Isn't this how CouchDB works?

    Not even close. I started writing a post describing exactly how, but the number of differences are quite large.

    Here's a small, simple one: Couch is designed to be able to operate on large clusters, with large on-disk databases on each one. Storray is limited by what can fit into RAM on a single machine.

  • (cs) 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.

    Blah blah blah...more garbage from curmudgeons who are mad that people don't churn their own butter anymore.

    I can relate to the sentiment that the ease of higher-level framework-oriented languages has made for some pretty abysmal programmers, but good programmers transcend languages. You may call yourself a "real" programmer.

    I call you a shitty one (based only on my VERY limited observation, and my need to call you out on that line of bullcrap you're spouting).

    Any programmer who can't acknowledge the usefulness of Java and .NET is worthless, outside of programming wristwatches and washing machines. Note that I'm not saying that low-level languages are useless, I'm not daft. I'm saying that if you don't use the best tool for a given job, you're incompetent.

    That's the way this game has always been. If those languages didn't get shit done, they wouldn't be so incredibly popular. But they do, and they are.

    For all of that, every GOOD web programmer I know understands the "inner workings of a system". The crappy ones are the same crappy programmers that have been around since day 1.

  • abstrationGuy (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.

    A code monkey is the one writing the "optimized routines", spending an extra hour on writing a loop in assembly that might save 1 milisecond compared to C# or VB.net. A "real programmer" deals with higher-end issues like business requirements and logic which is made easier with abstraction. It is good to acknowledge the difference but why reinvent the wheel?

  • SoaperGEM (unregistered)

    To sum up half the comments so far:

    Blah blah blah No true Scotsman blah blah blah.

  • Man behind the scenes (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.

    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...)

  • (cs) 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.

    Well, what do you want to be: a real programmer, or an ass-tard code monkey who actually gets it? You can't have 'em both.

  • NetBiter (unregistered) in reply to Voodoo Coder
    Voodoo Coder:
    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.

    Blah blah blah...more garbage from curmudgeons who are mad that people don't churn their own butter anymore.

    I can relate to the sentiment that the ease of higher-level framework-oriented languages has made for some pretty abysmal programmers, but good programmers transcend languages. You may call yourself a "real" programmer.

    I call you a shitty one (based only on my VERY limited observation, and my need to call you out on that line of bullcrap you're spouting).

    Any programmer who can't acknowledge the usefulness of Java and .NET is worthless, outside of programming wristwatches and washing machines. Note that I'm not saying that low-level languages are useless, I'm not daft. I'm saying that if you don't use the best tool for a given job, you're incompetent.

    That's the way this game has always been. If those languages didn't get shit done, they wouldn't be so incredibly popular. But they do, and they are.

    For all of that, every GOOD web programmer I know understands the "inner workings of a system". The crappy ones are the same crappy programmers that have been around since day 1.

    ....he's probably one of those union guys who put in screws by hand instead of using power tools.

  • (cs)

    The only real programmer:

    [image]
  • (cs) 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.

    And the TopCoD3r award of the day goes to....

  • Edward Royce (unregistered) in reply to Voodoo Coder
    Voodoo Coder:
    Spivonious:
    I'm not a web programmer, but aside from the fact that this would be more straightforward with a database, why is this one a WTF? Is it a security risk by having the product information in an asp page?

    This re-creates nearly every problem a relational database was designed to correct.

    Think: Reinventing a wheel. Only your new "wheel" is square. And it only works in a very specific set of circumstances. And it explodes if it moves more than 10 mph. You get the drift?

    This is a catastrophic fail. They would be better using Excel for their data repository and controlling it with 10k lines worth of VBA.

    I still bear the emotional scars from working on precisely that sort of system. A data repository based on Excel worksheets where every single one of 5.5 million customers had their data stored on an individual Excel worksheet.

    Don't even ask how many damn servers it required to handle the stupid things.

    I now need a beer.

  • Edward Royce (unregistered) in reply to Fabian
    Fabian:
    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.

    Well, what do you want to be: a real programmer, or an ass-tard code monkey who actually gets it? You can't have 'em both.

    What I want to be is retired and to forget I ever even knew how a computer worked.

  • Scott Simmons (unregistered)

    "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.

  • (cs)

    Wow, where can I get a copy of Storray? I'm tired of SQL telling me what to do all the time!

  • (cs) in reply to abstrationGuy
    abstrationGuy:
    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.

    A code monkey is the one writing the "optimized routines", spending an extra hour on writing a loop in assembly that might save 1 milisecond compared to C# or VB.net. A "real programmer" deals with higher-end issues like business requirements and logic which is made easier with abstraction. It is good to acknowledge the difference but why reinvent the wheel?

    I agree that "you're-not-getting-it" is not getting it. But you've still missed.

    A real programmer gets the job done in a roughly optimal manner. Sometimes, that optimizes developer time more. Sometimes it optimizes CPU time more. It always optimizes the bottom line.

    Language choice, platform, and optimizing techniques are merely tools to that end.

    If a routine is going to run on customer hardware, it generally gets less optimization than if it runs mostly on company hardware. If it runs rarely, it probably won't be optimized. If it runs continually on many machines, and performs a lot of processing, it's going to be optimized.

    If it takes 20 hours of programmer time to reduce CPU time enough to save needing ten more machines, that 20 hours of programmer time is clearly worth it. If it takes 20 hours of programmer time to reduce CPU time enough to turn off ten machines, that 20 hours of programmer time might be worth it, depending on maintenance costs and whether there's a need for some or all of those ten machines elsewhere. If it takes 20 hours of programmer time to free up 1% of the CPU of a single $500 machine, that time is clearly not worth it. Somewhere in there, there's a balance point.

    Now, personally, Perl works far better for me than Java and C# - both of the latter leave, IMHO, too much low level stuff to the programmer, that Perl handles automagically. I tend to write about 10 lines of Java (not including comments) for every 3-4 lines of Perl (including comments). When writing C code to embed in Perl, I tend to write about 20-50 lines of code per 3-4 lines of Perl. Writing stand-alone C runs about 100 lines of code for 3-4 lines of Perl.

    Of course, if I don't care about legibility, I could write 1 line of Perl (of course, no comments) per 3-4 lines of legible Perl (with comments - note that comments are sparse, not 2-3 lines of comments per line of code.)

    C# looks a lot like Java to me. But I don't write code that only runs on one OS, unless it's in C (and even then, I'm normally multi-platform). Yes, I know about Mono, but given Microsoft's track record, I have no faith in it.

  • Scott Simmons (unregistered) in reply to Engival
    Engival:
    I'll just throw out some random ideas, not in any order: ... 2. asp.net is a compiled language. By changing the source code, you're forcing a recompile all the time. (I never use windows hosting or .net, does IIS call the compiler automatically, or do you have to compile it yourself?)
    I didn't notice anybody answering this question amongst all of the 'real programmer' posturing, so I'll give it a whirl ... No, IIS does not call the compiler automatically; you need to compile the updated ASP.NET page in order for it to run for the users. This is presumably why the brilliant architect of this page had to call in an expert consultant to help convert this to ASP.NET. And it's really not possible--you'd have to rewrite this whole monstrosity in a completely different way. (Geez, I said that like it's a bad thing ...) Well, I guess you could write some VB that mimics the .NET compiler and converts the included page updates into the appropriate CLR code. To continue Voodo Coder's analogy, this would be something like fixing our reinvented square wheel by welding it to a statue of Henry Ford.
  • (cs)

    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"

  • (cs)

    It's quite simple, really. A computer program is code that's run by a computer, and programming is writing such code.

    Code that is not run by the computer, but instead is executed by some other program, is not a computer program, but a script. The fact that these days we have scripting languages that can accomplish many of the tasks that were originally the sole purview of real programs (Java, .NET, etc) does not change the basic definitions.

    I have nothing against abstractions. They're very useful, to a point. But any abstraction that you can't get beneath is evil because any code can have serious bugs, including the code that comprises an abstraction layer.

    I think the main difference between "a code monkey" and "a real programmer" is the ability to understand what's really going on and use that understanding wisely to make design decisions. Even if you never have to write a single line of assembly code, if you can't understand what's going on at the assembly level, you're contributing to the problem.

    For example, my first computer was an Apple IIe. My first video game system was a NES. The NES would boot up and be ready to play instantly, and the Apple took a few seconds. Now I have a PS3 and a modern, high-end PC. Both of them are well more than a thousand times more powerful than their early-90s counterparts, by any metric you can think of for measuring computing power, but they take far longer to get up and running or load programs.

    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.

  • (cs) in reply to Engival
    Engival:
    Spivonious:
    I'm not a web programmer, but aside from the fact that this would be more straightforward with a database, why is this one a WTF? Is it a security risk by having the product information in an asp page?

    I'll just throw out some random ideas, not in any order:

    1. Every HTTP request forces a [blah blah blah] that's dumb.
    He said "aside from the fact that this would be more straightforward with a database"; and instead, you've just explained why it would be more straightforward with a database, via a list of flaws in the design.

    If you can't read the spec, what are you doing here?

    The simple answer is that it is a database: just a hugely inefficient, insecure, poorly implemented, and unmaintainable one for a very tight niche market.

  • hoodaticus (unregistered)

    This crap disgusts me! This asshole is probably employed right now, making good money while I sit here unemployed and - get this - my database-implementing .NET code actually compiles. (To CIL, but still...).

    (BTW - I'm unemployed because I had a boss much like the one in the last article, only their arrogance was so great that they actually forced me to resign due to a conflict of interest with my side-contract for their boss, the Board of Directors).

    Why TF did this programmer think arrays were easier to work with than SQL anyway? And don't even get me started on classes...

    I know the WTFer isn't reading this right now - he's too busy making money - but how does he think databases store data in memory and, more importantly, why have billions of dollars been spent on developing them? Answer: no sense and no common sense either!

    EEAAARRRRGH!

  • (cs) in reply to Mason Wheeler
    Mason Wheeler:
    It's quite simple, really. A computer program is code that's run by a computer, and programming is writing such code.

    Code that is not run by the computer, but instead is executed by some other program, is not a computer program, but a script. [continuing drone]

    It must get lonely weaving your own clothes on a loom of your own design that you whittled from brushwood with your teeth.

    Use of tools is what was once thought to distinguish humans from the "lower" animals. Since that time, it's been discovered that even crows use tools ... and yet you won't?

  • (cs)

    Y'know, I can easily imagine circumstances under which it might be useful for an app to not be dependent on an external DB engine. Portability, compatibility, ease of installation, etc.

    But jesus christ... if you're going to have the hubris to try something like that, at least do it well!

  • J (unregistered) in reply to rfsmit
    rfsmit:
    Engival:
    Spivonious:
    I'm not a web programmer, but aside from the fact that this would be more straightforward with a database, why is this one a WTF? Is it a security risk by having the product information in an asp page?

    I'll just throw out some random ideas, not in any order:

    1. Every HTTP request forces a [blah blah blah] that's dumb.
    He said "aside from the fact that this would be more straightforward with a database"; and instead, you've just explained why it would be more straightforward with a database, via a list of flaws in the design.

    If you can't read the spec, what are you doing here?

    The simple answer is that it is a database: just a hugely inefficient, insecure, poorly implemented, and unmaintainable one for a very tight niche market.

    How 'bout just throw out any random ideas?

  • (cs) 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.

    Meh, whatever. As long as I write stuff that actually ships, you can call me whatever you want. If a higher-level language means stuff ships faster, all the better. I don't care about labels, but I do care about making money for my company.

    Besides, "elegant code" is for version 2, right. :-)

  • john doe (unregistered)

    real wtf are you guys here with your years of experience commenting noobs and their first programming attempts. yup, them having high title and degree does make them look funnier. i would like to see what wheels you reinvented long ago.

    and i bet those smart assess that think 'nope, that never happened to me' have most ludicrous examples

  • (cs) in reply to Voodoo Coder
    Voodoo Coder:
    I can relate to the sentiment that the ease of higher-level framework-oriented languages has made for some pretty abysmal programmers, but good programmers transcend languages.

    QFT. However, some of the pretty abysmal programmers have merely shifted from languages where they spent most of their day attempting to compile, making random changes around where the compiler said the error was until something finally made it through, to using languages which can glean enough semantic content from their spew to do the wrong thing in a bad way.

    Ugh. Lemme try that again. Some of the worst programmers in high level languages used to be failed programmers in low level languages. Most people remember the good ones better - it's the nostalgia effect. That doesn't mean the bad ones weren't there. Back in the day, there were a lot of atrocious programmers.

    Now, there has been some refinement in the low level arena since then - many of the bad programmers left, but a lower percentage of the good ones left. Some of that is attitude issues (like what we've seen from the low level programming crowd), and some of that is, "Why move on when you have a good paying job doing stuff you're good at?"

    Note that, as far as I can tell from outside the group, this does not mean that we've reached the point where most low-level programmers are competent. We started out with around 95% incompetence (as with everything else, 95% of everything is crap), and we're probably somewhere between about 75-90% of low level coders being incompetent. While that skew does probably mean we have a larger percentage of crap programmers in high level languages, there's few enough low level programmers the amount probably isn't significant.

  • (cs) in reply to rfsmit
    rfsmit:
    Mason Wheeler:
    It's quite simple, really. A computer program is code that's run by a computer, and programming is writing such code.

    Code that is not run by the computer, but instead is executed by some other program, is not a computer program, but a script. [continuing drone]

    It must get lonely weaving your own clothes on a loom of your own design that you whittled from brushwood with your teeth.

    Use of tools is what was once thought to distinguish humans from the "lower" animals. Since that time, it's been discovered that even crows use tools ... and yet you won't?

    Call me overly idealistic, but I was expecting a better response to that than just someone trotting out the tired old "do everything manually" strawman. Please read what I actually said. I enjoy working with abstractions and tools, since they make programming far easier and often (but not always!) lead to a better-quality program.

    The problem comes when you start using tools and abstractions without understanding how they work. That's directly responsible for the vast majority of software problems today, and "helpful languages" such as Java and .NET are making it worse, not better.

    Besides, programming languages need to be held to a higher standard than "tools" that other craftsmen use. If I use a hammer, a saw and a drill to build a table, I don't end up with a table with a hammer, a saw and a drill embedded in it. This means that I can get away with using low-quality tools with a minimum of trouble. But when I write code, all the frameworks, abstractions and design patterns I use get compiled into the program. The language isn't just a tool; it's a tool and a raw material in one.

  • (cs) in reply to Mason Wheeler
    Mason Wheeler:
    It's quite simple, really. A computer program is code that's run by a computer, and programming is writing such code.

    Code that is not run by the computer, but instead is executed by some other program, is not a computer program, but a script. The fact that these days we have scripting languages that can accomplish many of the tasks that were originally the sole purview of real programs (Java, .NET, etc) does not change the basic definitions.

    Ah, so bytecode is what makes up a "real program". Any VM or JIT compiler or CLR has nothing to do with it. Gotcha.

    Mason Wheeler:
    I have nothing against abstractions. They're very useful, to a point. But any abstraction that you can't get beneath is evil because any code can have serious bugs, including the code that comprises an abstraction layer.

    Java and .NET are evil, got it. C/C++ aren't evil, I presume. And you would never bother with "abstractions" like the STL, right? Straight to asm for you. There's some real programming!

  • guiltyascharged (unregistered)

    I've had to do this in PHP for a client with an irrational fear of databases (long story) and a reluctance to spend the money required to implement the database queries and admin panel involved. Instead they paid us for the hour or so every week spent adding new products to the array. facepalm

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

Log In or post as a guest

Replying to comment #294427:

« Return to Article