Earlier quoted context omitted.
I'm productive in Haskell and I don't know category theory. I didn't "learn" monads specifically, I used them in my projects and gained an intuition for monads followed by memorizing the 3 monad laws.
What distinction are you making between "learning monads" and "gaining an intuition for monads and memorizing the 3 monad laws"?
Learning Curves for Different Programming Languages
171–180 of 221 posts
Re: Learning Curves for Different Programming Languages
#172Re: Learning Curves for Different Programming Languages
#173Earlier quoted context omitted.
PHP is full of problems that lead directly to security vulnerabilities if you aren't constantly aware of them and very careful when writing your code. So when someone who doesn't know those problems (most people) "hacks together" something that "just works", it is almost always providing a backdoor into that server. Once you do learn a little, you find that every scripting language is just as easy to work with as PHP…
Does Perl, Python or Ruby have built-in automatic escaping and sanitization? I would not call PHP less safe than any of these languages. On top of that all three of those languages require additional setup. (Especially Ruby with RoR shudder )
No, of course not. That's very much the point. PHP's broken attempt at that created security holes.
>On top of that all three of those languages require additional setup
No they don't. It is just that someone else has already done the setup for you with PHP at most cheapo hosting companies. Installing python is no harder than installing PHP.
>(Especially Ruby with RoR shudder)
You are comparing a framework to a language. Rails is no harder to setup than any of the PHP frameworks like zend or symfony.
Re: Learning Curves for Different Programming Languages
#174Re: Learning Curves for Different Programming Languages
#175Earlier quoted context omitted.
I think your parent is referring to the fact that the Productivity graphed for PHP is the worst of all the languages, even at t=0 (except Haskell, which is shown as starting out with 0 productivity for a while.) I also strongly disagreed with that for the same reason your parent comment did. The self-assessment bar is funny, but hte blue (productivity) graph needs to be way higher.
There's no absolute scale, so you can't make comparisons between the graphs. The only conclusions you can make from the PHP scale is 1) that (according to the author) PHP developers think they are a lot more productive than they actually are and 2) experience doesn't increase productivity substantially in PHP.
Re: Learning Curves for Different Programming Languages
#176Re: Learning Curves for Different Programming Languages
#177Earlier quoted context omitted.
I'll take another tack and suggest that productivity today is more a function of what libraries might be available rather than language choice. A language like Python has a massive number of really good libraries spanning a range of disciplines. Is it the "best" language (whatever that means)? Don't know. Don't care. You can get the job done and the ecosystem is huge. I am not comparing Python to Haskell or anything…
The graphs are not productivity vs language choice. They are productivity vs experience in a given language. In languages with strong libraries, I'd expect a diminished benefit from experience. 10 years python experience doesn't make you much more productive in standing up a django application vs someone with 1 year of experience. Thus, the curve for python might very well be quite flat (since you start fairly high t…
Re: Learning Curves for Different Programming Languages
#178Earlier quoted context omitted.
Does Perl, Python or Ruby have built-in automatic escaping and sanitization? I would not call PHP less safe than any of these languages. On top of that all three of those languages require additional setup. (Especially Ruby with RoR shudder )
Actually yes - perl has a tainted mode (#!/usr/bin/perl -t) that force you to sanitize every input from the outside world. It does not do the work for you because it is agnostic to semantics (escaping for shell is different than escaping for SQL for example) but at least make you think about the problem.
Re: Learning Curves for Different Programming Languages
#179Earlier quoted context omitted.
There's no absolute scale, so you can't make comparisons between the graphs. The only conclusions you can make from the PHP scale is 1) that (according to the author) PHP developers think they are a lot more productive than they actually are and 2) experience doesn't increase productivity substantially in PHP.
what makes you think the graphs aren't meant to be read on the same scale? By that reading the PHP productivity line could be 100x higher than the next-best language listed, but with self-assessment being 1000x higher than the next-best language listed. That is not a very sensible reading.
Lack of labeled axes.
Without labeled axes there is no sensible reading between graphs.
Re: Learning Curves for Different Programming Languages
#180Earlier quoted context omitted.
Does Perl, Python or Ruby have built-in automatic escaping and sanitization? I would not call PHP less safe than any of these languages. On top of that all three of those languages require additional setup. (Especially Ruby with RoR shudder )
>Does Perl, Python or Ruby have built-in automatic escaping and sanitization? No, of course not. That's very much the point. PHP's broken attempt at that created security holes. >On top of that all three of those languages require additional setup No they don't. It is just that someone else has already done the setup for you with PHP at most cheapo hosting companies. Installing python is no harder than installing PHP…
You are right, there are a bunch of hosting company providing 0-config PHP, but setting it up in any distro is also never more than one command away, unlike the other languages mentioned.
Regarding Ruby and RoR, I can't even find a tutorial on how to run Ruby under FastCGI, and RoR appears to be the de facto way to run Ruby websites, so if having a framework is required to run any non-trivial Ruby website, then it has to go into the "hard to configure" part of the argument regardless of semantics.