MapleScala

[Hilia]

You keep writing unnecessary things like keywords for constructor parameters.

class LazyNXFile(val buffer: ByteBuffer)

can just be

class LazyNXFile(buffer: ByteBuffer)

Aren't the unnecessary keywords just a preference of the coder?,Like in the Microsoft C# Roslyn compiler they use a lot of the unnecessary "this" 's even though Microsoft's code analyses says:"Nono you can remove that". Where as the coders say: "It is just what you prefer". Doesn't the same count for the example you shown? (Unless there is a performance impact)

EDIT:
(Example where they don't use "this" it:

You must be registered to see links

Example where they use "this"

You must be registered to see links

)

 

[Minike]

I just find it incredulous that anyone would be willing to have their server take longer to startup just to save a bit of hard drive space.

I can totally understand your argument, but I saw no need for a few seconds of increased performance in a process that should only happen maybe once a week.
But it is not like it saves much disk space and neither takes up much space in total, so this is totally arguable.

 

[Minike]

A few updates;

• You must be registered to see links
• You must be registered to see links
• You must be registered to see links

So basically the login server is almost finished except for the PIC

Spoiler

I also have added a database script for creation with a default account 'Admin' with password 'Test123'

 

[aaronweiss]

Aren't the unnecessary keywords just a preference of the coder?,Like in the Microsoft C# Roslyn compiler they use a lot of the unnecessary "this" 's even though Microsoft's code analyses says:"Nono you can remove that". Where as the coders say: "It is just what you prefer". Doesn't the same count for the example you shown? (Unless there is a performance impact)

The difference is that there's an actual idiom here. Having it actually explicitly declare val means that you'll have to stop to read it (the alternative option is var) instead of correctly assuming that it's immutable. It's also to match pattern syntax and construction syntax better.

A few updates;

• You must be registered to see links
• You must be registered to see links
• You must be registered to see links

Clearly, you took the criticism to heart. Your NX reader is still basically Java (for loops, and Iterable). You replaced things with Option, but you don't match on the options! It's still better because at least the ability to have no value now exists explicitly in the type system, and not just implicitly everywhere. You should seriously look into Seq and map, fold, et. al.

 

[Minike]

Clearly, you took the criticism to heart. Your NX reader is still basically Java (for loops, and Iterable). You replaced things with Option, but you don't match on the options! It's still better because at least the ability to have no value now exists explicitly in the type system, and not just implicitly everywhere. You should seriously look into Seq and map, fold, et. al.

I am not quite sure if this also applies for Scala, but it does for C#; using things such as '.foreach' instead of the default 'for loop' creates functions overhead, so I have the tendency to avoid them.

As for the Options, I prefer using the 'for' syntax for them as you could see them as an Iterable with either one or zero values and when requiring a default value 'getOrDefault' suffices.

 

[aaronweiss]

I am not quite sure if this also applies for Scala, but it does for C#; using things such as '.foreach' instead of the default 'for loop' creates functions overhead, so I have the tendency to avoid them.

Oh, man. "Functions overhead." This is rich. Thanks for the laugh, bud.

You're writing a functional language. You should use functional style. You're not going to notice any performance differences, and your code will be far easier to read. There isn't much of a reason to use Scala at all if you're just going to write it as if it's Java or C#.

As for the Options, I prefer using the 'for' syntax for them as you could see them as an Iterable with either one or zero values and when requiring a default value 'getOrDefault' suffices.

I meant there's cases where you have if-else statements with isEmpty being the condition. In those instances, you should be using a match. It's far cleaner. Also, please go read the docs for

You must be registered to see links

already and stop talking about or using Iterable in Scala. I've mentioned it several times now.

 

[Minike]

You're not going to notice any performance differences, and your code will be far easier to read.

Actually, unless some compiler magic is going on, which I doubt as I personally think it will behave somewhat like the C# equivalent (LINQ), thus causing minor performance loss, or large losses if you are using it incorrectly (e.g. unknowingly causing to many iterations)

I meant there's cases where you have if-else statements with isEmpty being the condition. In those instances, you should be using a match. It's far cleaner.

I dont think many people would use a 'switch case' statement in Java or C# when there are only 2 options (or actually, 1 option and a default). So I neither see they gain of matching everything, everywhere.
Though I do have a few cases where it might add to the clarity of the code, so I probably use a match there instead.

Also, please go read the docs for

You must be registered to see links

already and stop talking about or using Iterable in Scala. I've mentioned it several times now.

Here is the reason why I talk about Iterable, rather than Seq

Spoiler

 

[aaronweiss]

Actually, unless some compiler magic is going on, which I doubt as I personally think it will behave somewhat like the C# equivalent (LINQ), thus causing minor performance loss, or large losses if you are using it incorrectly (e.g. unknowingly causing to many iterations)

It won't. It's inconsequential.

I dont think many people would use a 'switch case' statement in Java or C# when there are only 2 options (or actually, 1 option and a default). So I neither see they gain of matching everything, everywhere.

None is not a default, and no, obviously not because switch statements only work on numbers and strings in Java. Match statements are more flexible and are used to destructure patterns. Match statements are the idiomatic way to do these things in Scala.

Though I do have a few cases where it might add to the clarity of the code, so I probably use a match there instead.

No kidding. It's not like I said that already.

Here is the reason why I talk about Iterable, rather than Seq

Spoiler

You're unnecessarily over-abstracting (as most lousy Java programmers do). Seq is for collections with a sequential ordering. NX files have a sequential ordering. At the very least, start taking advantage of the fact that Scala's Iterable provides functional goodies, too.

 

[retep998]

Actually, unless some compiler magic is going on, which I doubt as I personally think it will behave somewhat like the C# equivalent (LINQ), thus causing minor performance loss, or large losses if you are using it incorrectly (e.g. unknowingly causing to many iterations)

This is called premature-optimization. Please avoid it.
Never make claims about the performance of something until you've benchmarked it.

 

[Minike]

This is called premature-optimization. Please avoid it.
Never make claims about the performance of something until you've benchmarked it.

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.

 

[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.

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.