sfvisser

Implemented this manually so many times that I’m almost annoyed that this works out of the box with CSS now.

Great to see this now works. Input and textarea sizing is still a mysterious black art to me though.

If you like this kind of pattern you might want to read up on Haskell’s GADTs. Generalized algebraic data-types.

This is where you can index the different constructors (enum variants) with an additional type variables and even specialize them when needed. A pretty powerful tool to encode at the type level that similar things are slightly different.

> It's just not very high on the list at all.

Maybe not for lawyers, no. But as a citizen I'm expected to comply with the law, with many many laws. It'd actually be nice if law was slightly more formally verifiable, so it would be easier for me to understand what to comply with.

Being able to break down clauses into more logical normal forms would probably greatly enhance the possibility of compliance.

Got it. Maybe I always naively assumed there is some shallow FFI layer and all the heavy lifting is done by some set of core standard libraries. Ideally portable to multiple environments.

> Deno is a simple, modern and secure runtime for JavaScript and TypeScript that uses V8 and is built in Rust.

Still don’t fully understand what ‘runtime’ means in this context. It’s not the parser, interpreter, VM, GC I think, because that is the V8 part. It’s not a runtime compiled into an executable like Haskell or Go.

Is it the term used here for a set of standard libraries? Or maybe in interaction layer with the operating system underneath, or the package/build system? Or an umbrella term for all of this?

I’ve been doing all kinds of JavaScript and TypeScript for a long time now without a runtime (I think) so pretty curious.

Starting homeowners who might want to move into a bigger home do want prices to fall as well. The loss in return of your current home is being royally offset by reduction in price when buying.

This is where you start explaining how trees capture carbon, how much, and where it is stored. Explain how we use trees in large quantities to reduce CO2 in the atmosphere, where and how many? Who should do this and who is going to pay for it? Genuinely curious.

But without those details your comment is just a poor quality and lazy attempt to disqualify people who are actually trying something.

React went from class components to function components and from lifetime callbacks to hooks. These concepts are completely orthogonal.

There exist design choices that would end up with a different combo. Class components with hooks or function components using lifetime callbacks.

Yes, hooks — basically sub components with possible effects and yielding values, or DOM output — are a terrific idea and much more functional and principled than explicit lifetime callbacks.

All the dependency arrays and non-conditional checks etc are because of the function components approach and don’t have much to do with hooks.

I feel nearly every discussion on hooks mixes this up and makes the whole conversation just weird and confusing.

> Deriving it instead of naming and explaining it will make it harder to understand any code using the derivation because you can’t look up what Promise.all does. If the code and explanation is written in terms of Arbitrary instead of Future then the explanation will be difficult to write and difficult to read.

To the contrary! Because I’ve already used that function (traverse) a million times and know exactly how to write it myself I understand exactly what it does without any knowledge about the details of your Future or Optional or whatever. True and meaningful abstraction. Which is truly an amazing super power!

> We've been improving our CO2 models for over a century now, and in recent decades the modelling has been extremely good - although if anything it's been too optimistic.

If the models are too optimistic, that still means they are wrong, right? Genuinely confused about this.

“The situation today is more dire than our previous models predict and the same models predict an even worse future so we need to take them extra seriously” doesn’t strike me as very reasonable. Not in a super non-linear system with tons of complicated feedback loops.

Any pointers to in-depth explanations of how these models work and how they are benchmarked? Definitely want to learn more.

I highly doubt many proponents of geoengineering think in terms of rebooting or isolating individual factors.

The appeal of geoengineering is you can nudge specific systems slowly into another direction. You can start small and observe expected effects and unwanted side-effects.

Reduction of sulfer emissions by ships is an interesting starting point to learn something.

I get the argument that fully custom scroll bars aren’t great for accessibility in many cases. However, the default behavior out of the browser or OS is pretty terrible in many cases as well.

Scroll bars popping in and out of existence awkwardly reflowing elements around it. Tiny unusable 30px wide horizontal scroll bars inside an input element because an element overflows 0.7px due to font size rounding issues or what not.

Default scroll bars are great for documents, but pretty terrible mostly for slightly more complicated UIs where a lot of info is displayed in small area.

You might not want them in your team maybe, but isn’t it really cool we reached a state where you can actually do this? Democratization of software engineering is a great good!

Haskell and JavaScript and the majority of humans call these things functions. That there exist a different context (a very specific academic context) where these terms have a slightly different technical meaning is completely irrelevant in the context of a normal user-level discussion on about programming languages.

> Functions do not capture environments.

They might not do that in Rust, they do in Haskell, JavaScript and plenty of others.

In some language all functions capture their environment, making that original statement more true than you make it out to be.

Personally I think the term closure should be banned, because it only adds confusion.

There are just functions, some named some anonymous, some capturing the environment, some not, some being disallowed by some constraints from the host language. The term closure cuts through this space in a useless and rather ad-hoc way.

And save every generated password for later use. Nice

Reminds me of the online bitcoin wallet public key QR code generator that just generated a code for some attacker’s wallet and got themselves some free coins.

Couldn’t quickly find it, but does it support enums/sum types?

Agreed.

I’m not a biologist, but I always assumed the self similarity of plants and trees is definitely some recursive process with some boundary conditions or external constraints as an implicit parametrization. Which is very similar to how you can describe (some) fractals.

It feels very unlikely to me that the tree dna for thick branches is completely different from that for thin twigs.

That’s a very pretty house! What country do you live if I can ask and is this a common theme?

Really strong language without any backing arguments whatsoever. You can’t just pick some random tech and decide this is boring tech so it’s good and so the other is bad and has always been. This type of comment is so incredibly meaningless and infuriating.

Please explain why you are saying what you’re saying so at least we can learn from it.

Looks great! Just high level enough for me to understand and easily readable.

Haskell style pure functions are a natural fit for shaders that are side effect free by design. Wonder how far you can go with abstractions like applicative functors for generic vector math etc. Could be quite powerful and when properly inlined without any perf hit.

We’re using something similar(ish) internally and it’s interesting how much more readable and expressive JSON can get by allowing Rust style constructors/tags for your data types.

Suddenly sum types become conveniently easy to express and understand, which is always incredibly awkward in JSON.

Besides that: tuples, tuple structs, comments, properly handling NaN, optional.

Really hope something like this takes over the role of JSON/yaml soon.

I don’t think it’s super relevant for the challenge to be similar to the day job challenges. Maybe it’s even unclear what those are at the point of interviewing.

What is important is that the candidate’s skills generalize well to both the challenge in the interview as well as the day job. A question like this might be a good indicator or not depending on the job.

If people completely fail at this question it can reveal a lot of relevant information.

This sounds very interesting! If you ever figure out how it came to that conclusion, that would deserve some write up.

Creating new knowledge would be good start yes. Observe a problem, state some conjectures, try falsifying, and come up with good explanations. Repeat this to learn and update knowledge over time. If that process works it is hard to see what else is left.

> I own several buildings

> expense in the low five figures

> So what are people complaining about, exactly?

This is an incredible take.

Many people don’t have the luxury to just spend five figures on a mandatory house renovation.

> Lazy evaluation increases mental burden.

In some situations, definitely! In other situations, definitely not!

My experience with writing Haskell application code is that you’re thinking way less about the runtime operational aspect of your code than in any other language. The burden is much lower.

The exceptions are possibly when writing low level library code that involves a lot of IO and steaming. Or when storing a lot of data in-memory for longer periods of time.

Yes, the GC helps tremendously here of course.

I guess laziness helps mostly by not dictating the granularity in which to expose both data and building blocks. You can expose more than strictly needed and consumers just pick what’s relevant.

Keeping APIs simple and to the point.

My biggest observation from switching from Haskell to Rust is the change in thinking in terms of program composition.

In Rust you need to really make some careful design choices in your producer/library code depending on the expected use. All of them quite on the operational level and not really semantically. So many internal choices about refs/arcs/pins/mut/ownership leak out.

In Haskell you don’t really do that. If your library internals are neatly written combinators with the right type and semantics you can just expose them and you’re done. Like the article explains, laziness is a big part of this.

I understand where that difference comes from, but it’s really a very different way of thinking.