51–60 of 146 posts
Nice paper guys. Any plan to get something peer-reviewed? It would be useful for motivating biologists. Anyone interested in using Julia for bioinformatics is invited to contribute to, or follow the progress of, the BioJulia project: https://github.com/BioJulia/Bio.jl
Earlier quoted context omitted.
It's more natural to you (and to be fair, most programmers who have used OOP languages) purely because you're used to languages which work that way.
> purely because you're used to languages which work that way. You don't know that. I think that for people new to programming both styles can be natural, depending on the specific situation.
People discuss certain styles as being more natural, but in nearly every case (including this syntactical debate) I assert that it is solely due to what the most mainstream languages do and thus what people are more used to seeing.
That's not the same as being natural
Earlier quoted context omitted.
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 sellin…
I tried CLOS, not a fan to be honest. OOP (or functional) isn't a very well-defined concept... I like what languages such as Ceylon, C# or Julia (to an extent) are doing - solid support for both OOP and functional styles. Because you typically need both, some problems are more readable and natural in OOP, others in FP.
I think this provides a very succinct summary of the Julia paradigm at a very high level.
Earlier quoted context omitted.
I think the point is that it special-cases the first object, at least in the syntax. You _could_ write it that way, but since the method is chosen based on all the object types, it doesn't make much sense to do so.
The point was that object.method() is sometimes more readable . For example I find web_socket_manager.reconnect_if_needed() more readable than reconnect_if_needed(web_socket_manager).
Earlier quoted context omitted.
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?
Typed Racket?
(: fun (natural natural -> real))
Earlier quoted context omitted.
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 versi…
Incremental GC is in the works. Do see: https://github.com/JuliaLang/julia/pull/8699 https://github.com/JuliaLang/julia/pull/5227
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'…
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…
Back to Julia: lack of CUDA support was a limiting factor for me when I tried it a year 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'…
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…
* module compilation is not cached, so if you use very many modules your start-up times can be slow
* error messages sometimes require some head scratching. For example, it's not uncommon to get an error that there's no available function convert(::SomeType, (Some, Args)) when there's no obvious convert() to be seen in the code in question. Occasionally the stack trace will be missing from errors, or there won't be a line number. Obviously this is improving quickly, but can be frustrating.
Earlier quoted context omitted.
Why? It can be just a syntactic sugar for method(object).
I think the point is that it special-cases the first object, at least in the syntax. You _could_ write it that way, but since the method is chosen based on all the object types, it doesn't make much sense to do so.
That could get really confusing for the language's users, though, if there were name clashes between the two, and they would be there in any reasonably large program.
And of course, argument order already gives the first and last arguments special attention.
Another way to diminish that special-casing is going to the extreme other end: object.object.object.method(). Remove the now superfluous parentheses and replace the periods by spaces and you end up with Forth.