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 <[email protected]> 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 <[email protected] >> <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. >> >>
