 |
 | Home | Contact Us | FAQ | Search & Site Map | Link to Us |
 | Sign In | Join | Other 45 Sites in Network |
Java Forum / General / December 2007Java Philosophy
Hi Folks, I have now played with java for a while and I can't get very comfortable with it. I don't really /dis/like, but it just hasn't "clicked" yet. Maybe that is because I come from the Python world, which is (almost) completely different in approach. Specifically I find Java to be overly paranoid sometimes (what with interfaces, typing declarations, etc ...). I see their value for optimization, but they hurt my brain because I'm just used to the freedom. I'm not writing this as a flame; maybe some Python-folks here can understand me. What I'd like now is some sort of "Java Philosophy" text. Something like a "spiritual guide" to Java, that would convey the right mindset for it. A quick googling found me nothing that seemed consentient, most was rather personal views. I've read the Java-is-not-Python thing, but that didn't cut it (felt lame). Any ideas? I'd love to hear them. thx /W >completely different in approach. Specifically I find Java to be overly >paranoid sometimes (what with interfaces, typing declarations, etc ...). >I see their value for optimization, You see interfaces and typing declarations having a value for optimization? Then, maybe you can explain: What do they optimize? How do they do this? >What I'd like now is some sort of "Java Philosophy" text. Something like >a "spiritual guide" to Java, that would convey the right mindset for it. To get the mindset, use Java. See also http://norvig.com/21-days.html >> completely different in approach. Specifically I find Java to be overly >> paranoid sometimes (what with interfaces, typing declarations, etc ...). >> I see their value for optimization, > > You see interfaces and typing declarations > having a value for optimization? Yes. Granted, I didn't give it that much thought. > Then, maybe you can explain: > > What do they optimize? > > How do they do this? No. I'm not experienced enough to do so, and from the mere fact that you ask this, I reckon that I was wrong in assuming they have optimization-value. I was thinking something along the lines of memory allocation or so. You know, the friendly and much more useful way to point this out would have been to just explain how my assumptions were wrong. >> What I'd like now is some sort of "Java Philosophy" text. Something like >> a "spiritual guide" to Java, that would convey the right mindset for it. > > To get the mindset, use Java. Oh thanks. I hadn't thought of that. You know how many Python programs I've seen that were essentially Perl-, Basic- or (very often) Java- programms trying to break free? I was hoping (and still do) that there is some form of common "idealism" regarding how to write Java code. > See also > > http://norvig.com/21-days.html Cute. I'm not in a rush, however. I just like to fly above as well as dive in. /W >You know, the friendly and much more useful way to point this out >would have been to just explain how my assumptions were wrong. An interface in Java is a means to write documentation (via JavaDoc) for a verb once, so that the documentation can be shared by several classes implementing this verb. For example, the verb »compareTo« is being documented in http://download.java.net/jdk7/docs/api/java/lang/Comparable.html#compareTo(T) The documentation is refered in the following two classes, each of which contains an implementation of this verb. http://download.java.net/jdk7/docs/api/java/lang/Integer.html http://download.java.net/jdk7/docs/api/java/lang/String.html The documentation does not have to be given twice in each of these classes. Instead both can refer the single documention in the interface. The verb »compareTo« has the same meaning in both classes, but it might have different implementations. Only its meaning (its interface and behavior) is relevant for clients, so it is all a client programmer needs to know. (Interfaces also are used for other purposes. Documentation sharing is only one of them.) What means does Python use to share documentation that is the same for a verb appearing in two classes between those two classes, so that there do not have to be two copies of the documentation in each class? > [snip useful explanation] > What means does Python use to share documentation that is > the same for a verb appearing in two classes between those > two classes, so that there do not have to be two copies > of the documentation in each class? None, really, apart from inheriting docstrings from superclasses (Python does multiple inheritance). Duck-typing usually alleviates the need for different implementations of the "same" method. But lets not get into any Python-vs-Java discussions please. /W >>> completely different in approach. Specifically I find Java to be >>> overly paranoid sometimes (what with interfaces, typing declarations, [quoted text clipped - 13 lines] > ask this, I reckon that I was wrong in assuming they have > optimization-value. Type declarations normally permit faster execution, compared to languages like Python, Ruby, Perl, etc., by an order of magnitude or so, because actual machines use typed data only, and have to go far out of their way to fake typeless variables. This is not normally called "optimization" because, traditionally, it is regarded as mere baseline performance that "optimization" should proceed to improve upon. Interfaces have more to do with catching logic errors at compile time (instead of at run time) than they do with speed.  SignatureJohn W. Kennedy "Give up vows and dogmas, and fixed things, and you may grow like That. ...you may come to think a blow bad, because it hurts, and not because it humiliates. You may come to think murder wrong, because it is violent, and not because it is unjust." -- G. K. Chesterton. "The Ball and the Cross" >>>> completely different in approach. Specifically I find Java to be >>>> overly paranoid sometimes (what with interfaces, typing [quoted text clipped - 23 lines] > Interfaces have more to do with catching logic errors at compile time > (instead of at run time) than they do with speed. And this leads us right into the philosophy of Java. Java is a strongly-typed, object-oriented, network-aware, inherently concurrent dynamic language. SignatureLew >Maybe that is because I come from the Python world, which is (almost) >completely different in approach. Specifically I find Java to be overly >paranoid sometimes (what with interfaces, typing declarations, etc ...). >I see their value for optimization, but they hurt my brain because I'm >just used to the freedom. I'm not writing this as a flame; maybe some >Python-folks here can understand me. This is a very common feeling when you transition from a weakly typed language to a more strongly typed one. I expect that the only way to overcome it is to understand and embrace the advantages that stronger typing gives you. >What I'd like now is some sort of "Java Philosophy" text. Something like >a "spiritual guide" to Java, that would convey the right mindset for it. >A quick googling found me nothing that seemed consentient, most was >rather personal views. I've read the Java-is-not-Python thing, but that >didn't cut it (felt lame). In a nutshell (and probably with some important inaccuracies), this is the philosophy that Java wants you to embrace: - The compiler should be given the maximum possible capability to help you detect errors in your code so that you may find and fix them prior to deployment. While I haven't coded any Python, I did code some ECMAScript a while back and it occurred to me that the only way in which I could get my ECMAScript code to be anywhere near my Java code in terms of robustness was by significantly increasing the scope of my unit test suite so as to cover variable types etc. And I'm not sure that this would ever be able to get me the same robustness as Java does by default. Of course, there may be lint-like tools available for these languages that are able to help you out further - I haven't looked into this. Cheers, Bent D SignatureBent Dalager - bcd@pvv.org - http://www.pvv.org/~bcd powered by emacs > In a nutshell (and probably with some important inaccuracies), this is > the philosophy that Java wants you to embrace: > > - The compiler should be given the maximum possible capability to help > you detect errors in your code so that you may find and fix them prior > to deployment. OK. That particular point is addressed in the tutorial as well. Now that you point it again, I will maybe perhaps start considering giving it some thought. :) > While I haven't coded any Python, I did code some ECMAScript a while > back and it occurred to me that the only way in which I could get my [quoted text clipped - 3 lines] > would ever be able to get me the same robustness as Java does by > default. Maybe this is (one of) the crucial point(s): Java was created with "the industry" in mind, doing big projects, grand "deployment" and all. That would serve well to justify the rigor of it; it catches certain errors before anybody else sees your code. /W Hi Wildemar, You wrote, > I have now played with java for a while and I can't get very comfortable > with it. I don't really /dis/like, but it just hasn't "clicked" yet. > > Maybe that is because I come from the Python world, which is (almost) > completely different in approach. Well the problem is that you come from Python Background. Had you come from C++ background, like me, you would have loved the simplicity, elegance and productivity of Java. But still if you need convincing about Java being strongly typed then here is the argument: Being strongly typed insures that you are using right values for right variables. A lot of mistakes are caught at compile time which saves a lot of headache while testing the program. This was the reason type-safe collections were introduced with JDK 1.5. I appreciated Java's being strongly typed while coding JavaScript. And for me the single most advantage of AJAX frameworks like GWT is that they let me code in Java instead of JavaScript. As far as interfaces are concerned I like them since I still remember the horrible time I spent reading the chapters on multiple inheritance in C++. It's a bit too confusing rather tan being help. What interfaces do is that they remove the complexity of the multiple inheritance yet allow us to develop useful polymorphic programs. If you want to see how effectively interface-based polymorphism can be put to use see how Database Access Objects (DAO) are created while using frameworks like Spring. That was the first time I really appreciated interfaces which allowed me to switch between JDBC based DAOs to Hibernate based DAOs by just changing a XML file. (Of course I had to write Hibernate DAOs but the coupling was changed with only XML, no change to other business logic code.) As far as a book explaining "Java Philosophy" is concerned I don't know if any such book exists. But from whatever I have read if anything can come closer to become "The Standard way of Coding in Java" then it is "Effective Java Programming Language Guide" by Joshua Bloch. Another book you may want to take a look at is "Thinking in Java" by Bruce Eckel. the book is available for free for online reading. > As far as a book explaining "Java Philosophy" is concerned I don't > know if any such book exists. But from whatever I have read if [quoted text clipped - 4 lines] > Another book you may want to take a look at is "Thinking in Java" by > Bruce Eckel. the book is available for free for online reading. That second recommendation is a tad controversial. Mr. Eckel's way of "Thinking in Java" isn't quite consonant with the likes of Bloch, Goetz or Lea. It's good, but be prepared to do a mindshift after, to accomodate the more Java-esque way of thinking in Java. SignatureLew >> As far as a book explaining "Java Philosophy" is concerned I don't >> know if any such book exists. But from whatever I have read if [quoted text clipped - 9 lines] > or Lea. It's good, but be prepared to do a mindshift after, to > accomodate the more Java-esque way of thinking in Java. I note that the second edition of Block's book covers Java SE 6. Not yet available from Amazon but RSN? > I note that the second edition of Block's book covers Java SE 6. Not yet > available from Amazon but RSN? You did mean Bloch's book. SignatureLew >> I note that the second edition of Block's book covers Java SE 6. Not >> yet available from Amazon but RSN? > > You did mean Bloch's book. Oops yes. <http://developers.sun.com/learning/javaoneonline/j1sessn.jsp?sessn=TS-1512&yr=20 06&track=coreplatform> <http://www.amazon.com/Effective-Java-Programming-Language-Guide/dp/product-descr iption/0321356683> "Availability: This title has not yet been released. You may order it now and we will ship it to you when it arrives." >>> I note that the second edition of Block's book covers Java SE 6. Not >>> yet available from Amazon but RSN? >> >> You did mean Bloch's book. > > Oops yes. I'm a tad sensitive about the spelling of that particular surname. SignatureLew Bloch > <http://www.amazon.com/Effective-Java-Programming-Language-Guide/dp/product-descr iption/0321356683> > > "Availability: This title has not yet been released. You may > order it now and we will ship it to you when it arrives." Amazon UK lists a release date of 28th June 2008. Dan. SignatureDaniel Dyer http://www.uncommons.org > Amazon UK lists a release date of 28th June 2008. Bummer. I just bought the older version at Barnes & Noble last week! I guess it will still be a good read, though. Not everything is specific to the platform version, I guess. >> Amazon UK lists a release date of 28th June 2008. > > Bummer. I just bought the older version at Barnes & Noble last week! I > guess it will still be a good read, though. Not everything is specific > to the platform version, I guess. Seriously, it's worth it not to wait seven or eight months. Just buy /Effective Java/ again when the 2nd edition arrives. You won't regret having it early. SignatureLew > Well the problem is that you come from Python Background. Well, I wouldn't call it a *problem* ... ;) > As far as a book explaining "Java Philosophy" is concerned I don't > know if any such book exists. But from whatever I have read if > anything can come closer to become "The Standard way of Coding in > Java" then it is "Effective Java Programming Language Guide" by Joshua > Bloch. Looks interesting, I'll have a look. Thanks (also for the rest of your post, very interesting). :) /W On Thu, 13 Dec 2007 00:48:16 +0100, Wildemar Wildenburger <lasses_weil@klapptsowieso.net> wrote, quoted or indirectly quoted someone who said : >What I'd like now is some sort of "Java Philosophy" text. Something like >a "spiritual guide" to Java, that would convey the right mindset for it. >A quick googling found me nothing that seemed consentient, most was >rather personal views. I've read the Java-is-not-Python thing, but that >didn't cut it (felt lame). I hate relaxed type languages. Yes strict typing takes more type to type, but it saves time in the long run. It is much easier to understand what the code is doing when you have the types clearly laid out. Compile time checking excludes many errors. It comes down to what you are doing. If you are whipping out little one shot programs that you run once, then discard, and you are a slow typist, then relaxed typing is the way to fly. If you write systems that you keep coming back to for maintenance over the years, approaching each time cold, largely forgetting how the program works, with only your notes and the code to get up to speed, then you appreciate the tight typing. Learning to type quickly, using a high quality keyboard such as the kinesis or Maltron, and an optimised layout such as DSK, can take much of the pain out of the verbosity. A smart IDE helps too. see http://mindprod.com/bgloss/keyboard.html SignatureRoedy Green Canadian Mind Products The Java Glossary http://mindprod.com > I hate relaxed type languages. Yes strict typing takes more type to > type, but it saves time in the long run. It is much easier to > understand what the code is doing when you have the types clearly laid > out. Compile time checking excludes many errors. I know I shouldn't do this but ... It's all a matter of what you're used to. I usually don't care for the type of a variable, for the very reason that Python is designed around just that notion. I don't need to know what type a variable has, just what can be done with it, and that is usually obvious from the code. I don't really see the benefit of writing Thing foo = new Thing(); instead of just foo = Thing() OK, it might make more sense when it comes to interfaces, but here I don't see any benefit. I can better understand the strict typing in method signatures. But again, Python does "duck typing", so usually the docstring right below the function definition is all you need, most if the time. This of course, depends heavily on programmers writing descent documentation, which is not to be expected. So I agree and disagree. > It comes down to what you are doing. If you are whipping out little > one shot programs that you run once, then discard, and you are a slow [quoted text clipped - 4 lines] > program works, with only your notes and the code to get up to speed, > then you appreciate the tight typing. Reading that just breaks my little pythonic heart. :( (;)) Python was designed with the idea that code is usually read more often than it is written. So it is actually very easy to go (back) to a python program that you haven't seen in a long time if at all. Again, it is what you are used to reading and thinking that makes a particular type of program hard or easy to understand. If you expect to see type definitions everywhere, then of course you're going to miss them. If you're not used to them, they will bug the hell out of you. But I wouldn't claim that any aproach is generally worse than the other. > Learning to type quickly, using a high quality keyboard such as the > kinesis or Maltron, and an optimised layout such as DSK, can take much > of the pain out of the verbosity. A smart IDE helps too. > see http://mindprod.com/bgloss/keyboard.html My problem is not really the typing (though I *am* slow at that), but the fixture. My mind just isn't used to deciding on the datatype of a variable. I'm used to trying one an then changing it if my initial descision was bad. That is of course possible in any language, but in Java you have to make changes in much more places. I don't know, I'll get used to it sooner or later. /W PS. Thanks for the keyboard tips; I'm looking into touch typing but I've used my idiosyncratic method for years so that is hard to learn touch. > I don't really see the benefit of writing > [quoted text clipped - 5 lines] > > OK, it might make more sense when it comes to interfaces, But that's it. It absolutely, positively guarantees that foo will /always/ be a Thing. Which means that the compiler can always generate code based on that certainty, and give you an error message at compile time if you ask foo to do anything that cannot be done by a Thing -- and /not/ have to ask, "Is foo a Thing?" every single bloody time -- perhaps millions or billions of times -- foo is used. The word "new" could probably have been left out of the language design, but I think most Java programmers would prefer to retain the clear distinction between a constructor and a factory method. SignatureJohn W. Kennedy "The whole modern world has divided itself into Conservatives and Progressives. The business of Progressives is to go on making mistakes. The business of the Conservatives is to prevent the mistakes from being corrected." -- G. K. Chesterton >> I don't really see the benefit of writing >> [quoted text clipped - 8 lines] > But that's it. It absolutely, positively guarantees that foo will > /always/ be a Thing. I *kind of* see that. But that can be guaranteed with the second form just as well; once a var is initialized, it must always be a Thing. This is nitpicking on my part of course. /W >>> I don't really see the benefit of writing >>> [quoted text clipped - 12 lines] > just as well; once a var is initialized, it must always be a Thing. This > is nitpicking on my part of course. "Once a var is initialized" happens on the customer's machine. "During compilation" happens on the developer's machine, before customer, tester or manager can see any trouble. The difference is run-time vs. compile-time validation of the type. Both work, but Java is designed to reveal these things during development, and that is an advantage. SignatureLew >>>> I don't really see the benefit of writing >>>> [quoted text clipped - 19 lines] > Java is designed to reveal these things during development, and that > is an advantage. There is also a cost associated with it, in terms of development time and therefore the number of alternatives that can be investigated. Developers who have used languages with duck or optional typing are familiar with the very different style of programming such languages support. That being said, the typing wars are easily found elsewhere on Usenet and I have no urge to start that battle here. Suffice to say, a good developer will consider both the costs and benefits of any language feature. Regards, Patrick ------------------------------------------------------------------------ S P Engineering, Inc. | Large scale, mission-critical, distributed OO | systems design and implementation. pjm@spe.com | (C++, Java, Common Lisp, Jini, middleware, SOA) Lew writes: >> "Once a var is initialized" happens on the customer's machine. >> "During compilation" happens on the developer's machine, before >> customer, tester or manager can see any trouble. The difference is >> run-time vs. compile-time validation of the type. Both work, but >> Java is designed to reveal these things during development, and that >> is an advantage. > There is also a cost associated with it, in terms of development > time and therefore the number of alternatives that can be [quoted text clipped - 6 lines] > a good developer will consider both the costs and benefits of any > language feature. Like I said, > Both work SignatureLew >The word "new" could probably have been left out of the >language design, but I think most Java programmers would prefer >to retain the clear distinction between a constructor and a >factory method. I am not one of them. »new« just annoys me. But let's wait. Possibly someone here comes up with a good reason for it. >> The word "new" could probably have been left out of the >> language design, but I think most Java programmers would prefer [quoted text clipped - 5 lines] > But let's wait. Possibly someone here comes > up with a good reason for it. It makes it much easier to tell constructors from methods at a glance. SignatureLew > >> The word "new" could probably have been left out of the > >> language design, but I think most Java programmers would prefer [quoted text clipped - 10 lines] > -- > Lew I think I would take that statement one step further. "It makes it possible to tell constructors from methods." How about the following (someone guess the output if Java didn't use the word "new" and people didn't care about the naming conventions (which some people don't)) : public class Thing { public static void main(String[] args) { Thing t = Thang(); } private static void Thang() { System.out.println("Boo"); } } public class Thang { public Thang() { System.out.println("Bah"); } } /Steen > > >> The word "new" could probably have been left out of the > > >> language design, but I think most Java programmers would prefer [quoted text clipped - 39 lines] > > /Steen Apart from the ClassCastException which I just realized after rereading my post, but I'm sure you get my point..;) /Steen > I don't really see the benefit of writing > [quoted text clipped - 3 lines] > > foo = Thing() I sometimes wish there were a short-cut notation such as Thing<Whatever> foo = new(); for Thing<Whatever> foo = new Thing<Whatever>(); and List<Whatever> foo = new ArrayList<>(); for List<Whatever> foo = new ArrayList<Whatever>(); but clearly I haven't thought this through :-) >> I don't really see the benefit of writing >> [quoted text clipped - 6 lines] >I sometimes wish there were a short-cut notation such as > Thing<Whatever> foo = new(); I'm rather partial to a C++-like Thing<Whatever> foo(arg1, arg2, etc); myself. The only thing you'd be losing is the "new" operator so if you like searching for those, it might be a problem. >for > Thing<Whatever> foo = new Thing<Whatever>(); > (...) Cheers, Bent D SignatureBent Dalager - bcd@pvv.org - http://www.pvv.org/~bcd powered by emacs >>> I don't really see the benefit of writing >>> [quoted text clipped - 10 lines] > Thing<Whatever> foo(arg1, arg2, etc); > myself. That's not merely syntax; it's a major functional change -- allowing objects to be allocated on the stack instead of the heap. And that means all kinds of other problems. What are to be the semantics of: heapObject = stackObject; for example? Soon you'll be defining copy constructors and God-only-knows-what-else C++isms, not to mention references pointing to dead stack frames. SignatureJohn W. Kennedy "Sweet, was Christ crucified to create this chat?" -- Charles Williams. "Judgement at Chelmsford" >> I'm rather partial to a C++-like >> Thing<Whatever> foo(arg1, arg2, etc); >> myself. > >That's not merely syntax; it's a major functional change -- allowing >objects to be allocated on the stack instead of the heap. In Java, it would be only syntax, since the programmer already doesn't care where objects get allocated. It would be up to the JIT, as always, to determine how to do the actual allocation. A a(); would simply be shorthand for A a = new A(); Cheers, Bent D SignatureBent Dalager - bcd@pvv.org - http://www.pvv.org/~bcd powered by emacs >>> I'm rather partial to a C++-like >>> Thing<Whatever> foo(arg1, arg2, etc); [quoted text clipped - 3 lines] > > In Java, it would be only syntax, Every C++ or Delphi user trying to learn Java would curse your name forever. > since the programmer already doesn't > care where objects get allocated. Only in the sense that Java gives no option at present; all objects are on the heap, period. But if objects /could/ be allocated on both the heap and the stack, it would make all the difference in the world. SignatureJohn W. Kennedy "...if you had to fall in love with someone who was evil, I can see why it was her." -- "Alias" > Only in the sense that Java gives no option at present; all objects are > on the heap, period. But if objects /could/ be allocated on both the > heap and the stack, it would make all the difference in the world. That's not strictly true. Many times the optimizer will allocate on the stack; it just doesn't admit it to the programmer. SignatureLew >> Only in the sense that Java gives no option at present; all objects >> are on the heap, period. But if objects /could/ be allocated on both >> the heap and the stack, it would make all the difference in the world. > > That's not strictly true. Many times the optimizer will allocate on the > stack; it just doesn't admit it to the programmer. This should be looked at as an issue of object lifetime, rather than physical location. Currently, ignoring details of finalizers, Java objects live from the time they are created until they become unreferenced. I think the stack suggestion should be read as a proposal for Java objects whose lifetime is the lifetime of a specific variable, regardless of references. Is there any way to do it that does not lead to issues with dangling pointers to an object that no longer exists? Patricia >> Only in the sense that Java gives no option at present; all objects >> are on the heap, period. But if objects /could/ be allocated on both >> the heap and the stack, it would make all the difference in the world. > > That's not strictly true. Many times the optimizer will allocate on the > stack; it just doesn't admit it to the programmer. It will do it only if the optimizer can detect that there is no semantic difference -- that the object will die when the block is exited. Which is cool; it takes a big bite out of one of Java's biggest intrinsic performance problems. But, as I say, only where it makes no semantic difference. SignatureJohn W. Kennedy "Compact is becoming contract, Man only earns and pays." -- Charles Williams. "Bors to Elayne: On the King's Coins" >> In Java, it would be only syntax, > >Every C++ or Delphi user trying to learn Java would curse your name forever. I have thick skin, I could take it :-) >> since the programmer already doesn't >> care where objects get allocated. > >Only in the sense that Java gives no option at present; all objects are >on the heap, period. But if objects /could/ be allocated on both the >heap and the stack, it would make all the difference in the world. This would be such a fundamental change to the language it is unlikely to ever happen. Such decisions are best left to the JIT. Cheers, Bent D SignatureBent Dalager - bcd@pvv.org - http://www.pvv.org/~bcd powered by emacs On Fri, 14 Dec 2007 10:59:27 +0000, RedGrittyBrick <RedGrittyBrick@SpamWeary.foo> wrote, quoted or indirectly quoted someone who said : > Thing<Whatever> foo = new Thing<Whatever>(); Beside clutter you introduce the possibility of errors of this form: Thing<Whatever> foo = new Thang<Whatever>(); Unless you stare carefully you might read that as: Thing<Whatever> foo = new Thing<Whatever>(); In Bali, I suggested the following shortcut: BigDate d = new BigDate( 1997, 5 , 6 ); could be written as BigDate (1997, 5 , 6) d; It would be an easy extension to Java, requiring no JVM changes. SignatureRoedy Green Canadian Mind Products The Java Glossary http://mindprod.com > Learning to type quickly, using a high quality keyboard such as the > kinesis or Maltron, and an optimised layout such as DSK, can take much > of the pain out of the verbosity. A smart IDE helps too. > see http://mindprod.com/bgloss/keyboard.html I have used both the Kinesis and the Maltron keyboards. The Kinesis has these tiny little function keys that annoyed me the entire five years I used it. The Maltron was great, although it frightened my friends, but very fragile for a $300 keyboard. Both completely cured any tendency I had to wrist or arm pain. Neither really has a perfect layout for common PC key chords, but the Maltron is much better than the Kinesis for that. (I used the QWERTY layout, not the Maltron layout.) Now I just use a Microsoft wireless keyboard (Wireless Comfort Keyboard 1.0A) at home. It's only slightly ergonomic by comparison, but it seems to be enough to avoid pain. I just have to get my employer to let me use a more ergonomic keyboard at work. It's very important that the keyboard be low, your chair properly set, and the mouse be on the left due to the asymmetry of PC keyboard layouts. Touch typing really helps. I type roughly 50 wpm with reasonable accuracy, so a lot of the "it's too long to type" issues don't arise for me, even when I don't use copy-and-paste. SignatureLew I agree about the pathetic Kinesis function keys. Thankfully, modern programs make very little use of them. One thing I like about the Kinesis is the lack of separate numeric keypad. There is a logical embedded one I almost never use. The advantage is it makes the keyboard narrower. This means the mouse can be closer. I have looked all over for cheap keyboards for people with shoulder mouse pain. I saw a keyboard mouse combo the other day called an "air mouse". The retailer would not let me open the box to try it out. (This seems to be the new norm. How can you pick a keyboard without testing the feel?) Apparently the mouse does not need a surface. It says it uses a "gyroscope". I suspect they mean an accelerometer. SignatureRoedy Green Canadian Mind Products The Java Glossary http://mindprod.com I have been coding in Java since its early days. Throughout this time and before, I used other languages, such as Turbo Pascal, Perl, Javascript, and most recently C#. Java is a multifaceted beast. Here are some of the attributes I find important: * type safety of the language and runtime environment * garbage collection * easy multithreading * easy networking * extensive standard libraries as well as EE and 3rd party options * runtime optimization * cross-platform (let's not forget J2ME and Android for embedded VM's) * backwards compatible source, standard API (excepting a very slow deprecation process), and compiled form * alternate languages running on JVM (Scala, JRuby, Jython, BeanShell, Rhyno/ECMAScript, etc.) * Java source compiled to non-JVM environments (GWT, Android) There's more, but that's good enough for now. Don't fear the apparent complexity of API, frameworks or deployment. We're up to Java 6 and I doubt there's anyone on this planet who has comprehensive understanding of everything in the Java world. Some things overlap each other, some solutions compete with each other, some have not caught up to the latest language features that allow them to become simpler (take a look at JEE 5 and how annotations are actually simplifying things like web services). On Thu, 13 Dec 2007 11:43:22 -0800 (PST), Alexey <inline_four@yahoo.com> wrote, quoted or indirectly quoted someone who said : >* type safety of the language and runtime environment >* garbage collection [quoted text clipped - 8 lines] >Rhyno/ECMAScript, etc.) >* Java source compiled to non-JVM environments (GWT, Android) I don't know if it is a sufficiently rare feature to single out, but Java has nice facilities for plug in code. You can define interfaces and then plug in various different implementations of it at run time that did not even exist at compile time. I have had to kludge this feature in other languages in various ways. The cross-platform is much stronger than usual. Not only do programs run on different platforms, they don't even have to be recompiled, AND they give the exact same results. I am so happy the way Java nailed down the precise size of primitives and the precise way arithmetic has to work. Unless you use your own native code, apps are cross-platform automatically. In many other languages, getting that effect is difficult and requires intimate knowledge of all the target platforms. SignatureRoedy Green Canadian Mind Products The Java Glossary http://mindprod.com > Hi Folks, > [quoted text clipped - 17 lines] > thx > /W Blimey, I wouldn't want to be maintaining anything you've written! or, by the sounds of it, anything written in Python, though that's speculation on my part. I do hate maintaining perl though, in my opinion it's just not suitable for large scale development. > Blimey, I wouldn't want to be maintaining anything you've written! or, by > the sounds of it, anything written in Python, though that's speculation on > my part. I'm not following you. Can you elaborate? BTW, I cartainly am not a great programmer; I'm an enthusiast, not a programmer by trade. But assuming difficult maintainability for Python is doing the language unjustice, because it was (as I said elsewhere) designed with that goal in mind (readability). I feared I might hit a hornets nest when asking that question. But please folks, try to not let this slip into one of those "mine is better than yours" discussions. > I do hate maintaining perl though, in my opinion it's just not > suitable for large scale development. It wasn't designed for that, so what do you expect? It was designed for wrangling text. I'm not a fan of abusing tools for tasks they weren't meant to be used on. /W >> Blimey, I wouldn't want to be maintaining anything you've written! or, by >> the sounds of it, anything written in Python, though that's speculation >> on my part. >> > I'm not following you. Can you elaborate? you wrote: Specifically I find Java to be overly paranoid sometimes (what with interfaces, typing declarations, etc ...). these are the tools for producing well designed maintainable and robust OO code in Java. > BTW, I cartainly am not a great programmer; I'm an enthusiast, not a > programmer by trade. But assuming difficult maintainability for Python is [quoted text clipped - 13 lines] > > /W As I said, my statements on Python were pure speculation, was it designed for large scale development? I had thought it was a derivative of perl, am I wrong? > you wrote: > Specifically I find Java to be overly > paranoid sometimes (what with interfaces, typing declarations, etc ...). > > these are the tools for producing well designed maintainable and robust OO > code in Java. You could have just said that. Thanks for doing so now. My wording may have been a bit offensive to Java folks, but I tried to make clear (and understandable) the subjectiveness of this impression. Sorry if I irritated you. > As I said, my statements on Python were pure speculation, was it designed > for large scale development? No, not really I guess. Then again, it *was* designed to be read a lot. There are also quite a few relatively big projects based on or at least using python. Chandler and Google come to mind. > I had thought it was a derivative of perl, am I wrong? Try telling that to the folks at comp.lang.python and see what happens. ;) /W >> you wrote: >> Specifically I find Java to be overly [quoted text clipped - 17 lines] >> I had thought it was a derivative of perl, am I wrong? > Try telling that to the folks at comp.lang.python and see what happens. ;) Readability of source code is one element of maintainability, but not the only one. Frankly, I think bad code can be written in any language, likewise good code. Some languages support certain coding idioms better, others support different ones better. The trick is to think in the language that you're using and play to its strengths. Use good coding discipline appropriate to the language and you will write better code. The "Python is designed for readability" claim doesn't really indicate whether it's better, worse or the same as Java for writing industrial-strength applications. I suspect Java is stronger for such applications simply because of its combination of philosophies: GC, strongly-typed, dynamic, network-aware, well-defined operations (no endian controversies), built-in concurrency and the package organization make it suitable for large-scale team projects. This in no wise denigrates Python or its usefulness. It's just that Java provides bricks for your walls, which is great when you want to handle a windstorm of, say, 50-100 million documents entering your system in one week with no collapses, when those walls were built by dozens of programmers. Java is pretty readable, too, when written by someone who wants it to be. If the code we write isn't readable or maintainable, the fault lies not in our stars, dear Brutus, but in ourselves. SignatureLew > Frankly, I think bad code can be written in any language, likewise good > code. Some languages support certain coding idioms better, others > support different ones better. The trick is to think in the language > that you're using and play to its strengths. Use good coding discipline > appropriate to the language and you will write better code. Hence my question. :) > The "Python is designed for readability" claim doesn't really indicate > whether it's better, worse or the same as Java for writing > industrial-strength applications. It probably isn't. Most surely. It'll grow on me, I'm sure. /W On 14 Dec, 00:15, Wildemar Wildenburger <lasses_w...@klapptsowieso.net> wrote: > > you wrote: > > Specifically I find Java to be overly [quoted text clipped - 8 lines] > make clear (and understandable) the subjectiveness of this impression. > Sorry if I irritated you. No, no, I wasn't irritated, I apologise if my response sounded brash, wasn't meant to be, my point was just that you would use the correct tool for each type of job. Java is a tool suitable for large scale development and its features are thus what you'd use to do that, nothing really to do with a philosophy. Similar to how C is a tool suitable for system development so you'd have a different set of approaches again when using that. > > As I said, my statements on Python were pure speculation, was it designed > > for large scale development? > > No, not really I guess. Then again, it *was* designed to be read a lot. > There are also quite a few relatively big projects based on or at least > using python. Chandler and Google come to mind. Being readable is important but it's not the only important thing, and Java and C, C++ etc. are readable too. But they provide a model that's suitable for what they're intended for which you should use to produce maintainable and robust code. > > I had thought it was a derivative of perl, am I wrong? > > Try telling that to the folks at comp.lang.python and see what happens. ;) > > /W Think I'll keep my head down then! >tool for each type of job. Java is a tool suitable for large scale >development and its features are thus what you'd use to do that, I have different priorities. The reasons for Java that come to my mind now are: - prevalence Java is the most common language nowadays. »With over 6 million developers (according to Sun) Java clearly dominates the software development industry[. It is] perhaps the most successful software development platform in the history of computing« http://apsblog.burtongroup.com/2007/11/why-microsoft-l.html »3.3 billion Java devices worldwide« http://web.archive.org/web/20060615162523/http://java.sun.com/javaone/sf/session s/general/javacompatibility_thursday.jsp This means, that the chance that Java will be still around in the future is large. I am not only thinking of 2 years, but also of 20 years in the future. This means a smaller chance that I will be forced to rewrite into another language. - A standard GUI The standard distribution of the language (platform) contains a GUI library (Swing, AWT). Therefore the first reason of stability by prevalence also applies to Swing. Perl, Python, Ruby, C, C++ do not have a GUI toolkit as part of the standard library - though several extensions are available. - Portability Java includes a JVM to ensure portability even of GUI applications. While Python plus a GUI-Toolkit might also run on several platforms, it is not known how long such a combination will be available in the future. A C-program on Win32 surely is not that portable. - Teaching I give classes (open to everyone for a certain price) and only the most common languages will attract enough students. This includes C++ and Java, but not Perl, Python or Ruby. So I have to learn Java anyways. Otherwise, purely from the point of language notation, I might prefer Ruby. But I even do not dare to use JRuby, because I do not know how long it will be available and maintained. > Perl, Python, Ruby, C, C++ do not have a GUI toolkit > as part of the standard library - though several [quoted text clipped - 5 lines] > how long such a combination will be available in the > future. A C-program on Win32 surely is not that portable. Python has the tcl/tk bindings in its standard library, so, just like java, it ships with a GUI that looks equally ugly and alien on all platforms ;) /W (Yes, I know, there's the "native" L&F for Gnome and Win, but that never felt completely right to me. Also: Grain of Salt! Just in case.) Free MagazinesGet these publications absolutely FREE for up to 12 months. There are no hidden fees and no obligation. Simply choose a title, complete the application form and submit it. Read more ...
|
Reply to this Message
|
 Sign In
 Join
 My Latest Posts My Monitored Threads My Blog My Photo Gallery My Profile My Homepage Start New Thread Enable EMail Alerts Rate this Thread
|
©2009 Advenet LLC Privacy Policy - Terms of Use
This website includes both content owned or controlled by Advenet as well as content owned or controlled by third parties.