81–90 of 134 posts
I really wish there was a language based on Swift that would include most of the nice language, REPL and library characteristics of Julia (and perhaps few from Dart). That would get really close to a "perfect language" for me. Overall I like Julia - and use it as a CLI calculator as well - but there are several things that prevent it from being a good general purpose language: - OOP support is "meh". - str.parse(Int)…
But multiple dispatch support is great!
I use python CLI for exactly the same :)
I really wish there was a language based on Swift that would include most of the nice language, REPL and library characteristics of Julia (and perhaps few from Dart). That would get really close to a "perfect language" for me. Overall I like Julia - and use it as a CLI calculator as well - but there are several things that prevent it from being a good general purpose language: - OOP support is "meh". - str.parse(Int)…
crop(resize(first(images), 100, 100), 25, 25, 75, 75)
images
|> first
|> resize(100,100)
|> crop(25, 25, 75, 75)
images |> inspect
|> first |> inspect
|> resize(100,100) |> inspect
|> crop(25, 25, 75, 75) |> inspect
I really wish there was a language based on Swift that would include most of the nice language, REPL and library characteristics of Julia (and perhaps few from Dart). That would get really close to a "perfect language" for me. Overall I like Julia - and use it as a CLI calculator as well - but there are several things that prevent it from being a good general purpose language: - OOP support is "meh". - str.parse(Int)…
Swift syntax is really a pain to deal with. I programmed Objective-C for many years, and that syntax makes sense for object-oriented programming. But it is a disaster for functional programming.
Making closures and calling function objects gets really confusing with Swift syntax. Swift methods cannot naturally be passed around like a Julia function.
> str.parse(Int).abs is more readable than abs(parse(Int, str))
The problem is that the Swift approach entirely lacks composability. Julia's `abs` and `parse` can easily be passed around as first class objects. Besides a lot this readability cases can be solved with the `|>` operator like this:
parse(Int, "-12") |> abs
The Julia approach makes it easy to use functions as arguments to higher order functions such as map and broadcast. Using dot (.) is shorthand for broadcast which lets you do stuff like:
abs.(parse.(Int, ["-12", "-3"])) parse.(Int, ["-12", "-3"]) .|> abs
Both cases show parsing an array of numbers and taking the absolute value.
> 1-based indexing.
I know many people hate this but I don't get it. I have spent most of my life with 0-based indexing yet this represents no obstacle for me. When I use Julia I just think as if I am writing math. All my math text books are 1-indexed based and that is just something you get used to. In fact after using Julia for a long time, I frankly prefer 1-based indexing.
0-based indexing IMHO is quite nice when you are dealign with inserting numbers into arrays, or with C-style loops. But neither is usually done in Julia.
> Lack of good support for nullability, think of "if let", "guard let", "??", "object?.property".
That used to bother me as well coming from Swift. But this request actually makes not sense in a dynamic language. What you are basically asking it to have programming constructs to give you type safety at compile time. But Julia is a dynamically typed language, so you will never have this anyway. It if a fools errand.
Julia is built to catch type problems at runtime, not at compile time. Those problems will be caught at runtime in Julia even without `if let` and `guard let`. They don't actually add any value to a language like Julia.
Swift NEEDS these constructs because statically typed languages are quite poor at catching type problems at runtime. They are very dependent on catching type problems at compile time.
> OOP support is "meh". I kind of view that as a positive. I have spent years doing object-oriented programming but I must say the Julia way just makes a lot more sense. It is so much easier to work with. I find OOP inherently bad for a REPL environment. And REPL environments make me a lot more productive. You can built up functionality in a far more incremental and iterative fashion.
I still quite like Swift, but I feel it is going in the wrong direction. I tell tale sign for me when going back to Swift code these days is being reminded just how complex the language and the tools have gotten. If you do Swift everyday, that is easy to forget, but the whole toolchain is actually kind of complex.
For instance getting a closure setup correctly with appropriate tagging for life time/ownership of data is not easy. The Schizophrenia between trying to be both an object-oriented language and a functional one becomes more and more apparent.
Sometimes I wonder if Apple made the right choice and whether going with something more akin to Objective-Smalltalk would have been better. It would have been a more natural fit with the Objective-C syntax, which feels very wrong in a functional setting.
Earlier quoted context omitted.
“OOP” is an anemic special case of the multiple dispatch that Julia provides. So if you don’t know any better you can program in that style using Julia. “str.parse(Int).abs is more readable” No, but it makes sense if you also think that OOP makes sense. You can index based on anything you want.
No it's not. OOP is regularly used for new projects by experienced programmers. Julia doesn't have interfaces for example. I know that I can set indexing to be 0-based. Not a good solution.
You got to compare it to Ruby, Python etc.
Also I have no idea what an interface definition would look like in Julia. A function in Julia isn't bound to one specific type like in an OOP language.
Earlier quoted context omitted.
I'm using 1.4 on an Intel i5 4460, so about 3 years older but not a laptop cpu. I don't even think 0.5 seconds are that noticeable...
“3 years older but not a laptop cpu” might mean “spinning disk”, rather than SSD, too.
Earlier quoted context omitted.
I've been using julia for about three years now and from my interactions with devs and the issues on github, caching more code has only been considered in the past year because before then, the priorities were in getting the language stable, to 1.0, and on other lower-hanging performance fruit. "Just cache more" turns out to be a harder problem than it seems at first sight, if by the very nature of the language loadi…
Yeah, Julia has had some form of precompilation/caching for ages now, but sorting out all invalidations appears to be highly nontrivial [1] and devs have had more fundamental priorities pre-1.0. There have been some substantial improvements to latency in the meanwhile nonetheless, and PackageCompiler.jl is a viable option as well. [1] https://github.com/JuliaLang/www.julialang.org/pull/794
This has always been a huge complaint for Julia and it seems like one of those things that happens to new languages. People are excited, there are a few big rough edges that drive people away, they get ignored or underprioritized for WAY too long, and a giant window of opportunity is missed. I think of D with weeding out garbage collection, go with generics, D with tools and infrastructure, Zig with its refusal to parse carriage returns or tabs, Rust with compilation times, everyone with a lack of an easy road to a GUI, Jai not being released at all...
I think instead of getting lots of areas to a decent stage, languages end up trying to be the best in a single area and placate their hardcore users, when things like C++ succeed by not having huge blindsides and pitfalls, even if it ends up a little rougher in many areas.
I love the julia language. I would love to use julia as a command line calculator. Unfortunately, starting the interpreter is excruciatingly slow, an order of magnitude slower than octave or python (and several orders of magnitude slower than bc or dc).
How long does it take to start on your computer? If I have run it before. It takes less than 0.25 seconds. I use a several years old Mac. On none of my computers do I experience startup times which has any practical relevance to being productive. The only real problem I have experienced in Julia is using plotting libraries and those you can include in your Julia image with PackageCompiler.
Since this is a calculator topic, I'd like request your input on which calculators you use. I use the Emacs calculator (M-x calc) and XCalc ( http://www.tordivel.no/xcalc/ ) as I like to use RPN calculators. The Windows 10 calculator is painful and slow. XCalc has a mini mode, where it will sit as a small, single line without distracting you too much. I like that feature very much. One thing with Emacs is that I forg…
I use a function "ev" that wraps bc. It's crude, but handy: $ ev() { echo "scale=3; $*" | bc -l; } $ ev 22/7 3.142
$ math() { echo "scale=2 ; $" | sed -e "s:x::g" | sed -e "s:,::g" | bc; }
$ math 5,382 x 48,927.3
263326728.6
Earlier quoted context omitted.
Yeah, Julia has had some form of precompilation/caching for ages now, but sorting out all invalidations appears to be highly nontrivial [1] and devs have had more fundamental priorities pre-1.0. There have been some substantial improvements to latency in the meanwhile nonetheless, and PackageCompiler.jl is a viable option as well. [1] https://github.com/JuliaLang/www.julialang.org/pull/794
Just saying caching is difficult doesn't gel with my experience of what seems like low hanging fruit. I realize a lot of Julia ends up being templates, but when just one line of importing the same plotting package always takes 30 seconds or so, I get suspicious of the idea that all the usability warts are super difficult to solve. This has always been a huge complaint for Julia and it seems like one of those things t…
edit: also, time-to-first-plot is a lot less than 30 seconds for me these days, even without PackageCompiler. (time-to-second-plot is, as usual, instantaneous)