Re: [julia-users] Re: movingpastasquishedcaseconvention?

2015-02-06 Thread Ivan Ogasawara
I prefer underscore, because it is the same used for constant's name.

2015-02-06 7:26 GMT-02:00 Steven Sagaert steven.saga...@gmail.com:

 I prefer Java's camelcase: searchSortedLast: it's the same length as all
 lower case but clearer.


 On Thursday, February 5, 2015 at 8:12:43 PM UTC+1, David James wrote:

 Hello,

 The title of this post is Moving Past a Squished Case Convention not
 Moving Pastas Quiche :)

 The Julia standard library tends to use the squishedcase notation.
 Being concise is great for mathematical functions, like sin, cos, and ln.
 However, it is cognitively harder for people for compound function names;
 e.g. searchsortedlast. Such a naming convention flies in the face of real
 programming experience. It makes programming harder for people.

 There are many sane ways to name functions. Lisps tend to use hyphens,
 others often use underscores. R libraries use a non-standard mix [1].
 Interestingly, the Julia parser code itself uses hyphens; e.g.
 prec-assignment and prec-conditional: https://github.com/JuliaLang/
 julia/blob/master/src/julia-parser.scm

 It would be a shame for squishedcase to persist as the language reaches
 1.0. What are some possible ways to address this problem without breaking
 compatibility in the short-run?

 I see a possible solution. Choose a character and encourage its use to
 break apart words; e.g. -, _, or a middot (·) [2]. Make it highly
 recommended but non-breaking until 1.0. Deprecate
 functionsusingsquishedcase.

 Julia is great overall but lacking in this way. Let's make it better.

 Sincerely,
 David

 [1] http://stackoverflow.com/questions/1944910/what-is-
 your-preferred-style-for-naming-variables-in-r

 [2] The middot is relatively unobtrusive and doesn't take up much space
 horizontally, e.g. search·sorted·last. It is also useful for variables
 representing compound units; e.g. N·m.






[julia-users] Re: movingpastasquishedcaseconvention?

2015-02-06 Thread Steven Sagaert
I prefer Java's camelcase: searchSortedLast: it's the same length as all 
lower case but clearer.

On Thursday, February 5, 2015 at 8:12:43 PM UTC+1, David James wrote:

 Hello,

 The title of this post is Moving Past a Squished Case Convention not 
 Moving Pastas Quiche :)

 The Julia standard library tends to use the squishedcase notation. Being 
 concise is great for mathematical functions, like sin, cos, and ln. 
 However, it is cognitively harder for people for compound function names; 
 e.g. searchsortedlast. Such a naming convention flies in the face of real 
 programming experience. It makes programming harder for people.

 There are many sane ways to name functions. Lisps tend to use hyphens, 
 others often use underscores. R libraries use a non-standard mix [1]. 
 Interestingly, the Julia parser code itself uses hyphens; e.g. 
 prec-assignment and prec-conditional: 
 https://github.com/JuliaLang/julia/blob/master/src/julia-parser.scm

 It would be a shame for squishedcase to persist as the language reaches 
 1.0. What are some possible ways to address this problem without breaking 
 compatibility in the short-run?

 I see a possible solution. Choose a character and encourage its use to 
 break apart words; e.g. -, _, or a middot (·) [2]. Make it highly 
 recommended but non-breaking until 1.0. Deprecate 
 functionsusingsquishedcase.

 Julia is great overall but lacking in this way. Let's make it better.

 Sincerely,
 David

 [1] 
 http://stackoverflow.com/questions/1944910/what-is-your-preferred-style-for-naming-variables-in-r

 [2] The middot is relatively unobtrusive and doesn't take up much space 
 horizontally, e.g. search·sorted·last. It is also useful for variables 
 representing compound units; e.g. N·m.





[julia-users] Re: movingpastasquishedcaseconvention?

2015-02-06 Thread Reid Atcheson
This is obviously a point of taste, but for what it's worth I like Julia's 
approach. I am not a Fortran programmer, but being a scientific computing 
specialist I have likely been influenced by that culture - and there short 
uninformative names are the norm, rather than the exception.

I like the all lower case approach for the simple reason that it forces 
people to really think whether a long squished-together name is necessary. 
In one of my projects for example I have a function which was translated in 
one-to-one fashion from a C interface, and it reads 
buildkernelfromsource. That is a really ugly name, now I could make this 
cleaner by calling it buildKernelFromSource, now each of the grammatical 
units stick out in a much more readable way. However there is a lot of 
redundancy here, because the function accepts a string called filename 
and outputs something with type Kernel. Why don't I just call this 
function build and let the types offer further documentation? Obviously 
this would be in addition to proper documentation and comments, and 
shouldn't stand alone as the sole indication of functionality. This is 
something I have yet to fix in the code, but I offer it as a simple example 
:)

I find that in camelCase, it lets people be a little lazy with verbosity 
that otherwise could be removed. For my aesthetics I don't like it as much. 

On Friday, February 6, 2015 at 3:26:49 AM UTC-6, Steven Sagaert wrote:

 I prefer Java's camelcase: searchSortedLast: it's the same length as all 
 lower case but clearer.

 On Thursday, February 5, 2015 at 8:12:43 PM UTC+1, David James wrote:

 Hello,

 The title of this post is Moving Past a Squished Case Convention not 
 Moving Pastas Quiche :)

 The Julia standard library tends to use the squishedcase notation. 
 Being concise is great for mathematical functions, like sin, cos, and ln. 
 However, it is cognitively harder for people for compound function names; 
 e.g. searchsortedlast. Such a naming convention flies in the face of real 
 programming experience. It makes programming harder for people.

 There are many sane ways to name functions. Lisps tend to use hyphens, 
 others often use underscores. R libraries use a non-standard mix [1]. 
 Interestingly, the Julia parser code itself uses hyphens; e.g. 
 prec-assignment and prec-conditional: 
 https://github.com/JuliaLang/julia/blob/master/src/julia-parser.scm

 It would be a shame for squishedcase to persist as the language reaches 
 1.0. What are some possible ways to address this problem without breaking 
 compatibility in the short-run?

 I see a possible solution. Choose a character and encourage its use to 
 break apart words; e.g. -, _, or a middot (·) [2]. Make it highly 
 recommended but non-breaking until 1.0. Deprecate 
 functionsusingsquishedcase.

 Julia is great overall but lacking in this way. Let's make it better.

 Sincerely,
 David

 [1] 
 http://stackoverflow.com/questions/1944910/what-is-your-preferred-style-for-naming-variables-in-r

 [2] The middot is relatively unobtrusive and doesn't take up much space 
 horizontally, e.g. search·sorted·last. It is also useful for variables 
 representing compound units; e.g. N·m.