This strikes me as really dumb. An efficiency that the diner would never notice and he wants to make his staff work harder to prove a point. Way to make people resent their work.
He believes it will bleed into other things where it does make a difference. So he takes a 0 tolerance policy into cheating so it doesn't become a habit and a culture and instead hopes to instill the value of not taking shortcuts as a measure to prevent a lapse.
As a programmer, this still seems overly dogmatic. Why not just develop the discipline to put effort where it's actually needed instead of burning gas all around like a moron? Every programmer knows this. The extreme dogma seems the real lack of discipline to me.
As a programmer I probably don't know very much about how to run a kitchen, the kinds of people that work in them, and the reasonable expectations the kitchen manager might have. Not to mention, the outcome of the majority of software project is failure lol.
> A lot of people hate rote learning - but elementary math classes, meaning all the way up to calculus (or prior to more rigorous proof based classes), do require a bunch of memorization
A lot of people still think reading and re-reading textbooks is the way to memorise theorems but recall (attempting to remember them without the book) is much better.
I cannot recommend the book "A Mind for Numbers" by Barbara Oakley enough - it put me on a journey to re-learning Maths as an adult.
> Rationale: It is very difficult to make goto work well with defer and implicit unwrapping of optional results. It is not just making the compiler harder to write, but the code is harder to understand as well.
That seems to fit your heuristic. Goto being difficult to implement in the compiler doesn't match expected reality.
`goto` is trivial to implement. `goto` doing the right thing jumping over `defer` and implicitly unwrapping optionals (flow-typing) is less nice as you suddenly need to track much more things in the front end.
And you might say "so what, the compiler can be complicated, just make the language easy to use". However, one design constraint is to not make the language hard to reimplement.
And you might not agree with that constraint, but some people feel that this is indeed important. Important enough to not include `goto` as long as the use cases of `goto` are all covered.
It's not difficult to implement goto as such, it's just a JMP instruction, but (I'm not a compiler developer, but I can imagine) implementing goto without introducing strange bugs or crashes is a bit more difficult.
Compilers really like canonical forms. There's a good chance that if, for, while, goto, break and so forth all turn into an edge between basic blocks (anything that doesn't have a branch or branch target in it). In a rather literal sense it's usually all sugar over goto, unless you're doing something niche like carefully preserving structure because your target language doesn't have branches.
So seeing someone say that their compiler struggles to represent goto throws some doubt on how the thing is implemented. Goto should generally be the easiest possible control flow to translate into your IR.
Years ago I worked on a calendar application with recurrence. After lots of research I settled on using RRules to represent this, which I was very pleased with. That initial work was when I was at an agency.
Later I joined the company full time and discovered to my amazement that a contractor from a different company had removed the RRules in favour of creating and destroying instances of events on the fly. It had no/little fault tolerance so sometimes the script (which did other things that would sometimes fail) would fail to create new events. You'd have monthly recurring events with missing months.
I found it so frustrating that (after going through a lot of thought and research) that someone hadn't put anywhere near as much effort into removing mine. It took just a few weeks at that company to realise that the CEO expected the Engineering team to pump out features (that nobody used) at his will and, in the uncertainty of the job market, sadly I stayed there for 2 years.
Unrelated footnote: After Googling them, it's really sad to see what are blatantly fake reviews by the CEO on Glassdoor all written in the same style with nothing bad to say. I (and a bunch of other people I know who worked there) hated him, but the silver lining is that I wrote some of my best essays there. The CTO was hopeless too.
If you know a good way of searching through my entire comment history I'm happy to search for it, but it was some years ago, and I post several comments a day, so it may be a tall order to manually page through my history.
