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

211–220 of 228 posts

Re: JuliaLang: The Ingredients for a Composable Programming Language

#211

Post by FranzFerdiNaN »

Iwan-Zotow wrote: post #166
SolarNet wrote: post #154

Earlier quoted context omitted.

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

Why I have to make special efforts to make simple things? Simple example - I have Python sequence [0...N) to process. If members are independent, I could split it with easy in Python and do it in parallel: [0...N) -> [0...M) + [M...N) for any M between 0 and N. Basically, Python sequences/ranges/etc are monoids in many cases. Simplest composition rule - monoid, with unit element and associative composition. In Julia…

0-based indexing makes some things harder. Why should i have to make special effort to make those things simple?

Re: JuliaLang: The Ingredients for a Composable Programming Language

#212

Post by socialdemocrat »

throwaway894345 wrote: post #194
socialdemocrat wrote: post #181

Earlier quoted context omitted.

What you can do with Julia types is far more advance than I think you can do with any statically typed language. I can add a type annotation in Julia which is a function call which returns a type e.g. This function can be of any complexity. I think a better approach is simply a Linter. You report type problems you can find and ignore the rest. Not point trying to figure out the more advance Julia cases. I would assum…

You're describing optional type systems; in this regard, Julia is on par with Python or TypeScript. The linter you're describing is also a type checker (like Python's Mypy). That said, it would be really interesting if someone would make a type checker that would evaluate/resolve those more complex types, at least those that can be guaranteed to terminate.

Optional typing and what Julia does is quite different. Julia type system is nothing like Python or TypeScript.

In Julia type annotations are not just a sprinkle of sugar. It has a very concrete use beyond asserting type consistency.

Julia types are used to decide what code gets run and memory layout of data.

Re: JuliaLang: The Ingredients for a Composable Programming Language

#213

Post by socialdemocrat »

c-cube wrote: post #200
socialdemocrat wrote: post #180

Earlier quoted context omitted.

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…

For me static typing removes mental overhead. I have fewer things to keep in my head, I can trust the tools to have my back and point me to where I did stupid mistakes. It makes reasoning about the code more local. Also you can have static typing in an interpreted, interactive setting, with any language that has a REPL. That's even how the ML family started.

Peace of mind is not quite the same as what I meant with mental overhead. What I am referring to is that static type systems have far more complex type systems and semantics, which occupy more brain real estate.

And complexity tends to explode because it carries over to the tools. Static languages require far more complex tools to work with.

I did not mean static languages cannot have REPLs but my experience with them have not been great. They seem hamstrung in a way I cannot articulate well.

Re: JuliaLang: The Ingredients for a Composable Programming Language

#214

Post by sgillen »

krastanov wrote: post #58
mark_l_watson wrote: post #18

Earlier quoted context omitted.

FluxML is amazing, so much nicer than using TensorFlow.

I will have to disagree. FluxML is indeed great, but it changes often and it does not support many of the advanced features of TensorFlow (neither is there a package that seamlessly works with Flux in order to support these features). It is getting there, but Tensorflow v2 is pretty great itself, and frequently faster. But FluxML might soon be as good or better. Also, to be fair, FluxML is backed by a couple of peopl…

I mean to be fair I think the person you are responding too just finds flux more pleasant to use, not more feature complete.

I use pytorch mostly and always find tensorflow very cumbersome, but I assume it’s because I haven’t spent enough time with it yet.

Re: JuliaLang: The Ingredients for a Composable Programming Language

#215

Post by sgillen »

inamberclad wrote: post #197

I never was able to get julia to do what I want. If I were a data scientist who developed and maintained large libraries, then it would probably be great, but I'm not. I just want to quickly visualize and modify data, or maybe see how a model compares. Much more difficult to do simple things like that than in Octave/Matlab.

That’s interesting I would have thought it would be the opposite. Julia being good at smaller experimental work and maybe creaking when things get scaled and put into production. Coming from a matlab background I found Julia much more natural to pick up than say python.

Re: JuliaLang: The Ingredients for a Composable Programming Language

#216

Post by socialdemocrat »

oxinabox wrote: post #186
socialdemocrat wrote: post #180

Earlier quoted context omitted.

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…

Dynamic languages do do type inference. Or at least they can. Julia does type inference at compile time. The difference is that it doesn't have to succeed. If you write type unstable code then it won't.

Yes... but I feel that is more like an implementation detail. Semantically speaking you don't think of Julia as doing type inference.

Semantically speaking expressions don't have types and the type of expressions are never inferred (however they are inferred at compile time as an implementation thing for the JIT).

My point is that you can make an alternative Julia implementation that did absolutely no type inference and everything would work just fine apart from possibly bad performance.

However you could not make a compiler for a statically typed language such as Haskell which did not do type inference. If you did programs would no longer compile.

At least that is how I interpret the difference. I could be wrong. You probably know this better than me.

Re: JuliaLang: The Ingredients for a Composable Programming Language

#217

Post by socialdemocrat »

int_19h wrote: post #182
socialdemocrat wrote: post #178

Earlier quoted context omitted.

> Julia is the opposite - it's better than Python in one particular narrow niche, and cannot replace it broadly. So it has to offer enough to justify going from one language to two. Absolutely disagree. I will claim Julia is a BETTER general purpose language than Python. I am not an academic or researcher. I use Julia over Python because I find it better is almost every regard apart from startup time ;-) Julia outdo…

What truly makes the language general purpose isn't really language features. The vast majority of languages are "general purpose" by that metric - but you don't see people writing desktop apps in, say, R or PHP. It's the libraries. Python embraced "batteries included" a long time ago, and then there's everything on PyPI on top of that. With a language like Julia, it's going to be a chicken-and-egg problem - so long…

I partly agree, but I think it is a bit more to it than that. Part of what made Perl, Python and Ruby so widely used compared to say LISP or Matlab is that they are great at text manipulation and interacting with the unix shell.

Julia is exactly the same. Anything people would use to write shell scripts, I would use Julia with instead and I have used many languages for this purpose: Python, Ruby and Go. Out of al these I find Julia to be the best language.

The fact that Julia is free, open source, available on all platforms and is good at text and shell stuff means it has a sort of Trojan horse ability to get into more wide usage.

I am not a scientific programmer, yet I use Julia for a whole bunch of stuff and find it very productive. Here are some examples of stuff I have written in Julia:

- Custom scripts for Swift and Objective-C app compilations.

- Various file conversion utilities.

- Code generators based on custom DSLs. Due to Julia's support for macros writing a DSL is easier in Julia than in Python, Go or whatever "script" alternative I might have used. - Various parsers. I find Julia very good at writing parsers. I have used this to create tools for manipulating user interface definition files for a larger C++ project.

- Editor plugins. I have written plugins in Julia for e.g. TextMate although I guess it would have worked on Sublime and other editors as well.

I cannot imagine anyone would have had a nice experience writing any of this stuff in R or Matlab.

Julia may never get big as a Web programming language, but for scientific programming, data science, data scraping/munging/preparation, scripting make up quite a large field together.

Julia may have some slow startup due to JITing but I found my Julia scripts to run much faster than the shell scripts they replaced and the Julia code was easier to read and faster to write.

Re: JuliaLang: The Ingredients for a Composable Programming Language

#218

Post by FridgeSeal »

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…

Surely Haskell and Rust would be fantastic examples of languages that have static typing and excellent type inference?

Re: JuliaLang: The Ingredients for a Composable Programming Language

#219

Post by jbieler »

throwaway894345 wrote: post #133
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.

Presumably this means that no one has implemented a suitable static type checker or its type annotations don't provide sufficient information for a static type checker to work in principle?

I wrote an article showing a (probably naive) way how it could be done, but also discussing some of the limitations. At the end I think it would be better to think about these kind of tool as partial, automated tests rather than full-blown static type checkers.

https://nextjournal.com/jbieler/adding-static-type-checking-...

Re: JuliaLang: The Ingredients for a Composable Programming Language

#220

Post by oxinabox »

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.

DiffEq on ForwardDiff Dual numbers to calculate sensitivity via forward mode AD. DiffEq on Tracker's TrackedArray to calculate sensitivity via reverse mode AD.

Measurements.jl's numbers that track measurement error input any algorithm to compute the transformed measurement error after the algorithm is applied.

NamedDims.jl + Flux.jl to give everything that PyTorch's awesome Named Tensors feature gives.

Post reply on HN