sfvisser

Why does “patent pending” almost automatically sounds like it’s going to be an underwhelming technology.

Humans maybe wrote the code, but not the network of weights on top. And that’s where the magic happens.

Even if we’d understand precisely how every neuron in our brains work at a molecular level there is no reason to believe we’d understand how we think.

We can’t simply reduce one layer into another and expect understanding.

I sometimes wonder if city life used to be more bustling, or if photographers just avoided taking pictures of places without many people.

The past feels so alive!

I use the “HN Dark Mode” add-on set to “auto” so it switches with my OS preferences.

Both on iPhone and Mac.

Then you switch?

My entire OS, most apps and 90% of websites switch automatically with a single keyboard shortcut.

“The Netherlands” isn’t selling anything.

The Dutch national government mandated login system relies on technologies and hosting of a private company that was in conversation with an American counterpart about a possible acquisition.

Bad? Yes

The Netherlands selling their login service? No

I don’t understand this comment, yes everything going over the wire is bits, but both endpoints need to know how to interpret this data, right? Types are a great tool to do this. They can even drive the exact wire protocol, verification of both data and protocol version.

So it’s hard to see how types get in the way instead of being the ultimate toolset for shaping distributed communication protocols.

Reminds me of this classic doing the same: http://blog.sigfpe.com/2006/11/from-l-theorem-to-spreadsheet...

Even if you can reason through a code base a bisect can still be much quicker.

Instead of understanding the code you only need to understand the bug. Much easier!

Don’t know about difficult, but at least less elegant. Lazy evaluation, type inference, abstractions like Functor/Applicative/Alternative/Monad make them so incredibly natural to work with in a language like Haskell. Sure, they exist in other languages (made a few myself) but it’s not the same.

Yes, but that’s exactly what I’m trying to avoid.

We use WASM quite a bit for embedding a ton of Rust code with very company specific domain code into our web frontend. Pretty cool, because now your backend and frontend can share all kinds of logic without endless network calls.

But it’s safe to say that the interaction layer between the two is extremely painful. We have nicely modeled type-safe code in both the Rust and TypeScript world and an extremely janky layer in between. You need a lot of inherently slow and unsafe glue code to make anything work. Part is WASM related, part of it wasm-bindgen. What were they thinking?

I’ve read that WASM isn’t designed with this purpose in mind to go back and forth over the boundary often. That it fits the purpose more of heaving longer running compute in the background and bring over some chunk of data in the end. Why create a generic bytecode execution platform and limit the use case so much? Not everyone is building an in-browser crypto miner.

The whole WASM story is confusing to me.

> Like it or not, we are already serving the machines.

The machines don’t give a shit, it’s the lawyers and bureaucrats you’re serving :)

Better or worse?

Exactly right. Better have a domain layer with data types representing the domain object 1:1 and add one or more API layers on top for interacting with those for some modality. Creation, deletion, verification, auth etc.

The security failure is not the parsing library, but failing to model your application architecture properly.

This comment would have been more useful with some qualification of why that’s the case. The language, tooling, library ecosystem? Something else?

Really depends on your intent. Ideally code has meaning that reflects your problem domain and not just what happens to work at the moment.

Code that just works right now never scales.

You probably know answer and just hyperboling here, but there are plenty of reasons to raise as a startup. Even in pure software.

Most obvious one is you’re building something actually technically challenging and need to grow your team to get there. People, especially great people, are bloody expensive. No way to afford any reasonable headcount as a 22yo first time founder without venture money.

Of course, simple ideas are easy and need less resources and might be bootstrapped, hard ideas less so.

Isn’t the point of most carbon capture schemes to use renewables (likely solar) as the energy source. Like Terraform Industries?

Don’t know if it will work or is economically viable, but sounds pretty win-win to me.

Note that deriving Traversable for you own datatypes mean changing the structure to map effect over, the `t` variable. Not the effect `f`, which is generic and the Monad/Applicative in this case.

Besides Maybe/Either `t` could represent anything, like container types Lists/Trees/Hashmaps etc, but also more complicated structures like syntax trees for programming languages or custom DSLs. Or (my favorite use case!) recursive command types for robot control. I'm doing this mostly in Rust, but borrow all the ideas from Haskell.

They’re first class in the sense that they can be described, stored, computed, separated etc from pure functions. Fair to call them first class.

Correct! I simply copied the definition from the type class, but the context is important.

The generalized version of ‘traverse/mapM’ that doesn’t just work for lists, but any ‘Traversable’ type is absolutely amazing and is useful in so many cases.

‘traverse :: Applicative f => (a -> f b) -> t a -> f (t b)’

And you can derive it for free for your own datatypes!

The amount of code I’ve manually written in other languages to get a similar effect is painfully large.

> Have you noticed how in second 13 it rotates the lower body clockwise while the upper body rotates counter-clockwise in order to optimize the movements to archive the goal?

Could be a fancy optimization of course, but could as well be a side effect of a decoupled planning of the locomotion part and the upper body pick and place.

Algo could be: plan a path for a lower body motion from pose (4dof) A to pose B. And given pose B plan the upper body place of the tray in the target. If no constraints are broken plan both in parallel so it looks like one smooth behavior.

Obviously, I don’t know :)

Don’t ever use attacker controlled data directly in your source code without validation. Don’t blame setTimeout for this, it’s impolite!

Isn’t the argument that by checking for NULL you can now safely crash/panic instead of going into undefined behavior and being a potential security hazard?

This one feels more apt to me: the derivation of a single lambda calculus term in which you can express all other expressions.

> The systematic construction of a one-combinator basis

https://citeseerx.ist.psu.edu/document?repid=rep1&type=pdf&d...

The article clearly states why not: first you probably screw up your data (example is names, but there are many more examples) and second what is garbage depends on your output usage. Html/sql/JSON/etc all require a different sanitization.

It’s really not. The point is that sanitizing output is a better way to protect the host and the client.

Agreed, properly modeling domain knowledge without types for example feels insurmountable to me. Maybe there exist a category of programmer who can do this, but why make programming more difficult than it already is.

Yes, incredibly difficult. Nearing 20 years in the field now and programming is still as difficult as in at the start. Or maybe more so, because you are so aware things will break on the first try anyways. Always.

Most important lesson for me is to stay close to the problem domain. Think deeply about what your domain means and model in code accordingly.

Staying close to the true meaning of your application beats all other attempts at code maintainability. Types, tests, frameworks, dry, language features, ci pipelines, scrum whatnot. All just fun party tricks that fall short when your building the wrong thing.

Are we building the wrong thing? Almost always.