Insult to injury...



  • Don't you love it when you see a stack trace that looks like:

    at Company.Product.Namespace.Class.Method(SomeType arg) in C:\path\to\some\wtf\source.vb:line 6912

    And then upon inspection, line 6912 (in context) looks like:

    6911:  Catch ex as Exception
    6912:    Throw ex
    6913:  End Try

    Makes you want to just jump up and kiss the person who wrote it...



  • @djork said:

    Makes you want to just jump up and kill the person who wrote it...

    Fixed. 



  • Unfortunately, there are reason's for doing this.

    http://bartdesmet.net/blogs/bart/archive/2006/03/12/3815.aspx

     

     



  • Of course, they are all bad.



  • That's when the program throws up the exception.



  • @clively said:

    Unfortunately, there are reason's for doing this.

    http://bartdesmet.net/blogs/bart/archive/2006/03/12/3815.aspx

     

     

    That article is utterly worthless. First, it outlines exactly why what is going on here is stupid. Secondly, it shows you how to re-throw exceptions in a not-completely-retarded way... which is still fundamentally retarded. Thanks.

    Unless, that is, you can actually give me a good reason to re-throw here.

    P.S. It is just "reasons"



  • @djork said:

    Don't you love it when you see a stack trace that looks like:

    at Company.Product.Namespace.Class.Method(SomeType arg) in C:\path\to\some\wtf\source.vb:line 6912

    And then upon inspection, line 6912 (in context) looks like:

    6911:  Catch ex as Exception
    6912:    Throw ex
    6913:  End Try

    Makes you want to just jump up and kiss the person who wrote it...

    This is so common it's about time it was fixed in the language by specifying that a re-thrown exception should accumulate stack trace instead of wiping it out and starting again.  Surely it couldn't be that hard to do in a backward-compatible way?

     



  • @djork said:

    @clively said:

    Unfortunately, there are reason's for doing this.

    http://bartdesmet.net/blogs/bart/archive/2006/03/12/3815.aspx

     

    That article is utterly worthless. First, it outlines exactly why what is going on here is stupid. Secondly, it shows you how to re-throw exceptions in a not-completely-retarded way... which is still fundamentally retarded. Thanks.

    Unless, that is, you can actually give me a good reason to re-throw here.

    P.S. It is just "reasons"

    try
    {
      Oops();
    }
    catch (ExpectedException ex)
    {
      HandleExpectedException(ex);
    }
    catch (Exception ex)
    {
      Log.Write(ex.GetType().Name, ex.Message, ex.StackTrace);
      throw;
    }
    

    This is something you'll often encounter in a lower-level abstraction layer, especially in a web application.  You've already handled all of the exceptions which "normally" occur, and an uncaught exception means that there's a bug.  The UI decides how to actually handle the exception, but often the UI will try to do something "friendly" with it, like displaying "There was an unexpected error, please call our Customer Service department".  In order to debug the problem later, you need some information on what actually happened, so you intercept the exception early, log it somewhere in case you need it for debugging, then pass it on to whoever should care.

    The article from Bart is a technical article discussing how throw works with the stack, and people here seem to have completely missed its point.  He's not suggesting that you should simply catch and rethrow exceptions without taking any other action; he's saying that "throw ex" is technically not a rethrow.  If you throw [I]something[/I], then the stack trace begins at the throw itself.  If you simply [I]throw[/I], then the stack trace begins at where the original exception originated.  There are reasons for both approaches, neither of which are "fundamentally retarded".  If your exception originated deep in the bowels of some sooper-seekrit security doohickey, you might not want that entire stack trace making its way to the UI.  Although, I will point out that the most appropriate thing to do in those cases is usually wrap the exception in something more meaningful (like, say, SecurityException in this example).

    If I see exception-handling code that does nothing [I]but[/I] rethrow it, then it's probably a mistake made by someone who didn't understand the stack implications, or maybe even didn't understand exception handling at all.  The article is not worthless, however, because he points out specifically that he's not discussing where or when you should rethrow, just the different flavours of "throw" and how they differ.

    Let me ask you this; if there's never any good reason to rethrow, then why would C# even have the parameterless "throw" statement? 



  • @DaveK said:

    This is so common it's about time it was fixed in the language by specifying that a re-thrown exception should accumulate stack trace instead of wiping it out and starting again.  Surely it couldn't be that hard to do in a backward-compatible way? 

    It's a common error, sure, but how do you propose they "fix" it?  How is the language supposed to tell the difference between [code]throw ex[/code] and [code]throw new ArgumentNullException("data")[/code]?

    The "throw" keyword is just looking for an instance of Exception as an argument.  It doesn't care whether the exception is "new" or not.  This is fundamental to the C# language (and most languages in fact); arguments are evaluated [I]before[/I] a statement or operator is executed.  The parameterless [I]throw[/I] statement IS the "fix", it performs all of the special processing required in order to preserve the stack.

    If Microsoft "fixed" this the way you want it, then ordinary exception-wrapping code would fail.  They definitely aren't going to issue a lang update that breaks 90% of production code.

     



  • @djork said:

    Don't you love it when you see a stack trace that looks like:

    at Company.Product.Namespace.Class.Method(SomeType arg) in C:\path\to\some\wtf\source.vb:line 6912

    And then upon inspection, line 6912 (in context) looks like:

    6911:  Catch ex as Exception
    6912:    Throw ex
    6913:  End Try

    Makes you want to just jump up and kiss the person who wrote it...

    I would still put it one step above:

    try {
    ...do something...
    } catch(Exception e) {
    // todo: log the exception
    }

    Yes, the comment was in the code.  During a team meeting I literally threatened to beat people for such an offense soon after finding this.



  • @dphunct said:

    @djork said:

    Don't you love it when you see a stack trace that looks like:

    at Company.Product.Namespace.Class.Method(SomeType arg) in C:\path\to\some\wtf\source.vb:line 6912

    And then upon inspection, line 6912 (in context) looks like:

    6911:  Catch ex as Exception
    6912:    Throw ex
    6913:  End Try

    Makes you want to just jump up and kiss the person who wrote it...

    I would still put it one step above:

    try {
    ...do something...
    } catch(Exception e) {
    // todo: log the exception
    }

    Yes, the comment was in the code.  During a team meeting I literally threatened to beat people for such an offense soon after finding this.

    Well the beautiful thing is that we get "Throw ex" if we're lucky, and half the time the exception is just swallowed by an empty catch block.



  • @Aaron said:

    @DaveK said:

    This is so common it's about time it was fixed in the language by specifying that a re-thrown exception should accumulate stack trace instead of wiping it out and starting again.  Surely it couldn't be that hard to do in a backward-compatible way? 

    It's a common error, sure, but how do you propose they "fix" it?  How is the language supposed to tell the difference between [code]throw ex[/code] and [code]throw new ArgumentNullException("data")[/code]?

    Perhaps it could note that the token "ex" is the same token that was declared as the incoming exception?



  • @Suutar said:

    @Aaron said:
    @DaveK said:

    This is so common it's about time it was fixed in the language by specifying that a re-thrown exception should accumulate stack trace instead of wiping it out and starting again.  Surely it couldn't be that hard to do in a backward-compatible way? 

    It's a common error, sure, but how do you propose they "fix" it?  How is the language supposed to tell the difference between [code]throw ex[/code] and [code]throw new ArgumentNullException("data")[/code]?

    Perhaps it could note that the token "ex" is the same token that was declared as the incoming exception?

    And if it's not, it should assign the incoming exception to the InnerException of the one being thrown. 



  • @Aaron said:

    You've already handled all of the exceptions which "normally" occur, and an uncaught exception means that there's a bug.  The UI decides how to actually handle the exception, but often the UI will try to do something "friendly" with it, like displaying "There was an unexpected error, please call our Customer Service department".

    Adobe does things like that a lot, and it's real damn handy. I prefer that it tells me that it wet its pants, and give me a chance to save my work, rather than crashing and disappearing and letting Windows clean up the mess. 



  • @Random832 said:

    @Suutar said:
    @Aaron said:
    @DaveK said:

    This is so common it's about time it was fixed in the language by specifying that a re-thrown exception should accumulate stack trace instead of wiping it out and starting again.  Surely it couldn't be that hard to do in a backward-compatible way? 

    It's a common error, sure, but how do you propose they "fix" it?  How is the language supposed to tell the difference between [code]throw ex[/code] and [code]throw new ArgumentNullException("data")[/code]?

    Perhaps it could note that the token "ex" is the same token that was declared as the incoming exception?

    And if it's not, it should assign the incoming exception to the InnerException of the one being thrown. 


    Ah, but that would break backwards compatability, wouldn't it?



  • @Aaron said:

    Let me ask you this; if there's never any good reason to rethrow, then why would C# even have the parameterless "throw" statement? 

    The rest of your post wasn't completely out of the tree, but this bit was. Just because C# has something doesn't mean that it's not a really really stupid idea to use it. The primary design goal of C# was not to be a good language, but to appeal to really stupid people (the largest market share). It's all about winning over the brillant Java and PHP developers, and converting them to follow Microsoft.

    C# isn't an actively bad language (like, say, VB6) but neither is it a shining example of a good one. 



  • @asuffield said:

    @Aaron said:

    Let me ask you this; if there's never any good reason to rethrow, then why would C# even have the parameterless "throw" statement? 

    The rest of your post wasn't completely out of the tree, but this bit was. Just because C# has something doesn't mean that it's not a really really stupid idea to use it. The primary design goal of C# was not to be a good language, but to appeal to really stupid people (the largest market share). It's all about winning over the brillant Java and PHP developers, and converting them to follow Microsoft.

    C# isn't an actively bad language (like, say, VB6) but neither is it a shining example of a good one. 

    Wow, an anti-Microsoft post from asuffield. Better frame it and put it on the wall.

     



  • An apostrophe does not mean, "Look out! Here comes an S!"



  • @asuffield said:

    @Aaron said:

    Let me ask you this; if there's never any good reason to rethrow, then why would C# even have the parameterless "throw" statement? 

    The rest of your post wasn't completely out of the tree, but this bit was. Just because C# has something doesn't mean that it's not a really really stupid idea to use it. The primary design goal of C# was not to be a good language, but to appeal to really stupid people (the largest market share). It's all about winning over the brillant Java and PHP developers, and converting them to follow Microsoft.

    C# isn't an actively bad language (like, say, VB6) but neither is it a shining example of a good one. 

    Just out of morbid curiosity, what exactly is a good programming language to you?



  • @Sunstorm said:

    @asuffield said:
    @Aaron said:

    Let me ask you this; if there's never any good reason to rethrow, then why would C# even have the parameterless "throw" statement? 

    The rest of your post wasn't completely out of the tree, but this bit was. Just because C# has something doesn't mean that it's not a really really stupid idea to use it. The primary design goal of C# was not to be a good language, but to appeal to really stupid people (the largest market share). It's all about winning over the brillant Java and PHP developers, and converting them to follow Microsoft.

    C# isn't an actively bad language (like, say, VB6) but neither is it a shining example of a good one. 

    Just out of morbid curiosity, what exactly is a good programming language to you?

    There aren't currently any major languages without significant issues, but on the good end you'll find Haskell, Ruby, various members of the ML family, and hopefully soon Perl 6. 



  • @Quinnum said:

    @asuffield said:
    @Aaron said:

    Let me ask you this; if there's never any good reason to rethrow, then why would C# even have the parameterless "throw" statement? 

    The rest of your post wasn't completely out of the tree, but this bit was. Just because C# has something doesn't mean that it's not a really really stupid idea to use it. The primary design goal of C# was not to be a good language, but to appeal to really stupid people (the largest market share). It's all about winning over the brillant Java and PHP developers, and converting them to follow Microsoft.

    C# isn't an actively bad language (like, say, VB6) but neither is it a shining example of a good one. 

    Wow, an anti-Microsoft post from asuffield.

    How curious that you choose to interpret it that way, but that says more about your own preconceptions than anything else. 



  • @asuffield said:

    C# isn't an actively bad language (like, say, VB6) but neither is it a shining example of a good one. 

    IMO, "Good" and "bad" mostly depends on the purpose. For many tasks, VB6 was just the right tool.



  • @asuffield said:

    @Sunstorm said:
    @asuffield said:
    @Aaron said:

    Let me ask you this; if there's never any good reason to rethrow, then why would C# even have the parameterless "throw" statement? 

    The rest of your post wasn't completely out of the tree, but this bit was. Just because C# has something doesn't mean that it's not a really really stupid idea to use it. The primary design goal of C# was not to be a good language, but to appeal to really stupid people (the largest market share). It's all about winning over the brillant Java and PHP developers, and converting them to follow Microsoft.

    C# isn't an actively bad language (like, say, VB6) but neither is it a shining example of a good one. 

    Just out of morbid curiosity, what exactly is a good programming language to you?

    There aren't currently any major languages without significant issues, but on the good end you'll find Haskell, Ruby, various members of the ML family, and hopefully soon Perl 6. 

    Perl?  PERL?  The language with automatic obfuscation (i.e. the language itself)?!?!?



  • @Kyanar said:

    @asuffield said:

    There aren't currently any major languages without significant issues, but on the good end you'll find Haskell, Ruby, various members of the ML family, and hopefully soon Perl 6. 

    Perl?  PERL?  The language with automatic obfuscation (i.e. the language itself)?!?!?

    No.  He said Perl 6.  The Ur Language.  It's been in development since 2000.  It's a complete not-backwards-compatible rewrite of Perl.   It's supposed to be a complete ground-up rethinking of Perl (as in, the what have we learned in the last 20 years of Perl? is the central thought on development). 

    It could be the holy grail, or it could be the holy grail of IOCCC wannabes. 

    EDIT: I haven't tried it yet, but there are development builds.  I don't have time to mess around with it.   



  • @asuffield said:

    @Aaron said:

    Let me ask you this; if there's never any good reason to rethrow, then why would C# even have the parameterless "throw" statement? 

    The rest of your post wasn't completely out of the tree, but this bit was. Just because C# has something doesn't mean that it's not a really really stupid idea to use it. The primary design goal of C# was not to be a good language, but to appeal to really stupid people (the largest market share). It's all about winning over the brillant Java and PHP developers, and converting them to follow Microsoft.

    C# isn't an actively bad language (like, say, VB6) but neither is it a shining example of a good one. 

    Speaking as an ex-Microsoft bashing, Java afficionado, I think they have done a pretty good job with C#. Software development can be very time consuming without good tools, and C# manages to be both powerful and easy to use (and thats a difficult thing to do). With C# I can get things done in a lot less time than I would need with almost any other language - and time is money.



  • There aren't currently any major languages without significant issues, but on the good end you'll find Haskell, Ruby, various members of the ML family, and hopefully soon Perl 6.

    Again, out of curiosity, what kind of development do you do with these? I can't imagine them being useful in any way in applications that aren't either scientific, math-based, or for students. I'd go insane trying to build anything for corporate work in any of those.



  • @Sunstorm said:

    There aren't currently any major languages without significant issues,
    but on the good end you'll find Haskell, Ruby, various members of the
    ML family, and hopefully soon Perl 6.

    Again, out of curiosity, what kind of development do you do with these? I can't imagine them being useful in any way in applications that aren't either scientific, math-based, or for students. I'd go insane trying to build anything for corporate work in any of those.

    If you're in charge of the servers, you had better use the best language you can get away with. If you're an employee/contractor and you're tied to whatever they are already using then of course you won't be able to use Haskell or (probably not) Ruby. That doesn't mean, however, that you can't build tools in less-mainstream languages for your own use (initially). If you build them well enough then they could catch on and the language might gain a foothold in that space.

    PHBs choose Blub* because they think it's well marketed and because there are tons of programmers out there to fill the chairs.

    * [i]Blub was C++, now it's Java/C#[/i]



  • @Sunstorm said:

    There aren't currently any major languages without significant issues,
    but on the good end you'll find Haskell, Ruby, various members of the
    ML family, and hopefully soon Perl 6.

    Again, out of curiosity, what kind of development do you do with these? I can't imagine them being useful in any way in applications that aren't either scientific, math-based, or for students. I'd go insane trying to build anything for corporate work in any of those.

    Try Ruby on Rails



  • @Sunstorm said:

    There aren't currently any major languages without significant issues,
    but on the good end you'll find Haskell, Ruby, various members of the
    ML family, and hopefully soon Perl 6.

    Again, out of curiosity, what kind of development do you do with these? I can't imagine them being useful in any way in applications that aren't either scientific, math-based, or for students. I'd go insane trying to build anything for corporate work in any of those.

    Haskell's serious issue is that its IO mechanism sucks utterly, so sadly it can be used for very few applications.

    Ruby can be used for just about anything that doesn't need to be fast or large (the next version will be significantly quicker, but it's never going to seriously compete with C). The biggest problem there is the lack of type checking capabilities - you wouldn't want to use it for a project involving many people. It makes a good choice for small projects if you aren't fluent in Perl.

    Most ML variants are good enough to be used for anything. The only reason they aren't much used is because not many people know ML.

    Perl is routinely used for serious practical work all the time, so it's reasonable to expect that Perl 6 will be (probably more so, since it'll be much faster and have a real type system).



  • Any of those allow (and make it relatively easy) to make windows forms?



  • @Sunstorm said:

    Any of those allow (and make it relatively easy) to make windows forms?

    Visual Studio makes it easy to make Windows Forms. :) 

    Does that still relate to the original point of you finding out what asuffield considers a good language? Because I sense that you two have different definitions of "good language".



  • @djork said:

    @clively said:

    Unfortunately, there are reason's for doing this.

    http://bartdesmet.net/blogs/bart/archive/2006/03/12/3815.aspx

    P.S. It is just "reasons"

    Failure in editing...



  • I'm intrigued by asuffield saying that C# is a bad language. A good language for me is one that is both effective and useful, for me. I assume he means that from a language effectiveness perspective.

    I asked what languages he considered to be better, because I personally think that C# is a great language and can't imagine why would he consider it to be bad. I admit that the languages he listed might for some reason be "better", since they require an approach to programming that is different from your standard C-style approach.

    I'm willing to give them the benefit of the doubt for that, and I'm willing to try them out when I get the chance to see if they really more effective, or elegant, or flexible, or whatever, provided that they're useful for what I do.

    One of my requirements is that I'm able to produce a GUI because my users don't appreciate the eliteness from the whole 'type commands into a console' philosophy that most algorithmic/scientific/scholar programs (and the programming languages they're commonly done in) usually follow.

    Either that, or it should allow for web development (I've been curious about Rails for a while now).

    So I'm wondering if any of those languages are capable of supporting a GUI of whatever kind. If they don't have that flexibility, then I can't rate them as "better", since they are useless to me.



  • @Sunstorm said:

    So I'm wondering if any of those languages are capable of supporting a GUI of whatever kind. If they don't have that flexibility, then I can't rate them as "better", since they are useless to me.

    Ruby already has bindings for several GUI toolkits, i.e. wx, QT etc. Ironruby (MS' .net port of ruby) will give you access to everything .net has to offer.



  • @Sunstorm said:

    One of my requirements is that I'm able to produce a GUI because my users don't appreciate the eliteness from the whole 'type commands into a console' philosophy that most algorithmic/scientific/scholar programs (and the programming languages they're commonly done in) usually follow.

    Either that, or it should allow for web development (I've been curious about Rails for a while now).

    So I'm wondering if any of those languages are capable of supporting a GUI of whatever kind. If they don't have that flexibility, then I can't rate them as "better", since they are useless to me.

     

    Any language which can do stdin and stdout and read from environment variables can support a GUI. There's this thing called CGI...


    Andrew.



  • @Sunstorm said:

    I'm intrigued by asuffield saying that C# is a bad language.

    I'm pretty sure I didn't say that. 

    A good language for me is one that is both effective and useful, for me. I assume he means that from a language effectiveness perspective.

    It's kind of a fuzzy all-round thing - sanity, correctness, intrinsic performance, actual performance of implementations, functionality of commonly available libraries (that's the one that really makes Java suck, the standard library is awful), inclusion of modern language features and generally how well it fulfils its potential. Choosing between the good languages tends to be a matter of opinion about which facets are more important, but oddly enough there's a huge gap on all fronts between the really good ones and the middle of the field, and another huge gap to the really bad ones (VB6, I'm looking at you). I think it has something to do with the kind of people that create them.

    Usefulness is related but not exactly the same thing. Perl 5 is incredibly useful despite its flaws. C is deeply flawed in many respects, yet there has never been a language which has been more useful - it's what the world is made from.

    One of my requirements is that I'm able to produce a GUI because my users don't appreciate the eliteness from the whole 'type commands into a console' philosophy that most algorithmic/scientific/scholar programs (and the programming languages they're commonly done in) usually follow.

    This is extremely narrow-minded of you. What possible value could a GUI be in an http server, for example? Only the most trivial component of any system (the end-user interface) involves a GUI; it's so braindead-simple that you can write it in almost anything you want and do all the real work in something else. Nothing interesting happens in GUIs.

    For example, Firefox has its important parts written in C++, and its GUI mostly written in XUL and Javascript.

    On things that I've worked on with GUIs, I estimate that the interfaces
    have occupied under 5% of the total development effort I expended on
    them. Any UI that is remotely complicated to implement is too complicated for people to use.


    So I'm wondering if any of those languages are capable of supporting a GUI of whatever kind.

    Perl 6 doesn't exist enough to do it yet, but all the others do.



  • @asuffield said:

    functionality of commonly available libraries (that's the one that really makes Java suck, the standard library is awful),

    Funny... I've always considered that part the strongest advantage of Java. The standard libs are IMO pretty okay, but what really makes the difference are the open source libs like those from the Jakarta project (i.e. POI), Jasper etc. While my .net-coworkers struggle how to get an Excel sheet out of an asp.net application, it's very easy to do that with Java and HSSF. Having those libs open sourced is not only a pleasure for the cheap guy, it is also a protection against the supplier-goes-out-of-business-problem that really sucks in the market for proprietary third-party-components.



  • @ammoQ said:

    @asuffield said:

    functionality of commonly available libraries (that's the one that really makes Java suck, the standard library is awful),

    Funny... I've always considered that part the strongest advantage of Java. The standard libs are IMO pretty okay, but what really makes the difference are the open source libs like those from the Jakarta project (i.e. POI), Jasper etc. While my .net-coworkers struggle how to get an Excel sheet out of an asp.net application, it's very easy to do that with Java and HSSF. Having those libs open sourced is not only a pleasure for the cheap guy, it is also a protection against the supplier-goes-out-of-business-problem that really sucks in the market for proprietary third-party-components.

    I suppose it's a matter of perspective. Coming from .NET, Java might look pretty good. Compared to most languages though, the Java standard library is an exercise in applied insanity. It seems like every package in it was written by a completely different person, with no sense of overall consistency or attempt to make different parts interact smoothly. Obvious features are regularly missing from classes that really should implement them and little-used features add needless overhead to common tasks. Different parts of the library use different language features depending on their age.



  • @asuffield said:

    Coming from .NET, Java might look pretty good.

    Shudder.

    Perhaps the Java standard library has changed in the last few years; but around 2001 I was choosing between Java & C#/.NET...after 3 months exposure with Java, I ran as far and as fast as I could away from it.   Part of it was the quality of the code written in it that I had to work with, but a big part was just the irrationality of the libraries.   

    By comparison, .NET was very well structured.  Not saying it is/was perfect, but by in large it did what I expected in ways I expected, and a lot of common programming problems were handled directly in the libraries.  

    Coming from the .NET framework, Java standard libraries looks like 'good riddance' :)

    -cw



  • Well, of course one has to admit that the most fundamental Java APIs, like java.io.File, are also the oldest and therefore the most inconsistent ones. The switch from AWT to Swing also caused some fallout. In my opinion, the .net standard libs are definitely better in that respect, but I'm desperately missing those 3rd party open source goodies like POI.



  • @asuffield said:


    @Sunstorm said:

    One of my requirements is that I'm able to produce a GUI

    This is extremely narrow-minded of you.

    Speaking about narrow-mindedness...
    @asuffield said:

    What possible value could a GUI be in an http server, for example?

    It's quite possibly a passing frenzy but I heard of some http servers that serve these things called, er, web pages and apparently some obviously retarded people have the indulgence to actually LOOK at those. Can you believe that?
    @asuffield said:

    Only the most trivial component of any system (the end-user interface) involves a GUI

    Computers exist for the sole purpose of serving humans. Any computer activity that does not directly involve human beings is trivial plumbing and wiring. (Exaggerated? Yes. Likewise.)
    @asuffield said:

    it's so braindead-simple that you can write it in almost anything you want and do all the real work in something else.

    Tried a first person shooter yet?
    @asuffield said:

    Nothing interesting happens in GUIs.

    Outside the UI you'll find nothing but masturbating electrons in a dark void.
    Step away from the computer one night, go out to a lone mountain top, look up and enjoy the background microwave radiation. It's so much more interesting.
    @asuffield said:

    On things that I've worked on with GUIs, I estimate that the interfaces have occupied under 5% of the total development effort I expended on them

    That doesn't come as a surprise. You'll spend 95% of your time optimizing an algorithm thousandfold from 1 second down to 1 ms. That's clever and useful.
    Than you slam a crap UI on it that takes the average user 5 seconds to make it work. Total execution time: 5.001 seconds.
    Instead, you could have spend a little bit more thinking on a UI that enables the user to work it out in 1 second. Total execution time: 2 seconds.


    Even when programming the darkest corners of the server side, your only mindset must be how your program will enable the human user.



  • @asuffield said:

    @Sunstorm said:
    I'm intrigued by asuffield saying that C# is a bad language.

    I'm pretty sure I didn't say that.

    My bad. I meant less than good. 

    @asuffield said:

    Usefulness is related but not exactly the same thing. Perl 5 is incredibly useful despite its flaws. C is deeply flawed in many respects, yet there has never been a language which has been more useful - it's what the world is made from.

    Usefulness, to me. I find no reason to rate things on a global scale, other than as a curiosity for discussion.

    @asuffield said:

    This is extremely narrow-minded of you. What possible value could a GUI be in an http server, for example? Only the most trivial component of any system (the end-user interface) involves a GUI; it's so braindead-simple that you can write it in almost anything you want and do all the real work in something else. Nothing interesting happens in GUIs.

    Luckily, I don't build HTTP servers for a living. That would be either very dreadful or very fun. I do applications that manage data, for the most part. They normally require good interactivity and a rich way to display the data in a meaningful way. Yes, I could probably build the code library in one language, and then link it to the GUI project in another, but that seems like too much work for very little benefit.



Log in to reply