1. Home
  2. Categories
  3. Side Bar WTF
  4. Better way to compare booleans

Better way to compare booleans

  • ?

    @morbiuswilters said:

    I guess I don't buy that type safety eliminates any bugs.  In fact, with all the extra code overhead of casting, extending, etc. I would say it increases the number of bugs.  Strict typing makes you do all sorts of annoying bullshit to work with generics, collections, etc.  Taken to its logical conclusion, you end up with C++ templates, which are a huge source of fuck-ups.  I've done professional development for awhile and I can recall only a handful of bugs I've encountered that strict typing would have prevented.  However, I have encountered plenty of bugs caused by a fairly competent developer implenting all sorts of type-management boilerplate just to get the fucking compiler to shut up.

     

    Eh... what generics are you talking about?  I can't speak to Java, but .NET generics are nothing like C++ templates.  I really don't think I've ever had to do any casting with them - in fact, they're largely designed to eliminate the need for those annoying casts - and untyped function/method pointers are just a pale shadow of delegates.

    Really the only times I find myself wanting type coercion are when I have to deal with either reflection or metadata, and those are pretty obscure cases.  Otherwise, I really don't want numbers or dates being magically turned into strings (or vice versa) and messing up sort orders and comparisons.  Preferably I'd like to just be able to selectively opt-out of type safety, either with some compiler directives or multi-language compilation.  Failing that, I'll deal with the 45 seconds per day I have to spend on writing casts.

    0
  • Mason_Wheeler

    @morbiuswilters said:

    Meanwhile, comparing strings with == will not usually give you what you want in Java or C, so I suppose that means static typing is teh ghey.
     

    No, it means that C's string handling (like most things in C, really) is fundamentally flawed, and that a whole lot of its flaws have been  carried forward into other languages in the C family to preserve the appearance of backwards compatibility.

    By contrast, in Pascal, which is statically typed,  if you say "if string1 = string2", the result will be true if the contents of the two strings are identical, which is what you intuitively think you're asking when you ask that question.  It's not a static typing issue, it's a "how much thought did the language designers put into it?" issue.

    0
  • morbiuswilters

    @Aaron said:

    Eh... what generics are you talking about?  I can't speak to Java, but .NET generics are nothing like C++ templates.  I really don't think I've ever had to do any casting with them - in fact, they're largely designed to eliminate the need for those annoying casts - and untyped function/method pointers are just a pale shadow of delegates.

    I hear C# is better than most strictly-typed languages.  I am on the Unix side of things, basically C, Java, C++, bash, perl, php, python and ruby.  The last 5 are okay and C is an acceptable pain when I absolutely need the performance.  Java and C++ can rot in hell.

     

    @Aaron said:

    Really the only times I find myself wanting type coercion are when I have to deal with either reflection or metadata, and those are pretty obscure cases.  Otherwise, I really don't want numbers or dates being magically turned into strings (or vice versa) and messing up sort orders and comparisons.

    I don't know of any language where dates are amongst the primitives or where date objects would be cocerced into strings or ints.  For strings, I've never really found it to be a problem.  If I know I'm working with numeric data, I treat them like numbers, if I'm working with non-numeric strings, treat them like strings.  If there's a place where I think it is possible type coercion could go wrong, I simply take that into account.  The ability to have easy, implicit conversion from strings to numbers and vice-versa far outweighs the few times I have to be more cautious and explicitly specify the behavior I want.

    0
  • ?

    @Mason Wheeler said:

    @morbiuswilters said:

    Meanwhile, comparing strings with == will not usually give you what you want in Java or C, so I suppose that means static typing is teh ghey.
     

    No, it means that C's string handling (like most things in C, really) is fundamentally flawed, and that a whole lot of its flaws have been  carried forward into other languages in the C family to preserve the appearance of backwards compatibility.

    By contrast, in Pascal, which is statically typed,  if you say "if string1 = string2", the result will be true if the contents of the two strings are identical, which is what you intuitively think you're asking when you ask that question.  It's not a static typing issue, it's a "how much thought did the language designers put into it?" issue.

     

    Then again, Delphi (Pascal) just got Unicode in 2009, so the language is not exactly a shining example of how to do string handling the "right way"...

    0
  • morbiuswilters

    @Mason Wheeler said:

    @morbiuswilters said:

    Meanwhile, comparing strings with == will not usually give you what you want in Java or C, so I suppose that means static typing is teh ghey.
     

    No, it means that C's string handling (like most things in C, really) is fundamentally flawed, and that a whole lot of its flaws have been  carried forward into other languages in the C family to preserve the appearance of backwards compatibility.

    By contrast, in Pascal, which is statically typed,  if you say "if string1 = string2", the result will be true if the contents of the two strings are identical, which is what you intuitively think you're asking when you ask that question.  It's not a static typing issue, it's a "how much thought did the language designers put into it?" issue.

    Well, no, it's not.  I was making a facetious argument to illustrate the foolishness of what you were saying.  C's big flaw is that it is very minimalistic.  I suppose it would be convenient if doing == on two char pointers compared the null-delimited contents of the strings they hold the address for, but it would be largely out-of-line with the way C works and would introduce more confusion in the long run.  Of course, I have no idea why Java decided == should compare object addresses rather than object contents, other than the fact that Java is a piece of shit designed by crackheads.

     

    Besides, Pascal?  How about we limit this to real languages people actually use.  Maybe Pascal gets convenient string comparisons right, but clearly it got a lot wrong, which is why nobody uses it anymore.  Here's another idea: how about you come up with some concrete examples of why type coercion is "wrong"?  I prefer dynamic languages because I don't get a boner from casting shit or writing boilerplate code to make my shit work with the compiler.  I'm not saying static typing is "wrong" or bad, just that it's annoying and that loose typing doesn't cause half the problems people seem to think it does.  From plenty of experience with both, I can say that the times I've seen weak typing result in a bug that would have been prevented by strict typing are very, very rare.  Do you actually have any real-world experience with dynamic languages, or are you merely speaking out of your ass?  Your mention of Pascal would seem to indicate that you are little more than an academic wanker who nobody would ever trust with real authority or an actual, money-generating project.

    0
  • morbiuswilters

    @Aaron said:

    Then again, Delphi (Pascal) just got Unicode in 2009, so the language is not exactly a shining example of how to do string handling the "right way"...

    QFT.

    0
  • blakeyrat

     I like dynamic languages too.

     But I will say that static typing? Makes it much easier for the Intellisense/whatever in your IDE to grab useful information automatically.

    0
  • dhromed

    @belgariontheking said:

    I just installed FF again on a new comp.  How do I turn on autocomplete?
     

    It's on by default, no?

    I'm going to downgrade to 3.5 again until 3.6 stops being an unstable piece of junk that crashes on some specific urls als also drag operations. Sometimes.

     

    0
  • dhromed

    @morbiuswilters said:

    This evalutes as false in PHP.
     

    Oh I know. I must have made an error in communication. I meant to convey that the above statement would be logically true given the truthiness of the two others I mentioned, but it nonetheless evaluates to false.

    @morbiuswilters said:

    I love type coercion. it is easier and more elegant than having to cast shit all the time.

    I agree, but I would love it more if it contained some updates or culling of the coercion rules, and was generally less zealous.

     

     

    0
  • Mason_Wheeler

    @Aaron said:

    @Mason Wheeler said:

    By contrast, in Pascal, which is statically typed,  if you say "if string1 = string2", the result will be true if the contents of the two strings are identical, which is what you intuitively think you're asking when you ask that question.  It's not a static typing issue, it's a "how much thought did the language designers put into it?" issue.
     

    Then again, Delphi (Pascal) just got Unicode in 2009, so the language is not exactly a shining example of how to do string handling the "right way"...

    Actually, Unicode support in Delphi has been around since the late 90s.  It just didn't gain a Unicode string type as the default string until 2008.  And while that was long overdue, the way Delphi's strings are actually implemented is a shining example of how to do string handling the right way.

     It starts with the Pascal string model, with the length known up-front so copies and comparisons can be made as fast as the CPU is capable of, instead of one character at a time, constantly checking for a null terminator.  Then it adds a reference count (no need to think about memory management) and copy-on-write semantics, which together with the reference count allows you to avoid unnecessary string duplication.  It's a far better model than either C's strings (null-terminated = slow) or .NET strings (immutable?  What were they thinking?!?)

    0
  • dhromed

    @blakeyrat said:

    But I will say that static typing? Makes it much easier for the Intellisense/whatever in your IDE to grab useful information automatically.
     

    I like how I can ask the question: "dude, where the fuck did this variable come from?" and it'll say "yo, it's a parameter, man" and I'm like,"sweet, thanks."

    0
  • Mason_Wheeler

    @morbiuswilters said:

    Besides, Pascal?  How about we limit this to real languages people actually use. ... Your mention of Pascal would seem to indicate that you are little more than an academic wanker who nobody would ever trust with real authority or an actual, money-generating project.
     

    My boss would be very surprised to hear that.  Heck, my entire project team would be very surprised to hear that.  I'm a developer on a major app that's the industry leader in management software for broadcast media.  If you watch TV or listen to the radio in the USA, there's a good chance the station is running on our program.  Actual, money-generating project, and it's written in Delphi.

    Oh, and in case you weren't aware, the folks over at Skype would also be very surprised to hear that.  As would plenty of other developers of major Delphi applications that get used all over the world.  Pascal is alive and well.

    0
  • topspin
    BINNED

    @dhromed said:

    Hence the extraneous operators === and !== which mean (sametype && equal) and (sametype && !equal) respectively.

     

     I don't know any PHP but shouldn't that be !(sametype && equal) ?? === and !== not being the opposite of each other would be TRWTF.

     

    0
  • ?

    @morbiuswilters said:

    I prefer dynamic languages because I don't get a boner from casting shit

     

    Not even when you cast Lvl. 8 Cock of the Infinite?

    0
  • dhromed

    @morbiuswilters said:

    I don't know of any language where date objects would be cocerced into strings or ints. 
     

    Javascript.

    Anything in string context has its toString() method called.

    @morbiuswilters said:

    I don't get a boner from casting shit
     

    lol.

     

    0
  • L

    @Mason Wheeler said:

    No, it means that C's string handling (like most things in C, really) is fundamentally flawed, and that a whole lot of its flaws have been  carried forward into other languages in the C family to preserve the appearance of backwards compatibility.
    C doesn't really handle strings, as such calling this a "flaw" is somewhat... incorrect. It never was meant to have parsing strings as a strength, if you want a language to parse strings, pick something else. It handles character arrays, which are actually just pointers to a memory block that holds a sequence of characters that end in a NUL character. Strings were never its strength, C++ somewhat rectifies this with std::string, but no-one sane would use C++ for that reason.



    @Mason Wheeler said:
    By contrast, in Pascal, which is statically typed,  if you say "if string1 = string2", the result will be true if the contents of the two strings are identical, which is what you intuitively think you're asking when you ask that question.  It's not a static typing issue, it's a "how much thought did the language designers put into it?" issue.

    It's more of a "use the language for its strengths" and not a "every language should solve every problem" issue.

    0
  • ?

    @Mason Wheeler said:

    Actually, Unicode support in Delphi has been around since the late 90s.  It just didn't gain a Unicode string type as the default string until 2008.  And while that was long overdue, the way Delphi's strings are actually implemented is a shining example of how to do string handling the right way.

     It starts with the Pascal string model, with the length known up-front so copies and comparisons can be made as fast as the CPU is capable of, instead of one character at a time, constantly checking for a null terminator.  Then it adds a reference count (no need to think about memory management) and copy-on-write semantics, which together with the reference count allows you to avoid unnecessary string duplication.  It's a far better model than either C's strings (null-terminated = slow) or .NET strings (immutable?  What were they thinking?!?)

     

    Dude, I mentioned Pascal strings way way back.  I know what they are.  And are you seriously telling me that immutable strings are a bad thing, especially compared to Delphi's disgusting mess of interning and reference counting that made it damn near impossible to properly marshall them over module boundaries?

    On the one hand you say that strings should have similar semantics to primitives - in other words, the "=" operator does a character comparison.  And on the other hand you say that they should be mutable.  You can't have it both ways.  Either strings have reference-type semantics or value-type semantics; if they're value types then they should be immutable.  I would never, ever, ever want to work with mutable strings again, they're a conceptual trainwreck.  If you desperately need to treat one as a mutable structure then you always have the ability to fall back to a character array.

    And saying that Delphi had Unicode in the late 90's... please.  WideString in D6 (D5? I forget) was also a trainwreck.  You ran into all sorts of impossible-to-debug, rage-inducing errors if you tried to mix and match them with regular ANSI strings because, again, of the stupid interning and reference counting semantic, which were different for each string type, and yet you received absolutely no compile-time safety or even meaningful runtime errors if you got it wrong.  It wasn't just a matter of making it the "default" in 2009, they had to actually normalize all of the different implementations so Unicode handling was more than a big sloppy mess.

    Sorry, but I used Delphi quite heavily back in those days and even back then I knew that its string handling blew chunks.  Pascal strings were nice, a lot easier to work with than C strings, but Unicode support was practically unusable, and to suggest, even in jest, that Delphi's string types still have or even once had any advantages over .NET strings, is insane.  Give me one concrete example of where you actually need a mutable string.  Go ahead, just try.

    0
  • dhromed

    @topspin said:

    I don't know any PHP but shouldn't that be !(sametype && equal) ?? === and !== not being the opposite of each other would be TRWTF.
     

    Misthinking on my part.

    0
  • Mason_Wheeler

    @Aaron said:

    And are you seriously telling me that immutable strings are a bad thing, especially compared to Delphi's disgusting mess of interning and reference counting that made it damn near impossible to properly marshall them over module boundaries?

    I have no idea what you're talking about.  I've never had the slightest bit of trouble sending them across module boundaries.   If the other DLL is also written in Delphi, you can share the memory manager and everything's good.  Otherwise, it's probably expecting a C-string, which you can create with a simple typecast.  The only place where you might possibly run into trouble is if the other API is taking a C-string pointer and is going to change the contents of the string, in which case you need to make sure it's a unique copy first, which is a trivial operation.  Where's the near-impossibility?

    On the one hand you say that strings should have similar semantics to primitives - in other words, the "=" operator does a character comparison.  And on the other hand you say that they should be mutable.  You can't have it both ways.

    Why not?  Maybe this is just a matter of different experiences, but I've never had any problems with this.

    Sorry, but I used Delphi quite heavily back in those days and even back then I knew that its string handling blew chunks.  Pascal strings were nice, a lot easier to work with than C strings, but Unicode support was practically unusable, and to suggest, even in jest, that Delphi's string types still have or even once had any advantages over .NET strings, is insane.  Give me one concrete example of where you actually need a mutable string.  Go ahead, just try.

    Are you kidding?  I ought to be asking you what possible advantages you gain from throwing the ability to manipulate the contents of strings out the window!  It makes even trivial operations such as concatenation much more complex and inefficient. (Don't even get me started on the horrors of the StringBuilder!)  How do you accomplish anything without mutable strings?

    0
  • Cad_Delworth

    @toshir0 said:

    I so much want to cheer and sing with you all, my friends. Too bad.

    All together now!

    "Share and enjoy! Share and enjoy! Journey through life with a plastic boy
    …or girl by your side! Let your pal be … your … guide …"

    Oh. Just me, then? >sigh<

    0
  • Cad_Delworth

    @morbiuswilters said:

    @da Doctah said:

     Quick comparison....

    Q:  "What does this three-page PL/I program do?"

    A:  "What doesn't it do?"

     

    Q:  "What does this twenty-page COBOL program do?"

    A:  "Nothing yet.  We're only up to the Environment Division."

    Goddamn, pstorer and btk.  It's all fun and games until somebody posts something like this.  Are you happy now?  This is why we can't have nice things.

    Q: What does this one-page APL program do?

    A: How long have you got for me to explain?

    Have a nice day!

    0
  • Jaime

    @morbiuswilters said:

    @Aaron said:

    @morbiuswilters said:

    Right, because type safety eliminates all some bugs.

     

    Corrected.

    Language features aren't an all-or-nothing proposition.  Shall we also eschew garbage collection because it doesn't eliminate every conceivable null-pointer or resource leak error? Also, Pascal strings don't completely eliminate subscripting errors, so we probably should just go back to null-terminated strings.

    I guess I don't buy that type safety eliminates any bugs.  In fact, with all the extra code overhead of casting, extending, etc. I would say it increases the number of bugs.  Strict typing makes you do all sorts of annoying bullshit to work with generics, collections, etc.  Taken to its logical conclusion, you end up with C++ templates, which are a huge source of fuck-ups.  I've done professional development for awhile and I can recall only a handful of bugs I've encountered that strict typing would have prevented.  However, I have encountered plenty of bugs caused by a fairly competent developer implenting all sorts of type-management boilerplate just to get the fucking compiler to shut up.

     

    I hate to tell you this, but this sounds like a sales pitch for VB.  You get type safety and type coersion simultaneously in VB.

    0
  • Jaime

    @dhromed said:

    @blakeyrat said:

    But I will say that static typing? Makes it much easier for the Intellisense/whatever in your IDE to grab useful information automatically.
     

    I like how I can ask the question: "dude, where the fuck did this variable come from?" and it'll say "yo, it's a parameter, man" and I'm like,"sweet, thanks."

     

    Visual Studio 2008 and later give decent Intellisense in javascript.  Although this is more of a case of an IDE that's so awesome that it can make sense of javascript than a justification for dynamic languages.

    0
  • D

    @morbiuswilters said:

    I guess I don't buy that type safety eliminates any bugs.  In fact, with all the extra code overhead of casting, extending, etc. I would say it increases the number of bugs. 

    Sounds like you're just doing it wrong.  Casts should be a rare operation, not something that makes up any significant percentage of overhead.

    @morbiuswilters said:

    Strict typing makes you do all sorts of annoying bullshit to work with generics, collections, etc.  Taken to its logical conclusion, you end up with C++ templates, which are a huge source of fuck-ups.

    Maybe your compiler is a bit behind the times.  I find the STL "just works" absolutely perfectly for me these days.

    @morbiuswilters said:

    I've done professional development for awhile and I can recall only a handful of bugs I've encountered that strict typing would have prevented.

    I've only come across so many as well, but every single one was a real nasty hard-to-detect hard-to-diagnose hard-to-trace-reproduce-or-just-about-anything one.  If type safety mitigates the awfulness of bugs, even that's a worthwhile advantage.

    On the other hand, you should see the number of bugs that I haven't encountered because strict typing prevented them from ever occurring in the first place.  That number is huge.

    @morbiuswilters said:

    However, I have encountered plenty of bugs caused by a fairly competent developer implenting all sorts of type-management boilerplate just to get the fucking compiler to shut up.
    Doing things that you don't properly understand with the blind aim of "getting the fucking compiler to shut up" is exactly what I'd describe as "doing it wrong".  You yourself were just relying on the "Dumb people can fuck up in any language" argument weren't you?  Well, back at you; just because someone can get it wrong like that isn't an argument against type-safety.

    0
  • blakeyrat

    @DaveK said:

    Maybe your compiler is a bit behind the times.  I find the STL "just works" absolutely perfectly for me these days.
     

    Why are you even writing C++ these days?

    0
  • D

    @belgariontheking said:

    So, I just installed FF again on a new comp.  How do I turn on autocomplete?

    Click here -> http://forums.techguy.org/tech-tips-tricks/336287-how-turn-autocomplete-firefox.html

    0
  • D

    @Cad Delworth said:

    @toshir0 said:

    I so much want to cheer and sing with you all, my friends. Too bad.

    All together now!

    "Share and enjoy! Share and enjoy! Journey through life with a plastic boy
    …or girl by your side! Let your pal be … your … guide …"

    Oh. Just me, then? >sigh<

    Nah, I think I can remember how it goes.  Off the top of my head, ...

    @a choir of 5000 robots exactly a flattened fifth out of key said:

    But when it breaks down

    Or starts to annoy

    Because it's ripped off your door

    Leaked oil on your floor

    <something something> the mat

    Or had sex with your cat

    Don't bring it to us, we don't give a fig!

    We'll tell you ...

     

    ... Go stick your head in a pig!

    Hmmf.  <goes off to google the bits I forgot> 

    [EDIT: I was way off.  http://www.ligo.caltech.edu/~tdcreigh/share-and-enjoy.html for the full and correct version.]

    0
  • D

    @blakeyrat said:

    @DaveK said:

    Maybe your compiler is a bit behind the times.  I find the STL "just works" absolutely perfectly for me these days.
     

    Why are you even writing C++ these days?

    Well, there's the whole "It's simple, it's there, and it just works" thing.  That's not a bad reason for starters.  Hell, I also still use C and assembler.

    Other times I use other things.  Horses for courses and all that.

     

    0
  • blakeyrat

    C++ is simple?!

    You know how sometimes people say something which at first seems compeletely innocent, but then you realize that the fact that they've said it tells you that you'll never really understand or get along with them? This is that moment.

    0
  • D

    @blakeyrat said:

    C++ is simple?!

    You know how sometimes people say something which at first seems compeletely innocent, but then you realize that the fact that they've said it tells you that you'll never really understand or get along with them? This is that moment.

    Heh.  Well, maybe I should have said "well understood" or something like that, but what I meant is it's a straightforward procedural language with variables and function calls and all that pretty ordinary stuff, and there's some syntactic sugar on top of that which is where the complexity comes in.  It's conceptually simple, even if it gets complex in practice.

    0
  • B

    @DaveK said:

    @morbiuswilters said:

    Strict typing makes you do all sorts of annoying bullshit to work with generics, collections, etc.  Taken to its logical conclusion, you end up with C++ templates, which are a huge source of fuck-ups.

    Maybe your compiler is a bit behind the times.  I find the STL "just works" absolutely perfectly for me these days.

    STL != templates.  The fact that STL works does not mitigate the dreadfulness of templates.  They are awful.  This isn't even really a debated topic these days.  The fact that no modern languages saw fit to copy C++'s templates speaks loudly.

     

    0
  • D

    @DaveK said:

    @blakeyrat said:

    C++ is simple?! [ . . . ] 

    Heh.  Well, maybe I should have said "well understood" or something

    Actually, on second thought, no; "simple" is just the right word.  Simple is what we call stuff a child could understand, right?  Well, BASIC is simple.  I taught myself that from a book at the age of 10.  And Fortran, and COBOL; they're simple, I had textbooks for them that I could understand and do the exercises in.  LISP, on the other hand, that's complex.  I had a textbook on that too, and it taught me about car and cdr and a bit of basic list-handling, which was fine, but then suddenly I turned over the page and there was a solid wall of mathematical number-theory notation going into the first principles of lambda functions and stuff like that, and it was just meaningless to me; my brain simply could not wrap itself even around the basic concepts they were dealing with, let alone follow their arguments to the theorems they were proving.  Ouch.

    So, by that definition of complex/simple, C++ is very definitely on the simple side of the line.  It's the underlying conceptual structure of the language that I'm saying is simple rather than complex.

    0
  • Mason_Wheeler

    @bstorer said:

    @DaveK said:

    @morbiuswilters said:

    Strict typing makes you do all sorts of annoying bullshit to work with generics, collections, etc.  Taken to its logical conclusion, you end up with C++ templates, which are a huge source of fuck-ups.

    Maybe your compiler is a bit behind the times.  I find the STL "just works" absolutely perfectly for me these days.

    STL != templates.  The fact that STL works does not mitigate the dreadfulness of templates.  They are awful.  This isn't even really a debated topic these days.  The fact that no modern languages saw fit to copy C++'s templates speaks loudly.

     

    Quoted for truth.  It's also worth noting that no modern languages have seen fit to copy C++'s RAII either, even though C++ advocates almost universally seem to think it's a Good Thing for some reason...

    0
  • ?

    @Mason Wheeler said:

    I have no idea what you're talking about.  I've never had the slightest bit of trouble sending them across module boundaries.   If the other DLL is also written in Delphi, you can share the memory manager and everything's good.  Otherwise, it's probably expecting a C-string, which you can create with a simple typecast.

    Ah, I see, you've been staying in the box and using the horror that is BORLNDMM.  I can see why you'd think that everything's hunky dory.  Try doing actual interop sometime.

    Are you kidding?  I ought to be asking you what possible advantages you gain from throwing the ability to manipulate the contents of strings out the window!  It makes even trivial operations such as concatenation much more complex and inefficient. (Don't even get me started on the horrors of the StringBuilder!)  How do you accomplish anything without mutable strings?
     

    Please, please tell me you're joking.  A string is an atomic value.  It makes no more sense to manipulate the contents of one than it does to manipulate the lower bits of an integer.  If you want to do that, you create a new one.  And if you find yourself in one of those extremely odd corner cases where you actually need to perform this kind of mutable bit-twiddling (for example, you've gone temporarily insane), then you create a mutable bit vector or bit set and then cast it as an integer.  You can do the same with a character array and then cast that to a string.

    Are you honestly, seriously trying to tell us that it's a good thing for strings to leak their implementation details, to basically be paper-thin wrappers over character arrays, when it takes an extra 6 seconds to flip to an actual character array in the 0.0001% of cases where you actually need mutable semantics?

    And the "horrors" of the StringBuilder... please, do tell.

    0
  • blakeyrat

    @DaveK said:

    So, by that definition of complex/simple, C++ is very definitely on the simple side of the line.  It's the underlying conceptual structure of the language that I'm saying is simple rather than complex.
     

    We'll just have to agree to disagree.

    Possibly if you restrict yourself to a tiny subset of C++ features, you can call it "simple", but then you're also not talking about C++-- you're talking about a tiny subset of C++ features. If you consider the language holistically, it's by far one of the most complex languages ever made. "DaveK happens to know it pretty well" != simple.

    I mean, the first requirement for "simple" has to be automatic memory management, and C++ ain't got it. Or, for example, "simple" would probably mean a language without dozens of dangerous (security/stability-wise) functions that, despite being dangerous, have never been removed from the library. A "simple" language probably wouldn't let you overload the + symbol into doing subtraction, or attach a macro to the keyword "int" that redefines it as a float.

    And I still don't get why, in the 2010, with so many awesome languages around, anybody would voluntarily write code in C++. Do you just like bugs?

    0
  • dhromed

    @Aaron said:

    A string is an atomic value.  It makes no more sense to manipulate the contents of one than it does to manipulate the lower bits of an integer.
     

    ?

    I manipulate strings all the time with replace and concatenation. One has to format things like queries and output HTML.

    0
  • Mason_Wheeler

    @blakeyrat said:

    I mean, the first requirement for "simple" has to be automatic memory management, and C++ ain't got it.

    Don't be ridiculous.  Garbage collection doesn't simplify a language, it just dumbs it down and moves the memory leaks and other memory management glitches to dark corners that are harder to track down and debug.  Simply because C's memory management model, which C++ inherited and managed to make even worse, is a big mess doesn't mean that the basic concept is unsound.

    Or, for example, "simple" would probably mean a language without dozens of dangerous (security/stability-wise) functions that, despite being dangerous, have never been removed from the library. A "simple" language probably wouldn't let you overload the + symbol into doing subtraction, or attach a macro to the keyword "int" that redefines it as a float.

    And I still don't get why, in the 2010, with so many awesome languages around, anybody would voluntarily write code in C++. Do you just like bugs?

     

    OK, that part's more reasonable.

    0
  • R

    @morbiuswilters said:

    @Aaron said:

    @morbiuswilters said:

    Right, because type safety eliminates all some bugs.

     

    Corrected.

    Language features aren't an all-or-nothing proposition.  Shall we also eschew garbage collection because it doesn't eliminate every conceivable null-pointer or resource leak error? Also, Pascal strings don't completely eliminate subscripting errors, so we probably should just go back to null-terminated strings.

    I guess I don't buy that type safety eliminates any bugs.  In fact, with all the extra code overhead of casting, extending, etc. I would say it increases the number of bugs.  Strict typing makes you do all sorts of annoying bullshit to work with generics, collections, etc.  Taken to its logical conclusion, you end up with C++ templates, which are a huge source of fuck-ups.  I've done professional development for awhile and I can recall only a handful of bugs I've encountered that strict typing would have prevented.  However, I have encountered plenty of bugs caused by a fairly competent developer implenting all sorts of type-management boilerplate just to get the fucking compiler to shut up.

    I'm not sure why I even reply to your flamebait.

    Then you haven't worked on a C++Builder project I once worked on, where replacing all the TLists (from the Borland VCL, which had to be compatible with Delphi), with the SLT std::list template solved a huge amount of bugs, as the compiler could all of a sudden find a lot of incorrect type casts. (TLlist is a linked list that can only store void pointers, so everything that used linked lists in the code would constantly cast void pointers to all kinds of objects.)

    As to "00" and "0000" both being numbers, I also have to disagree. At best they are arrays of numbers represented as strings, given that 0 is a number. And, given that they are of different length, it's probably important to treat them as inequal to eachother. It could for example be what you need to do to dial an outside line. A big source of WTFs is if people treat "telelphone numbers" as numbers. They are not. They are arrays of numbers, otherwise 1234 and 01234 would be the same telephone number.

     P.S. the quotes in this thread about PL/I and COBOL made me laugh. More fun than the rest of it!

    0
  • Mason_Wheeler

    @Aaron said:

    Ah, I see, you've been staying in the box and using the horror that is BORLNDMM.  I can see why you'd think that everything's hunky dory.  Try doing actual interop sometime.

    BORLNDMM... now there's a name I haven't heard in a while. I haven't touched it in years, ever since FastMM4 came out.  And if by "actual interop" you mean COM, we've got an old COM DLL at work that some genius back in the day decided it would be a good idea to write in C++ "for performance reasons."  He's no longer with us, but the legacy of his DLL is.  It takes care of some of the most fundamental database communication, and after a few years of tweaking by a very talented coder to clean up the mess that the original author left behind, it actually works surprisingly well.  He's a good friend of mine, and we regularly gripe to each other about various bugs that get found.  He talks all the time about how many wheels the original coder reinvented, about glitchy containers and bad iterators and all sorts of template-related things.  He complains about obsucure code that causes linker errors if he tries to build with the Intel C++ compiler, which would apparently give quite a speed boost.  But he's never once mentioned any sort of marshalling problems, despite the tons of string data that this COM DLL passes back and forth to the Delphi program that it runs under.

    Simply because you apparently don't know how to marshal strings in Delphi doesn't mean it's hard to do.  It just means that you apparently never learned how it's done.

    Are you kidding?  I ought to be asking you what possible advantages you gain from throwing the ability to manipulate the contents of strings out the window!  It makes even trivial operations such as concatenation much more complex and inefficient. (Don't even get me started on the horrors of the StringBuilder!)  How do you accomplish anything without mutable strings?
     

    Please, please tell me you're joking.  A string is an atomic value.  It makes no more sense to manipulate the contents of one than it does to manipulate the lower bits of an integer.  If you want to do that, you create a new one.  And if you find yourself in one of those extremely odd corner cases where you actually need to perform this kind of mutable bit-twiddling (for example, you've gone temporarily insane), then you create a mutable bit vector or bit set and then cast it as an integer.  You can do the same with a character array and then cast that to a string.

    Are you honestly, seriously trying to tell us that it's a good thing for strings to leak their implementation details, to basically be paper-thin wrappers over character arrays, when it takes an extra 6 seconds to flip to an actual character array in the 0.0001% of cases where you actually need mutable semantics?

    Your premise is invalid. A string isn't an atomic value, it's a strange, dual-natured entity that is both a primitive and an array at the same time.  This is part of the reason why working with strings is difficult, but trying to pretend like it isn't both a primitive and an array at the same time leads to ugly abstraction inversions and makes string manipulation much more difficult.

    0
  • Jaime

    @dhromed said:

    @Aaron said:

    A string is an atomic value.  It makes no more sense to manipulate the contents of one than it does to manipulate the lower bits of an integer.
     

    ?

    I manipulate strings all the time with replace and concatenation. One has to format things like queries and output HTML.

    Strings have to be implemented as atomic to make a language less messy.  Most languages implement strings as reference types, but allow them to be manipulated as value types.  Because assignment only copies the reference for reference types, some magic has to be performed to allow this to work sensibly:

    String x = "Hello";
    String y = x;
    y += " world";

    By implementating strings as atomic, x is left unchanged.  The third line actually creates a new string instead of changing the single string instance that both x and y reference.

    0
  • R

    @Mason Wheeler said:

    @blakeyrat said:

    I mean, the first requirement for "simple" has to be automatic memory management, and C++ ain't got it.

    Don't be ridiculous.  Garbage collection doesn't simplify a language, it just dumbs it down and moves the memory leaks and other memory management glitches to dark corners that are harder to track down and debug.  Simply because C's memory management model, which C++ inherited and managed to make even worse, is a big mess doesn't mean that the basic concept is unsound.

    Or, for example, "simple" would probably mean a language without dozens of dangerous (security/stability-wise) functions that, despite being dangerous, have never been removed from the library. A "simple" language probably wouldn't let you overload the + symbol into doing subtraction, or attach a macro to the keyword "int" that redefines it as a float.

    And I still don't get why, in the 2010, with so many awesome languages around, anybody would voluntarily write code in C++. Do you just like bugs?

     

    OK, that part's more reasonable.

    I agree that garbage collection does not make a simple language. I also agree that C++ is not a simple language. A simple language is one that you can make a 1 page reference card for, like Python: http://home.uchicago.edu/~gan/file/python.pdf

    C++ does have it's uses however.

    • You have heavily using existing code written in C or C++.*
    • You need very close interaction with hardware.
    • You want to built a good looking cross platform user interface. (which almost only leaves Qt in my opinion, .Net isn't crossplatform, and Java or GTK are too ugly, or am I forgetting something?).
    • You can't rely on a VM, framework or interpreter being available or of a certain version.
    • You want a large amount of control over the exact execution of your code, given timing, memory or efficiency reasons.
    • You want to write object oriented software while being constrained by one of the above.
    • Your available alternatives are worse.
    • All of the above.
    Did I forget some? The above I have to take into account on a daily basis.
    *) If you're lucky. I have code bases written in Fortan IV and Fortan66. Adding IMPLICIT NONE and trying to have Fortran 77 or 99 compile it is usually the first step towards sanity.
    0
  • R

    @Mason Wheeler said:

    @Aaron said:

    Ah, I see, you've been staying in the box and using the horror that is BORLNDMM.  I can see why you'd think that everything's hunky dory.  Try doing actual interop sometime.

    BORLNDMM... now there's a name I haven't heard in a while. I haven't touched it in years, ever since FastMM4 came out.  And if by "actual interop" you mean COM, we've got an old COM DLL at work that some genius back in the day decided it would be a good idea to write in C++ "for performance reasons."  He's no longer with us, but the legacy of his DLL is.  It takes care of some of the most fundamental database communication, and after a few years of tweaking by a very talented coder to clean up the mess that the original author left behind, it actually works surprisingly well.  He's a good friend of mine, and we regularly gripe to each other about various bugs that get found.  He talks all the time about how many wheels the original coder reinvented, about glitchy containers and bad iterators and all sorts of template-related things.  He complains about obsucure code that causes linker errors if he tries to build with the Intel C++ compiler, which would apparently give quite a speed boost.  But he's never once mentioned any sort of marshalling problems, despite the tons of string data that this COM DLL passes back and forth to the Delphi program that it runs under.

    Sounds like it was build with an old version of Borland C++Builder, before things like the STL were standardized. There is this gap between early C++ and the C++1999 standard being fully implemented that caused all kinds of early C++ code to behave strangely by today's standards. Even nowadays you'll find differences between the C++ compilers because it's such a complex and sometimes ill defined language.

    The Roguewave STL as came with for example C++Builder 4, was in some important aspects not compatible with the STL as later defined in the C++1999 standard. C++Builder had some other limitations, because it's compiler was an extention of the Delphi compiler, which meant it had trouble with some concepts that were part of C++ but on of ObjectPascal.

    In the end I had no problem working with it at the time (1999-2001), because most of the things it didn't support properly were things that you'd want to avoid doing anyway.

    0
  • dhromed

    @Jaime said:

    [explanation of the workings of immutable strings]
     

    I understand this.

    I was responding to Aaron's claim that "inline" string manipulation is a rare or nonsensical task, that strings are conceptually atomic, and that mutable strings are therefore stupid. Or at least that's what I think he meant with the words "it makes no more sense". It seems a reasonable meaning to attach to those words.

    0
  • Mason_Wheeler

    @RogerWilco said:

    Sounds like it was build with an old version of Borland C++Builder, before things like the STL were standardized. There is this gap between early C++ and the C++1999 standard being fully implemented that caused all kinds of early C++ code to behave strangely by today's standards. Even nowadays you'll find differences between the C++ compilers because it's such a complex and sometimes ill defined language.
     

    Actually it's in MS Visual C++ and (AFAIK) always has been.

    0
  • derula

    Wait, what the hell? Did I start a flamewar about binary representations of strings? ... Excellent.

    0
  • blakeyrat

    @RogerWilco said:

    You want to built a good looking cross platform user interface. (which almost only leaves Qt in my opinion, .Net isn't crossplatform, and Java or GTK are too ugly, or am I forgetting something?).
     

    We just did this on another thread (the Java one). There are tons of cross-platform GUI solutions out there. And, hell, even Qt will talk to Python. (And possibly other languages.) Of course this depends on the specific combination of platforms you want to support-- nothing's cross-platform with iPhone/iPad, for example.

    BTW, .Net is crossplatform, it's just that the mono implementation isn't 100% caught-up to the MS implementation. But if you're coding in .Net 2.0, you could trivially port to Mono no problem.

    Frankly, I only see the first bulletpoint on your list as being valid. I think most people who use C++ now (game engines, for example) are doing it more out of habit than anything else.

    0
  • dhromed

    @derula said:

    Wait, what the hell? Did I start a flamewar about binary representations of strings? ... Excellent.
     

    Yeah.

    Me and my gun feel that you can die happy now.

    0
  • morbiuswilters

    @RogerWilco said:

    Then you haven't worked on a C++Builder project I once worked on, where replacing all the TLists (from the Borland VCL, which had to be compatible with Delphi), with the SLT std::list template solved a huge amount of bugs, as the compiler could all of a sudden find a lot of incorrect type casts. (TLlist is a linked list that can only store void pointers, so everything that used linked lists in the code would constantly cast void pointers to all kinds of objects.)

    I'm not sure how that is relevant at all.  So, you used a strictly typed language, it had an assload of typing bugs, you swap in a library and find your typing bugs.  What does this have to do with weakly typed languages or type coercion?  In fact, it just seems to negate the argument that strict typing does much good, because you can easily miss typing bugs if your library/compiler/environment is broken.  Still, even if we assume you catch all type-related bugs, what relevance does that have to dynamic languages?  Most of them wouldn't have those bugs to begin with.

     

    @RogerWilco said:

    As to "00" and "0000" both being numbers, I also have to disagree. At best they are arrays of numbers represented as strings, given that 0 is a number. And, given that they are of different length, it's probably important to treat them as inequal to eachother. It could for example be what you need to do to dial an outside line. A big source of WTFs is if people treat "telelphone numbers" as numbers. They are not. They are arrays of numbers, otherwise 1234 and 01234 would be the same telephone number.

    You seem to miss a finer point: their type does not indicate their function.  I'm not seeing the benefit of strict typing here.  If they are indeed integers, then you would cast them as integers anyway.  If their function is something like a telephone number or an identifier, then you'd want them as strings.  Strict typing isn't going to stop someone from casting a telephone number to an int.  Meanwhile, weak typing doesn't preclude you from treating them as strings.  The difference is that type coercion makes implicit assumptions, whereas strict typing makes you explicitly spell-out the assumptions.  In most cases, the implicit behavior is correct, in cases where it is not, you can simply explicitly spell-out the desired behavior.

     

    I suppose the fact that the implicit assumptions are less visible might make it hard for a newbie to grasp what is going on, and yet even with that, almost nobody is going to argue that strictly typed languages are less complex.  In fact, the bitching always seems to be in the other direction: dynamic languages make it too easy for non-programmers to write code.  Most people who claim that weak typing is inherently error-prone and "wrong", when compared to strict typing, seem to have three basic arguments: elitism ("dynamic languages are too easy!"); academic wanking ("typing is more pure"); or false sense of security ("typing eliminates all sorts of bugs").  I have not found any of those proven out in the real world.  And I'm not saying strict typing is bad, that it should never be used, or that there aren't niches where it is superior.  However, development in dynamic languages often has a quicker turnaround with less code written.  And the savings in verbose code often translate into fewer bugs, which seems to cancel out the rare bug that type safety would have prevented.

     

    Whatever, though.  This argument is as boring as PCs vs. Macs.  It's little more than a religious flamewar at this point.  We've even got asshats running around telling us Pascal will save us all, who in this debate are like the suicide-bombing Muslims or that dude with his "God hates fags" signs.

    0
  • ?

    @RogerWilco said:

    A simple language is one that you can make a 1 page reference card for, like Python: [url]http://home.uchicago.edu/~gan/file/python.pdf[/url]

    Nah, a simple language is one that you can [i]fully describe[/i] in two pages. Like [url=http://www.tcl.tk/man/tcl8.5/TclCmd/Tcl.htm]Tcl[/url].

    0
  • B

    @RogerWilco said:

    C++ does have it's uses however.

    We'll see about that...

    @RogerWilco said:

    You have heavily using existing code written in C or C++.*
    Only one of those is a justification for using C++.  If your existing code is in C, stick to C.  While continuing to write in C++ is a little like throwing good money after bad, but it's typically a bad idea to port a functioning program to a new language.    If you find yourself on the horns of such a dilemma, I suppose sticking with C++ is the better option.  I award you half a point.

    @RogerWilco said:

    You need very close interaction with hardware.
    Bullshit.  Use C and tie it to any of the twelve kerjillion languages that provides hooks to C.  Zero points.

    @RogerWilco said:

    You want to built a good looking cross platform user interface. (which almost only leaves Qt in my opinion, .Net isn't crossplatform, and Java or GTK are too ugly, or am I forgetting something?).
    Blakeyrat has already covered this one above, so I won't bother.  It's false, though. Zero points.

    @RogerWilco said:

    You can't rely on a VM, framework or interpreter being available or of a certain version.
    This isn't even close to a justification for C++.  There are a variety of other languages that can be compiled.  And many languages make their interpreters available under open licenses, so just pack the fucking thing in on your install CD and smile because you're not using C++.  Zero points.

    @RogerWilco said:

    You want a large amount of control over the exact execution of your code, given timing, memory or efficiency reasons.
      This is an excellent justification... for C.  Zero points.

    @RogerWilco said:

    You want to write object oriented software while being constrained by one of the above.
    This is only applicable in the very few cases where C is a good idea.  And even then, there are a few libraries out there that add OOP to C.  Or you could use Objective C.  I'll give you half a point, though.

    @RogerWilco said:

    Your available alternatives are worse.
    Like Pascal?  No points.

    @RogerWilco said:

    All of the above.
    Considering that you only made two half points above, this isn't really applicable.@RogerWilco said:
    Did I forget some? The above I have to take into account on a daily basis.
    You missed what are, in my mind, the big two reasons to use C++:

    1. You need a shitload of programmers, so it makes sense to trawl the much larger pool of available C++ applicants.
    2. Your boss says you have to.

    0
Log in to reply