employing and presenting one’s work and (indirectly) the language features / libraries that made it work;
patience, humility and hard work
As has been pointed out in the discussion already, people look for tools and (sometimes) people/behaviors/modes of being to emulate and learn from, not necessarily programming languages and libraries. I believe in good time, the efforts put behind a language and its ecosystem will bear fruit however this may take many years.
We recommend that you put your core pretty-printers into a Python package. If your pretty-printers are for use with a library, we further recommend embedding a version number into the package name. This practice will enable GDB to load multiple versions of your pretty-printers at the same time, because they will have different names.
Dear god, that’s what people recommend ? I had no idea this was a thing.
I don’t think the community is unfriendly or uncharitable, but I strongly believe it is still too “biased” toward software engineers, or even computer scientists.
Take the doc (or the discussions here on Discourse…) on large projects like MLJ or Symbolics and compare it with that on ScikitLearn and SymPy.
Sure MLJ and Symbolics are more powerful, efficient, and support state of the art, recent from-research stuff, but at the end, using ScikitLearn or SymPy is so easy for the average guy.
Even Julia base documentation is “tailored” to specialised audience. Take the examples in the doc on the randn function. I understand that it is “cool” that complex numbers are supported, but the example could have used “normal” Float64 numbers, as most “programmers” doesn’t work with complex numbers… think, you want to use randn, looks at the documentation, and you have a “phobia” to complex numbers…
Or the documentation for permutedims.
The doc correctly refer to the fact that permutedims is not recursive compared to transpose. And it even shows a long example on that, but what a “enlarged audience” could care is that transpose you can use only for numbers, while permutedims for everything else, so perhaps the first example should have been just julia> permutedims(["A" "B"; "C" "D"])
Of course there is a trade off… you want to be precise, complete and highlight the extreme cases only your function or library covers, but this could alienate the more casual programmers.
I tried JET.jl for several months as part of my runtests.jl. It often works (identifies use of a non-existing variable/function (which includes, getting the signature wrong)) – but a few times a day, it doesn’t.
C/C++ compilers, on the other hand, have become, over the last 20-or-so years, very good at identifying potential programmer mistakes (including, e.g., unused variables, missing cases in switch, etc). There, all the editor does is highlight the compiler warnings.
In C/C++, there are many constructs that do little else than communicate the programmer’s intention to the compiler – so that the compiler can check it and find the occasional mistake. (Simplest thing is declaring a local variable const.) I miss those.
If you spend twice of the time that you spend coding on documentation, you will increase the usage. There are quite a few occasions that I used a library (and of course the programming language of that library) because the documentation was so complete, it taught me the underlying scientific method, it taught me programming.
No, I didn’t submit a bug report, because I was trying to finish a project. Some people need to just use a programming language, and don’t have time to be part of the effort to create one.
The thing is that JET.jl is an amazing piece of software: it must be fiendishly difficult to catch the mistakes that JET.jl does in Julia source code. It blew my mind when I first saw the mistakes it finds. But I still have to exclude frames (otherwise I get false positives), occasionally it misses errors – so I still have to cover all the code in my own unit tests.
The same thing for C/C++ is several orders of magnitude easier due to the differences in the languages.
Disclaimer: I only only ever programmed seriously in C/C++ and Julia – so I cannot actually speak about language design. But I understand that some languages are designed (or have developed over time) with static analysis as a priority, and others (Julia! Python?) not.
That’s all true. One thing I changed when moving from Fortran to Julia is that I write much smaller functions. That’s a good thing, I guess, but also an imposition given the flexibility of the language.
I don’t think there is anything “unfair” about the situation, it’s just that other languages have spent more time integrating with external libraries. Unless there is an issue I have yet to encounter, I didn’t see anything preventing work to be done in Rust, with its toolset and package system, and then integrating it into Julia. Is anything preventing the integration of crates into Julia?
R just compiled 40K packages to wasm. I would be interested in hearing a plan for Julia to use wasm in browser, but potentially on server side which should eventually be relevant to two language issue.
… an even less fancy huge help would be to use literally any other algorithm than whatever Documenter currently uses to search docs. I would at this point rather do ctrl-F on raw html than use the built-in search functionality
I often find myself cloning repos locally just to grep because the search bar on the docs site works so poorly
When @mit.edelman and @jeff.bezanson told me back in 2011 that they were developing a new programming language, my initial reaction was “You’re doomed.” New programming languages, especially ones without a large corporate backer (Swift, Go, C#, …) rarely succeed because of precisely such network effects.
Over time, I upgraded my prognosis to “probably doomed” and “maybe still doomed” … but in the meantime I started having fun with it, and I found its unique combination of features made it more productive for me than other languages for many of my projects. As long as that holds true for sufficiently many people, Julia will continue to grow, but overtaking established languages is never something you can count on.
YMMV — a more mainstream language like Python has been around 3x as long and probably has > 1000x the funding and number of developers, so for the foreseeable future there will be domains in which it has more mature libraries, and the hassle of inter-language calls may not be worth it if you’re not writing any critical code in Julia. Or maybe you prefer static languages like Rust or C++, your other car is a cdr, or you are a big fan of APL and the conciseness of J. No judgement — everyone’s needs and tastes are different, and there a lot of fun languages to choose from.
(Unfortunately, it looks like this thread is headed for yet another unending collection of unrelated gripes, meta-gripes about the reactions to gripes, and heroically doomed attempts to raise the tone that fail because there is no specific actionable topic on which to focus, that festers for a few weeks until @mbauman mercifully closes the thread.)
Hah, yes, open-ended topics like these are tough. They can bring out some really interesting discussions (like the above), but everyone takes things in different directions (like the above) and discourse’s model here just isn’t great at handling that. At best, us mods split out lots of sub-threads, but that’s pretty intensive and isn’t always possible to do sensibly.
But we can learn! And try new things! Instead of festering, let’s try setting a close timer. That way, hopefully the “close” feels less pointed at any one individual. Of course, this doesn’t mean a free-for-all over the next 24 hours — we’ll still moderate flags and if things spiral further into meta-gripes and their reactions we’ll close it sooner.
As always, if there are specific things you’d still like to talk about after tomorrow, please do start a specific focused topic!
If I could suggest where this discussion goes from here, what are you yourself doing so Julia can win big?
Not a Julia wins big situation, but I’ve tried my own way of trying to make Julia win small.
Something that I used to do back in undergrad was try to solve homework problems with Julia libraries. If I found the Julia ecosystem to be incomplete/inefficient to solve undergrad curriculum I always thought that “it sucks that Julia (and its ecosystem) can’t solve a homework problem, let me see what I can do” and I’d make issues requesting features or PRs adding such functionality.
One example is when I needed to run A* on a huge graph. The existing A* requires a pre-built graph, which wasn’t possible for my problem due to the size of the graph. So I made an issue and then a package SimpleLazyGraphs.jl that solved my homework problem. The issue is now part of the Graphs.jl 2.0 milestone and I am hopeful that it will be tackled.
For student users, having a tool that can solve academic problems I think is huge for gaining traction and popularity. And I personally always wanted to the goal that I can solve my homeworks with Julia libraries.
Isn’t it possible to train a GPT on the Julia manual and package register, then give it some context on which packages you have installed. That ought to give decent search results, shouldn’t it?
Yeah, I think it’s common for libraries to ship pretty printers, e.g., llvm’s.
It’s annoying because instead of defining methods, you have to define regex matches on the types.
Fancy regex matches is IMO not a good way to do generic programming.
? I had no idea this was a thing.