Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Lenses in Julia

juliaobjects.github.io

Post reply on HN
Print view View original

61–68 of 68 posts

Re: Lenses in Julia

#61

Post by electroly »

WorldMaker wrote: post #60
electroly wrote: post #58

Earlier quoted context omitted.

My language doesn't have any other kind; it's not immutable by default , it's immutable only . There are no mutable types or reference semantics, so there's no other kind of type that I need to differentiate. That's my question--why haven't other languages taken this approach? Many newer languages today are full-throated defenses of immutable data structures--why do they still make the mutable structures the easiest,…

> But experienced designers don't, presumably because it's a bad idea, and I don't understand what the badness is. I don't think it's a bad idea, and I don't see anyone else saying that. I did try to give you a couple practical considerations, but I don't think they stop your idea for a toy language from existing or suggest anything you are trying to do is "bad". > We don't want add() and subtract() when we have + an…

Oh, I meant that I suspect it's a bad idea. I've got a gut feeling that I can't put my finger on. I implemented it anyway because my language's design "pointed" in that direction based on prior decisions I had made (re: not having any reference semantics), but I can't shake the feeling that I've created something internally consistent but confusing to people trying to learn it. Or that it will hit a wall at some point and I'll suddenly realize why this is not done. I'll have to think about it some more. Thanks for the discussion!

Re: Lenses in Julia

#62

Post by [deleted] »

electroly wrote: post #58
WorldMaker wrote: post #53

Earlier quoted context omitted.

One of the reasons functional languages like to make mutable code look very different from immutable code is to try to make it clear which is which when reading the code, to help avoid mistakes. > Is it so offensive that the syntax `obj.a = 2` ends up rebinding `obj` itself? That does imply that the `obj` binding itself is mutable, so if you are trying for entirely immutable data structures (by default), you do proba…

My language doesn't have any other kind; it's not immutable by default , it's immutable only . There are no mutable types or reference semantics, so there's no other kind of type that I need to differentiate. That's my question--why haven't other languages taken this approach? Many newer languages today are full-throated defenses of immutable data structures--why do they still make the mutable structures the easiest,…

[deleted]

Re: Lenses in Julia

#63

Post by WorldMaker »

electroly wrote: post #61
WorldMaker wrote: post #60

Earlier quoted context omitted.

> But experienced designers don't, presumably because it's a bad idea, and I don't understand what the badness is. I don't think it's a bad idea, and I don't see anyone else saying that. I did try to give you a couple practical considerations, but I don't think they stop your idea for a toy language from existing or suggest anything you are trying to do is "bad". > We don't want add() and subtract() when we have + an…

Oh, I meant that I suspect it's a bad idea. I've got a gut feeling that I can't put my finger on. I implemented it anyway because my language's design "pointed" in that direction based on prior decisions I had made (re: not having any reference semantics), but I can't shake the feeling that I've created something internally consistent but confusing to people trying to learn it. Or that it will hit a wall at some poin…

Ah, that makes sense. I went on to a longer length on that, but apparently my browser accidentally posted a partially complete draft.

Hopefully the remainder post adds additional perspective.

Re: Lenses in Julia

#64

Post by DNF2 »

electroly wrote: post #58
WorldMaker wrote: post #53

Earlier quoted context omitted.

One of the reasons functional languages like to make mutable code look very different from immutable code is to try to make it clear which is which when reading the code, to help avoid mistakes. > Is it so offensive that the syntax `obj.a = 2` ends up rebinding `obj` itself? That does imply that the `obj` binding itself is mutable, so if you are trying for entirely immutable data structures (by default), you do proba…

My language doesn't have any other kind; it's not immutable by default , it's immutable only . There are no mutable types or reference semantics, so there's no other kind of type that I need to differentiate. That's my question--why haven't other languages taken this approach? Many newer languages today are full-throated defenses of immutable data structures--why do they still make the mutable structures the easiest,…

> Julia is fastest with immutable structures--why provide a built-in syntax for complex assignment to mutable types, but then relegate lenses to a library that only FP aficionados will use?

This is not really accurate. Performance in Julia is heavily organized around mutability, in particular for arrays. The main reason Julia does not fully embrace immutability for everything is, simply, performance.

Re: Lenses in Julia

#65

Post by electroly »

DNF2 wrote: post #64
electroly wrote: post #58

Earlier quoted context omitted.

My language doesn't have any other kind; it's not immutable by default , it's immutable only . There are no mutable types or reference semantics, so there's no other kind of type that I need to differentiate. That's my question--why haven't other languages taken this approach? Many newer languages today are full-throated defenses of immutable data structures--why do they still make the mutable structures the easiest,…

> Julia is fastest with immutable structures--why provide a built-in syntax for complex assignment to mutable types, but then relegate lenses to a library that only FP aficionados will use? This is not really accurate. Performance in Julia is heavily organized around mutability , in particular for arrays. The main reason Julia does not fully embrace immutability for everything is, simply, performance.

There is some discussion about this from smarter people than me over here (same thread): https://news.ycombinator.com/item?id=45769149

> Counterintuitively Julia recommends the use of immutable data types for performance reasons...

Those folks are likely more able to respond to your counterclaim than me.

Re: Lenses in Julia

#66

Post by Darmani »

JanisErdmanis wrote: post #46
Darmani wrote: post #23

Earlier quoted context omitted.

I've worked in about 40 languages and have a Ph. D. in the subject. Every language has problems, some I like, some I'm not fond of There is only one language that I have an active hatred for, and that is Julia. Imagine you try to move a definition from one file to another. Sounds like a trivial piece of organization, right? In Julia, this is a hard problem, and you can wind up getting crashes deep in someone else's c…

It is discouraged to override internal internal functions, hence, one often only needs to monitor the public API changes of packages as in every other programming language. Updates for packages in my experience rarely had broke stuff like that. Updates in Base somrimes can cause issues like that, but those are thoroughly tested on most popular registered packages before a new Julia version is released. Interfaces cou…

So

In Julia, the (+) function is commonly overloaded

The [] is as well. For things that have no shared interface. (E.g.: Int64[1][1] contains two calls to the [] generic function, which have no interface in common.)

Plenty of definitions of (+) are not commutative. E.g.: for strings.

There is some package which uses the (+) generic function internally, meant to be used on numbers. You call it instead with some kind of symbolic expression type. And it just works. Yay! This is the kind of stuff Julia afficcionados preach.

Then suddenly the package gets updated so that it uses (+) in a way which assumes commutativity.

Your code breaks.

In your world, how would you be notified of a change that some internal use of the (+) function now assumes commutativity?

Or when Julia afficionados preach the amazingness of being able to just throw a differential operator or matrix or symbolic whatever in a place, are they just overselling something and should stop?

Re: Lenses in Julia

#67

Post by Darmani »

dandanua wrote: post #29
Darmani wrote: post #23

Earlier quoted context omitted.

I've worked in about 40 languages and have a Ph. D. in the subject. Every language has problems, some I like, some I'm not fond of There is only one language that I have an active hatred for, and that is Julia. Imagine you try to move a definition from one file to another. Sounds like a trivial piece of organization, right? In Julia, this is a hard problem, and you can wind up getting crashes deep in someone else's c…

I don't quite understand what your issues were, I don't have any with the current module system https://docs.julialang.org/en/v1/manual/modules/ Can you provide some concrete examples of that issues existing today?

I had a quick skim of the link you gave -- it looks to be the same as it was 6 years ago when I experienced this issue.

So basically:

Generic function F is defined in file A, and has a method definition DEF in file B.

File C imports files A and B, and then calls function G that internally uses generic function F. Somewhere internally, it winds up running F with method definition DEF.

You move DEF to file D, but don't update the imports of file B.

When file B calls G, it calls F with some default implementation instead of DEF, and then you get an error from function G.

Some details here might be wrong over how exactly to imports need to be set up, as I haven't used Julia being traumatized by it 6 years ago, but that's basically it.

Re: Lenses in Julia

#68

Post by dandanua »

Darmani wrote: post #67
dandanua wrote: post #29

Earlier quoted context omitted.

I don't quite understand what your issues were, I don't have any with the current module system https://docs.julialang.org/en/v1/manual/modules/ Can you provide some concrete examples of that issues existing today?

I had a quick skim of the link you gave -- it looks to be the same as it was 6 years ago when I experienced this issue. So basically: Generic function F is defined in file A, and has a method definition DEF in file B. File C imports files A and B, and then calls function G that internally uses generic function F. Somewhere internally, it winds up running F with method definition DEF. You move DEF to file D, but don't…

Well, with generic programming constructs you have more freedom, and with more freedom you have more ways to shoot yourself in the foot. I don't think Julia has some illogical or inconsistent design decisions of its module system. In fact, it's better than many other because the order in which you import modules doesn't matter.
Post reply on HN