Whoops, I meant to say that string concatenation is not commutative, not
not associative... you know what I mean.

On 23 November 2014 at 20:40, Mike Innes <[email protected]> wrote:

> If you want to get the most out of Julia it might be best to unlearn the
> Matlab practice of writing 500-line functions – this will probably solve a
> lot of your problems. This might sound crazy, but I tend to treat anything
> much longer than about 10 lines as code smell.
>
> There are a whole bunch of advantages to this:
>
>    - Julia will probably be able to optimise the code much better
>    - When editing code you can redefine a function at a time, which is
>    much faster than loading 500 lines at once. In Juno this is ridiculously
>    easy – just make your edits and press Ctrl-Enter. The edit-compile-test
>    cycle is practically instant and I've found this to be *very*
>     productive
>    - Error messages will probably be better – even if you only know which
>    function is the problem that narrows it down a lot
>    - Debugging is much easier, for the above reason and due to the fact
>    the each function is an independently testable unit that you can verify
>    just by throwing a few inputs at it. Again, in Juno this is very fast to 
> do.
>
> This isn't to say that there are no improvements Julia could make (things
> like code caching are definitely big ones) but if you're finding Julia to
> be *un*productive then there's almost certainly a better way.
>
> RE string concatenation: The idea here, I think, is that `*` is a better
> fit mathematically. For one thing `+` is normally associative whereas
> concatenation definitely isn't. It also extends quite nicely to `string^n`.
>
> On 23 November 2014 at 03:24, Christian Peel <[email protected]> wrote:
>
>> Hi all,
>>
>> I'm excited about Julia because of the speed and open nature of the
>> language.  I have a couple of suggestions from the past couple of days of
>> my time with the language:  (1) decrease the JIT time to allow faster code
>> changes, (2) automatically detect changed files and reload them, again to
>> allow developers to change their code quicker.    Combine that with the
>> integrated debugger that I believe is coming soon, and I think Julia will
>> be much more appealing.
>>
>> Here are some questions:
>> * Have any plans been made on allowing Julia to automatically notice that
>> a file has changed and reload it?  What is the normal development technique
>> for Julia developers? I typically write some code, test it, write some
>> more, and test it again.  For julia, do you just 'include' or 'reload'
>> every time you change a file?
>> * It can take a long time (10 seconds on my 2013 Macbook Pro) to do the
>> JIT (I guess that's what it's doing) the first time I run my simple
>> 500-line toy script after loading it; Putting this in the middle of
>> developing high-level code is really awkward.  Can you do anything to bring
>> this down?
>> * Why can't Julia show line numbers every time an error occurs, rather
>> than just sometimes?  Some errors for which I did not see line numbers
>> include "ERROR: BoundsError()" and "ERROR: `*` has no method matching
>> *(::Array{Complex{Float64},3}, ::Array{Float64,1})"
>> * I guess there is some sort of compilation happening when a file is
>> 'included'; can we have that spit out errors, rather than waiting for the
>> JIT to work?  The sooner we can see errors in my code, the better.
>> * At the matlab prompt, I can type 'str" then ctrl-P and it finds the
>> most recent command in the history that starts with 'str' and puts it on my
>> command line.  I can then hit enter immediately and execute it.  It appears
>> that with the current Julia setup, one has to type ctrl-R to enter
>> (reverse-i-search), where you can type 'str' and then ctrl-P or ctrl-N to
>> move forward and back through the history.  On finding an entry to execute,
>> one has to type enter twice, once to exit the interactive search and once
>> to execute the command.  Is it possible to configure Julia to have a
>> matlab-style search always active?  I tried playing around with the "Custom
>> Keybindings" description in the manual (http://bit.ly/1uOsoWq), but I
>> didn't know what I was doing.
>> * Is there anything like Matlab's 'format'?   Something so I don't see so
>> many significant digits when using print?
>> * Why does string concatenation use the "*" operator and not "+"?
>> (yes, this is completely minor, but I'm curious anyway... :-)
>> * I'd like to type "exit" instead of "exit()" or "edit myfile" instead of
>> "edit("myfile")    I can likely get used to this, but right now I'm
>> noticing those few extra characters that I'm typing  :-)      Could anyone
>> explain the motivation for this choice?
>>
>> This week I ported a 500-line Matlab script to Julia 0.3.2; these
>> questions and comments  are the result. My main impression is that
>> debugging is painful; to be useful as an every-day tool, the interaction
>> with the REPL and the write code/debug iteration has got to improve.
>>
>> My best
>>
>> Chris
>>
>
>

Reply via email to