Earlier quoted context omitted.
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.
Why Julia
221–230 of 257 posts
Re: Why Julia
#222As someone who has never run into performance problems with R, and also knows how to use Python - is there a good reason to learn Julia?
Obviously that question depends on your motivation, but one good reason is that it is a great way to learn how software actually works.
R makes it very easy to see the underlying R code (you just type the function name), until you get to a ".Call" or ".Primitive": from that point, it is effectively a black box.
But as most of Julia is written in Julia, you can easily inspect and understand how functions work, all the way down. Moreover, by using the @code_* macros, you can also inspect the various stages by which the code is transformed from high level Julia code down to the actual machine code which is running on your computer.
Re: Why Julia
#223Honestly my biggest bug with Julia was the lack of good programming environment. I detest MATLAB, but I can be very productive in that IDE. PyCharm is pretty good too when using NumPy. For Julia though, the tooling just didn't seem there yet.
Juno is actually quite nice. I find it far more productive than Jupyter and superior to Hydrogen
Re: Why Julia
#224Earlier quoted context omitted.
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.
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.
Re: Why Julia
#225Earlier quoted context omitted.
To demonstrate how slow the startup time is, here’s the respective times for executing ‘print(1)’ from Bash and from REPL on my machine: REPL: julia> @time print(1) 1 0.000031 seconds (7 allocations: 272 bytes) Bash: $ time ./julia -e 'print(1)' 1 real 0m0.184s user 0m0.156s sys 0m0.168s So yes, that’s a slow launch time. If you use Julia in a shell script and it’s starting up Julia on each calculation it will be bru…
honestly, parent had a use case in mind but it's ultra orthogonal with julia's goals. They're aiming at large numerical problems.. as I said above, if you need julia to make a quick one shot computation in a bash script loop, by all means use something else. But my bet is that anybody reading about julia is planning to do the heavy work inside of it, in which init time will probably be insignificant. It's a bit annoy…
Totally agreed, I'm a fan of Julia. I just wanted to comment with the delta between startup time and actual execution for passerby.
Re: Why Julia
#226Re: Why Julia
#227I 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.
JavaScript? 23n + 5 causes a TypeError.
Re: Why Julia
#228[deleted]
Re: Why Julia
#229Earlier quoted context omitted.
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.
Re: Why Julia
#230Earlier quoted context omitted.
> By one letter! Yes, by one letter. Out of 6. "using" is 16% shorter than "import". And it uses better keyboard alternation (the first 4 letters of `import` are on the right side of a qwerty keyboard, the last 2 on the other, for using the only "i" and "n" are consecutive letters on the same half of the keyboard). So "using" is 1. introduced first 2. the primarily documented import mechanism 3. significantly shorter…
But you have to type `python3` which is 7 letters to 5, if we're counting :) Seriously though, it's hard to write one manual which gives everyone the perfect on-ramp for their needs. I actually think it's fair to aim it low, make it easy for matlab refugees to get started, interactively. People who know how namespacing works in several other languages (and intend to write big projects) are the ones well-equipped to k…
> But you have to type `python3` which is 7 letters to 5, if we're counting :)
Of course, that was actually a pretty big consideration during the "vcs wars", both the length and the alternation of VCS commands.
> I actually think it's fair to aim it low, make it easy for matlab refugees to get started, interactively.
Then don't whine that people use that, and police your community.
> Nobody has been victimised!
Well how's that for dishonesty. ChrisRackauckas pretty much goes "this article is invalid because you're doing exactly what the languages suggests and incentivises" half a dozen comments above.