krumbie

Personally, I like the state now better than a couple years ago, where it was a struggle to get Cairo.jl working because it was interacting with users' systems in weird ways. It admittedly takes much more harddrive space, sometimes to a silly extent. I'm not sure if it's technically possible to have weak binary dependencies, I think if Cairo the C library declares binary deps, we have to add them all (hence Pango, Fontconfig, etc. etc.).

By the way, we get very few installation issues nowadays. They usually have to do with either graphics drivers on Linux, or because people have somehow messed with their library load paths and pull in the wrong dylibs. From a maintainer's perspective it's nice not having to worry about all that too much.

Yeah the recipes are Plots.jl's strength. We will need more time to get there, I've always felt that the statefulness you get from having interactivity gets in the way of easy composability a bit. In Plots, you assemble one big plot description from recipes that then gets translated to a backend representation once. In Makie (currently) each plot object gets instantiated immediately, ready to go for interaction. But in the future, we might add a layer on top that builds full descriptions first, like Plots, then instantiates at once.

As a side note, package extensions in Julia 1.9 mean that any package can now in principle extend Makie without directly depending on it. That should remove one of the big blockers for adoption, as admittedly, Makie is a heavy dependency to take on.

I don't use it personally, but RCall.jl[1] is the main R interop package in Julia. You could call libraries that have no equivalent in Julia using that and write your own analyses in Julia instead.

[1] https://github.com/JuliaInterop/RCall.jl

I don't think we claim we are the only library that uses something like Observables, as you say there are others that do. VegaLite also uses a signal mechanism for interactivity, for example. Makie has been inspired by many libraries that came before (although I can't say that I knew echarts, specifically :) )

Every plotting library has something to offer, there are so many choices to make when building one that you can't cover everything. I envy the pure javascript libraries a little for their easy embedding in websites. But when you already do data work in Julia, especially with custom types and such, it's nice not having to move across a language barrier, and instead make use of Julia's multiple dispatch some more by using a native plotting library.

It's in a different category I would say. For the users, ggplot is mostly about the grammar idea, how you assemble plots from data, geoms, etc. Makie is on a lower level, where you create elements like axes, colorbars, legends etc. manually (with convenience methods, where applicable) and plot things like volume plots or line plots to the axes (like in matplotlib or Matlab for example, but with the whole Observables thing for interactivity). However, the packages AlgebraOfGraphics and TidierPlots are just using Makie's plotting infrastructure to layer a more descriptive plot-building engine on top. There should be nothing in principle that ggplot can plot that Makie really can't, because there are only so many 2D primitives, but Makie has a bunch of 3D stuff that you would not use ggplot for, I'm sure.

My biased view as a coauthor of Makie is that Makie's model is cool because you have a much easier time to combine low-level tinkering with high-level descriptive plots this way. I don't know if you've ever tried hacking the ggplot data structures for special use cases but they are more complex or inscrutable than in Makie, I would say.

Of course, ggplot2 has an amazing and mature ecosystem around it, our ecosystem will need time to fill gap after gap.

Improving the docs as a key point was one of my takeaways from MakieCon. It's pretty time-intensive to work on them as you can imagine, but I hope we'll be able to make the structure more clear and efficient in the future. There should definitely at least be docstrings for every exported struct and so on. But I also want newcomers to get started with less friction, so the explanations/tutorials/how-tos must improve.

This is an easy way for newcomers to help out, by the way, just give feedback on how starting out with the library went and what the main roadblocks were. The better we understand them, the more we can improve them.

I have a reverse corollary of this, which is: As I do/use things that are useful/interesting despite of their papercuts, then if I don't do/use something because of perceived "papercuts", they are probably not really the reason.

Examples are not recording music because my audio interface is a bit too laggy, or not taking photos because my camera lens is a tad blurry in the corners. The real reason is that I'm not motivated / inspired enough and like to blame the "papercuts" of my gear.

This is not only about things moving away from where they were, but also popup windows appearing above a thing you wanted to click on. You cannot always avoid that, so I think the solution is to ignore clicks on things that have recently (in the last 500ms or so) appeared or shifted.

What's kind of crazy is how the images tend to have similarities in small features that become very apparent when flipping back and forth between images, but which are not obvious per se.

For example, I flipped back and forth between Beatrix Potter and Paulus Potter. A rounded white bonnet in one picture becomes a couple of blossoms in the other. The roof of a house becomes some shadowy wall with plants in the other. Two flower pots are very similar, just with slightly different coloring.

It makes it more apparent that the algorithm etches the images out of noise, and if the seed is the same for two images with different prompts, you're likely to see traces of that noise represented differently but recognizable in both images.

That is fascinating. I thought that bells had one or a couple dominant / loud frequencies that would mostly determine pitch, and the rest would just mix in to change the timbre but not the main percept. I always found the sound of melodies played with bells kind of uncomfortable because there is too much going on, too many different frequencies interfering with each other.

I guess it's mostly academics who have unusual problems that demand custom solutions, but which are small enough so people can switch to a language their lab group is not using and still be successful with their projects. I also wish for more common adoption but it is hard to make headway against python and R that have years of development for "basic packages" for typical users in them, which is just not the kind of stuff most academics can spend their time on.

It's definitely not objectively better. For normal workflows, the startup latency is a real hindrance, even if the community has collectively built norms around that which help a bit (keeping a long running repl session open, etc.). But in terms of expressiveness plus attainable performance it really is hard to beat. I think it's nice that the path from quick draft to really performant code is continuous, and not a big gap like switching languages.

I don't think it's frowned upon to compile, many people want this capability as well. If you had a program that could be proven to use no dynamic dispatch it would probably be feasible to compile it as a static binary. But as long as you have a tiny bit of dynamic behavior, you need the Julia runtime so currently a binary will be very large, with lots of theoretically unnecessary libraries bundled into it. There are already efforts like GPUCompiler[1] that do fixed-type compilation, there will be more in this space in the future.

[1] https://github.com/JuliaGPU/GPUCompiler.jl

I don't think it's just about whether it's hard to do, your syntax example looks short enough and one can memorize these two patterns relatively quickly.

However, both patterns are another special case how identifiers are resolved in the expression. Aren't `.env` and `.data` both valid variable and column names? So what happens if I have a column named `.data`?

Another example, which is the reason why we chose the `:column` style to refer to columns in `DataFramesMeta.jl` and `DataFrameMacros.jl`:

What happens if you have the expression `mutate(df, b = log(a))`. Both `log` and `a` are symbols, but `log` is not treated as a column. Maybe that's because it's used in a function-like fashion? Maybe because R looks at the value of `log` and `a` in their scope and sees that `log` is a function an `a` isn't?

In Julia DataFrames, it's totally valid to have a column that stores different functions. With the dplyr like syntax rules it would not be possible to express a function call with a function stored in a column, if the pattern really is that function syntax means a symbol is not looked up in the dataframe anymore.

In Julia DataFrameMacros.jl for example, if you had a column named `:func` you could do `@transform(df, :b = :func(:a))` and it would be clear that `:func` resolves to a column.

This particular example might seem like a niche problem, but it's just one of these tradeoffs that you have to make when overloading syntax with a different meaning. I personally like it if there's a small rule set which is then consistently applied. I'd argue that's not always the case with dplyr.

That's true. However, I believe that many R programmers don't know when non-standard evaluation happens or what it is exactly. Functions with or without it cannot be told apart just by looking at the syntax.

While NSE enables the dplyr syntax that many people enjoy, for me it's too magic and I have trouble reasoning about variable names in other people's code.

I've experienced it many times how intimidating it can be to ask about things in a new workplace that seem to be commonplace there. Especially in the US, where abbreviations are used for a ridiculous number of things. You just can't break through this barrier if you don't ask what people mean, and it gets worse over time if you avoid it for fear of seeming dumb.

This resonated with me. I refused to open an instagram account because I didn't want to think about what other people might like when taking photos.

And this is why it's hard for newcomers to switch to open access journals. Because they cannot easily afford not to have well known journals in their publication list when applying for positions. Because the people in charge probably don't fully understand the applicant's research, but they think they get a good sense of quality by the names of the journals

I'd actually say the opposite. In my experience, n-dimensional arrays for example are very useful for problems that don't have anything to do with linear algebra. And in Julia it's just so convenient that all the high level functions manipulating such arrays are fast, and therefore much simpler to write.

Because you believe that you can't get used to a different convention? It gets brought up a lot that for array offsets, zero based is more natural. In my experience, the amount of index calculations you need in Julia is minimal anyway because there are really nice abstractions for n-dimensional indexing.

That's true. I am of course biased in talking mostly to people on the Julia Slack etc. who enjoy the language a lot and do interesting things with it.

That's one of the reasons, though, why I never find the "how many people are using it" argument the most convincing when talking about the merits of a language. Because most people I've seen using R, Matlab and Python, at university or work for example, used it really superficially, and therefore wouldn't have any interesting things to say about it. Neither do they add anything interesting to the respective ecosystems. I don't think it's the first interest of a new language to get this type of user, although of course in the long term you want to build tools that are easy to be picked up and used by a wide audience, and number of users is some indicator of that.

The comparison between different languages gets tiring when it focuses on making a black-and-white statement like "Julia is better" or "Python is better" and "x is never going to overtake y". Yes, Python has many more libraries thanks to it being much older than Julia, same for R. But at the same time, Julia can be used for impressive work that R/Python struggle with and which only seem solvable in these languages because of large investments into certain packages by big companies.

So I find the fact that many hard problems can be solved very generically and performant with small libraries written in Base Julia much more interesting than countering that much larger and older Python packages with millions of developer hours poured into them are currently more feature-complete. Yes, they are, right now. Why wouldn't they be. But does what is being done in Julia with much fewer resources not point to an impressive ability of the language to facilitate such development?

I have created one of the recent competitors in this space [1], and I think it's not so bad, as long as the macros are reasonably simple to understand. If you look in the readme of my project, the four syntax examples actually look quite similar so I don't anticipate they'd cause a lot of confusion.

When I got annoyed in my own work that some data wrangling syntax was repetitive I was just really glad that I could easily build my optimal solution and didn't have to just accept that there's one suboptimal (for me) way. In Python and R, if you like what they offer that's good, if not - not so good.

Part of the problem comes from Julia not being geared towards DataFrames like R is, but I gladly trade a bit of convenience in one domain against a lot of expressive freedom with very clean rules that apply everywhere.

For example, I think it's quite good that you can only have "weird" behavior in Julia with macros, but they give you a visual indicator with the @ that you're seeing non-standard syntax. While in R, the non-standard evaluation means that literally anything could happen to the variables you pass into any function. It makes for some convenient syntax in some cases, yes, but it's so confusing as a system for writing software! You never really know if you're looking at a variable or just a name, for example.

[1] https://github.com/jkrumbiegel/Chain.jl