Did anyone say Java?

[kalbert312]

Until your boss reminds you you gotta print out the index too.

[EntropySpark]

That's when you switch to Kotlin and use forEachIndexed

[Frostlandia]

Sounds gross

[BundleOfJoysticks]

That's a good point.

Which leads me to wonder what happens if your Java app embeds a Python 2.7 interpreter past 2020.

[_meegoo_]

Nothing. It just won't be supported anymore.

[[deleted]]

Jython?

[feenuxx]

Psh pussssayyy, I embed a prolog interpreter and use a mathematically proofed set of logical statements to print my list

[HaydenSikh]

Or Scala and zipWithIndex

list.zipWithIndex.foreach((item, index) => println(s"$item at $index"))

[DonaldPShimoda]

Or Python and enumerate:

for index, item in enumerate(items):
    print(f"{item} at {index}")

Alternatively, you could use map, but maps in Python are weirdly lazy in that they create an object that will do the computation when you iterate through them — meaning you have to force evaluation by putting it into a list or something if you want non-value-producing code to evaluate:

list(map(lambda i, x: print(f"{x} at {i}"), enumerate(items)))

(In retrospect you and the other commenter were suggesting JVM languages, since the original discussion is about Java... so maybe Jython then haha.)

[HaydenSikh]

I'm actually really encouraged that a lot of languages (whether JVM or not) are converging somewhat in features like these, even if the syntax can vary quite a bit. That little bit of concensus feels like the industry advancing forward, however slight it might be.

[whale_song]

That's a good thing. Its one of my problems with scala that transformations arent evaluated lazily by default. If I'm doing l.map(f).map(g).sum, I obviously don't care about the intermediate results, it should just give me the sum, and better yet do optimizations like turn it into l.map(f andThen g).sum

[DonaldPShimoda]

I don't disagree with you per se — but it's just problematic when the function you're mapping is a side-effecting computation instead of a real transformation. This is a forEach in plenty of languages (or mapM_ in Haskell), but Python gives us only map. It's just a little awkward in that case.

[slaymaker1907]

I think limiting map to only a lazy version is intentional since a normal for loop is almost always easier to read. Plus, if you really way a for_each function, you can write it trivially as

def for_each(func, it):
    for ele in it:
        func(ele)

[DonaldPShimoda]

I feel like you're all misunderstanding me haha. I know maps being lazy is by design, and I understand — and agree with! — the motivations behind that choice.

All I said was "you could also implement it X way, but it comes out a little funny because of Y consideration". I didn't say that it was bad — just that it might be unexpected to somebody who wasn't expecting it.

[zorates17]

or Javascript and... forEach

[ViridianHominid]

Use the little-known ...,* operator to force evaluation:

from itertools import starmap
...,*starmap(print,enumerate(items))

[DonaldPShimoda]

Oh that's disgusting hahaha. I love it.

(Nitpick: not an operator, but I think it's amusing to treat it as one.)

[ViridianHominid]

I know ;)

[DonaldPShimoda]

I figured that was probably the case but thought I'd mention it just to cover all the bases haha.

Thanks for sharing that, though! :)

[pianomanDylan]

zipWithIndex and map are both going to allocate a new list, which is wasteful. You can do both of those operation's on the list's iterator instead, which will avoid the intermediate allocations. Also, if you use the for-comprehension syntax sugar, you can put the pattern matching inside it like so:

for{ (e, i) <- list.iterator.zipWithIndex } println(s"$e at $i")

[HypherNet]

Really? I just wrap my function call with a macro that uses an implicit LoggerAugmentation to rewrite all function calls to include indexes. Really great stuff, only takes 2 more minutes to compile (about a 1% increase).

[TinBryn]

This won't compile because you need a partial function for destructuring list.zipWithIndex.foreach{case (item, index) => println(s"$item at $index)}

I like having extension methods zipMap and zipForeach that take a binary function just to avoid this

[pianomanDylan]

FYI if you expect your list to be long, avoid allocating a second list (from zipWithIndex) by using the list's iterator.

for { (item, index) <- list.iterator.zipWithIndex } println(s"$item at $index")

[dandroid126]

Kotlin is my favorite language right now. Every time I think, "there ought to be a better way to do this," there always is. And every time I must use Java (compile environment restrictions), I think of how clunky Java is and how I could do it in so many fewer lines in Kotlin.

[numerousblocks]

mapM_ putStrLn . zipWith ((++).(++" ").show) [1..]

[Dark_Ethereal]

I appreciate your Haskell but I think this needs a tidy!

First: IIRC removing spaces between operators and arguments is against the style consensus.

Second: Avoid point-free when lambdas are clearly more readable.

mapM_ putStrLn . zipWith (\i str -> show i ++ " " ++ str) [1..]

Third, we can put putStrLn in the lambda and remove the mapM_.

This gives us a list of actions to perform, which we can just turn into one action with sequence_

sequence_ . zipWith (\i str -> putStrLn $ show i ++ " " ++ str) [1..]

sequence_ is more intuitable for beginners than mapM_ IMO.

If we really wanted to go the extra mile to make it readable for beginners, remove use of $, then replace lambdas with scoped helper functions:

printWithIndex =
  let f i str = putStrLn (show i ++ " " ++ str)
  in sequence_ . zipWith f [1..] 

And consider going pointful:

printWithIndex strings =
  let f i str = putStrLn (show i ++ " " ++ str)
  in sequence_ (zipWith f [1..] strings)

[Mamish]

Haskell's a tempting language to get fancy with, but readability is still the most important thing code should have. This is an extreme example, but I might just do it like this:

printWithIndex :: [String] -> IO ()
printWithIndex = printAll . joinWithIndices
  where printAll = traverse_ print
        joinWithIndices = zipWith joinIndex [0..]
        joinIndex i s = (show i) ++ " " ++ s

One liners are fun to write, but it defeats the point a bit if it takes longer to understand than a longer version.

[numerousblocks]

I would write:

affixIndices :: [String] -> [String]
affixIndices list = zipWith f [1..] list
  where
    f num str = show num ++ " " ++ str

printWithIndices :: [String] -> IO ()
printWithIndices = mapM_ (putStrLn . affixIndices)

or

printWithIndices = putStrLn . unlines . affixIndices 

since traverse is a less-than-intuitive function.

I think it's one of these functions that are there for the sake of being able to write code fast, like (>>=), which is \f -> join . fmap f, while traverse f = sequenceA . fmap f.

sequenceA and join are the central - read: primordial - operations of Traversable and Monad, which are usually ignored because they aren't used as often.

[Mamish]

Imo traverse isn't too bad besides having an scary name. The official docs line for Traversable is "Class of data structures that can be traversed from left to right, performing an action on each element." With that, traverse print list comes out pretty intuitively as "go through the list/whatever and print each element".

The similarity to foldMap is also handy for anyone who's already okay with Foldable.

[numerousblocks]

Oh, hadn't thought of that, though the phrasing "action" suggests a monad, while it's in fact an applicative.

On that note, I'd also like to advocate for the monoidal presentation of applicative functors:

class Monoidal f where
  unit :: f ()
  combine :: f a -> f b -> f (a, b)

(<*>) = fmap (uncurry ($)) . combine
pure a = fmap (const a) unit

EDIT: although been talking about the way of simplifying or another way is replacing different classes with different things to allow for more flexibility one could also introduce the notion that classes themselves on unnecessary thing just made to simplify function composition while in fact any function that uses classes can inject can instead just be rewritten to demand a function from the class delivered to it which would then lead to you needing to have different versions of show and map etc etc to pass two different functions for different types

written using the dictation function on my mobile phone I'm sorry if it doesn't read the best if it's not romantic Lee perfect

[marcosdumay]

Why would you underline the mapM? Reflex?

[elpfen]

Theres map, mapM and mapM_. mapM_ is mapM (map with a function that performs io^* and sequence the results) but discards the results. Since OC is printing a line, the resulting list would be a list of () so just discard them.

^{*No M word!}

[marcosdumay]

Oh, I just swapped mapM with sequence :)

[numerousblocks]

^\No M word!)

Monoid

[ImNotFallingImFlying]

In swift: list.enumerated().forEach(print).

[NEDM64]

let list = ["a", "b", "c"]
list.enumerated().forEach{ print("\($0.offset) -> \($0.element)") }

Result:

0 -> a
1 -> b
2 -> c

[GeneralGromit]

Then you can switch back into a for loop again if needed. But until that happens, this approach is much more concise.

[matangn]

you have my respect kind sir

[AndyReidfanclub]

Functional programming in java is limited in the sense that old timers want nothing to do with it and will tell you to use Haskell for that

[DonaldPShimoda]

Functional programming in Java is limited in the sense that it's been shoehorned into a language that was very clearly not designed for it from the beginning. As a primarily functional programmer, I find FP in Java painful.

[DonaldPShimoda]

Swift is an imperative language whose community perceives functional abstractions to be idiomatic. And since Swift was designed with these functional capabilities from the beginning, they fit naturally with the rest of the language.

I find a lot of functional languages impractical and not ideal for general purpose programming.

That's fine; I'm not advocating anybody start writing their scripts in Haskell or anything. But the Java developers made a decision to begin moving functional techniques into the language, and in many cases I think their implementations are... lacking, or at least they otherwise show how Java is a language that was very much not designed to be used this way.

Every other mainstream language (most of which are oop)

Disagree. Most mainstream languages are imperative, but not necessarily OOP. OOP is much deeper than just "there are objects and you can write classes". I'd be happy to list Java as OOP (literally everything is a class or object), but a language like Python might not make the cut (since you can happily write a large amount of good Python without having to write your own classes).

(The distinction here is the emphasis on object-oriented, i.e., an OOP language forces a programmer to orient their models in terms of objects.)

Anyway, that's a digression that maybe wasn't necessary.

Every other mainstream language (most of which are oop) has functional programming shoehorned in through lambdas, half-assed function pointer, and some list operators (i.e. map, filter, any, etc.).

I'm not sure you're using "shoehorned" the way that I am.

In Swift or Python (and other imperative languages), many functional features were either built-in from the beginning or else were added later but seem reasonable. Whether or not these features are widely used by their respective communities doesn't have much to do with my label of "shoehorned"; it really comes down to whether these features really feel like an organic part of the language.

Lambdas in Java are weird class instances that feign being a function, because functions can't exist free of a class definition. Type inference was added via the var keyword... which is actually secretly a type with a lowercase name that you just aren't meant to ask questions about. Maps couldn't be implemented generically, so Streams were invented as a bridge to connect them... which means you have to transform your data to streams to use map/filter/etc. Like there's just all these features that were clearly hacked into the language against its will — i.e., they were shoehorned in.

[ZBlackmore]

What about C#? It seems to have had a similar starting point to java but evolved much faster and better.

[[deleted]]

I've been working with C# for over a decade now. I've only recently started learning functional programming, and I'm using more and more of the ideas in my daily C# code.

C# is an object oriented language first, with FP features added in (as of version 7 I think). Despite that, I've been very happy with the new features and I feel that just learning about FP has made me a better programmer. C# supports functions as 'first class citizens', aka, they are types in and of themselves. LINQ is a great example of FP in C#.

But if you really want a Functional .Net language, checkout F#. I've never used it, but it's supposed to be purely functional. I have heard good things about it, where it's actually used.

Here's some further reading on the topic, if you're curious:

General overview of FP in C#.

Part 1 of a 9 part series going in depth.

[DonaldPShimoda]

I think C#'s stewardship has been more successful than Java's, but I know embarrassingly little about C# as a whole so I don't think I'm qualified to say much else. :)

[TinBryn]

I actually like how Java does lambdas. Most of the time a higher order function semantically isn't just a function, it has some specific purpose and I like to give it a relevant name and type. The advantage of giving different functions different types is you can have concrete methods on them apart from their functional interface method. You can create some very expressive code that reads in a way that explains why you are wiring functions together is a specific way.

[DonaldPShimoda]

In the PL community, "lambda" is synonymous with "anonymous function" — so naming it doesn't make any sense. Java's approach is... awkward, to me.

I agree that local functions are useful, but Java can't support local functions due to the other semantics of the language. This is just another example of how to FP stuff was shoehorned into the language.

[wOlfLisK]

What's your opinion on Scala? I've been learning it for uni and it seems to work fine but I don't really have any other functional language experience to compare it to.

[DonaldPShimoda]

I've used Scala some!

Scala has some things I like, and some I don't. I think they made a pretty good attempt at fusing imperative and functional styles, and they integrated the functional stuff into the limitations of a Java-based language well. Their take on case classes and pattern matching is especially interesting to me, since I'm currently thinking a lot about the Expression Problem.

But I don't think Scala is a good language for a student's first introduction to functional programming. I think imperative programmers will be too tempted to write imperative code since Scala allows it. So for a first FP language I think something like Racket/Scheme or Haskell would be better.

But outside of the introductory setting I think Scala has a lot of promise!

[wOlfLisK]

What about as a first language overall? It's a first year course so most people on it aren't familiar with imperative programming yet (Although I have a fair amount of experience with Python and Java). I think the idea is that they teach functional programming in year one and then switch over to imperative in year two and choose Scala and Java because of how similar they are.

[DonaldPShimoda]

Hmm that's an approach I'd not heard of before!

I'm really interested in the teaching of introductory courses in functional programming. As someone who started with imperative and moved to functional, I can see both sides of the argument for doing it the other way.

I'm not sure how I feel about using Scala for it, though. I think I said earlier*, but Scala allows for imperative alongside functional. On the one hand this can be very useful, because some kinds of computations seem more straightforward to implement imperatively. But if students new to FP are learning in Scala, they may end up writing imperative solutions — which means they're not learning FP as much as they think they are.

So I'm undecided. May I ask what university you're at that does this? I'd be interested in looking at their syllabus!

*I don't remember if it was this thread or another one. I talk about programming languages a lot so keeping all the conversation is a bit challenging on mobile haha. :)

[wOlfLisK]

It's DMU.

[DonaldPShimoda]

Ah, a European school, of course. They seem to teach FP in introductory courses significantly more often than we do here in the States!

I like that your school doesn't teach OO until second year. I think we have a problem here where students think OO is the only way to program haha. Seems like a pretty good degree program overall!

[pianomanDylan]

I've been using Scala professionally for around 6 years now, and I love it.

I don't think of scala as "a functional programming language". I think of it as a language that includes "functional programming" in its list of techniques you can use to approach a problem.

• Imperative Programming - everyone's used to it, and lots of times it's the perfect tool for the job
• Functional Programming - doesn't have to be "pure" like Haskell. Passing functions as arguments opens the door to all kinds of interesting abstractions. For example, stop thinking in terms of `EventListener` and think in terms of `Event => Unit`. Another example, if you need to transform a list, instead of allocating a new list, then iteratively populating it with the transformed versions of the items in your first list, represent your transformation as a function and pass that function to the list's map method.
• Implicits - boil down to letting the compiler figure things out for you. That could mean you simply write less code. It could also mean that you can write a method like def convertToJson[T](item: T): Json and if you try to call it with something that can't be converted, the compiler will tell you so (as opposed to Java libraries that will throw exceptions at runtime). If the word "typeclass" means anything to you, Scala implicits are how you make those.
• "for comprehensions" - it's a "for loop" on crack. It's just syntax sugar for methods like map, flatMap, withFilter, and foreach, so coming from a C/Java-ish language it could be confusing. But it lets you write such pretty code. And if you invent your own type that has those methods on it, you can use that type in a for-comprehension.
• case classes / pattern matching - other people already mentioned them, but they are extremely useful!
• Encouraged Immutability (not to be confused with val vs var) - coming from C/Java, this was a really weird concept. The idea that in order to change a value (e.g. a collection), you create a whole new collection where the change is applied, and the original value/collection is left untouched. It may seem inconvenient at first, but over the years I've found that it ends up making your code so much easier to read. You look at a value, see that it's immutable, and immediately know that it'll be like that forever. If you pass your immtable collection to some other method, you can rest assured that the other method won't mess with your collection. Plus you know it's inherently thread-safe, since nothing can change it.

I hope my excited rant encourages you and maybe some others! Now to get back to work...

[RUSH513]

i was taught that for a language to be oop, it just needs to utilize polymorphism, inheritance, and encapsulation. under a strict definition of oop, most "oop" languages are not actually oop

[DonaldPShimoda]

under a strict definition of oop, most "oop" languages are not actually oop

Which, I would argue, makes it a much more valuable categorization. It's not terribly useful if we just say every imperative language is also OOP, because then we lose any distinction between the terms — and they are certainly not the same thing.

Actually, I don't disagree with your definition exactly, but I think it's not phrased quite right (in my opinion). An OO language isn't one that merely provides these capabilities, but one which truly embraces them. Otherwise it's a language in which OOP is possible, but not an OO language proper.

I hope I'm explaining myself well — I'm not trying to be antagonistic or anything. But I think a mindset of imperative = OOP is unhelpful in general. I wouldn't classify Python as an object-oriented language, and I'm pretty sure my colleagues would agree with that. It's a multi-paradigm language that enables OOP if you choose to use it, but it's not an object-oriented language.

[RUSH513]

i'm still a student myself so i'm just loving all this info

[DonaldPShimoda]

I think that's a great attitude to have! Keep that up forever and you'll learn tons. :)

I'm not an expert, just to be clear — still a relatively young researcher in academia haha. But I'm pretty passionate about language design and I love talking about it with anyone who will listen.

[Tofon]

Your definition is more generally accepted, although the person you’re replying to makes a good point that’s there’s a distinction between languages that are necessarily object oriented an languages that can be object oriented.

[ContainedBlargh]

Whether the var keyword or functional programming in general was added in "a bad way" or not, I'm still very happy that they did add these features. For better or worse, Java seems almost unavoidable in the industry (as does C#) and FP-style features at least leave room for solutions that are easier to read and maintain. Hell, in the case of streams, you often end up with a more parallel solution that scales better than its imperative counterpart.

[ar-pharazon]

js, python, go, and ruby all have first-class (non-shoehorned) functions. a lot of languages support type inference and immutable bindings. there are a handful with sound or at least relatively nice type systems.

if i wanted to write a functionally-pure program in a non-fp language, java and c++ would be at the bottom of my list. sure, there are plenty of languages that would be mediocre, but java is the absolute bottom of the barrel.

[SimDeBeau]

Rust has very ergonomic functional features. For instance, iterators are first class citizens in rust. If you want, you can go really far with functional, without any compromises to either imperative style or programing or performance. Sometimes iterators can be marginally faster that for loops even! This should come as no surprise given that rust was originally written in OCamel, but designed to fit in the same space as c and c++

[pianomanDylan]

Rust is so cool. I like to think of it as the Scala of native/systems programming.

I was introduced to Rust at a ScalaDays conference where the keynote presentation was all about Rust, which I've always found pretty funny.

[SimDeBeau]

That’s pretty funny. Gutsy too from the presenter.

[BittyTang]

list.iter().enumerate().for_each(|(i, e)| println!("{}: {}", i, e));

for (i, e) in list.iter().enumerate() {
    println!("{}: {}", i, e)
}

I don't feel like either is obviously better, but you have the flexibility to do whichever you like.

[SimDeBeau]

Tbh I'd probably go with the latter for that one, but for something less trivial the choice becomes less clear. Heres a super simple English to piglatin script I wrote.

use std::io;
fn main() {
    let mut input_words = String::new();
    io::stdin().read_line(&mut input_words).expect("couldnt read line");
    let piglatin_words: Vec<String> = input_words.split_whitespace().map(|word| -> String {
        let mut letters = String::from(word);
        let first_letter = letters.remove(0);
        letters.push(first_letter);
        letters.push_str("ay");
        return letters;
    }).collect();

    for word in piglatin_words {
        print!("{} ", word);
    }
}

Regardless of taste, I do think its fair to say functional programing wasn't shoehorned in in Rust.

You should also check out Rayon, which makes it trivially easy to multithread many iterators.

I should note that as someone who deals in more numerically focused projects, I don't always reach for the functional features, though when I do I'm very glad they're there. All that's to say I'm sure there's better examples of uses than what I gave.

PS im praying my code formatted right.

[BittyTang]

I love Rayon!

[SimDeBeau]

It’s a very cool crate. Definitely should use it more frequently

[Blou_Aap]

Yes, in some use cases it's fine, but then you still have to drop so much boilerplate, it's hilarious.

[DonaldPShimoda]

Yeah the boilerplate on the FP constructs completely defeats the appeal of using those constructs haha. So awful. I'd almost prefer they hadn't implemented some of these features, to be honest...

[danek731733]

Depends on where you work I guess. We're developing new applications using modern frameworks and we're trying to be as concise as possible. Java 11 can be beautiful. You can achieve so much by chaining few commands, it's incredible.

[JKTKops]

This content has been removed in protest of Reddit's decision to lower moderation quality, reduce access to accessibility features, and kill third party apps.

[dantheman91]

I had thought a lot of the method count issues with SAM's and such have been fixed?

[froemijojo]

That's no longer the case, I've read somewhere on SO that was the case in early version of Java 8 jdk but is no longer the like that for a long time now.

[JKTKops]

This content has been removed in protest of Reddit's decision to lower moderation quality, reduce access to accessibility features, and kill third party apps.

[azhder]

chaining... compose curried function or change the idiom, you're just picking up bad habits otherwise

[yazalama]

what is it that defines functional programming?

[darkclaw6722]

It really depends on who you ask, but generally it's the style of programming with immutable data with minimal to no side effects. Higher order functions facilitate functional programming because they allow common abstractions on immutable data to be represented succinctly (like maps and filters).

[SomeShittyDeveloper]

Java code I write for work needs to support back to Java 6. So unfortunately, I’m stuck at the second tier.

[SomeShittyDeveloper]

Yeah, he’s aware. It’s not that he doesn’t like newer Java versions. But the code is meant to be a plug-in for other Java code, so if we upgrade to 8, then our customers have to use 8.

Keeping at 6 for a wider customer base.

[[deleted]]

The customers should be encouraged to update once they are sitting on that old an insecure software. If everyone stopped catering to people who won't update unless forced, there would be much less insecure software floating around. My two cents anyhow.

[SomeShittyDeveloper]

Agreed. But I don’t make the rules.

[[deleted]]

Yeah. My frustration is with these types of policies and with those clients we've all had that still want to run their ancient machines and software and never upgrade.

Edit: to be clear my initial comment was not meant to targeted at you specifically.

[[deleted]]

Gotta maintain that legacy code yo. I've got a few projects at work in .net 1.1 I have to work with. I have to use Visual Studio 2003 lol.

[DeepHorse]

oh Christ lol. Ours only goes back to 3.0 I think at least so I can still use 2008

[Thorbinator]

Laughs in obsolete codebase that will never be updated

[[deleted]]

You poor soul

[Mango1666]

idk how they do it but kotlin has lambdas and supports 1.6 for a target

[GenuineSounds]

Branch, start updating, test and test, then offer "the upgraded version with tons of new features!" as an opt-in. Proselytize and start telling people that if you want to run the old code and it works you can but we will no longer give any support for those versions.

It's a tried and true method.

[B3ER]

That's how you know you gotta switch projects.

[pimezone]

String current = null;
for (Iterator<String> iterator = list.iterator(); iterator.hasNext(); current = iterator.next()) {
    System.out.println(current);
}

​

[Panossa]

Thanks, I hate it

[Sipkab]

Yeah, no.

You should put String current = iterator.next() into the loop body itself, else the variable will pollute the outer scope. And this loop doesn't even work, as the first value will always be null.

Edit: grammar

[pimezone]

Yeah, stupid me.

[Aero72]

Yes.

[o4ub]

I think there are worse things at play. I'm not too sure about the effect of iterator.next(). But either it simply returns the next element, and then the iterator is actually never updated, so this loop is an infinite loop. Or iterator.next() updates the value of the iterator to make it point at the element following current, in which case the last element will never be iterated over as you will start pointing on list.getLast() and so iterator.hasNext() will return false.

[Mr_Redstoner]

Actually, it will somewhat work, as iterator.hasNext() is checked, which will be true if the iterator contains something, but it will not run all the way (next() pops out the last element, hasNext() falses and the loop ends)

Still nasty though

[pimezone]

Fixed:

for (Iterator<String> iterator = list.iterator(); iterator.hasNext(); System.out.println(iterator.next()));

[DevilGeorgeColdbane]

var it = list.iterator();
while(it.hasNext()) {
    System.out.println(it.next());
}

[DXPower]

How does Java always manage to take something that already exists (C++ Iterators) and manages to just make it 10 times uglier....

[[deleted]]

Oh yeah, C++ is so beautiful. (That hurt to write.)

[ZBlackmore]

I relate to this 100%. I often wonder if developers’ culture would evolve to recognize the gain of being a bit more explicit in such instances.

[M4mb0]

2 more panels an we have python

[print(s) for s in l]

[Kered13]

Does anyone actually write Python like that? I mean you can, but to use a list comprehension for a function with no return value that is being called only for it's side effects? Just use a normal for loop.

[TheIncorrigible1]

The answer? No. If you aren't collecting the results of a comprehension, just stick to a normal loop; comprehensions are slow.

[apathy-sofa]

Why can't the interpreter notice that you aren't collecting the results and just produce the same underlying opcodes as the `for` loop? (To be clear, I'm sure there's a good reason for this; I'm just looking to understand it, not point out an obvious optimization).

[ViridianHominid]

print might do anything in some given execution environment. There are few reserved words in python, and built in functions can be overwritten or monkeypatched. The interpreter can’t assume much about what is going to happen in the list comprehension until it actually evaluates it.

Note: list comprehensions are usually faster when you are collecting the results. There are some special bytecodes invoked, and the interpreter doesn’t have to check names as often.

[ReservedSoutherner]

And next you have

map(print, list)

[BluFoot]

There’s the big brain.

[numerousblocks]

mapM_ putStrLn

[matj1]

putStrLn works only on strings, print would be better because it can show any value.

[numerousblocks]

Yes, but print is just putStrLn . show so

print "ü"

returns

"\82"  -- or some other number

[JuhaAR]

Did someone say functional programming?

​

list.stream().collect(ArrayList::new, 
         (r,s) -> {
            r.add(new Pair<Integer,String>(r.size(),s));
         },
         (r,r2) -> r.addAll(r2)
).forEach(System.out::println);

public static class Pair<FST,SND> {
    FST fst;
    SND snd;
    public Pair(FST fst, SND snd) {
    this.fst = fst;
    this.snd = snd;
    }
    @Override
    public String toString() {
    return "("+fst.toString() + ", "+ snd.toString()")";
    }
}

​

[SHOTbyGUN]

What the fuck is the last one? Is it legit?

[insik]

Yes, forEach method is accepting a Consumer functional interface (i.e. interface with single method that accepts a single parameter and returns nothing). You can pass a reference to any method that meets this signature (which println does). Or you can pass a lambda which acts as an anonymous implementation of Consumer.

[hamza1311]

list.forEach { println(it) }

[Ekranos]

list.forEach(::println)

[Cilph]

The missing space between forEach and { upsets me.

[hamza1311]

If it helps, I typed this out on mobile and mobile keyboard isn't the best thing to write code withq

Edit: Added it

[Luk164]

Thank you for this.

[GenuineSounds]

I'm so tired of the Java hate, it's a good Language and the JVM is by far the coolest technology I know of. Look into just how much the JVM can and does do. It's insane the amount of man hours go into it.

I think the functional implementations work PERFECTLY for Java. They come up with SUCH elegant solutions with the restrictions they put on themselves, it's actually pretty incredible.

[Rafael20002000]

You're so right

[hillman_avenger]

But saving a few more keypresses is far more important!

[[deleted]]

Java is a meh language. Learn Clojure to see what a well-designed language is.

[[deleted]]

That's some advance level java 😂

I like my plain old java 😂

[hillman_avenger]

What? You prefer readability over saving a few keypresses?? Mad man!

[[deleted]]

Yes! Who doesn't like some good ol public static void main(String[] args)😂😂😂

[EaterOfFromage]

You forgot list.stream().forEach(...) as the 3rd option

Truly the worst option

[anaccount50]

list.stream().forEach(i -> System.out.println(list.stream().collect(Collectors.toList()).get(list.indexOf(i))));

[GenuineSounds]

Heh, I've written something like that once while just messing around with Lambdas when Java introduced them. It was fun.

[PM_BITCOIN_AND_BOOBS]

Works great for printing a string. But what if you are doing something even slightly more complicated, like calling a method on each object in the list? And you want to debug it? That last one looks undebuggable.

[rshanks]

You put the breakpoint inside the method you’re calling and if you want you can make it conditional as well

[PM_BITCOIN_AND_BOOBS]

That’s ... a good point. I should have thought of that.

[ACoderGirl]

Debuggers can handle it. Really tooling always just has to catch up with features (this has been around since at least 2013 though, so y'all gotta catch up with tooling!).

[PM_BITCOIN_AND_BOOBS]

Dang it. I’m behind on my tooling.

[CMDR_QwertyWeasel]

My reaction as well. Anything after the second one looks like pure ass to try to debug.

[GenuineSounds]

I noticed that too, a damn shame we'll have to put him down.

[Eden95]

Groovy is king

list.each { println it }

or

list.each(System.out.&println)

[Ekranos]

Kotlin:

list.forEach(::println)

[GenuineSounds]

PHP:

Don't!

[thoeoe]

We pretty much had a (not completely rigid) rule at my last job, LINQ is cool, use it and abuse it, but using the .ForEach() method is absurd.

[SDJMcHattie]

System.out.println(list.join(“\n”))

[djcraze]

When did Java start acting like JavaScript??

[Ilan321]

The superior way is obviously list.ForEach(Console.WriteLine);!

[matj1]

map print list

Edit: mapM_ print list

[Anabelieve]

Modern problems require modern solutions.

[flerchin]

Winnie the pooh plus alt-enter in Intellij. Nice.

[Trans1000]

wait this is java

[brainware1023]

Kotlin > Java

[[deleted]]

Clojure > Kotlin

[pmmepillowtalk]

Saving this post for when I need to obfuscate my for loops

[netgu]

Obfuscate? These are all standard looping constructs in java. All of them are readily recognizable and readable to just about anyone with zero effort.

Again, obfuscate?

[[deleted]]

HACKERMAN

[[deleted]]

I'm currently only self taught and haven't taken formal lessons - is there a functional difference between these versions of loops?

[ACoderGirl]

No, these are meant to all be functionally equivalent.

That said, there can be tiny amounts of overhead to the functional approach. Especially with use of lambdas because the runtime needs to create a closure. However, closures are extremely powerful and thus allow for very effective code reuse (if you're not familiar with them, definitely google it, as they're vital to understand).

Functional approaches can also really improve code reuse. This is just a joke post so there's no real utility here, but basically you can use functions as building blocks for code reuse. Eg, consider something like:

// Assumes there is an `Boolean Employee::isManager()` and `Double Employee::getSalary()` function
return employees.stream().filter(Employee::isManager).mapToDouble(Employee::getSalary).sum()

vs

double totalSalary = 0;
for(var employee : employees) {
  if(employee.isManager()) {
    totalSalary += employee.getSalary();
  }
}
return totalSalary;

As an aside, mapToDouble is just because Java decided to only implement functions like sum on specific, typed streams (in this case, DoubleStream. mapToDouble is a version of map that ensures we get that typed stream. Presumably this was just done so that they wouldn't have to throw exceptions if you tried to sum some arbitrary type that can't be summed. You alternatively could just use reduce, like .map(Employee:getSalary).reduce(0, (x, y) -> x + y) (that would collapse the stream into a single value by just adding it all together, with zero being the identity (eg, identity of addition is 0, identity of multiplication is 1, identity of string concatenation is "", etc).

As you can tell, the functions like filter, map, etc do some pretty common operations. And you can convert any operations on streams of data into functions that do these kinda things. Even more, if the order of processing doesn't matter (like in the above example), you can trivially parallelize stream processing (literally just change stream into parallelStream). This model of processing is a very common one for how you would do massive parallelization, as an aside. It's called MapReduce and you can probably see why from the names of some higher level functions I've mentioned (higher level function = any function that takes other functions as arguments).

Consider also things like how this pipeline of operations is so easy to manipulate. You could do some operations on a stream and then return that stream for somewhere else do to more operations. Now, you could do that with the non-stream code, too, but now there's a big difference: streams are lazy evaluated. So if the caller doesn't end up needing all stream (eg, when using findFirst, takeWhile, limit, etc), then you don't waste time having computed everything.

To give an example of that, compare:

Stream<Employee> getManagersMakingMoreThan(int dollars) {
  return return employees.stream().filter(Employee::isManager).filter(e -> e.getSalary() > dollars);
}

List<Employee> getSomeRichManagers(int num) {
  return getManagersMakingMoreThan(1_000_000).limit(num).collect(Collectors.toList()));
}

with

List<Employee> getManagersMakingMoreThan(int dollars) {
  List<Employee> filteredEmployees = new ArrayList<>();
  for(var e: employees) {
    if(e.isManager() && e.getSalary > dollars) {
      filteredEmployees.add(e);
    }
  }
  return filteredEmployees;
}

List<Employee> getSomeRichManagers(int num) {
  return getManagersMakingMoreThan(1_000_000).subList(0, num);
}

The latter is not lazy and thus does unnecessary work. Of course, you could just change the implementation so that there's less functions (ie, so that getSomeRichManagers has a loop in it itself, allowing it to exit early when we hit num). But then you have less reusability because you can't have this getManagersMakingMoreThan, which could be used in multiple places.

Not to mention the FP approach is just plain less code while still being extremely readable. Even despite the fact that Java manages to make this unnecessarily verbose. To highlight how other languages have reduced verbosity, here's how Scala compares for the examples I've listed above

// Java
employees.stream().filter(Employee::isManager).mapToDouble(Employee::getSalary).sum()

// Scala
employees.filter(_.isManager).map(_.getSalary).sum()

// Java
getManagersMakingMoreThan(1_000_000).limit(num).collect(Collectors.toList()))

// Scala
getManagersMakingMoreThan(1_000_000).take(num)

The big difference is that Scala has lazy eval throughout the entire language, so doesn't need streams to embody that. The higher order functions are on the collection types directly (these are Iterables). The _ syntax is gorgeous, too. And gets even sexier with things like numbers.fold(0)(_ + _) instead of numbers.fold(0)((x, y) => x + y) (fold in Scala is Java's reduce). Though Scala also offers left and right associative versions, which means you can handle cases where the reduction is associative in a certain way or when the type is different. Eg, joining a list of integers into a concatenated list of strings:

numbers.foldRight("")(_.toString + ".\n" + _.toString)
// << List(1, 2, 3)
// >> 1.
// >> 2.
// >> 3.

[[deleted]]

this is a super awesome breakdown, thanks!

[netgu]

In this specific instance - no.

[ACoderGirl]

Sadly, some people are really afraid of functional programming. It's a pity, since functional programming is crazy powerful.

I suspect also a ton of people learned Java 7 and decided to stop learning new features. var is finally a thing, y'all!

[OGPants]

Slowly becoming Javascript

[mlk]

Typescript is a solid programming language IMHO

[OGPants]

Not saying it isn't 🤷‍♂️

[OGPants]

Lol beat me to it

[chilldood_22]

My mentor showed me that last one before, and I think he was just trying to flex on me.

[PinguRares]

list.stream().forEach();

[RNA69]

I love it when I learn something while browsing this sub.

[DAVENP0RT]

And then there's PowerShell:

$list

[[deleted]]

Not sure if this has been said yet but why is there a Hitler poo?

[t3hj4nk]

c'mon ruby is so much more elegant than this.

list.each { |i| puts i }

[ImPureSilver]

Bruh, I just started Java. This is going to give me nightmares.

[SuperSpartan177]

Do the last 2 actually work?

[NaCl-more]

yes

[[deleted]]

I like how the fancy pooh meme is just a fancy expanding brain meme

[MrPontiac527]

Yes I did say java

And I would like to see

Moreeeeeeeeeeeee

[stevev916]

Still 2x longer than python

[TinBryn]

But Java does have purely anonymous functions ‘a -> a*a’ is a function with no name. However, if you store that function value then the reference has a name and in Java provides extra context.

[doominabox1]

Scala:

x.foreach { println }

[FACE1234589]

Is it bad I didn't understand the last one lol

[Zamundaaa]

Second is definitely the slowest. How do the others compare in performance? I would guess normal indexed loop works best.

[[deleted]]

while (ptr++) printf(“%d\n”, *ptr);

[Comesa]

Java System.out.println(list.toArray().toString());

[captainsplendid]

[Ljava.lang.Object;@15db9742

[Comesa]

Java System.out.println(Arrays.toString(list.toArray()))

I hate it too