I guess that is one way to do it but why?




  • Public Const Datum As Integer = 15
    Public Const Maand As Integer = 16
    Public Const Jaar As Integer = 17

    Public Function Check_Datepart_Validity(Datepart As Integer, sString As String) As Boolean
    ' Check on maximum length performed by MaxLength property of related textboxes

    Dim iLength, iValue, i As Integer
    
    If Datepart = Datum Then
        iLength = 2
        iValue = 31
    ElseIf Datepart = Maand Then
        iLength = 2
        iValue = 12
    Else
        iLength = 4
        iValue = -1
    End If
    
    ' Check for presence of non-numerics
    For i = 1 To iLength
        If IsNumeric(Mid(sString, i, 1)) = False Then
            Check_Datepart_Validity = False
            Exit Function
        End If
    Next i
    
    ' Check maximum value for date & month
    If iValue > 0 Then
        If CInt(sString) > iValue Then
            Check_Datepart_Validity = False
            Exit Function
        End If
    End If
    
    Check_Datepart_Validity = True
    

    End Function



  • Visual Basic? That doesn't have date parse functions that throw exceptions, and 31 days in a month is just right anyway. And checking iValue > 0 and iValue > -1 is not redundant. Perfect code, although he could have made constants out of 31, 12, and -1, of course.



  •  I know I'm beating a dead horse here, but in the words of the immortal prophet, 'Visual Basic sucks my ass'.



  •  That code would be shitty in any language, gentlemen. It's not exactly VB's fault this time.



  • Any computer language with "visual" in its name turns me off immediately, as it seems to indicate that those who released it care more about "purty pictures" than creating stuff that actually works.

     



  • @dtobias said:

    Any computer language with "visual" in its name turns me off immediately, as it seems to indicate that those who released it care more about "purty pictures" than creating stuff that actually works.

    That makes perfect sense.



  • What's with all the VB hate?  As this site proves, bad code can be created in ANY language.  And so can good code.

    So many of the new langauges that have become uber-buzzwords lend themselves to code which is MUCH less easy to debug or even follow.  And in turn lead to greater and greater levels of WTFness. 

    I miss Pascal . . . .



  • @ the original poster,
    First thing I noticed was the lack of variable declaration. I'd tell the coder to always use Option Explicit

    @ the silly VB versus RestOfTheWorld debate,
    No, it's not perfect, but neither is any other language. VB is a reasonably efficient scripting language.



  •  @Medezark said:
    What's with all the VB hate?
    VB is a punishment from the gods, unleashed on mankind for the crime of hubris.  I'm pretty sure this is mentioned in the release notes. @Medezark said:
    As this site proves, bad code can be created in ANY language.  And so can good code.
    This is mostly true, provided we except a class of esoteric languages designed for incomprehensibility.  Still, this is not a point in VB's favor.  Rather, it is an unpoint in VB's disfavor.  checks logic table  Yeah, I think that works.  VB is a bad language because its merits, relative to other languages, are few.@Medezark said:
    So many of the new langauges that have become uber-buzzwords lend themselves to code which is MUCH less easy to debug or even follow.  And in turn lead to greater and greater levels of WTFness. 
      Is this just a vague handwaving that I'm supposed to accept on your word, or can you cite a specific example?  I have no doubt they exist, but I'm not sure what, if anything, that proves.@Medezark said:
    I miss Pascal
    This is a clear sign of brain damage.  While Wirth's languages have a certain clean, structured clarity to them that is appealing, they are also cumbersome, needlessly restrictive, and often run directly counter to what I would consider good code.
     

     



  • @bstorer said:

    While Wirth's languages have a certain clean, structured clarity to them that is appealing, they are also cumbersome, needlessly restrictive, and often run directly counter to what I would consider good code.
     

    Is this just a vague handwaving that I'm supposed to accept on your
    word, or can you cite a specific example?  Though I have no doubt they exist, and I'm sure they prove your entire point.



  • @Kiss me I'm Polish said:

     That code would be shitty in any language, gentlemen. It's not exactly VB's fault this time.

     

    Actually it is. VB accepts currency symbols in a string as being numeric. You need to do something like this to avoid getting a "numeric" string that throws an error when you convert it to an integer.

    And normally I like VB, but "IsNumeric" <> valid number is just wrong.

     



  • Oh, I get it. The WTF is [code]Datepart[/code] not being in Hungarian notation. Like, you know, [code]sString[/code].



  • @dhromed said:

    @bstorer said:

    While Wirth's languages have a certain clean, structured clarity to them that is appealing, they are also cumbersome, needlessly restrictive, and often run directly counter to what I would consider good code.
     

    Is this just a vague handwaving that I'm supposed to accept on your
    word, or can you cite a specific example?  Though I have no doubt they exist, and I'm sure they prove your entire point.

    Oh, there are plenty of examples: Euler, Pascal, and Modula-2, just to name a few.



  • @coentje said:

    I guess that is one way to do it but why?

    Because I can.



  • @bstorer said:

    just to name a few
     

    I was thinking of specific language aspects.



  • @I'd rather kiss a Russian said:

    That code would be shitty in any language, gentlemen. It's not exactly VB's fault this time.

    I explicitly mentioned VIsual Basic, since that has a library for this kind of stuff, allowing you to parse dates in any format, much like Java, of course. So it is certainly not VB's fault, but it apparently once again managed to attract a certain kind of "programmer".



  • @dtobias said:

    Any computer language with "visual" in its name turns me off immediately, as it seems to indicate that those who released it care more about "purty pictures" than creating stuff that actually works.

     

    Because obviously "stuff that actually works" and "stuff that looks pretty" is mutually-exclusive.



  • @Zecc said:

    Oh, I get it. The WTF is <FONT face="Lucida Console" size=2>Datepart</FONT> not being in Hungarian notation. Like, you know, <FONT face="Lucida Console" size=2>sString</FONT>.
    I'd give that a +1, but you didn't specify 'Microsoft Hungarian Notation.'



  • @coentje said:

    Public Const Datum As Integer = 15

    Public Const Maand As Integer = 16

    Public Const Jaar As Integer = 17

    Public Function Check_Datepart_Validity(Datepart As Integer, sString As String) As Boolean

      ' Check on maximum length performed by MaxLength property of related textboxes

    Hmm … looks like this dude is trying to figure out whether three textboxes on a screen comprise a valid date. And yes, that is 100% lousy code, whether or not you love/hate VB/VBS/VBA.




    Tell you what:


    Public Function Check_Datepart_Validity() As Boolean

      Check_Datepart_Validity = IsDate(textboxes(Maand) & " " & textboxes(Datum) & " " & textboxes(Jaar))

    End Function





    (You would have to make the substitution for textboxes, but you get the idea.)



  • @Cad Delworth said:

    IsDate(textboxes(Maand) & " " & textboxes(Datum) & " " & textboxes(Jaar))

    Now there is a WTF .. Month/Day/Year format



  •  And that may be completely wrong... since the UI would appear to be three separate boxes,allowing data entry.

     

    __ __

     

    Now, we begin entering, (say the order is day, month, year). I begin with entering 3 and then tab to the next field. Validation is done. The original code validates 3 as date, and everything is ok. Your code attempts validating "3" as a date, and fails.

    So, the form logic would need changing to only validate upon leaving the triplet (which is nasty, and would be more WTF worthy) OR the application would need changing to have a date entry field // which would be better. BUT, there may be some business case for entering the date as number tab number tab number tab.

     Offhand, I don't know what it is, though. But, if it exists, I can see that:

     

    1 - I don't know if VB supports edit fields. In any case, I don't the syntax, and for quick turn around and easy maintainance I may recommend doing edit validation this way.

    2 - The design allows for "heads down" entry.

    3 - It is easy to find and modify the edit routine for the field. For maintainance, I would probably merge the three edit routines into one as well.

    4 - The wierd feature is that the field length is defined in the edit routine, but is not referenced. I was expecting a Len(sString) somewhere. But it doesn't matter. EI. 0003 is still 3, and a valid day.

    5 - Based on the code snippet presented, your postulated replacement would qualify as a WTF; deploying would entail redesign.

     



  • @Medezark said:

    I miss Pascal . . . .
     

    Why?  It's alive and well and there are plenty of people still using it these days, mostly as Delphi.

     

    @Medezark said:

    As this site proves, bad code can be created in ANY language.  And so can good code.

    Very true.  I've seen good code and bad code in plenty of languages.  But some languages make creating bad code easier, (C and anything descended from it being the obvious examples,) and some, like Pascal, make writing good code easier.  That's probably why the C family keeps evolving to become more and more like Pascal in recent years.



  • @Cad Delworth said:

    @coentje said:
    Public Const Datum As Integer = 15

    Public Const Maand As Integer = 16

    Public Const Jaar As Integer = 17

    Public Function Check_Datepart_Validity(Datepart As Integer, sString As String) As Boolean

      ' Check on maximum length performed by MaxLength property of related textboxes

    Hmm … looks like this dude is trying to figure out whether three textboxes on a screen comprise a valid date. And yes, that is 100% lousy code, whether or not you love/hate VB/VBS/VBA.




    Tell you what:


    Public Function Check_Datepart_Validity() As Boolean

      Check_Datepart_Validity = IsDate(textboxes(Maand) & " " & textboxes(Datum) & " " & textboxes(Jaar))

    End Function





    (You would have to make the substitution for textboxes, but you get the idea.)

    You're assuming that it's not important to know which field caused the error. Also, I don't think he's passing three dateparts at once - just one part at a time, with an indicator as to which type it is. WhyTF he didn't just use the text input boxes to validate numericalness, I don't know. And, for that matter, having done so, why not have three lines:

    If datepart=month

    If sstring > 12

    exit function

    Elseif datepart = day

    If sttring > 31


    etc etc.

    What I really don't understand is how this is better than three separate, simple functions:

    Public Function Check_Day_Validity(sstring) as boolean

    Check_day_validity = false

    If sstring < 13 then

    Check_day_validity = true

    Else



    End function



  • @Mason Wheeler said:

    @Medezark said:

    I miss Pascal . . . .
     

    Why?  It's alive and well and there are plenty of people still using it these days, mostly as Delphi.

     

    @Medezark said:

    As this site proves, bad code can be created in ANY language.  And so can good code.

    Very true.  I've seen good code and bad code in plenty of languages.  But some languages make creating bad code easier, (C and anything descended from it being the obvious examples,) and some, like Pascal, make writing good code easier.  .


    Is making it easy to create shonky (but working) code necessarily a bad thing? A programming language is just a tool for a job. Being evangelistic about the jobs it can do is not the point. Basic variants are designed to be easy to pick up just as much as you need with minimal prior knowledge. If you're a non-programmer who needs to occasionally do a little scripting or data validation, or some such, VB is great. It's easy to learn, and has something much closer to a natural linguistic syntax than most higher-powered languages. It's far easier to read and analyse a snippet of VB that you've grabbed from google but don't understand than it is with most other languages.

    Alternatively, for more advanced programmers who know what they're doing, it's a very quick and simple way to do things in Windows that are otherwise ridiculously complicated in other languages. I doubt anyone except a fanboy would suggest that it's the best tool for any other job - although someone's familiarity with it might make it the best choice for them.



  • @davedavenotdavemaybedave said:

    Is making it easy to create shonky (but working) code necessarily a bad thing?
    Yes.



    'Shonky' code ends up being used because the model itself ends up getting tweaked/refined to do what's needed rather than a new program being written (in a better/faster/more appropriate language) from scratch.



  • @PJH said:

    'Shonky' code ends up being used because the model itself ends up getting tweaked/refined to do what's needed rather than a new program being written (in a better/faster/more appropriate language) from scratch.




    Not sure if you realise, but not everyone has a programmer on call.



    I think of VB like the toolkit I keep in my car. That toolkit is basically junk. It cost me a fiver from the supermarket - although that was actually cheap for what it has. There's a small socket set, pliers, hammer, screwdrivers, adjustable spanner, and so on. Still, it's junk. The tools are made of soft metal to low tolerances. I don't do enough work on the car to justify buying a set of good tools for it - hundreds of pounds worth - but if I break down on the road somewhere, I'll have something I can use at a pinch to get a working repair done. If there are big jobs that need doing, I take it to a mechanic, who has all the appropriate tools and the knowledge and experience to wield them.



    VB plays a very similar role in my working life. If I have a major job to do, that goes to a programmer - once it's been agreed, quoted, okayed, and so-on - but if I have something minor to do, I can bodge something up that'll do the job I want done and save me a few minutes.



    The last thing I wrote used VBA in Excel to automate a repetitive copy-paste-transpose task. The task is done a few times a day - maybe a dozen or so. It saves me thirty seconds each time I use my little macro. My time's not valuable enough for it to be worth paying a programmer to sort out a good solution. Mine took me half an hour (including re-learning the VBA I hadn't used in a while). It doesn't work perfectly, but it does the job correctly. As it happens, it takes nearly two seconds to run, which seems too long. I could look into it, but at most I'd save two seconds each time I used it, so I can't justify the time.



    It's a tool for a job, nothing more. If it's not the right tool for the job you want to do, that doesn't make it a bad tool: it makes it the wrong tool.



  • @OzPeter said:

    Now there is a WTF .. Month/Day/Year format




    Actually, it's "mm dd yyyy" format. Using that specific syntax for the date string in a VBScript IsDate statement prevents VBS misinterpreting the order of the day and month.



    [FX: shrug] Take it up with MS: for some reason, they decided IsDate in VBS should be able to parse something like 11 different formats of string (I forget the exact number) and then return a True/False. It hadn't escaped me that the original snippet appears to have variable names in Dutch, so my replacement attempted to provide something that worked regardless of Regional Setting. Speaking as a UK programmer, the M/D/Y date format gets up my nose as well … but as some of our customers in one job were in the UK and the USA, I got used to writing region-independent date handling code.



    And yes, as others have said, I'm assuming a lot, and also that it doesn't matter which of the three D/M/Y TextBoves is invalid. But (again making an assumption here) it looks like it's either from a VBScript on an ASP page, or it's some kind of global validation function from an Office 'document,' most likely an Access database Form. Either way, yes there are three boxes which together form a date: IME most users ARE capable of spotting that their entered date is wrong without needing to know WHICH of the three date parts is wrong. …but personally, I would just make the date into one field unless there's some weird reason why it has to be entered in three parts (any guesses?).



    Give VB/VBA/VBS a Date, and all three are capable of giving you the three components of it (D/M/Y). So I guess there must be some other reason for using three fields in the first place? Oh wait: I get it now! It's so the app. can tell the user WHICH part of the date is wrong!



    Hmm … this is where I came in. I'll get me coat!



  • @bstorer said:

    VB is a bad language because its merits, relative to other languages, are few.

    One of its merits, however, is that from v5.0 on, I think, it has been designed with microsoft's (back then halfway new) COM infrastructure in mind. I think it's still one of the easiest languages to access COM components in or to write your own.

    @bstorer said:
    @Medezark said:
    So many of the new langauges that have become uber-buzzwords lend themselves to code which is MUCH less easy to debug or even follow.  And in turn lead to greater and greater levels of WTFness. 
      Is this just a vague handwaving that I'm supposed to accept on your word, or can you cite a specific example?  I have no doubt they exist, but I'm not sure what, if anything, that proves.
     
    Examples? Like PHP and Java/ECMAScript that make a reliable code completion and many other common-courtesy IDE features conceptually impossible, because (among other things) the number and names of declared variables depend on runtime conditions?
     
    Like Ruby, where every callback can potentially terminate half of your program unless you litter everything with finally statements?
     
    Or like the ol' HTML/JS/CSS trio that is so littered with incompatible concepts, loopholes and hacks that kludgy programming isn't just a trivial offense, it's necessary to get things done?

    But what amazes me most are that they are now hyped as the "next step of evolution in the usage of computers". WTF?
     
    @Medezark said:
    I miss Pascal
    ...alright, I've got nothing to say to this.



  • ..... managed to attract a certain kind of "programmer"

    I program in VB all the time.
    I like it, and it puts bread on the table.
    You will thank me in the future for page after page of Grade A wtf postings of my code, but those WTFs will all be HTML/Java related. My VB code will be WTF free. Mostly.

    Then again, my group does have some of THOSE programmers. I spend about four hours a week re-writing queries and stored procedures for them. (no, not in VB)



  • @PSWorx said:

    Like PHP and Java/ECMAScript that make a reliable code completion and many other common-courtesy IDE features conceptually impossible, because (among other things) the number and names of declared variables depend on runtime conditions?
     

    Call me a dufus if you want, but I think Javascript's ability to rewrite its own code at runtime is its best feature. I use it all the freakin' time on client websites.

    For example, if I'm writing a JS that has to trap errors, but the website only reports errors in the form of alert(), then I have two options:

    1) Completely re-write their error-checking code into an identical version and serve that alongside my script

    2) Create a new function metaAlert(), then write about 3 lines of code to dive into their error-checking function and replace references to alert() with metaAlert().

    Option 2 is a heck of a lot less code, time, and testing, it's nearly 100% reliable, and it's impossible to do in most other languages.

    Anyway, even C has places where "the number of declared variables depend on runtime conditions". For example, the printf() family of functions.



  • @blakeyrat said:

    Anyway, even C has places where "the number of declared variables depend on runtime conditions". For example, the printf() family of functions.
     

    There's a huge difference between "has places where" and "standard behavior."



  • @davedavenotdavemaybedave said:

    @PJH said:
    'Shonky' code ends up being used because the model itself
    ends up getting tweaked/refined to do what's needed rather than a new program
    being written (in a better/faster/more appropriate language) from
    scratch.


    Not sure if you realise, but not everyone has a
    programmer on call.
    Wot? If you want programs written, you want a programmer writing them. And I think you're missing the context here. Regardless..

    @davedavenotdavemaybedave said:
    I think of VB like the toolkit I keep in my car. That toolkit is basically junk.
    It cost me a fiver from the supermarket - although that was actually cheap for
    what it has. There's a small socket set, pliers, hammer, screwdrivers,
    adjustable spanner, and so on. Still, it's junk. The tools are made of soft
    metal to low tolerances. I don't do enough work on the car to justify buying a
    set of good tools for it - hundreds of pounds worth - but if I break down on the
    road somewhere, I'll have something I can use at a pinch to get a working repair
    done. If there are big jobs that need doing, I take it to a mechanic, who has
    all the appropriate tools and the knowledge and experience to wield them.
    Your analogy is wrong. Assume it is the mechanic that has bought the cheap toolkit and is working on your car, instead of buying the proper tools to begin with, and you may then have a closer analogy.
    @davedavenotdavemaybedave said:
    The last thing I wrote used VBA in Excel to automate a repetitive
    copy-paste-transpose task. The task is done a few times a day - maybe a dozen or
    so.
    Again, you miss the context. This isn't about time-saving stuff for the occasional person, it's "we produced this prototype for the customer in VB, they loved it so much they want to use the prototype" when the program concerned should, in reality, be written in a different language (and probably by a different person.)


    And in your copy/paste/I can't be bothered script, could the task even be written in any other language to begin with? What would a person using OpenOffice do? Should the task be done in (I'm assuming) Excel to begin with? Or is that just a convenient UI to use on the data?



  • @Mason Wheeler said:

    @blakeyrat said:

    Anyway, even C has places where "the number of declared variables depend on runtime conditions". For example, the printf() family of functions.
     

    There's a huge difference between "has places where" and "standard behavior."

     

    Yah, well, I still like Javascript.

    What it really comes down to is I've written code in PASCAL, C, C++, Hypertalk, BASICs of various flavors, Javascript, VBScript, VBA, Lua, some Obj-C, and C#. Right now, with what I know of all those languages, I'd much, much rather use Javascript or C# than anything else in the market.

    Your welcome to hate me if you want. But I'm not going to decree that Javascript is an inherantly inferior language because it contains a few features you don't like. 

    I'm a pragmatist, and Javascript and C# just fucking work, quicker, easier, faster, and more bug-free than the alternatives.



  • @PJH said:


    @davedavenotdavemaybedave said:
    I think of VB like the toolkit I keep in my car. That toolkit is basically junk.
    It cost me a fiver from the supermarket - although that was actually cheap for
    what it has. There's a small socket set, pliers, hammer, screwdrivers,
    adjustable spanner, and so on. Still, it's junk. The tools are made of soft
    metal to low tolerances. I don't do enough work on the car to justify buying a
    set of good tools for it - hundreds of pounds worth - but if I break down on the
    road somewhere, I'll have something I can use at a pinch to get a working repair
    done. If there are big jobs that need doing, I take it to a mechanic, who has
    all the appropriate tools and the knowledge and experience to wield them.
    Your analogy is wrong. .....
     

     

    TRWTF is analogys.. god i hate them, They are made up for people who do not understand to still not understand



  • @blakeyrat said:

    What it really comes down to is I've written code in PASCAL, C, C++, Hypertalk, BASICs of various flavors, Javascript, VBScript, VBA, Lua, some Obj-C, and C#. Right now, with what I know of all those languages, I'd much, much rather use Javascript or C# than anything else in the market.

    Agreed.  I think Javascript's dynanism is a major strength and I love the language.  From a practical standpoint, I hate JS, but only because of browser incompatibilities, the fact that DOM is a piece of shit and the lack of multi-threading support (which would be nice when you're building, you know, event-driven user interfaces).  But for a scripting language, it's got many strengths.  I'm not saying it's the solution for every (or even most) problems, but it's good at some things.  People who hate or are terrified of dynamic languages piss me off.  Look, asshole, you're writing some fucking business logic to take information from forms, massage it and put it into a database and then display pretty graphs for the idiots upstairs.  You're not writing the critical targeting code for cruise missiles, your code doesn't need to be reducible to a mathematical proof, so the fact that your tool has the flexibility to modify itself is a bonus because it saves you time.



  • PJH>

    To expand on my earlier example, I must have a dozen or so little bits of code doing things like that for me. If I hadn't slapped them together quickly in VB, no-one would have 'written them properly'. I'd still be doing the jobs manually.

    I'm not quite sure what you're saying except that either you believe that in a situation where perfect code can't be justified, one should do everything manually - a beautiful, if impractical idea - or just that you're being somewhat intransigent in refusing to accept that a tool may be inappropriate for professional use precisely because it's not designed for professional use. But then, if geeks didn't have Aspergers, we wouldn't have the sanitation, the medicine, education, wine, public order, irrigation, roads, the fresh-water system, and public health - or something.

    P.S. Can't believe I thought a bit of 'it's just a tool for a job' would calm the argument down...



  • @blakeyrat said:

    Call me a dufus if you want, but I
    think Javascript's ability to rewrite its own code at runtime is its
    best feature. I use it all the freakin' time on client websites.

    For
    example, if I'm writing a JS that has to trap errors, but the website
    only reports errors in the form of alert(), then I have two options:

    1)
    Completely re-write their error-checking code into an identical version
    and serve that alongside my script

    2) Create a new function
    metaAlert(), then write about 3 lines of code to dive into their
    error-checking function and replace references to alert() with
    metaAlert().

    Option 2 is a heck of a lot less code, time, and
    testing, it's nearly 100% reliable, and it's impossible to do in most
    other languages.

     

    Just to clarify, my rant was
    directed at JS' "every object is a dictionary" approach, not at the way
    it treats functions as first-class object. The latter is absolutely
    awesome and I agree with you that the abillity to hook/replace functions
    at runtime is one of its most useful abillities.

    @morbiuswilters said:

    But for a scripting language, it's got many strengths.  I'm not saying it's the solution for every (or even most) problems, but it's good at some things.  People who hate or are terrified of dynamic languages piss me off.  Look, asshole, you're writing some fucking business logic to take information from forms, massage it and put it into a database and then display pretty graphs for the idiots upstairs.  You're not writing the critical targeting code for cruise missiles, your code doesn't need to be reducible to a mathematical proof, so the fact that your tool has the flexibility to modify itself is a bonus because it saves you time.

    I'm not interested in mathematical proofs, either, but I'm usually very lazy and I'm a huge fan of intellisense and code completion. (And, yes, I know, that's another debate notorious for its flame-fests.) If I can just hit CTRL+Space and get a list of all class members of the object I'm currently paying attention to, I personally can get things done much more quickly than if I have to memorize each method name (or look it up in the dokumentation) and type it out again every time.

    I know there are editors that try the same with JS and the like. But those usually do little more than display fixed lists when you type "window." or "document." and become completely useless once you try to work in a non-DOM environment or use one of the more recent JS frameworks.

    Same goes for other IDE features like reference searching or refactoring. If I need to find all calls to a certain method in java code, I can just do a reference search. In JS, thanks to eval(), dictionaries and friends, I couldn't even be sure I got everything if I did a text search.

    I agree on the other hand, that most statically typed languages are unnecessarily complicated and make it hard to get things done quickly. Java with its "need a struct with two members? sure, make a new compilation unit!" approach takes the cake here. But I think there are newer languages, like Schala, which try to fix those things. (Took them long enough to ackgnowledge them in the first place, no objections here.)

    Summing up (in order of ease of development): Static language with a text editor < Dynamic language with a text editor < Dynamic language with a good IDE < Static language with a good IDE.



  • @morbiuswilters said:

    lack of multi-threading support
     

     Try to shoot off some functions with setTimeout() or setInterval(). These are executed separately from the main javascript thread. I haven't done any testing to see if they're usable to factually achieve or at least simulate threads, but I'm sure you're better equipped* to perform that experiment.

    @PSWorx said:

    thanks to eval(),
     

    eval() is a blight and must be destroyed with FIRE FIRE FIRE FIIREEEERRREE BURN BURN BURNNNN

     

    (I'm sorry, I was once traumatized by overseas code that utilitized it)

     

    😉 because of your bloated enormous, virulent virile, pustulent proud dick, obviously.



  • @dhromed said:

    Try to shoot off some functions with setTimeout() or setInterval(). These are executed separately from the main javascript thread.
     

    Two slight issues:

    1) Those are DOM functions, not part of Javascript-proper. About the only part of DOM that doesn't suck.

    2) You're wrong

    The code in setTimeout/setInterval won't run unless the main thread is done executing.



  • Some light testing blew that dream out of the water, yea.



  • @blakeyrat said:

    The code in setTimeout/setInterval won't run unless the main thread is done executing.
     

    Given the lack of synchronisation support (semaphores, lock objects etc.) in the language, it's a good thing. Multithreading without proper synchronisation is the way to race-condition hell.



  • @ammoQ said:

    @blakeyrat said:

    The code in setTimeout/setInterval won't run unless the main thread is done executing.
     

    Given the lack of synchronisation support (semaphores, lock objects etc.) in the language, it's a good thing. Multithreading without proper synchronisation is the way to race-condition hell.

    Obviously.  My complaint was about the lack of multi-threading in general (including synchronization methods) not just about the inability to create arbitrary threads.



  • @dhromed said:

    Some light testing blew that dream out of the water, yea.

    Every browser I know of runs JS in a single thread.  In fact, it's often a single thread across all windows, which is why a single script on one page can bring the browser to a crawl.  It's also often the same thread that does rendering, parsing, etc. which is why an HTML-heavy page can cause other browser windows to become unusable.  I've tried all kinds of tricks to "fake" multi-threading, like using a pop-up window or a frame for "heavy processing" with the foreground window just handling UI (so things are responsive).  This does not work due to the single-threaded nature of browsers.



  • @morbiuswilters said:

    js thread recap
     

    What aboot Chrome or Opera with their advanced and odd (respectively) engines?

    Opera had some especially interesting behaviour when I used CANVAS to draw a big fucking bifurcation diagram. All the other browsers would spin and lock until done and then display the whole beautiful thing suddenly, but Opera was the only who'd update the canvas tag's canvas with each iteration (or as real-time as possible, anyway) as the script was running. This was a few years ago.



  •  snort

    I realized I still had it online: http://pliv.com/show/bifurcate/

    I used to have to wait seconds upon seconds for it to finish.

    It renders in 0.6 seconds in Chrome now.



  • @dhromed said:

    @morbiuswilters said:

    js thread recap
     

    What aboot Chrome or Opera with their advanced and odd (respectively) engines?

    Opera had some especially interesting behaviour when I used CANVAS to draw a big fucking bifurcation diagram. All the other browsers would spin and lock until done and then display the whole beautiful thing suddenly, but Opera was the only who'd update the canvas tag's canvas with each iteration (or as real-time as possible, anyway) as the script was running. This was a few years ago.

     

    What about them?

    Whether or not Javascript is multi-threaded (it's not, that would break sites) has absolutely nothing to do with whether or nor the DOM is updated in real-time or all-at-once when the JS is finished.

    The terrible secret of space here is that, while all the browsers are penis-measuring with the speed of their Javascript engines, DOM is actually pretty damned slow in almost all of them. Since JS doesn't really do anything except update the DOM, that's where the performance work should be focused. But... Javascript performance is easier to measure. 🙂

    Should also mention that browsers with process isolation (at the moment, just IE8 and Chrome I believe) use a different thread for each browser window by necessity. Still could cause compatibility issues, and ramps up the inter-process communication, when you have something like a pop-up window being remote-controlled from a browser window, but that case is pretty rare nowadays.


Log in to reply
 

Looks like your connection to What the Daily WTF? was lost, please wait while we try to reconnect.