mightybyte

Never underestimate the capacity of poor management for screwing things up.

My take on this was The Monad Challenges (https://mightybyte.github.io/monad-challenges/), which attempt to provide a guided map through the grind of developing your own intuition about monads. Credit to the matasano crypto challenges for the inspiration.

I really like this talk on the topic called "Stop Treading Water: Learning to Learn":

https://www.youtube.com/watch?v=Z8KcCU-p8QA

Did you mean "neophobes"?

Ever heard of planted evidence?

One is matching a face--yes, concerning, and I don't like it but IMO Google has had a much worse privacy reputation for quite some time--and the other is reporting private data to law enforcement and potentially abusive parents. It's quite a bit different.

The difference can also be seen from a customer service perspective. One is a feature that lets you sort according to which friends you were with. The other is a feature that puts you in jail. No thanks. Not gonna pay money for that.

> ON YOUR DEVICE (where it's encrypted in a way that Apple can't read until the 30 image threshold is crossed)

First of all, you have to be able to read it to do the comparison that can increment the counter to 30. So regardless of whether it is or is not encrypted there, they're accessing the unencrypted plaintext to calculate the hash.

And yes, on my device is definitively more private than on someone else's server--just like in my bedside drawer is more private than in an office I rent in a co-working space.

This is the same company that saved the disk encryption password as the password hint. You really trust them to not screw this up when the stakes are that it could ruin your life and/or land you in jail? I'm simply not ok with that.

I think the difference here is that it's ON YOUR DEVICE. I think there's a pretty clear understanding that if you upload stuff to a cloud provider they can do whatever they want with it. This is different. This is reaching into what has up until now mostly been considered a private place. Law enforcement often has to get warrants to search this kind of thing.

This is the difference between putting CSAM on a sign in your front yard (maybe not quite front yard but I can't come up with quite the same physical equivalent to a cloud provider) and keeping it in a password protected vault in your basement. One of those things is protected in the U.S. by laws against unlawful search and seizure. Cloud and on your device are two very different things and consumers are right to be alarmed.

I'll say it again, if you are concerned with this privacy violation, sell your Apple stock and categorically refuse to purchase Apple devices. Also go to https://www.nospyphone.com/ and make your voice heard there.

Vote with your money. If you own AAPL stock, sell it. And loudly refuse to buy Apple devices. That is the only language organizations like this will understand.

Oh the irony...

https://www.youtube.com/watch?v=VtvjbmoDx-I

I had already decided to switch back to Linux. I was planning on continuing to use an iPhone but after the news stories of the past week I might even ditch the iPhone too.

The point would be to provide a more legitimate USD stablecoin in a space that seems to be attracting a growing user base (blockchains). I imagine a significant share of the market would choose the Fed-provided stablecoin over any of the non-Fed competitors. If you're using US Dollars in the first place you're already inherently trusting the Fed, so it shouldn't be a much bigger leap to also use their blockchain-based version. This would reduce the degree to which Tether and others are "a challenge to financial stability" because it puts mint/burn powers of the dominant USD stablecoin squarely back in the control of the Fed.

> There is also a pretty big body of evidence already that doesn't show any hugely significant (say, 2x) changes in productivity

> For productivity I haven't been able to find any large-scale studies that compare functional vs imperative/OOP languages

I'm having trouble reconciling these two statements of yours.

If the restaurant uses the stablecoin, nobody takes the loss because the transaction is happening with a different currency. The restaurant isn't holding BTC, it's holding a USD-equivalent.

If BTC loses 10 percent of its value overnight, the people who lose are the people who sold at the lower prices. When we say "the price of BTC is X", what we really mean is that a trade happened at that price. That means that someone thought selling at that price was the right thing for them to do and someone else thought that buying at that price was the right thing to do.

As I see it, the federal reserve official's statement really boils down to the fact that if Tether (or any other widely adopted stablecoin) is conventionally accepted to have the value of $1 USD, and the people running Tether can print them, then those people can effectively print USD. And THAT, from the Fed's perspective, is a risk to financial stability.

If I was the Fed I would seriously consider creating my own TheRealUSD stablecoin. Create a token that you have mint/burn control over, and create a portal that allows people to exchange USD for the stablecoin and the stablecoin for USD. No doubt a number of the crypto-libertarians out there will not trust that thing and might object to using it. But from the other perspective which would you trust more? A USD stablecoin run by some random collection of tech people? Or a USD stablecoin run by the Fed?

> I still do not understand why it even exist?

Imagine you're a restaurant (or any other business) and you want to allow your customers to pay with digital transactions on a blockchain. If your customers pay you in Bitcoin, you are taking on a huge amount of risk due to Bitcoin's price fluctuations. I just looked up the price of Bitcoin and it has dropped 6% in the last 24 hours. If you sell a $100 steak dinner for Bitcoin in the morning and it drops 6% by the time you're converting it to dollars at the end of the day, you've just lost 6%. You have to pay your expenses (labor, food, etc) in USD no matter what but you're holding a currency that is now worth 6% fewer dollars than what the customer paid. The reason I picked the restaurant business for my example is because restaurants have really thin margins. A 6% loss due to currency fluctuation is a huge problem for a restaurant.

That is why people have created stablecoins that are constructed in a way such that their value is pegged to some kind of external asset (like the USD). This allows business to accept payment via a blockchain without being exposed to the price risk of volatile cryptocurrencies.

This idea can be extended by observing the following analogy:

purity is to functions

as

immutability is to data

Immutability is definitely a valuable technique that can help make software faster (sometimes), more reliable, and easier to maintain. I would take it one step further and argue that we can get a similar boost by extending the idea to functions, not just data. And the way you do that is by writing pure functions (i.e. no side effects...or controlling/limiting them in some way) and using languages that can enforce that your functions are pure.

I really like a post I saw awhile back that refines the idea of technical debt as an unhedged call option. (Original link is dead, so here's the wayback machine link and the HN thread.)

https://web.archive.org/web/20161223143702/http://higherorde... https://news.ycombinator.com/item?id=8777237

From the post:

> Call options are a better model than debt for cruddy code (without tests) because they capture the unpredictability of what we do. If I slap in an a feature without cleaning up then I get the benefit immediately, I collect the premium. If I never see that code again, then I’m ahead and, in retrospect, it would have been foolish to have spent time cleaning it up.

> On the other hand, if a radical new feature comes in that I have to do, all those quick fixes suddenly become very expensive to work with. Examples I’ve seen are a big new client that requires a port to a different platform, or a new regulatory requirement that needs a new report. I get equivalent problems if there’s a failure I have to interpret and fix just before a deadline, or the team members turn over completely and no-one remembers the tacit knowledge that helps the code make sense. The market has moved away from where I thought it was going to be and my option has been called.

I don't know that I would go quite that far. A blockchain is a linked list, but IMO a run-of-the-mill linked list doesn't quite make the cut to be a blockchain because I would argue that the essence of the word "blockchain" has to do with the "one block contains the hash of the previous block" property. A C-style linked list where the link is a pointer to a memory location would not be a blockchain.

That being said, I will definitely agree with you that the word "blockchain" is very overused and underspecified these days. Just because a term is often misused doesn't mean it has no definition. I think most of that is just laziness on the part of whoever is using it and not actual lack of...consensus...on a fairly clear definition.

Interesting. This kind of seems like the software version of the efficient-market hypothesis from financial economics. It's pretty much obvious that markets have inefficiencies. But at the same time, they're the best we've got and constructing something that's better in general is really hard.

Completely agree. And the thing I love about your comment is that even though you've found solid argument for why the OP's criticism was right, you articulate the tradeoff and explain why you think it was the wrong one. This is a dramatically more effective and compelling approach IMO.

If you happen to do design work and are looking for a job, I'd love to chat and see if there are any possibilities for collaboration. If you're interested, feel free to drop me a line at my username at google's mail service.

I appreciate the OP's point. In fact, I accidentally hung up a video conference literally today due to pretty much this exact issue (no, it wasn't Google Meet). I even appreciate the colorful language and style of writing. Sometimes is just feels good to get one's frustrations out. However, allow me to defend the UI designers.

The thing the author doesn't seem to realize / acknowledge is that UI/UX design is about balancing enormous numbers of competing constraints and concerns. It's a human problem, and like most problems of this genre there is no "best" answer, only different sets of weights for different, often competing, concerns. Simplicity and ease of use are good things, but they are almost always at odds with flexibility and power...also good things. Do you make things bigger with more space so they're easier to see, or do you make them smaller so you can fit more things on the page? Do you use color so you can communicate more and catch the eye more quickly, or do you avoid that so that your app is friendly to colorblind users? (Yes, I know there are color schemes that can achieve both to a decent degree.)

These kinds of tradeoffs are lurking almost everywhere you look in UI/UX design, but this kind of nuance seems to be lost on the author. He only seems to see his set of priorities for a UI. Yes, there are plenty of cases where one thing is pretty objectively worse than another, but usually it's more subtle than that. I'm way more impressed with someone who can talk intelligently about the tradeoffs than I am with someone who fixates on something that very well might have been traded off and rant about it.

No matter how heterogeneous the map seems to be, there's always some underlying structure. If you have written code to work with it, then you've encoded that structure...by definition. Haskell gives you fantastic tools for managing this structure at whatever level of specificity you want. At the end of the day everything in a computer always boils down to bytes, so in the absolute worst case, you can always drop out to the escape hatch of:

Map ByteString ByteString

This can represent any heterogeneous map that any other language can represent. Sum types can allow us to add another layer of structure to this if we want. For example, take the classic example of JSON.

Map ByteString JValue

...where

   data JValue
     = JObject (Map Text JValue)
     | JArray Array
     | JString Text
     | JNumber Scientific
     | JBool Bool
     | JNull

This is just one example of a way you could structure things. Sum types are super powerful for this kind of thing. And no matter what structure you come up with, you can always escape hatch that structure by adding a catch-all constructor like this:

   data MyValue
     = MyThingA A
     | MyThingB B
     | ... more things
     | Unexpected ByteString

That's actual valid code btw, and it even reads really nicely!

I agree with you that the many flavors of Haskell are problematic when it comes to uniformity. C++ and Scala have similar challenges. The old trope of every C++ shop using their own unique subset of the language is pretty relevant here. One thing in Haskell's favor though...with the language extension paradigm you have a very clear and tangible path to enforcing uniformity in your codebase that you don't have in C++ or Scala. You can use simple code analysis tools (I believe hlint already has this functionality, but just grep is sufficient actually) to enforce your team's choice of language extensions.

The author wrote follow-up book called The Dichotomy of Leadership specifically to address the problem of people taking EO too far in one direction. But like my sibling comment mentions, I don't think you should blame the Gallagher problem on EO without clear evidence connecting the two. And even if you do, the follow-up book is there to clarify.

There's a slick little Haskell library that does something similar called reflex-vty:

https://github.com/reflex-frp/reflex-vty#reflex-vty

One thing neither of these libraries appear to have done yet that I would really like is create a more compact window rendering. Currently each window gets a 1-character border. What I would like is something that saves space by collapsing adjacent windows' borders into a single character instead of having two redundant borders next to each other. Of course I get why they do it the way they do, but terminals are often more constrained for space and with complex UIs you can lose a fair amount due to these unnecessary borders. That would be the next thing I'd hack on to improve these kinds of libraries. But alas...too many fun projects to hack on and not enough hours in the day.

> But if you smelt aluminium, you have valuable aluminium.

And it's useless until you spend more energy to move it to where people want it.

> It's disingenuous to pretend (without any sourcing) that bitcoin is only mined using electricity that would otherwise have been wasted.

It doesn't have to be only mined that way. You're being absolutist. Competition has resulted in bitcoin mining being very sensitive to energy costs. It stands to reason that miners--especially the ones operating at large scale--will move to places where there is cheap energy.

https://www.publish0x.com/muchograph/top-5-biggest-bitcoin-m...

Several of the big mining operations mentioned there are located in places known for cheap electricity. Genesis mining relocated to Canada and Iceland specifically for cheaper power. Gigawatt is located in Washington State which has some of the cheapest electricity in the U.S. (part of the reason Google chose The Dalles, OR for one of their data centers).

> I prefer using the word 'control' over fault, because fault has so many negative connotations.

Excellent point. I completely agree. I'll have to keep that in mind in the future.

If you smelt aluminium in a remote area you then have to move it to an area where it can be useful. Moving it consumes a lot of energy. If you mine a bitcoin near a power plant with excess capacity, anyone anywhere in the world with an internet connection can leverage that work for value transmission. This literally allows a computer in China to replace an armored car in Denver, Colorado.

> There are plenty of other good uses for electricity besides bitcoin or powering a city directly.

The argument "uses lots of energy = bad" is a fallacy. You have to take into account what the alternatives are. You know what uses a lot of energy? Public transit systems. But nobody is arguing that public transit systems are bad because the alternatives are a lot worse.