I'm doing a lot of python lately...but yesterday I compared one of my python lucene search programs with the java equivalent...and the Java one was considerably faster. Also, the fact that I could write the same program with Scala is enticing.
I feel like I am being drawn back to the JVM after pushing it away for so long. It really is an impressive system.
I wouldn't expect it ever. Rapid development not rapid execution. However, I didn't expect the difference in speed to be so large, considering it is calling into the Java lucene.
This might be overkill, but would it be possible to setup a mini-Java Lucene process to handle the indexing and queries, and talk to your Python process over a socket?
Like I said, overkill, but it could be worth it.
I say this being in the same boat: coming from the JVM to Python and looking back at some of the things I'm missing.
The problem with using the JVM is that it has been designed around the Java language. This doesn't make it a great fit for languages that don't use Java's object model, or that require functionality like tail call optimisation. It's possible to work around these problems, but for implementing languages, it's less flexible than something like LLVM
The advantage with using the JVM is that you get a lot of libraries for free, which may be worth coping with a Java-centric design.
True, but it's hugely significant as a signal that "the JVM isn't just for Java". Languages like Ruby and Python have large mindshare right now, so InvokeDynamic floated to the top.
Clojure will have it's turn. Things like tail recursion are already on the radar. Check out the Da Vinci Machine project for details.
I'll wait for a bit, we're kind of scared of the bleeding edge :)
As soon as it hits the mainstream and people have been testing the hell out of it we'll surely follow though. Second best is good enough for production.
Incidentally, that other 'dead' language (Latin) is still very much in use, precisely because it is dead. Being 'dead' (as in no longer under aggressive development) can actually be an advantage. Plenty of branches of industry prefer stability over sexiness any day.
I think that's true in some instances. But if you want to keep the Latin analogy going, you have to acknowledge that Latin stuck around because an entrenched organization continued to use it long after it had lost vulgar relevance. And Latin's high status fooled the intellectuals of the day into thinking that it was the pure, holy tongue, and had undue and sometimes destructive influences on the development of other languages. This happened precisely because people tried to apply the grammatical patterns of Latin to languages that were structurally different.
I'm not saying that Java (or Latin, for that matter) doesn't have a place in the future, but I just hope that it doesn't continue to have undue influence on the evolution of programming language and methodologies simply because it is a revered institution.
"but I just hope that it doesn't continue to have undue influence on the evolution of programming language and methodologies simply because it is a revered institution."
I would tweak that to "... programming language and methodologies accepted by the mainstream...". Java is already not stopping many very different streams of development from existing at all, but the question is whether anything that isn't Algol-derived can be the next big mainstream language. That syntax is really starting to creak under the load of all the stuff that even C# loads onto it, and the Next Big Enterprise Language really needs to not be that way. (I make no claims as to what it should actually be, though.)
Good point. I don't have a good idea either what the Next Big Enterprise Language should be, but I'll bet that it will not be what it should be. I think an "Enterprise Language" is bound to be disappointing because it's a solution to an ugly problem: "How do we make developers interchangeable?"
I guess the rest of us will just continue along doing what we do with whatever tool we need for the job.
Okay, that analogy makes sense. As a technical and taxonomic language, yeah something really stable like Latin or Greek (also used a lot in medicine) is probably best. And yes, I was referring to the Church. Fortunately, Sun doesn't have that kind of influence or power, even if developers as a group can be quite dogmatic.
I wouldn't say that the medical profession uses as a "dead" language that is "no longer under active development". In fact, they invent new words in it all the time.
What I find quite unfair is how everyone compares "lines-of-code" for a Java app vs PHP/Python/Ruby.
IMO there's a big difference: A Java IDE like Eclipse probably writes half of the lines of source code for me - the tedious bits that are simply structure/sugar. PHP/Python guys write every single one in vim/e-macs. Perhaps "unnecessary boiler-plate" Java code gets in the way, but yet my IDE hides most of that for me automatically. And most importantly, when I do want to edit that getter - it's right there in my source code for me already.
I believe IDEs and compilers should become more powerful, rather than the languages, because you often want to drop down a level of abstraction to improve things.
If the programmer does not need to write the code, it has no business being in the source code. Nobody wants to find all their slightly-modified boilerplate and modify it because the boilerplate generator had a bug. Sane programmers will fix the bug in one place, upgrade the library, and be done with it.
The less code to maintain, the better. The less repeated code, the better. This is what many programmers strive for, and why they eschew "my IDE will write it" in favor of more powerful abstractions.
Relying on your IDE is like using a shopping cart to carry around a portable generator, tower CPU, and CRT monitor instead of carrying a laptop. It's pretty easy to push around that shopping cart, right, so why bother with a laptop? The laptop doesn't have a 21" screen, after all, so it seems like a total waste of money compared to the shopping-cart-and-50"-TV.
eschew "my IDE will write it" in favor of more powerful abstractions
But he specifically said that this breaks down when you need to pierce the abstraction and he's right. You can often accomplish the same thing by doing the "non-abstracted" code in a lower level language and linking to it, but that's not always convenient or safe.
I'm of two minds on this topic. I like the "smarts" of a good IDE that hides stuff that I don't care about. But at the same time, I'm afraid that if it breaks (bug in the IDE or library), I don't have the ability to find the broken part and fix it or work around the problem. This was exactly how I felt when I started playing with WCF.
If you have to pierce abstraction by stripping away the IDE, you've got an issue with the design of the language.
Take python: I don't have to write getters and setters, but if I need to tinker around "inside" one, I simply write a function and decorate it with @property. But that code is only present if I need to create an exception to the general case, rather than having everything, including the common cases, present in source and hidden by the IDE.
Python is not even the best example here, in Common Lisp and Perl (and probably lots of other languages) provide even better abstractions. If you want to modify the behavior of one accessor, you can modify it with method modifiers. If you want to create a new class of accessor-generation behavior, you can write a new metaclass that works exactly the way you want. (And of course, you can write your own "defclass" macro that always uses your own metaclass, if you desire.)
In Perl, we can even compose meta-roles into metaclasses; meaning that even tiny changes can be made easily reusable.
This is generally preferable to editing code in an IDE.
One thing that I think is often missed in the discussion around LOC and features like closures is that, while sometimes denser code is terser, often it's more expressive. For example, the code:
List<String> userNames = new ArrayList<String>();
for(User user : users) {
userNames.add(user.getName());
}
is not just more verbose but also reveals the programmers intentions less than something like:
var userNames = userList.map(\u -> u.Name)
Java programs often devolve into a lot of for loops, which all kind of look the same regardless of what you're doing, and you have to read pretty closely. It's nice to replace a bunch of loops with explicit methods like "map" or "find" or "reduce" or "each" or other things that explicitly declare the intent of the programmer.
I write a lot of Java, and we also have an in-house Java-like language built on the JVM (that we're working to open source), and we added closures to it in order to gain those sorts of benefits. Even though IDEA or Eclipse can write my for loops for me, it can't read them for me.
There's no technical reason why you can't have a statically-typed language with excellent tools that isn't unnecessarily verbose: all you really need to add are type inference, closures/first-class functions, and properties, and a little bit of metaprogrammability (instead of code generation) is also both feasible and helpful.
In theory, why can't it read the for-loop for you? Why not summarize the above as eg:
List<String> userNames = users[@name]
Just showing the line in a different colour could mean it's "summarized". Clicking on it could reveal the complete loop and allow you to modify it. But common idioms such as map/find/reduce/each can be summarized.
Def agree that Java is less readable, and there will always be shorter ways of expressing things (such as a for-loop). But I do think an IDE does, and could do a lot more to help: hide the generated boiler-plate code from me, show me a visual map of the source structure so I can jump to places quickly, and perhaps even summarize certain code blocks for readability (eg why not summarize a standard MAP for-loop, so that it becomes editable if I click on the summary?)
There are many other things that an IDE could do beyond validating my code, function arguments, giving me hints, auto-completing variable names, code-blocks, etc. All those things make Java & C# much more productive than people think. The worst bit is actually dealing with libraries, whereas with Python/PHP much more stuff is built-in.
As someone who (fortunately) doesn't have to write a lot of Java any more, but does have to read and understand Java source code upon occasion I have to say that this is a totally bogus attitude - when I read Java code I seem to spend a great deal of time playing "hunt the code that actually does something".
I accept that things like Eclipse are essential to write Java but I still have to read vastly more code.
I'd much rather use Ruby (with Rails) than Java, and for future learning, I'm interested in Scala. Obviously, the JVM figures heavily into all this, though that isn't the same thing as Java.
But still, GWT, Guice and Grails are pretty active and relevant projects. Even if you don't plan to use them (I don't), it's pretty hard to see a language as "dead" when the community still draws this level of talent and innovation.
This is something I keep bringing up with my fellow PHP developers. I like the simplicity of PHP in some respects, however the syntax and various frameworks seem to be constantly evolving around my projects. I have friends who are constantly having to adjust their code to comply with the newest release of CakePHP. I find some syntax (pseudo-)rules and best practices in PHP have changed enough to make it a constant struggle just to keep on top of these changes along with trying to improve my abilities in other areas. I'm all for new features but I'm beginning to grow weary of the time spent staying on top of trendy languages (PHP vs Python or Rails, SVN vs git). I would much rather spend this time learning better security practices along with design and architecture. I would never state that change is bad, I'm merely stating what I now see as a drawback of these constantly evolving languages.
... I really hope I'm not becoming one of those really old dinosaurs who refuse to learn anything new. ;)
Yes, only short of touting the new 'best' programming language. Thanks for the demonstration. Name a programming language without horrid drawbacks, I dare you.
Do you know anything other than PHP? If you don't, you are in a bad place. It almost doesn't matter what else you pick up, stop looking for a language without "horrid drawbacks" and pick something up. Anything. Even Java, and it pains me to say that.
By the way, specifically PHP isn't important here; the question is really "Do you only know one language?"
Heh, it does not pain me at all to say that Java is better than PHP! PHP, in turn, is better than Fortran, Cobol and the original Basic, and I guess that's about it.
Yes, I've done professional work in Perl, C#, and Java. These silly stereotypes need to end. Think what you will about PHP, it's not as horrid (now) as most people like to assume, it's mostly just misused. Oh wait, it's trendy to hate on PHP now, which is really the problem I'm was originally addressing. People want to jump to another language as soon as they've worked with one long enough to truly become aware of it's handicaps (or even be able to parrot other people's gripes) and then repeat the cycle. Even as much as I (regretfully) look down on ASP/.NET, if that's what you want to be good at, go for it. I'm sure it's plenty capable if used correctly.
All-in-all it's plenty fine when I see people writing off PHP devs, in my case, it's mutual. I don't write off ASP devs just because I think ASP is restrictive to my style of programming. There are "better" tools for the job, but often the claim that something is the wrong tool is rooted in... well.. yeah, I'll stop there.
You missed my point. The word "if" was not accidental. If you hadn't worked in any other languages, then you needed to try something else for perspective immediately. I went out of my way to point out this had nothing to do with PHP particularly.
It's funny how languages shape the community around it. I feel like I spend more time these days debugging Zend, PHPUnit and Propel than I do debugging my team's code. I am continually astounded at how bad PHP can be.
I feel like I am being drawn back to the JVM after pushing it away for so long. It really is an impressive system.