Type Wars
-
Great article. >As programs grew ever more complicated in the late 70s and early 80s, the problem of keeping your types straight began to get out of hand. And it still is. > Today we call that discipline: Test Driven Development. Exactly -- the only way to verify you haven't screwed up is to test, test, and test. And, as I recently wrote[^], "[This] is why developers who promote duck-typed languages also strongly promote unit testing. Unit testing, particularly in duck-typed languages, is the "fix" for making sure you haven't screwed up the type." > we have repeatedly seen, unit test coverage close to 100% can, and is, being achieved. Really? Where? Not any Ruby or Python code I've seen over the last 5 years. I think that's a complete fiction, and is the one flaw in an otherwise really great post. > dynamic languages will become the preferred languages. I hope not. Because at least in the experience of this old programmer, duck-typed languages are great for rapid prototyping, but they're also the path to rapid disaster. I also find productivity reduced, especially when I either have to run the code to see if I screwed something up that, heck, I don't even have to compile the C# code, the Visual Studio IDE will redline it for me in the editor, or I have to take the time to write a unit test. But what do you expect. From what I've seen, people who write with duck-typed languages don't even use an IDE. I work with one guy who actually adamantly refuses to use an IDE. He does everything in Sublime. Now, granted, Sublime is an awesome editor, but at best all it does is syntax highlighting and some smart auto-completion, and yes, I use it and love for when I have to work in Javascript and Python across a VM bridge, the auto-SFTP is awesome, but nothing, absolutely nothing (except maybe what JetBrains is working on with their C# IDE) comes close to what Microsoft has achieved with Visual Studio. For me, there is no war. For anything but small scale projects, duck-typed languages are absolutely the wrong choice, and at this point, I'd rather be flipping hamburgers than writing flippin' unit tests to verify something the IDE can tell me I did wrong when I use a strongly typed language. Marc
-
I generally struggle to read "Uncle Bob's" screed with an open-mind; for my tastes, there's such an evangelical, almost messianic, and self-promoting, flavor to his style that my automatic the-one-and-only-one-truth shields go up. In this article, I really don't think the global characterization of programming across a few decades falls as neatly into a SmallTalky-and-ducky-typish and strong-typish-Pascaly-Cish dichotomy as the author describes. No mention of Lisp, Algol, Modula, Ada, Simula, Cobol, and, given the author's emphasis on the joys of assembler, I'm surprised he didn't mention the programming language Forth (which was also, imho, like TDD is for Uncle Bob, a "religion"). How about the work at Xerox Parc on languages like Sail ? Alan Kay's work ? BASIC ? One important reason for Pascal's relative success, during its "time," was the fact that academic computer science programs at top-tier universities and colleges tended to use it. I once took lecture notes for a lecture note-taking service at UC Berkeley for Doug Cooper's Pascal course: Cooper, and co-author Mike Clancy, had a best-selling book, "Oh! Pascal!" widely used in college introductory programming courses. The students were doing their homework on mainframes, from terminals ... yeah, this was 1981, or so. I share (what I perceive as) the skepticism expressed by Marc Clifton on this thread about "total code coverage," and the future as "belonging to" duck-typed languages. As to my opinion on TDD, Agile, Waterfall, Kanban, etc. ... well, I haven't really looked deeply into any of them. But, yeah, I can't see developing, particularly in the prototyping phase, without constant testing. Now "SOLID:" that seems to me to be where the "meat" is, and that's where I'm investing my get-better-brain resources at the moment. I disclaimer what I've expressed here by noting that I write from a perspective of being a solo developer enjoying a con$traint free self-employed context in which I can pursue what I want to pursue, which is, at this time, often "academic." Should the Fates somehow move me to become a part of a development team, then I would expect, and look forward to, some over-arching software management discipline ... hopefully one that does not involve frequent meetings ... remember Joel Spolsky's comments on meetings [^] ... [
-
I generally struggle to read "Uncle Bob's" screed with an open-mind; for my tastes, there's such an evangelical, almost messianic, and self-promoting, flavor to his style that my automatic the-one-and-only-one-truth shields go up. In this article, I really don't think the global characterization of programming across a few decades falls as neatly into a SmallTalky-and-ducky-typish and strong-typish-Pascaly-Cish dichotomy as the author describes. No mention of Lisp, Algol, Modula, Ada, Simula, Cobol, and, given the author's emphasis on the joys of assembler, I'm surprised he didn't mention the programming language Forth (which was also, imho, like TDD is for Uncle Bob, a "religion"). How about the work at Xerox Parc on languages like Sail ? Alan Kay's work ? BASIC ? One important reason for Pascal's relative success, during its "time," was the fact that academic computer science programs at top-tier universities and colleges tended to use it. I once took lecture notes for a lecture note-taking service at UC Berkeley for Doug Cooper's Pascal course: Cooper, and co-author Mike Clancy, had a best-selling book, "Oh! Pascal!" widely used in college introductory programming courses. The students were doing their homework on mainframes, from terminals ... yeah, this was 1981, or so. I share (what I perceive as) the skepticism expressed by Marc Clifton on this thread about "total code coverage," and the future as "belonging to" duck-typed languages. As to my opinion on TDD, Agile, Waterfall, Kanban, etc. ... well, I haven't really looked deeply into any of them. But, yeah, I can't see developing, particularly in the prototyping phase, without constant testing. Now "SOLID:" that seems to me to be where the "meat" is, and that's where I'm investing my get-better-brain resources at the moment. I disclaimer what I've expressed here by noting that I write from a perspective of being a solo developer enjoying a con$traint free self-employed context in which I can pursue what I want to pursue, which is, at this time, often "academic." Should the Fates somehow move me to become a part of a development team, then I would expect, and look forward to, some over-arching software management discipline ... hopefully one that does not involve frequent meetings ... remember Joel Spolsky's comments on meetings [^] ... [
BillWoodruff wrote:
How about the work at Xerox Parc on languages like Sail ?
Dang, I'm impressed. I used SAIL to program a robotic arm to move chess pieces. Was my first introduction to concurrent programming, I loved it so much I wrote a "wedge" for the Commodore PET BASIC to create co-subroutines, complete with software-based context switching to simulate threading. Fun times! Marc
Imperative to Functional Programming Succinctly Contributors Wanted for Higher Order Programming Project! Learning to code with python is like learning to swim with those little arm floaties. It gives you undeserved confidence and will eventually drown you. - DangerBunny
-
-
BillWoodruff wrote:
How about the work at Xerox Parc on languages like Sail ?
Dang, I'm impressed. I used SAIL to program a robotic arm to move chess pieces. Was my first introduction to concurrent programming, I loved it so much I wrote a "wedge" for the Commodore PET BASIC to create co-subroutines, complete with software-based context switching to simulate threading. Fun times! Marc
Imperative to Functional Programming Succinctly Contributors Wanted for Higher Order Programming Project! Learning to code with python is like learning to swim with those little arm floaties. It gives you undeserved confidence and will eventually drown you. - DangerBunny
Marc, methinks we had the curse, and blessing, of living in "interesting times," and, then, coming out of those times with, evidently, our intellect, curiosity, and passion for the Goddess Techne, alive-and-well. One of my favorite memories is the day when, still a newcomer at Adobe, I had John Warnock and Chuck Geschke visit my office for a demo of an object-oriented mvc prototype I did in PostScript on the NeXT machine (while working at Emerald City Software, which was then acquired by Adobe). I named this folly "Toto," and gave it the slogan: "We're not in Kansas anymore" :) I soon learned that I was one of the very few programmers at Adobe who actually liked PostScript qua programming language. cheers, Bill
«There is a spectrum, from "clearly desirable behaviour," to "possibly dodgy behavior that still makes some sense," to "clearly undesirable behavior." We try to make the latter into warnings or, better, errors. But stuff that is in the middle category you don’t want to restrict unless there is a clear way to work around it.» Eric Lippert, May 14, 2008
-
Great article. >As programs grew ever more complicated in the late 70s and early 80s, the problem of keeping your types straight began to get out of hand. And it still is. > Today we call that discipline: Test Driven Development. Exactly -- the only way to verify you haven't screwed up is to test, test, and test. And, as I recently wrote[^], "[This] is why developers who promote duck-typed languages also strongly promote unit testing. Unit testing, particularly in duck-typed languages, is the "fix" for making sure you haven't screwed up the type." > we have repeatedly seen, unit test coverage close to 100% can, and is, being achieved. Really? Where? Not any Ruby or Python code I've seen over the last 5 years. I think that's a complete fiction, and is the one flaw in an otherwise really great post. > dynamic languages will become the preferred languages. I hope not. Because at least in the experience of this old programmer, duck-typed languages are great for rapid prototyping, but they're also the path to rapid disaster. I also find productivity reduced, especially when I either have to run the code to see if I screwed something up that, heck, I don't even have to compile the C# code, the Visual Studio IDE will redline it for me in the editor, or I have to take the time to write a unit test. But what do you expect. From what I've seen, people who write with duck-typed languages don't even use an IDE. I work with one guy who actually adamantly refuses to use an IDE. He does everything in Sublime. Now, granted, Sublime is an awesome editor, but at best all it does is syntax highlighting and some smart auto-completion, and yes, I use it and love for when I have to work in Javascript and Python across a VM bridge, the auto-SFTP is awesome, but nothing, absolutely nothing (except maybe what JetBrains is working on with their C# IDE) comes close to what Microsoft has achieved with Visual Studio. For me, there is no war. For anything but small scale projects, duck-typed languages are absolutely the wrong choice, and at this point, I'd rather be flipping hamburgers than writing flippin' unit tests to verify something the IDE can tell me I did wrong when I use a strongly typed language. Marc
Marc Clifton wrote:
except maybe what JetBrains is working on with their C# IDE
Not just their C# IDE. I spend a fair bit of time in their JS IDE, and the completion, highlighting, squiggles, and debugging is way better than I've ever had in Visual Studio (using JS). To be fair, I've not done any JS in VS2015. Just stickin' with what works these days.
-
Great article. >As programs grew ever more complicated in the late 70s and early 80s, the problem of keeping your types straight began to get out of hand. And it still is. > Today we call that discipline: Test Driven Development. Exactly -- the only way to verify you haven't screwed up is to test, test, and test. And, as I recently wrote[^], "[This] is why developers who promote duck-typed languages also strongly promote unit testing. Unit testing, particularly in duck-typed languages, is the "fix" for making sure you haven't screwed up the type." > we have repeatedly seen, unit test coverage close to 100% can, and is, being achieved. Really? Where? Not any Ruby or Python code I've seen over the last 5 years. I think that's a complete fiction, and is the one flaw in an otherwise really great post. > dynamic languages will become the preferred languages. I hope not. Because at least in the experience of this old programmer, duck-typed languages are great for rapid prototyping, but they're also the path to rapid disaster. I also find productivity reduced, especially when I either have to run the code to see if I screwed something up that, heck, I don't even have to compile the C# code, the Visual Studio IDE will redline it for me in the editor, or I have to take the time to write a unit test. But what do you expect. From what I've seen, people who write with duck-typed languages don't even use an IDE. I work with one guy who actually adamantly refuses to use an IDE. He does everything in Sublime. Now, granted, Sublime is an awesome editor, but at best all it does is syntax highlighting and some smart auto-completion, and yes, I use it and love for when I have to work in Javascript and Python across a VM bridge, the auto-SFTP is awesome, but nothing, absolutely nothing (except maybe what JetBrains is working on with their C# IDE) comes close to what Microsoft has achieved with Visual Studio. For me, there is no war. For anything but small scale projects, duck-typed languages are absolutely the wrong choice, and at this point, I'd rather be flipping hamburgers than writing flippin' unit tests to verify something the IDE can tell me I did wrong when I use a strongly typed language. Marc
Preach Brother! Preach!:thumbsup::thumbsup::thumbsup::thumbsup::thumbsup:
#SupportHeForShe Government can give you nothing but what it takes from somebody else. A government big enough to give you everything you want is big enough to take everything you've got, including your freedom.-Ezra Taft Benson You must accept 1 of 2 basic premises: Either we are alone in the universe or we are not alone. Either way, the implications are staggering!-Wernher von Braun
-
Great article. >As programs grew ever more complicated in the late 70s and early 80s, the problem of keeping your types straight began to get out of hand. And it still is. > Today we call that discipline: Test Driven Development. Exactly -- the only way to verify you haven't screwed up is to test, test, and test. And, as I recently wrote[^], "[This] is why developers who promote duck-typed languages also strongly promote unit testing. Unit testing, particularly in duck-typed languages, is the "fix" for making sure you haven't screwed up the type." > we have repeatedly seen, unit test coverage close to 100% can, and is, being achieved. Really? Where? Not any Ruby or Python code I've seen over the last 5 years. I think that's a complete fiction, and is the one flaw in an otherwise really great post. > dynamic languages will become the preferred languages. I hope not. Because at least in the experience of this old programmer, duck-typed languages are great for rapid prototyping, but they're also the path to rapid disaster. I also find productivity reduced, especially when I either have to run the code to see if I screwed something up that, heck, I don't even have to compile the C# code, the Visual Studio IDE will redline it for me in the editor, or I have to take the time to write a unit test. But what do you expect. From what I've seen, people who write with duck-typed languages don't even use an IDE. I work with one guy who actually adamantly refuses to use an IDE. He does everything in Sublime. Now, granted, Sublime is an awesome editor, but at best all it does is syntax highlighting and some smart auto-completion, and yes, I use it and love for when I have to work in Javascript and Python across a VM bridge, the auto-SFTP is awesome, but nothing, absolutely nothing (except maybe what JetBrains is working on with their C# IDE) comes close to what Microsoft has achieved with Visual Studio. For me, there is no war. For anything but small scale projects, duck-typed languages are absolutely the wrong choice, and at this point, I'd rather be flipping hamburgers than writing flippin' unit tests to verify something the IDE can tell me I did wrong when I use a strongly typed language. Marc
Marc Clifton wrote:
For anything but small scale projects, duck-typed languages are absolutely the wrong choice, and at this point, I'd rather be flipping hamburgers than writing flippin' unit tests to verify something the IDE can tell me I did wrong when I use a strongly typed language.
Or we can use F# with its strong type inference on steroids. :)
Kevin