I still find streams far more difficult to teach to a new programmer than loops.
Java 8: No more loops
51–60 of 99 posts
Re: Java 8: No more loops
#52Earlier quoted context omitted.
I disagree. The benefit of having the standard terms is they are the same in every FP library you use. If you spend the time to learn and internalize them within one, it'll be the same in every language or library that implements them. I don't understand how map, filter, collect, reduce are obtuse or arcane.
Those aren't the worst offenders. I'm referring to curry, cadr, lambda, monad, etc. But map is confusing: it's also a data structure. "Wait, does map() create a new key-value dictionary?" Filter and collect are okay. Reduce is pretty arcane but tolerable, but the actual operation feels intuitively closer to "categorize" or "group." My point about math was cultural. Math seems to revel in having its own peculiar and o…
1. Map isn't "also a data structure", the data structure is a way to implement a mapping function. There is no conceptual difference between code and data (for an example, see http://en.m.wikipedia.org/wiki/Cons#Not_technically_fundamen...)
2. cadr is relatively easy, if you know your assembly (http://en.m.wikipedia.org/wiki/Car_and_cdr#Etymology) :-)
And math has locally defined terms because one cannot give every concept a unique short meaningful memorable name. That is no different in computer science, where 'integer' can include negative numbers or not, may or may not wrap around, can be any number of bits or potentially unlimited, may include minus zero, etc.
Re: Java 8: No more loops
#53why not use: public final class Article{ public final String title; public final String author; public final List tags; public Article(String title, String author, List tags) { this.title = title; this.author = author; this.tags = tags; } } Getters don't seem very useful on an immutable object.
If you ever want to change the implementation of Article, you'd break anyone that was using that part of your API. If you use getters, you can change your implementation without breaking the consumers of your API. For instance, let's say that you don't want to store the author's name as a string anymore, and want to store a reference to an Author object. If you have a getAuthor() method, you can change it from a simp…
So I think a fair question at this point is how often does that happen? To further inquire, how often does that happen in contexts that you don't control?
I'm sure that library/framework people need to worry about that. Most normal developers do not. For many cases Java objects like Article are just structs. They are static maps. Sure, in the example on the site there was a getTags that added some logic, but still, pretty much a struct.
Switching to either public accessor for mutable or immutable objects actually will stream line code. You might say that public mutators are bad; encapsulation and all that. For the most part little is actually gained in the majority of getter/setter code to necessitate their weight.
Heck, as per the JavaBean spec (a spec for making components to create drag and drop UIs by the way), you can't even have fluent APIs where the setter returns "this". It has to be void.
API stability has value. If you're a library, you probably want to do this just to be safe. But really for most imperative Java code it's just a lot of fluff for little value.
Re: Java 8: No more loops
#54Java's one of the worst language examples of using FP collections I've seen. Even with hindsight I still find this to be uglier and unnecessarily more verbose than it needs to be. E.g. same Example in Dart: class Article { String title; String author; List tags; Article(this.title, this.author, this.tags); } Article getFirstJavaArticle() => articles.firstWhere((x) => x.tags.contains("Java")); List getAllJavaArticles(…
And your example doesn’t even tell what it’s doing.
I’d have to look up what .expand, .where etc means, while Java just uses the standard FP names that every CompSci student knows.
Re: Java 8: No more loops
#55[deleted]
No its the price you pay, when you improperly implement generics and do not have polymorphic functions. In other words its the price you pay, if you ignore the developments in computer science in the last 10 years and invent a crippled terrible language in 1995 (roughly the same time OCaml came out) and push it onto the world with success, because you are a big corporation. At the point they introduced generics, ther…
>actually for historical reasons its called fmap, but nevermind
Heh, reading that reminded me of this blog post I wrote a while ago:
fmap(), "inverse" of Python map() function: http://jugad2.blogspot.in/2012/10/fmap-inverse-of-python-map...
And someone I know also commented on it and gave what is probably a better version, called compose.
Re: Java 8: No more loops
#56Earlier quoted context omitted.
If you ever want to change the implementation of Article, you'd break anyone that was using that part of your API. If you use getters, you can change your implementation without breaking the consumers of your API. For instance, let's say that you don't want to store the author's name as a string anymore, and want to store a reference to an Author object. If you have a getAuthor() method, you can change it from a simp…
And this is one of the major reasons why Java is regarded as verbose. There's a simple solution (have the compiler transparently rewrite references to x.foo to x.getFoo / x.setFoo and transparently add getFoo/setFoo - the JVM inlines (trivial) getters and setters anyways) and yet Java, in the interests of "transparency", doesn't allow it. And their justification fails. Sure, currently if you read x.foo you know that…
That's one of my favorite things about Swift. I can do, for example:
// version 1
var author: String
// version 2
var author: String {
get {"\(authorFirst) \(authorLast)"}
}Re: Java 8: No more loops
#57Here is another example, porting a spellchecker from Python to Java 8.
https://github.com/jmoy/norvig-spell/blob/master/java/src/ma...
Re: Java 8: No more loops
#58Earlier quoted context omitted.
MS did the right thing. A huge barrier to FP adoption is the unnecessarily obtuse terminology. In playing around with FP languages I often find myself having to re-look-up basic syntax because the terms are simply so obtuse that they won't "stick" in my head. I think it comes from FP's rooting in mathematics, and math is itself unnecessarily arcane.
I disagree. The benefit of having the standard terms is they are the same in every FP library you use. If you spend the time to learn and internalize them within one, it'll be the same in every language or library that implements them. I don't understand how map, filter, collect, reduce are obtuse or arcane.
Interesting enough, my academic background was mostly FP based, but my first heavy industry use of the terms was with the LINQ libraries. I have since had lots of experience with the more academic terms and can pretty easily translate back/forth with no problem. Except for filter. I routinely forget if it is "filter in" vs "filter out". It is easy enough to look up, but I never had that problem with LINQ's "where".
Re: Java 8: No more loops
#59Java's one of the worst language examples of using FP collections I've seen. Even with hindsight I still find this to be uglier and unnecessarily more verbose than it needs to be. E.g. same Example in Dart: class Article { String title; String author; List tags; Article(this.title, this.author, this.tags); } Article getFirstJavaArticle() => articles.firstWhere((x) => x.tags.contains("Java")); List getAllJavaArticles(…
And your example doesn’t even tell what it’s doing. I’d have to look up what .expand, .where etc means, while Java just uses the standard FP names that every CompSci student knows.
Where makes sense if you think of it from a SQL perspective which I think has more widespread use than the corresponding FP terms (ie lots of developers don't have a CompSci background, but few of them haven't used trivial SQL).
Re: Java 8: No more loops
#60So Java is trying to slowly turn into Haskell.
More like it is trying to catch up with C#.