-
Notifications
You must be signed in to change notification settings - Fork 24
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
tag for 3.0.16? #24
Comments
Thanks for your interest! Yes, that's the latest commit. You are of course welcome to build from source, but you shouldn't need to. 3.0.16 shows up in the Maven Repository, so not sure where the issue might be: The "master" branch is always the most stable branch. Features go in new branches, though bug fixes often get made to Master. If you use Paguro and do a lot of .filter().map().any() operations on the collections the way you would in Clojure, please let me know. I much prefer Paguro's Transformations to Java 8 Streams. Kotlin has transforms built in that are a little nicer even. I ask because I could interpret a lot of feedback as, "We just want the collections, don't give us anything else." Either that means they want to incorporate collections into other tool kits, or it means, "We hate your streams." So far, I can't tell. Compiled Kotlin is nearly indistinguishable from Java. It's not like Scala where you end up calling |
Re: maven - yeah I can see the artifacts up there. The issue is just that we have a custom set of build tools at work where we have to build third-party libs from source. Typically I go to maven central to determine the latest release version, then go look for a corresponding tag in GitHub. In the absence of tags it's a matter of making sure I can identify the right commit by poking through the history. This is where my questions about kotlin come into play as well. Since I have to build from source, if there is a compile-time kotlin dependency then I'll have to sort that out. I know that our build tools have some support for kotlin but I don't know how mature it is, if it supports mixed java/kotlin projects, etc. These aren't concerns I'd expect to be high on your priority list :) Just trying to get a sense of your plans since it might effect my ability to upgrade the library over time, which might weigh into the decision on taking it as a dependency. Or, at least, prompt me to understand the state of our kotlin build tooling before choosing paguro. One other note that might be of interest - our build system runs Lastly, re: transformation functions: personally I am interested in them and may play with them some for my own edification, but initially if I end up being able to use the lib for work, it'll be for the collections. Having spent some years in clojure, I am 100% sold on immutable persistent data structures. But what I'm finding is that while anyone who has worked in clojure for a while comes out feeling that way, almost anyone who hasn't just looks at you like you are bananas when you try to sell them on it in a 5-minute pitch :) Most of my teammates don't have much or any previous FP experience and are still leery of the java 8 lambdas and stream methods, but are willing to consider them since they are built in to the language. They get more skeptical when I start advocating for bringing in FP things from outside the core language. So, baby steps :) The data structures are definitely step 1. |
I promoted the build instructions to the first page for you: https://github.com/GlenKPeterson/Paguro#build-from-source
I've been bumping along on the assumption that people would either use the latest version on Maven Central (Sonatype), or clone the master branch and build from that. Based on your feedback, I tagged the latest release here: I typically use the latest available version of Kotlin. I've had a little trouble configuring Maven correctly, but they must be upgrading their instructions and the IntelliJ automatic-fix code because every time I do this for a new project it gets easier. I'm learning here too, but I have put a couple of hours into the current Maven configuration on the (unstable) Kotlin development branch: 2017-09-17_Kotlin. If I wasn't my own worst enemy, it probably would have worked on the first try. I've tried to address your other Kotlin concerns by updating the announcement: https://github.com/GlenKPeterson/Paguro/blob/master/README.md#next-major-release-will-be-paguro-40-kotlin-compatibility
I'll have to try that. Thanks for letting me know. I'm opening issue #25 for that.
Yes, that is frustrating. I don't have a very good track record of convincing people, but the highlights of my best pitch are here: Brian Goetz and the people managing Java's direction are brilliant. No question about that. But Java is a big language and everyone has a different focus. Goetz book on Concurrency is brilliant. But he doesn't seem too impressed with functional programming and immutability. Java 8 got the big things right, but a lot of the details around functional programming are still really awkward. Perhaps this is most evident in the Java 8 Streams API. It's probably not actively hostile to immutability, but it does nothing to help you. I was pretty excited about the idea, but shocked when I saw the final implementation. Here are some thoughts: |
Thanks! Very kind of you.
Totally reasonable assumptions, I imagine that you'll hit 95% of your target audience with that approach. Our build tools are way off of the beaten path, so I wouldn't expect any self-respecting GitHub oss library maintainer to be making accommodations for a setup like ours :) Our chain doesn't use maven for dependency resolution OR for the actual build process. I have to Port to an ant-based setup. Luckily that is usually very easy for basic maven projects that follow the typical maven conventions. Anyway, thanks a bunch for tagging, that's helpful! And who knows, maybe I'll be able to turn this into an excuse to kick the tires of kotlin at work. Thanks for the wiki FP links, looking forward to reading those one the bus this morning :) feel free to close this issue out! |
If you haven't seen issue #25 yet, you should know that there's a 3.0.17 version, with a tag, ready for a git pull, with about half of your FindBugs issues fixed. Thank you very much! I'm closing this issue as you suggested. |
I did see that, thanks! I'll update to that tag. |
Hello,
I'm a former Clojure developer who is now back in Java land. This library sounds really interesting and seems like it would fill in some gaps that I'm sorely missing based on my time in Clojure. I am going to play around with it but need to build from source; I don't see a tag in the repo that corresponds with the
3.0.16
maven artifact. Am I correct in assuming that this is the appropriate commit?:61f61c7
Also - it seems like you're gaining a lot of momentum in the direction of Kotlin. Kotlin sounds fantastic but I doubt I'll be able to adopt it at work any time in the near future. Do you expect that the library will continue to be seamlessly consumable for Java 8 as your Kotlin changes continue to come in?
Thanks for writing a really interesting library!
The text was updated successfully, but these errors were encountered: