Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

How an MIT research project became the Julia programming language

news.mit.edu

Post reply on HN
Print view View original

41–50 of 142 posts

Re: How an MIT research project became the Julia programming language

#41

Post by Someone »

Joel_Mckay wrote: post #23
hn_submit wrote: post #18

Safe for BASIC I believe it's very difficult to make a programming language which is easy-to-learn like the creators of Julia proclaim. It may be somewhat easier to implement specific scientific functionality in the language but does that warrant the creation of yet another language? Scanning the language it doesn't strike me at all as "simple."

Julia abstracts entire programming paradigms in single characters. https://juliahep.github.io/Hands-on-Julia-for-particle-physi... BASIC "made simple things easy, and hard things impossible..." Julia is the first language I've seen in years that implicitly abstracts parallelism cleanly. =3

> Julia is the first language I've seen in years that implicitly abstracts parallelism cleanly.

What do you mean by “implicitly”? A single dot is short but not implicit.

I also do not see https://docs.julialang.org/en/v1/manual/parallel-computing/ s mention that such map calls (can) run on multiple threads.

Re: How an MIT research project became the Julia programming language

#42

Post by [deleted] »

muragekibicho wrote: post #4

Julia uses 1-based indexing. It's competes with R and Matlab for the same set of users. Both R and Julia have their core functions written in C++. Absolutely nothing new. From my experience, grad students use Julia when their PI thinks a new programming language will help differentiate their next NSF proposal among vast funding requests.

[deleted]

Re: How an MIT research project became the Julia programming language

#43

Post by ModernMech »

jhbadger wrote: post #32
jhoechtl wrote: post #21

Earlier quoted context omitted.

> Julia uses 1-based indexing. That rules it out to become a successor to Python. It sounds reasonable until you start interacting with other libraries. I do know the attemp to justify it for Lua and I don't buy it.

Nearly all languages designed for mathematics are 1-based - R, Matlab, Mathematica, etc. because that's the mathematical convention and allows using formulas directly. The fact that Python isn't is a drawback in the domain.

Nearly all languages for non coders are this way including Excel and SQL and Scratch.

Re: How an MIT research project became the Julia programming language

#44

Post by ModernMech »

jhoechtl wrote: post #21
muragekibicho wrote: post #4

Julia uses 1-based indexing. It's competes with R and Matlab for the same set of users. Both R and Julia have their core functions written in C++. Absolutely nothing new. From my experience, grad students use Julia when their PI thinks a new programming language will help differentiate their next NSF proposal among vast funding requests.

> Julia uses 1-based indexing. That rules it out to become a successor to Python. It sounds reasonable until you start interacting with other libraries. I do know the attemp to justify it for Lua and I don't buy it.

This is why AI is better at writing code than humans. They just write code and don’t complain about things that don’t matter, like indexing; or another classic, spaces vs tabs. Humans must learn to get past these things.

Re: How an MIT research project became the Julia programming language

#45

Post by ModernMech »

Joel_Mckay wrote: post #23
hn_submit wrote: post #18

Safe for BASIC I believe it's very difficult to make a programming language which is easy-to-learn like the creators of Julia proclaim. It may be somewhat easier to implement specific scientific functionality in the language but does that warrant the creation of yet another language? Scanning the language it doesn't strike me at all as "simple."

Julia abstracts entire programming paradigms in single characters. https://juliahep.github.io/Hands-on-Julia-for-particle-physi... BASIC "made simple things easy, and hard things impossible..." Julia is the first language I've seen in years that implicitly abstracts parallelism cleanly. =3

Yes that was the basic trick they learned from Matlab, said to be a billion dollar company built off a single operator: \

Which, for anyone who doesn’t know Matlab, is the solve operator; it calls out to a big algorithm that chooses an appropriate solver given the operands, reducing large programs down to a single line.

Re: How an MIT research project became the Julia programming language

#46

Post by Joel_Mckay »

Someone wrote: post #41
Joel_Mckay wrote: post #23

Earlier quoted context omitted.

Julia abstracts entire programming paradigms in single characters. https://juliahep.github.io/Hands-on-Julia-for-particle-physi... BASIC "made simple things easy, and hard things impossible..." Julia is the first language I've seen in years that implicitly abstracts parallelism cleanly. =3

> Julia is the first language I've seen in years that implicitly abstracts parallelism cleanly. What do you mean by “implicitly”? A single dot is short but not implicit. I also do not see https://docs.julialang.org/en/v1/manual/parallel-computing/ s mention that such map calls (can) run on multiple threads.

The abstraction does not require a lot of understanding/bodges to get performant code by amateurs:

https://cuda.juliagpu.org/stable/tutorials/introduction/

But I agree the shared memory Distributed Computing part of Julia still needs a lot of work. Spawning binary image instances over ssh is too fragile. =3

Re: How an MIT research project became the Julia programming language

#47

Post by Joel_Mckay »

ModernMech wrote: post #45
Joel_Mckay wrote: post #23

Earlier quoted context omitted.

Julia abstracts entire programming paradigms in single characters. https://juliahep.github.io/Hands-on-Julia-for-particle-physi... BASIC "made simple things easy, and hard things impossible..." Julia is the first language I've seen in years that implicitly abstracts parallelism cleanly. =3

Yes that was the basic trick they learned from Matlab, said to be a billion dollar company built off a single operator: \ Which, for anyone who doesn’t know Matlab, is the solve operator; it calls out to a big algorithm that chooses an appropriate solver given the operands, reducing large programs down to a single line.

Matlab was better than Octave in many ways, till folks get the sticker-price shock for $3k/host in a commercial cluster. ymmv

I still like Julia more, as it is fun. =3

Re: How an MIT research project became the Julia programming language

#48

Post by bee_rider »

drhagen wrote: post #37

When I was a grad student at MIT, my desk was across the hall from the Julia people. We even shared a lunch table. Julia is most famous for its optimizing compiler, but many people may not notice the careful work that went into designing the language itself. Matlab this was not! I remember one long conversation where one of them was teaching me about the different types of normalization of unicode. They had to pick o…

I don’t know if experience has just damaged my brain or what, but I really like matlab’s syntax for what it is. Nice for writing 100 line experiments or using in the REPL. Sort of like the Python of linear algebra, haha. It also has a nice feature where you start getting headaches to let you know you’ve tried to extend it past its comfort zone.

Julia seems to sit in this area between Matlab and Fortran where I can’t ever find a reason to learn it instead of just using one of the other two. But people seem to love it (and the GPGPU support sounds like it is good?) so I should probably just make up a reason.

Re: How an MIT research project became the Julia programming language

#49

Post by eigenspace »

Julia is such a great language, it's what really made me care about end enjoy programming. I think it's the modern language which has taken the most lessons from lisps, and has come up with some great ideas of its own too.

There's lots to like, but I think the thing I love most about it and find it so interesting is that it's almost uniquely good at taking a piece of code and transforming it's meaning in various ways, and has so many tools for doing so. There's

  * Multiple dispatch allowing very flexible writing of generic code, and multiple dispatch isn't some tacked on, opt-in extra. Every function in the language is overloadable, and there's no performance penalty for using multiple dispatch

  * Parametric typing allows for a huge amount of abstraction over common 'base' types

  * Lispy macros let you do metaprogramming that changes the meaning of a piece of syntax

  * Generated functions let you intervene at compile time and lets you essentially take over the compilation pipeline and customize the code generation for any given input type signature

  * The abstract interpreter interface which lets one essentially take over the compiler and customize your code generation and analysis passes to your heart's content. This is used for instance to support GPUs and automatic differentiation as package offerings.

Re: How an MIT research project became the Julia programming language

#50

Post by eigenspace »

radiator wrote: post #30

Do you think the criticism in the article "Why I no longer recommend Julia" about correctness is still valid? * there are too many correctness and composability bugs throughout the ecosystem to justify using it in just about any context where correctness matters * https://yuri.is/not-julia/

Programming languages have bugs. These things happen, and this tired article blows them totally out of proportion.

Some languages are less permissive, and have a culture of searching harder for corner cases and dealing with them than others, that is true. I would expect to find less cases like this in Rust, but more cases like this in Python.

Julia is an extremely flexible and permissive language, which means that generic code needs to be written carefully and contracts between interfaces need to be thought through.

When you combine funky package types like OffsetArrays with functions from a package where the authors didn't think about OffsetArrays, bad things can happen. Those things were then reported and the community has learned a lot about how to deal with those sorts of things.

I'm sure an AI agent can crawl through and find a new big list of weird bugs in julia, but that's true even of a language like Rust.

Post reply on HN