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

191–200 of 228 posts

Re: JuliaLang: The Ingredients for a Composable Programming Language

#191

Post by oxinabox »

mindB wrote: post #183
tgflynn wrote: post #122

Earlier quoted context omitted.

Yes, but delegation requires a lot of extra code to get what you have for free in a class based language. And yes I know you can probably write macros to handle much of that but having to use meta-programming to get what other languages give you for free doesn't seem ideal to me.

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

Re: JuliaLang: The Ingredients for a Composable Programming Language

#192

Post by goatlover »

hpcjoe wrote: post #168
goatlover wrote: post #132

Earlier quoted context omitted.

Sure, but if Julia relegates Python to a niche and Rust does the same thing to C, they're still the same kind of approach to programming, and not some high level, mostly automated thing. They don't fundamentally change how people program.

When you write idiomatic Julia ... not C in a Julia syntax, but actually leverage the native power of Julia, yeah, you write code differently.

Same with idiomatic Python or Lisp circa 1960.

Re: JuliaLang: The Ingredients for a Composable Programming Language

#193

Post by eigenspace »

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’m a bit biased as someone who switched from Python to Julia for my physics research (I.e. I’m biased to believe I made a good choice and others should follow my decision making), but I think any extra effort you spend in the beginning to get it working in Julia will pay big dividends.

In the scientific world, Julia’s package ecosystem is already more developed than Python in some fields (Differential equations being one, but there are others), so you may not find that limiting you.

Furthermore, for the reasons laid out in the article, Julia is highly composable and empirically, has a far greater ratio of code re-use than Python. I believe you’ll see greater bang for your buck in Julia because code you write is more likely to be re-used, especially in scientific domains.

Re: JuliaLang: The Ingredients for a Composable Programming Language

#194

Post by throwaway894345 »

socialdemocrat wrote: post #181
throwaway894345 wrote: post #133

Earlier quoted context omitted.

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?

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.

Re: JuliaLang: The Ingredients for a Composable Programming Language

#195

Post by yahyaheee »

tgflynn wrote: post #17

Julia is a language I really wanted to like, and to a certain extent I do. However after spending some time working with it and hanging out on the Discourse channels (they certainly have a very friendly and open community, which I think is a big plus), I've come to the tentative conclusion that its application domains are going to be more limited than I would have hoped. This article hits on some of the issues that t…

Yep this has been my conclusion as well, I really wanted to like Julia and there are parts of it I do, but I think it misses the mark in some big ways.

Re: JuliaLang: The Ingredients for a Composable Programming Language

#196

Post by ablekh »

eigenspace wrote: post #193
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’m a bit biased as someone who switched from Python to Julia for my physics research (I.e. I’m biased to believe I made a good choice and others should follow my decision making), but I think any extra effort you spend in the beginning to get it working in Julia will pay big dividends. In the scientific world, Julia’s package ecosystem is already more developed than Python in some fields (Differential equations bein…

Your blazingly fast and thoughtful comment is much appreciated. Let's see what others have to say ... :-)

One clarification that I would like to make (which IMO diminishes your second point's potential value) is that the B2B SaaS platform that I plan to build would stay away from implementing a myriad of domain-specific scientific methods and algorithms (though I plan to provide a valuable core) and rather would enable users to integrate their own implementations (through a plug-in architecture). Thus, Julia's package ecosystem seems to be a factor of somewhat lesser importance.

Re: JuliaLang: The Ingredients for a Composable Programming Language

#197

Post by inamberclad »

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.

Re: JuliaLang: The Ingredients for a Composable Programming Language

#198

Post by yahyaheee »

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 a pain than denoting functions as public one way or another.

* The tooling is poor. I work with Go for my day job and it’s toolchain is an absolute pleasure. The Julia toolchain isn’t in the same arena.

* The JIT is slowwww to boot. I was amazed the first time running a Julia program how slow it was. You could practically compile it faster.

* Editor support has never been great.

* As others have mentioned type checks don’t go deep enough

I think it has some neat ideas and in certain scientific arenas it will be useful, but IMO they need to focus a bit more on making it a better general purpose language.

Re: JuliaLang: The Ingredients for a Composable Programming Language

#199

Post by oxinabox »

UncleOxidant wrote: post #60

I really like Julia a lot and actually used it in a work project a few years back. However, there's the debugger issue. There are several debugger alternatives. It's tough to figure out which debugger is canonical (or is any of them the canonical debugger?). The one that seems to being used most at this point is Debugger.jl. However, it's exceedingly slow if you're debugging sizeable operations (matrix multiplies, fo…

I wrote 2 of them. MagneticReadHead.jl and MixedModeDebugger.jl

MagneticReadhead is interesting as it is a purely compiled debugger via extensive source code transfroms. Same magic that powers Zygote.jl for AutoDiff. Also same general concept as is behind Jax.

It has huge compile time overhead, so is not practically usable. In that way it is the opposite of Debugger.jl, rather than being slow at runtime it is very slow at JIT compiling.

MixedModeDebugger.jl is a proof of concept. A small Source Code Transform to allow the debugger to run entirely compiled until it is going to do something, then it swaps to interpreted just like Debugger.jl Early benchmarks are extremely promising. But it's not really hardened enough for use.

Re: JuliaLang: The Ingredients for a Composable Programming Language

#200

Post by c-cube »

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…

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.

Post reply on HN