I don't really know Java, so this is made up Java/C#/something, but compare these:

    List<int> mapped = new List<int>();
    for (int i = 0; i < list.count(); i++)
    {
        mapped[i] =  list[i] + 1;
    }

Or:

    List<int> mapped = list.map((x) => x + 1);

Which do you think is more elegant and readable? For a slightly more extreme example, what if we want the numbers less than 100:

    List<int>filtered = new List<int>();
    for (int i = 0, j = 0; i < list.count(); i++)
    {
        if (list[i] < 100)
        {
            filtered[j] = list[i];
            j++;
        }
    }

Or this:

    List<int> filtered = list.filter((x) => x < 100);

I wrote a blog post with a nearly identical example.

http://jaydonnell.com/blog/2011/08/07/is-your-idea-clealry-e...

The code gets nutty when you have to do multiple transforms on collections. There are some libraries in Java which make it more bearable.

http://code.google.com/p/lambdaj/

    List<Person> sortedByAgePersons = sort(persons, on(Person.class).getAge());

Using objects and a functional style aren't mutually exclusive. Use objects for encapsulation and abstraction and use a functional style for clarity, conciseness, expressiveness and less mutating state.

I think it's a fair statement to prefer the OO paradigm, and indeed it is good for a whole load of things in programming. Nonetheless, adding lambdas to Java should give plenty of easy wins even if you prefer your code to be broadly OO.

Look through your for and foreach loops. I bet a lot of them would be neater, more readable, and better express intent as some combination of map and filter.

Count how many classes you have with only one method and no data in them. Would you really make separate classes for all of those if you had the option to pass them around as functions?

I would also like to see something like the yield and yield! (yield every item in this collection) keywords, because those can give readability improvements in a lot of places too, but one step at a time.

> Count how many classes you have with only one method and no data in them.

I have never done this, but for the usecase that you have mentioned, would the following work?

  class Xyz {
    private Type type;

    private RetType type1MethodName(params) {
      // Do Whatever
    }

    private RetType type2MethodName(params) {
      // Do Whatever
    }

    public Xyz(type) {
      this.type = type;
    }

    public RetType methodName(params) {
      switch(type) {
        type1:
          return type1MethodName(params);
        type2:
          return type2MethodName(params);
      }
    }
    
    public enum Type {
      type1;
      type2;
    }
  }

And then when we want to pass methods according to types, we can just instantiate the class with a proper type and pass it.

JavaScript is kind of functional. It pretty much forces you to use functional stuff like closures.

It's not a pure functional language, but it's sure not pure OO either.

Yes, but IMO JavaScript, again, is not as easy to read (especially for a person who's just learning it) as Java.

(And why the downvote?)

Not worth saying: "I like pizza. It tastes good."

Worth saying: "I like pizza. Its combination of bread, cheese and tomato sauce is unique."

I haven't downvoted, but you've not given any reasoning behind why you think OO code is more readable than functional.

I suspect most people think readability is more affected by style rather than choice of programming language.

Agreed, may be I have seen only bad code. I am still a student and the only industry code that I have seen was in Java. Much of the rest of code, that I saw in academia, was functional in nature and written in C.

I have observed that (may be due to the lack of a review system in academia) the code was much harder to read. With C, the problem was even worse due to extensive use of global variables and poor structuring of code. Java, on the other hand, has two benefits: firstly, it's really strict and verbose. So even if a person is practicing bad coding, it is still harder to make truly unreadable code. Secondly, the IDE are more powerful, makes coding as well as code browsing easier.

My prejudice might be against C and in favor of Java. And i just related it to functional and OO respectively. But I would like to add that modifying objects still somehow seem more intuitive to me - probably because I had a better Java teacher than a C teacher. :)

I think you might be misunderstanding what "functional" means. C is typically considered a procedural and not functional language, even though you do define everything in functions.

Functional programming refers to languages (like scheme and Haskell, and also Ruby and Python) where a function is no different than any other object in memory (like int, char, etc.). It can be returned as a value and passed as a parameter. A function can take functions as arguments and return another function as a result, kind of like taking the derivative or integral in math. (Something like this can be done in C with function pointers, but it's ugly.) Moreover, it's possible to define an "anonymous function", or "lambda". This is essentially an expression that evaluates to a function without a name, the same way you can type (x * y * z) and have it evaluate to a number without having to store it in a named variable first.

Also, you ideally want to define "pure functions", which means functions that return the same value for the same inputs no matter when you call them. These are much easier to debug than code that depends on outside conditions.

When you wrap your head around functional programming, it is actually a lot easier and more sensible in many cases than OOP. Of course, OO is still ideal in a lot of situations, which is why many languages (Python, Ruby most notably) combine the two.

(if you've been in academia, Mathematica is an example of a functional language.)

I didn't downvote. Don't sweat the downvotes. Sometime people just hit the wrong button. Sometimes they don't agree. If you worry about being popular on HN ...

Anyway.

It might be harder to read because you already know Java. Javascript has some horrible warts (IMO), and CoffeeScript fixes.

Also, Javascript is usually targeting the DOM, which is often ugly, especially if you are trying to include compatibility stuff. The DOM is basically a GUI, and GUI code can be rank ugly. Yes, it is hard to read (and learn) HTML, CSS, DOM, HTTP, and Javascript all at once, which is what real Javascript often involves.

Yes, and to add on that, I think for JS there is a lot of ugly code out there on the web. I have actually used them a lot before watching Crockford video's and I found them quite late!

BTW, are there any other resources similar to these videos? (Or, to put it differently, is Douglas Crockford the authority for JS?)