On Monday, September 21, 2015 at 12:18:12 AM UTC, Daniel Carrera wrote: > > > On 21 September 2015 at 01:36, Páll Haraldsson <pall.ha...@gmail.com > <javascript:>> wrote: > >> I know about @devec but wander how close Julia is also able to match the >> speed of its looks with more condensed code or MATLAB-like or functional >> programming language style. What are the most interesting issue numbers to >> look at, if you were to try to help? I'm guessing its not one of the easier >> "up-for-grabs" issues, for relative newbies like me.. >> > > Sorry, I don't understand what you are trying to ask. >
I really just meant, with the loop, the code goes from 2 to 6 lines. Is three times LOC a drawback of Julia to get speed (note you do not *have to* expand if speed isn't critical, and much code isn't). Compared to C/C++ that is competetive, but may not be against say MATLAB. The code was already fast there and didn't need a loop. I assume/understand this is a temporary situation, and maybe I or anyone can help fix it. > > > Another thing I saw: >> "String is not a concrete type. Consider ASCIIString or UTF8String. " >> >> This would not apply in Python, UTF8, UTF16 etc. could be in a type (a >> new one that can hold the others through composition?) that "just works" >> [fast]? Windows uses UTF16 and then choosing UTF8String there would be bad? >> > > No, that's not what it means. UTF8String will be fast too. In Julia there > are two kinds of types: concrete types, and abstract types. A concrete are > things like: > Thanks for answering. I knew about abstract vs. concrete. What I meant here, "UTF8String will be fast" yes, but if you are on Windows the API uses UTF16 and I assume you'll be converting needlessly back and forth. That might not be a problem, you are maybe I/O-limited. But if not, will Windows always be second class platform, for code that assumes UTF8 (or wise versa..)? Will Julia at least compete will with Python for string handling..?
