There seems to be a group of people who like to disparage Java like it were equivalent to VB! I notice that this group tends to come from the C/Lisp/*nix community. Groups that promote Perl and PHP as the true solutions.. or Python because it is more "script-like". (or because these all start with P??)
I think part of the debate is static vs. dynamic typing all over again. All these supposed "better" languages are dynamic typed. Certainly dynamic typing has its advantages: I can still code much much faster in PHP even though I am much more adept at Java and waste an inmense amount of time fumbling around www.php.net trying to figure out how the language works). This is shocking if you think about it! Or, maybe not...
Dynamic typing IS more expressive, IS simpler, IS faster.. but dynamic typing has the advantage of better maintainability (by default).
Why??
Well, when I want remove a class in a Java project, I just rip it out.. the compiler then tells me what I need to change. Sure, you could do the same with unit tests in P**** but you HAVE TO WRITE THEM.. and in Java you get the functionality EVEN IF YOU DON'T.
Intellij IDEA and Eclipse are marvelous too (JBuilder to a lesser extent).. they quickly id errors in your code. How do they do this? They do it because they take advantage of static typing. Yeah, sure, it's a pain to type all those declarations.. but in the end the analysis you can do on the code is much better, and with the right tools you'll have less bugs.
On the other hand I have to agree with other posters that Java is just a Smalltalk wannabe.. I mainly moved to it because it was like Smalltalk (before I was doing C++.. C++ is stinky). I worked a summer at the VisualAge for Smalltalk team, and dealt with OTI code (before they were IBM). Needless to say.. I was impressed with their approach. Today Eclipse.org is trying to do what IBM and OTI tried back then.. and with the same amount of controversy.
They claimed that the native approach to portable widgets was superior, but most Smalltalkers disagreed. I, was of course influenced by this, and always thought that Swing was the wrong approach. What was really wrong though, is that Sun doesn't know how to do native UIs. Had AWT been SWT, Swing never would have existed.
Now for some trolling: the most famous Lisp app is Emacs the most famous Perl app is ?? (Bugzilla maybe?) the most famous Java app is maybe one of: Websphere, Weblogic, Eclipse, JBoss, log4j, JUnit, etc...
I dunno which the most famous one is.. but they are certainly more impressive to the average business than Emacs.
I like Lisp.. but Java helped fuel patterns, extreme programming, unit testing, standard logging practices, very complex enterprise apps for the average programmer, etc...
Before that we were all just trying to figure out why destructors had to be virtual.. and stuff like that.
Orbitz also uses masses of Jini stuf and the ITA Engine, although important, is just a component that's linked together by their Jini-based infrastructure
> Orbitz also uses masses of Jini stuf and the ITA Engine, > although important, is just a component that's linked > together by their Jini-based infrastructure
And the ITA Engine also uses C++ - does that somehow mean that it isn't a well known Lisp application?
> Interesting. > > What makes Eclipse powerful is its access to the > programming language constructs. Lisp has this by > default, providing it with unbelievable flexibility. > Smalltalk has access to it to. Python and Ruby have it > t to an extents (after all they are interpreted) however > possibly more at the runtime level and not at the syntax > level. The key is introspection, from there you can build > powerful language environments. ... > However, I guess I have to qualify my argument, the > argument against Lisp can easily put me in hot water, same > goes with Smalltalk. However, arguments against Python, > Ruby or Perl still hold true. > > This of course brings up another question, if Lisp and > Smalltalk environments were so good, how come Python and > Ruby are more popular now? Answer: Architecture of > Participation ;-)
My main interest is writing GUIs on the client, I used to write NeXTStep/Objective-C apps, and recently I've been working on ruby bindings for the KDE project.
I'm not sure if an Objective-C programmer can be included with the Smalltalk enthusiasts - its only a subset. I would say that the dynamic features of Objective-C make a huge difference to writing GUI apps. You can add or change methods on a running instance via 'categories', with code dynamically loaded from 'bundles'. And reflection/introspection is far less clunky in Objective-C than java.
I like the clarity of the Objective-C/Smalltalk syntax - rather than knowing what an argument means by its position in the argument list, there are keywords that tell you what each arg means.
The downside is when you want to base a native api on Smalltalk or Objective-C, which needs to be used in several languages. That makes it harder to write auto-generated language bindings for Cocoa/Objective-C than it is for KDE/C++, as no other languages use similar syntax.
Why do you say that python and ruby 'have it to an extent (after all they are interpreted)' referring to dynamism compared with lisp or Smalltalk? I'm not an expert on python, but I can certainly confirm that ruby doesn't give away anything in terms of runtime introspection, and it has a more complete 'autoboxing-less' type system that java's. Ruby isn't a toy 'scripting language' at all, even though it can be used perfectly well for scripting.
I'm sure Eclipse fixes java development environment problems caused by the static nature of the language. But I just think the rest of us don't really need that stuff..
> Why do you say that python and ruby 'have it to an extent > (after all they are interpreted)' referring to dynamism > compared with lisp or Smalltalk? I'm not an expert on > python, but I can certainly confirm that ruby doesn't give > away anything in terms of runtime introspection, and it > has a more complete 'autoboxing-less' type system that > java's. Ruby isn't a toy 'scripting language' at all, even > though it can be used perfectly well for scripting. > Access to language syntax has nothing to do with being dynamic or statically typed. Its about having the APIs to read and manipulate the source code. Lisp has it, because everything in Lisp are lists including the source code. Smalltalk has it since the parsing classes are available on the workbench. Perl, Python, Ruby all do not have this.
> > I'm sure Eclipse fixes java development environment > problems caused by the static nature of the language. But > I just think the rest of us don't really need that stuff.. > When you refer to the "static nature" of Java and at the same time call objective-c dynamic, then I'm really confused as to what you mean. Historically, Java derives most of its ideas from Objective-C. I can't see how one can say that they are philosphically at odds.
"One of the many advantages of dynamic languages such as Ruby is the ability to introspect---to examine aspects of the program from within the program itself. Java, for one, calls this feature reflection."
> Access to language syntax has nothing to do with being > dynamic or statically typed. Its about having the APIs to > read and manipulate the source code. Perl, Python, Ruby > all do not have this.
What makes you think they don't?
At least in Python there are standard library ways to do that. I would not say they are easy or common, but they are there.
To do so is against Pythons culture, but that's another story.
There's a significant different between having introspection libraries and having a compiler.
Rule of thumb, is the compiler for the language written in the same language, or less restrictive, is the AST accessible in the language.
Answer: true for Lisp, Smalltalk, Java. False for Perl. Unsure about Ruby or Python (true for Jython) most likely answer is No. So if you got a definite link, then please provide it.
> Access to language syntax has nothing to do with being > dynamic or statically typed. Its about having the APIs to > read and manipulate the source code. Lisp has it, because > everything in Lisp are lists including the source code. > Smalltalk has it since the parsing classes are available > e on the workbench. Perl, Python, Ruby all do not have > this. Yes you're right, ruby introspection doesn't allow you to access the source code like Smalltalk. But it is easy in ruby to do 'data => code conversions' at runtime - you don't need runtime access to the source code to do that. > > > > I'm sure Eclipse fixes java development environment > > problems caused by the static nature of the language. > But > > I just think the rest of us don't really need that > stuff.. > > > When you refer to the "static nature" of Java and at the > same time call objective-c dynamic, then I'm really > confused as to what you mean. Historically, Java derives > most of its ideas from Objective-C. I can't see how one > can say that they are philosphically at odds. No I disagree that java was influenced by Objective-C or Smalltalk. For instance, java has no dynamic despatch on static methods - it doesn't have class methods. Also classes or not first class types. In Objective-C, you can send a message to a class to create a new instance. Java has to have 'borked' factory method patterns to get round this obvious limitation. You can't have static methods in interfaces, which in turn messes up remoting - this design flaw permeates java.
Rule of thumb, is the compiler for the language written in the same language, or less restrictive, is the AST accessible in the language.
Answer: true for Lisp, Smalltalk, Java.
Is AST access really part of the standard Java APIs?
"Future versions of this API might expose more of the structure of the program, ... or even the code itself (ASTs: Abstract Sytntax Trees). These are not goals of the initial version of this specifications." http://www.jcp.org/en/jsr/detail?id=199
As to Java being influenced by Objective-C, we only have Gosling's actual words on the subject... [googling those left to the reader]. But I think the particular influence was the concept of a defined "interface", which is a different term in Objective-C, and which is not part of Smalltalk-80 (which relies on implicit interfaces, a.k.a. Python's "duck typing".
It worth remembering that the first automated Refactoring tools (post Martin Fowler's book) were implemented in Smalltalk. And JUnit and (by extension) many other xUnit frameworks for test-driven-development were inspired by the SUnit framework in Smalltalk. And the first "Extreme Programming" project run by Kent Beck and Ron Jeffries was using team-oriented Smalltalk-based tools -- VisualWorks Smalltalk, Gemstone OO database, and Envy 3.01 source-code-control.
It worth remembering that the first automated Refactoring tools (post Martin Fowler's book) were implemented in Smalltalk.
Actually before Martin Fowler's book:
"Even before I started work on the refactoring book, John Brant and Don Roberts came up with the Smalltalk Refactoring Browser. This awesome tool makes refactoring much quicker and more pleasurable." http://www.martinfowler.com/articles/refactoringRubicon.html
> Is AST access really part of the standard Java APIs? >
No it is not but is available within the Eclipse environment. Ask yourself the same question for smalltalk. Don't know if smalltalk has the concept of a "standard api" however its available in the environment.
For Python and Ruby, well I don't know where you are going to dig up the AST. Possibly in some alpha-state open source project, but nothing as mature as the Eclipse JDT. Come to think of it, if you dig a bit deeper, you'll find the AST in every JDK distribution. Its not public, but I've been able build a visitor against in to spit out SAX events.
Carlos
Flat View: This topic has 32 replies
on 3 pages
[
«
|
123
|
»
]
Previous Topic
