PropCheck.jl
Chain.jl
PropCheck.jl | Chain.jl | |
---|---|---|
1 | 8 | |
79 | 348 | |
- | - | |
8.0 | 4.2 | |
about 2 months ago | 3 months ago | |
Julia | Julia | |
MIT License | MIT License |
Stars - the number of stars that a project has on GitHub. Growth - month over month growth in stars.
Activity is a relative number indicating how actively a project is being developed. Recent commits have higher weight than older ones.
For example, an activity of 9.0 indicates that a project is amongst the top 10% of the most actively developed projects that we are tracking.
PropCheck.jl
-
Julia as a unifying end-to-end workflow language on the Frontier exascale system
There is no rebuttal because nothing much has really changed culture wise. Sure, the various @inbounds issues and concrete bugs that are mentioned in Yuris post have mostly been addressed, but the larger point (that is, "what can I actually expect/get guaranteed when calling a given function?") definitely hasn't been, at least not culturally. Documentation of pre- and postconditions are still lackluster, PRs trying to establish that for functions in Base stall for unclear reasons/don't get followups and when you try to talk about that on Slack retorts boil down to "we're tired of hearing you complain about this" instead of trying to find a systemic solution to that problem. Until that changes, I have large doubts about Yuris post losing relevance.
My own efforts (shameless plug, https://github.com/Seelengrab/PropCheck.jl for property based testing inspired by Hedgehog and https://github.com/Seelengrab/RequiredInterfaces.jl for somewhat formalizing "what methods are needed to subtype an abstract type") are unused in the wider community as far as I can tell, in spite of people speaking highly of them when coming across them. I also don't think Kenos InterfaceSpecs.jl is the way forward either - I think there's quite a lot of design space left in the typesystem the language could do without reaching for z3 and other SAT/SMT solvers. I personally attribute the lack of progress on that front to the lack of coherent direction of the project at large (and specifically not to the failings of individuals - folks are always very busy with their lives outside of Julia development/other priorities). In spite of the fact that making this single area better could be a big boon with more traditional software engineers, which are very underrepresented in the community.
Chain.jl
-
Pains of Julia compared to python
The [Chain.jl package](https://github.com/jkrumbiegel/Chain.jl) is becoming idiomatic for these kind of pipelines.
-
Transition from R Tidyverse to Julia (VS Code)
If you do have tabular data in a dataframe you have a few options for data manipulation, the most popular packages are probably DataFramesMeta and Query, although in my opinion the best way to manipulate dataframes is with the functions built in to DataFrames.jl and using a package like Chain.jl or Pipe.jl to pipe the functions into each other like magrittr in R.
-
The (updated) history of the pipe operator in R
The Julia community built a better piping method than any other language has AFAIK: Chain.jl.
-
What are some of your favourite macros?
@chain and @match.
-
Why is piping so well-accepted in the R community compared to those in Julia and Python?
Have you ever tried Infiltrator.jl and Chain.jl?
-
https://np.reddit.com/r/Julia/comments/nnu6if/julia_object_oriented_programming_with_dot/h0anaru/
You are right. However, sometimes well used is very useful, and readable. One suggestion, in Julia I suggest Chain.jl, because it allows intercalate easily the output for debugging:
-
Julia Update: Adoption Keeps Climbing; Is It a Python Challenger?
I also like pipe syntax and I've found there is nice support for it in Julia. There are some nice packages to improve it over base [1].
Have you checked queryverse [2]?
[1] https://github.com/jkrumbiegel/Chain.jl