MapleScala

[aaronweiss]

I am well aware of this, as you basically end up 'reinventing the wheel and make it square'

And yet you did it anyway.

The thing I want to prevent though, and trust me I have seen this happening a lot of times in other people their code, is to create one humongous psuedo-query just because it looks 'fancy'.

It's not about looking fancy. It's about having idiomatic code that's concise and easy to understand (particularly for people who actually know the language).

This while a mere combination of a filter and foreach could have the same result.

It won't if you're not stupid about it. Also, you should favor map and fold to foreach. They're generally what you want.

So while being 'fancy' you might have accidentally looped thrice over twice the amount of data.

This is still premature optimization. You're just being stupid if you do this because it means that you could've done the task in one map/fold/etc. This is like complaining about the fact that you can write three for loops one after the other that are all fundamentally maps and could be done in one for loop.

(please save me the part of 'you should know what each function does')

Why? You should. Saying save you that doesn't change the fact that this is an incredibly relevant reality. You should know what common standard library functions do. That's part of what makes them idioms.

So personally I think things such as 'foreach' is just abusing the functional syntax as it hurts the clarity of the code.

It's not abusing functional "syntax". It's actually using functional style. Higher-order functions like map and fold are the bread and butter of functional programming. Using a functional programming language without them is absolutely ludicrous.

[Minike]

And yet you did it anyway.

I think we have been over this a few times already?
If you are going to point out that I made some mistakes, please be constructive so can actually change it and learn something from it.
Now you are just putting loads of effort in singlehandedly bashing arguments in a post that was not even in a reply to you.
Maybe it is a good way for you to blow of some steam or something, but you are simply just wasting my time by just having to read this.

It's not about looking fancy. It's about having idiomatic code that's concise and easy to understand (particularly for people who actually know the language).

You would almost think I actually do not know the language and thus try to prevent creating to much of mess.

It won't if you're not stupid about it. Also, you should favor map and fold to foreach. They're generally what you want.

Oh thank you, I instantly understood what I have been doing wrong the whole time.
Oh wait, it did not help at all.

This is still premature optimization. You're just being stupid if you do this because it means that you could've done the task in one map/fold/etc. This is like complaining about the fact that you can write three for loops one after the other that are all fundamentally maps and could be done in one for loop.

Yeah, so basically the opposite of what I (tried to?) explain.
Why use multiple maps, folds and filters while a single for and filter does what you want.
People do this because they think it looks 'fancy', yet I do not have enough knowledge to simplify it enough without using the for syntax.

Why? You should. Saying save you that doesn't change the fact that this is an incredibly relevant reality. You should know what common standard library functions do. That's part of what makes them idioms.

Hmm, if there only was of telling somebody I already fully understood that in the first place so they wont come up telling me exactly what I tried to avoid them telling me.

It's not abusing functional "syntax". It's actually using functional style. Higher-order functions like map and fold are the bread and butter of functional programming. Using a functional programming language without them is absolutely ludicrous.

Also, you should favor map and fold to foreach.

Thank you fine sir, by actually figuring out what I tried to say by contradicting yourself.

[retep998]

I am well aware of this, as you basically end up 'reinventing the wheel and make it square'
The thing I want to prevent though, and trust me I have seen this happening a lot of times in other people their code, is to create one humongous psuedo-query just because it looks 'fancy'.
This while a mere combination of a filter and foreach could have the same result.
So while being 'fancy' you might have accidentally looped thrice over twice the amount of data. (please save me the part of 'you should know what each function does')

So personally I think things such as 'foreach' is just abusing the functional syntax as it hurts the clarity of the code.

Using functional style for things like iteration can actually be very efficient. For example, Rust uses functional style iterators and yet, thanks to optimizations, it runs just as fast as a carefully crafted C-style loop. In fact, when writing nx-rs, mapping and folding over nodes in Rust turned out to be even somewhat faster than the C++ version's for loop.
Functional style is not slow, but an implementation of it can be. Hence why I said to benchmark it first.

[aaronweiss]

I think we have been over this a few times already?
If you are going to point out that I made some mistakes, please be constructive so can actually change it and learn something from it.

The entire rest of the post was explaining what you did wrong.

You would almost think I actually do not know the language and thus try to prevent creating to much of mess.

You're not learning the language by avoiding its mechanics. You don't need to write perfect code the first time, or even good code the first time, but if you actually want to learn the language, you should be making an active effort to actually learn how the language is used and what the sort of code that people expect is. If you need some lints, I'm sure you can find a Scala linter online. General rule of thumb though: You never need to chain maps because instead, you could map the composition of those functions. Similar rules apply to other higher-order functions.

Oh thank you, I instantly understood what I have been doing wrong the whole time.
Oh wait, it did not help at all.

What you've been doing wrong, as I've said before, is that you've been writing entirely object-oriented code in a hybrid language that's main strength is its ability to use functional idioms. The clarification I was adding was that while you keep responding and talking about foreach, in most cases, you'd actually want to use a map or fold instead of a foreach. If you didn't refuse to listen at all, this would actually prove a useful piece of advice.

Yeah, so basically the opposite of what I (tried to?) explain.
Why use multiple maps, folds and filters while a single for and filter does what you want.

My point exactly is that you can use a single map or fold instead of a single for loop. Your complaint about using multiple maps is akin to saying "For loops suck because you could use three of them to implement something you could do in one for loop." Bad programming isn't a reason not to use something, and it's not a reason not to learn how to do something useful.

People do this because they think it looks 'fancy', yet I do not have enough knowledge to simplify it enough without using the for syntax.

You don't pull the knowledge out of thin air. You learn how to write good code using higher-order functions by doing it, not by totally ignoring it as a language feature. Anybody who's writing higher-order functions because they look "fancy" is probably not a very good programmer, but I think you're wrong that this is the general trend. People write higher-order functions because they're an effective way of encapsulating common, but somewhat complex semantics into simple, consistent idioms.

Hmm, if there only was of telling somebody I already fully understood that in the first place so they wont come up telling me exactly what I tried to avoid them telling me.

If you really knew this already, you wouldn't have tried to put that point as an aside. The necessity to understand standard library functions is important, and incredibly relevant in this discussion.

Thank you fine sir, by actually figuring out what I tried to say by contradicting yourself.

I did not contradict myself at all. I said you should use map and fold over foreach, and I also said that map and fold are the bread and butter of functional programming. Both of these things are true, and both of these things are mutually consistent. I'm not sure where exactly you think I contradicted myself, but you're clearly lacking in English literacy. So, maybe you should work on that before you start trying to work on learning how to actually program.

- - - Updated - - -

Using functional style for things like iteration can actually be very efficient. For example, Rust uses functional style iterators and yet, thanks to optimizations, it runs just as fast as a carefully crafted C-style loop. Functional style is not slow, but an implementation of it can be. Hence why I said to benchmark it first.

For the record, Scala, Haskell, and any other reasonable functional language perform similar optimizations. There's virtually no performance difference between one map and two maps. Any performance difference is so negligible that other factors (in Scala's case, especially the GC) will outpace it. Go ahead, try it yourself.

[Zygon]

This is called premature-optimization. Please avoid it.

Says the king of premature optimizations.

Love you Peter.

[SuperLol]

The entire rest of the post was explaining what you did wrong.

Sure, but you are being extremely condescending and hardly constructive. The first language I learned and was proficient at was a flavor of Lisp (Scheme) and you should have seen the Java code I wrote a little later as I began to pick it up. It takes some time to get out of the fold-left/right or reduce mindset, as well as using tail recursion instead of loops when you go from functional->object (note that I am not at all familiar with Scala, these concepts may not apply here). This guy is a C# programmer and has never tried any functional. The language difference and then code design is enormous that any beginner would not be able to do it well. At least Scala looks somewhat like C#... scheme looked nothing like Java.

The guy said he didn't know how to use fold. Show him how to use fold then. You're right, he won't know how to do fold with pure theory. It takes usage to actually learn it. The thing is you're basically doing the same thing as people going to /f427/ and posting on the release threads that they didn't write their code right.
@Minike
I'll run by a few basics with you. Disclaimer: has been quite a while so my memory could be foggy
Note that my names of the functions may be wrong because I only know general functional concepts and have no clue how Scala works. From my knowledge of fold in functional languages (aka accumulate), it's basically a "apply this new function to all and save previous value" kind of function. Reduce is very similar to fold but with a few differences. There's also a function called map which is also some "apply all to" function. It will do the function for every element in the list, which is pretty cool. There's also a function called filter, which is like a coffee filter that applies a condition to all elements and returns the ones that are true for that condition.

[Minike]

I'll run by a few basics with you. Disclaimer: has been quite a while so my memory could be foggy
Note that my names of the functions may be wrong because I only know general functional concepts and have no clue how Scala works. From my knowledge of fold in functional languages (aka accumulate), it's basically a "apply this new function to all and save previous value" kind of function. Reduce is very similar to fold but with a few differences. There's also a function called map which is also some "apply all to" function. It will do the function for every element in the list, which is pretty cool. There's also a function called filter, which is like a coffee filter that applies a condition to all elements and returns the ones that are true for that condition.

Thank you for this, I already tried finding the C# LINQ equivalents of each function, so I can confirm a few with this.

Scala	C#
filter	Where
map	Select
fold	Aggregate
reduce	Aggregate

Aggregate is a little bit of a weird story, as it is a little bit of a multipurpose C# thingy

[Shmoconut]

Hey dude, what's your planned actor architectural design? Any reasoning behind making each client an actor? I think it's interesting and has its merits but I want to know your reasoning too.
Good luck on your project!

[oxysoft]

Hey dude, what's your planned actor architectural design? Any reasoning behind making each client an actor? I think it's interesting and has its merits but I want to know your reasoning too.
Good luck on your project!

it probably resembled something from java/c# seeing as the author has no desire to learn and apply the idioms and principles of scala and functional programming beside the syntax

he is merely translating from one syntax to another

[Minike]

it probably resembled something from java/c# seeing as the author has no desire to learn and apply the idioms and principles of scala and functional programming beside the syntax

he is merely translating from one syntax to another

I bet you did not even think of reading the actual source.
I wonder why people even bother to post when they did not bother to read the source.

Anyhow, Actors used to be a part of Scala itself and while there is a .NET version available, I have never used it or seen anyone using it.

So even if I wanted to, I could not 'merely translate from one syntax to another'

Hey dude, what's your planned actor architectural design? Any reasoning behind making each client an actor? I think it's interesting and has its merits but I want to know your reasoning too.
Good luck on your project!

Personally I think it is a good thing to split up the servers and the clients, because in this way it would be impossible for the client to affect the server.
So it really just is a piece of fault tolerance.

Though this is also how the Akka documentation advised on how to use the TCP system so I sticked with it.

So basically the server Actors will try to restart when something occurred they could not recover from while the client Actors will simply be killed to prevent anything from escalating.

[Shmoconut]

Personally I think it is a good thing to split up the servers and the clients, because in this way it would be impossible for the client to affect the server.
So it really just is a piece of fault tolerance.

Though this is also how the Akka documentation advised on how to use the TCP system so I sticked with it.

So basically the server Actors will try to restart when something occurred they could not recover from while the client Actors will simply be killed to prevent anything from escalating.

I wanted to write a MapleStory server in Erlang but never got around to it, so I'm looking forward to seeing your progress because it is naturally going to be architecturally similar. Making each client an actor seems like the right thing to do. With that said, here are some considerations:

Don't really get what you mean by client affecting the server, but the main benefit I see in making each client an actor is to have the power to persist client state even if a server fails. You can look into making each client supervise its server actor, so if a server fails then the character data can be persisted and the client session can be automatically migrated to a functioning server. Akka has some cool health checking functionality, but I don't know if it's possible to have a many-to-one supervision scheme, or if it's even necessary - maybe there's a simpler way. I'm not overly familiar with Akka.

Also I looked through your code a little bit (I like it when things are on Github) and it seems like you never keep characters in memory? Every time a user gets its character it re-constructs one from the database. If I'm not wrong, then perhaps you should look into changing that.
It seems like you have two actors per player (one as the Client, one unnamed representing the raw tcp connection between player and server), but I guess that doesn't really matter.

Like others have said, you really should use pattern matching on Options and similar things instead of for loops though, it's more readable and is considered good practice.

Have you thought about how you are going to implement cross-server messages? Right now I don't think you keep track of all clients in the server, so you should probably think about how you would implement a super megaphone (or buddy/guild chat, etc) because that's probably a design decision that needs to be made early on.
It seems like this is where there is added complexity by making each client its actor.

[Minike]

Don't really get what you mean by client affecting the server

Actually, you said exactly what I ment;

but the main benefit I see in making each client an actor is to have the power to persist client state even if a server fails.

Also I looked through your code a little bit (I like it when things are on Github) and it seems like you never keep characters in memory? Every time a user gets its character it re-constructs one from the database. If I'm not wrong, then perhaps you should look into changing that.

Yeah, I havent had any need yet in for persisting the character in the memory, but I will probably story it within the Client after it migrated away from the loginserver

It seems like you have two actors per player (one as the Client, one unnamed representing the raw tcp connection between player and server), but I guess that doesn't really matter.

As far as I am aware I only wrap the Client (which directly is the TCP actor) in a RoundRobinPool, which the documentation suggested for the fault tolerance.

Like others have said, you really should use pattern matching on Options and similar things instead of for loops though, it's more readable and is considered good practice.

I actually use for loops when I have no need for the None case and already checked the None case in previous code. So it is only for unwrapping the value and ensure it could never be None (as alternative to just using .get). Adding a None case would be redundant in my opinion.

Have you thought about how you are going to implement cross-server messages? Right now I don't think you keep track of all clients in the server, so you should probably think about how you would implement a super megaphone (or buddy/guild chat, etc) because that's probably a design decision that needs to be made early on.
It seems like this is where there is added complexity by making each client its actor.

Basically the same story as with the characters, I tend to write code only when I actually need it even though I already thought out the process in the first place (it is not like I am writing everything blindly). I will probably store all clients per server instance and have the client message the server, which in turn messages all clients.

The nice thing about this Actor system is that you could make relative large changes to the system as a whole with only minor changes in code.

[aaronweiss]

Sure, but you are being extremely condescending and hardly constructive.

Am I being condescending? Sure. I think it's plenty constructive though. I gave him examples of things that could be done better, and I told him specific tools for him to research to write better code in Scala.

The guy said he didn't know how to use fold. Show him how to use fold then. You're right, he won't know how to do fold with pure theory. It takes usage to actually learn it. The thing is you're basically doing the same thing as people going to /f427/ and posting on the release threads that they didn't write their code right.

I don't think it's my job to write tutorials for Scala on this forum. There's plenty of guides that go into detail about how to use higher-order functions. It's a short web search away. If he can't learn how to search the web properly, there's not much I can really do for him.

[Snakeday]

aaronweiss: Yes there were some constructive points but overall your comments were rather toxic. For example you have yet failed to mention that not all scala users/advocates actually favor a highly functional style, Scala is a multi-paradigm programming language. Feel free to treat it as such.

retep998: You are making the common mistake of misclassifieing something as premature optimization. If I have a given problem and can choose between two algorithms of which I know that one is faster and both are equally readable I should always choose the faster one. Kevlin Henney talks about this here: https://www.youtube.com/watch?v=w3JkpQAbTA4&t=27m I personally find it's a very good talk on the topic.

That said I'm a huge fan of writing code to get things done and not being afraid to revise the code later when I learn newer things about the language/libraries/frameworks. I'm also excite about a pserver project in scala. Try to go on and do not get distracted by the toxicity.

[retep998]

retep998: You are making the common mistake of misclassifieing something as premature optimization. If I have a given problem and can choose between two algorithms of which I know that one is faster and both are equally readable I should always choose the faster one. Kevlin Henney talks about this here: https://www.youtube.com/watch?v=w3JkpQAbTA4&t=27m I personally find it's a very good talk on the topic.

OP was expressing uncertainty regarding the performance of fancy iterator stuff, like filter and foreach, compared to handwritten loops. Since that difference alone is not an algorithmic difference, and I know from personal experience that iterators can be implemented very efficiently (see Rust), I therefore classified it under premature optimization. Now if OP did benchmark the various techniques and get some numbers to demonstrate that iterators are significantly slower than the equivalent handwritten loop, then that optimization would no longer be premature.

EDIT: Whoops. Didn't realize this was a different person. Fixed.