Julia among the most loved languages

Community
1

image
image782×81 3.06 KB

15 Likes
2

Note however, that it is also one of the least “wanted” languages. Together, I think this implies that we need to be advertising more.

10 Likes
3

Julia needs to focus on more use cases as well. I see some progress on compiling relocatable binaries, but it’s still quite a ways off compared to it’s strong REPL story.

2 Likes
4

More advertising is certainly good, but there’s another thing to consider.

StackOverflow’s user base is skewed, as you could have guessed. Seeing Java used by 40% of developers and PHP used by 26% tells you its userbase is more oriented towards server deployement, web and mobile apps. Even though all those are important software fields, they are not all that’s out there. I for one have never encountered Java in any software I’ve contributed to on GitHub, and that’s a lot of software.

Julia is lacking in the sever and apps, that’s for sure. But those also highly-competitive fields, with JavaScript, TypeScript, Java, Go, Rust, even Kotlin and Dart having their already-estabilished positions. Most of the most popular repositories on GitHub written in Python, JavaScript, TypeScript and Go are made just for that world. That’s how those languages broke through. In the Julia it’s the other way around, with research software being way more popular than the production software.

Something like the following packages will certainly help the cause:

If Julia is to break into a larger userbase, more of reliable software has to be made in those fields. More integration with JavaScript will surely help.

To conclude all of that, I put a question forward. Was Julia made for the boring world of endless deployement and integration? In that world it takes 10 years for the world to move forward after introducing one breaking change.

8 Likes
5

I’ve been playing with Julia for about a month now. While I am a newbie to Julia, I am not a newbie to software development. I have developed software in many languages, some popular, some arcane.

My view of Julia at this point is:

  1. I like the language. It has a simplicity and structure that make is clearer than other languages. The typing system is excellent, but sometimes a touch confusing. I like the idea of super-typing/sub-typing. I like that you can have named parameters in function calls. I am not too crazy about function redefinition. There a a lot of other points that I think Julia rates an 7//8/9 on a 10 scale.
  2. The documentation doesn’t do as well. On my scale of 1 to 10, I would rate it about 3. I have struggled significantly with finding simple things such a punctuation definitions, clear explanation of function calls, explanations of modules–how they work, what they do, etc.–just to name a few. It does me no good to read a circular function definition–I can usually infer that a function, “GetABC() returns ABC”. I prefer some knowledge of how it gets ABC as well as the source of ABC.
  3. Debugging–on a scale of 1 to 10, again I would rate it at a 3. Debugging needs to be easy and timely to use. Juno is a giant step forward, but is slow and sometimes error prone or cumbersome when working with a substantial piece of code. REPL is quite handy for 5-10 lines of code but I haven’t found how to use it in large code chunks.

These are my impressions after only 30 days or so of working with Julia. I don’t want to fault the developers for what they have accomplished–it is fantastic! But, for Julia to advance, I believe it needs to step up the documentation and development environment.

Just my thoughts…

11 Likes
6

I am feeling your confusion with the documentation and debugging. However, I don’t think the situation on either is any better in virtually any general-purpose language. Speaking from personal experience, the processes you’ve described are way more terrible in Python, C, C++ and JavaScript, all considered first-class programming languages. Since the other languages have been floating around longer, they usually have the IDEs and other tools that remedy such terribility.

Here are simple possible workarounds for your points:
2. reading the standard library’s source definitions yourself (e.g. in GitHub - JuliaLang/julia: The Julia Programming Language), as they are (mostly) written in Julia and not C/C++
3. extensively using @which and other interactive utilities

That may or may not help you, but then again, I don’t think what you’re asking for is easy to give.

Edit: this thread is also worth checking: What Juno features do you use most?

3 Likes
7

Thanks for the references–I’ll check them out.

I am a extremely frequent user of julia’s language documentation–I have installed a local copy of docs.julialang.org just to speed up access.

I have also ordered two books from Amazon on julia (haven’t come yet)–Hands On Design Patterns… and Julia Quick Syntax Reference.

I have been using QT Creator a lot over the past 3 years and I guess I have gotten spoiled by the QT environment. Usually, each function has a 3 or so lines to demonstrate the call and expected results. I have done a cut-and-paste of the String trimmed() function documentation below. (BTW, I’m not saying that Qt is perfect, just offering a different example of software documentation. There are others styles that has pluses and minuses as well.)

To bottom line it, my thinking is that Julia is an excellent product technically. But I am finding the learning curve pretty steep. For Julia to become more widely accepted and mainstream (which I would to see), I think the learning curve needs to be flattened a lot.

Just thinking…

Thanks again.

Qt String trimmed function documentation follows

QString QString::trimmed() const

Returns a string that has whitespace removed from the start and the end.
Whitespace means any character for which QChar::isSpace() returns true. This includes the ASCII characters ‘\t’, ‘\n’, ‘\v’, ‘\f’, ‘\r’, and ’ '.

Example:

QString str = " lots\t of\nwhitespace\r\n ";
str = str.trimmed();
// str == “lots\t of\nwhitespace”

Unlike simplified(), trimmed() leaves internal whitespace alone.

See also simplified().

2 Likes
8

Here’s the Julia documentation for strip, for comparison:

help?> strip
search: strip rstrip lstrip AbstractDisplay string stride String strides StridedArray StridedVector StridedMatrix StridedVecOrMat StringIndexError

  strip([pred=isspace,] str::AbstractString) -> SubString
  strip(str::AbstractString, chars) -> SubString

  Remove leading and trailing characters from str, either those specified by chars or those for which the function pred returns true.

  The default behaviour is to remove leading whitespace and delimiters: see isspace for precise details.

  The optional chars argument specifies which characters to remove: it can be a single character, vector or set of characters.

  │ Julia 1.2
  │
  │  The method which accepts a predicate function requires Julia 1.2 or later.

  Examples
  ≡≡≡≡≡≡≡≡≡≡

  julia> strip("{3, 5}\n", ['{', '}', '\n'])
  "3, 5"

It seems similar to the QT documentation, except that Julia has 3 methods and only one has an example. I agree it would be good to have an example for each method.

2 Likes
9

One thing I sometimes find confusing about docstrings in certain packages is that keyword arguments are not listed and I have to dig through the code to find them. Even some documentation pages lack these descriptions. I don’t have an example in mind at the moment.

2 Likes
10

Agreed. There are a handful of possible interpretations; I understood those results as “everyone who is interested in Julia is already using it” (eg great conversion ratios). That is certainly assuming a correlation that may or may not exist, but certainly suggests that more publicity for Julia would have a significant return on invested time/money.

11

everyone who is interested in Julia is already using it

Matlab and R still have a significant user base. Even with legacy software excluded, there still
may be many users who are interested to switch to Julia.

2 Likes
12

Documentation is also what I think Julia is really bad at. I’ve used R a lot (and a long list of languages since the 1980s), including developing packages, and the situation there is different. If you want your package in the standard repository (CRAN), you must document every argument of every public function. There are also facilities for ensuring that the documentation, e.g. the list of arguments, matches the actual function definition. In short, function documentation isn’t just a string, it’s a structured document with some required fields which must match the actual function. And facilities (like Roxygen) for writing the docs.

In addition, any package can have accompanying PDFs (vignettes) and demo-scripts and examples easily runnable in R, and tagged fields with links to relevant published papers, even JEL and MSC-classifications. All in a uniform format.

The documentation may of course anyway be poor, you can in principle write “blah blah” or some other gibberish, but it is a good incentive to actually write the documentation (which most programmers hate).

3 Likes
13

I have a background in Physics, Statistics and Operations Research. Nowadays I teach college level data analysis courses, and I head up an analytics department in a (tiny) financial organization.

I love Julia. It was love at first line of code as coding in Julia is way more succinct and expressive and elegant and performant than anything else out there for Scientific Computing and Data Science. I love it so much that I teach my students Julia in my data wrangling and statistics courses. I love it so much that I’ve adopted it for Data Science use in my (tiny) department. I love it so much that I teach Julia for Data Science amongst my network of Data Scientists in Toronto just to share the Joy of using Julia and to show them a bright new future.

Julia is still young, it has a lot of potential to grow and mature. In as much as Julia is fantastic for scientists (all the brilliant regular contributors here) who are heavy into package development, I think we should also nurture the much bigger audience of practitioners who just want to use a tool to solve a business or engineering problem.

JuliaCon is focused on Julia’s future development directions and brilliant people pushing various frontiers, which is great. Perhaps there is room for beginners and industry practitioners, a Julia User’s Conference where the focus is on simple usage and practical case studies of using Julia to solve problems. Just a thought.

9 Likes
14

I’m going to play devils advocate and say that Julia is no longer a new language. If it were a javascript framework, 8 y/o would already be six feet under

The main problem I see with Julia is that it isnt undergrad friendly. It seems like boot speed and simplicity take a back seat pretty often. Young people want things that are fast and easy

// sometimes it seems like developers here think those two things are a weakness. either packages will be sped up in a couple months (which seems to never come) or you should need to type multiple arcane commands to do something that should have been a one liner

the other problem i see is that many julia people think web dev is below them, a job for plebs and not phds. in reality 95%+ of programmers work on the web. i think it would be better to embrace the community than cast them outsiders

5 Likes
15

I would specifically like to refute the part about package loading not getting faster. In 1.4.0, using Plots took 11.6s. In 1.5 beta, it takes 5.7s. Julia doesn’t have one magic bullet to fix this, but it has gotten and continues to get significantly better.

7 Likes
16

And in v1.3 in the Plots version before the snoopcompile was added, it was more than 30 seconds on most computers we tried. And on v1.0 it was almost a minute. This progression has been going on for years, so it’s very clearly getting better. If you don’t believe me, go back to Julia v1.0 and the Plots.jl release at that time and time it.

2 Likes
17

@ChrisRackauckas interestingly, 1.0.5 with the most recent Plots is only 5 seconds. Any idea why?

18

The snoopcompile must be doing a ton there? That’s odd :laughing:. If you go back before the snoop it was terrifying.

19

oh wait, v1.0.5? I wonder if that got some of the compile time stuff backported. v1.0.0 had some pretty awful compile times.

20

If you linked me to 1.0.0, I’ll take a look.