41–50 of 146 posts
Earlier quoted context omitted.
Object.method() doesn't really make sense due to multiple dispatch, I think.
Why? It can be just a syntactic sugar for method(object).
Earlier quoted context omitted.
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.
Julia supports multiple dispatch OO, which is more powerful than what you get from traditional OO languages. Or do you purely mean the x.foo(y) syntax rather than foo(x,y)?
Earlier quoted context omitted.
> 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).
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…
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.
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'…
* 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.
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'…
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…
https://github.com/JuliaLang/julia/pull/8699 https://github.com/JuliaLang/julia/pull/5227
anyone know where I can get a juliabox.org invite code?
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