5 ms·

What I would like to know before jumping in a new programming language is what it sucks at and how badly it sucks there. Never in my life have I ever heard any

by monochr 12y ago

What I would like to know before jumping in a new programming language is what it sucks at and how badly it sucks there. Never in my life have I ever heard anyone say anything good about how wonderful it is language X is good at y which is what it was designed for. I have however heard plenty of people cursing languages for not doing something which they thought was an "obvious" thing for a language to do and X didn't.

sgt101 12y ago
I would say Julia sucks for embedded programming :); building graphical clients - although not badly as there are various js libaries that it can chat to, games programming, it's not great at data base interaction although once you have the data in it it is fine (frames). The last point is a bit of a development area I would expect to see because Julia has a console and this means that interactive querying would be great - like SQL on steroids but currently without the sql unfortunatley. Julia shines at developing efficient reusable code for crunching numbers. The type system is really nice, and the syntax is very clean and natural (to me!)
- ViralBShah 12y ago
  There is work happening on the UI side in Julia. While we are some ways away from building graphical clients in Julia, we do have GTK bindings and such. For some interesting ideas borrowed from Elm, do see: https://github.com/shashi/Patchwork.jl https://github.com/shashi/Patchwork.jl
  - infinite8s 12y ago
    Is anyone working on direct Qt bindings (I don't consider using PyCall a viable option). Qt is a bit harder to wrap since it is C++, but it look like Lua has been able to auto generate bindings based on the Qt headers.
    - StefanKarpinski 12y ago
      Keno Fischer, who recently created the Cxx package [1] used to be a Qt dev, so I wouldn't be terribly surprised if we see such bindings materialize in the future, using Cxx, of course. That said, I don't want to speak for him, so if someone wants this, they should maybe go ahead and start working on it! [1] https://github.com/Keno/Cxx.jl https://github.com/Keno/Cxx.jl
amelius 12y ago
What I'd like to know when learning a new language is: why can't this be done in an existing language? Take for example the R programming language. Things you do in this language can be perfectly well done in e.g. Python too. Same goes for the MATLAB language.
- one-more-minute 12y ago
  Isn't this... exactly what the linked paper tries to explain? The very first three bullet points are a great overview of the traditions Julia breaks away from, and the rest explains how the language enables that. Can you clarify which parts can easily be done in other languages and how?
- 4ad 12y ago
  Julia is homoiconic, so it can do things non-homoiconic languages can't do. E.g. symbolic differentiation of Julia expressions. Of course Lisp and Scheme can do this too, but it's virtually non-existent in any common language today. SICM makes heavy use of this. Now, is there any other language with Lisp-like macros and static typing?
  - termain 12y ago
    Typed Racket?
    - 4ad 12y ago
      Never heard of it. Will check it out.
      - orbifold 12y ago
        Racket is a scheme derivative, actually it consists of several languages including some domain specific ones, that all are compatible with each other. It also has a _very_ nice C foreign function interface (much better than Haskells for example).
RivieraKid 12y ago
One of the few things I don't like is that it lacks a bit for object-oriented programming. Specifically: - It doesn't use the object.method() syntax, which is often more natural and readable than method(object). - Support for interfaces but I'm not 100% sure about that.
- one-more-minute 12y ago
  Julia is really more a functional language than an object oriented one. Not saying that's not a valid point (at least to the extent that favourite paradigm is subjective) but just to point out that it's about more than just syntax. It wouldn't really make sense for Julia to support object.method() any more than it would for Haskell to, superficial as it may seem.
  - RivieraKid 12y ago
    I wish there was a language like Julia but with a first-class OOP support. Sometimes the OOP approach is more readable and easier to reason about than functional approach.
    - jghn 12y ago
      When you say "OOP approach", I'm reading "OOP in the style of the C++/Java/C#/etc branch of the OOP family tree". Not all OOP languages look remotely like what you're describing.
      - RivieraKid 12y ago
        > I'm reading "OOP in the style of the C++/Java/C#/etc branch of the OOP family tree". You read mostly right. But the OOP language I like the most is Ceylon (it also has a first-class support for the functional paradigm).
        jghn 12y ago
        In particular I'm thinking of things like Dylan or CLOS. When people from the more typical OOP backgrounds see stuff like that often their heads explode. I recently got into an argument with some coworkers over type classes. My argument was that it all made sense when viewed from the Dylan/CLOS/S4/etc lens, and that this was very much OOP, just not what they were used to. Many of them weren't buying what I was selling, but IMO they were using too strict a definition of OOP.
qooleot 12y ago
Julia's http library, and furthermore the extensive communities around tech stacks like node.js and ruby. Although Julia is focused on mathematical problems, its still often important to pull data from resources on the net (google weather just as a trivial example). Or outputting results to a website to share results dynamically. This is one area where Python shines - being both a strong web framework (Flask and Django)as well as with scipy and pandas library for computation. As a bootstrap to letting us do things like stream audio from the Web Audio API, and use Julia inside of an existing web app was to build a Node.js and Julia bridge: https://github.com/waTeim/node-julia https://github.com/waTeim/node-julia It worked out very conveniently that Node.js through node-gyp can use C libraries, and Julia can run inside a C context. I think the strongest use cases are node streams, and also online-learning models such as a recommender system. I.e. pass to Julia what the user has been interested in, and simply get back a few suggested items of high correlation.
fdej 12y ago
Julia's non-incremental stop-the-world garbage collector is quite bad. I ran into problems with this when trying to implement an algorithm that creates and destroys lots of temporary objects, where each object is a wrapped C struct that can point to a large amount of extra memory (the algorithm in question is doing polynomial division, where each coefficient is a polynomial represented by a C object). The Julia version of this program runs unexpectedly slowly and uses gigabytes of memory, even though a few megabytes should be enough. The same code runs much faster if you do it in C and free every temporary object when it's no longer used, or even you do it with a Python C extension. Since Python uses reference counting, the objects get freed as soon as they fall out of scope. But Julia allocates thousands of objects at a time before running the GC. Inserting manual GC calls is even worse -- the memory usage drops, but the program slows down by an order of magnitude (every GC takes a long time, even if you've just allocated a couple of objects since the last time). Part of the problem is that the C code in question uses an object pool to speed up frequent allocations and deallocations. But even if you disable the pool, Julia performs worse than you would hope. A good generational/incremental GC would solve the problem.
- ViralBShah 12y ago
  Incremental GC is in the works. Do see: https://github.com/JuliaLang/julia/pull/8699 https://github.com/JuliaLang/julia/pull/8699 https://github.com/JuliaLang/julia/pull/5227 https://github.com/JuliaLang/julia/pull/5227
  - fdej 12y ago
    That's good to know!
wbhart 12y ago
This very much depends on what you want to do with it and what your background is. Here are some things that might bother you. * Julia's approach to OOP is via multimethods, not the usual class/inheritance model. This might be annoying for people who don't want to learn how to be an effective programmer in the other paradigm. * Julia's garbage collector is not generational/incremental and in some corner cases, GC can take 10 times longer than the actual function you are running (typically it is between 5% and 50%). This would make Julia unsuitable for HFT, real-time games, web browsers of the future and other real-time applications. (Edit: see Viral's post in the same thread. Incremental GC is in the works. This is genuinely my experience of Julia to date. No sooner do you need something, and someone competent is already working on it, if they haven't already done it!) * Julia sucks at predicate dispatch. It doesn't have it. Granted, neither does any other language except Gap and one other I forgot. So if you are used to that feature, you would find Julia a step down. (Edit: yes of course Julia does not need/want predicate dispatch. It's just an illustration of something that could bother you if you were really, really used to something. I just happen to have colleagues who really are used to this.) * Julia is tied to LLVM, so if you want to be on the CLR/DLR or JVM, you are out of luck. * Julia currently doesn't have static compilation (I hear it is being actively worked on). This makes it more difficult to deploy binaries. * Julia does not have Haskell-like separation of effects from pure functions. This might not appeal to type purists. * Julia functions can fail at runtime where statically typed/compiled languages would pick up the errors at compile time. * As popular as it is, Julia is still not in the top 50 programming languages by measure of usership. * Julia's support of mutable C-style structs allocated on the stack, as opposed to pointers to heap allocated objects is still somewhat lacking. This creates some challenges in efficient C FFI in corner cases, especially in combination with GC. * Julia doesn't have inheritance of data types (it is really a dual to a data focused language, which is sensible -- you typically have far more functions than data types in a program -- but it's still hard for traditional OOP users to get used to). * The Julia abstract type system is somewhat linear, which makes it a little less flexible as far as contracts/interfaces are concerned, if you choose to implement things that way. Of course Julia has so many features that make it worthwhile, that it is worth investigating for many projects. It has multimethods, (static) dependent typing, very easy and efficient C interface (soon C++ interface), C-like performance is possible, garbage-collection, macros, runtime console (REPL), great numerical features, Jit compilation, a good selection of libraries/packages, a package manager, profiling, various development tools, a good (highly intelligent and helpful) community.
tmbsundar 12y ago
May be documentation will need some time to catch up vis-a-vis the likes of R, Python etc., Understandably since it is a new language this may probably remain so for quite some time? For e.g., when I was trying to find out how to generate "n" random numbers in a uniform distribution from a range of -x to +x. In R the code is as simple as runif(n,-x,x). In matlab, it is a little bit contrived by offsetting and multiplying with the interval etc., But in Julia, the details do not go beyond the standard random functions that do not let you do this and no pointers to documentation beyond. But finally I was lucky to find an entry in the mailing list where I figured out I needed to use the "Distributions" package using the "using" command. Even then , the results were delivered in multiple precision points -> 1.1234, 1.123456 etc., In R computing an outer product while passing a custom function is easy. Something like outer(x,y, some function of (x,y)) is pretty straight forward. Not sure how to achieve this in Julia. Nevertheless, as the language grows and as more idioms are documented and widely used, lif will be simpler I guess.

by monochr 12y ago

sgt101 12y ago

I would say Julia sucks for embedded programming :); building graphical clients - although not badly as there are various js libaries that it can chat to, games programming, it's not great at data base interaction although once you have the data in it it is fine (frames). The last point is a bit of a development area I would expect to see because Julia has a console and this means that interactive querying would be great - like SQL on steroids but currently without the sql unfortunatley. Julia shines at developing efficient reusable code for crunching numbers. The type system is really nice, and the syntax is very clean and natural (to me!)

ViralBShah 12y ago
There is work happening on the UI side in Julia. While we are some ways away from building graphical clients in Julia, we do have GTK bindings and such. For some interesting ideas borrowed from Elm, do see: https://github.com/shashi/Patchwork.jl https://github.com/shashi/Patchwork.jl
- infinite8s 12y ago
  Is anyone working on direct Qt bindings (I don't consider using PyCall a viable option). Qt is a bit harder to wrap since it is C++, but it look like Lua has been able to auto generate bindings based on the Qt headers.
  - StefanKarpinski 12y ago
    Keno Fischer, who recently created the Cxx package [1] used to be a Qt dev, so I wouldn't be terribly surprised if we see such bindings materialize in the future, using Cxx, of course. That said, I don't want to speak for him, so if someone wants this, they should maybe go ahead and start working on it! [1] https://github.com/Keno/Cxx.jl https://github.com/Keno/Cxx.jl

amelius 12y ago

What I'd like to know when learning a new language is: why can't this be done in an existing language? Take for example the R programming language. Things you do in this language can be perfectly well done in e.g. Python too. Same goes for the MATLAB language.

one-more-minute 12y ago
Isn't this... exactly what the linked paper tries to explain? The very first three bullet points are a great overview of the traditions Julia breaks away from, and the rest explains how the language enables that. Can you clarify which parts can easily be done in other languages and how?
4ad 12y ago
Julia is homoiconic, so it can do things non-homoiconic languages can't do. E.g. symbolic differentiation of Julia expressions. Of course Lisp and Scheme can do this too, but it's virtually non-existent in any common language today. SICM makes heavy use of this. Now, is there any other language with Lisp-like macros and static typing?
- termain 12y ago
  Typed Racket?
  - 4ad 12y ago
    Never heard of it. Will check it out.
    - orbifold 12y ago
      Racket is a scheme derivative, actually it consists of several languages including some domain specific ones, that all are compatible with each other. It also has a _very_ nice C foreign function interface (much better than Haskells for example).

RivieraKid 12y ago

One of the few things I don't like is that it lacks a bit for object-oriented programming. Specifically: - It doesn't use the object.method() syntax, which is often more natural and readable than method(object). - Support for interfaces but I'm not 100% sure about that.

one-more-minute 12y ago
Julia is really more a functional language than an object oriented one. Not saying that's not a valid point (at least to the extent that favourite paradigm is subjective) but just to point out that it's about more than just syntax. It wouldn't really make sense for Julia to support object.method() any more than it would for Haskell to, superficial as it may seem.
- RivieraKid 12y ago
  I wish there was a language like Julia but with a first-class OOP support. Sometimes the OOP approach is more readable and easier to reason about than functional approach.
  - jghn 12y ago
    When you say "OOP approach", I'm reading "OOP in the style of the C++/Java/C#/etc branch of the OOP family tree". Not all OOP languages look remotely like what you're describing.
    - RivieraKid 12y ago
      > I'm reading "OOP in the style of the C++/Java/C#/etc branch of the OOP family tree". You read mostly right. But the OOP language I like the most is Ceylon (it also has a first-class support for the functional paradigm).
      - jghn 12y ago
        In particular I'm thinking of things like Dylan or CLOS. When people from the more typical OOP backgrounds see stuff like that often their heads explode. I recently got into an argument with some coworkers over type classes. My argument was that it all made sense when viewed from the Dylan/CLOS/S4/etc lens, and that this was very much OOP, just not what they were used to. Many of them weren't buying what I was selling, but IMO they were using too strict a definition of OOP.

qooleot 12y ago

Julia's http library, and furthermore the extensive communities around tech stacks like node.js and ruby. Although Julia is focused on mathematical problems, its still often important to pull data from resources on the net (google weather just as a trivial example). Or outputting results to a website to share results dynamically. This is one area where Python shines - being both a strong web framework (Flask and Django)as well as with scipy and pandas library for computation. As a bootstrap to letting us do things like stream audio from the Web Audio API, and use Julia inside of an existing web app was to build a Node.js and Julia bridge: https://github.com/waTeim/node-julia https://github.com/waTeim/node-julia It worked out very conveniently that Node.js through node-gyp can use C libraries, and Julia can run inside a C context. I think the strongest use cases are node streams, and also online-learning models such as a recommender system. I.e. pass to Julia what the user has been interested in, and simply get back a few suggested items of high correlation.

fdej 12y ago

Julia's non-incremental stop-the-world garbage collector is quite bad. I ran into problems with this when trying to implement an algorithm that creates and destroys lots of temporary objects, where each object is a wrapped C struct that can point to a large amount of extra memory (the algorithm in question is doing polynomial division, where each coefficient is a polynomial represented by a C object). The Julia version of this program runs unexpectedly slowly and uses gigabytes of memory, even though a few megabytes should be enough. The same code runs much faster if you do it in C and free every temporary object when it's no longer used, or even you do it with a Python C extension. Since Python uses reference counting, the objects get freed as soon as they fall out of scope. But Julia allocates thousands of objects at a time before running the GC. Inserting manual GC calls is even worse -- the memory usage drops, but the program slows down by an order of magnitude (every GC takes a long time, even if you've just allocated a couple of objects since the last time). Part of the problem is that the C code in question uses an object pool to speed up frequent allocations and deallocations. But even if you disable the pool, Julia performs worse than you would hope. A good generational/incremental GC would solve the problem.

ViralBShah 12y ago
Incremental GC is in the works. Do see: https://github.com/JuliaLang/julia/pull/8699 https://github.com/JuliaLang/julia/pull/8699 https://github.com/JuliaLang/julia/pull/5227 https://github.com/JuliaLang/julia/pull/5227
- fdej 12y ago
  That's good to know!

wbhart 12y ago

This very much depends on what you want to do with it and what your background is. Here are some things that might bother you. * Julia's approach to OOP is via multimethods, not the usual class/inheritance model. This might be annoying for people who don't want to learn how to be an effective programmer in the other paradigm. * Julia's garbage collector is not generational/incremental and in some corner cases, GC can take 10 times longer than the actual function you are running (typically it is between 5% and 50%). This would make Julia unsuitable for HFT, real-time games, web browsers of the future and other real-time applications. (Edit: see Viral's post in the same thread. Incremental GC is in the works. This is genuinely my experience of Julia to date. No sooner do you need something, and someone competent is already working on it, if they haven't already done it!) * Julia sucks at predicate dispatch. It doesn't have it. Granted, neither does any other language except Gap and one other I forgot. So if you are used to that feature, you would find Julia a step down. (Edit: yes of course Julia does not need/want predicate dispatch. It's just an illustration of something that could bother you if you were really, really used to something. I just happen to have colleagues who really are used to this.) * Julia is tied to LLVM, so if you want to be on the CLR/DLR or JVM, you are out of luck. * Julia currently doesn't have static compilation (I hear it is being actively worked on). This makes it more difficult to deploy binaries. * Julia does not have Haskell-like separation of effects from pure functions. This might not appeal to type purists. * Julia functions can fail at runtime where statically typed/compiled languages would pick up the errors at compile time. * As popular as it is, Julia is still not in the top 50 programming languages by measure of usership. * Julia's support of mutable C-style structs allocated on the stack, as opposed to pointers to heap allocated objects is still somewhat lacking. This creates some challenges in efficient C FFI in corner cases, especially in combination with GC. * Julia doesn't have inheritance of data types (it is really a dual to a data focused language, which is sensible -- you typically have far more functions than data types in a program -- but it's still hard for traditional OOP users to get used to). * The Julia abstract type system is somewhat linear, which makes it a little less flexible as far as contracts/interfaces are concerned, if you choose to implement things that way. Of course Julia has so many features that make it worthwhile, that it is worth investigating for many projects. It has multimethods, (static) dependent typing, very easy and efficient C interface (soon C++ interface), C-like performance is possible, garbage-collection, macros, runtime console (REPL), great numerical features, Jit compilation, a good selection of libraries/packages, a package manager, profiling, various development tools, a good (highly intelligent and helpful) community.

tmbsundar 12y ago

May be documentation will need some time to catch up vis-a-vis the likes of R, Python etc., Understandably since it is a new language this may probably remain so for quite some time? For e.g., when I was trying to find out how to generate "n" random numbers in a uniform distribution from a range of -x to +x. In R the code is as simple as runif(n,-x,x). In matlab, it is a little bit contrived by offsetting and multiplying with the interval etc., But in Julia, the details do not go beyond the standard random functions that do not let you do this and no pointers to documentation beyond. But finally I was lucky to find an entry in the mailing list where I figured out I needed to use the "Distributions" package using the "using" command. Even then , the results were delivered in multiple precision points -> 1.1234, 1.123456 etc., In R computing an outer product while passing a custom function is easy. Something like outer(x,y, some function of (x,y)) is pretty straight forward. Not sure how to achieve this in Julia. Nevertheless, as the language grows and as more idioms are documented and widely used, lif will be simpler I guess.