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

101–110 of 228 posts

Re: JuliaLang: The Ingredients for a Composable Programming Language

#101

Post by fludlight »

tgflynn wrote: post #32
oxinabox wrote: post #24

Earlier quoted context omitted.

Author of post here: there were a major gripe for me starting out too. It took me a fair while to conclude that they allowed to useful things in the bigger picture. and it certainly is not a pure win. I do miss static typing. I would question the claim it doesn't scale to production. I know people who have build hugely complex production systems in perl that are still running today 20 years later. Further, I myself w…

> I know people who have build hugely complex production systems in perl that are still running today 20 years later. Sure, but there aren't many programmers who would want to maintain such a system.

Most programmers want to build new things, not work on maintenance projects, regardless of tech stack.

That said, many people do enjoy that sort of work and finding them is not unusually difficult unless the project is so big that you need dozens of bodies.

Re: JuliaLang: The Ingredients for a Composable Programming Language

#102

Post by eigenspace »

cosmojg wrote: post #92
snicker7 wrote: post #61

Earlier quoted context omitted.

I think the above poster is referring to languages like Go/Java/C#/Nim/whatever. Like Julia, these languages have a significant runtime. Unlike Julia, their apps can be compiled AOT into standalone executables.

My point exactly! Thanks for clarifying.

Right, but you said

> there will no longer be any reason to use any other garbage-collected language.

(emphasis mine). I was just curious as to why you specified garbage collected there.

Re: JuliaLang: The Ingredients for a Composable Programming Language

#103

Post by gugagore »

tgflynn wrote: post #50
logicchains wrote: post #39

Earlier quoted context omitted.

>In a language that supports classes I can have class B inherit from class A and automatically provide all of class A's functionality without adding a single extra line of code. And people will abuse this to create horrible brittle inheritance hierachies. There's a reason modern languages like Go and Rust deliberately don't support implementation inheritance; to many people it's an antifeature.

The thing about software is that the "one true way" changes every 2 or 3 years. A few decades ago inheritance was considered a key software design principle, then it was abused by many (especially Java programmers, I think), just like any other powerful feature, now it's considered evil. If multiple dispatch becomes as popular as classes/inheritance was, I suspect it will go through the same love/hate cycle. All I kn…

It's interesting to think about what multiple dispatch abuse would be.

As far as I know, implementation inheritance can be misapplied when you try too hard to use the language's type system to capture some domain-specific model. e.g. you're dealing with multiple kinds of entities, and they all have a `name`, so you decide that all of the classes should inherit from `class Named`, because they have that in common with each other.

Well, there's lots of different taxonomies possible for your entities, probably. And single implementation inheritance lets you express just one taxonomy. Interfaces and multiple inheritance aim to allow multiple co-existing taxonomies, but I can't really explain the ways in which its misapplied.

I agree that there are some clear situations for implementation inheritance, so it seems like a useful pattern to be able to support. I think the discussion is whether it should be a key design principle, and built into the language design, or if the language design should be more general, so that implementation inheritance can be built on top of that.

Re: JuliaLang: The Ingredients for a Composable Programming Language

#104

Post by [deleted] »

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://…

[deleted]

Re: JuliaLang: The Ingredients for a Composable Programming Language

#105

Post by improbable22 »

CreRecombinase wrote: post #86
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://…

How much of the BioJulia stuff would you say currently works? It looks like a lot of repos have been created, and the scope is pretty impressive (looks like there are repos for everything from structural bioinformatics to population genetics), but a lot of them look to be basically empty( https://github.com/BioJulia/PopGen.jl ), or have really scary looking issues:(e.g https://github.com/BioJulia/GeneticVariation.jl/…

Not my field, but at least some of it appears to be worked on seriously. This was an interesting recent blog post about making DNA-sequence processing go fast:

https://biojulia.net/post/seq-lang/

Re: JuliaLang: The Ingredients for a Composable Programming Language

#107

Post by gugagore »

eigenspace wrote: post #54
cosmojg wrote: post #49

Earlier quoted context omitted.

> A more traditional static compilation approach is being tried with StaticCompiler.jl by tshort, but it's in early development. The moment this ships, there will no longer be any reason to use any other garbage-collected language.

What does this have to do with garbage collection? If your concern is about latency in real time systems, Garbage collection isn't the problem, heap allocating memory is. Julia makes it easy to never allocate anything on the heap (unlike most garbage collected langauges). Check out this talk this discusses this in detail in the context of robotics: https://www.youtube.com/watch?v=dmWQtI3DFFo

Julia doesn't make it easy to guarantee that you won't allocate anything on the heap. The semantics of the language don't include really any control over that, yet. I hope one day it does. It seems like a tough problem, because the allocation strategy can depend on the results of inference and compilation, which is another thing that is hard to control since the language try hard to have the semantics not depend on inference.

Of course, you can measure the allocations, and you can see as a matter of fact whether some code allocates, but I would say that it's hard to predict what allocates and what doesn't, and that this is still changing (e.g. https://github.com/JuliaLang/julia/pull/32448)

Re: JuliaLang: The Ingredients for a Composable Programming Language

#108

Post by Sukera »

UncleOxidant wrote: post #85
nwvg_7257 wrote: post #78

Earlier quoted context omitted.

Couple comments on the Debugger situation: 1. Debugger.jl is A LOT smoother if you run it in compiled mode, which is a checkbox in the Juno interface. I've found that stepping to next line is instant in compiled mode, but takes forever without it. 2. Infiltrator.jl is great at what it's designed for, which is to dump you in a REPL deep within a call stack and let you see what's going on. But, Debugger in compiled mod…

> 1. Debugger.jl is A LOT smoother if you run it in compiled mode, which is a checkbox in the Juno interface. I've found that stepping to next line is instant in compiled mode, but takes forever without it. Is there a way to do this if I'm not running Juno? I'd guess there must be some parameter that can be passed to @enter or @run?

Sure! 'C' in the debug REPL enters compiled mode.

https://github.com/JuliaDebug/Debugger.jl#compiled-mode

Re: JuliaLang: The Ingredients for a Composable Programming Language

#109

Post by kescobo »

CreRecombinase wrote: post #86
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://…

How much of the BioJulia stuff would you say currently works? It looks like a lot of repos have been created, and the scope is pretty impressive (looks like there are repos for everything from structural bioinformatics to population genetics), but a lot of them look to be basically empty( https://github.com/BioJulia/PopGen.jl ), or have really scary looking issues:(e.g https://github.com/BioJulia/GeneticVariation.jl/…

% of the repos in the org on github? That number is lower than I'd like. % of the repos that are actively maintained? Much higher.

One of the great things about julia is that it's really easy to throw together a package and register it. One of the bad things about julia is how easy it is for those one-off projects or idea dumps to pollute the space. We could definitely do a better job labeling the repos that are no longer being maintained or that aren't actually ready for prime time. There's a tradition in julia of a lot of really functional libraries to stay < v1.0, because we all take semver seriously, and if the interface is still in a bit of flux, making the switch to 1.0 is a big deal (DataFrames.jl, looking at you). But it does make it hard for new users to distinguish between a super robust package and someone's weekend hobby.

Re: JuliaLang: The Ingredients for a Composable Programming Language

#110

Post by improbable22 »

short_sells_poo wrote: post #40
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…

You touch upon some interesting pain points. I really like Julia and working with it is a pleasure. Except the Module system, which feels unnecessarily arcane. I'm happy to be educated on why, but it seems to successfully combine the awkwardness of C-style #include with the mess of a free-form module system. The end result is a Frankenstein monster where technically everything is possible, everything could be include…

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 with a macro, or simply copy-pasting wrong.

Post reply on HN