• rien (unregistered) in reply to rbriem
    rbriem:

    Seriously, though, I'm an Knife user, which pretty much does everything I need to do (its handling of hash is exceptional), so I've never had a reason to try Gun. But I do recall seeing this discussed on a forum and from what I recall, Gun is a trigger-driven system that delivers unique "message/object" modules called "Bullets", and it requires an actor (person) to initiate the message/object delivery action. So I think that you're *both* right, to a certain extent.

    People kill people ... guns just improve their performance.



    Executive summary: A bullet is an ultra-efficient mechanism for IPC (Inter-People Communication).

    we can comment longer on its efficiency: not much latency and, the most important, generally the receiver will perform the requested action BEFORE receiving the message.
    BUT it works only for receivers close enough to the emmiter, difficulty (impossibility) of dispatching/routing/..., lost messages due to incorrect adressing (highly depends on the skills of the emmiter), bullets do not work with XML.
  • (cs)

    hmm... it's hardly worse than any other flat-file storage method (XML, CSV etc.). Of course, not using a real database counts as a WTF in most real world applications; but it's hard to judge if this "database" with a few hundred records makes it worth the effort. Most applications in this world  can be made more sexy by throwing lots of cash at it. Buy me a database server, buy me a middleware, send some consultants for 250 USD/h and we will make the most buzzword compliant system in the world. But please never mention the ROI.

  • (cs) in reply to Cheddar
    Anonymous:
    The problems people create trying to avoid problems they should fix are usually worse.


    You're right.  Things like this are often the result of a Second-System-Syndrome-afflicted programmer who thinks he's going to "save" everyone a lot of work.  Notice how proud the brain was that "all you have to know is arrays."  Evidently he was convinced the other programmers were incapable of anything more than that.

    The fewer programming teams this "brain" is permitted to infect, the better.  At least until he learns to write code that does the job well instead of trying to be so "helpful."

  • challahc (unregistered) in reply to seizethedave

    That's my favorite part!
    THE STORRAY ENGINE!!! echo. echo.. echo...

  • (cs) in reply to Cowardly Anonymous
    Anonymous:

    In the first place, someone who can't be bothered to learn SQL should have never been allowed to code web applications. That's specially true for someone who apparently never heard words like "maintainability", "scalability" or "thread safety".

    There are a fairly limited number of people who understand these things, and lots more work than there are people. And if you are someone who's a bit afraid to jump into something like an SQL database and don't really understand concurrency that well, yet still have to write a functioning web app, the solution presented isn't all that awful. In fact, the use of self-modifying code in that way is kind of clever, even if it is also ugly, bad and a poor fit for the problem if more than one person needs to update the product list at a time.

    So, I hold out hope for the programmer who did that. He's definitely overly proud of himself. And he is clearly afraid of various technologies he doesn't yet understand. But better a solution you understand than making some horrible SQL monstrosity because you haven't a clue what you're doing.

  • (cs) in reply to CornedBee

    CornedBee:

    /Code/.../Data/

    That's just something you don't really want to see in a directory structure.



    You must be from the middle generation. Code is Data. Lisp for ever.
    (in a lot of Lisp frameworks, data is saved as runnable code)
  • Bravely Anonymous (unregistered) in reply to Anonymoose

    mcrbids:
    He at least abstracted maintenance into a single, uniform method!

    It's scary, but that's a good thing.

    Anonymoose:
    He was not restricted from using SQL, as far as we know.

    Even if he was (and that happens) it's still a crap solution.

    A) He's obviously reading and writing files - this data can and should go in a simple CSV (comma separated value) or XML style file or something - writing it back into the application like that is just weird and wrong. It has a certain cuteness, but in the same sense that a two year old drawing on the walls can be cute even if you know it's going to be hard to clean.

    B) It's not even a little bit scalable - if every write operation rewrites part of the application, then they can't be writing to it often. Therefore even if a full SQL engine (Oracle, SQL Server, or even MySql) is out of the question, a tiny thing like SQLite ought to be usable.

    C) WTF?  While writing an update, anyone attempting to read any page dependant on that file is risking a failed access?  Sure, that may be a rare option, but attention to detail is important, dammit!  Really, I'ld love to see the spec that makes that the best option available. And then I'ld go to the bar, too.

  • (cs) in reply to Cowardly Anonymous
    Anonymous:
    In the first place, someone who can't be bothered to learn SQL should have never been allowed to code web applications. That's specially true for someone who apparently never heard words like "maintainability", "scalability" or "thread safety".

    You just listed the three reasons why to use generated code (like in the OP).
    1) Most firms don't have a DB admin, they have a VB devlopper coder -er.
    2) Most firms had only a 5-connection license (not true any more)
    3) Code scales better than DB
    4) Thread-safety? For read-only data?
  • (cs) in reply to mcrbids

    mcrbids:
    I've used solutions like this where part of the spec is that no flavor of SQL is available, and there's a need to store complex sets of data in files. He at least abstracted maintenance into a single, uniform method!

    So, really, what's the WTF? Please explain. No, I'm not satisfied with "ooh, the eyes!", either.

    Yes, you end up with limits on storage size, and SQL is the preferred choice. But, with the limitations mentioned above, what's the "non-WTF" answer to this kind of problem?

    Seems to me that the WTF here is a programmer unable to challenge himself, and perhaps too dependent on alcohol.

    The WTF here is that he uses self-rewriting code when many far simpler and less likely to explode solutions exist.  For example, why not just write the data to a file and read it back in in the included ASP page?  Why not put in in the Application object?  Even better, have the accessor code in the included file, have that check for existing Application data, if that's not available, load it and return it.  If the data is in the Application object, compare the current file last modified date to one previously stored in the Application object, if too old, dump and reload.  Add an included COM object for thread synchronization written in a real language.  In an hour he could have built a rudimentary cache system that would probably have supported many thousands of data items as long as the data is rarely changed.  Instead he built a ready-to-explode beast and was proud of it.

    This reminds me of the "put the images in images.php" WTF where "cleverness" was seen as the defining characteristic for code quality.

  • Anonymous (unregistered) in reply to ferrengi
    ferrengi:
    Give us a real life example of where a database cannot be used and then we can discuss the best answer to the problem without using a database.

    At my last job, myself and a graphic designer turned coder were tasked with creating an internal knowledge base, but all we had was some file storage - no dynamic scriping allowed because IT convinced management that giving us any thing else would compromise the security of the server. They refused to even let us have one of the surplus desktop boxes and slap a WinXP / IIS / MSSQL Express or LAMP solution on it.

    We ended up writing the whole thing in client side JScript that would load up XML from the small file stores they gave us.

    That KB was constantly months out of date because it was so hard to maintain. Shortly before I left, the other person on the project discovered a security flaw in the internal server that allowed him to execute arbitrary classic ASP code, but still no database.

    Idiotic management can make even good programmers take drastic measures.
  • Asif Youcare (unregistered) in reply to Omnifarious

    I can't believe that people are defending this as not so bad.

    The guy could've simply used a flat file and read it into memory at start-up, and changed the contents of that file whenever a data change was required.  Instead, he had the program rewrite itself whenever data changed.

    My god!



  • Anonymous (unregistered) in reply to Anonymous Coward
    Anonymous:

    Sadly there really are people in this industry who are so wrong that it actually isn't possible to help them. I mean way far out down "Wrong Road" that a journey to go and reach them would take an entire lifetime!



    the worst part is that they're always so confident.  if you're in the predicament of having to teach them, not only do you have to start from design basics (and maybe why programming languages support more than just arrays), but first you need to completely destroy their self-confidence and tell them that everything they hold dear is ruining the world.

  • Jase (unregistered)

    I would have loved to see how this performed on some of my past projects I've had to deal with, such as databases that have in excess of 1.7million rows in some tables! I know they say memory is cheap, but not that cheap, and unless you already have LINQ (Even so I don't think it could cope with huge datastores in RAM that easily), or maybe you skilled enought to use MultiIndex in C++ / Boost, then I wouldn't want to think how slow it would be on something that is in the magnitude of 1'000'000 ARRAY elements!

  • A+ (unregistered)
    Alex Papadimoulis:

     it's like having the benefit of a database without ever having to use SQL, ADO, or any of that stuff; just simple arrays.

    WOW! What a concept! A database without actual database.

    What exactly would be wrong with "having to use SQL, ADO, or any of that stuff"

  • (cs) in reply to fmr

    fmr:
    It seems there is another one, as the Ryobi info seems to override the Dewalt one... (index 345 used instead of 2)

    Yeah... but the Ryobi is less than a tenth of the price of the Dewalt, so that's okay.  Good eye.  Wonder how many other little overrides are sprinkled about the *database*?

  • Moobar (unregistered) in reply to Carl
    Anonymous:
    And the difference between this and an XML "database" is....
    ...
    ...


    At least with XML you can change individual entries using XUpdate.  On the other hand, this guy's format is a POS because it requires rewritten the entire database everytime you save a change.  Even an idiot would nkow this is a stupid way to implement data storage.
  • (cs) in reply to mcrbids
    mcrbids:
    I've used solutions like this where part of the spec is that no flavor of SQL is available, and there's a need to store complex sets of data in files. He at least abstracted maintenance into a single, uniform method!

    So, really, what's the WTF? Please explain. No, I'm not satisfied with "ooh, the eyes!", either.

    Yes, you end up with limits on storage size, and SQL is the preferred choice. But, with the limitations mentioned above, what's the "non-WTF" answer to this kind of problem?

    Seems to me that the WTF here is a programmer unable to challenge himself, and perhaps too dependent on alcohol.

    A simple CSV file used to store the data -- separate from the code -- is far preferable to the mess we see here. And the JET engine using a simple MDB file, while certainly not ideal for a busy site, is 100% free when using ASP and far more robust, flexible and maintainable then what we see here.

    The #1 rule any programmer should know: always separate your code from your data.

  • (cs)

    It's not difficult to compile stuff at runtime with .NET ... this could be easily accomplished with .NET's System.CodeDom.Compiler namespace using your .NET language of choice.

  • Anonymous (unregistered)

    yeah, I just can't figure out how to bring this into .NET; I'm thinking using classes instead, but man, it's hard to compile stuff at run-time!

    Now I think I understand what my boss was asking, when he wanted to know how to get the web site to compile files it had created...

  • (cs) in reply to voodooc
    voodooc:
    The *real* WTF here, is why didn't he use a hash instead of an array?

    vc


    Do you think that if he didn't know how to persist data in a RDBMS, that he would know about a hash table?  The *real* WTF is the manager that hired this dipswitch.
  • mikeyd (unregistered) in reply to SeekerDarksteel

    Of course this is coming from the same person who couldn't stop laughing for 5 minutes after thinking about the idea of pcAnywhere'ing into a remote box, then pcAnywhere'ing back into my own box. Speaking of which, I need to try that sometime.

    Back when I was starting on 'nix, I couldn't figure out how to su but be able to use X. My solution? ssh -X to my other box, then ssh -X root@ this one.

    Well, it worked.

  • Oli (unregistered)

    I'd hate to see the memory use of that IIS server o_O

    "A million webservers cried out at once... and then silence"

  • Asd (unregistered) in reply to ammoQ
    ammoQ:
    hmm... it's hardly worse than any other flat-file storage method (XML, CSV etc.).

    Is it just me or are the responses here getting even dumber?
    I'm sorry but storing all your data in your source code IS far, far worse than using a flat file storage method and if you can't see that then you are beyond help.
  • (cs) in reply to Asd
    Anonymous:
    ammoQ:
    hmm... it's hardly worse than any other flat-file storage method (XML, CSV etc.).

    Is it just me or are the responses here getting even dumber?
    I'm sorry but storing all your data in your source code IS far, far worse than using a flat file storage method and if you can't see that then you are beyond help.


    It's just you ;-)
    Technically it is source code but in practice it's just a serialisation method. As long as there is no other code in Products.asp, I couldn't care less. The main drawback compared to CSV or XML is that the data cannot be loaded into e.g. Excel.
  • (cs) in reply to Jeff S
    Jeff S:

    The #1 rule any programmer should know: always separate your code from your data.



    Are prolog programs data or code?
    Are Postscript, PDF and WMF data or code?

  • (cs) in reply to ammoQ

    Ideally he should have used a fully scallable database system, such as SQL Server, Oracle, MySQL, DB2 or whatever.  Choose your fave.  They all have pros and cons.  Some of these offer free versions so "we can't afford that" isn't much of an excuse.

    Failing that (such as not having a suitable server or needing it to be file-handled), he could have used a smaller-scale database system, such as Paradox or Access.

    Failing that, he could use a collection of CSV files or an XML file.   Hell, even Excel would have been a better choice than the one he used (he could interact with the .xls through COM).  Personally I'd have probably gone for XML if I couldn't use a full database system.  Parse it with SAX and it's not too slow, you can generate reports straight from it using XSL, you can perform queries on it so searches and filters become a lot easier.  If his requirement was to avoid databases, then XML offers many of the same features, even if it can be hard to set all that up.

    What you should not do is put it in a hardcoded array like that.  I was wondering what happens if I have 5 products and #3 is discontinued so I delete it...?  And what was that stuff about compiling at runtime?

  • a0a (unregistered)

    .. suspension of disbelief!
  • (cs) in reply to johnl
    johnl:

    What you should not do is put it in a hardcoded array like that.  I was wondering what happens if I have 5 products and #3 is discontinued so I delete it...?  And what was that stuff about compiling at runtime?


    I think you missed the point how the storray engine works. The "data file" looks like hardcoded (in fact it is obviously source code), but it is not hand written. All you have is an array. Change a record? Delete a record? Insert a record? Do it in the array. Afterwards, the new version of the array is written to the "data file". (Of course, this is neighter efficient nor thread safe).
    Instead of XML which requires an additional parser, the programmer wrote ASP code that can be directly imported. I guess it's also faster than parsing an XML file. But of course, on the downside, other tools cannot process it.
  • nope (unregistered) in reply to ammoQ

     "Are prolog programs data or code?"

    data(prolog_program).
    no.

    code(prolog_program).
    no.

  • (cs) in reply to nope
    Anonymous:
     "Are prolog programs data or code?"

    data(prolog_program).
    no.

    code(prolog_program).
    no.


    *LOL* good answer :-))
  • (cs)

    I hope the original programmer got the opportunity to fix the problem: A happy ending to a sad Storray.

    ducks

  • (cs) in reply to versatilia

    ...and let's not forget the 'BRILLANT' technology!

  • (cs) in reply to rien

    "we can comment longer on its efficiency: not much latency and, the most important, generally the receiver will perform the requested action BEFORE receiving the message.
    BUT it works only for receivers close enough to the emmiter, difficulty (impossibility) of dispatching/routing/..., lost messages due to incorrect adressing (highly depends on the skills of the emmiter), bullets do not work with XML."

     

    Sounds a bit like PERL.

     

    BTW: The funniest thing, when searching the classified ads for a job, is to see Programmer positions that require;

      PEARL and SEQUEL skills

    Makes me laugh out loud every time

  • (cs) in reply to ammoQ
    ammoQ:
    Jeff S:

    The #1 rule any programmer should know: always separate your code from your data.



    Are prolog programs data or code?
    Are Postscript, PDF and WMF data or code?



    Not sure what your point is ... do you write applications in PDF ?

    Any particular file format might ultimately contain both data and instructions/code (i.e., display instructions, macros, etc) but that is different from writing an application in which your data is embedded in your code.

  • (cs) in reply to ammoQ

    ammoQ:
    johnl:

    What you should not do is put it in a hardcoded array like that.  I was wondering what happens if I have 5 products and #3 is discontinued so I delete it...?  And what was that stuff about compiling at runtime?


    I think you missed the point how the storray engine works. The "data file" looks like hardcoded (in fact it is obviously source code), but it is not hand written. All you have is an array. Change a record? Delete a record? Insert a record? Do it in the array. Afterwards, the new version of the array is written to the "data file". (Of course, this is neighter efficient nor thread safe).
    Instead of XML which requires an additional parser, the programmer wrote ASP code that can be directly imported. I guess it's also faster than parsing an XML file. But of course, on the downside, other tools cannot process it.

    ammoQ, can you post your real name so we can all avoid ever working with you in the future?

  • (cs) in reply to SeekerDarksteel
    SeekerDarksteel:

    voodooc:
    The *real* WTF here, is why didn't he use a hash instead of an array?

    vc

     

    I dunno if you've ever messed around with VB's Scripting.Dictionary object (afaik the easiest (only?) way to do hashes in VB), but they are extremely annoying to work with.  Massive bugs can occur because you fail to use cStr around either a key or a data item.  Just last week I was having a problem where I was getting data out of the hash that I had never put in.  Worse, if I tried to use certain keys to access the data the page would error out.  It turns out that the problem was that I didn't cast the data as cStr before putting it in the dictionary.

     

    Now, I know you were probably joking about using hashes given the tell-tale "The real WTF here is...", but I just wanted to use this opportunity to bitch about hashes in VB without being entirely off-topic.



    Yeah, it sucks that you have to use proper data types and everything ... even worse, sometimes you even have to declare variables!  
  • (cs) in reply to JohnO
    JohnO:

    ammoQ:
    johnl:

    What you should not do is put it in a hardcoded array like that.  I was wondering what happens if I have 5 products and #3 is discontinued so I delete it...?  And what was that stuff about compiling at runtime?


    I think you missed the point how the storray engine works. The "data file" looks like hardcoded (in fact it is obviously source code), but it is not hand written. All you have is an array. Change a record? Delete a record? Insert a record? Do it in the array. Afterwards, the new version of the array is written to the "data file". (Of course, this is neighter efficient nor thread safe).
    Instead of XML which requires an additional parser, the programmer wrote ASP code that can be directly imported. I guess it's also faster than parsing an XML file. But of course, on the downside, other tools cannot process it.

    ammoQ, can you post your real name so we can all avoid ever working with you in the future?



    look at www.ammoq.com
  • (cs) in reply to Jeff S
    Jeff S:
    ammoQ:
    Jeff S:

    The #1 rule any programmer should know: always separate your code from your data.



    Are prolog programs data or code?
    Are Postscript, PDF and WMF data or code?



    Not sure what your point is ... do you write applications in PDF ?

    Any particular file format might ultimately contain both data and instructions/code (i.e., display instructions, macros, etc) but that is different from writing an application in which your data is embedded in your code.


    In this particular case, data is encoded as source code. But since it seems that Product.asp does not contain anything else, "source" is just a file format and I wouldn't call that "embedded".

  • (cs) in reply to ammoQ
    ammoQ:
    johnl:

    What you should not do is put it in a hardcoded array like that.  I was wondering what happens if I have 5 products and #3 is discontinued so I delete it...?  And what was that stuff about compiling at runtime?


    I think you missed the point how the storray engine works. The "data file" looks like hardcoded (in fact it is obviously source code), but it is not hand written. All you have is an array. Change a record? Delete a record? Insert a record? Do it in the array. Afterwards, the new version of the array is written to the "data file". (Of course, this is neighter efficient nor thread safe).
    Instead of XML which requires an additional parser, the programmer wrote ASP code that can be directly imported. I guess it's also faster than parsing an XML file. But of course, on the downside, other tools cannot process it.

    XML *requires* an additional parser only if you are using uber-complex XML files.  For simple stuff (like this), I would hope any programmer who can parse a simple string should be able to figure out how to pull some data from it. 

    And remember -- XML is only a file format.  If you have list of items on your site, don't have any database availabilty to use at all (again, dubious -- MDB is free and quite powerful, though not good for multi-users but certainly better than what we see here) then *you* can choose whatever file format you want.  CSV?  Delimited by "*jeff*" ?  tabs?   fixed width?   One per line?  As long as it works and is documented.  Using XML because it's cool when you don't use any of its features is often overkill, especially if you now feel that you "need to use an XML parser" to parse simple data files.

    Pretty much the only way you can mess things up is to say "instead of a data file in any format, I will just dynamically alter the code in my application that one-by-one fills in array with my harded coded data!"
  • jeti (unregistered) in reply to ammoQ

    I don't know ASP and I feel somewhat lazy at the moment.

    Can you tell me whether entering quotes or brackets in the
    item descriptions would affect the "engine"?



  • (cs) in reply to jeti
    Anonymous:
    I don't know ASP and I feel somewhat lazy at the moment.

    Can you tell me whether entering quotes or brackets in the
    item descriptions would affect the "engine"?



    I guess the

    Replace(storray(i,j),"""","""""")

    part handles the problem of quotes; brackets don't matter

  • (cs)

    Well, based on some of the responses, it appears that some people actually do not consider this a WTF.  Let me spell it out for you.

    1) Let's pretend for argument's sake that writing saving data as code isn't a bad idea.  At least do it "right" and use an array of a user-defined type.

    2) If any product information changes, it requires editing script code.  With any other reasonable method, updating product information could be done by a chimp.

    3) If your website is worth a damn, you will offer query capability like show me all the hammers you sell, etc..  Implementing query capabilities on 2d arrays is pathetically stupid and a waste of time re-inventing the wheel.

    4) CSV, XML, Jet, Access, MSSQL and VB record I/O are all FREE viable alternatives to the Storrary Engine.

    5) If you weren't writing pathetic, throw away code, your system might have to be maintained (instead of rewritten).  If you use standard techniques and don't overengineer, other people can easily maintain your code.  No one with any sense would do anything but throw away the Storrary Engine.

    How can anyone defend this?  I can think of no set of circumstances under which I would call the Storrary Engine an acceptable solution.  People mention performance and overhead as reasons.  Are you kidding

  • (cs) in reply to Jeff S
    Jeff S:

    XML *requires* an additional parser only if you are using uber-complex XML files.  For simple stuff (like this), I would hope any programmer who can parse a simple string should be able to figure out how to pull some data from it.

    Right, I've also done that. Handfull of lines in Java. But this imposes many restrictions on the XML file, so it's a good candidate to end as a WTF once someone mistakes it for a real XML parser.

    And remember -- XML is only a file format.  If you have list of items on your site, don't have any database availabilty to use at all (again, dubious -- MDB is free and quite powerful, though not good for multi-users but certainly better than what we see here)

    It would have to be a very bad database to be worse than that ;-)

    then *you* can choose whatever file format you want.  CSV?  Delimited by "*jeff*" ?  tabs?   fixed width?   One per line?  As long as it works and is documented.  Using XML because it's cool when you don't use any of its features is often overkill, especially if you now feel that you "need to use an XML parser" to parse simple data files.

    This guy choose "ASP script" as his file format. It works and I think it is even documented. And the best thing is: the parser is already built-in ;-)

    Pretty much the only way you can mess things up is to say "instead of a data file in any format, I will just dynamically alter the code in my application that one-by-one fills in array with my harded coded data!"

    Probably the most efficient way to mess this up would be an attempt to understand and alter the file, instead of completely rewriting it. Definitely a no-go. This file must be written as a whole, and read as a whole.

  • (cs) in reply to ammoQ
    ammoQ:
    Jeff S:

    XML *requires* an additional parser only if you are using uber-complex XML files.  For simple stuff (like this), I would hope any programmer who can parse a simple string should be able to figure out how to pull some data from it.

    Right, I've also done that. Handfull of lines in Java. But this imposes many restrictions on the XML file, so it's a good candidate to end as a WTF once someone mistakes it for a real XML parser.

    And remember -- XML is only a file format.  If you have list of items on your site, don't have any database availabilty to use at all (again, dubious -- MDB is free and quite powerful, though not good for multi-users but certainly better than what we see here)

    It would have to be a very bad database to be worse than that ;-)

    then *you* can choose whatever file format you want.  CSV?  Delimited by "*jeff*" ?  tabs?   fixed width?   One per line?  As long as it works and is documented.  Using XML because it's cool when you don't use any of its features is often overkill, especially if you now feel that you "need to use an XML parser" to parse simple data files.

    This guy choose "ASP script" as his file format. It works and I think it is even documented. And the best thing is: the parser is already built-in ;-)

    Pretty much the only way you can mess things up is to say "instead of a data file in any format, I will just dynamically alter the code in my application that one-by-one fills in array with my harded coded data!"

    Probably the most efficient way to mess this up would be an attempt to understand and alter the file, instead of completely rewriting it. Definitely a no-go. This file must be written as a whole, and read as a whole.


    Wow .... can't tell if you are goofing around or serious.   Your comment about MDB files is a good indication of your overall ignorance on this topic, but again, hopefully you are just trolling or having some fun. 

  • (cs) in reply to Jeff S

    Yeah, ammoq, I did miss the point about what he was doing.  But then, if it's not hand-written, the data obviously comes from somewhere.  I dunno, maybe I'm just missing something but I'd be interested to see how the array that was being passed to that function was actually generated.

    Thing is, a lot of modern languages actually include XML parsing as part of the package.  If you use .NET, it includes the System.Xml namespace, which has classes to work with the DOM.  If you want speed, then there's a SAX parser available as well.  And, as I mentioned, you can do more with XML than you can with this.  However, it's still not as good as having a proper database (even if your database system is Access) because that's not really what it was intended for.  But it would be an improvement over this.

  • (cs) in reply to JohnO
    JohnO:

    Well, based on some of the responses, it appears that some people actually do not consider this a WTF.  Let me spell it out for you.

    1) Let's pretend for argument's sake that writing saving data as code isn't a bad idea.  At least do it "right" and use an array of a user-defined type.

    Since the storray engine is implicetely Q&D, "doing it right" makes it only worse (still D, but no longer Q).


    2) If any product information changes, it requires editing script code.  With any other reasonable method, updating product information could be done by a chimp.

    As far as I can read from the code, the whole file is rewritten. It is probably never edited in a conventional way, maybe except for Q&D changes.


    3) If your website is worth a damn, you will offer query capability like show me all the hammers you sell, etc..  Implementing query capabilities on 2d arrays is pathetically stupid and a waste of time re-inventing the wheel.

    Simple queries like "all the hammers" that are not especially complex on a 2D string array. I hope they never implement a "show me all your hammers where the same company provides at least 5 types of nails" query feature.


    4) CSV, XML, Jet, Access, MSSQL and VB record I/O are all FREE viable alternatives to the Storrary Engine.


    IMO CSV and XML are nearly as much a WTF for this task than the storray engine. The hard facts (speed, reliability, concurrency etc.) are probably not better. Well, CSV needs less space.


    5) If you weren't writing pathetic, throw away code, your system might have to be maintained (instead of rewritten).  If you use standard techniques and don't overengineer, other people can easily maintain your code.  No one with any sense would do anything but throw away the Storrary Engine.

    How can anyone defend this?  I can think of no set of circumstances under which I would call the Storrary Engine an acceptable solution.  People mention performance and overhead as reasons.  Are you kidding



    It's always easy to say "throw it away, do it right" if you have the budget. Don't get me wrong, the storray engine is not my baby and I don't feel like using it for my next project. But at least it's Q&D, a big advantage compared to many pathetic WTFs which are so large and complex that "throw it away" is something the ties won't accept.
  • (cs) in reply to johnl
    johnl:
    Yeah, ammoq, I did miss the point about what he was doing.  But then, if it's not hand-written, the data obviously comes from somewhere.  I dunno, maybe I'm just missing something but I'd be interested to see how the array that was being passed to that function was actually generated.

    Read the OP.
    STORRAYLIB_SaveArray
    does the job.


    Thing is, a lot of modern languages actually include XML parsing as part of the package.  If you use .NET, it includes the System.Xml namespace, which has classes to work with the DOM.  If you want speed, then there's a SAX parser available as well.  And, as I mentioned, you can do more with XML than you can with this.  However, it's still not as good as having a proper database (even if your database system is Access) because that's not really what it was intended for.  But it would be an improvement over this.

    Honestly, if someone takes this system and translates it to (handwritten) XML I would call it a big big WTF.
    The closest resemblance of the original concept would be to serialize and deserialize the array.
    But as many have pointed out, a lot of free databases is available in the year 2006.

    Jeff S:

    Wow .... can't tell if you are goofing around or serious.   Your comment about MDB files is a good indication of your overall ignorance on this topic, but again, hopefully you are just trolling or having some fun. 

    I didn't mean to say MDB is bad. And yes, playing the WTF's advocate is more funny to me than joining the "oh my eyes" chorus.


  • (cs) in reply to Jeff S
    Jeff S:
    ammoQ:


    Are prolog programs data or code?
    Are Postscript, PDF and WMF data or code?



    Not sure what your point is ... do you write applications in PDF ?



    At least someone wrote an HTTP server in Postscript.

    http://www.au.horde.org/pub/pshttpd/

    So while Postscript files can be considered data (mostly images), they are also programs. To some extend, the same is true for PDF and WMF.
  • wind (unregistered) in reply to Asif Youcare
    Anonymous:
    I can't believe that people are defending this as not so bad.

    The guy could've simply used a flat file and read it into memory at start-up, and changed the contents of that file whenever a data change was required.  Instead, he had the program rewrite itself whenever data changed.

    My god!





    I think written back to itself isn't a really terrible idea if your application write very little but read often. If data only write back when using admin functions and we assume only one admin using at one time, then why we should reject this form of flatfile "database"?

    I just wonder if ASP has caching of compiled code just like PHP so that it can minimize the impact of flatfile?
  • (cs)

    I think I would have to break my rule and join Steve in the bar for that drink.

    Yeah this solution works. However the pride of the creator was too much.

    Here is a clue: there are a number of free SQL databases that you can link to. (The much hyped MySQL is perhaps the worst) Most hosting providers will give you access to one for very little extra change - it doesn't cost them much to provide it, and they can make some money.

    Even if they won't provide a database sqlite is plenty good, and provides all the thread safety you really need in a web app.

    Yes you can do something in code without a database. You can even provide the thread safety (not to mention the rest of ACID) that a database provides. If you are working with a small number of records (like this), your solution probably is faster. However it is faster and easier (for the programmer) to use a database anyway. In today's world programmer time it more expensive than computer time.

    Considering the lack of thread safety, and the small size, it is faster to re-parse this file as needed. However the users will not notice the extra time it takes after you convert to a real database. This will notice the lack of random problems caused by threading issues.

Leave a comment on “The Storray Engine”

Log In or post as a guest

Replying to comment #57582:

« Return to Article