If you are a Kotlin or TypeScript coder, Julia is not for you. While it has all the general programming facilities, it is mainly a scientific programming language, not a web or app language.
If you don't have at least an undergrad in CS/Finance/Math/Physics/Engineering, you likely don't have a need for it and would be better off with Python or some other mainstream languages with numeric libraries for the occasional vector math that Julia primarily targets.
> Even in older machines I still had to come to a python package that didn't load in a fraction of a sec
Spacy would take a while to load the english model. Pandas + Scikit-learn used to take a few seconds some years ago, without an SSD (~1 sec each now). So did matplotlib. With SSDs and modern hardware though, things got a lot better.
Only some of Julia's packages were heavy. Gadfly was the worst then. When I first looked at it, the slow startup stood out for me as well. But I can tolerate 5 sec for a large package though in an interactive session. I am used to that. Still, I would agree that load times should be their priority.
I haven't followed Julia much in a while. So I can't speak for the performance changes. I tried it when it first came out.
If you look for Python in Julia, you will be disappointed. When I first tried Julia, a few years ago, on a slow machine without an SSD, the plot package, Gadfly, took minute(s) to load.
This was likely due to the JIT. Startup times are not a key factor for its target audience. This is not a typical scripting language. People fire up the interpreter and leave it running all day or all week, as they test snippets in it. It is used like Matlab or like a Jupyter notebook session. Scientific packages in Python take several secs to load as well. On the full dataset, the extra few secs of startup means little when the savings are in orders of magnitude.
But if you are testing on small datasets and starting it up like a scripting language, I can see how you would be disappointed.
Once you get over your newbie tunnel vision with the block syntax, you will find that Julia is a compact (despite the ends), powerful, high-performance, array language with meta-programing features.
No, it is not an academic language like say, Haskell. It is a practical programming language for research into math-heavy algorithms - Artificial Intelligence, Signal Processing, Image Processing etc.
No, it is not a general purpose language for day-to-day scripting or web/business programs. It is not, as you put it, for "bootcamp coders".
"want it all" refers to the historically diametric needs of computer scientists. They need a high-level, expressive, vectorized language like Matlab to prototype and interactively explore data... and a high performance language like Fortran or C++ to implement that algorithm after, on the fastest supercomputers. This gives them both in one tool.
It sounds like your never wrote any significant matrix/math code in your life. Writing any complex matrix code with just loops is like having one's teeth pulled, compared to how it is done in an array language like Julia. The block syntax is the least of one's worries when dealing with high-dimensional data.
People who currently write Matlab/Octave code. It is trying to be familiar to its community of computer scientists writing vector code. You are clearly not the target audience. This is like wailing at design choices of R without understanding its S legacy.
Also people who used Algol based languages in the past. Just be thankful, the begin wasn't also added.
For someone who is taking a shot at bootcamp coders, you are evaluating Julia with the syntax superficiality of someone who learnt programming last year.
Julia is Python + Numpy + Numba, without GIL, with metaprogramming features to make the code more symbolic than is possible with Python. It's community also tries to work along side Python, rather than compete. There are packages to call both ways.
If you write only occasional linear algebra code, Julia is not worth the effort. But for those who write a lot more math code, it could be.
It is the only array programming language with a decent JIT. It is a high-level array programming language like Matlab/Octave/R, while executing at about the speed of a native language like Fortran. If you prototype a lot of linear algebra functions in an interactive environment, this is the language for you. The thunder is somewhat stolen by newer tools like tensorflow, which give you GPU performance, while still providing a high-level language (Python). Still, Julia has meta-programming features. So it can deliver compact, high-performance mathematical code.
If MIT had been having its way, we'd all be using Scheme.
Julia is a better Octave (open source Matlab replacement) - good for computer scientists, but software engineers will not be interested. Question is, will the scientific community create enough definitive libraries to provide alternatives for Matlab toolboxes. Not enough seem to have attended the Octave party.
Also, computer scientists don't define popular adoption of programming languages. Else, we'd be using Haskell/Scheme by now.
> Good grief. The problem is mentally unstable people
Are you suggesting that US has a unique mental health problem?
I have seen far worse mental health situations elsewhere. Mental health is even a taboo topic in less developed countries, much less have imperfect access to care. Yet, in these countries, psychopaths and people who go postal don't do mass shootings (they may throw something around or charge with a sharp/heavy objects - much easier to deal with) because they don't live societies with a cavalier attitude to optimized killing tools.
> Yes, but a poor design may make it difficult or impossible to optimize later.
Which is fine. Optimization is possible to a reasonable degree, but not completely. A 40 or 400 times slower program is only perhaps 2-4 times slower after Cython, Numba, ShedSkin etc - a very reasonable trade-off. Further that, Python is meant to be used with a splash of C for those few core data structures and algorithms, not replace it. Have a lot more custom stuff that needs native performance? Python was never meant for that use case.
> Using hashtables to implement arrays, for example.
> Maybe not the MOST important, but I sure don't like waiting for the computer any longer than is strictly necessary.
No one does. But people like even less to wait for people writing code. It takes much longer to write C++ code and it takes longer to compile it as well. Fast, optimized native code is valuable only if your program is going to be used on larger amounts of data, performing intensive computations or used by a large number of people. Most code is not written for these cases.
Most code is written for very local purposes, doing fairly simple and focused things, often for one-off purposes. It is illogical to use a programing language that is slow to write code in and takes longer to compile. This is not just true today. These were successful (and rational/logical) arguments offered 2-3 decades ago when CPU time was at a much higher premium and interpreters were much less optimized.
You should measure the total performance (programmer and code) and costs, not just CPU time.
> I'm going to go out on a limb here and say that there isn't *anyone* who wouldn't benefit from faster performance.
Matlab and R are most commonly used by computer scientists and statisticians. Both are worse than Python by runtime performance. These are not unintelligent people. Their time is as valuable as anybody else's. So why do these people use them? Because their time is valuable.
Often time the runtime difference between C++ and Matlab/Python/R is 0.01 sec vs. 0.5 sec. It might matter if the difference is 1 hr and 500 hrs, same ratio, but at such small time scales, the human latency barely even takes notice.
> Mind you, there are features worth trading CPU time for, but they have to be justified and should never be the default case if they lead to performance hits. The simplest, fastest alternative should always be an option.
You have it exactly wrong. Human time is first and foremost important. That is the default case. Humans are extremely hard and expensive to train and cannot be upgraded. They are the bottleneck and need to be most managed. Performance is something you worry about after you produced something correctly. Generally speaking, identifying and optimizing small bottlenecks is much more productive than starting with performance as a key consideration even when you don't need it.
Premature optimization is the root of all evil -- Donald Knuth
The entire point of programming languages is human performance, not computer performance. CPU performance is the job for compilers (you can transliterate a fair subset of Python to C/C++. Eg. ShedSkin). That said, I am enthusiastic for productive AND fast tools - Rust & Nim, in my case, but none of these are Python/Matlab/R replacements yet.
I would like to hear from people who switched from the more mainstream numpy and tensorflow for linear algebra.. to Julia. What were your experiences? Was the worflow much more productive? What were the other gains?
Windows 10 is snappy, as long as you have an SSD. It is slow, if you run it off a HDD. Yes, It should not be this way, but I don't think anyone using it off a modern, even budget laptop with a modest SSD, finds it slow. That is the only resource it badly needs. Yes, "telemetry" that the user is not allowed to disable (or even fully disclosed) is basically spyware. We have more of a case for open source OS today than 10 years ago.
Variations of LLLT have gone by a variety of alternate names including low-power laser therapy (LPLT), soft laser therapy, low-intensity laser therapy, low-energy laser therapy, cold laser therapy, bio-stimulation laser therapy, photobiomodulation, photo-biotherapy, therapeutic laser, and monochromatic infrared light energy (MIRE) therapy.
Low-level laser therapy (LLLT) is a form of alternative medicine that applies low-level (low-power) lasers or light-emitting diodes (LEDs) to the surface of or in orifices of the body. Whereas high-power lasers are used in laser medicine to cut or destroy tissue, it is claimed that application of low-power lasers relieves pain or stimulates and enhances cell function.
The effectiveness of low-level laser therapy (LLLT)
Low-level laser therapy versus sham treatment
One study [64] with a low risk of bias, compared low-level laser therapy treatment with sham laser therapy treatment in elderly patients over 60 years. The study provided low quality evidence that LLLT was more effective in pain relief at intermediate follow-up (44.7%) compared with sham LLLT (15.2%).
Low-level laser therapy + exercise versus sham LLLT + exercise
Results on pain and disability at post-treatment were reported by one study [62] and no difference was found between the intervention groups on both outcome measures.
Two studies [62, 63] reported on pain intensity and disability at short-term (3 months) follow-up. The pooled analysis of these two small trials (n = 61) showed a significant difference in pain relief (WMD 13.57 [95%CI 26.67; 0.47]). No difference was found on disability between those who received LLLT plus exercise and those who received sham LLLT + exercise (WMD 5.42 [95%CI 23.55; 12.71].
Very low quality evidence was provided (serious limitations, inconsistency, and imprecision) for the effectiveness of LLLT + exercise compared to sham LLLT + exercise on pain intensity at short-term follow-up, but not for disability.
Low-Level laser therapy versus exercise
One study [27] compared the effectiveness of LLLT with exercise therapy post-treatment. No statistically significant difference was found between both therapy groups on pain level and disability.
This looks exactly like quackery. You perhaps tried it and subsequently psychologically bought into it. That is also typical with these alternative stuff.
It is more like a phablet (minus the phone stuff) with a controller. GPD is a very niche product, not anywhere in the same space as the Surface Go. Go was reviewed to have a good keyboard, for the form factor. I would not do any serious typing or reading with the GPD.
Why are you comparing with laptops that are in an entirely different class? These laptops weigh 3 times more and have 1/2 the battery life. I have one of these laptops. I don't intend to lug mine around very much. The power brick is heavy and I don't trust it to last my day on battery alone. If I was in the market for a Surface Go, it would be because I need a simple, ergonomic machine that I can carry with me all the time.
If you think this is overpriced, by all means, compare with other 10" Windows devices with high-density screens, touch and pens.
My next job might need me to move around between meetings, read a lot more email, annotate PDFs and does not need me to write any code or at least process any data locally. Surface Go should work well for that. Right now, I have a GPU laptop for deep learning, 3D visualization and some gaming. These are completely different needs.
A.) I mentioned my use case - research analytics. I am the only user for most of the code I write. My results have users, not the code.
B.) If your users are not tech-savvy, you distribute the binaries, not the code, just as with any other language. There are plenty of tools to do that.
Slashdot Mirror
It does.
https://github.com/JuliaEditor...
If you are a Kotlin or TypeScript coder, Julia is not for you.
While it has all the general programming facilities, it is mainly a scientific programming language, not a web or app language.
If you don't have at least an undergrad in CS/Finance/Math/Physics/Engineering, you likely don't have a need for it and would be better off with Python or some other mainstream languages with numeric libraries for the occasional vector math that Julia primarily targets.
> Even in older machines I still had to come to a python package that didn't load in a fraction of a sec
Spacy would take a while to load the english model. Pandas + Scikit-learn used to take a few seconds some years ago, without an SSD (~1 sec each now). So did matplotlib. With SSDs and modern hardware though, things got a lot better.
Only some of Julia's packages were heavy. Gadfly was the worst then. When I first looked at it, the slow startup stood out for me as well. But I can tolerate 5 sec for a large package though in an interactive session. I am used to that. Still, I would agree that load times should be their priority.
I haven't followed Julia much in a while. So I can't speak for the performance changes. I tried it when it first came out.
If you look for Python in Julia, you will be disappointed. When I first tried Julia, a few years ago, on a slow machine without an SSD, the plot package, Gadfly, took minute(s) to load.
This was likely due to the JIT. Startup times are not a key factor for its target audience. This is not a typical scripting language. People fire up the interpreter and leave it running all day or all week, as they test snippets in it. It is used like Matlab or like a Jupyter notebook session. Scientific packages in Python take several secs to load as well. On the full dataset, the extra few secs of startup means little when the savings are in orders of magnitude.
But if you are testing on small datasets and starting it up like a scripting language, I can see how you would be disappointed.
Once you get over your newbie tunnel vision with the block syntax, you will find that Julia is a compact (despite the ends), powerful, high-performance, array language with meta-programing features.
No, it is not an academic language like say, Haskell. It is a practical programming language for research into math-heavy algorithms - Artificial Intelligence, Signal Processing, Image Processing etc.
No, it is not a general purpose language for day-to-day scripting or web/business programs. It is not, as you put it, for "bootcamp coders".
"want it all" refers to the historically diametric needs of computer scientists. They need a high-level, expressive, vectorized language like Matlab to prototype and interactively explore data... and a high performance language like Fortran or C++ to implement that algorithm after, on the fastest supercomputers. This gives them both in one tool.
It sounds like your never wrote any significant matrix/math code in your life. Writing any complex matrix code with just loops is like having one's teeth pulled, compared to how it is done in an array language like Julia. The block syntax is the least of one's worries when dealing with high-dimensional data.
People who currently write Matlab/Octave code.
It is trying to be familiar to its community of computer scientists writing vector code. You are clearly not the target audience.
This is like wailing at design choices of R without understanding its S legacy.
Also people who used Algol based languages in the past. Just be thankful, the begin wasn't also added.
For someone who is taking a shot at bootcamp coders, you are evaluating Julia with the syntax superficiality of someone who learnt programming last year.
Yes, Python is the current replacement.
However, Python is just not an array programming language by design.
https://github.com/malmaud/Ten...
Julia is Python + Numpy + Numba, without GIL, with metaprogramming features to make the code more symbolic than is possible with Python.
It's community also tries to work along side Python, rather than compete. There are packages to call both ways.
If you write only occasional linear algebra code, Julia is not worth the effort. But for those who write a lot more math code, it could be.
Software engineers hate R.
Statisticians love R and find it very easy to learn and use.
Different target audience.
It is the only array programming language with a decent JIT.
It is a high-level array programming language like Matlab/Octave/R, while executing at about the speed of a native language like Fortran.
If you prototype a lot of linear algebra functions in an interactive environment, this is the language for you. The thunder is somewhat stolen by newer tools like tensorflow, which give you GPU performance, while still providing a high-level language (Python).
Still, Julia has meta-programming features. So it can deliver compact, high-performance mathematical code.
If MIT had been having its way, we'd all be using Scheme.
Julia is a better Octave (open source Matlab replacement) - good for computer scientists, but software engineers will not be interested. Question is, will the scientific community create enough definitive libraries to provide alternatives for Matlab toolboxes. Not enough seem to have attended the Octave party.
Also, computer scientists don't define popular adoption of programming languages. Else, we'd be using Haskell/Scheme by now.
> Good grief. The problem is mentally unstable people
Are you suggesting that US has a unique mental health problem?
I have seen far worse mental health situations elsewhere. Mental health is even a taboo topic in less developed countries, much less have imperfect access to care. Yet, in these countries, psychopaths and people who go postal don't do mass shootings (they may throw something around or charge with a sharp/heavy objects - much easier to deal with) because they don't live societies with a cavalier attitude to optimized killing tools.
OK, I'll bite. What is your "extensive experience"?
> Yes, but a poor design may make it difficult or impossible to optimize later.
Which is fine. Optimization is possible to a reasonable degree, but not completely. A 40 or 400 times slower program is only perhaps 2-4 times slower after Cython, Numba, ShedSkin etc - a very reasonable trade-off. Further that, Python is meant to be used with a splash of C for those few core data structures and algorithms, not replace it. Have a lot more custom stuff that needs native performance? Python was never meant for that use case.
> Using hashtables to implement arrays, for example.
Hence, numpy.
50 hrs, not 500 hrs.
> Maybe not the MOST important, but I sure don't like waiting for the computer any longer than is strictly necessary.
No one does. But people like even less to wait for people writing code. It takes much longer to write C++ code and it takes longer to compile it as well. Fast, optimized native code is valuable only if your program is going to be used on larger amounts of data, performing intensive computations or used by a large number of people. Most code is not written for these cases.
Most code is written for very local purposes, doing fairly simple and focused things, often for one-off purposes. It is illogical to use a programing language that is slow to write code in and takes longer to compile. This is not just true today. These were successful (and rational/logical) arguments offered 2-3 decades ago when CPU time was at a much higher premium and interpreters were much less optimized.
You should measure the total performance (programmer and code) and costs, not just CPU time.
> I'm going to go out on a limb here and say that there isn't *anyone* who wouldn't benefit from faster performance.
Matlab and R are most commonly used by computer scientists and statisticians. Both are worse than Python by runtime performance. These are not unintelligent people. Their time is as valuable as anybody else's. So why do these people use them? Because their time is valuable.
Often time the runtime difference between C++ and Matlab/Python/R is 0.01 sec vs. 0.5 sec. It might matter if the difference is 1 hr and 500 hrs, same ratio, but at such small time scales, the human latency barely even takes notice.
> Mind you, there are features worth trading CPU time for, but they have to be justified and should never be the default case if they lead to performance hits. The simplest, fastest alternative should always be an option.
You have it exactly wrong. Human time is first and foremost important. That is the default case. Humans are extremely hard and expensive to train and cannot be upgraded. They are the bottleneck and need to be most managed. Performance is something you worry about after you produced something correctly. Generally speaking, identifying and optimizing small bottlenecks is much more productive than starting with performance as a key consideration even when you don't need it.
Premature optimization is the root of all evil -- Donald Knuth
The entire point of programming languages is human performance, not computer performance. CPU performance is the job for compilers (you can transliterate a fair subset of Python to C/C++. Eg. ShedSkin). That said, I am enthusiastic for productive AND fast tools - Rust & Nim, in my case, but none of these are Python/Matlab/R replacements yet.
Why do you think performance is the most important consideration for programming language choice?
The idiocy is in believing that everyone's needs are the same.
For the things that are usually done with Python, it would not matter if the interpreter was further 10 times slower.
Tensorflow is a well-known. That is all I meant.
https://simplyml.com/linear-al...
Most probably just use Numpy.
I would like to hear from people who switched from the more mainstream numpy and tensorflow for linear algebra.. to Julia.
What were your experiences? Was the worflow much more productive? What were the other gains?
Windows 10 is snappy, as long as you have an SSD. It is slow, if you run it off a HDD.
Yes, It should not be this way, but I don't think anyone using it off a modern, even budget laptop with a modest SSD, finds it slow. That is the only resource it badly needs.
Yes, "telemetry" that the user is not allowed to disable (or even fully disclosed) is basically spyware. We have more of a case for open source OS today than 10 years ago.
Wikipedia
=======
Variations of LLLT have gone by a variety of alternate names including low-power laser therapy (LPLT), soft laser therapy, low-intensity laser therapy, low-energy laser therapy, cold laser therapy, bio-stimulation laser therapy, photobiomodulation, photo-biotherapy, therapeutic laser, and monochromatic infrared light energy (MIRE) therapy.
Low-level laser therapy (LLLT) is a form of alternative medicine that applies low-level (low-power) lasers or light-emitting diodes (LEDs) to the surface of or in orifices of the body. Whereas high-power lasers are used in laser medicine to cut or destroy tissue, it is claimed that application of low-power lasers relieves pain or stimulates and enhances cell function.
https://www.ncbi.nlm.nih.gov/p...
The effectiveness of low-level laser therapy (LLLT)
Low-level laser therapy versus sham treatment
One study [64] with a low risk of bias, compared low-level laser therapy treatment with sham laser therapy treatment in elderly patients over 60 years. The study provided low quality evidence that LLLT was more effective in pain relief at intermediate follow-up (44.7%) compared with sham LLLT (15.2%).
Low-level laser therapy + exercise versus sham LLLT + exercise
Results on pain and disability at post-treatment were reported by one study [62] and no difference was found between the intervention groups on both outcome measures.
Two studies [62, 63] reported on pain intensity and disability at short-term (3 months) follow-up. The pooled analysis of these two small trials (n = 61) showed a significant difference in pain relief (WMD 13.57 [95%CI 26.67; 0.47]). No difference was found on disability between those who received LLLT plus exercise and those who received sham LLLT + exercise (WMD 5.42 [95%CI 23.55; 12.71].
Very low quality evidence was provided (serious limitations, inconsistency, and imprecision) for the effectiveness of LLLT + exercise compared to sham LLLT + exercise on pain intensity at short-term follow-up, but not for disability.
Low-Level laser therapy versus exercise
One study [27] compared the effectiveness of LLLT with exercise therapy post-treatment. No statistically significant difference was found between both therapy groups on pain level and disability.
This looks exactly like quackery. You perhaps tried it and subsequently psychologically bought into it. That is also typical with these alternative stuff.
Just did. Looks like quackery - usual inflated claims using some minor positive studies.
> tablet with touchscreen
It is more like a phablet (minus the phone stuff) with a controller.
GPD is a very niche product, not anywhere in the same space as the Surface Go.
Go was reviewed to have a good keyboard, for the form factor. I would not do any serious typing or reading with the GPD.
Why are you comparing with laptops that are in an entirely different class? These laptops weigh 3 times more and have 1/2 the battery life.
I have one of these laptops. I don't intend to lug mine around very much. The power brick is heavy and I don't trust it to last my day on battery alone. If I was in the market for a Surface Go, it would be because I need a simple, ergonomic machine that I can carry with me all the time.
If you think this is overpriced, by all means, compare with other 10" Windows devices with high-density screens, touch and pens.
My next job might need me to move around between meetings, read a lot more email, annotate PDFs and does not need me to write any code or at least process any data locally. Surface Go should work well for that. Right now, I have a GPU laptop for deep learning, 3D visualization and some gaming. These are completely different needs.
He has back problems and won't fly - "I sat down in 2005".
This is the deep learning industry growing around his lab.
https://www.nytimes.com/2017/0...
A.) I mentioned my use case - research analytics. I am the only user for most of the code I write. My results have users, not the code.
B.) If your users are not tech-savvy, you distribute the binaries, not the code, just as with any other language. There are plenty of tools to do that.