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

221–228 of 228 posts

Re: JuliaLang: The Ingredients for a Composable Programming Language

#221

Post by byt143 »

e12e wrote: post #73
byt143 wrote: post #34

Earlier quoted context omitted.

Thanks. I mean in julia you can use traits for that, but it's not built in (yet). Though there's no speed penalty, as you probably know. So this is about extending types, but it sounds like swift is strictly "better" then, since it's also statically checked? Or is there something that multiple dispatch gives that substantively better? I'm trying to get a feel for if the Swift for Tensorflow project will afford the sa…

Does swift have macros? Looks like there's some work in bolting type checking on to Julia (small surprise, as we've seen that with eg: python and ruby as well). I'd hazard it's easier to bolt on typechecking than a proper macro system.

It does not have macros.

Re: JuliaLang: The Ingredients for a Composable Programming Language

#222

Post by ddragon »

pdexter wrote: post #210
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.

As an additional example, I really like the combination of unitful and diffeq [1]. But you're right that the core feature that allows this stuff is duck typing, but by itself it's not enough. Your notduck had to not only quack, but other animals have to look at it and act like it's a duck sometimes and like a notduck when you want it to do more than a duck. Multiple Dispatch (plus parametric subtyping) allows you to trivially define both notduck + A (notduck.+(A) in OOP languages) and A + notduck (extending A whatever A is) and it's really fast. That allows for the core Julia concept of specialization, easily customizing the particular behavior of any agent at any point to get both the common behavior right and the extended behavior.

For static languages you can implement part of it with, for example, interfaces (you'll face the same restrictions if the language is single dispatch), but even if you can extend the interface freely for already existing objects, there must be an agreement between the multiple packages to comply to the same interfaces (and you might either end with tons of interfaces since there are tons of possible behaviors for each entity and purpose or giant interfaces to fit all). In Julia you can use specialization to surgically smooth the integration between two packages that had no knowledge of each other and didn't even decide to comply to any (informal) interface (which do exist in Julia, like the Julia Array and Tables.jl interfaces).

[1] https://tutorials.juliadiffeq.org/html/type_handling/03-unit...

Re: JuliaLang: The Ingredients for a Composable Programming Language

#223

Post by Symmetry »

socialdemocrat wrote: post #180
Symmetry wrote: post #158

Earlier quoted context omitted.

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

I think he possibly phrased it wrong. Dynamic languages don't do type inference, they carry type with each value at runtime. Dynamic and statically typed languages each have their own wonderful advantages. There is just no way of replicating all the advantages of dynamic typing in a statically typed language. It is hard to sum up why in a short sentence but I have tried to articulate it in a longer article here: http…

Reading through that Medium post makes me think that maybe the author has never worked with a large code base written in a dynamic language and is attributing the difficulties of large projects to them being written in static languages? My day job involves a large amount of Python and we certainly use CMake to bundle it up for deployment, use YAML configuration files, worry about library version compatibility, and all of the other problems the author ascribes to static typing.

Re: JuliaLang: The Ingredients for a Composable Programming Language

#224

Post by mindB »

oxinabox wrote: post #191
mindB wrote: post #183

Earlier quoted context omitted.

If using meta-programming to get "basic" features rubs you the wrong way, the language might just not be for you. In general, the Julia philosophy (as well as the lisp philosophy from which Julia descends) is that things which can be done efficiently using macros instead of being built-in should be done with macros. Language features are only for things that cannot be accomplished via metaprogramming. As far as actua…

I have concluded that it is basically impossible to write a general purpose delegation macro. I have seen many and alway immediately run into cases they can't handle. A top level `for m in (:foo, :bar); @eval $m(X::MyType) = $m(X.backing)` Is general and has no performance overhead

To be honest, I've never found the need for delegating a huge number of methods in my own work, but then I've never wanted to add a feature or field to something as complex and featureful as e.g. a DataFrame. What issues have you run into when using method-forwarding/delegation macros?

The nice thing about the Julia ecosystem is that people tend to be pretty willing to step back and define their methods in terms of an interface (Tables.jl in this case) which then allows code reuse without brittle delegation. Having to put so much effort into changing the structure of upstream doesn't seem ideal from a composability perspective though.

Re: JuliaLang: The Ingredients for a Composable Programming Language

#225

Post by vanderZwan »

tgflynn wrote: post #119
vanderZwan wrote: post #87

Earlier quoted context omitted.

> It’s too bad the typing is only for dispatch, but hopefully someone will write a typechecker someday I was under the impression that if you write a function that takes very specific sub-types as its parameters, and then try to call it with invalid parameters (that is, values that cannot be converted to the right type via the promotion rules) that Julia will complain about this?

It will complain, but typically only at run time.

Ah, right! We're talking about AOT typechecking. I had forgotten Julia doesn't really do that (yet). Yes, fair is fair, since that is when it is the most useful its absence is a bit painful.

Re: JuliaLang: The Ingredients for a Composable Programming Language

#226

Post by iLemming »

mark_l_watson wrote: post #112
vasili111 wrote: post #44

Earlier quoted context omitted.

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

I didn’t express that correctly. What I meant to say was that I investigated Julia as a possible “use it for everything language.” For me, general purpose has to include deep learning tools. I really prefer Lisp and Haskell, but although Haskell’s TensorFlow support is pretty good, I found it easier to just use Python. I have had problems with the SBCL Common Lisp TensorFlow C bindings, but perhaps that was my fault.

AFAIK Clojurians doing some interesting stuff in that space. They've figured out Python Interop, writing books on Deep learning, Linear Algebra, etc. all that in Clojure.

https://aiprobook.com https://nextjournal.com/gigasquid

Re: JuliaLang: The Ingredients for a Composable Programming Language

#227

Post by masklinn »

mumblemumble wrote: post #151
masklinn wrote: post #84

Earlier quoted context omitted.

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

> My sense is that it's because Java isn't really all that static a language.

All the stuff that happens at runtime explains the "low rewards" part, but it doesn't explain the "high investment", Java is also an extremely verbose language, doing anything is verbose and the one thing you'd want to be doing (create and use new types) is one of the most verbose parts of the language.

Records will eventually make things less bad, but a "newtype pattern" in Java takes a dozen lines or five, that's horrendous for something which should take maybe two lines. And that's before we even consider the insanity of the "one (public) class per file" mandate.

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

There are lots of criticisms you can leverage at Python, but it's nowhere near as bad a representative of dynamically typed language as Java is statically typed ones.

Re: JuliaLang: The Ingredients for a Composable Programming Language

#228

Post by cmcaine »

eigenspace wrote: post #171
cosmojg wrote: post #150

Earlier quoted context omitted.

I equate garbage collection with larger static binaries. Julia's static binaries are especially large since they package the entire sysimage. I'm excited about StaticCompiler.jl because, by cutting out the sysimage, it promises to make Julia more competitive with other garbage-collected languages like Nim, Go, Crystal, etc., all of which produce relatively small static binaries. However, like these other garbage-coll…

I see, thanks for the explanation! I think with StaticCompiler.jl, if you create a binary where the compiled code knows there won't be any GC, for instance, say you only ever work with Tuples and floating point numbers, I don't think there will be any GC runtime in the compiled binary. I could be wrong about this though.

Julia can stack allocate all sorts of values. I think it currently stack allocates all immutable values and also every mutable value that it proves do not escape their function.

Kind of besides the point, though, because the GC is probably not heavy anyway. Lots of fear of GC is not based on benchmarks.

Post reply on HN