Why functional programing approach can be good?

Oh, yes, I figured it, but it is the first code, done by anyone using JME3 using functional programming I ever seen, a paradigm that I hate and I can’t understand it advantages (paying readability for… what?, is like going backwards on language progress).

(Sorry about off-toping :S)

I take it you refer to the lambdas under the usage title on the github page. These could easily be anonymous classes implementing the interface but it makes the sample a bit more readable, at least to me. Ideally the loading tasks should be implemented as concrete classes and not be done as anonymous classes or lambdas. I strongly encourage testing and this code has about 70% test coverage, but lets not get into that here :wink:

I’ve mainly been using Java 1.8 for the current project I’m working on, which this code is extracted from, and I must say I’ve got to really like some of the 1.8 api and the lambdas at times. I was at first rather hesitant to using the new language features of 1.8 but now I really like them :smiley:

Well if you do enough multithreading, you will understand where functional shines greatly.

multithreading

Hm… there is any great article making any comparison about the different usages (object oriented vs functional) on Java?, or any great tutorial about this?. I would like to learn the basis of it if is really better. All that I can find on google is about the lambdas, nothing focusing on multithreading aspects.

well I guess google would help I never followed any tuto.
It’s a bit off topic with the current thread though, so I’ll summon @erlend_sh so he does his splitting thing (never figured how to do it).

The biggest problem with classic OO, is that you have to make sure your class is thread safe to be able to properly use it in a multithreaded context (ie state less classes).
From my understanding one of the main paradigms of functional programming is that there is no shared states between operations. Functions are just that : functions, with no state that could leak out of the context. This makes multithreading trivial, and it’s perfect for multi core architectures that we have today.
Note for example that to multithread a stream operation in java 8 you just have to call parallelStream() instead of stream() and chain whatever operation to have it parallellized for you.
That’s huge.

1 Like

Lambdas and stream api is really nice for typical (and not…) collection handling tasks, also stream api provides parallel processing based on superfast fork-join-pool, but you have to take into account a tradeoff between cost of creating and maintaining multiple threads and benefits of their usage. If your problem takes lesser than 100ms in single threaded mode, then you most likely wont achieve any performance enhancements with using parallel stream, but situation definitely changes when your task is quite big. And all java 8 stuff is cool because it makes code much more human-readable, reduces boiler plate code and just makes all shorter =)

P.S. I’m not advertising java 8 and I also don’t prefer functional programming :stuck_out_tongue: , I still love old java.

Yes, I can understand the point of “parallelizing” things but my concept of “multithreading” (doing full operations on the thread) isn’t really the same as “parallel” (splitting the same operation on threads). So, the real advantages are for the second definition?, just streams?.

I can’t agree with you in here. All the code I see is, imo, less human-readable, it may make all shorter (sometimes you just reduce some characters) but I don’t think more human-readable. The concept of lambdas comes from mathematics, and so, it not-readability.

Not sure I get what you mean.Streams are just an example where functional programming reveals its strength. But Java is hardly a functional programming language, it’s just that some new java 8 apis are done this way.

As for readability…well it’s a matter of taste and habit… I don’t find it particularly readable nor unreadable…

Well, normally, on games, when you use a secondary thread is more for don’t stuck the main thread than for making the threaded operation faster. Here is where I differ the “multithreading” of “parallel” (but… is just a way of seeing things). Thanks for your aclaration of the strengths of functional programming (I think I mustn’t be aware about learning it any soon).

Object Oriented + Functional programming on a same language is just like mixing chinese with english, yes, you can talk chinenglish if you know both and you are great at languages, but, normally, even for these people is harder to speak/understand if you mix them. What I don’t like about adding functional programming to Java is that people will and is using it and, that, makes other people code to be less readable about what I just explained (it may be a taste and habit, but imo is more than that, I hope don’t, because I’m sure I’ll have to learn it sooner or later).

Beside the already said multithreading, lamdas usually shorten your code a lot. Less lines to maintain, and much less error prone once you are used to read the syntax.

public class User {
    int id;

    public int getId() {
        return id;
    }


    public void sortJava7() {
        ArrayList<User> users = null;
        Collections.sort(users, new Comparator<User>() {
            @Override
            public int compare(User o1, User o2) {
                return o1.getId() - o2.getId();
            }
        });
    }

    public void sortJava8() {
        ArrayList<User> users = null;
        Collections.sort(users, (user1, user2) -> user1.getId() - user2.getId());
    }
}

Also for me personally method references are one of the most used java 8 features. And unfortuantly also the one that can’t be compiled back to java 7. No more workaround when you needed to implement the same interface twice with different generic parameters, no more eventlistener interfaces.

I was actually a bit shocked that JME is still on Java 6, which died like 2 years ago. AFAIK you could use Java 7 for Android. So one would at least have access to nice things like diamond operator, try with resources, switch with strings, concurrency utils. I also have the feeling that annotation could in some places improve the developer experience with JME.
Things like

@AppState("WhatAnAppState")
public class MyAppState extends AbstractAppState {
    @Asset("Interface/Fonts/MyFont24.fnt")
    BitmapFont myFont;
    @Asset("Models/MyModel.j3o")
    Node myModel;

 ...

But I don’t know very much about game development and maybe that feels as wrong to game developers as it feels wrong to me being able the change the state of global constants (that Zero Vector pitfall, that every large scale server developer would shy away from as it can really lead to very hard to find bugs) or having access to lots of protected variables using common framework base classes. It is probably just a different world as you usually do not have to maintain a game after it is released - at least not for a long time.

Do you really think that sortJava8 is more readable than sortJava7?. As I said before, is like saying that speaking with mathematics is more readabla and easy to maintain than using english. You can represent the reallity with maths, but is easiest with words (yes, much more characters, but ridiculous easier). In this case, the Collections.sort used in sortJava8 can be readable, but never as like in sortJava7.

Imagine now that you don’t know what Collections.sort is and my accept as parameters. In the first case if you read the code you can see that you are using a sort function over a list and using a comparator, wich accepts two users and compare them by Id.
If you look at sortJava8 you see that Collection.sort is sorting the users, and then you pass two users and subtract their IDs, but what is that doing?.
In this case it may be obvious, you are sorting a list, what can be the next?, obviously, a comparison but not always is as easy.

It’s always needed the developer to name great their vars and methods but with lambda expressions is doesn’t matters, is just, things going to things (things → things).

About method references… Is just… useless?, just saving some characters to mix paradigms?.

(is for anyone else the reply layout totaly fuckedd as well?)

→ You think classical games.
But think bigger, for example a MMO or a Entity-Component system are natural matches for multithreading and for functional programming.

(In fact in a ES you naturally will write most stuff functinal)

About mixing it, it#s ntow worse than mixing in normal languages, at leawst as a german im used to have 50% english in my everyday work language. Also you can write purly functional in java, you dont have to mix it. Same as you can write purly procedual in java.

also sorry for any errors, but im writing blind here O.o due to the layouting problem.

yeah, layouting probblem also on my side

I can only speak for myself, but for me the java 8 code is more readable and maintainable than the java 7 version.

And regarding method references, Just look at the way the input system currently works, and then consider how it could work with method referencing.

http://wiki.jmonkeyengine.org/doku.php/jme3:beginner:hello_input_system

The whole AnalogListener, gone!, all “typo error” prone strings, gone!, the whole switch expression gone!

1 Like

Yep, I’m having the preview with a f12 tweak xD.

Is just that, I don’t want things gone!, I just want things verbose, easy to read, just for dummies, not making assumptions and heavy cerebral procedures (I’m a lazy one). I just never though java on that way, I’ve always liked java because it easy understanding when looking any code.

I’m just not so “pro”. I’m just a beginner on multithreading and I’ve never had a parallel need for improving performance so I can’t go against that :smile:

Once you get how to read the labdas, they are kinda easy to read as well, its mostly a thing of getting used to them.
→ Still i use near to none at all in my code, even tho it is functional.
Lambdas are a language feature, dont mix them up with the programming approach. You cen pretty easily use them in OO or not use them in functional.

(F12 doesnt work for me ):frowning:

It’s quite simple, for the text input and the preview add the style attribute with a default height, letting it just like here:

Text input:

<textarea id="wmd-input" class="ember-view ember-text-area" placeholder="Type here. Use Markdown or BBCode to format. Drag or paste an image to upload it." tabindex="4" style="height:200px">

Preview:

<div id="wmd-preview" class="cooked" data-bindattr-1984="1984" style="height:200px">

Well, you usually want things that bloat your code gone.


void callThisOnSomeEventAction();
//java 7
inputManager.addMapping("someEvent",KeyTrigger.X);
inputManager.addListener("someEvent", new AnalogListetener(){
  onAction(String event){
     if(event.equal("someEvent"){
          callThisOnSomeEventAction();
     }
  }
});

//java 8 could look like:
inputManager.addMapping(this::callThisOnSomeEventAction,KeyTrigger.X);

Sure i kind of agree that java 8 code is less readable if you are new to java, but if you hold to the usual conventions for choosing the names of your variables/methods you can make it quite readable.
Having less code is usually better. (not talking about lisp syntaxes here :stuck_out_tongue:)
And even more generalising, knowing FP is probably a requirement for any programmer in the future.

yep 200px works fine for me too