Yeah, but Ruby?

Post #350,734 by malraux 11/15/11 11:39:08 PM Reply	Yeah, but Ruby? It's slower than Perl, Python, Java, and just about everything else. All of the above have ZeroMQ clients as well. Regards, -scott Welcome to Rivendell, Mr. Anderson.
Post #350,736 by boxley 11/16/11 12:33:46 AM Reply	slow vs faster dev time? Any opinions expressed by me are mine alone, posted from my home computer, on my own time as a free American and do not reflect the opinions of any person or company that I have had professional relations with in the past 55 years. meep
Post #350,752 by folkert 11/16/11 9:18:30 AM Reply	Does it really matter? Doing it faster in dev time... Perl has CPAN, its ginormous. If you typically want something its there. Even if you don't like what is there, you can look at it and fix it up or make a new module. Feck man, Perl is so complete, I have yet to look for something that was there at least in a usable state. Perl is also very fast. So fast it makes my head spin on fast new hardware. Heck on 6 year old hardware its fast. Even on 500MHz P3 hardware its fast. Dev time is far out-trumped by production speed anytime. Perl is scalable and very well known by many people. Yes there are more Java and C# junkies out there... but a good Perl chef can whip something together just as fast and work it.
Post #350,754 by malraux 11/16/11 9:25:30 AM Reply	Nope I would never suggest Perl for anything other than batch processing (with hesitation) or shell scripting. We've got a few hundred thousand lines of it here. Never never never. Well, maybe if you have 4 Bens or Barrys on staff, but in the hands of mere mortals and people who think they are gods it's a swamp. I'm sure Barry will have something to say about this, but Perl is too dangerous in the hands of people who like complexity. Regards, -scott Welcome to Rivendell, Mr. Anderson.
Post #350,810 by crazy 11/17/11 3:14:07 AM Reply	Agreed 90% of teaching a perl programmer is forcing him to read the Tao of Programming and quizzing him on it, and then read the 1st several chapters of the AUP, and quizzing him on it, and really pounding in that other people were going to maintain this code. Some day. Every piece of code has a life, and it may outlive you. Do NOT force the next guy to decode your brain state. I would not allow him to code for about 3 days because he didn't do his homework. Allow is a bit strong, but when I refused to review his code, it sunk in. So anyway, most never got this stuff beat into them, they whipped out some code, it seemed to work, and a new career was born. He's decided to dive into Lisp for a bit and is working in the Eclipse environment. It annoys him when he is doing an exercise that he could just whip out in Perl. I told him to withhold judgment until he got all the fundamentals of the language. Anyone here know Lisp? I sure don't.
Post #350,812 by pwhysall 11/17/11 3:25:14 AM Reply	I with I did know lithp. It thure theemth interethting.
Post #350,814 by malraux 11/17/11 8:55:28 AM Reply	I've done LISP I wouldn't say I know it, however. It's one of those languages that takes a long time to master. I personally don't find it all that compelling versus the cognitive load required. Regards, -scott Welcome to Rivendell, Mr. Anderson.
Post #350,764 by drook 11/16/11 11:26:03 AM Reply	Depends on the industry Dev time is far out-trumped by production speed anytime. In the financial industry, sure. And airline booking ... anything with insanely high transaction volumes. But for the rest of us, where the majority of execution time is handling user interface, dev time is far more valuable. -- Drew
Post #350,753 by malraux 11/16/11 9:21:39 AM Reply	Not in the financial world Here it's about transaction speed, safety (very conservative), and then time to market. Dev time with Python is just as fast as Ruby (better in my opinion). Where are you hearing this from? I'm very curious. Regards, -scott Welcome to Rivendell, Mr. Anderson.
Post #350,744 by S1mon_Jester 11/16/11 7:55:14 AM Reply	I seem to recall complaints about Java being slow at one point.
Post #350,751 by pwhysall 11/16/11 9:17:54 AM Reply	Re: I seem to recall The prodigious throughput of modern hardware has rendered moot many (but not all) of the traditional performance differences between platforms such as Java and those which are natively compiled. Certainly, Java is Fast Enough these days for most things.
Post #350,756 by folkert 11/16/11 9:30:52 AM Reply	Yes but... Perl is SO MUCH faster than Java on equivalent hardware with similar loads. Heck, we use a Java Data Warehouse Reporting tool. It sucks. We have made it into a "Presentation only" tool. We can do the same report data extraction with Perl and Shell on 6 year old hardware in 1/10th the time and passing fully populated short-term/temporary tables to the "tool" to render the "PDF" or "XLS" or what have you, than if the whole thing with was done almost brand new hardware withe the "tool". Yes, its true, if you want faster clustered performance out of Java, just add more cores/processors and memory. But the point is, I can get nearly 90% more work done on older hardware not using Java. No to mention, start-up loading times for Java really blow on new hardware. Worse than the time does for even the BIGGEST Perl programs we have on 6 year old hardware. Its hard to believe that Intel and AMD doesn't praise Oracle (formerly Sun) for making Java such a pig!
Post #350,758 by pwhysall 11/16/11 9:47:24 AM Reply	Re: Yes but... Perl's a maintenance horror. Java, less so. If I save £20K on hardware but burn through an additional £50K in software maintenance (easily done), I'm £30K down; for all but the most performance-critical applications, no one upstairs is going to care that it's OMG FAST!!, they're just going to extract my gonads for overspending. My experience is that, for a bespoke system with (say) a five year lifespan with software maintenance (not just bugfixes, but features and stuff) included, hardware is 10% or thereabouts of the total cost.
Post #350,759 by folkert 11/16/11 10:40:50 AM Reply	We aren't experiencing... Maintenance horrors. Its only because you can't find good Perl coders. Sucks to be you. We write maintainable Perl. Even the stuff 10 years old is still easily maintainable, a bit archaic, but easy to maintain. And you are talking different budgets and types of expenditures. Capital Expenditures are typically horribly hard to push through and justify. If you've got wetware already working... its easy to have them fix it. Though, you don't have good (as in real ones not "think I am") Perl programmers.
Post #350,761 by malraux 11/16/11 10:59:04 AM Reply	You are confusing two things: Java the language vs. poorly written Java programs. Straight out, Java is considerably faster than Perl. For maintenance, with similarly skilled developers, Java is better than Perl. Hell, Python is faster than Perl, and significantly easier to maintain as well. For startup, well, Java isn't meant to be run as a short-run script like Perl. Startup time doesn't matter for anything other than a script that runs in an amount of time similar to startup time, after all. For batch processing, long-running server processes, and other such programs it simply doesn't matter. Incidentally, if you're talking about Pentaho then yes, it really truly sucks. Don't use it. I'll add, however, that general reporting tools are usually slower than custom-built scripts. The former might not need a programmer involved, however, and the latter definitely does. Regards, -scott Welcome to Rivendell, Mr. Anderson.
Post #350,755 by malraux 11/16/11 9:27:51 AM Reply	And they're working on it But again, financial companies are about conservatism and safety. Incidentally, we have some Java code here that runs significantly faster than the exact same code in C++ (parser and expression language execution). Both implementations were written by people I consider to be extremely capable, and both have been tuned within an inch of their lives, but the Java is still faster. Regards, -scott Welcome to Rivendell, Mr. Anderson.
Post #350,757 by folkert 11/16/11 9:31:49 AM Reply	Now that is... Effing unbelievable. But coming from you Scott, on this kind of stuff, is significant!
Post #350,762 by malraux 11/16/11 11:00:24 AM Reply	Re: Now that is... Java optimizes the code that's running. C optimizes the code you're going to run. The difference can be significant. Regards, -scott Welcome to Rivendell, Mr. Anderson.
Post #350,811 by crazy 11/17/11 3:17:22 AM Reply	Damn straight It optimizes with knowledge of data flow history and code path transversal. A few passes of data and it can rewrite your core hot spots. CPUs just got fast enough that this type of optimization is possible in real time and people don't get annoyed by the initial "sluggish" moment while the overhead of the optimizer tanks the system.

Welcome to IWETHEY!