I think julia is very newbie-friendly, except for some very common patterns that people run into. How many times do people run into the "globals are slow" problem, post a long question about why "I thought julia was fast...", and then we go through the same performance tips. It would be nice if there was a "newb mode", in which there were warnings generated for some of these common problems (or they were fixed automatically). I think some of it may be solved with something like Lint, but your typical Matlab user will not go anywhere near Lint when they're first starting out. I'm not sure the right answer, but it would be nice to have a more obvious way to automatically fix things like globals that could be declared const, or maybe even automatically wrapping global code in functions?
Also with regards to how Julia should be pitched to new users... I think you should always stress: "Julia *can* be faster than most alternatives, and it takes much less effort and much less code alteration to make it happen. If you want to make python fast, you have to rewrite your whole algo in cython or c, and go through the annoyance of writing code to *call* that new code. If you want to make matlab fast, you have to rewrite your whole algo in a mex file, and you also have to wrap it. If you want to make Julia fast, wrap the same code in a function, maybe with a few type declarations for safety." The comparison is stark when you put it in those terms. On Thu, Sep 24, 2015 at 12:06 PM, Kristoffer Carlsson <[email protected] > wrote: > Yeah cause Haskell is so super newbie friendly??? > > I don't think the developers had the goal with Julia that you should be > able to write code with as few characters as possible. > > > On Thursday, September 24, 2015 at 5:54:37 PM UTC+2, Páll Haraldsson wrote: >> >> On Thursday, September 24, 2015 at 12:17:25 PM UTC, Marcio Sales wrote: >>> >>> Wow. All this discussion to make Julia only *as fast as* the old >>> scripting languages? >>> >> >> This is not what I meant. Matching C is the goal I understand and often >> that goal is met. *Should* always be possible. >> >> A. By matching the speed C/C++ (and I guess Fortran that I'm not too >> familiar with) the length of your code shouldn't be longer. It might very >> well be shorter and still not slower. >> >> B. Some other languages (such as Haskell or scripting languages), can be >> very concise. And sometimes there is not much speed penalty. It would be >> ideal to also have (as) short code and not pay a price in speed. That is >> the only thing I meant. >> >>
