Re: Haskell monads
If something hurts my brain, I don't want to do it; I don't care about the long-term benefits. Most humans feel the same way and that's why Haskell will never become mainstream.
Learning Curves for Different Programming Languages
211–220 of 221 posts
Re: Learning Curves for Different Programming Languages
#212Re: Haskell monads If something hurts my brain, I don't want to do it; I don't care about the long-term benefits. Most humans feel the same way and that's why Haskell will never become mainstream.
...and that's the difference between an amateur and a professional.
Re: Learning Curves for Different Programming Languages
#213Re: Haskell monads If something hurts my brain, I don't want to do it; I don't care about the long-term benefits. Most humans feel the same way and that's why Haskell will never become mainstream.
...and that's the difference between an amateur and a professional.
No, it's not. Software developers are human. Being a professional does not always override human nature. Statistically, most "professional" software developers will not want to adopt a language with a high cognitive load.
Re: Learning Curves for Different Programming Languages
#214Earlier quoted context omitted.
...and that's the difference between an amateur and a professional.
No, it's not. Software developers are human. Being a professional does not always override human nature. Statistically, most "professional" software developers will not want to adopt a language with a high cognitive load.
Doing what you need to do, and not what you want to do, is the heart of professionalism.
Re: Learning Curves for Different Programming Languages
#215Earlier quoted context omitted.
If I took time to link to each one of those would it change your opinion any?
Likely. Ideally with code tutorials/examples rather than "me and my friends changed X to Haskell and we liked it". I mean, it's not I am anti-Haskell or something (it is clearly on my list things to learn), and I am theoretically-inclined (I did quantum physics and pure mathematics). Moreover, I am biased towards clever, succinct solutions rather that horrible code that "just works, somehow". Yet, for practical probl…
Re: Learning Curves for Different Programming Languages
#216Earlier quoted context omitted.
jQuery and Javascript Promises comes to mind, I know they started in C++ put they are practically Monads.
Since when did monads become a synonym for Haskell?
You really need to learn monads to use Haskell, and it's one of the major barriers for newcomers. It's no different from pointers in C.
Re: Learning Curves for Different Programming Languages
#217Earlier 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…
"People will forget what you said, people will forget what you did, but people will never forget how you made them feel."
-- Maya Angelou
If PHP had moved on, it wouldn't want to be PHP anymore. Those haters have moved on: they did so when they decided to not program in PHP anymore.
Re: Learning Curves for Different Programming Languages
#218Earlier quoted context omitted.
What distinction are you making between "learning monads" and "gaining an intuition for monads and memorizing the 3 monad laws"?
The distinction that memorizing 3 simple rules is not exactly a deep understanding of category theory.
I wasn't asking for any distinction from "a deep understanding of category theory". Neither "learning monads" nor "memorizing 3 rules and building intuition" stands a chance of being identical to that, though.
Re: Learning Curves for Different Programming Languages
#219Earlier quoted context omitted.
> Half of the web is powered by PHP, including tons of websites with huge traffic and usage. What powers the web: web servers or web sites/applications? If it's web servers then your claim that half of the web is powered by PHP is false because I'm—and I'm going to be honest here—yet to see/use a web server written in PHP.
Obviously web sites/applications. Web servers would just server static sets of pages without some means to run dynamic code.
> Web servers would just server static sets of pages without some means to run dynamic code.
Web applications respond to requests. That's all they do. Web servers parse those requests and deliver responses appropriately. You're reducing the role of all intermediaries (DNS servers, caches, etc) and unfairly praising the web application. The web server serves both non-changing static files and the generated documents.
Re: Learning Curves for Different Programming Languages
#220Earlier quoted context omitted.
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).
I think the only languages that are "statically safer" than Haskell are the theorem provers... (agda and coq come to mind) Disclaimer: I do not have enough PL type theory under my belt to confidently make this argument.
Haskell is the least statically safe language I've used.
Sorry, that Bool was actually an expensive computation that eats up all your memory, but there's no way to figure that out without running it.
At least in C, you know unsigned char and the uintN_t integers won't blow up in your face. In Haskell, you can't be sure about anything, not even unit.