@iwikal

> react dev here: the mantra, [that UI = f(state) ] is repeated a lot in talks from the maintainers and official advocates at conferences and tutorials and stuff.

Thanks, that's exactly what I was looking for. Do you happen to know of a specific example that I could link to in a blog post? I was looking, and all I seem to be finding are mention in third-party guides — but I'd love to have something like you mentioned instead

@sotolf

> Isn't that just a normal FRP tagline?

Yeah, it is. But React _isn't_ really FRP, and usually doesn't really claim to be. But I thought they *did* claim to support the `UI = f(state)` model, which is why I was surprised when I couldn't find any official-ish source making that claim.

@starbreaker

> My understanding is that React doesn't deal with state on its own. Instead, you've got to use Redux with React if you want to handle state client-side.

I'm not primarily a JS dev, but my understanding is that was considered best practice circa ~2017 (aka, ancient history for JS devs :( …) but that since then, React has come out with "context" and "hooks", which have both made state-management without an external lib. much more popular.

Random source: dev.to/asayerio_techblog/is-re

question to those of you who've followed webdev for a while:

Where did the association between and the phrase "UI is a function of state" come from? It's something I've heard a lot (and that shows up in a lot of blog posts, etc.). I'd kind of thought of it as React's tagline, in fact.

But, to my surprise, that claim doesn't seem to show up in the official docs. Do you know when it started to be associated with React? Was it once listed in the docs and then removed?

@Steinar

> I've never seen a single instance of dynamic scoping where it actually was a good idea

I've seen several (though they're the distinct minority).

Off the top of my head, they're a key part of how emacs can be so extensible, as Stallman described 30 years ago: gnu.org/software/emacs/emacs-p

Raku APIs also make good use of dynamic scoping when wrapping functions without changing their signature (these dynamic variables aren't exposed to the API's user). e.g.: fosdem.org/2021/schedule/event

I might should slightly walk back ^^^ I do think that many of the practices of "modern" web-dev are ignorant re-inventions of previous solutions (we all need more history!), this one seems to have been an *intentional* re-implementation (much better!):

> In React, this is solved by Context. It is essentially like dynamic scoping for components. It’s like a wormhole that lets you put something on the top, and have every child at the bottom be able to read it

overreacted.io/react-as-a-ui-r

Show thread

A few weeks ago, I asked:

> Many programming languages have syntax that means "everything from this token until the end of the line is a comment" (e.g., // in C-family, ; in Lisp family, # in shell family)
>
> Do any have syntax for "everything from this token until the end of the line is a string"?
>
> Why isn't that a common thing to have? It strikes me as something that'd be *super* handy

I just learned that has pretty much *exactly* the syntax I wanted! ziglang.org/documentation/mast

Show thread

It recently occurred to me, relatively unprompted, that many of the state management patterns in "modern" "react-ish" webdev are just re-implementations of dynamic scope – with the same advantages and disadvantages dynamic scope has had for the past ~60 years that it's been in use.

(Of course, after noticing this, I checked, and pointing out how not-new this pattern is… is itself not at all new: spin.atomicobject.com/2020/04/ We sure do love reinventing wheels!)

There's a very deep satisfaction in using a tool that I built. it's got all the parts I think are important, and none of the other stuff. I'd like to make more tools like this. the next step will be figuring out the simplest way to deploy these!

Show thread

Spoiliers for a ~decade old conference talk 

I just watched Gary Bernhardt's 2012 talk, A Whole New World, which has the gimmick of him pretending to have written a text editor and terminal emulator – and then revealing the trick to make the point of how surprising it'd be if he'd actually done so, because no one goes that deep.

From here in 2021, though, I was thinking "oh, _another_ terminal?" Like kitty/hyper/alacritty/zutty…

Does that reflect a large sea change since 2012, or a coincidence?

I'm working with some code where a function takes a `date` parameter, and if no date is provided, calls Date.today _in the default argument constructor_.

The functional programmer in me finds that absolutely horrifying.

I'm not sure why calling an impure function in the argument constructor bothers me so much more than calling it in the body of the function would – but it sure does!

@tequillaThirst @asterope

Also, if your comment that

> APL is an underrated gem

wasn't a reference to the classic comparison between Lisp and APL, it really should have been!

> APL is like a beautiful diamond – flawless, beautifully symmetrical. But you can't add anything to it. If you try to glue on another diamond, you don't get a bigger diamond. Lisp is like a ball of mud. Add more and it's still a ball of mud – it still looks like Lisp.

en.wikipedia.org/wiki/Big_ball

@tequillaThirst @asterope

> APL is an underrated gem

Strong agree. In fact, despite my commitment to free software, I came within a hair of seriously committing to programming in Dyalog APL (a proprietary language) because it's just that good.

(But then I discovered which – despite taking a vastly different approach – gives me much of what I loved about APL while also being *extremely* open source)

@pettter

> As for the pipeline model, that's arguably how a lot of functional languages are written (f . g . h(x))

Yeah, that's the sort of thing I was thinking of. Because that model loses some of it's left-to-right flow as the function names grow beyond one letter.

You end up with something like

some_list.map(|a_mapper|)
.filter(|filter_fn|)
.sort(|sort_fn|)

Which is still ok – good, even! – but not as left-to-right anymore

In every programming language I've ever heard of, program control flows left→right and then top→bottom. That is, this psudo code:

{ print "1" } { print "a" }
{ print "2" } { print "b" }
{ print "3" } { print "c" }

would print 1a2b3c

Are there any languages (even eso-langs/DSLs) that invert that order, so that the above would print 123abc?

It occurs to me that a left-to-right control flow would be a good fit for a lot of "pipeline" type data work, and I'm curious if anyone has tried it

For those of you with functional-programming sympathies, what are your thoughts on environmental variables? Do you think they make an otherwise pure function impure?

I'm torn. On the one hand, if a fn is a pure mapping from input => output, it seems pure regardless of how it reads the input. `FOO=1 cmd --bar=2` seems identical `cmd --foo=1 --bar=2`

On the other hand, referential transparency *usually* means being able to reason about a fn from the callsite. And env. vars lose that.

Hmm…

@mcol

> Why not the inverse: why do so few languages allow for middle-of-a-line comment?

I mean, not _that_ few: most C-family languages have
/* comments */, which work fine for middle-of-the-line comments (even if they're often called multiline comments)

@tewha

> Not all languages, of course. But usually these language features are copied from someone else.

Yeah, I bet that's it. Come on, language designers, show some creativity!

@fedops

> here-documents in the sh family.

Sort of, but not really. That's actually what got me thinking about this: a heredoc like

cat << EOF
"He's a zany fellow!"
EOF

takes 3 lines, which is a lot of verbosity for a one-line string. And I started thinking "shame I can't just have a newline as the delimiter", which led to the OP.

(Well, except that I was writing , not shell, so the heredoc I was using has some superpowers, docs.raku.org/language/quoting But it still needs a delimiter!)

Show older
Fosstodon

Fosstodon is an English speaking Mastodon instance that is open to anyone who is interested in technology; particularly free & open source software.