27:23 I understand this question as is there another way except flatMap to fulfil the monad conditions with lists? Any bind with return should do nothing and any f looking like A -> list(B) should give the same result if instead of calling on A it would be called on return(A) followed by bind(f). It is not easy to come with a working example for lists, and for Maybe there simply no other implementation obiding these rules
I wouldn't say that functional programming concentrates in computing results rather than performing actions, I would say decouples computing results from performing actions, giving a clean semantics to both of them.
The problem of this approach is that arrives too late, arrives when people already did that in those scripting languages, people already had their DSL obsession in Ruby and other scripting languages. Another thing is that the Haskell community have done an amazing job, proving to the entire world with code and not just with talks that types matter and types are an excellent tool to conquer complexity. And this is why TypeScript and Rust have won lots of followers. For instance in the world of the web, Elm is the superior option and is a DSL that abstracts a FRP framework, and is amazing and a lot more helpful and the reason is that it had careful development for years. All languages to be useful rely on tooling to support them, syntax highlighting, style checking, etc. We also come form the massive industry headache with microservices and we have learned the importance of having monoliths and scaling vertically first before considering the possibility of distributed systems. Meaning that we have to use languages that perform faster so we need types for performance as much as types for verification. So this talk sounds obsolete, unless he is willing to do what he doesn't want to do and is to get involved in sophisticated typing with dependent types that help to produce fast performing software because most of the scripting languages perform at 8% of compiled languages like Rust and at 20% of compiled languages like Go.
well, verification and GADTs have proven to conquer complexity and untyped languages like lisp have proven to increment complexity. and I agree that behind every library there is a language that wants to come up, but the way we can make all these language interact successfully for all the goals of software in general and products in particular is with a robust, flexible, powerful and ergonomic Verification system.
At ~@4:00 Aditya is talking about custom visualizers for one's libraries. Around the release of Firefox 4, when some folks who had worked on Firebug were tapped to work on Firefox's new, integrated inspector and other Web Developer tools (ultimately set to displace Firebug itself-which it did-and obviate the need for the older, XUL-based DOM Inspector-which it did not), I had been maintaining the original DOM Inspector, still useful for browser extension developers and people hacking on Firefox's own UI, and I realized based on the way things were going with the work that the new devtools team who'd gotten spliced in were doing, all they were really going to achieve was to pull off Firebug-in-the-browser at best. So I set out at the time to write a replacement for the legacy DOM Inspector that both retained and highlighted some aspects of its architecture that Firebug and its clones lacked. Hewitt had done a really good job at that part, so the inspector's "framework" was basically akin to UNIX pipes, but in graphical form-with pluggable viewers that could take the output of one as the input to another-there just wasn't a lot of obvious visual affordance for it in the UI that made it clear that this was happening under the hood or that you could string them together in sequence to the nth degree (rather than a fixed, two-pane inspector layout, with the document tree on the left and e.g. the CSS viewer on the right). While I was still maintaining the legacy DOM Inspector, I started on a from-scratch rewrite that would also incorporate the sort of Miller columns-inspired design that ultimately ended up in Glamorous Toolkit. That was in 2013, 2014, though-and then the-powers-that-be at Mozilla Corp announced finally that XUL was *definitely* going to go by the wayside as the Firefox product team began chasing Chrome's tail and would implement instead its newer but unfortunately far more limited WebExtension standard. This would have completely killed the ability to install a replacement inspector, so I stopped working on it (and called it quits on my involvement with Mozilla once and for all, which I had been contributing to since 2006). Huge bummer. I'm not saying I need to have been to have done it, but we'd be way better off today (not to mention in the meantime) with an inspector that was designed to embody these principles and fostered the culture that Aditya talks about at the very top of this presentation. And there's no reason it should have needed to be constrained to the browser, either-a general purpose framework for inspecting/debugging any and every application and component on one's desktop at any given moment would have been a huge boon to system introspectability, developer productivity, end-user control, and free/open source software and computing generally. Unfortunately, we just ended up with Firebug-reimplemented-inside-the-browser instead...
It's funny how we fix javascript/typescript issues with tools like ReasonML, ReScript and Elm, but still fallback to use TS because of business decisions that in the end cost millions of dollars
Maybe it is painless later. But to setup Haskell on the computer is excruciating. I could never figure out how to do it correctly. Always a bunch of installation errors. Ghcup, stack, doesn't matter. You will loose hours to make it work for a day. It'll stop working another day and you won't be able to figure out why.
That's some overcomplicated way to tell the associativity of monad's "join" natural transformation property join . fmap join == join . join "join" after "joining" within is the same as "joining" after "joining" from outside
Another cool feature in the finder is search by example. You provide the input parameter values and the expected result value. The finder shows you all methods which pass this test in a second.
programming language people focus on verification because it's the easier problem? not sure if it was a joke but i heard proving incrementing a variable is hard
The category of natural numbers with matrices only seems strange because this underlying structure is hidden: associate each number n with R^n. Then it's also clear why 0 is not allowed. There's no vector space R^0.
R^0 is a perfectly good vector space. It's zero-dimensional, has only one element (zero) and has a basis given by the empty set. (In fact it's a rather important space, being both the initial and terminal object in any category of vector spaces.) I think the only reason zero is excluded in the example brought up in this talk is that we usually don't have empty matrices in mind when we think of matrices. But there's nothing wrong with them, they're certainly useful in programming, and in fact Emily includes zero in her later ACT 2020 talk (ru-vid.com/video/%D0%B2%D0%B8%D0%B4%D0%B5%D0%BE-SsgEvrDFJsM.html).
@@jonathanlong4042 Of course you are right about R^0, 0-dimensional with basis the empty set. Exactly! Maybe I was thinking something else? I will check out your link...
"associative" is easy to motivate: composition is defined for 2 things, and associativity tells you how to compose 3 things. (More precisely, it tells you that the two natural ways are equal).
OO might no longer be the absolute king but putting nails in his coffin and sharpening the guillotine might lead to even harsher a tyranny : evolving towards an OO constitutional monarchy might spare a lot of trouble to the future denizens of software engineering.
