JuliaLang: The Ingredients for a Composable Programming Language • Hacker News Board

Re: JuliaLang: The Ingredients for a Composable Programming Language

#81

Post by harikb » Mon, Feb 10, 2020, 5:40 PM UTC

mumblemumble wrote: post #51

cultus wrote: post #25

Earlier quoted context omitted.

People write large-scale systems in dynamically-typed languages all the time. Multiple dispatch and macros make clean scaling easier than it would be in most other dynamic languages. Its competitors in numerical performance are C/C++ and Fortran, which are both minefields (C much more so). Julia is definitely safer in practice than these kind of languages with weak, unsafe type systems. I'm not saying static types do…

> I'm not saying static types don't have benefits as well, It's funny; formerly I was a die-hard fan of static typing, but, lately, my opinions have become more nuanced. Something more along the lines of, "Yeah, I'd never want to just remove the type annotations from my Java code and then try to maintain the result, but some dynamic languages allow me to have a fraction as much code to maintain in the first place." I…

Java's code verbose-ness is not entirely due to static typing though. IMHO, it is ecosystem, people, SO-copy-culture

Re: JuliaLang: The Ingredients for a Composable Programming Language

#82

Post by totalperspectiv » Mon, Feb 10, 2020, 5:41 PM UTC

xvilka wrote: post #2

I hope Julia will be more popular in bioinformatics. Personally, I have a high hopes for BioJulia[1][2][3] and the amazing AI framework FluxML[4][5] + Turing.jl[6][7]. Apart from the speed, they offer some interesting concepts too - I recommend to check them out. [1] https://biojulia.net/ [2] https://github.com/BioJulia [3] https://github.com/BioJulia [4] https://fluxml.ai/ [5] https://github.com/FluxML/ [6] https://…

I've always found Julia a little lacking for bioinformatics, but I'm not doing ML. I have very high hopes for Nim, which I think has better performance potential than Julia across domains and can produce binaries.

Re: JuliaLang: The Ingredients for a Composable Programming Language

#83

Post by gugagore » Mon, Feb 10, 2020, 5:41 PM UTC

dcolkitt wrote: post #66

FranzFerdiNaN wrote: post #15

Earlier quoted context omitted.

Python will still be used 20 years from now. The clear advantage of Python is the enormous ecosystem that is available, the millions of questions on SO giving solutions to every problem you can run into, the books and learning materials etc, programmers and corporations having invested loads of time and effort in building, maintaining and battle-testing libraries. Don't get me wrong, i think Julia is an amazing langu…

> R shows how you can succeed just fine with a kinda weird language. One thing that most people don't appreciate about R is the subtle influence from lisp world. This makes it really feel like the language is optimized for data science down to the most basic syntax level.

I'd love an example of the subtle influence. In any case, the influence of lisp on julia is pretty obvious if you're familiar with lisp, I believe.

Re: JuliaLang: The Ingredients for a Composable Programming Language

#84

Post by masklinn » Mon, Feb 10, 2020, 5:43 PM UTC

mumblemumble wrote: post #51

cultus wrote: post #25

Earlier quoted context omitted.

People write large-scale systems in dynamically-typed languages all the time. Multiple dispatch and macros make clean scaling easier than it would be in most other dynamic languages. Its competitors in numerical performance are C/C++ and Fortran, which are both minefields (C much more so). Julia is definitely safer in practice than these kind of languages with weak, unsafe type systems. I'm not saying static types do…

> I'm not saying static types don't have benefits as well, It's funny; formerly I was a die-hard fan of static typing, but, lately, my opinions have become more nuanced. Something more along the lines of, "Yeah, I'd never want to just remove the type annotations from my Java code and then try to maintain the result, but some dynamic languages allow me to have a fraction as much code to maintain in the first place." I…

> It's funny; formerly I was a die-hard fan of static typing, but, lately, my opinions have become more nuanced. Something more along the lines of, "Yeah, I'd never want to just remove the type annotations from my Java code

That might be one of the issues. Even when it comes to static typing java is high investment low rewards.

Things are admittedly less bad than they were 15 years ago, but it remains that java has very high overhead both syntactically and at runtime and yet is pretty limited in its static expressivity. So when you do away with java for a dynamically typed langage most of what you lost from missing static types you gain back from having so much less LOCs and ceremony and architectural astronautics to deal with.

In theory you could probably write terser java but that’s not what the community does or what the ecosystem encourage, so if you do you’re on your own and then why keep using java? There’s plenty of better langages with no community and no ecosystem out there. And they have way, way better type systems.

Re: JuliaLang: The Ingredients for a Composable Programming Language

#85

Post by UncleOxidant » Mon, Feb 10, 2020, 5:46 PM UTC

nwvg_7257 wrote: post #78

UncleOxidant wrote: post #60

I really like Julia a lot and actually used it in a work project a few years back. However, there's the debugger issue. There are several debugger alternatives. It's tough to figure out which debugger is canonical (or is any of them the canonical debugger?). The one that seems to being used most at this point is Debugger.jl. However, it's exceedingly slow if you're debugging sizeable operations (matrix multiplies, fo…

Couple comments on the Debugger situation: 1. Debugger.jl is A LOT smoother if you run it in compiled mode, which is a checkbox in the Juno interface. I've found that stepping to next line is instant in compiled mode, but takes forever without it. 2. Infiltrator.jl is great at what it's designed for, which is to dump you in a REPL deep within a call stack and let you see what's going on. But, Debugger in compiled mod…

> 1. Debugger.jl is A LOT smoother if you run it in compiled mode, which is a checkbox in the Juno interface. I've found that stepping to next line is instant in compiled mode, but takes forever without it.

Is there a way to do this if I'm not running Juno? I'd guess there must be some parameter that can be passed to @enter or @run?

Re: JuliaLang: The Ingredients for a Composable Programming Language

#86

Post by CreRecombinase » Mon, Feb 10, 2020, 5:47 PM UTC

xvilka wrote: post #2

I hope Julia will be more popular in bioinformatics. Personally, I have a high hopes for BioJulia[1][2][3] and the amazing AI framework FluxML[4][5] + Turing.jl[6][7]. Apart from the speed, they offer some interesting concepts too - I recommend to check them out. [1] https://biojulia.net/ [2] https://github.com/BioJulia [3] https://github.com/BioJulia [4] https://fluxml.ai/ [5] https://github.com/FluxML/ [6] https://…

How much of the BioJulia stuff would you say currently works? It looks like a lot of repos have been created, and the scope is pretty impressive (looks like there are repos for everything from structural bioinformatics to population genetics), but a lot of them look to be basically empty(https://github.com/BioJulia/PopGen.jl), or have really scary looking issues:(e.g https://github.com/BioJulia/GeneticVariation.jl/issues/25).

Re: JuliaLang: The Ingredients for a Composable Programming Language

#87

Post by vanderZwan » Mon, Feb 10, 2020, 5:48 PM UTC

smabie wrote: post #10

Julia is great. It’s significantly simpler than Python while also being much more expressive. It’s too bad the typing is only for dispatch, but hopefully someone will write a typechecker someday. I’ve found it surprisingly refreshing to not have to think about classes and just add functions on objects wherever I want. Some languages solve this with monkey patching (which is bad), others like Scala with an extension c…

> It’s too bad the typing is only for dispatch, but hopefully someone will write a typechecker someday

I was under the impression that if you write a function that takes very specific sub-types as its parameters, and then try to call it with invalid parameters (that is, values that cannot be converted to the right type via the promotion rules) that Julia will complain about this?

Re: JuliaLang: The Ingredients for a Composable Programming Language

#88

Post by gugagore » Mon, Feb 10, 2020, 5:53 PM UTC

earenndil wrote: post #69

awb wrote: post #57

Earlier quoted context omitted.

> Python will still be used 20 years from now So much technology has come and gone since 2000. If innovation continues to accelerate I'd be hesitant to predict what 2040 will look like. Programming might become so simple and automated that we won't need StackOverflow to the extent we do today. It's really hard to predict the next year or two let alone the next 20.

> If innovation continues to accelerate It won't; that is a naive view. Innovation can't keep accelerating forever, and I would be surprised if it even keeps up its current pace; far likelier it's a sigmoid curve - https://en.wikipedia.org/wiki/Sigmoid_function

I don't know if you're talking about like the heat death of the universe, and so like nothing is "forever", but I don't see signs of programming language innovation slowing down at all.

Re: JuliaLang: The Ingredients for a Composable Programming Language

#89

Post by goatlover » Mon, Feb 10, 2020, 5:55 PM UTC

awb wrote: post #76

goatlover wrote: post #71

Earlier quoted context omitted.

Programming languages from 2000 remain, though. C, C++, Java, JS, Python, etc. Even Fortran, Cobol and Lisp remain in use. There’s been attempts since the 80s to popularize visual and and higher level approaches to programming, but the traditional languages still dominate. And the newer ones like Go, Elixir and Julia are like the traditional C, Lisp and Fortrans.

Sure, some do, but past adoption is not a guarantee of future adoption. 20 years in the future is a long time. Just look at Flash. Who knows, maybe a Quantum OS will dominate that doesn't support Python. So yes, if someone will still be using Python in 20 years, I'm sure you're right. But Python just as easily could be relegated to a niche domain while other languages take over a broader range of applications. Especi…

I'm more responding to the idea that programming might become simple and automated, and we can't even predict technological changes a year or two out. You're right that Python could be relegated to a niche language in 20 years. That does happen.

What hasn't happened is a fundamental change to programming languages since the 1960s, despite the incredible increase in computing power, ubiquity of computers and much better tooling and environments for programming languages. There's no evidence that this is going to change anytime soon. All the popular new languages are similar to the popular older languages. If people don't want to program in JS, they transpile from Typescript. Even web assembly is a means to use a language like Rust on the web.

There's no simple, automated PL on the horizon that is going to replace JS, Java, Python, etc. There isn't one for spreadsheets, either, which is a technology from the 80s.

Re: JuliaLang: The Ingredients for a Composable Programming Language

#90

Post by ChrisRackauckas » Mon, Feb 10, 2020, 5:56 PM UTC

dzonga wrote: post #67

eigenspace wrote: post #26

Earlier quoted context omitted.

As others have mentioned, Python does have JIT compilers. The problem is that havign a JIT doesn't solve the problem. PyPy is often a factor of 10 behind julia performance and projects like Numba, PyTorch (the PyTorch people had to build their own Python JIT compiler yikes!), etc. will always have a more restricted scope than a project like Julia because Python's very semantics make many optimizations impossible. Her…

so in this case, once say the Julia ecosystem grows then migrate to Julia. or wait for optimizations to be done, e.g have pandas, numpy etc handle multi-core processors etc ?

There's quite fundamental optimizations that will be missing if separately compiled pieces cannot optimize together. These barriers disallow many things. Additionally, anything that relies on higher order functions provided by the user, such as optimization or differential equations, will run into issues because those functions cannot be optimized by some super good package developer, but instead have to come from the user.

This blog post highlights the massive performance advantages Julia can have when you start integrating optimized packages and allow for optimizing across these barriers in Julia, and also the pros and cons of allowing these kinds of cross-function optimizations.

https://www.stochasticlifestyle.com/why-numba-and-cython-are...