+1
I too really like the consistency and readability of Mathematica.
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.
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?
julia> using Base.Libdl
Warning: using Libdl.dlopen in module Main conflicts with an existing identifier.
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.
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.
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.
com·mu·ta·tive
ˈkämyəˌtātiv,kəˈmyo͞otətiv/
adjectiveMATHEMATICSinvolving 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.
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
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.
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.
Add [] for general concatenation, ... and remove * for strings by 1.0
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.
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...
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 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 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 ?
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.)
Did Python have this much trouble when they introduced ''.join([...])?
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.
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."
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...
You should look at Distributions.jl, which already overloads rand to provide the functionality of the first two methods of "random" that you want.
> 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.
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...
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?
With all due respect, talk is cheap. If anyone really wants to help, submit a pull request with your proposed changes.
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.
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, 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.
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.