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

181–190 of 228 posts

Re: JuliaLang: The Ingredients for a Composable Programming Language

#181

Post by socialdemocrat »

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?

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 assume 90% of Julia code will use types in a pretty straightforward manner and thus would be able to be analyzed by some sort of Linter. Lint.jl e.g.

Re: JuliaLang: The Ingredients for a Composable Programming Language

#182

Post by int_19h »

socialdemocrat wrote: post #178
int_19h wrote: post #120

Earlier quoted context omitted.

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

> 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 as people are using it mostly for scientific computing, the stable and well-maintained libraries for it are mostly going to be about that.

Re: JuliaLang: The Ingredients for a Composable Programming Language

#183

Post by mindB »

tgflynn wrote: post #122
oxinabox wrote: post #80

Earlier quoted context omitted.

Generally via wrapping (Composition). ``` struct Foo struct SpecialFoo{T and then delegating calls to the wrapped object

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 actual implementations of method-forwarding macros, there's an implementation in Lazy.jl[1], and TypedDelegation.jl[2].

[1] https://github.com/MikeInnes/Lazy.jl/blob/0de1643f37555396d6...

[2] https://github.com/JeffreySarnoff/TypedDelegation.jl

Re: JuliaLang: The Ingredients for a Composable Programming Language

#184

Post by Iwan-Zotow »

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

Earlier quoted context omitted.

Whatever I'm doing this is wrong. 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 it really looks ugly, yo…

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?

Re: JuliaLang: The Ingredients for a Composable Programming Language

#185

Post by ablekh »

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 experts) on development of more and/or better features; B) develop an MVP in Python, then rewrite it for production in Julia for much better native performance, GPU integration and potential use of macros for an embedded DSL; C) take more time initially to master Julia and develop an MVP and then the corresponding production platform in Julia from scratch?

EDIT: Forgot to mention that HPC workloads would represent a significant, albeit non-unique, aspect of the platform in question.

Re: JuliaLang: The Ingredients for a Composable Programming Language

#186

Post by oxinabox »

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…

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.

Re: JuliaLang: The Ingredients for a Composable Programming Language

#187

Post by gmassman »

Recurecur wrote: post #145
int_19h wrote: post #120

Earlier quoted context omitted.

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

"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." How so? Julia is a fine general purpose language. I'd go so far as to say it's more appropriate than Python for a wide class of problems!

Purely anecdotal evidence, but Julia's support for basic HTTPS server capabilities is immature at best. Sure, it is capable, but the amount of effort to build an web API is much higher than in a language like Python which has had many more years to mature its ecosystem.

That's not to say I dislike Julia. I think it's a wonderful language for numerical computing. Over the next few years I certainly hope to see wider adoption among data science and analytics communities.

Re: JuliaLang: The Ingredients for a Composable Programming Language

#188

Post by oxinabox »

totalperspectiv wrote: post #82
xvilka wrote: post #2

I hope Julia will be more popular in bioinformatics. Personally, I have a high hopes for BioJulia[1][2][3] and the amazing AI framework FluxML[4][5] + Turing.jl[6][7]. Apart from the speed, they offer some interesting concepts too - I recommend to check them out. [1] https://biojulia.net/ [2] https://github.com/BioJulia [3] https://github.com/BioJulia [4] https://fluxml.ai/ [5] https://github.com/FluxML/ [6] https://…

I've always found Julia a little lacking for bioinformatics, but I'm not doing ML. I have very high hopes for Nim, which I think has better performance potential than Julia across domains and can produce binaries.

Nim made me really sad when they gave up on multiple dispatch. I has such potential as a language but I just can't imagine using one without multiple dispatch anymore

Re: JuliaLang: The Ingredients for a Composable Programming Language

#189

Post by oxinabox »

short_sells_poo wrote: post #142
Seanny123 wrote: post #135

Earlier quoted context omitted.

I mean, I'd like them to work like Python, Ruby and TypeScript, but you're right to say I can't describe why I want this. Is there some guide I could read about structuring a large Julia project? It was pretty easy to intuit with Python, wherein I would put related files in a folder. But with Julia, everything is everywhere and I'm baffled.

> But with Julia, everything is everywhere and I'm baffled. This is exactly it. Julia allows you to import and include anything, anywhere. You open a file and it doesn't say anything about where the dependencies are coming from and where this particular piece of code will go. Both of those are defined at the place where this file is included, which itself could be anywhere. It could be a different directory, differen…

In practice most packages:

1. Never use submodules (they don't add much) 2. Only use `include` within the main `src/MyPackage.jl` file

Re: JuliaLang: The Ingredients for a Composable Programming Language

#190

Post by oxinabox »

tgflynn wrote: post #122
oxinabox wrote: post #80

Earlier quoted context omitted.

Generally via wrapping (Composition). ``` struct Foo struct SpecialFoo{T and then delegating calls to the wrapped object

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.

You are not wrong. Also even the best metaprogramming solution will not help you you when you method to add to your backing type
Post reply on HN