Re: [julia-users] What is Julia bad for - currently? Practically (or theoretically) - any other language more powerful?
I actually don't think it is really that hard... for the most part, Julia needs better performance and better compatibility in some areas, that haven't received as much attention as of yet... (strings, decimal floats, database access). None of these things will take anything away from what what the core team wants to achieve for their target audience, and they can get unpaid (by them) help willing to work hard on improving those areas... (it's called enlightened self-interest ;-) ). On Sunday, May 10, 2015 at 6:55:58 PM UTC-4, ele...@gmail.com wrote: There is a very long list of interesting possibilities in this thread, but Julia does have a current target audience which it supports with a set of features that increase their utility. It is going to be tricky for those guiding Julia to ensure that things like more generality don't reduce the utility to that initial target audience. It will be interesting to see how that is managed. (No I don't know how to do it, thats why it will be interesting :) Cheers Lex
Re: [julia-users] What is Julia bad for - currently? Practically (or theoretically) - any other language more powerful?
There is a very long list of interesting possibilities in this thread, but Julia does have a current target audience which it supports with a set of features that increase their utility. It is going to be tricky for those guiding Julia to ensure that things like more generality don't reduce the utility to that initial target audience. It will be interesting to see how that is managed. (No I don't know how to do it, thats why it will be interesting :) Cheers Lex
Re: [julia-users] What is Julia bad for - currently? Practically (or theoretically) - any other language more powerful?
On Thursday, December 4, 2014 at 5:24:18 PM UTC-5, Simon Danisch wrote: Actually, I opened this thread: https://groups.google.com/forum/?fromgroups=#!topic/julia-users/IjG2ERHVjz0 when I needed to revisit prolog and first order logic for my AI exam... I think Julia can be great for DSLs! The current downside of Julia being very young and not having any established IDE can turn into an upside, if we use this to make a deeper connection between the parser and the IDE. This way we could offer correct syntax highlighting and parsing for any user defined DSL, if they use the same interfaces. I imagine that Julia might become a nice hub for other languages, with its low overhead for calling functions from other languages. If other languages can be integrated as nicely as Keno has done it with his Cxx package, together with good IDE support, this could be huge. This is part of why I (and the people at the startup where I'm consulting) are so interested in Julia... it seems like a much better glue than anything else we've seen... we won't lose performance by using Julia to tie together our C / C++ etc. modules with a number of third party open source packages that have nice C interfaces... Deciding to use Julia wouldn't mean to decide against using other languages. Even though removing the *necessity* to use multiple languages is, I think, core to Jeff Bezanson's PhD thesis, Julia does a wonderful job of just that, allowing you to keep your old C code or libraries, and write new interesting stuff in Julia. (As much as I like to believe that Julia could be the one and only language, this is still very powerful) Even I wouldn't say it would be the one and only language, but it could replace a raft of other languages, IMO. Scott Julia - one language to rule them all, and in the brightness bind them!
Re: [julia-users] What is Julia bad for - currently? Practically (or theoretically) - any other language more powerful?
I find your aversion to femtolisp difficult to understand, probably because I tend to think of Julia as a Lisp with the following key features: 1) a focus on being heavily optimizable, 2) infix/M-expression-like surface syntax. But given these two (very important) differences, I find Julia very, very similar to, say, Common Lisp (subset of CLOS, DSL for AST manipulation). Modern CL implementations can be very fast, but it turns out that the type system of CL is not rich enough to allow optimizations necessary for generic numerical code (at least without a lot of biolerplate). Infix vs prefix can seem like a matter of personal preference, but infix clearly makes macros easier because the AST is much cleaner. However, apparently a lot of thought went into designing the Julia surface syntax, and it turns out to be remarkably macro-friendly. I am not so sure about the mandatory macro prefix, but time will tell. The core of Julia is generic enough to be a potential substitute for all dynamic languages in the long run, as the language matures. I am not so sure that current technology allows a single language to be good at everything, languages like C seem to be difficult to replace with dynamic languages in some situations. Best, Tamas On Thu, Dec 04 2014, Páll Haraldsson pall.haralds...@gmail.com wrote: Hi, This is my first post here and since I've gotten your attention, my answer: Julia is (or seems to be) good at everything.[*] But I'm just not sure.. [You could stop reading here.] I think Julia could be the last language people need to learn (and should be the first).[*] Maybe I'm being incredibly naive thinking no *better* language will come along and I need to qualify that[*] but it seems people here, when saying the Wired article has it wrong (e.g. Bezanson), are being modest (or know better than I do). Maybe I just do not have enough perspective on languages/paradigms out there. I'm probably ignorant on (new) language/paradigm research.. Is Julia ready for prime time (0.3.3 considered stable)? I see some talk of breaking changes (Array nirvana and staged functions (for C++) will they break anything?). I already recommend Julia for technical computing (quant/financial) at least (to learn/try); there may be issues (especially for those doing non-technical) - for now. That seems to be changing fast. I would be preaching to the choir saying Julia is great for its target audience. But why do you just want to unify all of technical computing in one language and not all of computing? A fresh approach to technical computing might stop other people from considering Julia. I guess it's good to have a niche but I hope other people do not get scared away. What is needed is to support all the important platforms so that people will not overlook Julia as it doesn't support my work or run on my platform. This means the web (JavaScript as an assembly language target), Android (and iOS..). At least Bezanson seems to like (love?) Scheme (femtolisp). I wander if Scheme/Lisp (or any language) is *clearly* better than Julia for anything? Or would he stop using Scheme except to maintain Julia's core.. [Maybe femtolisp should be removed from Julia (e.g. to bootstrap Julia)..] While functional style is getting more popular, people seem to like imperative and Julia isn't either or. Can/should !-functions be enforced? It is only a recommendation? I know Lisp-syntax is simple. Maybe non-infix notation is better in a language but only for the interpreter it seems; or in regular math, had it been used first/what people are used to. I and most people just don't see it. I wander if there is anything to this other than preference. The S-expressions that come with Lisp and infix, do they have an inherent advantage that Julia can't match? In other words, I think that means, are Julia's Lisp-like macros and its homoiconicity as powerful as Lisp's? As for the (linked) lists (L in Lisp), of course we need lists (and trees) sometimes and Julia has them, but as a basic data structure of a language, seems to me to be a performance killer. I do not see caches (locality of reference) going away any time soon.. As all (Turing-complete) languages are equivalent in a sense, one can't be more powerful than another; C can implement Lisp, but without that exception (Greenspunning), programming a new runtime, languages with real macros can be more powerful. I used to associate macros with Lisp, are there (m)any other ALGOL-like/non-S-expression/not-list-based languages with real macros? Is Julia a first? I understand macros are the key to Lisp's power and Lisp is said to be the most powerful language. In short is there any area where another language (which one and for what) would be (*clearly*) better (not just slightly, see my metric below)? Maybe I'm not asking the right people.. I can assume people here have language theory
Re: [julia-users] What is Julia bad for - currently? Practically (or theoretically) - any other language more powerful?
On Fri, Dec 05 2014, Páll Haraldsson pall.haralds...@gmail.com wrote: On Friday, December 5, 2014 8:54:26 AM UTC, Tamas Papp wrote: I find your aversion to femtolisp difficult to understand, probably because I tend to think of Julia as a Lisp with the following key features: I don't really have an aversion to femtolisp. I understand it's an awesome implementation of Scheme. If you think of Julia as a Lisp (including Scheme, right?) then when would you prefer Lisp (or Scheme) for new things after Julia came along? Sorry, but did you read my e-mail? As I said, Julia is much more optimizable with its richer type system, which is a great advantage for me. Common Lisp is remarkably nice, but even nontrivial numeric code ends up being 1) non-optimized, 2) peppered with type declarations, specialized for a specific application, 3) wrapped in a fragile and complicated mess of template macrology. The kind people who designed Julia essentially took care of (3) for me -- how could I not like it? :D But given these two (very important) differences Why very important? I understand there is a difference in the syntax, is it important as in better *fro something*? Or just different. Personally, I like S-expressions too, but many people prefer M-expressions, especially for math (they are indeed more compact). What I thought. What I'm getting at, if Julia is better at somethings (e.g. the above) must it then be worse for other things? The core of Julia is generic enough to be a potential substitute for all dynamic languages in the long run, as the language matures. Not already? Then some dynamic language should currently be better, I would like to know why. I am not so sure that current technology allows a single language to be good at everything, languages like C seem to be difficult to replace with dynamic languages in some situations. These are very abstract points, and I am not sure that discussing them as such is very productive. As many have remarked in this thread, languages are tools, designed for a given prupose. Is a hammer better than a screwdriver? Etc. Why? For C, Julia seems already better for almost all users. If languages like C means C++, I could see all new code in Julia and C++ as legacy. What other like C do you mean? Again, I am wondering if you actually read the replies to your questions. Many have remarked on these issues in their replies to you, eg dynamic vs manual memory allocation, etc. C, C++, and Fortran are fundamentally different from Julia at the moment. Whether, in the long run, Julia will have features that dominate these in some markets remains to be seen, but at the moment this would be nothing more than idle speculation. In any case, history of computer languages teaches us that rich languages, especially in the Lisp family (where I include Julia) have features that interact in a manner that is difficult to describe and design in advance. If these are constraining, either the language is extended or a new one is introduced. But a priori it is nearly impossible to say what happens, so I think the best thing for stakeholders at this point is to work in Julia and see where it is going, and possibly try to shape its development, either directly or by helping to discover where it could be improved. Frankly, I don't understand your decision problem -- are you trying to decide whether to invest learning in Julia vs some other language? Even though that question does not have a well-defined answer either, it is possible that you would get more useful advice. Best, Tamas
Re: [julia-users] What is Julia bad for - currently? Practically (or theoretically) - any other language more powerful?
On Friday, December 5, 2014 11:34:46 AM UTC, Tamas Papp wrote: On Fri, Dec 05 2014, Páll Haraldsson pall.ha...@gmail.com javascript: wrote: On Friday, December 5, 2014 8:54:26 AM UTC, Tamas Papp wrote: I find your aversion to femtolisp difficult to understand, probably because I tend to think of Julia as a Lisp with the following key features: I don't really have an aversion to femtolisp. I understand it's an awesome implementation of Scheme. If you think of Julia as a Lisp (including Scheme, right?) then when would you prefer Lisp (or Scheme) for new things after Julia came along? Sorry, but did you read my e-mail? As I said, Julia is much more optimizable with its richer type system, which is a great advantage for me. Common Lisp is remarkably nice, but Yes I did read it. Note, I meant would you still recommend (Common) Lisp for anything, you seem to argue well for Julia (and against Lisp/S-expressions while you're at it?). Note also, I said would you prefer Lisp (or Scheme). I know Scheme is a dialect of Lisp and Racket of Scheme, but am not expert on the differences. I may be grouping all the Lisps together unfairly. Your objections to Common Lisp may not generalize to them all. Personally, I like S-expressions too, but many people prefer M-expressions, especially for math (they are indeed more compact). Is there a good way to call any (or all) of the S-expressions languages from Julia? I'm not even sure it's important too, there could be lots of useful preexisting code. I am not so sure that current technology allows a single language to be good at everything, languages like C seem to be difficult to replace with dynamic languages in some situations. These are very abstract points, and I am not sure that discussing them as such is very productive. As many have remarked in this thread, languages are tools, designed for a given prupose. Is a hammer better than a screwdriver? Etc. Libraries are also tools, I'm just not at all convinced we need many languages (for different purposes, maybe with very few limited exceptions) rather than just new libraries. That seems to be a failure of computer science. Why? For C, Julia seems already better for almost all users. If languages like C means C++, I could see all new code in Julia and C++ as legacy. What other like C do you mean? Again, I am wondering if you actually read the replies to your questions. Many have remarked on these issues in their replies to you, eg dynamic vs manual memory allocation, etc. C, C++, and Fortran are fundamentally different from Julia at the moment. I read all the replies (might have missed some). I already mentioned dynamic memory allocation in my first post as a temporary limitation (currently would be a problem for very few users/uses). Never programmed in Fortran but think it also uses manual memory allocation. While Julia uses those languages in part I think manual is not the reason for their (or Julia's) speed; in general that they are fundamentally different in a better way or others. Garbage collection can be hard real-time and fast (and Julia - the core language wouldn't need changes that break compatibility). or by helping to discover where it could be improved. Partly why I'm writing this. I want to know what needs improving or if something can't be improved, unless breaking things in a minor way or fundamentally that Julia can't work. Frankly, I don't understand your decision problem -- are you trying to decide whether to invest learning in Julia vs some other language? Even though that question does not have a well-defined answer either, it is possible that you would get more useful advice. Yes, I'm not too worried about me. I don't think I'm wasting time learning (more about) Julia, I just do not want to point people to it if there are even better languages available or if there is some defect in Julia I'm missing. It seems to be a good first language to learn, not just for matrix methods (is that all the Universities have started teaching with Julia?). Best regards, Palli.
Re: [julia-users] What is Julia bad for - currently? Practically (or theoretically) - any other language more powerful?
I'm glad you're enthusiastic about Julia. If you're looking to pitch in, one good place to look is the list of open issues: https://github.com/JuliaLang/julia/issues If you're most interested in features, filtering on the up for grabs label might be a good start. Best, --Tim On Friday, December 05, 2014 06:00:31 AM Páll Haraldsson wrote: On Friday, December 5, 2014 11:34:46 AM UTC, Tamas Papp wrote: On Fri, Dec 05 2014, Páll Haraldsson pall.ha...@gmail.com javascript: wrote: On Friday, December 5, 2014 8:54:26 AM UTC, Tamas Papp wrote: I find your aversion to femtolisp difficult to understand, probably because I tend to think of Julia as a Lisp with the following key features: I don't really have an aversion to femtolisp. I understand it's an awesome implementation of Scheme. If you think of Julia as a Lisp (including Scheme, right?) then when would you prefer Lisp (or Scheme) for new things after Julia came along? Sorry, but did you read my e-mail? As I said, Julia is much more optimizable with its richer type system, which is a great advantage for me. Common Lisp is remarkably nice, but Yes I did read it. Note, I meant would you still recommend (Common) Lisp for anything, you seem to argue well for Julia (and against Lisp/S-expressions while you're at it?). Note also, I said would you prefer Lisp (or Scheme). I know Scheme is a dialect of Lisp and Racket of Scheme, but am not expert on the differences. I may be grouping all the Lisps together unfairly. Your objections to Common Lisp may not generalize to them all. Personally, I like S-expressions too, but many people prefer M-expressions, especially for math (they are indeed more compact). Is there a good way to call any (or all) of the S-expressions languages from Julia? I'm not even sure it's important too, there could be lots of useful preexisting code. I am not so sure that current technology allows a single language to be good at everything, languages like C seem to be difficult to replace with dynamic languages in some situations. These are very abstract points, and I am not sure that discussing them as such is very productive. As many have remarked in this thread, languages are tools, designed for a given prupose. Is a hammer better than a screwdriver? Etc. Libraries are also tools, I'm just not at all convinced we need many languages (for different purposes, maybe with very few limited exceptions) rather than just new libraries. That seems to be a failure of computer science. Why? For C, Julia seems already better for almost all users. If languages like C means C++, I could see all new code in Julia and C++ as legacy. What other like C do you mean? Again, I am wondering if you actually read the replies to your questions. Many have remarked on these issues in their replies to you, eg dynamic vs manual memory allocation, etc. C, C++, and Fortran are fundamentally different from Julia at the moment. I read all the replies (might have missed some). I already mentioned dynamic memory allocation in my first post as a temporary limitation (currently would be a problem for very few users/uses). Never programmed in Fortran but think it also uses manual memory allocation. While Julia uses those languages in part I think manual is not the reason for their (or Julia's) speed; in general that they are fundamentally different in a better way or others. Garbage collection can be hard real-time and fast (and Julia - the core language wouldn't need changes that break compatibility). or by helping to discover where it could be improved. Partly why I'm writing this. I want to know what needs improving or if something can't be improved, unless breaking things in a minor way or fundamentally that Julia can't work. Frankly, I don't understand your decision problem -- are you trying to decide whether to invest learning in Julia vs some other language? Even though that question does not have a well-defined answer either, it is possible that you would get more useful advice. Yes, I'm not too worried about me. I don't think I'm wasting time learning (more about) Julia, I just do not want to point people to it if there are even better languages available or if there is some defect in Julia I'm missing. It seems to be a good first language to learn, not just for matrix methods (is that all the Universities have started teaching with Julia?). Best regards, Palli.
Re: [julia-users] What is Julia bad for - currently? Practically (or theoretically) - any other language more powerful?
On Friday, December 5, 2014 2:39:11 PM UTC, Tim Holy wrote: I'm glad you're enthusiastic about Julia. If you're looking to pitch in, one good place to look is the list of open issues: https://github.com/JuliaLang/julia/issues If you're most interested in features, filtering on the up for grabs label might be a good start. I did.. The issue was closed and I was pointed to the groups. Anyway I noted the Prolog answer in this thread. I have my forth issue comming but think I'll post in julia-dev for discussion first as not really a bug.. Best, --Tim On Friday, December 05, 2014 06:00:31 AM Páll Haraldsson wrote: On Friday, December 5, 2014 11:34:46 AM UTC, Tamas Papp wrote: On Fri, Dec 05 2014, Páll Haraldsson pall.ha...@gmail.com javascript: wrote: On Friday, December 5, 2014 8:54:26 AM UTC, Tamas Papp wrote: I find your aversion to femtolisp difficult to understand, probably because I tend to think of Julia as a Lisp with the following key features: I don't really have an aversion to femtolisp. I understand it's an awesome implementation of Scheme. If you think of Julia as a Lisp (including Scheme, right?) then when would you prefer Lisp (or Scheme) for new things after Julia came along? Sorry, but did you read my e-mail? As I said, Julia is much more optimizable with its richer type system, which is a great advantage for me. Common Lisp is remarkably nice, but Yes I did read it. Note, I meant would you still recommend (Common) Lisp for anything, you seem to argue well for Julia (and against Lisp/S-expressions while you're at it?). Note also, I said would you prefer Lisp (or Scheme). I know Scheme is a dialect of Lisp and Racket of Scheme, but am not expert on the differences. I may be grouping all the Lisps together unfairly. Your objections to Common Lisp may not generalize to them all. Personally, I like S-expressions too, but many people prefer M-expressions, especially for math (they are indeed more compact). Is there a good way to call any (or all) of the S-expressions languages from Julia? I'm not even sure it's important too, there could be lots of useful preexisting code. I am not so sure that current technology allows a single language to be good at everything, languages like C seem to be difficult to replace with dynamic languages in some situations. These are very abstract points, and I am not sure that discussing them as such is very productive. As many have remarked in this thread, languages are tools, designed for a given prupose. Is a hammer better than a screwdriver? Etc. Libraries are also tools, I'm just not at all convinced we need many languages (for different purposes, maybe with very few limited exceptions) rather than just new libraries. That seems to be a failure of computer science. Why? For C, Julia seems already better for almost all users. If languages like C means C++, I could see all new code in Julia and C++ as legacy. What other like C do you mean? Again, I am wondering if you actually read the replies to your questions. Many have remarked on these issues in their replies to you, eg dynamic vs manual memory allocation, etc. C, C++, and Fortran are fundamentally different from Julia at the moment. I read all the replies (might have missed some). I already mentioned dynamic memory allocation in my first post as a temporary limitation (currently would be a problem for very few users/uses). Never programmed in Fortran but think it also uses manual memory allocation. While Julia uses those languages in part I think manual is not the reason for their (or Julia's) speed; in general that they are fundamentally different in a better way or others. Garbage collection can be hard real-time and fast (and Julia - the core language wouldn't need changes that break compatibility). or by helping to discover where it could be improved. Partly why I'm writing this. I want to know what needs improving or if something can't be improved, unless breaking things in a minor way or fundamentally that Julia can't work. Frankly, I don't understand your decision problem -- are you trying to decide whether to invest learning in Julia vs some other language? Even though that question does not have a well-defined answer either, it is possible that you would get more useful advice. Yes, I'm not too worried about me. I don't think I'm wasting time learning (more about) Julia, I just do not want to point people to it if there are even better languages available or if there is some defect in Julia I'm missing. It seems to be a good first language to learn, not just for matrix methods (is that all the
Re: [julia-users] What is Julia bad for - currently? Practically (or theoretically) - any other language more powerful?
I suspect Tim's idea was to help out by closing issues, not by opening them. On 5 December 2014 at 15:36, Páll Haraldsson pall.haralds...@gmail.com wrote: On Friday, December 5, 2014 2:39:11 PM UTC, Tim Holy wrote: I'm glad you're enthusiastic about Julia. If you're looking to pitch in, one good place to look is the list of open issues: https://github.com/JuliaLang/julia/issues If you're most interested in features, filtering on the up for grabs label might be a good start. I did.. The issue was closed and I was pointed to the groups. Anyway I noted the Prolog answer in this thread. I have my forth issue comming but think I'll post in julia-dev for discussion first as not really a bug.. Best, --Tim On Friday, December 05, 2014 06:00:31 AM Páll Haraldsson wrote: On Friday, December 5, 2014 11:34:46 AM UTC, Tamas Papp wrote: On Fri, Dec 05 2014, Páll Haraldsson pall.ha...@gmail.com javascript: wrote: On Friday, December 5, 2014 8:54:26 AM UTC, Tamas Papp wrote: I find your aversion to femtolisp difficult to understand, probably because I tend to think of Julia as a Lisp with the following key features: I don't really have an aversion to femtolisp. I understand it's an awesome implementation of Scheme. If you think of Julia as a Lisp (including Scheme, right?) then when would you prefer Lisp (or Scheme) for new things after Julia came along? Sorry, but did you read my e-mail? As I said, Julia is much more optimizable with its richer type system, which is a great advantage for me. Common Lisp is remarkably nice, but Yes I did read it. Note, I meant would you still recommend (Common) Lisp for anything, you seem to argue well for Julia (and against Lisp/S-expressions while you're at it?). Note also, I said would you prefer Lisp (or Scheme). I know Scheme is a dialect of Lisp and Racket of Scheme, but am not expert on the differences. I may be grouping all the Lisps together unfairly. Your objections to Common Lisp may not generalize to them all. Personally, I like S-expressions too, but many people prefer M-expressions, especially for math (they are indeed more compact). Is there a good way to call any (or all) of the S-expressions languages from Julia? I'm not even sure it's important too, there could be lots of useful preexisting code. I am not so sure that current technology allows a single language to be good at everything, languages like C seem to be difficult to replace with dynamic languages in some situations. These are very abstract points, and I am not sure that discussing them as such is very productive. As many have remarked in this thread, languages are tools, designed for a given prupose. Is a hammer better than a screwdriver? Etc. Libraries are also tools, I'm just not at all convinced we need many languages (for different purposes, maybe with very few limited exceptions) rather than just new libraries. That seems to be a failure of computer science. Why? For C, Julia seems already better for almost all users. If languages like C means C++, I could see all new code in Julia and C++ as legacy. What other like C do you mean? Again, I am wondering if you actually read the replies to your questions. Many have remarked on these issues in their replies to you, eg dynamic vs manual memory allocation, etc. C, C++, and Fortran are fundamentally different from Julia at the moment. I read all the replies (might have missed some). I already mentioned dynamic memory allocation in my first post as a temporary limitation (currently would be a problem for very few users/uses). Never programmed in Fortran but think it also uses manual memory allocation. While Julia uses those languages in part I think manual is not the reason for their (or Julia's) speed; in general that they are fundamentally different in a better way or others. Garbage collection can be hard real-time and fast (and Julia - the core language wouldn't need changes that break compatibility). or by helping to discover where it could be improved. Partly why I'm writing this. I want to know what needs improving or if something can't be improved, unless breaking things in a minor way or fundamentally that Julia can't work. Frankly, I don't understand your decision problem -- are you trying to decide whether to invest learning in Julia vs some other language? Even though that question does not have a well-defined answer either, it is possible that you would get more useful advice. Yes, I'm not too worried about me. I don't think I'm wasting time learning (more about) Julia, I just do not want to point people to it if there are even better languages available or if there is some defect in Julia I'm missing. It seems to be a good first language to
Re: [julia-users] What is Julia bad for - currently? Practically (or theoretically) - any other language more powerful?
On Friday, December 5, 2014 4:58:44 PM UTC, Mike Innes wrote: I suspect Tim's idea was to help out by closing issues, not by opening them. I guess :) I took a look and there were pages of issues (including the PhD one.. :) You seem to have succeeded in making an awesome language. I'm mainly interested in the less math-heavy issues to enable Julia use for mere mortals/non-typical uses. See my post in julia-dev. Best regards, Palli.
Re: [julia-users] What is Julia bad for - currently? Practically (or theoretically) - any other language more powerful?
On Thursday, December 4, 2014 7:21:21 PM UTC, Isaiah wrote: Please: consider the advice given on the issue tracker and try to ask a small number of specific questions. Also, please search the issue tracker and mailing list (e.g., the question about assembly language has been discussed several times). Sorry about that, I went a little overboard with side-questions. About the assembly language, I think it is not in, but it's probably least important of everything I had to say. In general, asking questions like what is the best language ever is not going to lead to a very productive discussion. Programming languages are tools, not belief systems. Different tools are most appropriate for different purposes. I was trying not to ask what is the best language ever, but would like to know if there are better available, at least for most uses. Yes, they are tools, I believe we have more than we need (thousands), much more than the different purposes. I can see why Julia is good (made) for technical (e.g. speed) but it seems a good fit for lots of other uses that use inferior languages. In general, the answer to the question should I use Julia in production is right now going to be no. Or more specifically: if it is necessary to ask, then the default answer is no. There are certainly people using Julia in production already, for some definitions of production (possibly even with money on the line). But these people usually have the experience to evaluate the trade-offs, and the wherewithal to implement whatever they need. Julia lacks certain language features by choice. For example: it is not designed to write an OS kernel and is unlikely to be a good choice for hard realtime, microcontrollers, or other such uses in the near future I would think Julia could work for microcontrollers right now even (or with little changes).. I was surprised to see Python proposed for such use using modified but stil simple GC (not Pythons reference counting) and still work for hard real-time. This is from memory. You would be crazy to start building a new OS from scratch. Only sane way would be to use Linux and C (GCCism but now also compiles with LLVM) and I'm not saying Linus would go with it, but Julia could be embedded in its C code.. :) (maybe in a few years there will be cross-compilers for a subset of the language). Julia is not specifically designed for logic programming or theorem proving; certainly those things are possible given enough work, but there is probably a better language available (Coq or various Haskell flavors, for example). I was going to write a separate post on logic programming/Prolog/declarative.. Prolog is mindblowing for what it's good for. I wouldn't touch it for anything else. Racket supports Prolog (and ALGOL) using its macrosystem. It feels like cheating if you say you support declarative programming with an alternative syntax.. Couldn't Julia do the same? Or just embed a C Prolog runtime? Or just implement the backtracking in a library and not use Prolog syntax for Horn-clauses? Is declarative used really for anything else (besides SQL)? In other cases, the lacking areas are due to prioritization and the still relatively-small resources available to fully implement desired features. For example, debugging, improved allocation and garbage collection (but, these are in progress!), as well as many library areas. PL/1 (Programming Language number 1) was also a langage so much better than anything previously invented ok.. people I worked with used it in 1996, was this a popular opinion when it first came out? Best regards, Palli.
Re: [julia-users] What is Julia bad for - currently? Practically (or theoretically) - any other language more powerful?
Actually, I opened this thread: https://groups.google.com/forum/?fromgroups=#!topic/julia-users/IjG2ERHVjz0 when I needed to revisit prolog and first order logic for my AI exam... I think Julia can be great for DSLs! The current downside of Julia being very young and not having any established IDE can turn into an upside, if we use this to make a deeper connection between the parser and the IDE. This way we could offer correct syntax highlighting and parsing for any user defined DSL, if they use the same interfaces. I imagine that Julia might become a nice hub for other languages, with its low overhead for calling functions from other languages. If other languages can be integrated as nicely as Keno has done it with his Cxx package, together with good IDE support, this could be huge. Deciding to use Julia wouldn't mean to decide against using other languages. (As much as I like to believe that Julia could be the one and only language, this is still very powerful) 2014-12-04 23:07 GMT+01:00 Páll Haraldsson pall.haralds...@gmail.com: On Thursday, December 4, 2014 7:21:21 PM UTC, Isaiah wrote: Please: consider the advice given on the issue tracker and try to ask a small number of specific questions. Also, please search the issue tracker and mailing list (e.g., the question about assembly language has been discussed several times). Sorry about that, I went a little overboard with side-questions. About the assembly language, I think it is not in, but it's probably least important of everything I had to say. In general, asking questions like what is the best language ever is not going to lead to a very productive discussion. Programming languages are tools, not belief systems. Different tools are most appropriate for different purposes. I was trying not to ask what is the best language ever, but would like to know if there are better available, at least for most uses. Yes, they are tools, I believe we have more than we need (thousands), much more than the different purposes. I can see why Julia is good (made) for technical (e.g. speed) but it seems a good fit for lots of other uses that use inferior languages. In general, the answer to the question should I use Julia in production is right now going to be no. Or more specifically: if it is necessary to ask, then the default answer is no. There are certainly people using Julia in production already, for some definitions of production (possibly even with money on the line). But these people usually have the experience to evaluate the trade-offs, and the wherewithal to implement whatever they need. Julia lacks certain language features by choice. For example: it is not designed to write an OS kernel and is unlikely to be a good choice for hard realtime, microcontrollers, or other such uses in the near future I would think Julia could work for microcontrollers right now even (or with little changes).. I was surprised to see Python proposed for such use using modified but stil simple GC (not Pythons reference counting) and still work for hard real-time. This is from memory. You would be crazy to start building a new OS from scratch. Only sane way would be to use Linux and C (GCCism but now also compiles with LLVM) and I'm not saying Linus would go with it, but Julia could be embedded in its C code.. :) (maybe in a few years there will be cross-compilers for a subset of the language). Julia is not specifically designed for logic programming or theorem proving; certainly those things are possible given enough work, but there is probably a better language available (Coq or various Haskell flavors, for example). I was going to write a separate post on logic programming/Prolog/declarative.. Prolog is mindblowing for what it's good for. I wouldn't touch it for anything else. Racket supports Prolog (and ALGOL) using its macrosystem. It feels like cheating if you say you support declarative programming with an alternative syntax.. Couldn't Julia do the same? Or just embed a C Prolog runtime? Or just implement the backtracking in a library and not use Prolog syntax for Horn-clauses? Is declarative used really for anything else (besides SQL)? In other cases, the lacking areas are due to prioritization and the still relatively-small resources available to fully implement desired features. For example, debugging, improved allocation and garbage collection (but, these are in progress!), as well as many library areas. PL/1 (Programming Language number 1) was also a langage so much better than anything previously invented ok.. people I worked with used it in 1996, was this a popular opinion when it first came out? Best regards, Palli.
