Suggested alternative for Java, because making fun of NullPointerExceptions is too easy: "Java is a belt fed 240G automatic weapon that tries hard to avoid gun accidents: each round has to be individually authorized by ticking off a detailed questionnaire. By the time you get to actually shoot, someone may have already beaten you to death with a stick."
Scala would certainly have to build on that: "Scala is a variant of the 240G Java that tries to work around the problem by encoding pre-answered questionnaires directly into various types of ammunition. Unfortunately, the gun can detect lies and refuses operation when some of those answers do not match the actual situation."
I would have liked to see HTML and CSS just because they aren't really programming languages, but are referred to as "coding."
HTML = construction paper, safety scissors, and glue, while you wear a dirty scuba mask.
CSS = A gluestick, glitter, and pipe cleaners, while you wear mittens.
Python is the best at quite a few things these days, particularly if you need to accommodate projects (or developers) that require top-caliber tools for getting work done in several different problem areas.
The whole 2 vs. 3 is, if anything, an embarrassing interlude in getting to the fact that it's currently both amazing for beginners and one of the most versatile professional languages. Where it's not the best, it's often fighting "mainly good for this one problem area" tools and languages to a draw...while still being great for dozens of other problem areas.
Cracks about "really easy to use orbital death cannons being handed out to anyone who asks" aside - your best comparison is probably a trench knife. Simple, elegant, gets the job done whatever that job happens to be.
You need to build in some hyperbole. Python is a scripting language, and even amongst scripting languages, not a particularly fast one. So ...
Python, as a weapon, is like a government grant on which you have written "shoot a gun". You just tell it what to do and it somehow happens ...
using 500x the resources any sane human being would have used. If you examine what it did to launch a bullet found it built and operated an international airport including 5 passenger terminals and then used a very elaborate looking runway to fire the bullet. The amount of empty space between the buildings looks very impressive and significant.
The only reason Python should ever be problematically slow is if you're writing bad Python. (Well, almost ever.)
What you have to understand is that pythonic Python is largely a matter of invoking C libraries, and that Python only really runs at "interpreted" speed the first time you invoke the code.
It's no more slow than a shell script which serves to invoke grep and sed would be, because you're relying on the underlying optimized tools to execute the bits that would actually benefit from optimization. The microseconds it takes to switch from one to the other are almost never going to be a meaningful slice of the total execution time.
Instead of picking over the mostly insignificant delays that are left, Python has said "hey, let's optimize for readability & developer sanity instead — things that actually affect project outcomes." And then you go knock off 10 different issues you wouldn't have had time for, and you don't stab yourself in the eye with a fork while trying to make sense of the old code.
> What you have to understand is that pythonic Python is largely a matter of invoking C libraries, and that Python only really runs at "interpreted" speed the first time you invoke the code.
I do a bit of machine learning for work every now and then. I don't agree. Python is both really popular for machine learning and way too slow to let production stuff run in it.
I routinely do machine learning and computer vision, and have used a number of languages for them.
The main issue, irrespective of language, is that the implementation of your final model is often a distinct step from the last output of your experimental tools. If you just take what it gives you and try to deploy that, it will often provide extremely suboptimal performance.
The methods for implementing your final model could involve raw Python, NumPy, the Python wrapper for an external library, writing and consuming custom C libs...it depends on the complexity of the hyperplanes.
But e.g. scikit-learn already wraps libsvm and liblinear. If your SVM (etc.) is slow, it's very unlikely to be because you used Python.
If you're e.g. trying to do Facebook-level heavy lifting, your experiences may vary. But again, that would be a challenge for any tools. The solution is to use sampling, parallelism, etc. - and to implement and optimize your final model as a separate step from designing it.
The M1 was known for "M1 thumb" [1] which typically involved catching your thumb between the bolt and the back of the chamber if you weren't especially cautious. I'm not sure if the author considered this, but it seemed a fitting choice for C. It works and works well, but it can bite you when you least expect it.
Although the source I've linked (below) claims it's impossible to encounter M1-thumb while loading, I have heard from reliable sources who've fired heavily abused Garands in ROTC (and hence saw all manner of abuse--besides WWII) that letting go of the bolt after forcing the clip into the firearm without removing your thumb will correctly strip the first round--and eat your thumb.
Edit: I do have to wonder if the experiences I was related some years ago was from the individual(s) in question loading a single round rather than the full clip.
As a former M1 Garand owner (replaced it with a lighter weapon due to my RSI weakened arms), your link is to my knowledge correct. While I avoided the screw cases where the bolt was not properly locked back, I can attest to other examples, most especially loading a clip finishing with loading the top round. The cartridge is indeed where your thumb otherwise would be, your thumb is essentially pushed out the way, I'm pretty sure it's very hard to get hurt doing this. Or look at it this way, it would have been very sub-par to have a real problem there when soldiers were loading clips while their minds were preoccupied with combat, and back then in the '30s the Army really really cared about the quality of our small arms.
The #1 screw case I knew about pertained to closing the bolt without loading the rifle, there is danger since it requires reaching past the bolt down to the follower that is locking it back. The trick is to hold your right hand in a rigid way so that while your thumb is depressing the follower, the bottom of your hand is holding the operating rod handle, keeping the bolt from flying forward. Depress the follower, then lift your entire hand as a unit up and out. Works like a charm.
Overall I rate the Garand as having better ergonomics than our following two service rifles, the M14 and M16/M4, it's for example very smooth in profile, very little to get caught while you're carrying it (that insight from someone who used it in Korea). If I had one today, and only that rifle, I would not consider myself to be under-equipped.
Hmmm, one other screw case it has in common with all weapons with the common pattern of an operating handle that is linked to the bolt, i.e. reciprocates with it, is that if you have a hang-fire---you press the trigger and the weapon goes click, but unlike the Java example ^_^ there is a round in the chamber---you'd best pull the handle back with your smaller fingers, palm upwards and under the bolt. Because if the round fires while you're doing this, if your palm is reversed and you're using your forefinger and on without taking precautions, the handle will smash into your thumb or the web of you hand between it and your palm. That'll do some serious damage....
C is not quite as good as the Garand is, although I'm not sure what I'd use as an alternative.
Perl is a molotov cocktail, it was probably useful once, but few people use it now.
If anything, Molotov cocktails are some of the easiest weapons to improvise and are used quite often, particularly by underpowered guerrilla warriors. So if we're to take it literally, this would imply that Perl is a limited efficacy hack that a lot of people use.
If you use it for new stuff with up to date frameworks (e.g. symfony) it's not that bad, really. Since 5.4 it's getting a lot better.
If you're stuck with some old version and legacy codebase it's a problem unrelated to the language itself.
As a PHP developer, I think you are right. In last few years PHP changed a lot! Ofcourse like every tool it's sometimes used wrong way, thats why people complain.
Te biggest problem with PHP is just the mountains of old legacy code and what still passes for "good". The new beta of Wordpress for instance is still largely procedural and untestable, yet powers something like 60% of the web.
Well, to be fair, the flipside to that are some of these new PHP frameworks that attempt to include every pattern known to man and are buried under mountains of worthless abstractions.
I'd classify PHP as a Swiss Army Knife. Multi-purpose tool that's decent at a little bit of everything but for long-term and specific operations you should probably replace with a better-suited tool.
C++, nunchucks? Ha, fair enough. But I'll continue to think of Go as my legion of tiny gophers under command, scurrying into battle or working relentlessly like Doozers.
It would be more accurate to say, "C++ is a set of nunchuks, powerful and impressive when wielded but takes many years of pain to master and often you probably wish you were using something else, because of the frequent accidental firing of the hidden pistols in the grips."
"Perl is a molotov cocktail, it was probably useful once, but few people use it now."
Yikes! I've worked for big tech companies you've heard of and Perl is all over the place and used in real production projects. We also regularly choose it for new projects.
Ok I know this one will be tough to keep rational, but this is an honest question - we've got Python and (especially) Ruby now, whats the Perl USP in your case?
Choosing a language for a project rarely comes down to researching the languages that may best deal with the problem. More often than not from my experience, it’s what the first engineer(s) on the project thought would be fun (annoyingly often in the case of using new languages in production), were most-familiar in, or the company is most familiar with, or because some library they need to use is only available in X language and it would take too long to do the project and implement the library in their “normal” language.
Perl, Python, and Ruby are all pretty competent and on the same level. Given that Perl is chosen as a language the question isn’t “Justify the use of Perl to the exclusion of Python and Ruby.” It’s “What can Python or Ruby do that Perl can’t?”
Some common arguments between Python and Perl can be found at http://coosoft.wordpress.com/2013/02/24/the-perl-vs-python-d... (I would add the author should have expanded on Object Oriented in Perl more. While native OO in Perl is exceptionally basic, third party OO frameworks for the language exist such as Moose and Moo complete with introspection, roles, type constraint, triggers, attributes, etc, etc).
Perl is a powerful modern language, actively developed by a committed community[1]. We’re just generally too busy doing things to blog about all the awesome stuff as much, so people’s perceptions of the language are often stuck in 1998.
Their OO is terrible. Especially ruby's (single inheritance and a half-ass mixin system ... yeah, right).
Perl5's built-in OO is even more terrible, but exposed enough guts for Moo/Moose to be written, which is far, far superior.
Note that there's a MooseX rubygem and an Elk python package, because apparently there are people actively using ruby and python who also miss sensible OO :)
(I can elaborate on what I find superior but you might find it more instructive to see what people have ported than what I miss)
I personally also use Python regularly and am very comfortable with it, but we often choose Perl because of the developer experience in it.
Perl has a reputation for being difficult to learn, and it does have a bit of a high learning curve compared to Python. However, once you learn Perl, you'll find it's a rather wonderful, expressive. and powerful language.
Is it "better" than Python or Ruby? No, just a different solution to many of the same problems. If we're being honest, most anything you can do in Ruby or Python can also be done in Perl.
My experience is that most engineers and devs over the age of ~30 know Perl front and back (if they script), so it's a natural choice. Fewer of these people (in my experience) are as familiar with Python/Ruby.
Perl continues to evolve and the Perl we wrote in 1998 isn't the same as the "Modern Perl" we write in 2014. There are great modern Perl web frameworks (Dancer, Mojolicious), real object-orientation via Moose, powerful exception handling via Try::Tiny, and a history of excellent database support.
Maybe it's a matchlock or a blunderbuss, then? It was here first, it's still a brutally effective way to get the job done, but it takes longer to make each shot than with a more modern weapon, and sometimes it will kill you.
C is like a frag grenade, dipped in glue. It is strangely enticing to use it. It was more popular in the past but for some reason most of those guys aren't around anymore.
C++ is like a nuclear weapon, that automatically disables any means you have of getting clear of the blast radius when you activate it.
Perl is like a leaky vat of nitroglycerin. It can be used as a weapon, but one wrong character and it kills you, most of your family, and half the neighborhood.
Java is a 500000 pound KalashnikovFactoryDesignerFactoryProducerSingleton "weapon". I hear there's actually a way to fire it, using 50000 programmers, however as 90% of those programmers commit suicide on any given friday nobody has ever seen it successfully fired. It helped quite a few large company's IT departments grow to impressive sizes. You know, on thursdays.
Scala is a way to fire the KalashnikovFactoryDesignerFactoryProducerSingleton with only 500 programmers, provided they have a deep working knowledge of ancient Egyptian algebra.
Javascript is like a machine gun with two barrels pointed into two different directions. You can aim it at someone, but when you fire it, both the target and some poor bystander you liked will go down.
Go is like C, except the glue on the grenade has been replaced by handcuffs, there's a million grenades chained to you and you're required to cite the error checking oath which goes "if I check my errors I will not die". What happens next can only be described as "humor".
Bash is a row of unlabelled black buttons, which in order mean "coffee", "milk", "sugar", "lemonade", "global thermonuclear war", "diet lemonade" and "tea". I am not sure about that order. Neither is anyone else. Great lemonade though, you should try it.
Python is the government's version of a normal pistol. If you aim it at the person in front of you it will proceed to start an Apollo program, design a moon rocket, put a bullet in an orbit that will take it around the moon and then into it's target, which of course has long since killed you, taken your wallet, and left the scene.
Scala would certainly have to build on that: "Scala is a variant of the 240G Java that tries to work around the problem by encoding pre-answered questionnaires directly into various types of ammunition. Unfortunately, the gun can detect lies and refuses operation when some of those answers do not match the actual situation."