Anybody here has developed and deployed a Scala-based or/and Haskell-based project for production? I mean systems for business purpose where rubber meets the road with timeline to hit and budget to meet. Far too often the stories are shared by people who learned a new language for 3 months and implemented a pet system where only a few real users. Definitely I respect their zeal and curiosity, but I am more interested…
Yes. We wrote a webapp in PHP. It has actual paying customers, and handles billing and invoices for real money. As is so common with PHP projects, as we needed to keep adding features, changing functionality, etc it got difficult to maintain, and hard to make changes without adding bugs. So, we re-wrote it in scala using lift. We were not pleased with the results. So we re-wrote it in scala using play. We were even l…
Hello Haskell, Goodbye Scala
101–110 of 118 posts
Re: Hello Haskell, Goodbye Scala
#102Earlier quoted context omitted.
Not to mention, functional programming forces you to grok recursion and higher-order functions. Huge side benefit of learning FP that you can also implement in your OOP to write more elegant methods. Never write "for int i..." again.
And hope that your imperative language supports tail call optimization? ;)
I am starting to realize why people who know functional languages despise Java. I first started programming in Java, but now the more FP I learn, the uglier Java gets.
Re: Hello Haskell, Goodbye Scala
#103Earlier quoted context omitted.
Yeah, those tricky monoids. So hard to learn, and even harder to use a library based on them. You have a whole whopping one function to learn, that does some incredibly convoluted and arcane nonsense called "appending"? What a horrible language. You should definitely devote more time to complaining about ridiculous strawmen like this, it seems like a very good use of time.
Here is some of my code to parse html: tstamp >> arr parseTime - >> (this ! "href") &&& (getAllText >>> arr parseScore) - So yes, you do have to learn about arrow syntax in order to use HXT efficiently. For most newbies it is not an easy concept to grasp, not helped by the fact that HXT isn't a very well documented library.
tstamp >> arr parseTime -
This, on the other hand, is one of the thing I don't like about Haskell: there are 4 operators on this line, and no easy way to see, at a glance, their precedence. Also, some operators are "mentally interpreted" as flowing data left to right or right to left; changing the direction mid-statement, I find confusing. I have the same problem when unix shell commands are expressed like this: program outputRe: Hello Haskell, Goodbye Scala
#104I enjoyed the read, but I borked at your suggestion that not being purely functional, and the language barking at you if you break that convention stops you learning functional programming. Take most Lisps (I'll assume scheme, because it's what I'm most familiar with), which give you more than enough side-effecty rope to hang yourself with should you so desire- but you won't get far unless you're coding functionally.
I haven't seen much functional code in elisp, which is the Lisp I most commonly read. Some Common Lisp code I saw was also very imperative. Scheme seems to be a more functional language, but I don't really see why people consider other Lisps any more functional than say, Python.
Still Common Lisp uses mechanisms of functional programming widely. It supports lexical binding, many library functions are higher-order functions, etc. There are also some programs which are written in a very functional style and most implementations support tail call optimizations to further make a functional style useful.
Common Lisp does not enforce a particular programming paradigm. As a start all three supported would be used by a programmer. He or she might even add some more, if necessary.
Re: Hello Haskell, Goodbye Scala
#105Earlier quoted context omitted.
Yes. We wrote a webapp in PHP. It has actual paying customers, and handles billing and invoices for real money. As is so common with PHP projects, as we needed to keep adding features, changing functionality, etc it got difficult to maintain, and hard to make changes without adding bugs. So, we re-wrote it in scala using lift. We were not pleased with the results. So we re-wrote it in scala using play. We were even l…
Thanks for sharing. Could you elaborate why you were not pleased with the previous experience with Scala? The project was hard to maintain? Or it couldn't take heavy hitting of requests? Or it has limitation for multi-programmers kind of work?
Re: Hello Haskell, Goodbye Scala
#106Earlier quoted context omitted.
That's my point. You're talking about jumping around from language to language, but Functional Programming techniques tend to be applicable across all of them. My personal angle is that Haskell puts up less bullshit in your path while you're learning stuff about type based reasoning at the cost of being much less like things you may have seen before. Regardless of that, going from Haskell to Scala to ML to Clojure ad…
I wouldn't call opening myself to multiple languages "jumping", and it seems a bit of a leap that you assume so. (Note that I said nothing of the proportions invested in each.) The only point of my post was that one does not need to wall oneself off from one language in order to open oneself to another. Regardless of that, going from Haskell to Scala to ML to Clojure ad naseum isn't going to get you any deeper unders…
Comparative language evaluations are fine, but don't tell me that you made that clear that that was what you were after in your original comment.
Re: Hello Haskell, Goodbye Scala
#107Earlier quoted context omitted.
Would it be okay/possible to post the materials online? I'd be interested in going through the course.
The course material is still available, although you'll need to sign up for a Coursera account. It also looks like they're running another course in March 2013. https://class.coursera.org/progfun-2012-001/class/index
Re: Hello Haskell, Goodbye Scala
#108Earlier quoted context omitted.
I wouldn't call opening myself to multiple languages "jumping", and it seems a bit of a leap that you assume so. (Note that I said nothing of the proportions invested in each.) The only point of my post was that one does not need to wall oneself off from one language in order to open oneself to another. Regardless of that, going from Haskell to Scala to ML to Clojure ad naseum isn't going to get you any deeper unders…
Learning any one of these, if they have a strong type system and an emphasis on immutable data are going to prepare you for the literature. Comparative language evaluations are fine, but don't tell me that you made that clear that that was what you were after in your original comment.
I also don't understand why I needed to make it clear that language comparisons are beneficial. Was someone trying to assert that they're not?
Re: Hello Haskell, Goodbye Scala
#109Earlier quoted context omitted.
Learning any one of these, if they have a strong type system and an emphasis on immutable data are going to prepare you for the literature. Comparative language evaluations are fine, but don't tell me that you made that clear that that was what you were after in your original comment.
You're a strange chap. If you agree that languages are small – so much that you insist it was your point when, in fact, it was mine – then why do you think there's such a large cost to picking up another one? I also don't understand why I needed to make it clear that language comparisons are beneficial. Was someone trying to assert that they're not?
Now on the other hand, if you just like looking at a lot of languages and seeing the design tradeoffs, you can spend a lot less time using each one to get that perception.
But you only mentioned learning FP in the first place. I didn't divine that comparing the language design was your reason for not picking one and sticking with it.
Re: Hello Haskell, Goodbye Scala
#110Earlier quoted context omitted.
You're a strange chap. If you agree that languages are small – so much that you insist it was your point when, in fact, it was mine – then why do you think there's such a large cost to picking up another one? I also don't understand why I needed to make it clear that language comparisons are beneficial. Was someone trying to assert that they're not?
You said, 'My own approach to learning FP has been "Hello Haskell", "Hello Scala", "Hello ML", "Hello Clojure", "Hello Rust",...' and I thought to myself, "Well, that's not going to really help you learn Functional Programming techniques and design strategies". You really have to use a language for a while to understand how to make a good software design inside of it. It's not the cost of learning the language, it's…
That's where you went wrong, then, because it doesn't in any way rule out the possibility of learning it either.
In your initial response, you said "Maybe you should actually learn something about FP...". Let's make this clear: you don't know me.
Pro tip: if you have to make assumptions about other people, then it's possible to make a wrong assumption. In these cases, it's often better to ask a question than to launch into criticism based on assumptions.