201–210 of 257 posts
Earlier quoted context omitted.
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.
Swift does have a REPL.
> it's faster than other scripting languages That certainly depends on your use case. For instance, the launch time is ridiculously slow, so that you cannot realistically run a small matrix computation in julia from within a shell loop. It is better to use octave for that, where the startup time is almost negligible (just a bit slower than starting a subshell).
I agree. I meta-programmed (enormous) expressions from analytical expressions exported from Mathematica to Julia, because I found Julia to be ~3000 times faster than Mathematica when it comes to calculating eigenvalues. Using BigFloat for higher precision, my matrix function in Julia took ~20 minutes to compile on the first run and ~20 GB of RAM. Smooth once compiled, but I was the only one of my collaborators that h…
The above may only be an issue of BigFloat, to be fair, since Float64 compiled in an instant (never measured, and the time never bothered me).
So Julia has solved a lot of problems for me, and I see great potential for it in the future.
I recently began learning Julia and initially everything was amazing, except for 1 based indexing but with everything else I could overlook that. Then I attempted building something medium sized and it all fell apart. I feel like it needs some serious work on tooling, the module system, packages, etc. Has anyone built something medium-large sized in Julia? Maybe I'm missing something. When I was trying to use modules…
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…
...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.
Earlier quoted context omitted.
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…
> - 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…
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.
Earlier quoted context omitted.
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.
I recently began learning Julia and initially everything was amazing, except for 1 based indexing but with everything else I could overlook that. Then I attempted building something medium sized and it all fell apart. I feel like it needs some serious work on tooling, the module system, packages, etc. Has anyone built something medium-large sized in Julia? Maybe I'm missing something. When I was trying to use modules…
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…
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.
Earlier quoted context omitted.
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?
I wish Julia would be more strict wrt type coercion of integer to float values. I've once spent a day debugging the issue caused by the following line of code, where t1, t2 are floats and v is an array: d = (t2 - t1) * length(v) It should've been LinearAlgebra.norm():Float instead of length():Int. Had julia been stricter the code would have failed to run, saving me much time.
I actually can't think of a single language that doesn't allow you to multiply an integer and a floating point value, yielding a floating point result.
In Rust, all type coercion must be explicit, you can't even add different integer types:
5i64 + 5i32 // WONT compile
5i64 + 5i32 as i64 // will work
I wish Julia would be more strict wrt type coercion of integer to float values. I've once spent a day debugging the issue caused by the following line of code, where t1, t2 are floats and v is an array: d = (t2 - t1) * length(v) It should've been LinearAlgebra.norm():Float instead of length():Int. Had julia been stricter the code would have failed to run, saving me much time.
I actually can't think of a single language that doesn't allow you to multiply an integer and a floating point value, yielding a floating point result.
Earlier quoted context omitted.
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…
> - 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 be…
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.