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

41–50 of 228 posts

Re: JuliaLang: The Ingredients for a Composable Programming Language

#41

Post by klyrs »

tgflynn wrote: post #32
oxinabox wrote: post #24

Earlier quoted context omitted.

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 w…

> I know people who have build hugely complex production systems in perl that are still running today 20 years later. Sure, but there aren't many programmers who would want to maintain such a system.

Perl's just another language I've known. Maintaining a 20yo codebase in a language that people find distasteful sounds like comfortable job security, to me.

Re: JuliaLang: The Ingredients for a Composable Programming Language

#42

Post by ScottPJones »

real_eng_ wrote: post #33
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…

Why every Julia user can't help but trash Python at every occasion? It's getting really tiring

I haven't seen that at all - many Julia programmers are (or were) also Python programmers. I think there is a lot of respect in the Julia community for Python & the Python ecosystem. There have even been a number of Julia talks at various PyCons over the past few years.

Re: JuliaLang: The Ingredients for a Composable Programming Language

#43

Post by socialdemocrat »

byt143 wrote: post #20
eigenspace wrote: post #11

Earlier quoted context omitted.

Julian interfaces are less formal than swift protocols. We use sub-typing and/or traits together with multiple dispatch to define generic pluggable interfaces. There’s a lot of discussion around making a more formal protocol-like system but so far what we have works surprisingly well, so we’re not in a huge hurry to implement something and want to slowly explore the design space.

Sure, but I'm more looking for something from the swift side of whether Swift can do the same sort of composable generic programming.

To some degree it can, but there are a number of problems with using Swift for this:

(1) Swift does not support multiple dispatch. That limits the way you can glue together unrelated libraries.

(2) Swift does not use abstract type hierarchies very much. E.g. in Julia one frequently define functions to use arguments of type Number, AbstractArray, AbstractString etc. This means it is easy for somebody in the future and define an array that works on a GPU or which is statically allocated and all existing functions operating on arrays work just fine.

I can invent a whole new number type and make it a subtype of Number and all my existing algorithms operating on numbers work just fine. One example of this would be Dual Numbers, which allow automatic differentiation. This was fairly easy to accomplish in Julia, but has been a major undertaking on Swift, which I don't think is done yet. I think they actually have to change the whole compiler. For Julia this is just a library thing.

(3) Swift function and method syntax is a pain to work with. For purely object oriented code it is very nice to read with parameter names. But once you get into functional programming and composition I find that it just creates a mess. I have to fiddle way too much with my Swift code to get function composition working as I desire. With Julia it is straightforward.

I would say composition is easier when everything is just based on the same function syntax.

Re: JuliaLang: The Ingredients for a Composable Programming Language

#44

Post by vasili111 »

mark_l_watson wrote: post #16
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 have a collection of short Julia code snippets that do non numeric things like text processing, semantic web clients, etc. But in general I agree. Fir me, Lisp languages, Haskell, and Python are more general purpose.

>Fir me, Lisp languages, Haskell, and Python are more general purpose.

You mean Julia as language is not enough good for general purpose or it lacks ecosystem (frameworks, libraries) for general purpose use?

Re: JuliaLang: The Ingredients for a Composable Programming Language

#45

Post by mumblemumble »

FranzFerdiNaN wrote: post #15
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…

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…

I would be careful treating this too much like a popularity contest. Python will still be used 20 years from now, but that doesn't necessarily mean that it's going to be dominant 20 years from now.

Source: I used to do a lot of programming in various dialects of Basic, which, a bit over 20 years ago, was popular largely because of its own ubiquity and popularity. And, while I still maintain some Basic code, I was surprised how quickly it died. One day everything was being written in it. The next day, we were were writing new things in a fancy new language that everyone agreed was more productive, and talking to the existing stuff through an FFI. And, a day later, we were replacing modules in order to get them off of the "legacy" platform.

Re: JuliaLang: The Ingredients for a Composable Programming Language

#46

Post by byt143 »

tgflynn wrote: post #27
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…

> 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.

This can be done better with traits in Julia, which are more powerful, safer and faster.

See here: https://white.ucc.asn.au/2018/10/03/Dispatch,-Traits-and-Met...

Re: JuliaLang: The Ingredients for a Composable Programming Language

#47

Post by skybrian »

ScottPJones wrote: post #29
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!

Interesting, how does deployment work for you? What sort of executables do you ship?

Re: JuliaLang: The Ingredients for a Composable Programming Language

#48

Post by byt143 »

socialdemocrat wrote: post #43
byt143 wrote: post #20

Earlier quoted context omitted.

Sure, but I'm more looking for something from the swift side of whether Swift can do the same sort of composable generic programming.

To some degree it can, but there are a number of problems with using Swift for this: (1) Swift does not support multiple dispatch. That limits the way you can glue together unrelated libraries. (2) Swift does not use abstract type hierarchies very much. E.g. in Julia one frequently define functions to use arguments of type Number, AbstractArray, AbstractString etc. This means it is easy for somebody in the future and…

That makes sense. Swift is also way too complex and syntatically noisy imo. I like that Julia has a smaller set of very powerful abstractions.

Though isn't point (2) just a convention thing? Protocols can refine other protocols. So in S4TF there's a layer protocol and an RNN protocol which extends that, IIRC.

Re: JuliaLang: The Ingredients for a Composable Programming Language

#49

Post by cosmojg »

cmcaine wrote: post #8
classified wrote: post #3

Is it possible yet to compile ahead-of-time to a stand-alone binary executable?

The other replies are slightly out of date and imprecise. PackageCompilerX replaced PackageCompiler (and there's a PR open that will pull all the X work in soon). The binaries produced bundle the whole Julia sysimage by default and they're quite big, but they are quite fast! A more traditional static compilation approach is being tried with StaticCompiler.jl by tshort, but it's in early development.

> A more traditional static compilation approach is being tried with StaticCompiler.jl by tshort, but it's in early development.

The moment this ships, there will no longer be any reason to use any other garbage-collected language.

Re: JuliaLang: The Ingredients for a Composable Programming Language

#50

Post by tgflynn »

logicchains wrote: post #39
tgflynn wrote: post #27

Earlier quoted context omitted.

> 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.

>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. And people will abuse this to create horrible brittle inheritance hierachies. There's a reason modern languages like Go and Rust deliberately don't support implementation inheritance; to many people it's an antifeature.

The thing about software is that the "one true way" changes every 2 or 3 years.

A few decades ago inheritance was considered a key software design principle, then it was abused by many (especially Java programmers, I think), just like any other powerful feature, now it's considered evil. If multiple dispatch becomes as popular as classes/inheritance was, I suspect it will go through the same love/hate cycle.

All I know is that I have used implementation inheritance to good effect on multiple occasions and found it to be a very valuable feature.

Post reply on HN