Hacker News Reader

Comment by RivieraKid | Hacker News Reader

Agreed, that's my experience as well. Julia is amazing for scripts and smaller projects, but I wish there was something like Swift (which I'm increasingly convinced is closest to the ultimate general-purpose language) with all the nice things that Julia has.

Specifically, these things make Julia less suitable for larger projects:

- Lack of support for OOP. And no, purely functional programming is not the best way to code all projects.

- Dynamic typing.

- Doesn't compile to native code (there are ways to do it, but too complicated and there are caveats).

- Module system doesn't seem to be design well.

- You can't use a function before it's defined.

View on HN

Sorry, why do you need OOP? I haven't coded OO in about 10 years now. (Mostly Julia, elixir, and functional JavaScript). It's great. Would never go back.

I even had to write python once, so I built a class where none of the functions were passed self (so it was basically a functional module)

In python you’d normally just use module level functions for that. Using a class without having instances and all static functions doesn’t really buy you anything.

Iirc, modules have a dependency on bareword paths that can get awkward. I'm not a professional python programmer, so the fastest way for me to deliver something that I could be 100% guaranteed to work was that way. Maybe I'm wrong, but that was my logic.

The only problem I found with this approach is to manage state and dependencies: say, if the functions need to work with database, it is not convinient to send it as a parameter. A class instance initialised with a database looks more feasible in my opinion.

Your alternative is dependency injection. What you seem to be describing is class factories (I.e. the use of meta classes) which /is/ OOP.

That said, I think OOP is fine. And so is FP. They’re just tools, and I would prefer to model nouns in the former, and model verbs with the latter.

That’s a pattern I use a lot. Passing services and connections around everywhere is a pain, but I like to stick to a more functional style. I generally use classes as a place to hold context (E.g. dB connection) and then use a functional style within the class. Works as a fairly happy medium for me.

Because sometimes it's better for readability and conceptual simplicity to structure the code as objects connected to each other. Most of large-scale successful projects, often written by better developers than me or you, use OOP.

And 80% of the internet switches (Cisco and juniper) are controlled by erlang. So?

I think you're looking at this wrong. Part of the reason why so many large scale products use OO, is because they use Java, and java is awesome if you're working at such a large organization that your productivity is most easily measured by pointy haired managers who count how many LOC you've written ;)

As for readability and conceptual simplicity, may I introduce you to something called the Factory pattern?

I don't think that's a big part of the reason to be honest. Also, modern Java has a reasonable support for FP.

I'm talking about projects like Mapbox, Blender, Firefox, Android.

I might be wrong, but my understanding is things happened backwards from that. OOP tried to solve the problem of how to get tons of devs working on huge projects at the same time; java came along to try to be an awesome OOP environment, so Java became the standard.

What is or is not OOP is actually fuzzy. When it boils down to it erlang's actor model is basically an implementation of smalltalk objects (but don't tell joe Armstrong that). Elixir's module/struct/protocol looks awfully like OO in the post bjarne soustrop era.

Conversely, python's objects feel anti-object since you're passing self all the time (aka dot notation is a weaksauce syntactic sugar)... You could easily model this behavior if you really wanted in Julia, for example, with a custom operator (not that you should)

    function Base.^(o <: Object, fn)
       (a...) -> fn(o, a...)
    end

Joe already knows. He and Alan Kay had a talk about it. It was great.

> OOP tried to solve the problem of how to get tons of devs working on huge projects at the same time

I am skeptical of that history. Simula and smalltalk were academic endeavors long before lots of devs were working on projects, Java became popular because it was a portable C++ which had no pointers and garbage collection.

Smalltalk was being adopted across the industry when Java came around, the big difference was that JDK was free beer and one of the big Smalltakers (IBM) rebooted their environment into Eclipse, while jumping into Java bandwagon.

Was it Visual Age for SmallTalk which became Visual Age for Java which later became Eclipse? Vaguely remember reading something like that earlier.

Yes. With Gamma, one of the pattern book authors, as architect on Eclipse team.

Interesting, thanks.

That is seriously rewriting history. Smalltalk was not big in any shape or form in business in the mid '90s.

Like Java ended up being afterwards no.

It surely had lots of consulting opportunities, though.

Erlang is arguably the most object-oriented language in common usage. Actor concurrency is closer to the original OO model than everyone else's "struct with methods". I'm more inclined to agree with you overall, but Erlang might not be your best example. :)

Edit: never mind, you're obviously aware...

Erlang is more purely object-oriented than Java. These are the words from its creator itself

http://www.infoq.com/interviews/johnson-armstrong-oop

> Most of large-scale successful projects, often written by better developers than me or you, use OOP.

Ad hominem if I ever saw one.

I would be more interested in why needing dynamic typing is such a deal breaker

- Doesn't compile to native code (there are ways to do it, but too complicated and there are caveats).

What do you mean by that? It absolutely is compiled to e.g. x86_64 instructions by default, going through LLVM. Do you mean no standalone binaries? If so, that's actively being worked on by e.g. PackageCompiler.

https://github.com/JuliaLang/PackageCompiler.jl

> - You can't use a function before it's defined.

I'm not sure what you mean by this. You obviously can't call a function before it is defined, but you can use a function in another function without any problems:

    julia> foo(x) = bar(x)
    foo (generic function with 1 method)
    
    julia> bar(x) = x+2
    bar (generic function with 1 method)
    
    julia> foo(3)
    5

> - Lack of support for OOP. And no, purely functional programming is not the best way to code all projects.

Julia doesn't rely on functional programming and there are also structs and operator overloading. What feature do you think is missing specifically?

> Dynamic typing.

Julia is not dynamically typed, though if you write a type unstable function, you will get back an Any type.

- Module system doesn't seem to be design well.

What specifically is problematic?

Julia is dynamically typed: https://stackoverflow.com/a/28096079.

> Julia doesn't rely on functional programming and there are also structs and operator overloading. What feature do you think is missing specifically?

Interfaces, access modifiers, calling methods via object.method() instead of method(object), you can't define methods inside classes (structs) with an implicit "this" parameter.

> Module system doesn't seem to be design well.

Working with a multiple file project feels weird... I have to first "include()" the source code and then use "import" or "using". The module system in Java, Javascript or Swift seem to be more straightforward and sensible.

> - Lack of support for OOP. And no, purely functional programming is not the best way to code all projects.

...and neither is OOP? For doing data things I greatly prefer functional programming for ease of understanding how the data flows and gets changed.

> - Doesn't compile to native code (there are ways to do it, but too complicated and there are caveats).

Neither does Python, neither does R. AOT compilation is being worked on, I expect it to get pretty great. C and FORTRAN do, sure, but most people are not writing C and FORTRAN in production.

> - Module system doesn't seem to be design well.

It’s maybe not perfect, but it’s honestly miles better than Python.

> - You can't use a function before it's defined.

This feels like an incredibly unfair and unreasonable complaint given not many languages that aren’t AOT compiled actually support this and Python and R certainly do not.

> ...and neither is OOP? For doing data things I greatly prefer functional programming for ease of understanding how the data flows and gets changed.

OOP support doesn't imply not having support for functional programming. Swift, Scala, and Rust are good examples of languages thst support both.

The parent seems to like julia, but laments that it is missing several features which they have come to appreciate and depend on from Swift. Your response points out that Python and R don't have those features either, which is true, but sometmwhat besides the point of the parent comment.

> Lack of support for OOP.

Please. No. Languages that try to do everything are crap. If you want to do something OOP, why don't you grab a language built for it?

I do. Many languages have excellent support for both OOP and FP. I think Swift is currently the best-designed general-purpose language and wish that it would improve in areas where Julia is better, e.g. standard library and available packages or REPL.

I'd much rather whave a couple of language that specialize in their own paradigm rather than a single one which tries to do everything, to be honest.

What's convenient about Swift as a language which "tries to do everything" is that you can mix and match. Sometimes it's convenient to use different programming paradigms for different components.

It also makes the code a pain to read and maintain.

Difference of opinion. Swift is the most self-documenting language I have worked with between the named function parameters and the power of the type system.

Swift does have a REPL.

Yeah, but Julia's REPL is better in several ways.

Which ways?

Faster startup, better printing of values, integrated package manager, integrated help system, filesystem autocompletion, etc.

Swift actually has faster startup, a better package manager by far, better custom printing support. It also has playground and jupyther notebook integration. Swift is a solid piece of engineering, Julia is a hacky toy.

I'm talking about the REPL. I've tested all points I mentioned before submitting the comment.

honest question, not a serious SDE here. In what ways is julia not supportive of OOP?

It doesn't have interfaces for example. It doesn't have access modifiers. Also, not sure if this belongs to OOP but working with optionals is cumbersome.

Python also doesn’t have interfaces or access modifiers. Would you consider Python to have bad support for OOP by those criteria?

Yes, Python definitely has bad support for OOP.

Smalltalk doesn't have them, either.

Indeed. Alan Kay might take some issue with this notion of OOP.

Only if define OOP as what java does.

Smalltalk might be a better example.

Yes, although Python feels more suitable for OOP for some reason, not sure why... perhaps it's the object.method() notation. It's often more natural and readable and allows better autocompletion in an IDE. Also, I prefer that methods are defined inside of a class, it's immediately clear what is a top level functions and what is a method belonging to a class or struct.

Well Julia sort-of does have interfaces, it’s just that those interfaces are protocols and only conventions (ie there’s no way to say “my type will implement Foo interface”). There is an interface for iteration. If you want to implement it then you just have to implement the iterate function for your type and zero and 1 parameters. Similarly the way to say that your type has a length isn’t to implement the HasLength interface but to just implement the length function.

Again sorry for being dense but:

- aren’t access modifiers the way to define scope? That is possible in julia.

- getters and setters, wouldn’t those be defined in a struct in julia?

- inheritance: pretty sure this doesn’t exist in julia.

I seriously barely understand, i’m reading from the doc here:

https://docs.julialang.org/en/v1/manual/types/index.html

Reply on news.ycombinator.com