Earlier quoted context omitted.
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.
> what makes you think the graphs aren't meant to be read on the same scale? Lack of labeled axes. Without labeled axes there is no sensible reading between graphs.
Learning Curves for Different Programming Languages
181–190 of 221 posts
Re: Learning Curves for Different Programming Languages
#182Earlier quoted context omitted.
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…
[deleted]
I wasn't referring the the graphs anyway in regards to absolute productivity. Rather, I was referring to the parents claim that the library in python makes you more productive, which may be the case.
Also, "why wouldn't they be"? Whitespace is boring. Maximizing useful space on each graph would require a different scale for each language. Also, productivity in each space is varies widely limiting apples-to-apples comparisons across languages (even within languages this is tricky). There's no question that for some workloads Python is more productive than C++ or Haskell. The discussion is really about what the learning curve for the language is (hence the title).
Re: Learning Curves for Different Programming Languages
#183If all the lines were accurate, would it have been funny at all?
Re: Learning Curves for Different Programming Languages
#184Earlier quoted context omitted.
>I know a lot of people encharmed by it, but no-one productive (i.e. delivering products quickly; it's not the same as solving pure, mathematical problems). Is this actually true, or is it "true in your heart"? Very few people use haskell for solving "pure mathematical problems". People use it for things like developing the fastest microkernel in existence, doing high volume trading, making games, and writing boring…
Links or it didn't happen. I don't imply that nobody uses it for solving practical problems. Just, I made my judgement based on: - friends (I know, it may be biased), - GitHub codes I use (and in general, popularity), - blog posts on Haskell (I encounter mostly language-oriented; less problem-oriented like "let's make a 3d game", "web scraping", "machine learning", "web dev" etc).
Blog posts are heavily skewed towards how to write elegant code or how to use a difficult to understand feature and less toward "build a todo list app" or "build hangman in five hours".
Not that there shouldn't be material like that but it's usually non-existent because the programmers coming to Haskell don't need it but need help using lens, or pipes, or attoparsec at the implementation level.
Haskell is most definitely used for pragmatic industrial applications. You'll see a lot of the ivory tower research being done in Agda or other dependently typed theorem provers.
Research is still done with Haskell but it's definitely geared towards how to improve the language not just for the sake of intellectual masturbation but also for programmers like me that are building valuable companies in tight markets with a lot of resource constraints.
Re: Learning Curves for Different Programming Languages
#185Earlier quoted context omitted.
> what makes you think the graphs aren't meant to be read on the same scale? Lack of labeled axes. Without labeled axes there is no sensible reading between graphs.
[deleted]
Re: Learning Curves for Different Programming Languages
#186Re: Learning Curves for Different Programming Languages
#187For elmers out there, what will a graph of Elm look like?
Re: Learning Curves for Different Programming Languages
#188Earlier quoted context omitted.
Generally speaking, tutorials in those languages recommend using the paramatized versions of the queries rather than string concatenation and manual escaping. The official docs from these more well-designed languages would have copious warnings against attempting to escape user input yourself, rather than having numerous functions baked into the language to help you do just that (e.g. `mysql_escape_string`, `mysql_re…
The official docs will tell you how to properly handle queries, including prepares: http://php.net/manual/en/pdo.prepared-statements.php Additionally, the mysql_ extension is deprecated since PHP 5.5: http://php.net/manual/en/migration55.deprecated.php The official docs on the old mysql_ extension has large warnings advising people not to use it: http://php.net/manual/en/function.mysql-connect.php Reading a 10 year o…
> PHP has moved on, if only the haters would too.
Unfortunately it's not that easy. A lot of those tutorials are still being read by newcomers, and a lot of the web is filled with vulnerabilities as a direct result of official documentation recommending insecure ways of interacting with the database.
PHP may be "in recovery," but that doesn't necessarily mean the bad taste will magically leave everyones' collective mouths. The damage has been done.
Re: Learning Curves for Different Programming Languages
#189Earlier quoted context omitted.
The official docs will tell you how to properly handle queries, including prepares: http://php.net/manual/en/pdo.prepared-statements.php Additionally, the mysql_ extension is deprecated since PHP 5.5: http://php.net/manual/en/migration55.deprecated.php The official docs on the old mysql_ extension has large warnings advising people not to use it: http://php.net/manual/en/function.mysql-connect.php Reading a 10 year o…
So your argument is that the dangerous extension is deprecated as of a year and a half ago? Given that PHP has been around for nearly 20 years, it seems like your evidence supports my argument more than yours. > PHP has moved on, if only the haters would too. Unfortunately it's not that easy. A lot of those tutorials are still being read by newcomers, and a lot of the web is filled with vulnerabilities as a direct re…
I agree a lot of people read insecure tutorials, but it allows even beginners to write fairly advanced web sites. If the choice is between easy and available and difficult and hard to use, I'd rather have the first option available. On the web, ideas, timing and execution is important, not how amazing your code looks on the backend. A lot of great software may not have been created had it not been for how easy PHP is to get started with. As a community we are trying to educate people to code properly. It's an ongoing process.
Re: Learning Curves for Different Programming Languages
#190Earlier quoted context omitted.
It's an incorrect conclusion that requires further education and experience before you can be sure your subjective experience of productivity truly is that poor.
please, this is getting old. Haskell is one of those languages for people who want to show off how clever they are instead of just getting on with developing applications that actually do useful things efficiently.
Yes, that's what banks are most known for. Showing off how clever they are and not doing anything useful. Facebook and google certainly fit that profile as well right?