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.
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.
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.
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.
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.
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.
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.
"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.
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.
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)
65 comments
[ 6.7 ms ] story [ 126 ms ] threadhttp://xkcd.com/1397/
Apparently Randall has spent some time in this area before, Lisp is the lightsaber
http://xkcd.com/297/
Smaller Lisps, like Scheme, would be a barrel of generic Lego blocks.
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.
[1] http://www.garandgear.com/m1-thumb
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.
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.
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.
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.
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.
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.
Maybe every once in a while, when you load it just so, the trigger vanishes.
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.
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.
JavaScript is more like a kitchen knife, everyone has to use one even if is far from the best.
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.
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?
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.
[1] https://www.youtube.com/watch?feature=player_detailpage&v=hH...
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.
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)
[0] http://blog.codinghorror.com/the-php-singularity/