6 ms·

Julia could have had 10x the adoption if they painted themselves as more of a general purpose language, like "write the web app and your neural networks (GPU ac

by nnq 9y ago

Julia could have had 10x the adoption if they painted themselves as more of a general purpose language, like "write the web app and your neural networks (GPU accelerable bien sur) in the same language ftw!"... if only they'd have bolted in some support for "non-weird-looking classic OOP" like in "wanna type `window.` and have even the most retarded editor autocomplete methods". Imho they got it backwards: Python got so popular in scientific computing because it was first and foremost a general-purpose scripting language and didn't isolate (library-wise) sci-coders from all the other developers, second because it was designed as a "teaching language" so simple examples looked close enough to pseudocode so were liked by people in the business of having to explain their code (academia), and only lastly because it happen to be easily extensible for things like matrix operation (operator overloading...) and had non-weird general syntax (like in "functions are value and that's that" not Ruby-like weird blocks and procs that spooked math and physics folks...). My only hope for "general purpose & sci computing" language would be Go if they dragged they heads out their asses and added some damn sugar to the langue - like operator overloading, some parametric types or templates (good luck bothering a physicists to understand when to use type switches and type assertions...), and something to allow "casual" developers to not be bitten by things like "not all nill's are equal, wtf?!" things. I like Go, but it's a hard language to sell to a non-100%-professional-developer...

Volt 9y ago
They're going after Matlab, Octave and R rather than Python.
- nnq 9y ago
  That's why I think "they get things backwards" :| ...Python went after Matlab, Octave and R. And for ML/AI is almost completely replaced them. For stats and data-exploration it shares the pie with R because they are so different languages with different strengths. It's a shame that the best language designers seem to also be the worst at "market positioning" and programming languages a pretty much fashion & promotion driven area. Anyway, maybe I should shut up, find the time to delve into Julia and when I know enough try to give them a helping hand instead of whining...
  - jononor 9y ago
    Python (as in the language designers or core people) did not "go after Matlab, Octave and R". Non-affiliated or loosely-affiliated people who wanted to do their data-oriented work in Python wrote a bunch of libraries, and the result after many years was a pretty competitive set of tools. So yeah, I think that similarly can be done for Julia to improve it for more general purpose tasks. In educational/academic setting, I think even more importantly for adoption than Python being a general-purpose language is that it is already relatively widely adopted in various industries as a tooling language. For good and bad, universities today are very keen on providing skills with immediate relevance to employeers. The same network effect is kinda what is keeping Matlab alive...
    - nnq 9y ago
      > more importantly for adoption than Python being a general-purpose language is that it is already relatively widely adopted in various industries as a tooling language. For good and bad, universities today are very keen on providing skills with immediate relevance to employeers Maybe I phrased it confusingly but you're saying the same things I thought. I don't mean "go after" in a conscious/targeted way. I meant "it evolved towards taking over". And "immediate relevance to employeers" is provided by being a "general purpose language" (like in "look, you can quickly wip up web apps, general server admin scrips and even excell plugins with it"). And "tooling" mostly equals "general purpose" in my book: there is no clear definition of "tooling" it's about "glue code" that needs to do "a bit of everything" to tie things together... so you need a "general purpose" language for tooling. (Now I see that maybe some people use "general purpose" as in "you can write anything from device drivers and OSs to web apps if you really want to" but this is "systems languages" in my terms or C and C++ and the newcomers Rust and D. But by this definition even Go would be very far from "general purpose"...)
flavio81 9y ago
> if only they'd have bolted in some support for "non-weird-looking classic OOP" like in "wanna type `window. Ah, so you want an inferior way of doing OOP? Because the reason Julia is the way it is, it is because it supports OOP based on multiple dispatch (and over more than one object per method). I think this is a major quantum leap over the OOP you are requesting. Sincerely, if that's what you want, there is always Java to make you happy.
- nnq 9y ago
  The "inferior" way has a clear advantage: discoverability! What if I want to call a method but I totally forgot its name and I'm not not sure how to search for what it does? What if I don't know what I want to do, but I have this "thinggy" and I want to see "what can it do"? Or "what messages it can receive"? This is generally how you think when you build "interfaces", you start somewhere in the middle and figure out how & what to do along the way, regardless if it's "glue APIs" or "web GUIs" or "desktop GUIs". OOP is "message passing" first of all in my view. This is how it all started in Smalltalk, and single dispatch makes sense if you want to be able to "ask an object/actor what messages it can understand". Now yeah, truly retarded languages like Java and C++ crapped all over the "OOP as message passing" idea, and also rejected multiple-dispatch... resulting in a truly horrible experience that forces anyone to drown in design patterns. Julia is not retarded, multiple dispatch makes sense in a functional or in a math-oriented language, but I'd prefer things like operators to be multiple-dispatch and methods single dispatch. This would be the "having the cake and eating it too" solution that would please both "math coders" and "professional software engineers", otherwise they'll keep using different languages and we'll keep wasting time writing "glue" between them imho. It's incredibly hard to reason about functions that dispatch on more than 2 arguments anyway, and those that dispatch on 2 operands could be written just fine in a Haskell-like operator syntax like: M1 `mySpecialXVectorOperation` M2 and if you truly need n-ary dispatch in some special cases, add a syntax like this: {M1, M1, V3}.mySpecialXVectorOperation(42, false) that could at least in theory allow IDEs and such provide some assistance to the developer! (not sure any IDE developers would bother developing so much introspection though...) (But practically thinking, I still think you can get away with single-dispatch + a few tricks, and have easier-to-reason-about code as a side effect ;) ) EDIT+: And I get it that math-people have a more "first you truly understand it, then you apply it, then maybe you try and expand on it" mindset that make my kind of reasoning completely alien to them, but lots of software is and will be written in a "jump in the middle of it, hack your way to the solution, in the end re-re-re-refactor it until it not only works, but it also makes sense and you can explain it and maybe even partially prove it works". EDIT+2: And don't get me wrong, Julia is a great language, its developers did some unbelievably awesome work... it's just not a "bridge the gap between physicists/engineers and software-people" language, despite being like 90% of the way there... I wish I could "sell it" to my "software-people" colleagues better :)

by nnq 9y ago

Volt 9y ago

They're going after Matlab, Octave and R rather than Python.

nnq 9y ago
That's why I think "they get things backwards" :| ...Python went after Matlab, Octave and R. And for ML/AI is almost completely replaced them. For stats and data-exploration it shares the pie with R because they are so different languages with different strengths. It's a shame that the best language designers seem to also be the worst at "market positioning" and programming languages a pretty much fashion & promotion driven area. Anyway, maybe I should shut up, find the time to delve into Julia and when I know enough try to give them a helping hand instead of whining...
- jononor 9y ago
  Python (as in the language designers or core people) did not "go after Matlab, Octave and R". Non-affiliated or loosely-affiliated people who wanted to do their data-oriented work in Python wrote a bunch of libraries, and the result after many years was a pretty competitive set of tools. So yeah, I think that similarly can be done for Julia to improve it for more general purpose tasks. In educational/academic setting, I think even more importantly for adoption than Python being a general-purpose language is that it is already relatively widely adopted in various industries as a tooling language. For good and bad, universities today are very keen on providing skills with immediate relevance to employeers. The same network effect is kinda what is keeping Matlab alive...
  - nnq 9y ago
    > more importantly for adoption than Python being a general-purpose language is that it is already relatively widely adopted in various industries as a tooling language. For good and bad, universities today are very keen on providing skills with immediate relevance to employeers Maybe I phrased it confusingly but you're saying the same things I thought. I don't mean "go after" in a conscious/targeted way. I meant "it evolved towards taking over". And "immediate relevance to employeers" is provided by being a "general purpose language" (like in "look, you can quickly wip up web apps, general server admin scrips and even excell plugins with it"). And "tooling" mostly equals "general purpose" in my book: there is no clear definition of "tooling" it's about "glue code" that needs to do "a bit of everything" to tie things together... so you need a "general purpose" language for tooling. (Now I see that maybe some people use "general purpose" as in "you can write anything from device drivers and OSs to web apps if you really want to" but this is "systems languages" in my terms or C and C++ and the newcomers Rust and D. But by this definition even Go would be very far from "general purpose"...)

flavio81 9y ago

> if only they'd have bolted in some support for "non-weird-looking classic OOP" like in "wanna type `window. Ah, so you want an inferior way of doing OOP? Because the reason Julia is the way it is, it is because it supports OOP based on multiple dispatch (and over more than one object per method). I think this is a major quantum leap over the OOP you are requesting. Sincerely, if that's what you want, there is always Java to make you happy.

nnq 9y ago
The "inferior" way has a clear advantage: discoverability! What if I want to call a method but I totally forgot its name and I'm not not sure how to search for what it does? What if I don't know what I want to do, but I have this "thinggy" and I want to see "what can it do"? Or "what messages it can receive"? This is generally how you think when you build "interfaces", you start somewhere in the middle and figure out how & what to do along the way, regardless if it's "glue APIs" or "web GUIs" or "desktop GUIs". OOP is "message passing" first of all in my view. This is how it all started in Smalltalk, and single dispatch makes sense if you want to be able to "ask an object/actor what messages it can understand". Now yeah, truly retarded languages like Java and C++ crapped all over the "OOP as message passing" idea, and also rejected multiple-dispatch... resulting in a truly horrible experience that forces anyone to drown in design patterns. Julia is not retarded, multiple dispatch makes sense in a functional or in a math-oriented language, but I'd prefer things like operators to be multiple-dispatch and methods single dispatch. This would be the "having the cake and eating it too" solution that would please both "math coders" and "professional software engineers", otherwise they'll keep using different languages and we'll keep wasting time writing "glue" between them imho. It's incredibly hard to reason about functions that dispatch on more than 2 arguments anyway, and those that dispatch on 2 operands could be written just fine in a Haskell-like operator syntax like: M1 `mySpecialXVectorOperation` M2 and if you truly need n-ary dispatch in some special cases, add a syntax like this: {M1, M1, V3}.mySpecialXVectorOperation(42, false) that could at least in theory allow IDEs and such provide some assistance to the developer! (not sure any IDE developers would bother developing so much introspection though...) (But practically thinking, I still think you can get away with single-dispatch + a few tricks, and have easier-to-reason-about code as a side effect ;) ) EDIT+: And I get it that math-people have a more "first you truly understand it, then you apply it, then maybe you try and expand on it" mindset that make my kind of reasoning completely alien to them, but lots of software is and will be written in a "jump in the middle of it, hack your way to the solution, in the end re-re-re-refactor it until it not only works, but it also makes sense and you can explain it and maybe even partially prove it works". EDIT+2: And don't get me wrong, Julia is a great language, its developers did some unbelievably awesome work... it's just not a "bridge the gap between physicists/engineers and software-people" language, despite being like 90% of the way there... I wish I could "sell it" to my "software-people" colleagues better :)