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

JuliaLang: The Ingredients for a Composable Programming Language

white.ucc.asn.au

Post reply on HN
Print view View original

21–30 of 228 posts

Re: JuliaLang: The Ingredients for a Composable Programming Language

#21

Post by socialdemocrat »

byt143 wrote: post #7

Anyone know how this compares to swift and its protocols etc?

I am a big fan of Julia, but Swift is perhaps the only statically typed object-oriented language (apart from Objective-C) which I have found offers some similarity in flexibility to Swift's way of dealing with types.

With the ability in Swift of adding extensions to conforming to a particular protocol to a class, you gain some of the same flexibility in Swift as in Julia.

It means you can take an existing class which was not designed in particular for some kind of abstraction and add conformance to an abstraction (protocol) you later added.

That is kind of what Julia gives you, with the ability to easily add functions dispatching on an existing type.

Say you got a `Polygon` and `Circle` type in Swift and Julia which you want to add serialization to without either one having been designed for it originally. In Swift I would define a `Serializable` protocol with a `serialize` method taking an `IO` object to serialize to. Then I would extend `Polygon` and `Circle` to implement this protocol.

In Julia I would simply add two functions:

   serialize(io::IO, poly::Polygon)
   serialize(io::IO, circle::Circle)
The challenge in Julia is that I might want to define that only objects of type `Shape` can be serialized, but if `Polygon` and `Circle` was not already defined as subtypes of `Shape` I cannot do anything about that without changing source code. Swift has an advantage in his case.

My only alternative in Swift would be to create a Union type of all tye types I want to be serializable.

Re: JuliaLang: The Ingredients for a Composable Programming Language

#23

Post by setr »

dzonga wrote: post #19

though, Julia is faster than Python. Does anyone mind explaining why Python can't have a JIT ?

Pypy exists, but as I recall, cpython never made use of a JIT simply because they wanted to keep the compiler intentionally simpler.

However as a result, the language isn't well designed for a JIT, and pypy has run into several headaches/blockers. Not sure if there's anything fundamentally blocking usage, or simply lack of manpower

Re: JuliaLang: The Ingredients for a Composable Programming Language

#24

Post by oxinabox »

tgflynn wrote: post #17

Julia is a language I really wanted to like, and to a certain extent I do. However after spending some time working with it and hanging out on the Discourse channels (they certainly have a very friendly and open community, which I think is a big plus), I've come to the tentative conclusion that its application domains are going to be more limited than I would have hoped. This article hits on some of the issues that t…

Author of post here: there were a major gripe for me starting out too. It took me a fair while to conclude that they allowed to useful things in the bigger picture. and it certainly is not a pure win.

I do miss static typing.

I would question the claim it doesn't scale to production. I know people who have build hugely complex production systems in perl that are still running today 20 years later.

Further, I myself work on what we believe to be the largest closed source julia code base, in terms of number of contributors, number of packages and total size. (Its also pretty large in general, though i have yet to work out how it stacks up against DiffEq-verse). And I have seen thing go from research prototype into running in production. It works.

I am not going to deny though there are advantages to other languages. There are many trade-offs in the world

Re: JuliaLang: The Ingredients for a Composable Programming Language

#25

Post by cultus »

tgflynn wrote: post #17

Julia is a language I really wanted to like, and to a certain extent I do. However after spending some time working with it and hanging out on the Discourse channels (they certainly have a very friendly and open community, which I think is a big plus), I've come to the tentative conclusion that its application domains are going to be more limited than I would have hoped. This article hits on some of the issues that t…

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 don't have benefits as well, but it would also be very against the design goals as a Matlab/R competitor.

Inheritance would also directly clash and overlap with multiple dispatch, which is strictly more powerful.

Re: JuliaLang: The Ingredients for a Composable Programming Language

#26

Post by eigenspace »

dzonga wrote: post #19

though, Julia is faster than Python. Does anyone mind explaining why Python can't have a JIT ?

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.

Here's a great talk from the author of the famous Flask library in Python: https://www.youtube.com/watch?v=qCGofLIzX6g where he discusses the fundamental problems with Python's semantics.

If you fix these problems, you will end up changing Python so fundamentaly that you'll really have a new language. Generic CPython 3._ code will certainly not be compatible with it.

Re: JuliaLang: The Ingredients for a Composable Programming Language

#27

Post by tgflynn »

cultus wrote: post #25
tgflynn wrote: post #17

Julia is a language I really wanted to like, and to a certain extent I do. However after spending some time working with it and hanging out on the Discourse channels (they certainly have a very friendly and open community, which I think is a big plus), I've come to the tentative conclusion that its application domains are going to be more limited than I would have hoped. This article hits on some of the issues that t…

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…

> multiple dispatch, which is strictly more powerful.

In a language that supports classes I can have class B inherit from class A and automatically provide all of class A's functionality without adding a single extra line of code. I can extend class B's functionality by adding only code that is specific to it.

I don't see how to do that with multiple dispatch, at least the way it's implemented in Julia.

Re: JuliaLang: The Ingredients for a Composable Programming Language

#28

Post by socialdemocrat »

Iwan-Zotow wrote: post #12

Composable? Julia and composable?!? They decided on sequence range [1...N], instead of [0...N) like Python. Try to compose that.

Depends on what you work on. When doing more computer science like stuff, such as computing memory offsets etc, then 0-based indexing is practical. But for numerical work 1-based indexing is usually easier to work with. Mathematical texts are already using 1-based indexing and hence that is what people are used to when thinking about math.

I work with both and I never found this a big problem. This is on par with complaining about whitespace in Python. I prefer languages to not be whitespace sensitive but it is not a big problem.

Although I pretty sure you will accidentally get more problem from Python whitespace usage than from Julia 1-based indexing.

And frankly since Julia can use any indexing, you can use A[begin:end] to refer to the whole range of an object. If you want the second item in any array you can just write A[begin+1].

Re: JuliaLang: The Ingredients for a Composable Programming Language

#29

Post by ScottPJones »

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…

I've been using Julia for non-scientific computing programs for almost 5 years now, and (especially now that it is stable since the 1.0 release) have found it well suited for general programming as well. Having a language that is easy to write (like Python), runs fast (like C/C++), and incredibly flexible & expressive (like Lisp) makes programming fun again!

Re: JuliaLang: The Ingredients for a Composable Programming Language

#30

Post by smabie »

sgt101 wrote: post #13
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…

could you expand on the "too bad typing is only for dispatch"? I've enjoyed the way that the Julia type system can be used...

It can’t be used for compile time correctness checking? i.e Julia isn’t a statically typed language.
Post reply on HN