Live data from Hacker News

Learning Curves for Different Programming Languages

github.com

131–140 of 221 posts

Re: Learning Curves for Different Programming Languages

#131
post #62

Really don't understand the pure hatred that people have for PHP, I'm at network engineer and I don't have any desire to become a programmer because I love my job, however I've wrote some very useful applications that myself and my team use on a daily basis to make networking easier for us. For me it was simple to learn PHP and create something 'useful', basically every web server is capable of running it which makes…

I'm no mechanic and I have no desire to be one but I've changed my own brake pads, surely anyone can adjust their car's brakes and many other tasks with a few simple tools and a book. I don't understand why mechanics say some cars are better than others.

Playing around with motorbikes is actually one of my hobbies, and I have some very nice and quite expensive Snapon tools which work wonders in the garage.

However I'm certainly not going to suggest that changing your breakpads was done incorrectly because my tools cost more than what I'm assuming yours did, or that I could complete the same job a bit quicker and therefore better.

Sure, if you're going to change break pads all day long for the next year I can suggest some very nice tools which might help you.

But instead I'd like to say well done on changing the break pads, I'd wish more people would use the tools that they have at there disposal, show some initiative, and do the same.

Re: Learning Curves for Different Programming Languages

#132

Would learning Monads really come before learning Category Theory in Haskell?

Monads are a construct from category theory, and one with a particularly significant use in idiomatic Haskell, so I'd expect learning Monads as used in Haskell to generally precede a broad understanding of category theory for most Haskell programmers.

Thanks, good to know. I should clarify that I was genuinely asking a question and not making a statement.

Re: Learning Curves for Different Programming Languages

#133

Earlier quoted context omitted.

I think the fact that Ruby didn't even make the list tells a lot about how far it has fallen in terms of mindshare. I have nothing against Ruby, its people or its ecosystem, but it's beginning to seem like a bit of a flash in the pan.

10 years+ totally a flash right?

When you have more than a few years' experience yes, something like this seems like a flash in the pan.

http://www.tiobe.com/index.php/content/paperinfo/tpci/Ruby.h...

Peaked in 2009, now down to a third of that popularity. Other measurements might give you different numbers, but the same trend. As I said, I have nothing against Ruby, but it just doesn't seem to be holding its position.

Re: Learning Curves for Different Programming Languages

#134
post #95

Earlier 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 )

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

#135

Earlier quoted context omitted.

I wrote the core of our system in Clojure a couple of years ago, which is pretty high in productivity and actually quite pleasant to work with. Unfortunately as the scale goes up (hundreds of web application routes, sharing code among multiple projects etc) it doesn't feel nearly as nice anymore, and having static typing turns out to be pretty handy. Haskell to me felt exactly like what you described: I could get stu…

Oh ok, I can be wrong about Haskell. BTW, I really like Ceylon, it's very statically safe (more than Haskell I'd say) and very pragmatic (unlike Haskell IMHO, it doesn't seem to focus on maximizing productivity).

Ceylon looks interesting. Mind pointing me to some features you think make it more statically safe than haskell?

Re: Learning Curves for Different Programming Languages

#136

Earlier quoted context omitted.

There are a few startups out there who use it as their core tech. It's a sweet spot because you don't have any legacy code to support and it allows you to slap together fairly stable code fairly fast, at least once you get to know the basic tools. E.g. picking up Yesod (which, to be fair, isn't something you'll do in a couple hours) gives you all of the niceties and rapid prototyping of a tool like Rails, plus the ob…

I can't imagine ever using Haskell for a startup. Unlike pg's python paradox, the only programmers I could imagine applying would be programming language theorists, toy programmers, and people who think they are productive (because arrows!), without ever having built anything ever. I would only do it if it meant I could hire John Macfarlane.

We use Haskell heavily at my startup and it's definitely a competitive edge and well suited to the many general programming problems we solve with it (amqp processing client, rest api, javascript heavy webapp w/ haskell web framework backing, db orm modelling, scrubbing and feeding data into influxdb, the list is long).

I know quite a few professional programmers who credit Haskell with making programming fun for them again (this holds true for me too and my production skill set includes php, c, c++, python, ruby, erlang, scheme, javascript, scala).

Re: Learning Curves for Different Programming Languages

#137

Everyone seems to be focusing on the PHP vs Haskell thing and seem to be missing the other points. Here's a summary: Callbacks in Javascript make you feel more productive, but in fact you become less productive. Design patterns in Java don't actually make much of a difference in productivity, but you think they do. Templates in C++ seem hard but with a big payoff, but they don't accelerate productivity. Unit tests in…

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 else, just using it as an example. I don't use Haskell and wouldn't know how the libraries compare.

My only point is that when all the smoke and bullshit clears out the only thing that matters is if you can get the job done as required. If this includes a performance metric than language performance is important. If it does not, then library availability or other criteria might quickly become more significant.

From my own perspective, it would take a lot for me to choose anything other than Python for my work. When a platform mandates it --iOS native apps-- you have no choice. On embedded systems it's mostly C. When Python fits I can get shit done with it. Nothing else matters.

Re: Learning Curves for Different Programming Languages

#138

Earlier quoted context omitted.

>I just don't find Haskell ... to be as productive as many would suggest >I have ... very little experience with Haskell So, how would you know?

I don't know with 100% certainity, but it's a moderately confident conclusion from my little experience.

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.
Post reply on HN