Small>t<alk

Author: raganwald

Diff for: 2005/10/im-not-young-enough-to-know-everything.html

@@ -71,7 +71,7 @@
 							</div>
 
 							<div class="blogComment">
-								<a name="114247937095560026"></a> 				james,<BR/><BR/>With a dynamic model, you actually have more accurate autocomplete assistance in a real dynamic IDE, because the IDE itself has _more_ information about the types of the objects, not less.<BR/><BR/>Refactoring in a dynamic IDE is streamlined and simplified, for the same reasons, but you'll find that you don't need to refactor much, if at all, if using a good dynamic language like Ruby.<BR/><BR/>In a dynamic world, you just ask the object what its capabilities are. You don't have to look up call sites in the source code. What dynamic language have you been using that does not have this capability?<BR/><BR/>Also, Objective-C offers dynamic typing and optional static typing. The static typing allows the compiler to detect many type errors at compile time. In practice, you use static typing in most places in Objective-C, because it's still C at the core, and it's still a pain to go through the debug-edit-test cycle to find out you've gotten the type of something wrong. In a fully dynamic language, it really isn't an issue.<BR/><BR/>Again, Ruby is the exemplar. SmallTalk (from whence large bits of Objective-C and Ruby came) is both the original object-oriented language and a darn fine 'dynamic language' in the sense we know it today.<br />
+								<a name="114247937095560026"></a> 				james,<BR/><BR/>With a dynamic model, you actually have more accurate autocomplete assistance in a real dynamic IDE, because the IDE itself has _more_ information about the types of the objects, not less.<BR/><BR/>Refactoring in a dynamic IDE is streamlined and simplified, for the same reasons, but you'll find that you don't need to refactor much, if at all, if using a good dynamic language like Ruby.<BR/><BR/>In a dynamic world, you just ask the object what its capabilities are. You don't have to look up call sites in the source code. What dynamic language have you been using that does not have this capability?<BR/><BR/>Also, Objective-C offers dynamic typing and optional static typing. The static typing allows the compiler to detect many type errors at compile time. In practice, you use static typing in most places in Objective-C, because it's still C at the core, and it's still a pain to go through the debug-edit-test cycle to find out you've gotten the type of something wrong. In a fully dynamic language, it really isn't an issue.<BR/><BR/>Again, Ruby is the exemplar. Smalltalk (from whence large bits of Objective-C and Ruby came) is both the original object-oriented language and a darn fine 'dynamic language' in the sense we know it today.<br />
 								<div class="byline"><a href="http://raganwald.github.com/2006/03/fair-and-balanced-look-at-static-vs.html?showComment=1142479320000#c114247937095560026" title="permanent link">#</a> posted by <span style="line-height:16px" class="comment-icon anon-comment-icon"><img src="http://www.blogger.com/img/anon16-rounded.gif" alt="Anonymous" style="display:inline;" /></span>&nbsp;<span class="anon-comment-author">Anonymous</span> : 10:22 PM</div>
 
 								<span class="item-control blog-admin pid-1482585217"><a style="border:none;" href="http://www.blogger.com/delete-comment.g?blogID=7618424&postID=114247937095560026" title="Delete Comment" ><span class="delete-comment-icon">&nbsp;</span></a></span>

Diff for: 2006/01/finding-signal-to-noise-ratio-in-never.html

@@ -24,7 +24,7 @@
 				<span class="PostTitle">
 
 					<a href="http://raganwald.github.com/2006/05/reg-suffering-from-high-altitude.html" title="permanent link">Reg suffering from high-altitude hypoxia?</a></span>
-					<div style="clear:both;"></div>Respected Java and XML Guru <a href="http://www.elharo.com/">Elliotte Rusty Harold</a> has posted <a href="http://cafe.elharo.com/java/eliminating-final/">a very nice discussion of Eiffel's Design by Contract principles</a>. Along the way, he makes a vicious ad hominem attack, accusing me of architecture astronautics (he actually stooped to using using the word "theorist," which means, <span style="font-style: italic;">someone who blogs when they should be coding</span>). But I digress.<br /><br /><a href="http://www.flickr.com/photos/raganwald/152207513/"><img src="http://static.flickr.com/46/152207513_b3be666020.jpg" width="375" height="500" alt="The World's Longest Single Arch Bridge" /></a><br /><br />The gist of his post is that since we don't have language-level support for Design By Contract, we ought to use <span style="font-weight: bold;">final</span> to accomplish as much invariant enforcement as possible. He suggests that final should be the default choice, that interfaces should be rare and concrete classes plentiful in a design, and that support for polymorphism is less-important than enforcing invariants:<br /><blockquote style="font-style: italic;">Preconditions, postconditions, and invariants are at the core of data encapsulation. They are the first and most important pillar of object oriented programming. Inheritance and polymorphism are second and third respectively, and are less important.</blockquote>While controversial, this argument is cogent. I would say it is consistent with a specific kind of design philosophy, one that would be as at home in Ada or Modula as it is in Java. This is in marked opposition to the design philosophy of SmallTalk and Squeak, so I would say it is <span style="font-style: italic;">not very object oriented</span>.<br /><br />Is that a bad thing? <span style="font-weight: bold;">I don't think so</span>. Principles like data encapsulization, modularity, contract enforcement, and componentization are extremely valuable and can be realized in many different ways. For example, what do you think the <a href="http://www.erlang.org/">Erlang</a> programming language or the <a href="http://en.wikipedia.org/wiki/Linda_%28coordination_language%29">Linda</a> communication and co&ouml;rdination frameworks are are all about? It's not just concurrency, dude.<br /><br />The large-scale Java applications I've seen have been particularly devoid of true object orientation, and people seem perfectly happy with that. (Rough metric: the OO-ness of a Java application is congruent to the reciprocal of the number of public static methods in the source code).<br /><br />So my conclusion is that if you want some advice on writing robust, large scale Java applications in a style that has been proven to be useful over the last several decades, you will find Rusty's post informative.<br /><br />p.s. My tongue was in my cheek when I composed the title and suggested that one of the most socially conscious Java bloggers in the world was vicious. But you knew that.<br /><br />p.p.s. If you feel that either Rusty or I can be correct but not both of us, please accept my condolences. How long has it been since imagination passed out of your life?<div style="clear:both; padding-bottom:0.25em"></div><p class="blogger-labels">Labels: <a rel='tag' href="http://raganwald.github.com/archives/labels/java.html">java</a></p>&nbsp;
+					<div style="clear:both;"></div>Respected Java and XML Guru <a href="http://www.elharo.com/">Elliotte Rusty Harold</a> has posted <a href="http://cafe.elharo.com/java/eliminating-final/">a very nice discussion of Eiffel's Design by Contract principles</a>. Along the way, he makes a vicious ad hominem attack, accusing me of architecture astronautics (he actually stooped to using using the word "theorist," which means, <span style="font-style: italic;">someone who blogs when they should be coding</span>). But I digress.<br /><br /><a href="http://www.flickr.com/photos/raganwald/152207513/"><img src="http://static.flickr.com/46/152207513_b3be666020.jpg" width="375" height="500" alt="The World's Longest Single Arch Bridge" /></a><br /><br />The gist of his post is that since we don't have language-level support for Design By Contract, we ought to use <span style="font-weight: bold;">final</span> to accomplish as much invariant enforcement as possible. He suggests that final should be the default choice, that interfaces should be rare and concrete classes plentiful in a design, and that support for polymorphism is less-important than enforcing invariants:<br /><blockquote style="font-style: italic;">Preconditions, postconditions, and invariants are at the core of data encapsulation. They are the first and most important pillar of object oriented programming. Inheritance and polymorphism are second and third respectively, and are less important.</blockquote>While controversial, this argument is cogent. I would say it is consistent with a specific kind of design philosophy, one that would be as at home in Ada or Modula as it is in Java. This is in marked opposition to the design philosophy of Smalltalk and Squeak, so I would say it is <span style="font-style: italic;">not very object oriented</span>.<br /><br />Is that a bad thing? <span style="font-weight: bold;">I don't think so</span>. Principles like data encapsulization, modularity, contract enforcement, and componentization are extremely valuable and can be realized in many different ways. For example, what do you think the <a href="http://www.erlang.org/">Erlang</a> programming language or the <a href="http://en.wikipedia.org/wiki/Linda_%28coordination_language%29">Linda</a> communication and co&ouml;rdination frameworks are are all about? It's not just concurrency, dude.<br /><br />The large-scale Java applications I've seen have been particularly devoid of true object orientation, and people seem perfectly happy with that. (Rough metric: the OO-ness of a Java application is congruent to the reciprocal of the number of public static methods in the source code).<br /><br />So my conclusion is that if you want some advice on writing robust, large scale Java applications in a style that has been proven to be useful over the last several decades, you will find Rusty's post informative.<br /><br />p.s. My tongue was in my cheek when I composed the title and suggested that one of the most socially conscious Java bloggers in the world was vicious. But you knew that.<br /><br />p.p.s. If you feel that either Rusty or I can be correct but not both of us, please accept my condolences. How long has it been since imagination passed out of your life?<div style="clear:both; padding-bottom:0.25em"></div><p class="blogger-labels">Labels: <a rel='tag' href="http://raganwald.github.com/archives/labels/java.html">java</a></p>&nbsp;
 					<span class="PostFooter">
 
 						&para; <a href="http://raganwald.github.com/2006/05/reg-suffering-from-high-altitude.html" title="permanent link">10:03 AM</a>

Diff for: 2006/03/fair-and-balanced-look-at-static-vs.html

@@ -24,7 +24,7 @@
 				<span class="PostTitle">
 
 					<a href="http://raganwald.github.com/2006/08/causality-or-correlation.html" title="permanent link">Causality? Or Correlation?</a></span>
-					<div style="clear:both;"></div>There's an interesting thread on <a href="http://c2.com/cgi/wiki">Ward's Wiki</a>:  <a href="http://c2.com/cgi/wiki?CouldExtremeProgrammingHaveArisenWithoutSmalltalk"><span style="font-style: italic;">Could Extreme Programming Have Arisen Without SmallTalk?</span></a><span style="font-style: italic;"> </span>(for those who didn't know this, the earliest use of Extreme Programming was on a commercial SmallTalk project.)<br /><br />Looking over the discusion, I notice that is heavily weighted towards arguing cause-and-effect. The abridged version is: <span style="font-style: italic;">SmallTalk has these properties, which lead you to these practices, which are codified as XP</span>. The implication is that if everyone had been using SmallTalk (perhaps because it had "won the war with VB"), XP would have been independently discovered/invented dozens or hundreds of times.<br /><br /><style type="text/css">.flickr-photo { border: solid 2px #000000; }.flickr-yourcomment { }.flickr-frame { text-align: left; padding: 3px; }.flickr-caption { font-size: 0.8em; margin-top: 0px; }</style><div class="flickr-frame"> <a href="http://www.flickr.com/photos/raganwald/152208719/" title="photo sharing"><img src="http://static.flickr.com/54/152208719_7ba6251015.jpg" class="flickr-photo" alt="Cascade" /></a><br /><span class="flickr-caption"><a href="http://www.flickr.com/photos/raganwald/152208719/">Cascade</a>, originally uploaded by <a href="http://www.flickr.com/people/raganwald/">raganwald</a>.</span></div><br />I am unconvinced. Instead, I suggest that both SmallTalk and XP are common effects of a hidden variable. They are <span style="font-style: italic;">correlated</span>.<br /><br />The kind of people that chose SmallTalk for an enterprise application at a time when OOP was considered an unproven language paradigm, and at a time when running "serious" applications on a virtual machine was considered "unprofessional," are the kind of people that will discover or invent new ways to do things.<br /><br />Paul Graham said similar thing in his <a href="http://www.paulgraham.com/pypar.html">Python Paradox</a> essay: <span style="font-style: italic;">if a company chooses to write its software in a comparatively esoteric language, they'll be able to hire better programmers, because they'll attract only those who cared enough to learn it</span>.<br /><br />What I like about this quote is that it says nothing about whether the "esoteric language" is more productive. It simply says something about the kind of person who learns an esoteric language. And likewise, you can infer something about the kind of project that is implemented in a comparatively esoteric language.<br /><br />I conclude that the relationship between SmallTalk and XP is one of correlation, not causality. In my opinion, radically different practices like XP are most likely to be discovered/invented by people who are willing to bet on radically different tools like (at the time) SmallTalk.<div style="clear:both; padding-bottom:0.25em"></div>&nbsp;
+					<div style="clear:both;"></div>There's an interesting thread on <a href="http://c2.com/cgi/wiki">Ward's Wiki</a>:  <a href="http://c2.com/cgi/wiki?CouldExtremeProgrammingHaveArisenWithoutSmalltalk"><span style="font-style: italic;">Could Extreme Programming Have Arisen Without Smalltalk?</span></a><span style="font-style: italic;"> </span>(for those who didn't know this, the earliest use of Extreme Programming was on a commercial Smalltalk project.)<br /><br />Looking over the discusion, I notice that is heavily weighted towards arguing cause-and-effect. The abridged version is: <span style="font-style: italic;">Smalltalk has these properties, which lead you to these practices, which are codified as XP</span>. The implication is that if everyone had been using Smalltalk (perhaps because it had "won the war with VB"), XP would have been independently discovered/invented dozens or hundreds of times.<br /><br /><style type="text/css">.flickr-photo { border: solid 2px #000000; }.flickr-yourcomment { }.flickr-frame { text-align: left; padding: 3px; }.flickr-caption { font-size: 0.8em; margin-top: 0px; }</style><div class="flickr-frame"> <a href="http://www.flickr.com/photos/raganwald/152208719/" title="photo sharing"><img src="http://static.flickr.com/54/152208719_7ba6251015.jpg" class="flickr-photo" alt="Cascade" /></a><br /><span class="flickr-caption"><a href="http://www.flickr.com/photos/raganwald/152208719/">Cascade</a>, originally uploaded by <a href="http://www.flickr.com/people/raganwald/">raganwald</a>.</span></div><br />I am unconvinced. Instead, I suggest that both Smalltalk and XP are common effects of a hidden variable. They are <span style="font-style: italic;">correlated</span>.<br /><br />The kind of people that chose Smalltalk for an enterprise application at a time when OOP was considered an unproven language paradigm, and at a time when running "serious" applications on a virtual machine was considered "unprofessional," are the kind of people that will discover or invent new ways to do things.<br /><br />Paul Graham said similar thing in his <a href="http://www.paulgraham.com/pypar.html">Python Paradox</a> essay: <span style="font-style: italic;">if a company chooses to write its software in a comparatively esoteric language, they'll be able to hire better programmers, because they'll attract only those who cared enough to learn it</span>.<br /><br />What I like about this quote is that it says nothing about whether the "esoteric language" is more productive. It simply says something about the kind of person who learns an esoteric language. And likewise, you can infer something about the kind of project that is implemented in a comparatively esoteric language.<br /><br />I conclude that the relationship between Smalltalk and XP is one of correlation, not causality. In my opinion, radically different practices like XP are most likely to be discovered/invented by people who are willing to bet on radically different tools like (at the time) Smalltalk.<div style="clear:both; padding-bottom:0.25em"></div>&nbsp;
 					<span class="PostFooter">
 
 						&para; <a href="http://raganwald.github.com/2006/08/causality-or-correlation.html" title="permanent link">9:57 AM</a>