> It is quite believable that it's easier to describe what a program should result in versus actually programming it to produce that result
This is obvious for the central cases of a program. It becomes less and less true when going toward the edge cases, especially for a wide array of input.
Complex specs becoming programs is IMHO the direct effect of that (defining what we want is just that burdensome, and special cases we haven't though of will still have a coherent definition in the spec), and we fall back to the base "is this spec even correct" issue the parent points out.
The trick is to start with the smallest possible implementation of a spec and proving it correct. You then add a more advanced and faster implementation and prove that the 2nd implementation implements the 1st. Etc. etc.
It's called refinement and it's a great way to prove really complex software correct. You basically have a formally proven correct chain of software from simple to advanced. CompCert is an example of how to do this.
To note, this isn't just banning random scams: calls coming from a known entity, but abusing their existing relation to push marketing calls also fall under this law.
For instance your main bank calling you for "special offers", even as you've already explicitly told them you don't want any marketing calls, would be candidate to punishment under this rule.
I always wondered how actually cheaper a QR menu is, compared for instance to an android tablet you set there or pass to the client so they order.
People immediately see the cost of a tablet, the issues with charging, building the app and updating the data, customers not understanding the interface etc.
Yet, they don't seem to grasp all of these are basically the same for a QR code: you're now maintaining an online service just for your restaurant. People still need to understand your site. You'll be dealing with their browser, extensions, languages etc. And you still need the QR code somewhere on the table, visible, explain that it needs to be scanned (by one person ? everyone ? do they need to keep the tab open ? etc.). These will all be costs, you pay either upfront by hiring experts to make the experience good, or on the go with crappy customer experience, your staff spending more time than needed working around the system and explaining it to your customers, and those not coming back.
There are super cheap and simplistic ways to deal with all of that, and I assume GP has seen many of these.
PS: The weirdest experience I ever had was someone at our table scanning the code, to copy/paste it on the browser on their personal profile (default was work browser).
They missed a digit in the url params and ended up opening the order menu of a table at the other side of the restaurant, and just started ordering, then waiting for a pretty long time while the other table was dealing with the mess.
> They don't want 100 apps that do the exact same thing.
I read it as the "insane" part parent is pointing at.
It's nothing new, has been going on basically since the existence of the App store and Apple has explicitly built their whole business to put themselves as the arbiter of who gets to have their app on people's phones.
Still it's healthy that from times to time we stop and shout "that whole situation is insane" (short of finding a way to actually do something about it)
Slightly besides your point, but it's interesting how many here naturally ponder about how the current winner could or "should" keep winning, instead of how another company could become a competitor by doing the more clever thing the incumbent isn't thinking about.
It is not a “should”. At least not in the “we wish it were so” sense.
It is more that there are multiple reasons why this idea (burning an LLM into silicone and deploying it into a device in people’s pockets) requires huge piles of cash and the kind of engineering chops only a few company posesses.
Of course i would like it if a small upstart would do this, but it doesn’t seem likely as a posibility. They won’t have the funds to fab the IC. They won’t have the funds to train and validate the model before burning it into silicone. They can’t absorb the risk of the first tape out going wrong. They can’t absorb the risk of the model being faulty in some subtle way. They don’t have a device to integrate the IC into. They won’t have the funds to develop one. If they somehow would make a device they don’t have the marketing and sales channels built out to get the device into people’s hands in sufficient numbers to justify the development cost.
Basically this idea feels ruinously expensive. Apple has deep pockets, they already have working well-regarded phones, and an ethos of privacy preserving innovation. This is why this idea feels well suited for them and not many others.
Do i want the winners to keep winning? No. But not many others can pay for a moonshot crossed with a manhattan project. They just can’t.
Yes, it's an interesting register (sorry for the claudism; blame lesswrong-weighted training) for the use of the word 'should'. I agree with your assessment and it is rarely articulated. Sometimes I think that the HN set is abused by big tech both from above on the employer side and the consumer usage side (all the T&C's, VC incentives and M&A taking away once-good-things). So they adopt the only sliver of agency-salving language available, like 'big company that I have no scope over should X'.
Good point. IMHO we're thinking of too much in single entities doing everything.
Right now it's kinda the world we live in, with Apple or Google doing the total vertical integration from chip design to retail shops, but it doesn't have to be that way.
It could be done the traditional way with for instance a joint venture receiving funds and expertise from several players in each of the field and collaborating with external companies to get to the final package.
You're right on the principle, and this camera is purposefully aimed at a subpar viewfinder experience.
As a comparison point, many people shoot street photography "from the hip", aiming the camera at the rough spot they want to get with a forgiving aperture setting (around 8 or more). This help either for speed, or engage with the scene without having to stick a camera on one's face.
I think this camera is basically aimed at the same crowd, those who will want some idea of what the camera is pointed at, but want to stay "in the moment" and no fully focus on the capturing process. This is pretty close to a phone camera perhaps, but I'd assume it's a lot more fun and carefree.
The from-the-hip cameras typically have a waist-level viewfinder, which still is a good approximation of the optical path or you don't and you shoot completely blind. In that case any camera does the trick and so does a phone.
Usually the hip part is so you get a better, more candid, portrait due to being inconspicuous. There's some composition advantage due to the perspective difference too.
This isn't about getting a good shot, it's about the vibes and the fun. The viewfinder is the gimmick that catches the eye but it technically doesn't do anything.
> The from-the-hip cameras typically have a waist-level viewfinder
That is the case with twin-lens reflex cameras, for example, which are not commonly used for street photography. What the GP meant was holding an SLR or rangefinder camera at hip level, forgoing the viewfinder completely and shooting blind.
> As a comparison point, many people shoot street photography "from the hip", aiming the camera at the rough spot they want to get with a forgiving aperture setting (around 8 or more).
Interesting you say this as I have been on my photography journey these last 2 years and keep hearing the opposite opinion: People "cheating" by using a low aperture so they don't have to think about the entire composition as it gets blurred out.
Because street photography is very spontaneous it’s pretty common practice to set an aperture of 8 and just snap away - it’s a helpful trick for rangefinder cameras that often take some time to pull focus.
Its cheating because you don't have to think about focusing your lens. At f/8 you have a reasonable hyper-local distance, and so for instance everything from 2m to infinity is sufficiently sharp.
This kind of advice was given before the advent of good enough autofocus where indeed you've rely on the machine to focus your imagine. But at the same time you delegate the choice of the subject to the machine instead of spontaneously capturing "everything".
Absolutely not defending anything the US gov is doing now or for the past years, and in general agreement (Iran is targeted for totally stupid reasons), just to point out:
> With the abundance of onshore oil through fracking revolution
Fracking isn't free of consequences, and while the current US gov doesn't care about them, people are directly affected and are rightfully pissed about it.
Bombing/invading foreign countries to get the oil is obviously not the right approach, but relying on fracking isn't a clean solution either.
> He didn’t get the job because even though the technical attributes were all good, he should have pressured the customer.
I'd say he didn't get the job because they would have asked him to pressure customers day in day out, he would refuse, never get promoted and be otherwise miserable in an aggressive culture.
IMHO he shouldn't change his answer to please the interviewer, the process is working as intended and I'd assume he found a job that better matched him somewhere else, where his mindset will be better valued.
I've too many wacky interview stories to list here, but the first time I came to this same conclusion was when I had an interviewer interrupt me mid-answer to correct my pronunciation of "idempotent" (because I said it in what is apparently a more British fashion). I asked him to repeat himself to see if he'd apologize or brush it off as a tic and he repeated himself with an elevated level of contempt. I declined the offer, that company got bought by McKinsey a year later, and everybody lived happily ever after.
A long time ago, maybe 2016, I interviewed at Paperless Post. The interviewer asked me explain the concept of a promise in javascript, then asked me to implement it from scratch, then asked me to extend it with different features like promise.all.
About 45 minutes into doing this I decided that any company that screened candidate like this was not somewhere I wanted to work so I told the interviewer that I didn't think this was the right fit and I appreciated them taking the time to consider me for the role but I wouldn't be continuing on.
I'll never forget he was like, "But you're doing great!" ... like yes, I know. I'm not stopping because I'm failing, I'm stopping because you are.
I had an interviewer once interrupt me and say that there was no way I could remember the techincal details of a 10 year old project I was the architect for, thus any details I did offer would likely be lies. Needless to say, I didn't get an offer nor would I have accepted it.
I had an interviewer once interrupt me and say there was no way I would have studied gray codes in college. I still don't know if that was some bias that I went to a "provincial school" in their mind or that they hadn't noticed my Master's degree or that my degree program also involved a lot of hardware and electronics work or just that they didn't study it in college and were secretly telling me how useless their fancy "West Coast Ivy" degree program was for them.
I made the mistake of letting that company bring me back for a second "less technical" round of interviews, but I shouldn't have.
that's true, being lucky enough to have one's basic food and shelter needs covered does really help one refuse employments that might be unpleasant, and it's very true that many people are not lucky enough to have that freedom and may end up having to put up with difficult working environments.
> I'd say he didn't get the job because they would have asked him to pressure customers day in day out, he would refuse, never get promoted and be otherwise miserable in an aggressive culture.
But how do you differentiate between if it is just this one interviewer or if it is the team or the whole company? I had interviewed at places that my friend referred me to, and after the fact, my friend told me it is just this one interviewer with their weird preference that screwed the whole process…
The only goal of an interview for the interviewee is to get as much money as possible. If they're offering really good money, you need to pass whatever obstacles they have. If they're not, why are you there?
Money is a factor, but not the only one, and for some, not the most important one. Beyond a certain point, there are diminishing returns. Does driving a car that costs twice as much make you twice as happy? Maybe for the first month, then it's just normal again.
For me personally, quality of life is important, so is vibing with my coworkers, and management that respects work-life balance. I have this at my current job. My salary is good, not amazing but comfortable. Would I trade double the salary for an environment where I'm stressed, expected to work 50 hour weeks, and answer calls on my own time? Nah. No way.
For most foreign dishes you can't just compare the total price to local food. I'm saying that having ordered pizza in Japan, and an actually good one with Buffala for instance will be twice to three times the price you'd pay in Italy.
Ramen chains managed by Japanese people are decently good when I tried them in France (Ippudo for instance), it's not that far from what's served in Japan. It costs 1.5x to 2x more, and the default orders will be slightly adapted to the locals (harder noodles and lower grease by default) but that's par for the course.
> BTW, you can also replicate the form factor using western cooking ingredients/traditions and it still works pretty well.
The toughest part is the sheer amount of time to prepare the soup and dexterity to get good noodles. Spending 8h on the soup with all the ingredients, and repeat I don't know how many times to get to a decent balance is a dedication I don't think I'll ever have to be honest.
I'm currently in a coastal American city, and all food is expensive here! You can have a casual lunch or dinner at a ramen shop, a Neapolitan pizzeria, a Thai restaurant, or an American burger spot and you will pay $25-30 per person after tax and tip at each of them. (Assuming you don't drink alcohol, and assuming you avoid both bottom-barrel and upscale places.)
There doesn't really seem to be a "cheap local default" option like there would be in Japan, or Portugal. I guess McDonald's sort of fills that niche, but this neighbourhood doesn't have one. The two best "cheap" options near me are both Vietnamese.
One nice thing about this is that there's no penalty for experiencing a variety of food.
At least where I'm at, you can still go cheaper for pizza and burgers. In-N-Out's combo meals start at about $8. If I want to, I can also get 2 big slices of serviceable pizza for a bit less than $10 in a mom & pop shop, and this is in a city that IMO punches well below its weight when it comes to pizza.
I've been able get better or equivalent results than most non-japanese ramen places near me by starting with miso paste and fresh noodles from the local h-mart, without the massive amount of work that typically goes into ramen.
Not everyone can fly to Italy for a pizza to save money! But seriously, pizza in most countries is horrible. When I lived in Ecuador the pizza had some really funky cheese. I'm not sure if you can even call it cheese. That's probably why it is almost impossible to order a plain cheese pizza. They are trying to cover it up with an assortment of vegetables and meats.
If the tooling allows rollbacking X, Y and Z as a set, it could make sense ?
I'm also on the "compare to the main branch" camp in general, but will sometimes end up with a set of X,Y,Z branches that have different purposes but all depend on X.
More often than not, the base dependency is a set of constants or additional class/methods that could be released with no impact (no reference in live code) but still need a somewhat lenghty review process. Reverts would be happening on the higher level PRs, which hopefully are independent.
This is obvious for the central cases of a program. It becomes less and less true when going toward the edge cases, especially for a wide array of input.
Complex specs becoming programs is IMHO the direct effect of that (defining what we want is just that burdensome, and special cases we haven't though of will still have a coherent definition in the spec), and we fall back to the base "is this spec even correct" issue the parent points out.
reply