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

201–210 of 228 posts

Re: JuliaLang: The Ingredients for a Composable Programming Language

#201

Post by slavapestov »

socialdemocrat wrote: post #174
byt143 wrote: post #161

Earlier quoted context omitted.

Perhaps this helps? https://github.com/apple/swift-evolution/blob/master/proposa... and this https://twitter.com/jckarter/status/1202260205074968578

Must confess I am a bit too tired to parse that text effectively at the moment, but I don't think that is a solution. It is basically a solution to deal with generics across libraries. In C++ this is a big problem right. Templates cannot really be put in libraries. You put them in header files. So if you put generics in a library and link it, how are you going to know what to specialize and what not to specialize? Th…

You're right that in general an AOT compiler cannot solve this problem. Swift does specialize generic functions within a module. Across module boundaries, you can declare a function with the `@inlinable` attribute, which makes its body available as part of the module's binary interface. Of course this hinders future evolution of the function -- you can swap in a more efficient implementation of an algorithm for instance, but you have to contend with existing binaries that compiled an older version of the function.

The standard library makes extensive use of `@inlinable` for algorithms on generic collection protocols and so on.

Re: JuliaLang: The Ingredients for a Composable Programming Language

#202

Post by newen »

Iwan-Zotow wrote: post #184
JustFinishedBSG wrote: post #173

Earlier quoted context omitted.

You're inventing problems that don't exist. Every thing you said is applicable exactly with 1, 2 or whatever based indexing. It literally doesn't matter. Julia's sequences/arrays are monoids too, I don't see what it has to do with anything.

> Every thing you said is applicable exactly with 1, 2 or whatever based indexing. read my statement again, it is about open vs closed interval. Python ranges/sequences are composable, Julia ones are not. > Julia's sequences/arrays are monoids too really? suppose you compute sum, and got two results: S(1, M) and S(M, N) Could you compose them in Julia?

You compute S(1, M-1) and S(M, N) instead and compose them. That's it. This is not complicated stuff.

Re: JuliaLang: The Ingredients for a Composable Programming Language

#203

Post by ViralBShah »

yahyaheee wrote: post #198

There are parts of Julia I really like but it has some problems. * Multiple dispatch is an odd design pattern that seems to over complicate things. I know there are people that love it and claim it’s better, but after working with it for some time I just want a struct with methods. It’s much easier to reason about. * The packaging is cumbersome. I understand their reasoning behind it but in practice it’s just more of…

While I don't agree with many of these points, I do agree that some of these can be substantially improved. We continue to work hard at it. Some are research problems, while others need elbow grease.

Just to present the other side, here's a recent thread on Julia discourse about why people love Julia. Many chiming in there are recent users of Julia and I think it is insightful.

https://discourse.julialang.org/t/in-as-few-lines-as-possibl...

One that I particularly enjoyed reading about:

https://discourse.julialang.org/t/in-as-few-lines-as-possibl...

Re: JuliaLang: The Ingredients for a Composable Programming Language

#204

Post by byt143 »

slavapestov wrote: post #201
socialdemocrat wrote: post #174

Earlier quoted context omitted.

Must confess I am a bit too tired to parse that text effectively at the moment, but I don't think that is a solution. It is basically a solution to deal with generics across libraries. In C++ this is a big problem right. Templates cannot really be put in libraries. You put them in header files. So if you put generics in a library and link it, how are you going to know what to specialize and what not to specialize? Th…

You're right that in general an AOT compiler cannot solve this problem. Swift does specialize generic functions within a module. Across module boundaries, you can declare a function with the `@inlinable` attribute, which makes its body available as part of the module's binary interface. Of course this hinders future evolution of the function -- you can swap in a more efficient implementation of an algorithm for insta…

Why can't you just have the higher level representation of the code available and just recompile everything?

Re: JuliaLang: The Ingredients for a Composable Programming Language

#205

Post by oivey »

tgflynn wrote: post #116
cultus wrote: post #96

Earlier quoted context omitted.

Single-dispatch OOP dispatches (implicitly) only on the first argument, self. That is how Class B can provide the functionality of A. Multiple dispatch can dispatch on all arguments. Thus, OOP single dispatch is a special case of multiple dispatch. In your example, functionality in class B can be written simply as ordinary generic functions, which are inferred to their most general compatible type without annotations…

Yes, but in Julia the problem is that inheritance isn't allowed from concrete types. So this example in Julia would mean that A is an abstract type whose objects can contain no data. So you have to figure out a way to implement functionality on A without having any data to work with. There are several ways to work around this but they all involve considerably more code complexity than would be required in a language…

It’s maybe less of a problem than you think. If you simply want to call a method on two different types you can often just do it. Type annotations generally don’t help with performance, and any type checking is only going to happen at run time anyway.

Inheritance does help with documenting what functions are compatible with what types. I think that could be better in Julia, and things like abstract type hierarchies and traits help a bit. Concrete inheritance could be nice, but that seems to also enable some pretty bad OOP practices.

Re: JuliaLang: The Ingredients for a Composable Programming Language

#206

Post by slavapestov »

byt143 wrote: post #204
slavapestov wrote: post #201

Earlier quoted context omitted.

You're right that in general an AOT compiler cannot solve this problem. Swift does specialize generic functions within a module. Across module boundaries, you can declare a function with the `@inlinable` attribute, which makes its body available as part of the module's binary interface. Of course this hinders future evolution of the function -- you can swap in a more efficient implementation of an algorithm for insta…

Why can't you just have the higher level representation of the code available and just recompile everything?

Basically, because Swift has to support separate compilation of shared libraries.

The @inlinable attribute is in fact implemented by serializing the high-level IR of a function as part of the module's interface; but doing this for all functions would be a non-starter, because it would place unacceptable restrictions on binary framework evolution.

You can think of @inlinable as being somewhat similar to defining a function in a C header file. Unlike C++ templates, Swift generics don't require all definitions to be available at compile time, because dictionary passing is used to compile generic code when monomorphization cannot be performed.

Re: JuliaLang: The Ingredients for a Composable Programming Language

#207

Post by yahyaheee »

ViralBShah wrote: post #203
yahyaheee wrote: post #198

There are parts of Julia I really like but it has some problems. * Multiple dispatch is an odd design pattern that seems to over complicate things. I know there are people that love it and claim it’s better, but after working with it for some time I just want a struct with methods. It’s much easier to reason about. * The packaging is cumbersome. I understand their reasoning behind it but in practice it’s just more of…

While I don't agree with many of these points, I do agree that some of these can be substantially improved. We continue to work hard at it. Some are research problems, while others need elbow grease. Just to present the other side, here's a recent thread on Julia discourse about why people love Julia. Many chiming in there are recent users of Julia and I think it is insightful. https://discourse.julialang.org/t/in-as…

Yea I really wanted to like Julia overall and many of the parts I like about it are on this thread. I think it's apparent we need a better numeric language than python, I just wish Julia would focus a bit more on utility.

Re: JuliaLang: The Ingredients for a Composable Programming Language

#208

Post by tomkwong »

ablekh wrote: post #185

Interesting post and excellent discussion. I have the following question to all Julia and/or Python experts here. What strategy for developing a cloud-native {science and engineering}-focused platform would be better, in your opinion, and why: A) develop an MVP and then relevant production platform in Python, spending some saved time and efforts (due to simplicity, [as of now] better tooling and much wider pool of ex…

I would avoid the two language problem so option B is out of the way. If you choose option A, then you run into a risk of having to optimize some part of the code in C/C++. So you end up with the two language problem again. If you care about performance, then option C is not a bad place to be. Learning Julia is not a big deal. It would not take a seasoned developer too much time to get up to speed with it. What I found is that the Julia community is so vibrant that you can get a lot of help to move along quickly. My two cents.

Re: JuliaLang: The Ingredients for a Composable Programming Language

#209

Post by ablekh »

tomkwong wrote: post #208
ablekh wrote: post #185

Interesting post and excellent discussion. I have the following question to all Julia and/or Python experts here. What strategy for developing a cloud-native {science and engineering}-focused platform would be better, in your opinion, and why: A) develop an MVP and then relevant production platform in Python, spending some saved time and efforts (due to simplicity, [as of now] better tooling and much wider pool of ex…

I would avoid the two language problem so option B is out of the way. If you choose option A, then you run into a risk of having to optimize some part of the code in C/C++. So you end up with the two language problem again. If you care about performance, then option C is not a bad place to be. Learning Julia is not a big deal. It would not take a seasoned developer too much time to get up to speed with it. What I fou…

Thank you for sharing your helpful insights. I will continue learning Julia as well as exploring and comparing options (in addition to Python and Julia, I'm also considering Node.js and C#, though to a lesser degree). I have certainly noticed the vibrancy of the Julia community, however, to me, as a startup founder, the problem of talent availability still represents a significant issue - community help can get us only so far. Most Julia developers are academia/science-affiliated, with a smaller number of people employed in the industry, mostly in sectors like finance and energy - so, a very limited talent pool makes it quite challenging to build a very good engineering team, at least, in the near term).

Re: JuliaLang: The Ingredients for a Composable Programming Language

#210

Post by pdexter »

StefanKarpinski wrote: post #147

I think the top-level take away here is not that Julia is a great language (although it is) and that they should use it for all the things (although that's not the worst idea), but that its design has hit on something that has made a major step forwards in terms of our ability to achieve code reuse. It is actually the case in Julia that you can take generic algorithms that were written by one person and custom types…

Interesting. Can you give an example of generic algorithms plus custom types, in practice? Off the top of my head I thought that any dynamic language or static language with good genetics would have this property, but maybe there's something that Julia does differently.
Post reply on HN