On 13 July 2010 09:04, Wildam Martin <[email protected]> wrote: > On Tue, Jul 13, 2010 at 06:29, Oscar Hsieh <[email protected]> wrote: > > Well, someone need to balance the force ... so let me take on the other > > side. > > Thanks, I already somehow got the impression being quite the only > person here that sees some of the currently hyped (real programming) > languages and paradigms from a more critical point of view. > > > > 1. function language syntax look too much like mathematical equations, > and > > most people dont like math. Comparing the following code > > erlang: [X + 1 || X <- L]. > > java: for(X : List1) List2.add(X+1); > > You can argue but I think most people will find the 2nd code fragment > > easier to understand. > > Of course. I remember school time where one of my collegues' sport > when we did C++ was to write things as one-liners, that others wrote > in ten lines. He was very smart but the problem is: The code should be > readable by as many people as possible. If just the 5 smartest people > of the world are understanding it, then you have to pay those smart > people to maintain the code which is expensive.
You forgot my favourite! scala: val list2 = list map (_ + 1) I'd like to think that was pretty readable & maintainable, the idea of transforming every element in a collection shouldn't cause problems for *any* developer > > > 2. Pure function language such as Erlang does not have loop (for, while > > ...). Instead, you have to use recursion. For average > > Joe, recursion is hard. > > Recursion is often a smart - often even the easier method to solve a > programming problem, but it also creates a huge stack. I had cases > where I ran out of memory because the recursive solution was consuming > up the memory. The non-recursional solutions can be harder to code but > less resource hungry at runtime. Definitely harder to read if you're not familiar with the technique. Though I often wonder what aspects of object-oriented programming would be challenging to a programmer only familiar with functional techniques; the correct use of wildcards in Java Generics has definitely got to be a candidate here. Also... most, if not all, functional languages provide tail recursion to stop this from happening, so the massive-stack argument is invalid. > > 3. Yes function language code tend to be concise, but sometimes people > tend > > to be tooooo concise. I have seem lots Erlang code > > with single character function name and parameter f(X, Y) #...@%$@#%. > > Oh man, yes, you make me remember things that were deeply burried in > the last corners of my brain... > To find the shortest meaningful name was a challenge. But I think that > helped me when trying - before exams - to put as most information as > possible into my TI-74 with it's 8KB RAM only. ;-) Very limited memory devices. Now that's a classic use-case for procedural programming. (see, everything has it's place!) > > Yes you can also write bad code in Java, but thanks to its > > chattiness, people tend not to write short class/function/parameter name. > > In practice IDE's are doing autocompletion and NetBeans either does > (quite good) parameter guessing so even very long variable names are > not really an issue these days. Reading a long functional expression > on the other hand with longer function and variable names (still) is. > NO! No, no, no, no, no Having IDEs write boilerplate for you is NEVER the correct solution, not until they can read it for you as well. The cost of writing code is trivial compared to reading, understanding and maintaining it. Eye-tracking studies and other research have clearly shown that the time taken to understand an algorithm is directly proportional to how large it is, both in LOC and in the length of those lines. BTW: I met people arguing e.g. the much of code to write for example > for "MyCoolClass myCoolClass = new MyCoolClass();" > NetBeans offers the code templates feature where you just write "newo" > and type tab. While typing "MyCoolClass" it automagically writes that > also in parallel after the new keyword. So the amount of writing can > be really reduced which means: You do not really need to write so much > code and still get the readability - thanks to modern IDEs. And the > same people then still argue why the hack writing this two times, but > hey, there are cases where you write "MyCoolClass myCoolClass = new > MyMoreSpecificCoolClass();" - so makes sense not rationalize, isn't > it? The classic example in Java is Map m = new HashMap Which allows you to change the exact type of Map you use at some later point in time. But... this is just a hack to work around the lack of type inference. Now consider scala: val myCoolClass = new MyCoolClass val myCoolClass = new MyCustomCoolClass I challenge you to give me even a single valid use-case where you would need to use MyCustomCoolClass but also need to hide any extra methods/properties it exposes. > 4. Function language are stateless and immutable. Although that is very > > good thing but can be challenging for new developer. > > Immutability (in the meaning of the word) etc is also a topic to learn > in Java and can be done with plane Java also, if you just want > immutable objects. Of course there is an implementation difference and > for the functional approach it's by design immutable. And: There are > plenty of use cases where mutability makes much sense - and of course > then it can be challenging - for the new developer and either for the > experienced one. I use to think so as well, but since changed my mind on this :) Hibernate for example, it seems obvious to take a bean representing a DB row, mutate it, then save it. But that then leads to all sorts of issues with beans tracking their session, which is bound to a thread, so such beans can't be passed across a thread boundary. Then you've got all this extra work to create/destroy sessions for each and every thread that uses hibernate. It's far cleaner to bind the row to an immutable object, clone that with the changes, then push it back into hibernate. The thing still has an ID, which maps to a primary key, so it'll get saved in the right place all the same. Threading issues just melt away, the hibernate session could even be made into an actor... Similar logic is now being applied to backing objects in rich GUIs, and with events being represented as lazy-evaluated streams. > 5. Tooling. One thing I hate about coding Erlang is error message that > does > > not tell you anything, and the lousy debugger. After using java and > eclipse > > for so many years it is like going back to stone age. > > I feel that for designing web applications - the NetBeans already had > the visual designer for JSF and dropped the support for it in 3.8 - I > hope it will be back (even if it had flaws it is better than nothing). > > Although the Java debugger is already very good, I still miss the > feature from the VB debugger that I could completely change the code > and set the execution point to whereever I wanted during run of the > program. I miss in particular the option to set the execution point > e.g. back to the beginning of a loop or so. Totally, I feel for you here. I'm sure there was once a debugger that let you step back in time through the stack, make a change, then hit "play" again... I wonder what happened to that? > > Recently I have a new job. Although interview was all about Java, I was > > asked to work on Erlang and MongoDB. > > (It is partially my fault since I mention I was learning Scala :), but I > > think they also have problem finding people know or > > willing to learn function language. > > I guess they don't expect anyone have experience with those so they > even don't ask to avoid fear. > > > > Personally I think everyone should at least take a look at > > functional language since it allows you to see programming > > from a totally different perspective. > > Yes, of course. However, some people want to talk me into trying some > new stuff to learn the new perspective although I already have - even > if it is very old nearly forgotten experience. Anyway there were > reasons (basically those you mentioned) why I decided not to remain > with those languages. > > > > However, I think it is silly to > > choose language mainly based on how functional it is or > > how much less boiler plate you have to write. > > Yes, focus should be considerations like (in no particular order): > - Interoperability with other stuff > - ease of use and learn (it is needed that it is easy for new > developers to get on board) > - stability and continuity of the language > - bug resistance (yes, with some languages it is easier to write buggy > code) > - tools (of course) > - ... It's just that different people have different ideas on what is easy, stable, and bug-resistant. I find that unnecessary duplication of names and types is often a source of problems if they're not meticulously all changed together in a refactoring, so reduced boilerplate and type inference help to achieve your criteria. > > As far as I see functional > > languages are still too nerdy for most people and > > probably remain mostly in telecoms and those of googles and amazons. > Scala, > > being the hybrid and seems to get the best of > > both worlds, might finally bring both worlds together, at least we can > hope > > Having both options in Scala maybe increases the options on how you > could write bad code. ;-) > Some things are better in FP, some in OO. If your language only offers one paradigm then you're almost guaranteed to write bad code when the other is called for. > However, I learned here in this group that the functional approach > makes sense for parallel programming in the way that it avoids thread > overlapping issues by the constraint of immutability for example. > > And Scala for sure is good stuff - I read performance tests where it > ranged closely behind C++ being even faster than Java. > > Anyway, although there is a lot of good new stuff, I do see people > expecting those stuff to be the overall solution for all problems - > even for the hunger in the 3rd world... > We're working on global warming at the same time. Build some massive solar farms in Africa, use local labour wherever possible to push money into economies there, reduce our dependence of fossil-fuels for electricity. These farms need moving mirrors, which need control software, something good with concurrency to handle all those mirrors... > -- > Martin Wildam > > -- > You received this message because you are subscribed to the Google Groups > "The Java Posse" group. > To post to this group, send email to [email protected]. > To unsubscribe from this group, send email to > [email protected]<javaposse%[email protected]> > . > For more options, visit this group at > http://groups.google.com/group/javaposse?hl=en. > > -- Kevin Wright mail/google talk: [email protected] wave: [email protected] skype: kev.lee.wright twitter: @thecoda -- You received this message because you are subscribed to the Google Groups "The Java Posse" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/javaposse?hl=en.
