Slashdot Log In
Beyond Java
Posted by
samzenpus
on Wed Feb 01, 2006 02:33 PM
from the to-infinity dept.
from the to-infinity dept.
Anml4ixoye writes "I recently got sent a copy of Bruce Tate's newest book Beyond Java - A Glimpse at the Future of Programming Languages. Having read Bruce's Bitter Java and Better, Faster, Lighter Java, I was intrigued to see what he would have to say about moving beyond Java. In short: If you're a hard-core Java (or to a lesser extent, C#) developer who thinks Ruby is something that goes on a ring, Pythons will bite you, and Smalltalk is something you have to do at parties, you are in for a rude awakening." Read the rest of Cory's review.
Let's get down to it. For many people, Java pays the bills. For dealing with big problems, it is a wonderful language with a myriad of libraries for solving domain-specific problems. The author thinks that this focus on the larger applications is causing Java to alienate the developers who need solutions to small, real-world problems, like babysitting a database with a web site.
Bruce starts out in Chapter 1 discussing a disrupting experience he recently had when he discovered how much faster and more productive he and his team were when they switched mid-stream to Ruby on Rails. He gives some controversial numbers that discuss this improvement. This experience leads him to realize that maybe Java is dying - or at least fading in certain areas.
His next sections (Chapters 2 and 3) discusses the "Perfect Storm" that led Java to become the leader it is today. How it traded the OO purity of Smalltalk to woo C++ developers. And how the programming environment was calling out for a language like it.
But that landscape is changing, and Java is having a hard time keeping up. In chapter 4, he gives an example of servlets. Earlier servlet specs allowed you to get a Hello, World servlet, albeit ugly, up rather quickly. That same example now requires deployment descriptors, packaging into WAR files, configuration files, etc, etc. For Java developers, this is the norm, but for a developer new to Java, who wants to learn all that?
Chapter 5 is a discussion of what Bruce feels is the Rules of the Game, or what the next "Killer language" will need in order to beat out Java. This was a very good treatment, highlighting some of the good and bad of Java and languages as a whole. For example, he rates high that you will need some sort of Enterprise Integration, Internet Focus, and Interoperability. He also feels things like dynamic typing, rapid feedback loops and dynamic class models (making reflection more natural).
Most importantly, it needs a killer app to act as a catalyst to get people's mindsets changed. In Chapters 6, 7 and 8, he gives examples of some killer apps - Ruby on Rails and Smalltalk's Continuation servers (like Seaside). Chapter 6 is a kick-in-the-teeth intro to Ruby (which left me wanting to go out and pick up Dave Thomas' Programming Ruby book). Chapter 7 shows a sample Ruby on Rails application, and Chapter 8 gives a very interesting look into Continuation servers and the work being done by the Smalltalk community on it.
Finally, he closes the book with a list of Primary and Secondary contenders that could up and replace Java. Primaries include Ruby, Python, Groovy, and .NET (C# and VB.NET). Secondary contenders include Perl, Smalltalk, PHP and Lisp, which he summarizes as: "Perl's too loose and too messy, PHP is too close to the HTML, Lisp is not accessible, and Smalltalk wasn't Java". To which he adds, "...go ahead and fire up your GMail client and your thesaurus, and drop me a nasty note. Ted Neward reviewed this book, so I can take a few more euphemisms for the word sucks".
Thankfully there is nothing in this book that would cause me to write a nasty note to Mr. Tate. In fact, if you haven't begun looking at other languages and are heavy in the Java world, I would highly recommend picking up a copy of the book. It's a fast, intriguing read with great insights and the chance to save yourself from looking around 4 years from now wondering what the heck happened, and why all of these developers can afford jewels and play with snakes while chatting among themselves."
You can purchase Beyond Java: A Glimpse at the Future of Programming Languages from bn.com. Slashdot welcomes readers' book reviews -- to see your own review here, read the book review guidelines, then visit the submission page.
This discussion has been archived.
No new comments can be posted.
The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
Ruby's Quite Nice, Really (Score:5, Informative)
I can understand why he noted Ruby as a primary contender with Java. I've been learning it from an online primer [rubycentral.com], and it seems quite flexible and elegant. Java, on the other hand, is much too bloated.
Re:Ruby's Quite Nice, Really (Score:4, Insightful)
1) extinct, or,
2) 'bloated'
Parent
Re:Ruby's Quite Nice, Really (Score:3, Informative)
-jcr
Re:Ruby's Quite Nice, Really (Score:3, Interesting)
Seeing as Matz intend to stay in command of Ruby (as he's been since he created it) and has started a complete, faster, more efficient rewrite of Ruby for Ruby 2.0 (without even excluding possible backward-compatibility breakage for the sake of sanity and efficiency), without the errors of the past (e.g. without the mistakes he made raising Ruby from the beginning to the current 1.8.4) and potentially with a JIT at the end, Ruby doesn't intend to take the path Java did.
And neither does Python, obviously.
S
Re:Ruby's Quite Nice, Really (Score:5, Insightful)
People keep repeating this, but it just isn't true. What Java has is an extensive set of libraries that provide all kinds of common functionality. If I were asked to trim it down, I'd have a hard time nixing anything that wouldn't get me in trouble with a LOT of people.
The main problem that Java still has is a large memory footprint. This is due to loading all those libraries into memory at startup. Why is this done? To reduce startup time. (i.e. It doesn't have to keep hitting the disk every time a new class is instantiated.) Thus Java appears "bloated". Yet if they remove the "bloat", people complain about the startup time. It's really difficult for Java to win this one.
The only real solution to this dichotomy is to make Java an operating system component. As a system-wide component, it could keep all the info in memory ONCE (including the pre-compiled versions of the classes) and make effective use of the system resources. This is very similar to what most OSes do with their libraries. Sun has taken steps toward this design with new code that preloads the classes into a shared memory area, but it's only partially complete. Given Microsoft's stance on Java, it's doubtful that they'll ever be able to completely solve the issue on Windows.
Thankfully, systems today have tons of memory and disk space. Since the unused classes will just be swapped out to disk anyway, there's no real concern. So quit whining, and enjoy what the Java platform has to offer.
Parent
Re:Ruby's Quite Nice, Really (Score:4, Informative)
Parent
Re:Ruby's Quite Nice, Really (Score:5, Informative)
Parent
Re:Ruby's Quite Nice, Really (Score:3, Insightful)
Essentially Operating Systems would startup a JRE when they startup. The actual memory footprint would be around 16MB for Java5. That way when apps loaded, they could reuse the existing JVM, sharing common classes with other applications. Think of dynamic libraries on steroids. It wouldnt just be a shared library but possibly instatiated objects.
As for a repository system for libraries, this uneeded.
Re:Ruby's Quite Nice, Really (Score:4, Informative)
It looks like my next language of choice, however. I like the OO concepts, and although the block/yield methodology is a bit awkward (the packaging of blocks into Procs is the way the entire language should have gone, I 'got' that concept much easier), it's solid and on it's way to much wider use.
Parent
D programming (Score:5, Interesting)
See it here http://www.digitalmars.com/d/ [digitalmars.com]
Re:D programming (Score:5, Funny)
Parent
Re:D programming (Score:3, Interesting)
Re:D programming (Score:3, Insightful)
Comparison with perl?? (Score:3, Insightful)
Re:Comparison with perl?? (Score:3, Funny)
Re:Comparison with perl?? (Score:3, Insightful)
Now, I work in a department where Java is the canonical language, and other languages are discouraged (except expect - *ugh* - but I understand why)
And guess what? For the most of the applications we write and deploy, Java is a great choice! Looking back on some of my larger perl programs, I wish I could re-write them in Java. They'd be
News flash: (Score:5, Insightful)
If you half ass your job in any professional field, you are in for a rude awakening. This is not news.
Perl is not too loose and messy (Score:4, Insightful)
The typical response is to post some obsfustacted perl with a good reg exp thrown in for good measure and some cute comment about ascii explosions. These are red herrings. To these I say:
Any langauge can be obfusticated and C is perhaps the easiest to obfusticate.
Built in reg exp are extreme useful - learn to used them and do not fear them. Or good coding style requires you to document them. A single line reg exp can replace pages of code.
(ot-ish) Perl is not too loose and messy (Score:3, Informative)
Example, if you had a list of files, and you wanted to print files from a list that exist (not contrived, I was doing this the other day) you would probably write something like:
foreach (file in files) {
if (Exists(file)) {
print file;
}
}
A programmer who has never seen the language before
Java's regexp support is yucky (Score:4, Interesting)
I only use Perl for quick scripts, but compare the following:
Perl:
Java:
It is telling that I had to go look up the Java interface (I am a professional Java developer and have been for 8 years), while the Perl came naturally (I am pretty good with Perl, but I only use it for scripting support).
Java does NOT have built-in regular expression support, at least not at all in the same way that Perl does.
Parent
Rails (Score:4, Insightful)
What I've found is that it really is much faster in initial development. Rails has an explicit separation of model, view and controller code, while in Java it tends to become convenient to mix all but the lower levels within .jsp pages. Another worry I have is the packaging system, which is harder to manage than Java's dom.company.package.subpackage structure. I could imagine that namespace conflicts would be inevitable in Ruby as with other 'scripting' (sorry to use that word) languages.
I haven't gotten much further than that.. Once I get to the point of having to maintain and expand on a larger codebase I'll no doubt have stronger opinions on its strengths and weaknesses, but for now, I'd say that most of what people are doing in Java can be done more simply and faster in Rails (or perhaps a Perl framework). I'd be concerned about its resilience and scalability on larger systems, as well as its industry or 3rd party support (Java's support, esp from Apache, is outstanding).
Re:Rails (Score:5, Insightful)
Parent
Ah. Dynamic typing. Again. (Score:5, Interesting)
I pray that the future will not be dynamically typed. We have enough run-time bugs as-is, and while I am in no way opposed to doing prototyping in dynamically typed languages, I would much prefer my everyday applications to be written in languages that don't constantly segfault because of pointer arithmetic, raise null pointer exceptions because nullable and nonnullable types are not distinguished, or give syntax errors at runtime because they happen to be fully interpreted.
Most static type systems suck, which is why people don't like them, but people who have used, say, SML or Haskell, tend to agree that static types can be something very natural and useful (the SML community has a saying which goes, roughly, "if it compiles, it's almost certainly correct").
I don't know about you guys, but I'd much rather have a slightly harder time with dynamic module loading, reflection (which, IMHO, is vastly overrated, considering the correctness/safety/usefulness tradeoff) and perhaps side effects than having to find all of my bugs (rather than 5% of them) through testing.
Just my EUR 0.018.
-- Christoph
Re:Ah. Dynamic typing. Again. (Score:5, Insightful)
I've been using Python for prototypes, and have come to like the concise and clear nature of the syntax compared to Java and Perl. However I don't like the thread handling, the lack of quality compared to Java in the libraries, and the lack of some libraries that enterprise applications commonly use. Some performance measurements I've made also show Java is 4-10 times faster.
Parent
Re:Ah. Dynamic typing. Again. (Score:5, Insightful)
Now, the null pointer exceptions don't happen in these languages because there are no pointers, but similar things do happen. And they happen in Java too. Java not statically typed enough? Well, whatever, you get back to me when you have that awesome statically typed language with no slop that anyone actually does useful things with.
I don't think experience has shown us that statically typed languages are more reliable than dynamic. Programs that are developed with obsessive attention to detail, extensive review, and formalized practices and standards are reliable. None of those has anything to do with static typing; static typing is the absurd notion that the computer can be disciplined for you. If you look at something like programming by contract, it has nothing to do with static typing -- it's all about the programmers writing the system spending time indicating the exact needs and promises of the API, and language gives those programmers a structure in which to describe and automatically confirm those promises.
Parent
Rails and unit tests (Score:3, Informative)
One nice thing about Rails is that the unit tests are built in. Rather than having to go out and use JUnitWebTest or whatever, once you start writing Rails code the basic tests are generated for you and writing new tests involves fairly readable code, like this:
It seems like the folks who are writing Rails are aware of the whole web development picture; not just getting a web app up but also making sure it's well tested. It's certainly making RubyForge much busier [blogs.com]...
Oh, and, book plug [pmdapplied.com]!
News flash! (Score:5, Funny)
And no, the Batmobile doesn't count as a "commuter car".
Lisp (Score:5, Insightful)
Re:Lisp (Score:5, Interesting)
Hey, that's what I was going to post!
I used to work as a Java programmer, then on to Python and Perl. I've looked at RoR, and it's extremely impressive (basically, one guy defined web app best practices for the next decade, I think - not necessarily this particular implementation in Ruby, but the setup of the framework, emphasis on good defaults, sensible object model, well integrated testing, real easy use of Ajax, etc... very impressive)
But then I read Practical Common Lisp. And it rather opened my eyes. Turns out all these dynamic features of Python, Perl, Ruby etc are really just subsets of what's available in Lisp (like those Lisp people always insisted, but I never believed), and it's blazingly fast. It's compiled into machine code. I'm in love.
Right now, the useful Web libraries are just about there, but I don't think they are quite as featureful yet as what we're used to in the scripting languages. But I expect that to change dramatically in the coming year, as so many web programmers are checking out that book...
Parent
It's Too Much. (Score:5, Insightful)
I'm only 35 and I'm so tired of it. I don't want new languages. I just want to work with tools the team truly understands.
I have a life outside of work. The days of my wanting to read through stacks of documentation in the evenings to learn the latest new thing are gone.
So I'm being groomed for what I think is the natural progression for the tired but still knowledgeable developer... project management.
Re:It's Too Much. (Score:4, Interesting)
Parent
Python (Score:3, Informative)
Python is the best language I've ever worked with. It's very human friendly, no need to learn/read/write hieroglyphs, like in Ruby or Perl. Very compact, no need to write a pages of text to print Hello World, like in Java. It's very oo, supports multiple inheritance, what makes code reuse a reality. Has a wide range of modules, a wonderful application server, called Zope [zope.org], a code generator, that eats UML [plone.org] and many many features, to make it an outstanding choice.
Lisp not accessible? (Score:5, Informative)
I've been reading Practical Common Lisp [gigamonkeys.com], and I have to say I love Lisp so far. I'm down to the practical examples and continue to enjoy the experience of reading, learning and coding lisp. It's certainly an excellent book and it shows, since it is a finalist in the Jolt awards.
Paul Graham [paulgraham.com] is a big advocate of Lisp. He made big bucks selling is 3 year-old company to Yahoo, a company that was built off of software coded in Lisp.
Of course, one can't forgot the quote from Eric Raymond's 'How To Become A Hacker': LISP is worth learning for a different reason -- the profound enlightenment experience you will have when you finally get it. That experience will make you a better programmer for the rest of your days, even if you never actually use LISP itself a lot. I especially like these quotes from the blurbs section of the PCL website:
"This book shows the power of Lisp not only in the areas that it has traditionally been noted for--such as developing a complete unit test framework in only 26 lines of code--but also in new areas such as parsing binary MP3 files, building a web application for browsing a collection of songs, and streaming audio over the web. Many readers will be surprised that Lisp allows you to do all this with conciseness similar to scripting languages such as Python, efficiency similar to C++, and unparalleled flexibility in designing your own language extensions." --Peter Norvig, Director of Search Quality, Google Inc; author of Paradigms of Artificial Intelligence Programming: Case Studies in Common Lisp
"Please don't assume Common Lisp is only useful for Databases, Unit Test Frameworks, Spam Filters, ID3 Parsers, Web Programming, Shoutcast Servers, HTML Generation Interpreters, and HTML Generation Compilers just because these are the only things happened to be implemented in the book Practical Common Lisp.--Tobias C. Rittweiler, Lisp Programmer
Lisp was once in the same position C, C++ and now Java were/is in. It was one of those languages you had to know if you were going to get a job in programming. The only reason why it isn't still in that position is because it was ahead of its time. It was once thought to be slow, but Lisp compilers can compile to machine code and run as fast or even faster than C/C++. Lisp gives you the flexibility to code quickly to get features working and it also allows you to go back and optimize your code to perform at C levels.
So don't make the mistake of thinking Lisp is simply a worthless, academic language. Just check out Practical Common Lisp and see for yourself!
Not very insightful (Score:5, Interesting)
If he had tried, he could have gotten insightful and well-thought-out contributions from developers who are experienced with the kinds of things he talks about. He could have edited them down to be concise and reasoned expositions on the benefits and pitfalls that might lie ahead for the Java developer interested in change. Not everyone is a cheerleader, lots of people with lots of experience and investment in these other technologies are willing to talk about them in reasoned ways, and offer some real wisdom about the good and bad. But he just talked to a bunch of Java guys. No offense to those guys, but transcribing a few email exchanges into a book isn't cool.
Application Programming (Score:5, Insightful)
Looking at Java, the only thing I found interesting was the ability to write platform-independent applications. Even for that, Java appeared to have some significant shortcomings. I'm sure I'm not the only one who felt that way -- considering how few stand-alone Java apps I have installed on my computer now. Let me count. . .
Three. I have three Java apps. I have more apps built in REALbasic than in Java. So much for Java taking over the world, eh? And now people are buzzing about Ruby. Ruby? Man, it's an *interpreted* language! If I were coding a CMS, sure, I'd consider it. I may use it as a scripting language for my apps, it should be very spiffy for that. Will I code the apps themselves in Ruby? No!
Recently I've been learning my way around Mac OS X, with Objective-C and Cocoa. It's not perfect. But. . . For what it's designed for, for developing stand-alone GUI-based applications, I haven't seen anything dramatically better. And you know, I have doubts about whether I'm ever going to. Nobody is working on languages oriented toward application programming anymore. Some of the newer languages can do it, but they aren't focused on it. Apps and GUIs are a sideline, an afterthought.
Heard it all before.... (Score:5, Insightful)
Java is omnnipresent in the marketplace and contra the usual
Java utterly dwarfs Ruby or Python in the workplace, and that's not because Ruby needs more time - Ruby has been around for ages already, it's just not what people want to use. The fact that Rails is a nice solution to ONE single problem domain doesn't make the Ruby language a success - in fact, a simple perusal of the numbers shows that Ruby doesn't even figure. Go read the book sales numbers for Ruby - all but nonexistant compared to Java.
Show me where the tool support for Ruby is. Show me Ruby for cellphones, show me Ruby on embedded devices. Show me enterprise level Ruby. Go look at eBay - running Java, go look at Google - running Java, go look at IBM and Apple - strong proponents of Java. Why? Not fucking hype, but because it does the fucking job well - DESPITE the bleating of whiney assed slashbot fan boys. Grow the fuck up, Java is successful because it is good at getting stuff done. End of story.
Sourceforge is now dominated by Java - more FOSS is coming out made in Java than C or C++. Compare the supposed "Java killers" like C#, Ruby - they don't even figure.
This whole "Java is dead" thing is utter crap and merely reflects the
Java will be superceded at some point, all languages fade from the number one spot at some point, but none of the current crop of tin pot alternatives being bandied around on
Re:Dynamic typing (Score:3, Insightful)
For a nice tradeoff of static and dynamic typing, check out pike. Its statically typed, but lets you give up just as much of that staticness as you need when you need to. You can declare a fu
Re:Dynamic typing (Score:3, Insightful)
or inheritence:
rather than dynamic typing:
I'm firmly in the static typing camp. Not only does it make things more reliable (due to compilers catching errors) it also prevents those errors in the first place by allowing IDEs to be smart and suggest appropriate parameters. Going back to dynamic typing also means going back to vi as the u
Re:Dynamic typing (Score:4, Insightful)
If I'm building a treehouse for my kids* I'm probably not going to bother with the same sort of formal measurement that I would use to build a house for myself - line it up and cut it to fit will do most of the time. That flexibility is beneficial because I'm building around a tree, and being able reshape and redesign things easily makes a whole lot more sense in that environment (the other option being spending several weeks surveying the tree, and a lot of long tedious calculations to deal with its twisting organic structure).
If I'm building a house to live in I'm probably not going to just slap it together: I want to have some sort of design and measure everything against that as I go so I can be sure everything will fit together exactly as I want it to when I'm done. This more rigorous checking saves vast amounts of time over a flexible approach because I know that as long as all my measurements match up, the house will stay up - with a more dynamic approach I'll have to be testing everything every step of the way.
If I'm building a bridge or a bank vault I'm probably going to have another level again of formal requirements and calculations to ensure not just that things fit together, but that I can be certain that it will be safe in all weather conditions, or properly secure from potential thieves. Bothering to have detailed specifications from which extensive calculations and proofs of deep properties can be made is going to save me effort in the long run - it's just another level of formality again, above that used to design and build the house.
Now to my mind these three cases represent dynamic typing, static typing, and full formal specification (for those who think static typing in Haskell is as high as you can go, check out HasCASL). Each has their own place, and it's a matter of what it is that you're doing that determines which is the most suitable approach. If you mostly work on treehouses then someone telling you that you need to be properly measuring everything is going to seem like a pedant who just wants to annoy you and slow down your treehouse building. If you mostly build houses then someone telling you to hold up the 2x4 to where it needs to go and cut it to shape is going to seem reckless and foolhardy. As long as you're looking at everything only through the type of things you build the other point of view will always look silly.
Jedidiah
* (I am not trying to suggest that dynamic typing is for inconsequential or throwaway projects, I just wanted an example that is fairly dynamic and works best with an evolving approach)
Parent
Re:Dynamic typing (Score:5, Informative)
For the dynamic versus static typing debate, in particular read http://paulgraham.com/hundred.html [paulgraham.com]
I've done both styles quite a lot, and I can say that static typing really is overrated. It sacrifices too much language power for what is really too little benifit (the benifit is often perceived to be much greater than emperical studies of real-world coding errors seem to confirm). The main problem that many static-typing fans seem to have is a lack of exposure to the other way of doing things--and enough experience to allow themselves the freedom to break old habits/patterns to actually see the power of dynamic typing.
Parent
Re:Dynamic typing (Score:3, Insightful)
Fundamentally, what you perceive as "power" or "expressibility" in a dynamically typed language is due to lack of structure. For example, in Smalltalk one can add a new method onto Object and then one can call this method on any instance of any type. This means you can solve some requirements in such a dynamically typed language in a very small amount of code, by tweaking ho
Don't confuse dynamic with weak typing (Score:5, Informative)
Dynamically typed language like Python or Ruby are also strongly typed. This means that the language absolutely *prevents* you from accessing an object incorrectly (breaking type safety).
C on the other hand is statically typed, but also weakly typed....the exact opposite!
C++ and Java are also in the same camp--static and weak; although both are much much closer to being strongly typed than C ever was. Although you can argue that Java is static/strong except for some low-level exceptions; or that C++ is partly dynamic (with template meta-programming)
Just for completeness, assembly is most always dynamically/weak; and Haskell is static/strong.
BTW it is the weakly-typed behavior of C (casts, void pointers, array bound checking, etc) that causes probably 95% of all type-error bugs. In fact this falacy that dynamically typed means the same as weakly typed is probably the primary reason that so many people seem opposed to dynamic typing. Dynamic != Weak.
Parent
Re:Dynamic typing (Score:5, Insightful)
Fact: Nothing is free.
Everyone will agree with that in principle, but few people have internalized it.
Static typing is not free. It makes you jump through hoops to type correct code. When you need to change a type, it's even more difficult, especially when it's not something you can search and replace. When changing requirements require you to refactor out some interface, this costs yet more.
The great failure in this debate between static typing people and dynamic typing ethusiasts largely arises from the fact that static typing people can only see the benefits of static typing, and only see the costs of dynamic typing. You particularly made reference to your own inablitity to see the benefits in your post.
You can't complete the debate until you admit to yourself that there are costs to static typing, and benefits to dynamic typing. Only then can you intelligently weigh the costs and benefits of each approach.
I think dynamic typing wins in the vast majority of cases not because "static typing has no advantages", but because static typing charges you through the nose for very, very dubious benefits. Yes, static type correctness catches bugs. But what kind of bugs does it catch? Type bugs. All in all, as someone working in dynamically typed languages exclusively for years now, that's just not the kind of bug I deal with very often. I have logic bugs, architecture bugs, library bugs (bleh! and no these aren't type bugs), comprehension bugs, specification bugs, but I just don't run into type bugs that often. Thus, "paying through the nose" to avoid this particular type of bug is not a compelling bargain.
You're almost always better off taking the development-speed gains of a dynamically-typed language, and learning the discipline to write good tests (which, incidentally, tend to be easier in those languages). Static type correctness has very little overlap with program correctness. (Neither is even a subset of one another; it's perfectly possible to have a completely correct program that does not meet some definition of "static type correctness".) (Elaboration by somebody else [mindview.net].)
There are rare calls for static type languages, where it is so important not to make any type errors, ever, that's it's worth the pain of using them. But it's pretty rare for most programmers. (Of course there are programmers who deal in that exclusively.)
One of the things that could conceivably tip the balance back in favor of static type correctness is if static type correctness becomes more cheap, perhaps with such things like better type inference. But few things are worth the unbelievably staggering price you pay in Java for static type correctness. If you've never used a dynamic language for long enough to see the benefits, you have no idea just how much you are paying.
Until someone shows me that all the code that I've written in dynamic languages that have served tens or hundreds of thousands of people are somehow riddled with type bugs that have somehow failed to cause my code to come crashing down, I'm going to continue to use dynamically-typed languages. The predictions of doom if you let go of static typing have so far shown themselves to just be fear-mongering, quite a lot of it (as far as I can tell) from people who learned in school that static typing was important and have never even tried anything else.
Parent
Re:Dynamic typing (Score:4, Insightful)
Well, as they say, "your mileage may vary".
From my development perspective, static typing isn't a cost, it's a dividend.
Code with explicit typing, to me, is MORE readable, more clear, and easier to deal with, because type expectations are spelled out explicitly; I *can't* avoid specifying them, because the language won't let me. Maybe you find it to be annoying, irrelevant dreck that drowns out the meat of the program, but for me, types are inextricably part of the meat -- removing them makes me wonder, "what are the expectations for this again? I hope someone commented it properly..." (And yes, I've done enough work in dynamic languages to have valid opinion of both sides.)
You're almost always better off taking the development-speed gains of a dynamically-typed language, and learning the discipline to write good tests
Yeah, yeah, yeah, I've heard this argument. I happen to agree that improved testing is a good thing, and that testing frameworks tend to be harder than necessary in most current static-typed languages. But IMHO this argument is rather like saying that seat belts are unnecessary if you have air bags (or vice versa); I'll take *both*, thanks.
Until someone shows me that all the code that I've written in dynamic languages that have served tens or hundreds of thousands of people are somehow riddled with type bugs
Whoa, slow down, no one's saying that dynamic languages are impossible to write proper code in. My assertion is that static typing is a tool to help programmer's avoid dumb mistakes, and to make the meaning of the code more clear. Can I get by without this tool? Yeah. But I don't see a good reason to, in general.
Parent
Re:Dynamic typing (Score:5, Insightful)
// Proto language dynamic typed
// This function trims a string from the 2nd param
FUNCTION trimString(a, b)
IF typeOf a <> "String" OR TypeOf b <> "Number"
// er, not sure what I should do here.
// Maybe the caller passed the wrong params OR
// maybe I was passed the wrong number of params OR
// maybe I was passed NO params
// I "guess" that maybe I cuold throw an error OR
// maybe I should just pop up a message box OR
// Is this a web application? If it is I really can pop a message box
// I "guess" that really I should just throw an ugly runtime error
// at the user even though this realy should be a "compile" time error.
throw new WTFError()
ENDIF
// Code goes here....
RETURN
In other words. It's *impossible* to write any kind of generic code without having to deal with these kinds of runtime issues. Much better code:
// Proto language static typed
// This function trims a string from the 2nd param
String FUNCTION trimString(String a, Number b)
RETURN
Parent
Re:Dynamic typing (Score:4, Interesting)
That sounds more an example of weak dynamic typing, rather than strong dynamic typing, such as in Python or Ruby.
I'm a Java programmer professionally, so I use static typing all the time. However, I also doubt it's that beneficial. Static typing puts a limit on what you can do with a language. In an object orientated programming, it limits the OO model by having a solid distinction between classes and objects; classes are defined at compile time, objects at runtime. In a language such as Python or Ruby, classes are objects, so there is no such distinction. This in turn gives the programmer access to greater layers of abstraction, which can often be a very good thing.
Parent
Re:Dynamic typing (Score:3, Insightful)
Re:Dynamic typing (Score:3, Informative)
What "dynamic typing" lets you do is forget about data types.
Then, code can be restructured to REDUCE the amount of code that is necessary. Sort of what the C++ template system is supposed to do.
Source code reduction is a very good thing.
With OOP programming, the idea is that an "object" encapsulates "dynamic type" -- not by type, but by interface. Generally, it is preferred to be able to inspect the possible behaviour at run-time (C++ RTTI).
This means that generic code can be written, that separates out th
My first experience with C# (Score:3, Interesting)
I program Java. Recently had to do a C# project.
My first thought - Hey! This is a whole lot like Java. Only took me a couple of hours to learn the syntax differences. I'm off and running!
Two hours later I hated it. If you'd like to know why, allow me to offer you the following observation/puzzle.
In C#/.NET, create a form. Put a text box on it, and a button. Have the button create a thread. Have the thread write "Hello world" in the text box.
Because I'm feeling generous, here is the Java code
Re:java growing old.... (Score:4, Insightful)
"Java is an advertising name"????
FFS, this is typical anti Java FUD. You don't go from new to used by IBM, Apple, Google, eBay, most fortune 500 companies in the world by advertising. People like IBM and Google have actual engineers -you know, people with brains. The kind of people who probably even try technologies before presuming to pass judgement on them.
Moron.
Parent