> Kay Schluehr posted this on another thread recently. Not sure if you saw it. It challenges the notion that parallelism 'comes for free' in functional languages.
No, I hadn't seen that. Thanks.
I think the argument is faulty because saying "this makes it easier to ..." does not mean "this is the absolutely very best way to. ..." I just finished reading "Design abd Evolution of C++," a ten-year-old book. In it Stroustrup made the off-hand comment that people were predicting multi-core computers would be commonplace Any Day Now, and when they were, functional programming would Really Take Off. Thing was, they had been predicting this for thirty years at the time! And, as I said, that was ten years ago.
If it hasn't taken off yet, it may simply not be the most natural way to think about many problems. I've looked at erlang, lock-free programming, and POSIX-style threading (in the generic sense, including the same kits you get with Java and Windows), and things look to me like there isn't one best way to write multithreaded apps (any more than "while" loops are better than "for" loops).
This all counts moreso because Scala doesn't have the traditional functional VM. Scala runs in the Java VM; so this "trivial parallelizability" is just as trivial with Java-generated bytecode.
But I will go back to "sometimes a functional approach is the most natural approach (and sometimes it's not -- I really don't see the benefit of calling a function recursively in all cases instead of just looping); I've seen this in Perl, and I keep working hard to find it in other languages." Scala may meld a couple approaches together better than the competition. I don't really know. I've given Scala a few half-hearted looks in the past. I may give it a better look after I'm done going through "Structure and Interpretation of Computer Programs" again (this time without translating all the approaches to C++).
> But I will go back to "sometimes a functional approach is > the most natural approach (and sometimes it's not -- I > really don't see the benefit of calling a function > recursively in all cases instead of just looping); I've > seen this in Perl, and I keep working hard to find it in > other languages." Scala may meld a couple approaches > together better than the competition.
I find that Python makes it pretty easy to use OO and functional techniques together. This style has had a big impact on designs in Java. It's not all that natural in Java but you can still pull it off.
I think that a lot of people look at something like Scala and say "nothing new here" but I'm not looking for new stuff in a language. I want a language that incorporates all the proven features of successful language and eliminates the warts associated with the originals.
So far, Scala only has one obvious wart that I know of: erasure. The standard library has some nasty bits IMO. Native XML support is an ill-conceived attempt at being 'business-focused' IMO. I have some concern about the implicit feature with regard to maintenance (although it could be helpful for maintenance too.) Other than these fairly petty concerns, it seems to be a pretty good crack at getting a lot of good stuff together without too many screw-ups.
As far as getting major acceptance going, I think the comment about the academic feeling is right. The documentation needs to be fattened up and come down a notch to spell things out in more detail. I had to use two documents and trial and error all together just to work out how to do certain things.
After quickly checking Scala syntax, it seems like a next generation Java. It already has all the features that are being just planned for JDK7 (and many others that are not even planned). And, what's most important, it has multi-line string literals. :-)
Basically Java should be freezed as it is now, and instead Scala should become the new official Java. Java has too much burden, like primitives not being objects.
I have been using Java for a long time and found it has served most of my needs almost all the time. But i am kind of curious as to whether i am missing something by not knowing enough about groovy or Scala. Is there any real scenario where someone has made use of either and found that it enabled you to achieve something that could not be done by Java.
> I have been using Java for a long time and found it has > served most of my needs almost all the time. But i am kind > of curious as to whether i am missing something by not > knowing enough about groovy or Scala. Is there any real > scenario where someone has made use of either and found > that it enabled you to achieve something that could not be > done by Java.
I think the thing that functional programming is really good at is making code reusable. Much more easily than OO does. Actually, I think there's a common misconception that the main point of OO is code reuse.
Most likely, you've used Java in a functional way. If you've ever used SAX with a custom handler, you've used a functional-style API. But it takes a lot of work to do this in Java and isn't all that natural. As a result, I believe functional-style approaches are very much under-used in Java. There are some certain features of functional languages that don't have a direct counterpart in Java although, you could probably emulate all of them with an OO design. It's a question of how much time and effort is worth spending on something that you can just do in a functional language.
At the very least, I think learning a language with functional features is definitely worth it, even if you still use Java for your implementations. It will improve your designs. Python is a good start because you'll be able to code right away without a paradigm shift but Groovy may also be a good choice for this same reason. I'm not familiar with Groovy's functional features (or lack of them.)
Flat View: This topic has 19 replies
on 2 pages
[
«
|
12
]
Previous Topic
