Naming convention

[François Fayard]

Hi,

I would like to talk about naming convention. I think it's fine to have short names in a langage with few keywords such as C (memcpy), but a langage such as Julia that wants to be also high level with a huge standard library needs convention because the langage might become very large. I find the convention used by Mathematica the best ever made. Nothing is shortened except a few exceptions and consistent use of CamlCase. On the other hand, Matlab is probably one of the worst thing that happen in terms of naming: no consistency at all! I suspect that Cleve Moler who started Matlab not used LAPACK but also the Fortran 77 naming convention which was only there only for technical reasons ;-)

I've seen that the naming convention for function in Julia looks like the same as in Python: everything must be lowercase, and don't use underscore. Let's look at different naming conventions, the first one being the one used by Julia.

1) daysinmonth()

2) daysInMonth()

3) days_in_month()

I find the first one the most difficult to read. I tend to prefer the last one, but the second one is also easy to read. The fact that Julia uses the first one and the fact that many names are shortened, makes reading code with functions you've never seen a pain. For instance reading a name "iso..." my mind does not understand if we at talking about a function that returns a Bool ("is" suggests that) or something that has been standardised (ISO). Using the second naming convention would make things easier. Also it would prevent people using underscores as we have in the standard library without any clear reason.

I don't find any disadvantage for the second naming convention over the first one. So why do people use the first one?

[Tracy Wadleigh]

+1
I too really like the consistency and readability of Mathematica.

[Scott Jones]

Umm... the style guide for Julia says *to* use underscore for longer names, *not* camelcase:

• modules and type names use capitalization and camel case:module SparseMatrix, immutable UnitRange.
• functions are lowercase (maximum(), convert()) and, when readable, with multiple words squashed together (isequal(), haskey()). When necessary, use underscores as word separators. Underscores are also used to indicate a combination of concepts (remotecall_fetch() as a more efficient implementation of remotecall(fetch(...))) or as modifiers (sum_kbn()).
• conciseness is valued, but avoid abbreviation (indexin() rather thanindxin()) as it becomes difficult to remember whether and how particular words are abbreviated.

Personally, I think the Julia style guide gets it right... also, there have even been studies that show that words separated by _ are easier to read (>20% faster to read!) than words with no spaces and camel cased...

Scott

[Tracy Wadleigh]

I too like underscores. The thing that bugs me is that they aren't always used. I'm not a fan of conventions that involve judgment calls without an especially compelling reason.

[Scott Jones]

Yes - I think there are a lot of overshort names in some of the Julia packages/modules... for example, why is it readdlm, and not read_delim?

[David P. Sanders]

El sábado, 25 de abril de 2015, 8:21:42 (UTC-5), Scott Jones escribió:

Yes - I think there are a lot of overshort names in some of the Julia packages/modules... for example, why is it readdlm, and not read_delim?

I completely agree that readdlm is a particularly bad offender in the readability contest.

+1 for read_delim

[Sisyphuss]

I find something contradictory : http://docs.julialang.org/en/latest/manual/variables/#stylistic-conventions

Names of functions and macros are in lower case, without underscores.

[Scott Jones]

And just before that, it says this:

• Word separation can be indicated by underscores ('_'), but use of underscores is discouraged unless the name would be hard to read otherwise.

The documentation is not very consistent...

[François Fayard]

I tend to prefer names with underscores, but the Julia team has decided to use names without underscores. I don't want to change that but, I think many things need to be fixed:

- shortnames should be banned: cholfact for instance might be replaced by choleskyfactorization. Using shortnames without word separation is just a nightmare. And it's not because Matlab is a mess regarding this matter that Julia should imitate it.

- underscores should be banned: we need consistency, and there are places with underscores, some without. We could keep underscores for functions that do 2 things.

Consistency is of uttermost importance in a langage with a lot of functions in the standard library.

[Tamas Papp]

I am not sure that "banning" naming conventions is feasible in an open
source context. Also, as Scott Jones pointed out, the documentation
itself is not consistent.

I prefer underscores, and I guess I will continue using them wherever
they make sense. Perhaps people could file an issues about very
abbreviated names, but IMO cholfact is OK. Naming functions is more of
an art than a science; style guides are useful but do not necessarily
lead to unambigous rules.

Best,

Tamas

[François Fayard]

I don't want to ban any Julia user from using underscores in a name. But I think it would be nice to have consistency in the naming convention of the standard library. I've seen that a lot of names come from Matlab and Matlab happen to be (this is my advice) the worst thing that happen to the scientific community in terms of langage and naming conventions.

But you may be right. Having the consistency of a tool such as Mathematica might be something that's hard to reproduce in an open source project. It's sad, because it is something that I do value a lot. For instance, I do work on C++ projects where I am alone and I am using C++ coding guidelines.

That's why it should be nice to have a good "coding guideline" that is enforced across the Julia standard library, especially for naming convention.

[Jameson Nash]

- shortnames should be banned: cholfact for instance might be replaced by choleskyfactorization. Using shortnames without word separation is just a nightmare. And it's not because Matlab is a mess regarding this matter that Julia should imitate it.

I assume that name came from some Matlab or Numpy user. I think the more Julian might be to write this as `factorize(Cholesky, ...)` where Cholesky happens to also be the return type in this case, but also could have been a singleton type.

Part of the push to use names without underscores is to encourage users to choose names that are actually just a single word (or at most two, like the is••• methods). If you feel the method needs to have a name of does_this_and_that, it's often true that either you could have made two methods (this and that), or eliminated one of the descriptors by utilizing multiple dispatch (see the recent change from parse_•••(x) to parse(•••,x) for example)

[François Fayard]

Very nice explanation. I love the factorize(Cholesky, ...) way of doing it. It's nice to use types to convey precision on what you want to do.

[Scott Jones]

I agree - although I worry about the direction being taken currently to prevent modules from using the same name unless they know in advance about each other, and create some joint module that they can both import from in order to extend the generic function.

I think this would unfortunately end up with a lot of message like:

julia> using Base.Libdl
Warning: using Libdl.dlopen in module Main conflicts with an existing identifier.

Scott

[Christoph Ortner]

A comment in **strong support** of the Julia naming convention: these are just my personal impressions:

I think in much of numerical analysis (and to some but lesser extent scientific computing) overly short variable names are fairly popular, I think because they represent a direct translation of algorithms or formulas into code. I guess it never becomes a problem because codes or code blocks tend to be short. Similarly, I like `cholfact`; it is completely clear what is meant. While I'd be still ok with `cholesky_factorisation`, I think it is unnecessary. 

`factorize(Cholesky, ...)` is overdoing it. This is again the mistake of sacrificing simplicity of use for elegant language design. So far, Julia has relatively few of those. 

[Christoph Ortner]

A P.S.: A few people complain about Matlab's naming conventions. But something to keep in mind is that Matlab is an incredibly popular tool, largely because of its simplicity of use. Something you don't want to loose.

[Tony Kelman]

Making Cholesky just a method of factorize via dispatch is a fantastic idea that I've mentioned before, I strongly suspect we'll be implementing it at some point.

[Scott Jones]

On Monday, April 27, 2015 at 3:27:07 AM UTC-4, Christoph Ortner wrote:

A comment in **strong support** of the Julia naming convention: these are just my personal impressions:

I think in much of numerical analysis (and to some but lesser extent scientific computing) overly short variable names are fairly popular, I think because they represent a direct translation of algorithms or formulas into code. I guess it never becomes a problem because codes or code blocks tend to be short. Similarly, I like `cholfact`; it is completely clear what is meant. While I'd be still ok with `cholesky_factorisation`, I think it is unnecessary. 

An issue I have with the Julia community, is that many times it seems that people only see Julia as being important for the numerical computing community... and I think it could have much broader use... (yes, the introduction states that it is also for general computing, but that seems to be forgotten frequently...)

How is `cholfact` completely clear to the general programming community?   I bet most people, just seeing the name, would think it was some fact about "chol"...

Same thing with the explanation of why * was used for string concatenation (that it screamed "not commutative"... but, I'd also bet, that at least 9 out of 10 college graduates

would assure you that multiplication *was* commutative, and could point you to a ton of results on Google to back that up!) [I *do* understand that in matrix multiplication, a dot product is not commutative, but how many people, even well educated people, would know that...])

The name Cholesky looks like it might be something about a hole in the sky, actually ;-)

[François Fayard]

Matlab might be popular for many reasons, but not for the consistency of the tool. The advantages of Matlab are:

-1- When it started, it was the only tool with numerical and graphic libraries

-2- It was difficult to shoot yourself in the foot with it (think about out of bound array access)

-3- It was easy to deal with for scientist with no computer science background

-4- It was a collection of libraries with curated versions that work well together

-5- Many people give you Matlab scripts nowadays

Python also solved those problems (except the 4th one which could be tricky to solve in an open source project) and is also an interesting contender. But people don't use Matlab because of "nice naming conventions". Matlab just shows that it was once possible to build a tool with far less consistency than in today's open source projects.

It still believe that naming convention is something important to deal with. One should write code that is easy to read by other people, not easy to type for the developer. We have tools to help programmers doing that, and tools are always better with consistent naming conventions.

[Tamas Papp]

On Mon, Apr 27 2015, Scott Jones <scott.pa...@gmail.com> wrote:

> How is `cholfact` completely clear to the general programming community?
> I bet most people, just seeing the name, would think it was some fact about
> "chol"...

If there are indeed such people and they are wondering about the
function, they can just type help(cholfact) and figure it out.

The reverse problem (finding the function that does what you want,
instead of figuring out what a given function does) is much more common
and difficult to solve, which is why I think that
factorize(Cholesky,...) would be just awesome.

> Same thing with the explanation of why * was used for string concatenation
> (that it screamed "not commutative"... but, I'd also bet, that at least 9
> out of 10 college graduates
> would assure you that multiplication *was* commutative, and could point you
> to a ton of results on Google to back that up!) [I *do* understand that in
> matrix multiplication, a dot product is not commutative, but how many
> people, even well educated people, would know that...])

I guess that 90% of people who have a college degree and program had
some exposure to intro linear algebra, so they might know it. The rest,
of course, are out of luck and will have to google it, which is not a
big deal.

While I agree that * for strings is unfortunate (in fact, I don't think
that strinng concatenation warrants infix syntax), IMO this whole issue
is a red herring: all languages have quirks like this, and while
minimizing the number of them is a worthy goal, I wouldn't think that
these pose the greatest conceptual difficulty when learning Julia.

Best,

Tamas

[François Fayard]

While I agree that * for strings is unfortunate (in fact, I don't think
that strinng concatenation warrants infix syntax), IMO this whole issue
is a red herring: all languages have quirks like this, and while
minimizing the number of them is a worthy goal, I wouldn't think that
these pose the greatest conceptual difficulty when learning Julia.

It did not know the * convention. It is more than unfortunate. I think it is a major mistake. I have seen Stefan Kaprinski talking about a ring of strings. It does not make any sense as a ring needs 2 operations + and *. If one want to go into mathematics, the set of strings looks more like a Z-module (a kind of vector space over the ring Z).

1) "ab" + "" = "ab"

2) "abc" + "def" = "abcdef"

3) 3 * "abc" = "abcabcabc"

Well it not even true as 2 * ("ab" + "cd") = 2 * "abcd" = "abcdabcd" which is different from 2 * "ab" + 2 * "cd" = "ababcdcd". And there is no string s such that "ab" + s = "". So this all story of "math" is just wrong.

Isn't there a way to fix it ?

[Toivo Henningsson]

Strings are do not form a ring, but just a monoid.

[François Fayard]

It totally agree on this point. It does not rules out the * notation, but there is not a single argument to say that it is better than +. As + is used by many languages, it should be the right choice.

[Tamas Papp]

I guess that the fix itself is trivial (simply remove the method
definition or change its name), but the associated costs may not be
(breaking code), and from the discussion in the issues it looks like the
decision has not been made yet.

Again, I do think that * and ^ for strings is not an ideal choice, but I
am still surprised how often this issue crops up and how strongly people
feel about these infix ops. Its not like one has to use them, if you
don't like * or ^ for strings, there are `string` and `repeat` and a few
other alternatives which may be more suitable in certain cases. This is
what I do at the moment.

Perhaps limiting the number of discussion threads about
*(s::AbstractString...) to 1/month would not be a bad idea :P

Best,

Tamas

[Yuuki Soho]

There's one argument for * over +. That string concatenation is not commutative, and that + main property is to be commutative.

Personally I don't mind * for string concatenation. If anything I would prefer to have matlab style concatenation, using []; it would make sense to use concatenation syntax for concatenation.

[François Fayard]

I have no idea how much it would cost too change * to + for string concatenation. That's where you value tools such as clang-modernize on C++ or corresponding tools on Go. Perhaps the best way to get rid of it is to enforce the change.

Maybe allowing + and * for a few iterations, and removing * before 1.0. Then you won't hear about it anymore. Otherwise, people will rightly complain about it for a long time.

[Scott Jones]

On Monday, April 27, 2015 at 8:27:59 AM UTC-4, Tamas Papp wrote:

On Mon, Apr 27 2015, Scott Jones <scott.pa...@gmail.com> wrote:

> How is `cholfact` completely clear to the general programming community?  
> I bet most people, just seeing the name, would think it was some fact about
> "chol"...

If there are indeed such people and they are wondering about the
function, they can just type help(cholfact) and figure it out.

The reverse problem (finding the function that does what you want,
instead of figuring out what a given function does) is much more common
and difficult to solve, which is why I think that
factorize(Cholesky,...) would be just awesome.

> Same thing with the explanation of why * was used for string concatenation
> (that it screamed "not commutative"... but, I'd also bet, that at least 9
> out of 10 college graduates
> would assure you that multiplication *was* commutative, and could point you
> to a ton of results on Google to back that up!) [I *do* understand that in
> matrix multiplication, a dot product is not commutative, but how many
> people, even well educated people, would know that...])

I guess that 90% of people who have a college degree and program had
some exposure to intro linear algebra, so they might know it. The rest,
of course, are out of luck and will have to google it, which is not a
big deal.

 

???

I think you are *way* off base with that (and this, to me, is an example of the rarified world it seems a lot of the Julia community lives in! ;-) )

1) A large number of people who program do NOT have CS degrees, or have even had a single CS course (probably the vast majority, actually)

2) Even at places like MIT, linear algebra is not a requirement for a 6.3 (CS) degree (at least, it wasn't 30+ years ago)

3) Even for people who've had linear algebra (like me, I did take 18.06, the linear algebra course),

    * does not "scream" non-commutative, in fact, I still think of * as generally being commutative, and would explicitly

    say "matrix multiplication" if I were talking about the non-commutative matrix operation.

4) If you Google "commutative", guess what you find?  Pages upon pages that say commutative property of multiplication!

    In fact, the *very top* result is this:

com·mu·ta·tive
ˈkämyəˌtātiv,kəˈmyo͞otətiv/
adjective

MATHEMATICS

involving the condition that a group of quantities connected by operators gives the same result whatever the order of the quantities involved, e.g., a × b = b × a.

To me, if I saw "string" * foo, that would "scream" repitition, NOT concatenation... (and I hold that if you did a survey, outside of the Julia community, that at least

90% of programmers would say the same thing)

So, I hope that lays to rest the justification of using * for string concatenation... it simply was a very bad choice, and I *really* wish it would be changed ASAP...

(at least, use a new operator [not overload some other binary operator] that also works for concatenation of vectors, and deprecate the confusing use of * for

string concatenation...)

While I agree that * for strings is unfortunate (in fact, I don't think
that strinng concatenation warrants infix syntax), IMO this whole issue
is a red herring: all languages have quirks like this, and while
minimizing the number of them is a worthy goal, I wouldn't think that
these pose the greatest conceptual difficulty when learning Julia.

It is a pretty big one, I think, for people coming from most any other language...

+,  &, _, ||, .. are all infix operators for string concatenation in other languages... + being by far the most common [not that I think that ANY numeric operator

should be overloaded for string concatenation in Julia]

I can tell then that you don't do much string processing... Nobody would want to use Julia if you didn't have infix syntax for one of the most common operations!

Sorry, but I feel that that's insane... dot product warrants infix syntax, but string concatenation does not???

 

Best,

Tamas

 

[Scott Jones]

On Monday, April 27, 2015 at 9:50:10 AM UTC-4, Yuuki Soho wrote:

There's one argument for * over +. That string concatenation is not commutative, and that + main property is to be commutative.

And most people think of * as being commutative also...

I would be strongly against overloading *any* binary numeric (or boolean) operator to use for string concatenation.

Many times, you need to use vectors of characters for mutable strings... but + and * have very different meanings for vectors in Julia.

a * b, if a is a Vector{UInt8}, will multiply each element by b, but a * b, if a is a ASCIIString or UTF8String, concatenates them...

Very confusing, and not good at all.

Personally I don't mind * for string concatenation. If anything I would prefer to have matlab style concatenation, using []; it would make sense to use concatenation syntax for concatenation.

I had suggested the Lua .. operator, but it seems that was wanted for ranges (I thought : was used for ranges in Julia though),

[] would be perfectly fine, and if it is easily understandable to the *current* Julia community (I think that the community will extend far outside the numerical computing world in the future), and not confusable to those outside the numerical computing world, that would be great!

Scott

 

[François Fayard]

That's a point. One should see * as a monoid operator rather than multiplication in the number meaning. I get it.

But I still believe that we are going way too far. I thought that all those algebra stuff "for everyone" was just a bad habit in the french education system for mathematics in the 70s (a total disaster if you want my point of view as a former math teacher). If you go this far, let me state :

1) + should not be used for floating point numbers as it is not associative (a + b) + c != a + (b + c)

2) * should not be used for floating point numbers as it is not associative (a * b) * c != a * (b * c)

If we go this far, we'll be in real trouble.

Yes, + for strings is not commutative. So what? It does not lead to some substantial problems.

Anyone coming from another langage will think "abcd" * s  as "abcd...abcd", not a concatenation of 2 strings. It is especially dangerous in a langage where types are not always explicit. I've seen a talk yesterday on cppcon 2014 where they enforce C++ guys to code in a way that a Python developer should understand unless there is a very good reason not to do so.

[Scott Jones]

On Monday, April 27, 2015 at 9:50:10 AM UTC-4, Yuuki Soho wrote:

There's one argument for * over +. That string concatenation is not commutative, and that + main property is to be commutative.

Personally I don't mind * for string concatenation. If anything I would prefer to have matlab style concatenation, using []; it would make sense to use concatenation syntax for concatenation.

+100 to the suggestion of using [] for a general concatenation operator! 

(could ^ be deprecated as well, and replaced with something that also doesn't look either like bitwise XOR or exponentiation?)

[Scott Jones]

Changing to + would still run into the problems where you are using vectors of UInt8, UInt16, UInt32 (or Char), for mutable strings.

Not good either.

Add [] for general concatenation, (i.e. like vcat on vectors/arrays), and and add a compiler warning for * suggestion replacing with [], and remove * for strings by 1.0.

(Add something else (maybe !*, or does MatLab or some other language have a repetition operator that is not overloading some numeric meaning?) for general repetition of strings/vectors, and do the same with warnings for ^ and removal by 1.0).

It seems to me, that the people who don't use or care that much about strings, are the ones who say, just use string() or repeat(), no need for a *good* non-confusable

infix operator... and the people who really do work a lot with strings want this changed ASAP. ;-)

[Tony Kelman]

.* is the operator for elementwise multiplication, * on two 1-dimensional vectors does not work.

There's also a very strong desire from people who've been using the language for some time to remove the concatenation semantics from [], and separate array literal construction from array concatenation. So trying to introduce [] for string concatenation is unlikely to be very popular. Otherwise what would you use as syntax to create an array of strings for example?

[Kevin Squire]

Just a note, Matlab-style [a b] concatenation has been deprecated in Julia v0.4.  See the linked issues for details.  The main issue is that this functionality makes it challenging to create arrays of arrays (or arrays of ranges), which are less useful in Matlab, but quite useful for general programming.

Aside: a colleague who was a pretty proficient perl programmer found it quite confusing that "+" was used for string concatenation in Python, because he couldn't understand how you could add two strings...

Cheers!

   Kevin

[François Fayard]

Looks like a nice move.

On Monday, April 27, 2015 at 4:16:19 PM UTC+2, Scott Jones wrote:

Add [] for general concatenation, ... and remove * for strings by 1.0

[Scott Jones]

On Monday, April 27, 2015 at 10:09:23 AM UTC-4, François Fayard wrote:

That's a point. One should see * as a monoid operator rather than multiplication in the number meaning. I get it.

But I still believe that we are going way too far. I thought that all those algebra stuff "for everyone" was just a bad habit in the french education system for mathematics in the 70s (a total disaster if you want my point of view as a former math teacher). If you go this far, let me state :

1) + should not be used for floating point numbers as it is not associative (a + b) + c != a + (b + c)

2) * should not be used for floating point numbers as it is not associative (a * b) * c != a * (b * c)

If we go this far, we'll be in real trouble.

Yes, + for strings is not commutative. So what? It does not lead to some substantial problems.

The problem is not there, the problem is elsewhere, when you need to work with mutable strings, i.e. as Vector{UInt8} or Vector{UInt32}.

+ means something totally different then.

*Any* overloading of numeric / boolean operators that can operator on Vectors or Arrays causes problems (and is simply confusable).

Using something like [] takes just a minute to figure out, just like learning that .. in Lua is string concatenation... no confusion.

Using + or * means you are always wondering just what the code is doing.

 

Anyone coming from another langage will think "abcd" * s  as "abcd...abcd", not a concatenation of 2 strings. It is especially dangerous in a langage where types are not always explicit. I've seen a talk yesterday on cppcon 2014 where they enforce C++ guys to code in a way that a Python developer should understand unless there is a very good reason not to do so.

Yes... I also always coded this way, since I was programming in C,C++, Java, and a language that had strict left-to-right evaluation of expressions where there was no precedence...

i.e.  A + B / C meant (A + B) / C, not A + (B/C), so in my ObjectScript code, I always wrote (A + B)/C, and in my C/C++/Java code, if I meant A + (B/C), I wrote it with the parenthesis also, even though they weren't strictly necessary.

Scott

[François Fayard]

Couldn't we use <> for concatenation like in Mathematica?

[Scott Jones]

On Monday, April 27, 2015 at 10:21:11 AM UTC-4, Kevin Squire wrote:

Just a note, Matlab-style [a b] concatenation has been deprecated in Julia v0.4.  See the linked issues for details.  The main issue is that this functionality makes it challenging to create arrays of arrays (or arrays of ranges), which are less useful in Matlab, but quite useful for general programming.

I thought the suggestion was for `a [] b`...

I hadn't seen `[a b]`, it seems pretty bad to me also...

I did run across `[a ; b]`, which I don't like at all either... it seems you are giving the ; special meaning only when it is between [ ].

Why does `a ; b` mean evaluate a, then b, and return b, but `[ a ; b ]` mean concatenate a and b? To be consistent, `[a ; b]` should return a

one element array `[a]`.

The syntax [a , b] seems to return the same thing as [a ; b], is there a difference?

The [a b] syntax doesn't seem to be deprecated in v0.4, at least, it is still in the documentation for latest...

 

Aside: a colleague who was a pretty proficient perl programmer found it quite confusing that "+" was used for string concatenation in Python, because he couldn't understand how you could add two strings...

Any of the many M/Mumps, ObjectScript, Multivalue or Pick programmers would tell you, it *obviously* means take the numeric interpretation of the string(s),

and add them together!

They get all confused when they see + used for concatenation, instead of having a dedicated concatenation operator.

Scott

[Scott Jones]

<> means not equal to in some languages, but that may not be that important, and if it is familiar to the a lot of the current Julia community, it could be a good choice.

[Scott Jones]

I just remembered, it is the inequality operator in SQL... probably not a good idea to use it!

You don't like have `[]` as an infix operator? (not `[a b]`!)

Scott

[Tony Kelman]

[] already has a meaning, it's an empty array. Trying to make it an infix operator sounds like making a complicated parsing situation even worse.

[François Fayard]

I tend to think as brackets as containers for things. That's why I am not a big fan.

What do you think of string1 ~ string2 ?

[Yuuki Soho]

On Monday, April 27, 2015 at 4:21:11 PM UTC+2, Kevin Squire wrote:

Just a note, Matlab-style [a b] concatenation has been deprecated in Julia v0.4.  See the linked issues for details.  The main issue is that this functionality makes it challenging to create arrays of arrays (or arrays of ranges), which are less useful in Matlab, but quite useful for general programming.

As I understand it, only [a, b] is deprecated, with [a b] and [a; b] still being valid horizontal and vertical concatenation.

I find a bit inconsistent that [a b] means something different when a and b are string as opposed to arrays, but maybe that rest upon the wrong idea that string are array-like objects.

[Scott Jones]

I had actually suggested

On Monday, April 27, 2015 at 10:59:48 AM UTC-4, François Fayard wrote:

I tend to think as brackets as containers for things. That's why I am not a big fan.

What do you think of string1 ~ string2 ?

I had actually suggested that... I still think it is a good idea, but I think some other packages already pre-empted it's use as

a binary operator (in a way that didn't really make much sense to me - I'd suggest that DataFrames not use ~, and use ~

for string concatenation.

It is very troubling to me that packages are overloading single characters, in such a way that those cannot be used for the core language,

(without breaking those packages)

(if they overload it ONLY using their own types, that's another issue entirely, as the compiler could still disambiguate)

Scott

[Scott Jones]

Good point... so down with [] also :-(

[Scott Jones]

Why is it a wrong idea that strings array-like objects?

If you need to use mutable strings (which is most cases for what I'm doing), you need to treat strings as vectors.

Scott 

[Kevin Squire]

For some interesting reading, here are some previous discussions on the topic of string concatenation:

https://groups.google.com/d/msg/julia-dev/43N5oYSHWdc/zPVmEVDZ5MwJ

https://groups.google.com/d/topic/julia-dev/4K6S7tWnuEs/discussion

https://github.com/JuliaLang/julia/issues/2301

https://groups.google.com/d/topic/julia-users/nQg_d_n0t1Q/discussion

Cheers,

  Kevin

[François Fayard]

It comes back to the C++ coding guide from Google. One of the most important rule is : "don't polute the global namespace".

[Tamas Papp]

~ is an implementation of R's formula interface, which many find useful,
even essential for statistics; calling it "pollution" is a somewhat
heterodox use of the term.

See
https://github.com/JuliaStats/DataFrames.jl/blob/master/test/formula.jl
for nice examples.

Best,

Tamas

[Scott Jones]

1) How readable is that though, unless you know R already?   `f = y ~ x1 + x2` really doesn't mean anything at all to me...

2) People say that we should just use `string(a,b,c)` and `repeat(a,n)` for string concatenation and repetition...

    that makes no sense for code where you find many string concatenations in the same line...

3) Even in the code you referenced, the operator is only used once every few lines... so why

    not have it be:  `formula(y,x1+x2)`  or `@formula(y,x1+x2)` instead?

    That seems MUCH more readable to me, and doesn't seem like an undue burden on people using DataFrames,

    as it doesn't seem to be used that frequently...

Scott

[Kevin Squire]

Also note that other packages are free to define ~ (as a macro) for their own purposes (although there will be a warning when they try to use DataFrames).

julia> macro ~(s1, s2)

          :(string($s1, $s2))

       end

julia> "Hello" ~ " World!"

"Hello World!"

julia> using DataFrames

Warning: using DataFrames.@~ in module Main conflicts with an existing identifier.

julia> "Goodbye" ~ " World!"

"Goodbye World!"

DataFrames (or ~, at least) did get special treatment here (see https://github.com/JuliaLang/julia/issues/4882).  I think this is quite reasonable--even though Julia is a general purpose programming language, it does target scientific computing users first!  

And just because it's less readable to you doesn't make it so for everyone.  As you pointed out, for users coming from R or those who do Bayesian modeling (I do!), y ~ x1 + x2 is very understandable.  (And it's quite reasonable that those without those backgrounds would find it weird... we all come with our own baggage!)

So please, continue to say what you like and find useful and what you find weird... but don't expect everyone to agree with you. ;-)

Cheers,

   Kevin

[François Fayard]

So let's forget about ~ as it is already used by DataFrames which is a very important package.

I just found that the project Coq is using ++ for string concatenation. It has the advantage of not overloading + and still be similar to Python's +. What do you think ?

[Patrick O'Leary]

On Monday, April 27, 2015 at 11:19:31 AM UTC-5, François Fayard wrote:

I just found that the project Coq is using ++ for string concatenation. It has the advantage of not overloading + and still be similar to Python's +. What do you think ?

(And Haskell, as discussed in innumerable prior conversations on this topic.)

Should we start a julia-stringconcat mailing list? This topic generates a lot of heat, clearly, and has been derailing a number of otherwise interesting threads, and I would like to read the !stringconcatenation (or maybe !string_concatenation, or !strcat...I'm trying to bring this back around to the original subject...) parts.

Not trying to pick on you specifically; I'd start a new thread but it would inevitably become another discussion on concatenation syntax. (This might be the Julia discussion corollary to the Second Law of Julia Type Dynamics I expressed way back in https://github.com/JuliaLang/julia/issues/524#issuecomment-4409760)

Alright, got that off my chest. Feeling better now.

Did Python have this much trouble when they introduced ''.join([...])?

[Jacob Quinn]

Official Julia issue to deprecate *, ^: https://github.com/JuliaLang/julia/issues/11030

[François Fayard]

On Monday, April 27, 2015 at 6:37:34 PM UTC+2, Patrick O'Leary wrote:

On Monday, April 27, 2015 at 11:19:31 AM UTC-5, François Fayard wrote:

I just found that the project Coq is using ++ for string concatenation. It has the advantage of not overloading + and still be similar to Python's +. What do you think ?

(And Haskell, as discussed in innumerable prior conversations on this topic.)

I was just trying to find a good notation. This one seems to be the best to me so far.

Did Python have this much trouble when they introduced ''.join([...])?

I hope they had. It's very bad ;-)

Sorry for that, I am new to Julia and I did not know all the discussion on that topic. As you seem to know the history of the string concatenation syntax, do you know what is the position of the project leaders? "too late to change", "we might change when we have a good syntax" ? 

[Patrick O'Leary]

See also https://github.com/JuliaLang/julia/issues/11030

(They came up with julia-infix-operator-debates for the alternative mailing list, which is a better suggestion.)

[François Fayard]

Thanks

On Monday, April 27, 2015 at 6:55:15 PM UTC+2, Patrick O'Leary wrote:

See also https://github.com/JuliaLang/julia/issues/11030

[François Fayard]

Back to the original discussion, I just came across sprandn in another thread. How the hell do you want someone to have a feeling of this function? I still have no idea what the n is for.

[Patrick O'Leary]

On Monday, April 27, 2015 at 2:18:50 PM UTC-5, François Fayard wrote:

Back to the original discussion, I just came across sprandn in another thread. How the hell do you want someone to have a feeling of this function? I still have no idea what the n is for.

Providing information only--random samplers with an "n" suffix mean the sample is from a normal distribution. Breaking it down:

sp prefix: this is a method for sparse matrices

rand: that produces random samples

n: from a normal distribution

[François Fayard]

Ok thanks. I did not think about normal. And my background is mathematics (and I don't want to know Matlab ;-) ). Imagine how puzzling it could be for many people.

It totally violates the "Style Guide" which claims: "conciseness is valued, but avoid abbreviation (indexin() rather than indxin()) as it becomes difficult to remember whether and how particular words are abbreviated."

[Patrick O'Leary]

On Monday, April 27, 2015 at 2:36:40 PM UTC-5, François Fayard wrote:

Ok thanks. I did not think about normal. And my background is mathematics (and I don't want to know Matlab ;-) ). Imagine how puzzling it could be for many people.

It totally violates the "Style Guide" which claims: "conciseness is valued, but avoid abbreviation (indexin() rather than indxin()) as it becomes difficult to remember whether and how particular words are abbreviated."

The chronology goes more like, "we had a method named `sprandn`, then someone wrote a style guide which contradicts it." As you correctly guessed/looked up this name is from the MATLAB branch of the Julia family tree.

I suspect sparse matrix users will grab pitchforks if you force them to prepend the full word "sparse" to every one of their method names. (I live in a dense matrix universe and have no dog in that fight.)

[François Fayard]

Thanks for the nice explanations. I guess that in the open source world, it is very difficult to enforce consistency.

[Jiahao Chen]

For sparse matrix functions, Matlab's nomenclature is the de facto standard, since providing a high level interface to sparse matrices is a Matlab innovation. Renaming these functions can be considered, but will doubtless offend the sensibilities of those accustomed to other languages.

[Scott Jones]

Why can't we have our cake and eat it too?

I'd suggest that all of these methods be given maximally understandable names...

such as sparse_random_normal for sprandn.

Can't you then simply define sprandn as an alias for sparse_random_normal?

Would there be maybe a to have only the long names exported normally, and then setting up the aliases if you want them...

Scott

[Patrick O'Leary]

On Monday, April 27, 2015 at 5:21:27 PM UTC-5, Scott Jones wrote:

Why can't we have our cake and eat it too?

I'd suggest that all of these methods be given maximally understandable names...

such as sparse_random_normal for sprandn.

Can't you then simply define sprandn as an alias for sparse_random_normal?

Would there be maybe a to have only the long names exported normally, and then setting up the aliases if you want them...

I'm not sure what that buys you if everyone uses the aliases (the long name goes unused). Or if anyone uses the aliases (you have to realize these are both the same method). Or if no one uses the aliases (then why have them?).

[Stefan Karpinski]

I'm not sure what the problem with sprandn is. If you're working with sparse matrices, you'll know what this is. If you're not, then you're unlikely to accidentally use it. Sure, it's kind of an ugly name, but it's the traditional, well-known name for this function. I don't see anyone complaining about cryptic but standard names inherited from C.

[François Fayard]

Hi Stefan,

I am just expressing my point of view here as a Mathematica user.

[1] One can't compare Julia and C. C is one of the smallest language than can exist. Therefore, small names are not too much of a problem. Julia aims to be a langage with a huge standard library (kind of "batteries included") which makes it a totally different beast than C. If you look at C++ that has a bigger library, names are more consistent. The larger the library, the more consistency is needed.

[2] I think that Matlab gets a lot of things wrong, and its naming conventions (of lack thereof) is just  nightmare. For instance why not working on something as:

   - random(distribution) : gives a random number

   - random(dimension, distribution) : gives a random matrix

   - random(sparsity_pattern, distribution) : gives a random sparse matrix

I think it fits nicely the dispatch method of Julia which is very closed to what Mathematica does.

[Glen H]

+1 for using multi-dispatch to separate concepts and to make things more readable:

cholfact -> factorize(Cholesky, ....)

sprandn -> Sparse(Normal, m, n)

The main benefit isn't readability but for speed and generality.  If you want to use a different distribution (in sprandn) or a different factorization type then than is easily parameterized and can be specialized by the compiler to make the fastest code.  This desire to stick with "defacto standards" doesn't make sense because it is coming from a different language that doesn't have multidispatch and has poor types.  

As an example, what would you call the function that factorizes polynomials?  The answer for MATLAB is "factor".  I would much rather it be:

factorize(Polynomial, ....)

This is self documenting and all factorization methods have the same name and and can be easily found.  It would be nice to also have:

?factorize(Polynomial, ....)

To return the help for how to factorize a polynomial and some way to find out all the types that can go in the first argument of factorize().  

If people are really set on not learning something new then there could be a MATLAB compatibility package that does:

cholfact -> factorize(Cholesky ...)

But that leads to bad code so I would rather it just be a chapter in the documentation for MATLAB users (or maybe a script to do the conversion).

Forwards compatibility from MATLAB doesn't exist anyways so why stick to it when it leads to worse code?

I agree with François's reasons for why people use MATLAB...it isn't because they came up with the best function names for all languages to use...it likely just happened and people got used to it.

Glen

[Jiahao Chen]

You should look at Distributions.jl, which already overloads rand to provide the functionality of the first two methods of "random" that you want.

[Glen H]

Hi Jiahao,

Distributions is an awesome example of a package that explains what I was trying to say about using multi-dispatch instead of compound function names -- a work of art.  I hope to use it in the future.  Have you had an uproar from the community that the names don't follow the MATLAB "defacto standard"?

My point was meant to be taken more general -- I was using the examples brought up in this thread. I wish multi-dispatch was used everywhere instead of underscore (or not) compound names.  Like for:

open(FileType,....) vs opentable, openmatlab, openimage, opentext, openmytype, etc.

write(FileType,....) vs write, writetable, writetable, writedlm, writecsv, writepng, writemime, etc.

rand(Type,....) vs randi, randbool, randstring, randperm, randpoisson, randfoo, etc.

many other examples

When you don't use multi-dispatch it gets very confusing how to extend something, what the interface should be, and how to write generic code that can be specialized by the compiler.  Using compound function names leads to an API explosion and I can't see any technical benefits (unless it is to ensure type stability or something like that).

Glen

[Tamas Papp]

On Tue, Apr 28 2015, François Fayard <francoi...@gmail.com> wrote:

> [1] One can't compare Julia and C. C is one of the smallest language than
> can exist. Therefore, small names are not too much of a problem. Julia aims
> to be a langage with a huge standard library (kind of "batteries included")
> which makes it a totally different beast than C. If you look at C++ that
> has a bigger library, names are more consistent. The larger the library,
> the more consistency is needed.

I think that you are ignoring the fact that, in contrast to C, Julia has
1. namespaces (modules), and 2. multiple dispatch. Both of these are
powerful, and there is a synergy between the two. Imposing some kind of
over-arching consistency, as if everything was loaded into a single
namespace, is neither necessary nor realistic.

Best,

Tamas

[Tony Kelman]

Renaming the sparse matrix functions should absolutely be done. And this is coming from a long-time former user of Matlab who works with sparse matrices much more often than I work with strings. SparseMatrixCSC is far from the only sparse matrix format in the world when you venture beyond what Matlab provides. A major shortcoming of spzeros, sprandn, etc is they are not at all generic or extensible in the output format. We should eventually use zeros(SparseMatrixCSC, ...) or something to that effect, and we can easily put deprecations in place for the current Matlab-heritage names. What will be somewhat challenging is figuring out how to coordinate this kind of restructuring along with the existing dense version of zeros, randn, etc - since these currently take an element type as an input and always output as a dense Array{eltype, N}. Since generally the container types already have their element types as a parameter, I think it would be more general to move towards asking for the complete container type of the output in functions like zeros, rather than asking for the element type.

[Tom Breloff]

+1 for factorize(MyType, ...), Sparse(MyDist, ...) and other similar examples that have been suggested.  It's only a very slight hardship for those copying their code directly from matlab, but for everyone else I think it's a big win for readability and type safety.  It's also likely easier to learn (assuming you don't already know matlab too well), since it'll be easier to guess the appropriate function name without reading through a long list of jumbled letters in function names.   Each method name will be more powerful, so I can see people having to reference docs less often.

[Andreas Noack]

I like the idea of something like factorize(MyType,...), but it is not without problems for generic programming. Right now cholfact(Matrix) and cholfact(SparseMatrixCSC) return different types, i.e. LinAlg.Cholesky and SparseMatrix.CHOLMOD.Factor. The reason is that internally, they are very different, but from the perspective of solving a positive definite system of equations they could be considered the same, and therefore they share the cholfact name.

[Yuuki Soho]

I think one should go over all the names in Base and see if there's some rules that can be applied sanely to come up with better naming scheme.

If you introduce factorize(MyType,...) and want to be consistent about this kind of things you might end up changing a lot of the functions in base. E.g.

    sqrtm -> sqrt(Matrix,...)

    hist2d -> hist(Dimension{2},...)

    ...

[Jiahao Chen]

> Distributions is an awesome example of a package that explains what I was trying to say about using multi-dispatch instead of compound function names -- a work of art.  I hope to use it in the future.  Have you had an uproar from the community that the names don't follow the MATLAB "defacto standard"?

Kindly note that the point I made about Matlab and sparse matrices was mainly historical and partly psychological, not one about rational PL design.

In the particular case of sparse matrices, Matlab had the first mover advantage because they were actually the first provider of sparse matrix functionality in a high level language. Furthermore, because most users of sparse matrices become familiar with them from a teaching environment that uses said language, they become accustomed to Matlab's spelling.

The example of Distributions makes a different point about rational design, which I am not opposed to. However, the meaning of the type annotation is not unambiguous. In some cases it refers to the _input_, and in other cases, the _output_. In some cases you may even need to annotate both the input and output types, which then strays dangerously close to function types and I/O monads.

Changing the spelling of writemime vs write(MIME) was discussed in Issue #7959, but it was difficult to disambiguate write(MIME) from other write methods IIRC.

[Scott Jones]

People who might realize, after becoming acquainted with Julia, for general computing, or maybe for some light usage of the math packages, might much rather have understandable names available, so they don't always have to run to the manual...

With decent code completion in your editor, I don't think it takes any more typing...

Also, there would be much less problems of name collision (only if you loaded the abbreviations into your module would it become as likely as now).

Just because those really short names (which had their roots back before IDEs with fancy code completion, when file names were limited to 8.3 (or 14 in Unix) characters),

became traditional, like the names of the C functions, doesn't mean that they are necessarily *good* names...

I would definitely complain about the cryptic names in C more, if there were thousands of them with short names... but as the set of functions that I'd use is very small, and generally fit a few simple patterns (such as mem*, *printf, *alloc [I'd never use the str* ones that expect \0 terminated strings anyway]), it doesn't bother me that much.

[Patrick O'Leary]

On Tuesday, April 28, 2015 at 11:56:29 AM UTC-5, Scott Jones wrote:

People who might realize, after becoming acquainted with Julia, for general computing, or maybe for some light usage of the math packages, might much rather have understandable names available, so they don't always have to run to the manual...

With decent code completion in your editor, I don't think it takes any more typing...

There's a tradeoff. Reading is more common than writing--which at first makes long names sound appealing. But long names can also obscure algorithms. So you want names to be long enough to be unambiguous, but short enough that code can look like the algorithm you're implementing. Support for Unicode in identifiers is huge in that respect, and it is nice to write a (non-CompSci, in my case) algorithm in Julia that looks remarkably like what's in the textbook. And someone else working in my domain--the people who are reviewing and modifying my code--can very quickly grok that.

If long names were unambiguously better, no one would pick on Java.

[Josh Langsfeld]

I don't know why it hasn't been mentioned (it was hinted at by Tamas) but it seems to me the clear solution is for most of Base to actually be moved into submodules like 'LinAlg'. Then to use those names, people need to call 'using LinAlg' or 'using Sparse', etc... Somebody mentioned how 'cholfact' might be confusing to generic programmer, but a generic programmer should never even see the name unless he or she goes looking for it.

I would be highly skeptical of any attempt to make the standard library a single gigantic list of function names that everyone can understand the purpose of by glancing at.

[Glen H]

Having "using LinAlg" would help to clean up the namespace of available functions for people who don't need it but what I was proposing is doing "using LinAlg" shouldn't change the API that much (if at all).  You still want to factorize numbers and polynomials (which are not part of LinAlg).  The API shouldn't grow 10x because LinAlg adds a bunch of matrix types than can also be factorized.  What I was proposing is actually a lot smaller list of fuctions to export (not more). 

For example

Using multi-dispatch:

factorize

factorize!

Not using multi-dispatch:

factor

factorize

factorize!

chol

cholfact

cholfact!

lu

lufact

ldltfact

qr

qrfact

qrfact!

bkfact

eigfact

hessfact

shurfact

svdfact

etc.

(I don't tend to pick on LinAlg in general...it is just the example brought up by this thread.  Please pick on the using multi-dispatch idea in general and not on specific errors/ommissions in the above list.)

I found multi-dispatch to be annoying at first but came around to really like it.  It made my code more generic, reduced the number of lines ("if" statements disappeared), ran faster, more modular, was more extendable and generic.  I haven't used another programming language that gives such enjoyment...but if people don't adopt multi-dispatch then these benefits dissappear.  The compound (shorthand) names will be shorter (horizontally) but the code will be less generic and you will have more lines to look at (vertically).  There are no guidelines for these compound names to follow so it is confusing for everyone except the people who have memorized these names.

[Josh Langsfeld]

Turning named functions into methods of a generic function is definitely something Julia should take maximum advantage of. It does look like it should work well in the case of 'factorize'. But I think it's a bit unrelated from the naming convention issue. Most, if not the large majority, of the standard library functions are not going to be neatly separable into generic concepts.

[François Fayard]

Sorry for being a pain, but doesn't LinAlg be LinearAlgebra? What's the point of issuing naming convention if it is not even respected by the main developers?

Besides, I really find that Julia underuses multiple dispatch. It's a big selling point of the language and it's not even used that much in the standard library! Mathematica has a kind of multiple dispatch and it's what makes the language so consistent. If people mimic Matlab, multiple dispatch will be underused.

[J Luis]

Just my opinion on this issue of long names. Generally I don't like them because they are often redundant and make code unnecessarily long.
With long lines come the mask width issues with many defending that lines should not be longer that 80 character.
If lines are long and instructions need to be broken in several lines we pay that in vertical space.

Having to scroll up and down to try to understand what a function does is orders of magnitude worst  than the little mental blink that goes between 'LinAlg' and 'LinearAlgebra'

[Iain Dunning]

Sorry for being a pain, but doesn't LinAlg be LinearAlgebra? What's the point of issuing naming convention if it is not even respected by the main developers? 

I'm glad you are apologizing, because I find the way you are expressing yourself is borderline insulting to the hard work of others (whose work you stand to benefit from, as it seems like you are just being to write Julia code going by your ODE thread).

Its not that the style guide "isn't respected by the main developers", its that some things happened organically, we're all human, we all have biases, that the style guide wasn't formalized from the start, and that perfect is the enemy of good.

Many people in this thread could do with taking a more charitable position. I see some constructive suggestions, that seem pretty darn sensible. Even better would be pull requests - anything than simply tearing down what exists. There is no shortage of people to offer opinions, but there is always a lack of people willing to actually do something about it - whether its improving documentation like the style guide, or implementing changes.

[François Fayard]

Ian. I am really sorry if I hurt people. I really respect what has been done with Julia. I kind of like when people push me in the corner because it helps me build better tools. That's why I might act this way, and I am sorry if it hurts people.

I've expressed my ideas that I would like to resume:
- I think consistency in naming is really important for big languages like Julia (as opposed to languages such as C)
- I wanted to follow a style guide, and the one I've found is not respected at all. It's a fact. When I find LinAlg, sprandn and so many other names whereas the style guide says clearly that one should avoid abbreviation, I just don't get it. If a style guide is not enforced, it is useless because it does not pass the reality test.

[John Myles White]

I think it's time for this thread to stop. People are already upset and things could easily get much worse.

Let's all go back to our core work: writing packages, building infrastructure and improving Base Julia's functionality. We can discuss naming conventions when we've got the functionality in place that Julia is sorely lacking right now.

 -- John

[François Fayard]

I've also tried to help proposing solutions to those problems, such as using multiple dispatch. But I understand the fact that my tone was not appropriate.

I was also puzzled to hear from Stefan that there is nothing wrong with sprandn, whereas the coding guideline says otherwise. It just feels like when there is a "stop sign" and nobody cares about even slowing down. Then, one of the main designer of the rules for driving looks at you and says : "So what?". It feels really weird, which might explain but does not excuse my tone.

[Jiahao Chen]

With all due respect, talk is cheap. If anyone really wants to help, submit a pull request with your proposed changes.

[Tamas Papp]

Hmm, maybe what I wrote was not clear -- I never meant to argue for
splitting into submodules. Using multipe dispatch seems like a much
nicer solution to me, ie something like

factorize(matrix, Cholesky)

which would perform a Cholesky factorization, returning an instance of
the applicable type (depending on whether matrix is sparse, etc). The
general syntax I could imagine is

factorize(matrix, factorization)

where factorization may or may not be an actual concrete type (most
often not), but simply a kind of factorization (SVD, eigen, LU, QR).

The fly in the ointment is that currently Julia cannot dispatch on
values directly (like the EQL specializer in CLOS), only on parametric
types, eg

factorize(matrix, Val{Cholesky})

Maybe it would then make sense to create an abstract type Cholesky,
which can be a supertype to all kinds of Cholesky factorizations. But of
course please keep in mind that I have been using Julia for less than a
couple of months so my perspective on interface design may not be that
valuable.

Best,

Tamas

[Tom Breloff]

+1 John... everyone back to work!  The core julia developers deserve a big pat on the back for the *incredible* attention to detail and thoughtfulness that has gone into designing the language.  I've developed in a lot of scientific and non-scientific languages, and julia constantly makes me smile how they take the best features of every language I've ever coded in, and put them together seamlessly.  No language is perfect, but you guys are trying.  Thank you for all your hard work! 

[Stefan Karpinski]

Just to clarify my position, I'm all for better and more generic APIs, but until we come up with such and have implementations for them, legacy names like sprandn aren't hurting anyone – they get the job done and they're what many people using sparse matrices are familiar with. If you want to improve the state of affairs, the best approach is not to complain about it, but to design something better, get some feedback, and implement it.

[François Fayard]

On Wednesday, April 29, 2015 at 1:58:07 AM UTC+2, John Myles White wrote:

Let's all go back to our core work: writing packages, building infrastructure and improving Base Julia's functionality. We can discuss naming conventions when we've got the functionality in place that Julia is sorely lacking right now.

I tend to disagree on this, and I still believe that good softwares need consistency in their developing process which includes

-1- Coding guidelines: naming conventions, a good error policy

-2- Proper unit testing

-3- People who takes the lead to enforce that

I've just talked to a friend who is one of the main developer of scikit-learn. They have strong coding guidelines, enforced with 2 reviewers for every patch and extended unit testing. Numpy and Scipy seem to use the same policy. Guidelines are a good way to share experience of good and bad habits, and as a new user I just need them. I might have upset people, but it would also have been nice that some main developers acknowledge once that there is a strong gap between usage and the available guideline. This lack of concern seems to have driven away other users ( http://danluu.com/julialang/ ) which makes me think that many of the main Julia developers don't seem to put the 3 points mentioned above in their priority list.

[Jiahao Chen]

François, why do you feel the need to continue irritating Julia developers by telling us what we are doing wrong?

No one is disagreeing with you that we should strive toward the ideals of proper software design and development. But with finite resources, we have to pick our battles.

Open source software doesn't magically improve because of user complaints. It DOES improve if said users would start contributing code.

[François Fayard]

On Wednesday, April 29, 2015 at 4:51:00 PM UTC+2, Stefan Karpinski wrote:

Just to clarify my position, I'm all for better and more generic APIs, but until we come up with such and have implementations for them, legacy names like sprandn aren't hurting anyone – they get the job done and they're what many people using sparse matrices are familiar with. If you want to improve the state of affairs, the best approach is not to complain about it, but to design something better, get some feedback, and implement it.

As some people have noticed, I am a new user, and I don't have an overview of the language. I only have an experience with Mathematica ans the solution they use for their system which is closed to multiple dispatch. If Mathematica has such a nice consistency, it's mainly because someone has enforced a very strict policy (my guess is that Stephen Wolfram is this guy).

I can help on designing numerical algorithms which is why I've coded a few lines for ODEs. That's my background. I don't have experience in designing guidelines, but my point is that I need them to feel comfortable in developing in Julia.

[François Fayard]

On Wednesday, April 29, 2015 at 5:00:02 PM UTC+2, Jiahao Chen wrote:

François, why do you feel the need to continue irritating Julia developers by telling us what we are doing wrong?

Open source software doesn't magically improve because of user complaints. It DOES improve if said users would start contributing code.

In all my last posts, I think that I have been careful not to upset anyone. I've expressed my ideas and I just get the feeling that they are not shared by many Julia developers. I'll let you code and I wish that my point of view turns out to be wrong and let Julia be successful.

[Tom Breloff]

It's pretty unrealistic to assume that a new language, developed by a small group of developers located around the world, will have the consistency and polish of a commercial language that has been in development for about 30 years with significant resources behind it.  It's mind boggling how well the language has turned out considering the relatively tiny resources available.  As has been stated, if you come across specific inconsistencies in design, etc, then you should take it upon yourself to either fix it or propose specific solutions.  Rome was not built in a day...

[Stefan Karpinski]

Good API design doesn't require any particular background, just clear thinking. If you like the way Mathematica does it, I strongly encourage you to study that design and make a Julian design that is inspired by it. If it makes sense, we'll be happy to adopt it.

[François Fayard]

On Wednesday, April 29, 2015 at 5:37:49 PM UTC+2, Stefan Karpinski wrote:

Good API design doesn't require any particular background, just clear thinking. If you like the way Mathematica does it, I strongly encourage you to study that design and make a Julian design that is inspired by it. If it makes sense, we'll be happy to adopt it.

Thanks for this kind comment. I've heard that Distributions.jl is very well designed and I'll try to pick up some ideas from it and Mathematica to implement them into my ODE library.