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

141–150 of 228 posts

Re: JuliaLang: The Ingredients for a Composable Programming Language

#141

Post by chalst »

tgflynn wrote: post #125
byt143 wrote: post #46

Earlier quoted context omitted.

This can be done better with traits in Julia, which are more powerful, safer and faster. See here: https://white.ucc.asn.au/2018/10/03/Dispatch,-Traits-and-Met...

Perhaps. The feeling I get with Julia is that the devs are sort of making it up as they go along. I don't mean just making up the language (which of course they're doing), but making up whole new approaches to programming that aren't necessarily well-understood and tested in the real world and certainly aren't very familiar to most programmers. Maybe in the end they will succeed and will invent a generally superior a…

A lot of the ideas come from Common Lisp.

Re: JuliaLang: The Ingredients for a Composable Programming Language

#142

Post by short_sells_poo »

Seanny123 wrote: post #135
improbable22 wrote: post #110

Earlier quoted context omitted.

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…

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, different file, tucked away in a module. It could be in a dozen other files, or no files at all, and you can't tell from looking at just the source of the file.

Re: JuliaLang: The Ingredients for a Composable Programming Language

#143

Post by pjmlp »

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…

Hardly any different than other programming languages with multiple implementations.

Re: JuliaLang: The Ingredients for a Composable Programming Language

#144

Post by pjmlp »

edw wrote: post #124
goatlover wrote: post #117

Earlier quoted context omitted.

Sure, but HLLs are decades old and ubiquitous by the 80s. There's no reason to think PLs are going to fundamentally change in 20 years. They could, but it's just speculation at this point.

The argument over whether C was fast enough to obviate the need to write in assembly raged across the pages of Dr Dobb's Journal and Byte Magazine well into the mid '80s.

Which while true for home micros, was already a proven fact since the early 60's in the big warehouse mainframes, with the Algol derived systems programming languages.

Re: JuliaLang: The Ingredients for a Composable Programming Language

#145

Post by Recurecur »

int_19h wrote: post #120
baron_harkonnen wrote: post #63

Earlier quoted context omitted.

I remember when Python was a new and exciting language and people said the exact same thing about Perl. "You'll never see Python replace Perl for string processing, Perl has such a huge ecosystem!". At the time Perl was the de facto interpreted/"scripting" language. Sure Perl is around still, but it has become a rather niche language used in a small number of specific communities. I use Python everyday, and still hav…

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!

Re: JuliaLang: The Ingredients for a Composable Programming Language

#146

Post by dv_dt »

FranzFerdiNaN wrote: post #15
smabie wrote: post #10

Julia is great. It’s significantly simpler than Python while also being much more expressive. It’s too bad the typing is only for dispatch, but hopefully someone will write a typechecker someday. I’ve found it surprisingly refreshing to not have to think about classes and just add functions on objects wherever I want. Some languages solve this with monkey patching (which is bad), others like Scala with an extension c…

Python will still be used 20 years from now. The clear advantage of Python is the enormous ecosystem that is available, the millions of questions on SO giving solutions to every problem you can run into, the books and learning materials etc, programmers and corporations having invested loads of time and effort in building, maintaining and battle-testing libraries. Don't get me wrong, i think Julia is an amazing langu…

Perl used to be in somewhere similar to Pythons place 20 years ago...

Re: JuliaLang: The Ingredients for a Composable Programming Language

#147

Post by StefanKarpinski »

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 that were written by other people and just use them together efficiently and effectively. This majorly raises the table stakes for code reuse in programming languages. Language designers should not copy all the features of Julia, but they should at the very least understand why this works so well, and be able to accomplish this level of code reuse in future designs.

Re: JuliaLang: The Ingredients for a Composable Programming Language

#148

Post by improbable22 »

Seanny123 wrote: post #135
improbable22 wrote: post #110

Earlier quoted context omitted.

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…

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.

Just reading what everyone does may work. Here's a tiny package:

https://github.com/ChrisRackauckas/EllipsisNotation.jl

I think that `/src/Name.jl` must have the main module, and `/test/runtests,jl` tests. And the package manager cares about `Project.toml`. But beyond this there are no real rules enforced, although there really seems to be one way to do things.

Here's a much bigger project, organised the same way. `include(file.jl)` literally copies in the text, and it's somewhat conventional to collect all imports & exports in the main file:

https://github.com/JuliaNLSolvers/Optim.jl/blob/master/src/O...

Still no sub-modules. No files included in mysterious locations. Methods being defined for functions from elsewhere are all qualified, like `Base.show(io::IO, t::OptimizationState) = ...`

Re: JuliaLang: The Ingredients for a Composable Programming Language

#149

Post by UncleOxidant »

StefanKarpinski wrote: post #136
UncleOxidant wrote: post #127

Earlier quoted context omitted.

I guess what I don't understand is this part (regarding the compiled mode): "The drawback is of course that breakpoints in code that is stepped over are missed." what exactly does that mean?

It means that if you would have hit a breakpoint in code that is run in compiled mode, the breakpoint doesn't trigger—because it's being run normally at full speed without breakpoints, not being interpreted in the debugger (which knows about breakpoints).

I read this as in compiled mode breakpoints don't trigger at all. Is that correct?

Edit: Ok, I tried out compiled mode and it does stop at my breakpoint. The verbage in the documentation is a bit difficult to understand on this point. I'd guess you need to first set your breakpoints prior to going into compile mode?

Re: JuliaLang: The Ingredients for a Composable Programming Language

#150

Post by cosmojg »

eigenspace wrote: post #102
cosmojg wrote: post #92

Earlier quoted context omitted.

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.

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-collected languages, Julia is unlikely to ever compete with the likes of Zig, Rust, C++, etc. which produce even smaller static binaries since they don't have to ship a GC runtime. That's why I specified garbage-collected languages as, in my opinion, the addition of proper static compilation will allow Julia to completely supersede other garbage-collected general programming languages but not manually managed systems programming languages.

Post reply on HN