[one-more-minute]

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.

[grayclhn]

I've seen julia described as "functional" a lot, but is that accurate? There are first-class functions for sure, but the "idiomatic julia" approach to a lot of problems is to allocate a large block of memory, pass around a reference to it and mutate it in place. i.e. all side effects. My terminology might be off, but that's not usually what I think of when I think of functional programming.

[one-more-minute]

I think there's a distinction between idiomatic code and code written for performance. Performance-conscious code looks a lot like C in most languages, not just Julia. Julia just happens to have a lot of that kind of code because it makes it easy to write.

But look at the high-level, user APIs and you tend to see the more functional side – `fft(x)`, `plot(y)` etc., all pure functions which return expressions. Mutation is possible but discouraged via the `!` modifier.

Functions are the primary unit of abstraction – larger programs tend to be designed as collections of functions as opposed to object hierarchies. Higher-order functions like map and filter (aka "functionals") are encouraged.

So I tend to view Julia as a nice functional language which lets me drop down easily when I need to.

[canjobear]

I recently started a project in Julia and, excited by the prospect of a smart JIT compiler, wrote everything in a declarative function style with maps, reduces, and filters. The result was slower than than equivalent Python code. I swallowed my aesthetic sense and rewrote every function imperatively, with for loops updating some mutable array, and now it is quite fast. But I am no longer enjoying coding as much. I switched to Julia for speed, but that speed seems to come at the cost of having to write very imperative code.

In terms of day-to-day programming, I'm not sure what makes Julia a better functional language than Python or Ruby. From my limited experience, it isn't speed.

I understand that work is under way to speed up anonymous function calls and to improve type inference on arrays resulting from `map`, etc. Once that is done then I will consider Julia a nice functional language.

[grayclhn]

"Idiomatic" might have been the wrong way for me to put it, but it seems like one of the biggest advantages and fundamental design decisions of Julia is that it makes numerical computing through side effects _very easy_. Most performance-conscious code doesn't just look like C in other languages, it is C! So I see your point, but I still wish there were a better way to convey exactly the mix of high and low level code that Julia's aiming for.

[RivieraKid]

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.

[one-more-minute]

Believe it or not it's actually perfectly feasible to implement first-class objects and inheritance on top of Julia. You can even integrate it with multiple dispatch (via some metaprogramming and manipulation of the type system) and get object~method(x,y) syntax.

I didn't want it enough to flesh out the prototype (and would argue that Julia's native approach is better anyway) but it's inevitable that someone will do this eventually.

[jghn]

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]

> 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]

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.

[RivieraKid]

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.

[jghn]

On that I fully agree. And going back to your statement that it isn't a very well-defined concept, I think that the two concepts aren't nearly as orthogonal as many would have you believe, it's just that the ways that the two communities have solved similar problems over the years appear to be alien to each other.

[jules]

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)?

[RivieraKid]

Yes, it's just about readability.

[grayclhn]

That seems like a pretty decent description of python, right? :)

[RivieraKid]

Yeah, I like Python but it's slow and Julia seems better designed in many ways :) I'm now using Julia when I don't need Pythin libs.

[grayclhn]

Check out the PyCall[1] and PyPlot[2] packages, then. Julia has pretty good integration with python. I've been pretty happy calling matplotlib from julia. (You probably already know about these packages, but just in case you didn't...)

[1]: https://github.com/stevengj/PyCall.jl

[2]: https://github.com/stevengj/PyPlot.jl