greenkey

That’s what proof-of-work and proof-of-stake are about. I’m saying that the problem has been solved and would need to just be applied to this use case.

> a year or two behind the times

How exactly?

I agree with you that use of blockchain on its own is not fully secure, but that can be mitigated for the most part through the same sorts of proof-of-work and proof-of-stake mechanisms and entities that Etherium, etc. use. with adjustments.

This might be exactly the time for Woz and co. to get into this given that there are others handling those problems, right?

> Oh wow! Thanks for telling us!...

In the US, admitting you did something wrong could open you up to a class action suit where some customers could be eligible for damages due to negligence.

You and others assume the merchant is unscrupulous, but they provided a remedy, so when you then called them out on it and gave them bad PR, you’ve given less incentive for other businesses to provide even that.

You could’ve written your post without specifically mentioning the merchant’s name, if your intent were really only to help others.

Even worse, if the merchant were unscrupulous and your aim were revenge, if it were to turn out that the merchant gets more business because of the PR around your stunt, they might tell other unscrupulous merchants that they should not pay their agents and hope for a windfall from rewarding only one of them with their due.

I’m not a fan of everything Bukowski wrote, but I wouldn’t try to censor him so that little Jimmy could read it, and I liked the movie Barfly.

Similarly, I’m not a fan of everything Linus wrote, but I wouldn’t enforce bad CS101 code on him so that little Jimmy could read it, and I like Linux.

This is good advice.

Another thing to consider is cost-to-benefit ratio.

If you don’t know cost, first look at:

Product costs: free < one-time cost < recurring cost or recurring “one-time” costs

Resource alignment costs: (Re-)hiring + severance + knowledge lost or transferred to competitors

Refitting and development costs: converting or re-writing code + (re-)training + architectural changes + design changes

Time + impact to other initiatives and maintenance

Don’t stop after costing!

Then listen to the perceived benefits or need again, being careful to communicate and discuss the perceived costs, so that those selling the idea within the company understand, because if they don’t, their good idea will be poor morale fodder later.

This is much quicker and easier than it seems. If you still haven’t convinced the elements within the company to back down on their idea, and you’ve done a good job listening and considering their points, then either those elements are onto something or they’re “on something” (drinking the kool-aid).

Make your decision.

In my experience, the main reason these companies fail and especially why acquisitions don’t turn out well is the assumption that the way you do business and the people you have are just successful in their own right and will just take in the new sheep and keep fleecing the larger flock. It doesn’t work like that.

> That said, Common Lisp is weird. What I find particularly jarring is that functions and variables live in different namespaces: if you put a function into a variable, you can’t just use it like a function, you have to funcall it.

Unless I’m misunderstanding, the author sounds like a developer that’s primarily used JS. It’s really not abnormal to have to include parens after a method name in a language, which indicating that you are calling a function.

I like this post but “unscrupulous merchant” seems harsh for a company that may have changed their policies and didn’t realize they had to inform the referring agent of those changes.

It’s not uncommon for policies to change; that initial marketing spiel for bringing agents aboard doesn’t look like a contract.

The reselling agent probably didn’t have a case here, and the merchant went out of their way to assist when presented with a good argument.

So, this is less about the “unscrupulous merchant” and more a warning to businesses to be clear and contractual with your policy and policy changes in order to avoid PR disasters like this.

Same here, I avoid them when I can. It won’t be too long before the gas stations are fast chargers, though- I give it 20 years.

That’s kind of harsh. Ruby was a great language and especially great syntax. Except for some duplication of methods and early misspelling of one or two methods, it would’ve been much easier for people to learn and do cool things with that didn’t happen in JS until years later.

Scheme’s not bad, but I think if you compare The uptake of both, Ruby did better? (Not counting Lisp.) It was a cool language though; a lot of problems that would’ve been avoided, if people could type all the braces in correctly... for Lisp at least.

Rails 1 was released in 2004.

I guess it’s a cultural difference because I don’t associate those things immediately with the word “bull”, even when it’s in the context of “red”.

If someone were to say,”Do you want a Red Bull?” would you get upset?

How many operations and objects? The method he’s talking about would seem more efficient for the purpose vs all of the strings still being created even if never used in the plain hash version.

Which became dominant for a while, but cgi scripts on the server-side were also hot.

Enter Perl and PhP server-side.

Then there was JSP, ASP, and ColdFusion, all server-side.

Rails! Also server-side.

Then back to JS.