It's a backup...
-
@PedanticCurmudgeon said:
What's worse is that when he comes this close to being right (make wrong code look wrong), but for some reason fails to take the next logical step (make wrong code not compile), his not-quite-there attempt still gets parroted perpetually on programmers.stackexchange.
Which works to a point. It starts falling apart when you move beyond a dichotomy such as "safe string" and "unsafe string". The other problem is that it really requires language-level support. Most strongly-typed languages are still going to permit you to concatenate an unsafe string with a safe string. And the libraries you work with are probably just going to support plain-old strings. And unless the only safe strings come from string literals (which would severely limit things) there is going to be a mechanism to cast unsafe strings to safe strings, and the compiler can't tell you when somebody uses that incorrectly.
So the utility of having the compiler catch such errors drops off pretty quickly, as it does almost every time you try to use the type system to force people to write better code.
-
@PedanticCurmudgeon said:
@C-Octothorpe said:
@PedanticCurmudgeon said:
And one day, if I study and work hard, I may be done and gets things smart.Filed under: smart and gets things done
... and gosh darn it, people like you.That article is vey much along the lines of a conversation I had with Ted Neward back at the Microsoft MVP summit. We were talking about "respected names" in the field, and how (IMHO quite often) their suggestions/recommendations seem a little "off". He brought up a very interesting point I had never tought of before. He pointed out that many (mos of the one's in question) has never dealt with a full life cycle (the many years between concept and retirement) of a single program/project. I had never looked at their backgrounds in this way, and did some studying, sure enough, most of them were "single role" types (many were just "concept types"), so it made sense that while their ideas had significant merit, they were not always "great ideas" when considered from a holistic point of view....Made a lot of things clear to me.
-
@morbiuswilters said:
@PedanticCurmudgeon said:
Have you tried Haskell?What's worse is that when he comes this close to being right (make wrong code look wrong), but for some reason fails to take the next logical step (make wrong code not compile), his not-quite-there attempt still gets parroted perpetually on programmers.stackexchange.
Which works to a point. It starts falling apart when you move beyond a dichotomy such as "safe string" and "unsafe string". The other problem is that it really requires language-level support. Most strongly-typed languages are still going to permit you to concatenate an unsafe string with a safe string.
@morbiuswilters said:And the libraries you work with are probably just going to support plain-old strings. And unless the only safe strings come from string literals (which would severely limit things) there is going to be a mechanism to cast unsafe strings to safe strings, and the compiler can't tell you when somebody uses that incorrectly.
Yes, but keep in mind the context: "make wrong code look wrong" wasn't meant to address the mechanism, it was meant to address remembering to use it.
-
@PedanticCurmudgeon said:
Have you tried Haskell?
No, but most software development isn't happening in Haskell, so it's not a particularly useful suggestion. I still imagine it would have trouble enforcing complex constraints via the type system.
@PedanticCurmudgeon said:
Yes, but keep in mind the context: "make wrong code look wrong" wasn't meant to address the mechanism, it was meant to address remembering to use it.
I understand that. My point was simply that such mechanisms can be moderately useful in some circumstances, but unfortunately leave much to be desired.
