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

121–130 of 228 posts

Re: JuliaLang: The Ingredients for a Composable Programming Language

#121

Post by elcritch »

Sukera wrote: post #108
UncleOxidant wrote: post #85

Earlier quoted context omitted.

> 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

Thanks! Didn’t even know that was a thing.

Re: JuliaLang: The Ingredients for a Composable Programming Language

#122

Post by tgflynn »

oxinabox wrote: post #80
tgflynn wrote: post #27

Earlier quoted context omitted.

> multiple dispatch, which is strictly more powerful. 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. I can extend class B's functionality by adding only code that is specific to it. I don't see how to do that with multiple dispatch, at least the way it's implemented in Julia.

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.

Re: JuliaLang: The Ingredients for a Composable Programming Language

#123

Post by elcritch »

smabie wrote: post #72
real_eng_ wrote: post #33

Earlier quoted context omitted.

Why every Julia user can't help but trash Python at every occasion? It's getting really tiring

Trashing is a little harsh, but Julia devs probably were mostly Python devs back in the day and are intimately familiar with the inadequacies of the language: the work required when you had to drop into C, the bad syntax for math, the constant conversions between ndarray, array, and lists, etc etc. At my old bioinformatics lab, Python literally wasted thousands and thousands of collective man-hours which would have b…

Exactly... well I didn’t do supercomputing but still wasted a lot of time dealing with Python 2/3 issues among others. Then there’s the ability to do things like fast bootstrapping, Monte-Carlo and other handy statistical techniques without writing kernel functions in C. Python was great for it’s time and enabled a lot and still let’s lots of people do great things, it’s just not for me anymore.

Re: JuliaLang: The Ingredients for a Composable Programming Language

#124

Post by edw »

goatlover wrote: post #117
JadeNB wrote: post #111

Earlier quoted context omitted.

> What hasn't happened is a fundamental change to programming languages since the 1960s I think the rise of HLLs is an example of a fundamental change. It was still reasonable to be hand-writing assembler for lots of applications in the '60s.

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.

Re: JuliaLang: The Ingredients for a Composable Programming Language

#125

Post by tgflynn »

byt143 wrote: post #46
tgflynn wrote: post #27

Earlier quoted context omitted.

> multiple dispatch, which is strictly more powerful. 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. I can extend class B's functionality by adding only code that is specific to it. I don't see how to do that with multiple dispatch, at least the way it's implemented in Julia.

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 approach to software development. But for the moment it all feels very experimental and so not a language I'd want to commit to at present if I were starting a major, non-solo project.

Re: JuliaLang: The Ingredients for a Composable Programming Language

#126

Post by ken »

socialdemocrat wrote: post #21
byt143 wrote: post #7

Anyone know how this compares to swift and its protocols etc?

I am a big fan of Julia, but Swift is perhaps the only statically typed object-oriented language (apart from Objective-C) which I have found offers some similarity in flexibility to Swift's way of dealing with types. With the ability in Swift of adding extensions to conforming to a particular protocol to a class, you gain some of the same flexibility in Swift as in Julia. It means you can take an existing class which…

> With the ability in Swift of adding extensions to conforming to a particular protocol to a class, you gain some of the same flexibility in Swift as in Julia.

You can add methods or computed properties, but that's about it. That's only one axis of flexibility, and it's really only syntactic sugar for writing and calling your own functions. You can't add any other kinds of features, unless they chose to use protocols in their interfaces -- which they usually didn't.

For example, that page gives the example of adding precision to numbers in Julia. I'm not sure how you could do something analogous in Swift, short of writing your own numeric tower from scratch. In Swift 4 they did add a Numeric protocol, but it's not used much. It's probably hard to retcon this sort of interface onto a framework which was built around concrete structs from the start.

Re: JuliaLang: The Ingredients for a Composable Programming Language

#127

Post by UncleOxidant »

Sukera wrote: post #108
UncleOxidant wrote: post #85

Earlier quoted context omitted.

> 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

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?

Re: JuliaLang: The Ingredients for a Composable Programming Language

#128

Post by goatlover »

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.

And that supports the argument that PL evolution is slow and unlikely to fundamentally change in 20 years time. Anyway, while people where arguing over C vs Assembly, there were Lisp and Smalltalk machines that didn't become the future.

Re: JuliaLang: The Ingredients for a Composable Programming Language

#129

Post by whataflag »

Iwan-Zotow wrote: post #12

Composable? Julia and composable?!? They decided on sequence range [1...N], instead of [0...N) like Python. Try to compose that.

1 based indexing introduces a whole class of errors that are solved in Rust. Why aren't you using Rust?

Re: JuliaLang: The Ingredients for a Composable Programming Language

#130

Post by simonbyrne »

dzonga wrote: post #67
eigenspace wrote: post #26

Earlier quoted context omitted.

As others have mentioned, Python does have JIT compilers. The problem is that havign a JIT doesn't solve the problem. PyPy is often a factor of 10 behind julia performance and projects like Numba, PyTorch (the PyTorch people had to build their own Python JIT compiler yikes!), etc. will always have a more restricted scope than a project like Julia because Python's very semantics make many optimizations impossible. Her…

so in this case, once say the Julia ecosystem grows then migrate to Julia. or wait for optimizations to be done, e.g have pandas, numpy etc handle multi-core processors etc ?

> or wait for optimizations to be done, e.g have pandas, numpy etc handle multi-core processors etc ?

All those exist already. Indeed, other than DataFrames.jl (the pandas equivalent) they are part of the language itself.

Post reply on HN