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

Generalizing 'jq' and Traversal Systems using optics and standard monads

chrispenner.ca

Post reply on HN
Print view View original

81–90 of 102 posts

Re: Generalizing 'jq' and Traversal Systems using optics and standard monads

#81

Post by tome »

whateveracct wrote: post #80
formerly_proven wrote: post #44

Earlier quoted context omitted.

They're practically useless for searching for them. Unsurprisingly trying to co-opt widely used terms tends to be ambiguous and confusing (cf. crypto cryptography, cryptocurrency, and those are at least related). Perhaps the only exception in this group is "data lens", which works as a compound [1]. Guess what optics software does? No ETL, that's for sure. Optics patterns? Uh-oh. Optics development? Nuh-uh. Optics da…

Try searching "optics Haskell" https://www.google.com/search?source=hp&ei=mL5-X7iCJNCs0PEPo... First result is to the popular and well-documented `optics` library which is exactly this topic. It's perfectly discoverable. On that note, try googling "Haskell >>=" or "Haskell ". Good results for both. Looks like the "Haskell's symbols and esoterica isn't googlable" is a dead argument now :)

> On that note, try googling "Haskell >>=" or "Haskell ". Good results for both. Looks like the "Haskell's symbols and esoterica isn't googlable" is a dead argument now :)

Wow, it works! I wonder when this happened.

Re: Generalizing 'jq' and Traversal Systems using optics and standard monads

#82

Post by 082349872349872 »

mongol wrote: post #68
Daishiman wrote: post #2

Optics, as the OP calls it, is definitely an underestimated problem of modern computing. So much work goes in most languages into processing nested data structures, especially in this day and age of heterogeneous APIs, and a lot of it is actually not that difficult to generalize conceptually into most languages. A few weeks ago I wrote a PoC in Python and it was remarkably easy to make a lens for traversing data stru…

Is using the word optics for other things than projecting light with glass a new thing? I do not recall seeing this word used for other purposes much say 10-15 years ago. Not a native English speaker but have read English for at least 30 years.

The earliest Newton reference of which I am aware is Functional Programming with Bananas, Lenses, Envelopes and Barbed Wire (1991), where iirc both the bananas and the lenses are (visually!) optical.

https://research.utwente.nl/en/publications/functional-progr...

In particular, the metaphor isn't used in Algorithmics: Towards Programming as a Mathematical Activity (1986).

https://ir.cwi.nl/pub/2686

Re: Generalizing 'jq' and Traversal Systems using optics and standard monads

#83

Post by 082349872349872 »

benrbray wrote: post #7

This is a really exciting area. See also the Cambria project [1] and the HN discussion from yesterday [2]. See [3,4] for a great introduction to category theory for programmers--we are all indebted to Milewski / Fong / Spivak / et al. for making this topic more accessible. [1] https://www.inkandswitch.com/cambria.html [2] https://news.ycombinator.com/item?id=24699615 [3] https://bartoszmilewski.com/2014/10/28/categor…

So, how does Cambria differ from XSLT?

For anyone interested in computing pre-history, early twentieth century punched-card processing, before von Neumann, was all about taking (monoidal) data structures (encoded as a deck of cards) with historical values and either querying them or running updates (encoded as a second deck of cards) to produce freshly copied current values.

https://en.wikipedia.org/wiki/Unit_record_equipment

Re: Generalizing 'jq' and Traversal Systems using optics and standard monads

#84

Post by MrBuddyCasino »

rrdharan wrote: post #47
vortico wrote: post #13

Earlier quoted context omitted.

Maybe so, but much easier to read . Code is read 10x more often than written, especially in teams, so it makes sense to optimize for legibility rather than elegance in some "higher" mindset, or less keys pressed (because most of the time will be spent staring at the line you wrote than actually typing if you write a functional line like that.)

Forget it, Jake. It’s Chinatown.

Underrated comment.

Re: Generalizing 'jq' and Traversal Systems using optics and standard monads

#85

Post by rainsil »

082349872349872 wrote: post #82
mongol wrote: post #68

Earlier quoted context omitted.

Is using the word optics for other things than projecting light with glass a new thing? I do not recall seeing this word used for other purposes much say 10-15 years ago. Not a native English speaker but have read English for at least 30 years.

The earliest Newton reference of which I am aware is Functional Programming with Bananas, Lenses, Envelopes and Barbed Wire (1991), where iirc both the bananas and the lenses are (visually!) optical. https://research.utwente.nl/en/publications/functional-progr... In particular, the metaphor isn't used in Algorithmics: Towards Programming as a Mathematical Activity (1986). https://ir.cwi.nl/pub/2686

I believe the concepts in the first paper are unrelated to those of modern lenses (i.e. functional references). See: https://stackoverflow.com/questions/17198072/how-is-anamorph...

Re: Generalizing 'jq' and Traversal Systems using optics and standard monads

#86

Post by nindalf »

synthc wrote: post #36
choeger wrote: post #22

Earlier quoted context omitted.

Your code is impossible to analyze. Console.log is a side effect. For loops can be easily mapped into functional constructs, but not your snipped does not compute anything. It's not a function.

Don't be pedantic, this is super simple code that is easy to analyze. Side-effects are not the terror that haskell programmers make of it.

A better reading of his comment is this. You can analyze side effects easily in a small function or system. Not so easily in a large system. That's why it's better to avoid side effects.

Re: Generalizing 'jq' and Traversal Systems using optics and standard monads

#87

Post by scns »

warkdarrior wrote: post #4
Daishiman wrote: post #2

Optics, as the OP calls it, is definitely an underestimated problem of modern computing. So much work goes in most languages into processing nested data structures, especially in this day and age of heterogeneous APIs, and a lot of it is actually not that difficult to generalize conceptually into most languages. A few weeks ago I wrote a PoC in Python and it was remarkably easy to make a lens for traversing data stru…

I wonder how these "optics" compare to .NET's Language Integrated Queries (LINQ) (see https://en.wikipedia.org/wiki/Language_Integrated_Query )

You are onto something, since LINQ was developed by Erik Meijer, one of the authors of the paper linked in the childcomment of the siblingcomment.

Re: Generalizing 'jq' and Traversal Systems using optics and standard monads

#88

Post by mpweiher »

imoverclocked wrote: post #46
synthc wrote: post #36

Earlier quoted context omitted.

Don't be pedantic, this is super simple code that is easy to analyze. Side-effects are not the terror that haskell programmers make of it.

After working on and maintaining several very large codebases, I would strongly disagree. When large blocks of code start being called only for their side-effects then refactoring/deleting old code gets pretty tricky. Conversely, when writing green-fields code, side effects are extremely convenient and make developers more productive in the very short-term.

(Side) effects are the reason you write code in the first place.

So I'd agree that focusing on the reason you are writing the code makes everyone more productive, though not just in the short term. ¯\_(ツ)_/¯

Now how you organize your code so that you don't mix things up willy-nilly is a different, more nuanced and, I think, more interesting question.

I am a big fan of hexagonal architecture, where you have a very localized and super-testable core with, ideally, all the complex functionality, surrounded by adapters that are as trivial as possible and communicate with the outside world, be that the user, persistence, network etc.

FP is one way of achieving this, but certainly not the only one.

Re: Generalizing 'jq' and Traversal Systems using optics and standard monads

#90

Post by chrisshroba »

dragonwriter wrote: post #30
vortico wrote: post #26

Earlier quoted context omitted.

Oh, you mean using analyzing software. Yeah, I've never had a use for that. On the other hand, you could make my function append to a string and then return the string. Then it wouldn't have side effects so it would be analyzable.

> On the other hand, you could make my function append to a string and then return the string. Then it wouldn't have side effects State mutation is a side effect. If you mean it builds it up locally, it would then not have nonlocal side effects (e.g., it would have a pure functional interface even though it has an imperative implementation). But to do that, you'd have construction and mutation overhead in the code, w…

(I'm new to FP so excuse this beginner question) How could you ever (in a non-trivial case) avoid local state mutation? It seems like any function which takes a collection and returns a collection would have to maintain some local state.

For example, if you want to take a list of integers and return a list of those those integers plus one ([1,2,3] -> [2,3,4]), that new list needs to be built up in memory somehow before it is returned, no? Sure that process might be hidden behind a generic `map` function (something like `map(lambda x:x+1, [1,2,3])`), lambda, but then you just have the `map` function building up the new list. Or if `map` returns a generator (so you don't need to construct the whole return list first), you're still storing some local state to keep track of which element of the input list you're currently processing.

What am I missing or getting wrong here?

Post reply on HN