I think, this may be a little unfair to Julia.
I agree that it’s unfair - but new users are seldom fair. What I meant to
get at was not that Julia code by an inexperienced programmer is worse than
anything else, but just that since Julia *can* be so fast, I think there’s
a big risk that the gap between potential and actual throughput in many
“first real Julia program”s becomes an annoyance, even if Julia has a the
potential to reach further than Python ever could. In other words, it’s not
Julia’s actual performance that is the problem, but the way it differs from
expectations.
// T
On Tuesday, September 29, 2015 at 2:50:14 PM UTC+2, Páll Haraldsson wrote:
On Tuesday, September 29, 2015 at 10:20:18 AM UTC, Tomas Lycken wrote:
>>
>> One thing Python does well, which Julia doesn't (yet) succeed in, is make
>> it easy to start coding from zero experience and get something that
>> executes "well enough"
>>
>
> I think, this may be a little unfair to Julia. Python (and Perl) succeeded
> not because it is fast (only because it has fast development times - to
> begin with at least). Julia is expected to be fast, compared to C, Python
> isn't. Even if Julia were as slow as Python, it seems to be a better
> language - more maintainable, as more static and doesn't really have
> duck-typing (and Hoare's "billion dollar mistake"), right?
>
> (although, as always with first-time coders, code organization and
>> readability might still leave some things to wish for...).
>>
>> In Julia, it's very much possible to get something to run, but the
>> performance differences between well-written and not-so-well-written code
>> are *huge*.
>>
>
> Right, but even your code that is written to be slow should work (no
> segfaults..) and not be slower than Python? At least, those would be
> exceptional cases, all that I would like to know about as I see no good
> reason for it.
>
> The way I see it, yes, type-instability makes your code way slower, but
> isn't that (roughly) the same as in Python, where all code is
> "type-unstable", because of duck-typing? That is or was at least the
> default. Now PyPy and Numba etc. helps (that didn't exist in the
> beginning/10 years ago)
>
> This means that most users will show their code to someone who knows more
>> than they do, and more likely than not get a first reaction along the lines
>> of "everything you do is wrong". Although the statement isn't untrue, it's
>> very off-putting - and even more off-putting is the fact that there's a lot
>> of "computer sciencey" stuff you need to understand to be able to grasp
>>
>
> Only for fast code, not "correct" code. And 90% of code isn't
> speed-critical. To a beginner this seems very good. First you learn the
> basics. You can prototype and later optimize ("premature optimization is
> the root of all evil"?).
>
> *why* you did it wrong (type stability, difference between abstract and
>> leaf types, difference between anonymous and named functions etc).
>>
>> Don't get me wrong - I think Julia is doing a lot of things right, and
>> I'm glad that these "CS-y" questions are asked and handled up-front: this
>> is what gives Julia much of its power. Hopefully, much of the performance
>> difference between hacked-together-rubbish code and well-polished code will
>> be eradicated by version 1.0, and we'll see how popular Julia becomes then.
>>
>> Currently, though, the success of any general programming language or
>> tool seems to hinge mostly on what you can build with it (Objective C is
>> ugly as hell
>>
>
> yes.. You can actually call Objective-C (OS X) from Julia.. I think
> Android support should come first, then iOS support. Neither should be too
> hard, possibly Apple would object..
>
> --
> Palli.
>
>
