• java.util.WTFException (unregistered) in reply to Monday

    do i smell a belgian?

  • PaulG (unregistered)

    I once had the fun task of maintaining a massive freight management application written in Delphi. By a self taught programmer whose comments were in Italian. Supposedly the guy who took over from me later resigned and became a lumberjack. I still wonder if that career choice had anything to do with the work.

  • (cs) in reply to akatherder
    akatherder:
    Andrew:
    akatherder:
    "Rather than use a database, all non-static information is crammed in thousands of text files scattered across subfolders of subfolders"

    Accessing the file system directly is clearly faster than creating a DB connection and THEN looking for your data. A database is nothing more than a glorified set of files!

    No, SQL database engines are not just "...a glorified set of files!". They organize data in relational tables. They provide logical search abilities: SELECT all relations WHERE these conditions are true.

    Sure, a database is (usually) stored in flat files. Maybe the files don't need SQL, but they must be organized somehow! Look-up the "Berkley DB" flat file database for comparison.

    Go back and read "Rutherford, Price, Atkinson, Strickland, and Associates" from last week. They used the database like "...a glorified set of files!", which was the WTF!

    I understand why you feel that way. You have done nothing wrong. You were just taught a lie. Filesystems are the answer, by explicit design. I am right and the entire industry is wrong. Secure data access via the filesystem is the future of all databasifying.

    The way you've framed that comment seems vaguely familiar....

  • Dutch Ucle (unregistered) in reply to java.util.WTFException
    java.util.WTFException:
    do i smell a belgian?

    Do you deny it?

    Since programming is not a problem that can be solved by getting drunk and shouting, the Dutch are just not suitabl for it :)

  • Joe (unregistered) in reply to GuitaristX
    GuitaristX:
    Publius:
    ... The reason there are 70 "Exit Function" statements: they use it instead of "ElseIf" and "Else" (despite knowing how to use these elsewhere in the code).

    If True Then DoThis Exit Function End If If False Then DoThat Exit Function End If If ... [snip]

    Part of the issue here is VB6's horrid syntax. You don't return values from Functions, you set the Function, as a variable, to the value you want to return, a la:

    Public Function Foo() As String
    Foo = "Hello World"
End Function
    If you want to return out of a conditional or a loop, it requires two lines: one to set the "return" value, and another to bail out of the function. Maintaining VB6 apps in general tends to be painful for reasons like this; the syntax is conducive to poor maintainability.

    Welcome to my Hell. Every time I want to exit a conditional statement with a return value, I have to do the same thing. It's enough to drive anyone batshit insane.

    myFunction = 5 Exit Function

  • NeoMojo (unregistered) in reply to Didiman

    1011001110111111101011000001110011111000011001011100001110101110000011101001101000110010110000011101001110010111010111101001101000

  • NeoMojo (unregistered) in reply to NeoMojo

    sorry, I meant 1011001110111111101010100000111001111100001100101110000111010110100000111010011010001100101010000011101001110010111010111101001101000

  • Chris (unregistered)

    Don't need the table (B64Compare), use ASC() instead.

    Don't need LEFT(), ASC() returns value of first encountered byte.

    Don't need to subtract 64 from byte value, bitwise AND with 63 should be quicker.

    No error checking, though. For shame.

    Public Function B64Length(ByVal strEncoded As String) As Integer
  B64Length = (Asc(strEncoded) And 63) * 64 + _
    (Asc(Right(strEncoded, 1)) And 63)
End Function
  • frmName.a.xl.formulaR1C1 (unregistered)

    Ah .. I see the WTF now, the euro symbol appears on the end of the ascii characters.

    The euros not even in the original 8-bit IBM extended set.

  • MadDog (unregistered) in reply to akatherder

    Unfortunately, I would have to disagree with you on the comparision of database against IO. Firstly, IO is one of the most expensive opertaions in computing. But isn't a database nothing more but a file? Answer is: yes, it is nothing more but a file. BUT it is optimized with indexes and data re-organization which would make data more "intuitive" to be accessed. Also, the accessor would know what's the most optimized way to pull a certain set of information out of a data schema.

    Wanna go for the proof? You can create a database + table and fill in, I don't know, close to 2GB of information. Perform a select against that database and see how much time it takes to return your query.

    Then, try to perform the samething in a 300MB text file.

    PS: If database is just a "glorified set of files", I wander why are they so widely used across enterprises and institutions.

  • NeoMojo (unregistered) in reply to MadDog
    MadDog:
    PS: If database is just a "glorified set of files", I wander why are they so widely used across enterprises and institutions.

    Which would you rather use? A set of files, or a set of glorified files ;)

    Live for the glory.

  • JimM (unregistered) in reply to Buffer Overflow
    Buffer Overflow:
    And is k-own like k-cool (i.e. really old & lame)? Because it sure looks that way...

    it's only a guess (my Dutch being only slightly better than my C++ ;) but I think you're mis-splitting the variable name: Ik is dutch for I, therefore the variable is Ik Own Jou, rather than I Kown Jou.

    Publius:
    Rather than use a database, all non-static information is crammed in thousands of text files scattered across subfolders of subfolders. Their version of "SELECT * FROM" is "DIR *.txt".

    It could just be that the only databases available to them were MS Access and Borland Paradox. I worked for a company once who had only just got SQL Server, and every app I supported was a mish mash of Access, VBA, Delphi and Paradox. I was often tempted to resort to text files for persitent data storage ;)

    Still, it could be worse; one of that company's clients had an IT department that they refused to licence any software they deemed unnecessary. I was asked to write a system for the client to send us updates for a db we maintained on their behalf. Had the client had Access available, it would've been a half day job. As it was, I had to program the damn thing in Word and VBA, with a text file output that we then imported into the db (yes, ideally I'd have done it online in perl or php, but the management wouldn't shell out for the hosting upgrade we'd've needed!). Not surprisingly, I handed in my notice about then!

  • (cs) in reply to akatherder

    Databasifying?

  • Ampersand (unregistered)

    In a (decidedly broken) system I was working with recently, the i18n system included among the possible languages "Sanscrit" and "Volapuk". Not that there were any translations into those laguages, but the system allowed for it.

    Oh well, at least they didn't include "Klingon".

  • Zombie_Hunter (unregistered)
    the rest of the board:
    half the posters:
    someone:
    facetious or humorous comment.
    Totally miss the point of the above comment and go into long winded explanation of the superiority of something other.
    laugh at half the posters for missing the point.
    Questions, class?

    CATPCHA: I'm not telling :P

  • (cs) in reply to Didiman
    Didiman:
    And writing code directly in binaryformat is clearly faster than using all this OO crap, right ?

    Writing the code is slower. Running the code is faster. (assuming your code doesn't do the same crap the OO stuff does)

  • BarfieldMV (unregistered)

    This makes me think about the dutch programmer that once told me that a complete file driven 'database' could perform as well and any other database as long as there wasn't any complicated locking going on.

  • Tom_fun_63 (unregistered) in reply to SomeCoder
    SomeCoder:
    Andrew:
    akatherder:
    "Rather than use a database, all non-static information is crammed in thousands of text files scattered across subfolders of subfolders"

    Accessing the file system directly is clearly faster than creating a DB connection and THEN looking for your data. A database is nothing more than a glorified set of files!

    No, SQL database engines are not just "...a glorified set of files!". They organize data in relational tables. They provide logical search abilities: SELECT all relations WHERE these conditions are true.

    Sure, a database is (usually) stored in flat files. Maybe the files don't need SQL, but they must be organized somehow! Look-up the "Berkley DB" flat file database for comparison.

    Go back and read "Rutherford, Price, Atkinson, Strickland, and Associates" from last week. They used the database like "...a glorified set of files!", which was the WTF!

    CAPTCHA: ludus - I think this this is "thanks" in Latvian?!?

    Sarcasm detector broken? :)

    Looks more like sarcasm tags missing ;-)

  • steve (unregistered)

    TRWTF... these "two lines", numbered for your convenience:

    1 1   Private Const B64Compare = _
2          "@ABCDEFGHIJKLMNOPQRSTUVWXYZ[]^_`abcdefghijklmnopqrstuvwxyz{|}- €"
3 2 1 Public Function B64Length(ByVal strEncoded As String) As Integer
4 3 2     B64Length = (InStr(1, B64Compare, Left(strEncoded, 1)) - 1) _
5                   * 64 + (InStr(1, B64Compare, Right(strEncoded, 1)) - 1)
6 4 3 End Function
    ...6 physical lines ...4 logical lines ...3 executable lines ..."two lines"

    WTF

Leave a comment on “ikownjou”

Log In or post as a guest

Replying to comment #:

Log Out

« Return to Article