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

151–160 of 228 posts

Re: JuliaLang: The Ingredients for a Composable Programming Language

#151

Post by mumblemumble »

masklinn wrote: post #84
mumblemumble wrote: post #51

Earlier quoted context omitted.

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

> Even when it comes to static typing java is high investment low rewards.

My sense is that it's because Java isn't really all that static a language. In terms of the syntax, sure. But it also relies very heavily on run-time reflection, run-time type casting, and run-time type checking. Since the introduction of generics, there are even some situations where the types are known and declared statically in the source code, but the compiler is unable to do static type verification, and so the type checking only happens dynamically at run time.

Meaning that you kind of get the worst of both worlds: High-ceremony programming, but not a whole lot of help from the compiler in return for it.

Anyway, yeah, that does mean that the debate does get more hair-splitty if we're talking Haskell vs. Racket. But, realistically, that's not usually the languages people have in mind when they're talking static vs dynamic - it's much more likely to be Java or Python. Both of which, like most languages, fall short of being the ideal examples of their respective type checking approaches.

Re: JuliaLang: The Ingredients for a Composable Programming Language

#152

Post by kwertzzz »

int_19h wrote: post #120
baron_harkonnen wrote: post #63

Earlier quoted context omitted.

I remember when Python was a new and exciting language and people said the exact same thing about Perl. "You'll never see Python replace Perl for string processing, Perl has such a huge ecosystem!". At the time Perl was the de facto interpreted/"scripting" language. Sure Perl is around still, but it has become a rather niche language used in a small number of specific communities. I use Python everyday, and still hav…

Python replaced Perl in many niches, because Python was better suited to general tasks. For string processing, it wasn't as convenient, but there were so many other things where it was clearly a better choice. And being able to use a single "good enough" language for everything is itself a major convenience. Julia is the opposite - it's better than Python in one particular narrow niche, and cannot replace it broadly.…

Did you know that Java for instance, was originally designed to run on interactive TVs? But then, Java run on many type of devices and in broad range of use-cases (maybe with the exception of TVs :-)).

The original niche for which a programming language is designed may or may not be indicative for what it is used in the end. Julia strikes a very good balance between performance, flexibility (macros) and ease-of-use (default type inference). I won't be surprised if there are other niches outside of scientific computing where these characteristics are desirable.

The biggest obstacle I see for the adoption of Julia outside of the scientific computing realm are the latencies due to compilation. There are already 3-party solutions for this (like PackageCompiler{X,}.jl) but imho they are not robust yet enough for widespread adoption, but this might be about to change when different effort join forces [1].

[1] https://github.com/JuliaLang/PackageCompiler.jl/pull/304

Re: JuliaLang: The Ingredients for a Composable Programming Language

#153

Post by gugagore »

short_sells_poo wrote: post #138
improbable22 wrote: post #110

Earlier quoted context omitted.

How would you like modules to work? It seems great to me that paths & source files are mostly irrelevant, you're free to re-organise without changing anything. And that `using Xyz` is always talking to the package manager. You can make sub-modules and say `using .Xyz`, but there's very little need to do so, and few packages do. You can shoot yourself in the foot by including source twice, as you can by generating it…

Languages like Python, Rust, C# or even Java have module systems that I find are more restrictive, but much easier to follow. You always have the pertinent information at hand. Each file containing code clearly tells you two crucial pieces of information: 1. Where the code fits in the greater picture 2. Where the dependencies of the code in a file come from Python, whose module story is actually pretty poor, is still…

That was helpful, especially realizing that part of the problem (at least as you see it) is that the "linking" is unidirectional.

Function definitions/calls are also unidirectionally linked. You can see at the call site which function is called, but you can't see at the function definition the references. But unlike a function, which might be called from many places, it really should be the case that a file is `include`d exactly once.

Re: JuliaLang: The Ingredients for a Composable Programming Language

#154

Post by SolarNet »

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.

It's pretty easy, you use an OffsetArray.

Because Julia is composable the shape of the array and the values in it are orthogonal while reaming performant (as discussed by the article). As demonstrated by OffsetArray how one access an array is also orthogonal to those other factors, while remaining performant (it's a zero runtime cost abstraction).

Re: JuliaLang: The Ingredients for a Composable Programming Language

#155

Post by ViralBShah »

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…

This visualization of dependencies among Julia packages in this twitter thread by cormullion shows it pretty well.

https://twitter.com/_cormullion/status/1224640188518932483

Re: JuliaLang: The Ingredients for a Composable Programming Language

#156

Post by lightsighter »

Except they have no story for building composable libraries in a distributed setting. The story for distributed execution in Julia today is just use MPI, which is a terrible answer. Anyone who has ever use libraries backed by MPI in any language knows that they are inherently not composable. You can't just take an object partitioned across multiple nodes one way by one library and pass it into a second library that expects it to be partitioned a different way. As far as I can tell the Julia language has nothing to say about that, and that makes them a non-starter today for anyone trying to build composable libraries for distributed memory machines.

Re: JuliaLang: The Ingredients for a Composable Programming Language

#157

Post by xiaodai »

lightsighter wrote: post #156

Except they have no story for building composable libraries in a distributed setting. The story for distributed execution in Julia today is just use MPI, which is a terrible answer. Anyone who has ever use libraries backed by MPI in any language knows that they are inherently not composable. You can't just take an object partitioned across multiple nodes one way by one library and pass it into a second library that e…

Just curious, is there anything that's composable in the distributed world

Re: JuliaLang: The Ingredients for a Composable Programming Language

#158

Post by Symmetry »

sgt101 wrote: post #131
smabie wrote: post #30

Earlier quoted context omitted.

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

Yes - I understand why some people are keen on static types, but type inference is a powerful way to create funcetionality and I believe that the separation of concerns between the dispatcher and the programming code (removing the logic of decisioning from the code and using type inference instead) leads to clearer programs. I can't think how you can have that and have static checking as well (although I know that th…

Lots of languages with static typing use type inference. Haskell, OCaml, Go, Rust, Nim, etc. Even C++ has auto these days which I think when combined with templates gives you what you're talking about though it is a bit clunky.

EDIT. For instance in Haskell I can just declar a function to sum the things in a container by saying

  summer a = folder (+) 0 a
And the compiler will figure out that the function accepts a Foldable container of some sort full of things that are Nums without ever having to tell the compiler that (though it's a good idea for maintainability. And then I can just pass in a list of floats and the compiler will Do The Right Thing. And if I pass in a list of booleans instead the compiler will yell at me at compile time because there's no (+) operation for booleans.

Re: JuliaLang: The Ingredients for a Composable Programming Language

#159

Post by socialdemocrat »

byt143 wrote: post #48
socialdemocrat wrote: post #43

Earlier quoted context omitted.

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.

I don't think so, I may be wrong, but I am quite sure you would get a significant performance penalty in Swift if you used protocols all over the place.

For instance if `func foo(bar: Number)` in Swift would give bad performance I believe as the number object would have to be boxed.

Julia can work with abstract types in a lot of instance without getting any performance penalty due to how the Julia type system works and Just in Time compilation. I don't quite see how a statically typed AOT compiled language could achieve the same.

Re: JuliaLang: The Ingredients for a Composable Programming Language

#160

Post by socialdemocrat »

eigenspace wrote: post #37
socialdemocrat wrote: post #21

Earlier quoted context omitted.

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…

> 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. You can do this with traits. One pattern is that you can define struct Shape{T} end struct Not{T} end has_shape_trait(::T) where {T} = N…

Great example with the traits. Yes I seemed to have made a whole series of typos. Must have been tired then.

In this quote, I meant Julia and not Swift ;-)

" some similarity in flexibility to Swift's way of dealing with types."

Post reply on HN