 |
 | Home | Contact Us | FAQ | Search & Site Map | Link to Us |
 | Sign In | Join | Other 45 Sites in Network |
Java Forum / General / April 2006why java is not pure object oriented?
hi, I want to know why java is not a pure object oriented programming language. Thanks in advance. > I want to know why java is not a pure object oriented > programming language. What does your textbook say? /Thomas  SignatureThe comp.lang.java.gui FAQ: ftp://ftp.cs.uu.nl/pub/NEWS.ANSWERS/computer-lang/java/gui/faq http://www.uni-giessen.de/faq/archiv/computer-lang.java.gui.faq/ Do you mean a) Why was java not designed as a purely object oriented language? or b) In what ways is java not purely object oriented? An answer that kinda covers both is: primitive types such as int, char and boolean are not Objects and this helps to improve the performance of java programs. (transmit-message (Hello 'laurenccostello) (You-wrote :on "21 Mar 2006 00:41:58 -0800") (Say '( l> Do you mean l> a) Why was java not designed as a purely object oriented language? l> or l> b) In what ways is java not purely object oriented? l> An answer that kinda covers both is: l> primitive types such as int, char and boolean are not Objects and this l> helps to improve the performance of java programs. _________________________^^^^^^^^^^^^^^^^^^^^^^^^^^^^ LOL ;) Signature))) => t > (transmit-message (Hello 'laurenccostello) > (You-wrote :on "21 Mar 2006 00:41:58 -0800") [quoted text clipped - 11 lines] > > LOL ;) What did I miss here? You're certainly not insinuating that Java is slow, do you? robert (transmit-message (Hello 'Robert) (You-wrote :on "Tue, 21 Mar 2006 10:05:20 +0100") (Say '( >> l> Do you mean >> l> a) Why was java not designed as a purely object oriented language? [quoted text clipped - 5 lines] >> _________________________^^^^^^^^^^^^^^^^^^^^^^^^^^^^ >> LOL ;) RK> What did I miss here? You're certainly not insinuating that Java is RK> slow, do you? I'm absolutly newbie to Java and I hope my perception of it's slowness is wrong. But now I'm trying to develop a web-application for Cocoon and when I'm waiting 10 seconds, watching output of `ant webapp', and then 20-30 seconds while tomcat reloads new versions of my java-classes, it's seems to me that Java isn't very fast. I want to see the result of my changes immediately like in any modern _interactive_ languge (Lisp, Python, ...) and I want development process to be incremental (without complete reloading of Cocoon after each small changes). But Java slows down my work for about 10 times ;( I agree that it's not slowness, but non-interactivity. Signature))) => t > I'm absolutly newbie to Java and I hope my perception of it's slowness > is wrong. But now I'm trying to develop a web-application for Cocoon and [quoted text clipped - 6 lines] > down my work for about 10 times ;( I agree that it's not slowness, but > non-interactivity. This has nothing to do with Java as a language, this is the way Cocoon and Tomcat were implemented. But I do admit that the turnaround times in an J2EE environment (and web applications are part of that) is way too high. Thomas Thomas Kellerer schrieb: >> I'm absolutly newbie to Java and I hope my perception of it's slowness >> is wrong. But now I'm trying to develop a web-application for Cocoon and [quoted text clipped - 9 lines] > This has nothing to do with Java as a language, this is the way Cocoon > and Tomcat were implemented. Sure this is a problem of java. You just don't have this problem with python or lisp. The JVM does support hot code replacement, but the support is very limited. I constantly have to restart my app during development, and it really affects productivity. Timo (transmit-message (Hello 'Thomas) (You-wrote :on "Tue, 21 Mar 2006 11:35:05 +0100") (Say '( >> I'm absolutly newbie to Java and I hope my perception of it's slowness >> is wrong. But now I'm trying to develop a web-application for Cocoon and [quoted text clipped - 6 lines] >> down my work for about 10 times ;( I agree that it's not slowness, but >> non-interactivity. TK> This has nothing to do with Java as a language, this is the way TK> Cocoon and Tomcat were implemented. TK> But I do admit that the turnaround times in an J2EE environment TK> (and web applications are part of that) is way too high. Is there any tutorial/book like "How to program in Java fast." or "How to setup environment for interactive and effective Java development."? Signature))) => t > Is there any tutorial/book like "How to program in Java fast." Many books. Without knowing your aptitude or preferences it's hard to make recommendations. > or "How > to setup environment for interactive and effective Java > development."? Just get Eclipse and the current Sun JDK and jump into it. (transmit-message (Hello 'James) (You-wrote :on "Tue, 21 Mar 2006 20:06:55 -0700") (Say '( >> Is there any tutorial/book like "How to program in Java fast." JM> Many books. Without knowing your aptitude or preferences it's hard to JM> make recommendations. I have some experience in different languages from assembler (x86) through c++, haskell, python, ... to Lisp. And my favorite language is Lisp (but for now I'm newbie to Lisp) ;) I don't need a book about Java's syntax (I can find it in the specification) or algorithms (I can find it in a book like "Concepts, Techniques, and Models of Computer Programming"), but I need some knowldge about effective use of BeanShell, JDEE (or other DE), interactive development, modification of running applications without their restart, debugging and etc. For example, in Lisp I can connect to the remote Lisp process and make some modifications without recompilation or even without restarting of this application. It would be great, if I could develop webapps for Cocoon without it's restarting after each small modification (it takes too much time). >> or "How to setup environment for interactive and effective Java >> development."? JM> Just get Eclipse and the current Sun JDK and jump into it. Actually, I prefer Emacs. But JDEE doesn't work in my GNU Emacs 22.0.50 ;( Thanks, I'll try Eclipse. Does it support interactive development (using BeanShell or something else)? Signature))) => t > I don't need a book about > Java's syntax (I can find it in the specification) Famous last words :-) Did you have a look at the JLS (The Java Language Specification)?. Using that one as a textbook for learning the syntax is masochism. Sure, it is all in, but it is really not in a form for easy consumption. What a simple reference might answer in seconds can take hours to figure out from the JLS. /Thomas SignatureThe comp.lang.java.gui FAQ: ftp://ftp.cs.uu.nl/pub/NEWS.ANSWERS/computer-lang/java/gui/faq http://www.uni-giessen.de/faq/archiv/computer-lang.java.gui.faq/ (transmit-message (Hello 'Thomas) (You-wrote :on "Wed, 22 Mar 2006 11:45:46 +0100") (Say '( TW> Denis Nikiforov wrote: >> I don't need a book about Java's syntax (I can find it in the >> specification) TW> Famous last words :-) Did you have a look at the JLS (The Java TW> Language Specification)?. Using that one as a textbook for learning TW> the syntax is masochism. Sure, it is all in, but it is really not TW> in a form for easy consumption. TW> What a simple reference might answer in seconds can take hours to TW> figure out from the JLS. But I didn't assert that specification is a good textbook ;) I guess Java syntax isn't so different from others (for example, Lisp differs from others much more)... JLS looks ok and I couldn't find in it something completely new to C++, Python and others. The problem is that at least all books about programming languages, which I saw, describes syntax and just syntax. Books like "Concepts, Techniques, and Models of Computer Programming" and some books about Lisp are exceptions of this rule. Signature))) => t >> I don't need a book about >> Java's syntax (I can find it in the specification) [quoted text clipped - 8 lines] > > /Thomas I think JLS reading may depend on how much practical language lawyering one has done in the past, and on fluency in formal grammars. I find it easier to get answers about Java syntax from the JLS than from any other reference. Patricia >> What a simple reference might answer in seconds can take hours to >> figure out from the JLS. [quoted text clipped - 3 lines] > grammars. I find it easier to get answers about Java syntax from the > JLS than from any other reference. It may also depend on the depth of understanding needed. Most references will give you a close enough approximation for most uses. The JLS is the real deal. The only reason the JLS is difficult to read is that it must cover every possible circumstance. Philosophy books are hard to read for the same reason. Signaturemonique Ask smart questions, get good answers: http://www.catb.org/~esr/faqs/smart-questions.html "Patricia Shanahan" <pats@acm.org> wrote in message news:k1kUf.5916 > I think JLS reading may depend on how much practical language lawyering > one has done in the past, and on fluency in formal grammars. I find it > easier to get answers about Java syntax from the JLS than from any other > reference. It also depends on what the intended usage is. If the goal is to learn how to program in Java, I wouldn't recommend the JLS. If the goal is to implement a Java compiler, I wouldn't recommend "Java for Dummies". - Oliver On Wed, 22 Mar 2006 11:45:46 +0100, Thomas Weidenfeller <nobody@ericsson.invalid> wrote, quoted or indirectly quoted someone who said : >What a simple reference might answer in seconds can take hours to figure >out from the JLS. It is a book for language lawyers, for those writing compilers to decide fine points. There are some with oracular powers at divining its meaning. When Patrician Shanahan is about, I turn to her for enlightenment on its intent. For most simple things, a few experiments settle the matter quickly. The nice thing about such experiments is you don't have to be able to formulate your questions in English or decipher someone else's. It is all very much legal/not legal. The disadvantage of an experiment is that if there is a bug in the compiler, you won't detect it. SignatureCanadian Mind Products, Roedy Green. http://mindprod.com Java custom programming, consulting and coaching. > [The JLS] is a book for language lawyers, for those writing compilers to > decide fine points. There are some with oracular powers at divining > its meaning. When Patrician Shanahan is about, I turn to her for > enlightenment on its intent. That's considerably overstated. It's certainly not a book to learn from, nor for a relative beginner... but I'd doubt someone's understanding of Java if they can't comprehend the spec and claimed to be an accomplished developer. When one rejects the idea that a good developer needs to memorize the language, the next logical option is that the good developer has the tools to look things up quickly and easily and authoritatively. > For most simple things, a few experiments settle the matter quickly. > The nice thing about such experiments is you don't have to be able to > formulate your questions in English or decipher someone else's. It is > all very much legal/not legal. This is very dangerous whenever you might run into undefined/unspecified behavior or portability issues. For that reason, I'd recommend such experimentation only when combined with a rudimentary understanding of what is and isn't guaranteed. In Java, the problematic bits are nicely isolated: file paths and other OS stuff, and multithreading, mainly. You just need to be careful about relying on experimentation all the time. In other languages, you have to be more careful. Java is unique in that, for the most part, the only choices are between well-defined behavior or a compile error. That is most assuredly not true, for example, in C. > The disadvantage of an experiment is that if there is a bug in the > compiler, you won't detect it. That's really the least problem in the list of problems with that approach. I've only ever seen one compiler bug in a compiler that I actually used at the time, and it was in an Eclipse milestone and pertained to code that no one would probably see. (Early Eclipse "Cheetah" releases were pretty bad, but no one used them either.) The bigger problem is explained above. Signaturewww.designacourse.com The Easiest Way To Train Anyone... Anywhere. Chris Smith - Lead Software Developer/Technical Trainer MindIQ Corporation > Is there any tutorial/book like "How to program in Java fast." I'm trying to do that by doing top coder practice programming assignments. I have a feeling that after I have done several hundred of them I will be faster than I am now. (Seriously I have done half a dozen and I'm already feeling faster) Our schooling system is extremely limited in the mere quantity of assignments that they put out. If you want to code well, and fast you need to train. Pick an algorithm that interests you. Mazes fascinate me - but I realize not everyone shares my conviction. To train, I used to choose an algorithm (don't always do the same one) and then time myself to see how quickly I could program it. (Incidentally this was in C++) Then I would delete my code and do it again, making it cleaner, sleeker, more inline and quicker. I considered myself successful when I could sit down and write the entire thing, and have no debug errors. (Syntax errors are ok, but no logic errors.) I did my first maze algorithm when I was 9 and it took me almost 35 hours. I think I timed myself at just under 4 minutes once. (Maybe it was 6 minutes actually) It's like anything - you just need to work at it. The only reason I suggest top coder is because they have hundreds of free examples. I'm sure other places do too. NOTE: I realize top coder is a commercial venture, and I affirm I am in no way affiliated with top coder other than as a user, with no vested interest. This message is not spam. -- LTP :) > The only reason I suggest top coder is because they have hundreds of free > examples. I'm sure other places do too. > > NOTE: I realize top coder is a commercial venture, and I affirm I am in no > way affiliated with top coder other than as a user, with no vested interest. Hopefully, no one here is that up-tight. Topcoder is great fun, and I'd recommend it to anyone looking for a way to spend an evening. Don't just do the practice problems, though; that would be missing the best part. Too bad I've had so little time for the last year or so... Ditto the affirmation. Signaturewww.designacourse.com The Easiest Way To Train Anyone... Anywhere. Chris Smith - Lead Software Developer/Technical Trainer MindIQ Corporation > Hopefully, no one here is that up-tight. Topcoder is great fun, and I'd > recommend it to anyone looking for a way to spend an evening. Don't > just do the practice problems, though; that would be missing the best > part. I would recommend to check their terms and conditions thoroughly. Some time ago I gave Topcode a look. Their terms and conditions put me of. Stuff about US tax forms to provide, reference to some Chines laws, reserve the right to change the terms without any notice, request to waive juristication. That, and their desire to gather and display more data than I would like. I decided not to do "business" with them. I am not saying that there is anything wrong with them. They are upfront with their Ts and Cs. It is just not my cup of tea. /Thomas SignatureThe comp.lang.java.gui FAQ: ftp://ftp.cs.uu.nl/pub/NEWS.ANSWERS/computer-lang/java/gui/faq http://www.uni-giessen.de/faq/archiv/computer-lang.java.gui.faq/ >> The only reason I suggest top coder is because they have hundreds of free >> examples. I'm sure other places do too. [quoted text clipped - 10 lines] > > Too bad I've had so little time for the last year or so... I am usually referring people who are far below competition level - so I defintely think the practice problems are the place to begin and almost always say that. To be honest - I've never myself gone beyond them (too afraid of utter humiliation) But I will see about changing that the next open enrollment round that comes up. -- LTP :) (transmit-message (Hello 'Luc) (You-wrote :on "Tue, 21 Mar 2006 21:46:23 -0700") (Say '( >> Is there any tutorial/book like "How to program in Java fast." LTP> I'm trying to do that by doing top coder practice programming assignments. LTP> I have a feeling that after I have done several hundred of them I will be LTP> faster than I am now. (Seriously I have done half a dozen and I'm already LTP> feeling faster) LTP> Our schooling system is extremely limited in the mere quantity of LTP> assignments that they put out. If you want to code well, and fast you need LTP> to train. LTP> Pick an algorithm that interests you. Mazes fascinate me - but I realize LTP> not everyone shares my conviction. [...] Ohh... ;( I'm afraid Java isn't best language for learning of programming. IMHO, it's based mainly on engineering tradition and uses top-down approach. For learning I preffer language like Lisp based on designer tradition with bottom-up approach. There is no problem to program fast in latter, but, imho, it's very hard in former (like Java). PS: It's all IMHO! Signature))) => t > Ohh... ;( I'm afraid Java isn't best language for learning of > programming. IMHO, it's based mainly on engineering tradition and uses > top-down approach. For learning I preffer language like Lisp based on > designer tradition with bottom-up approach. There is no problem to > program fast in latter, but, imho, it's very hard in former (like Java). There's some truth in what you say. Certainly no Java environment has anything like an acceptable level of interactivity. OTOH, Java isn't really about "top-down" development -- it's about OO programming which is neither top-down nor bottom-up (though it's closer to the latter). Please don't take this as an insult, but from the languages you list (and especially from your preference for Lisp[*]) I doubt whether you have experience of OO programming. Or at least, I think it's entirely possible that you don't have that experience. BTW, programming web applications must be just about the worst possible way to learn Java programming -- as you are discovering... -- chris ([*] Lisp is a fine language for those who like it, but it appears to me, as an outsider -- and despite CLOS -- to be antithetical to OO thinking) >([*] Lisp is a fine language for those who like it, but it >appears to me, as an outsider -- and despite CLOS -- to be >antithetical to OO thinking) Alan Kay coined the term »object-oriented« in 1967. In 2003, he wrote: »OOP to me means only messaging, local retention and protection and hiding of state-process, and extreme late-binding of all things. It can be done in Smalltalk and in LISP. There are possibly other systems in which this is possible, but I'm not aware of them.« http://www.purl.org/stefan_ram/pub/doc_kay_oop_en [me:] > > ([*] Lisp is a fine language for those who like it, but it > > appears to me, as an outsider -- and despite CLOS -- to be [quoted text clipped - 10 lines] > > http://www.purl.org/stefan_ram/pub/doc_kay_oop_en I agree that Lisp is one of the few languages possessing the necessary flexibility (and I more or less agree with Alan Kay's view that it /is/ necessary), but I still think that Lisp is (in practise) antithetical to OO thinking. It appears to promote a code-centric mindset rather than an object-centric one. Witness Denis's reply in this sub-thread: Denis Nikiforov wrote: > For me OO is mainly a way of code organization. I agree that OO could be > used like _one of_ the ways of thinking. In Lisp then I want to extend > language to support some cool feature (special form of loop, coroutine, > continuation or something else) I just write it. The specific thing that I consider typical of a Lisper is Denis's assumption that extending the expressible domain is as matter of extending the language, rather than of extending the domain to which the existing language applies. To reduce it to a caricature, where a Lisper implements abstraction by extending the semantic tower upwards[*], an OO-er just adds another object or two. ([*] possibly, but by no means necessarily, invoking Lisp's macro facility) BTW, Denis: > Actually, it's not so cool features, during Java learning my imagination > became doze ;) Cool features are new type systems based on something > like ACL2, object system extended with something like Lisa, mathematics > calculations formalized using Axiom, different emdeded DSLs and etc. ;) Agreed that these ideas are cooler[*] than your first bunch ;-) I'm afraid that you'll just have to accept that in Java these kinds of ideas are so out of range that they'll never be achievable. The language designers' heads are not in anywhere like that kind of space. And I don't think they ever will be. Java is /designed/ to be a limited, boring, language. BTW, you might find OpenJava interesting: http://www.csg.is.titech.ac.jp/openjava/ one attempt to open up Java's MOP. -- chris [*] Just for interest, and maybe for illustration, here's how your examples strike a hard-core OO-er. > new type systems based on something like ACL2 Type systems are about code, not behaviour, so who cares ? Now if you were talking about incorporating ACL-like concepts into the runtime /behaviour/ of objects, then that /would/ be interesting. The MOP-ery needed is way outside what's possible in Java, of course. > object system extended with something like Lisa Just more objects. Maybe some MOP-ery required too if you want to apply these concepts to /arbitrary/ pre-existing objects. > mathematics calculations formalized using Axiom Just more objects. > different emdeded DSLs Just more objects. (transmit-message (Hello 'Chris) (You-wrote :on "Wed, 22 Mar 2006 10:31:32 -0000") (Say '( >> Ohh... ;( I'm afraid Java isn't best language for learning of >> programming. IMHO, it's based mainly on engineering tradition and uses >> top-down approach. For learning I preffer language like Lisp based on >> designer tradition with bottom-up approach. There is no problem to >> program fast in latter, but, imho, it's very hard in former (like Java). CU> There's some truth in what you say. Certainly no Java environment CU> has anything like an acceptable level of interactivity. OTOH, Java CU> isn't really about "top-down" development -- it's about OO CU> programming which is neither top-down nor bottom-up (though it's CU> closer to the latter). For me OO is mainly a way of code organization. I agree that OO could be used like _one of_ the ways of thinking. In Lisp then I want to extend language to support some cool feature (special form of loop, coroutine, continuation or something else) I just write it. I call it bottom-up, creative approach. In Java smart engineers (somewhere in the sky) wrote a language specification for me and some little closer and a little less smart engineers writes specifications for my (assumed) work. My (assumed) work is to implement this specifications. I call it top-down approach. Both approaches sometimes good, sometimes bad. As I guess, in learning former approach is better, and I can't agree that Java supports this approach well. But, first, it doesn't mean that Java is a bad language, it's just hard to learn to think learning just Java and, second, my opinion means absolutly nothing because I'm a newbie ;) CU> Please don't take this as an insult, but from the languages you CU> list (and especially from your preference for Lisp[*]) I doubt CU> whether you have experience of OO programming. Or at least, I CU> think it's entirely possible that you don't have that experience. CU> BTW, programming web applications must be just about the worst CU> possible way to learn Java programming -- as you are discovering... But learning Java isn't my main target, it's just a tool. For now my undertaking is a model-based webapp design. I can use any adequate language I want, and I choosed Java because it has some good characteristics. CU> ([*] Lisp is a fine language for those who like it, but it appears CU> to me, as an outsider -- and despite CLOS -- to be antithetical to CU> OO thinking) I agree with it. Lisp gives you absolute freedom, it doesn't force you to use special way of thinking (like OO). I guess OO isn't an overkill approach. Signature))) => t (transmit-message (Hello 'Denis) (You-wrote :on "Wed, 22 Mar 2006 17:39:17 +0500") (Say '( DN> In Lisp then I want to extend language to support some cool feature DN> (special form of loop, coroutine, continuation or something else) I DN> just write it. Actually, it's not so cool features, during Java learning my imagination became doze ;) Cool features are new type systems based on something like ACL2, object system extended with something like Lisa, mathematics calculations formalized using Axiom, different emdeded DSLs and etc. ;) I can extend Lisp with all this apps or can write something similar but much simpler by myself. Signature))) => t [me:] > > BTW, programming web applications must be just about the worst > > possible way to learn Java programming -- as you are discovering... [quoted text clipped - 3 lines] > language I want, and I choosed Java because it has some good > characteristics. Unless the "some good characteristics" give Java a quite overwhelming advantage (for your purposes), I suspect you may be using the wrong language. You might find that either Rails (over Ruby) or Seaside (over Squeak or VW Smalltalk) suits you much better. -- chris (transmit-message (Hello 'Chris) (You-wrote :on "Thu, 23 Mar 2006 10:44:21 -0000") (Say '( CU> Denis Nikiforov wrote: CU> [me:] >> > BTW, programming web applications must be just about the worst >> > possible way to learn Java programming -- as you are discovering... [quoted text clipped - 3 lines] >> language I want, and I choosed Java because it has some good >> characteristics. CU> Unless the "some good characteristics" give Java a quite CU> overwhelming advantage (for your purposes), I suspect you may be CU> using the wrong language. You might find that either Rails (over CU> Ruby) or Seaside (over Squeak or VW Smalltalk) suits you much CU> better. Ruby and Smalltalk are two languages which I want to learn but I had not enough time for it ;( I sure heard about Rails and Seaside and know some other web-frameworks like UnCommon Web little better. But I guess Cocoon suits my needs better, because it's based on XML (it's very easy to generate, transform, manipulate, ... XML documents), and also Java has a lot of web 2.0 libraries (like Sesame, Jena, ...). Our approach is very close to OntoWeaver[1]. And so mainly we need a framework for ontology manipulation (for now we use Jena), I think we'll need a sophisticated inference engine (based on Prolog dialect or some logic framework) in future. Actually our approach doesn't depend on any particular language or web-framework. Another adjunct to our development process is that I'm only person (in our group) which heard something about languages like Lisp, Ruby, Smalltalk, it's very hard to find good hackers ;((( For now my main target is organization of our work and creation of working prototype version, which we can criticize, optimize and etc. After that I'll sure think about choose of programming language and etc. again. _____ [1] http://kmi.open.ac.uk/projects/akt/ontoweaver/ Signature))) => t >>Ohh... ;( I'm afraid Java isn't best language for learning of >>programming. IMHO, it's based mainly on engineering tradition and uses [quoted text clipped - 19 lines] > ([*] Lisp is a fine language for those who like it, but it appears to me, as an > outsider -- and despite CLOS -- to be antithetical to OO thinking) I'm an old Lisp hack, now a java programmer. I think you're wrong about lisp being anti-oo. Symbolics had a completely OO window system in the 1970's and CLOS is a more complete object system than java has. Most lisp programmers I know are writing entirely OO apps these days. As a general rule, you trade compile time type checking for interactivity. There's probably no fundamental reason this has to be true but languages with some type safety, like java & C++ are not interactive while perl, python, ruby & lisp are interactive but not type safe. I prefer programming in lisp too, and every now and then I write myself an emacs macro, but its essentialy a dead language. Wibble schrieb: > I prefer programming in lisp too, and every now > and then I write myself an emacs macro, but > its essentialy a dead language. Do you know why that is so? I have never used Lisp, but I think I have a grasp of it's concepts, and I think that it is far superior to a lot of languages that are common today, and at least a very solid alternative to the better ones. Timo >> its essentialy a dead language. >Do you know why that is so? McCarthy recently IIRC claimed that »Common Lisp« stabilized Lisp in such a manner that innovation was halted. But »dead language« can have multiple meanings: A »dead language« might mean: A language that is stable, i.e., does not change anymore. This might actually be just the right thing for long term portability as long as the language still is used widely and thus adopted for new platforms. »dead language« might also mean: A language that used only by a few persons and with few implementations available. Stefan Ram schrieb: >>> its essentialy a dead language. >> Do you know why that is so? > > McCarthy recently IIRC claimed that »Common Lisp« stabilized > Lisp in such a manner that innovation was halted. I see. Java is stabilized in such a manner that it was impossible to implement generics without type erasure. > But »dead language« can have multiple meanings: > [quoted text clipped - 5 lines] > »dead language« might also mean: A language that used only > by a few persons and with few implementations available. I think latin (a "dead language") is a good analogy. It isn't used "in production" anymore, i.e. there are no new books written in latin. But it is still translated by students and learning it helps understanding other languages. Timo > I think latin (a "dead language") is a good analogy. > > It isn't used "in production" anymore, i.e. there are no new books > written in latin. But it is still translated by students and learning it > helps understanding other languages. Lisp isn't dead in that sense. It's more like, say, Danish. It may not have as many speakers as some languages, but it has speakers (proper native speakers) who use it every day as a matter of routine. -- chris > Wibble schrieb: > [quoted text clipped - 9 lines] > > Timo There's a handful of things where Lisp just missed it. Better politics or design could have solved any of them but didn't. In the early days lisp was a small, single threaded, interpretted, free language (maclisp or franzlisp). It filled a role scripting languages do today, and then some. It was taken over by committees and corporations and evolved into a powerful, compiled, vastly bloated thing (CommonLisp). It still shares many limitations of scripting languages, but scripting languages have a different niche. Lisp only has runtime type checking, like a scripting language. Lisp exposed its guts to all programs, so was fundamentally unsafe. A hostile piece of code, can redefine what your application does on the fly in the same nice way you do it in the debugger. Lisp doesn't have a standard, portable way of doing multithreading or synchronization. CommonLisp requires a huge environment to do small things. The language was defined by a committee of weenies and reads like it. In the early days, there were no good free versions of CommonLisp. C was free and portable(kind of). Free languages win, always. Java has many of the nice things that Lisp had, except for interactivity and good macros. Java has alot that Lisp will never have, like its cool libraries, threading, type safety, security etc. I would recommend Java over lisp for anyone doing much more than homework. Unlike lisp, the tools and language are constantly improving and alot was incorporated from lisp. Ruby is a nice scripting language that seems to me to be a thinly disguised lisp implementation. Its interactive, easy to parse, and even has lambda notation. You may want to look at that too. If you want to find people who prefer lisp, try comp.lang.lisp . >Is there any tutorial/book like "How to program in Java fast." or "How >to setup environment for interactive and effective Java development."? The key is to find a book that matches your current skill level well. Ideally, you want one that does not tell you anything you already know and does not presume you know something you don't. Nothing beats reading a few pages at a bookstore to narrow down the candidates. If the book is opaque in the bookstore, it will be opaque when you get home. I love books with complete source code. That I can generally figure out even if the author's prose is atrocious. For a painless intro to Java, try Peter van Der Linden. Most books feel like a slog, his like a romp. I am a little biased since I helped edit the sections on generics and enums. Just Java 2, Sixth Edition http://www.amazon.com/exec/obidos/ASIN/0131482114/canadianmindprod see http://mindprod.com/jgloss/gettingstarted.html for other recommendations. SignatureCanadian Mind Products, Roedy Green. http://mindprod.com Java custom programming, consulting and coaching. > An answer that kinda covers both is: > primitive types such as int, char and boolean are not Objects and this > helps to improve the performance of java programs. Not to mention null... And all the "static" crud... And constructors... And a type-system which unduly emphasises ancestry over behaviour... -- chris in what ways is java not purely object oriented? irfan sez: > in what ways is java not purely object oriented? In 5 ways from Sunday. When's your homework due, by the way? Dima Signature...the mainstream products of major vendors largely ignore these demonstrated technologies... [Instead, their customers] are left with several ineffective solutions collected under marketing titles like "defense in depth". -- Thirty Years Later: Lessons from the Multics Security Evaluation irfan wrote On 03/21/06 03:19,: > hi, > > I want to know why java is not a pure object oriented > programming language. It used to be, but ever since the Garbage Collector sinned in Eden, Java hasn't been pure. It is prophesied that Java will again become pure when the Refactorer appears and washes all Java programmers in the JBlood of the JLamb. JAmen. SignatureEric.Sosman@sun.com :-D I just nearly spat my drink all over my keyboard! Eric Sosman schrieb: > irfan wrote On 03/21/06 03:19,: >> hi, [quoted text clipped - 7 lines] > appears and washes all Java programmers in the JBlood > of the JLamb. JAmen. Damn good distraction technique! :) > irfan wrote On 03/21/06 03:19,: > > hi, [quoted text clipped - 7 lines] > appears and washes all Java programmers in the JBlood > of the JLamb. JAmen. Jlol Signaturetrippy mhm31x9 Smeeter#29 WSD#30 sTaRShInE_mOOnBeAm aT HoTmAil dOt CoM NP: "The Way It Is" -- Tesla "Now, technology's getting better all the time and that's fine, but most of the time all you need is a stick of gum, a pocketknife, and a smile." -- Robert Redford "Spy Game" > I want to know why java is not a pure object oriented >programming language. Compare Java with Eiffel. In Eiffel, ints are treated as objects. They came up with some way of implementing ints much the way Java does primitives, as a sort of optimisation. Java invented autoboxing as a sort of afterthought which sort of lets you treat primitives as if they were objects. I think the difference is Meyer, (Eiffel's designer) was primarily a high level language designer interested in the how the language appears to the programmer and its features such as design by contract, consistent syntax etc. Whereas Gosling was a JVM designer interested in making the JVM work efficiently, perhaps with an eventual eye to building a hardware JVM.. To him, Java was just a sort of macro language for generating JVM byte codes, something of an afterthought, and certainly not the only way to generate byte codes. He was not all that interested in Java the language other than making sure it could generate all the interesting patterns of JVM byte code. He was a pragmatist who used C as a his model knowing that would sell best. SignatureCanadian Mind Products, Roedy Green. http://mindprod.com Java custom programming, consulting and coaching. >I want to know why java is not a pure object oriented >programming language. See http://c2.com/cgi/wiki?IsJavaObjectOriented >>I want to know why java is not a pure object oriented >>programming language. >See http://c2.com/cgi/wiki?IsJavaObjectOriented On my todo-list I have an entry »Why Java is not object-oriented (article)«. However, someone else already wrote that, possibly with other contents than the article I plan to write: »What makes people think that C++/Java is OO? Notice that I don't make the distinction between C++ and Java? Most people put C and C++ together. But in reality C++ and Java does not deserve to be put in the same category as C. It's degrading to C.« More can be read on: http://my.opera.com/Vorlath/blog/show.dml/58528 Another example from his blog: »Alan Kay (...) wanted it to be individual cells that interacted with each other. And he wanted to get rid of data. That there would only be these cells and interactions between them. If this is all I knew about object oriented, I jump on board. Then why do I claim it is flawed? Simple. Implementation details. Alan Kay and every other implementation of OOP left in the function call. Messages that are sent must return before you can send another one. The syntax is different is SmallTalk, but it's all the same. It's all basically function calls. (...) Do you now see the flaw in the implementation of OOP? If all cells were allowed to interact at the same time like in real life, I'd be all for it. But no. Everyone has to take turns and there is a master cell. All other cells are sub-cells that have to wait their turn and be called by other higher level cells. It's a hierarchy when it should have been a free flowing graph. (...)« http://my.opera.com/Vorlath/blog/show.dml/202787 >>>I want to know why java is not a pure object oriented >>>programming language. [quoted text clipped - 10 lines] > does not deserve to be put in the same category as C. It's > degrading to C.« Object-oriented is a methodology, not a language...Although, some languages lend themselves better to following the OO paradigm. And that's all I have to say on this issue. >Object-oriented is a methodology »object-oriented« is an adjective (participle), while »methodology« is a noun. >And that's all I have to say on this issue. That was already one paragraph too much, because it does not give any more information relevant to the topic. > http://my.opera.com/Vorlath/blog/show.dml/58528 > http://my.opera.com/Vorlath/blog/show.dml/202787 He seems to put undue emphasis on the calling sequence in the language. It doesn't (to me) seem that whether a message send is essentially a function call has anything to do with OO. Unless you are doing very bad OO, the /sequence/ of message sends is largely (not entirely) immaterial, so the question of whether they are serialised is not of central importance. Naturally there are /practical/ considerations involved too -- if an object can really encounter overlapping message sends, then it will have to synchronise itself somehow. But note that that is a problem /whatever/ the message send semantics. Indeed the fact that (say) Java has the mechanism to control that case shows that Java is not less OO because it uses function call semantics. BTW, there's one extension of Smalltalk that decoupled the message send semantics from function call semantics -- each send could be synchronous or asynchronous; replies could be sent, or not; replies could be waited for or not. Nice stuff, and there are interesting concepts in there, but the resulting system was not more OO than the vanilla Smalltalk that it started with. The new system was more expressive, sure, but in a direction orthogonal to OO (except in so far as OO was necessary in order to formulate and use the new freedoms). -- chris 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
|
©2008 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.