agreed. i think the economics of ramen make less sense outside of japan, where it’s more expensive and turnaround is slower because folks linger longer (often to amortize the cost of waiting to get seated in the first place).
In Düsseldorf that’s not the case. The Japanese restaurant are very distinctly less chill than other restaurants. Like, where you’d usually spend 3 hours in a normal restaurant, it is kinda expected that you eat and leave a Ramen shop within an hour.
Personally, its my Japanese Pizza. Both ramen and pizza have historical roots as affordable, filling meals for the working class and poor communities.
If you avoid the pork, it becomes less fast-food-ish.
I’m guessing back in the late sixties to early seventies going to McDonalds could have been a special night out and it could have been a place people stayed an hour. Some people may still linger in a McDonalds for an hour but I’d have think that’d be an exception. They’re loud, crowded and the seats are not entirely made for comfort. It’s not a place that strikes the imagination with, oh, there’s a place we can go eat and relax at.
I know this is the American in me but: what the heck do you do for 3 hours? Especially at a place that doesn’t serve 5 courses. If you’re hanging with old friends, maybe, but even then the conversation can slow down after a while.
I don’t know how restaurants work in America but generally you go to a restaurant to hang out here as well. I think service is generally slower. Drinks are also not free refills so a lot of restaurants do get fancy with their drinks so you try those as well. We usually also get at least desert and a coffee. Three hours is maybe not the norm but most restaurants plan in 2.5 hours slots.
Like, it’s not just eating. It’s socializing as well. You use the restaurant as a place for conversation.
If the average American fast food place here is reflective of the average American restaurant experience, I think that’s a big difference. Even the most run down gyros or kebab place that also sells burgers and pizza will have tables outside on the street with ash trays and will sell you a cold drink. But even five guys, which is a lot more expensive than those places, has lighting that is more suitable for surgery than chatting.
If you go to places like France, people will get an espresso and a little thing of olives and just sit there smoking and people watching. Alone. That’s maybe a bit much for me but a 2 to 3 hour dinner with friends seems very normal for me.
Oh and now I have a kid so a lot of times the waiters will play with the kid or the environment is suitable for the kid to just play alone and then it’s a good opportunity to just have a cold drink or a coffee with the my wife in peace after a meal so even with only my family we’d do 1 1/2 to 2 hours.
The fast food experience is a far end of the experience even for the US. I've experienced long meals here in the US too. They are much less systemic than what I experienced and observed in the UK, France, and, Italy. I've had the fast food experience in the UK too; e.g. sausage rolls at Gregg's.
this reminds me of a naive and happier time in tech, when i built a game called ramendan with twitter’s open API. you had to eat ramen every day for dinner, and tweet proof with the hashtag #ramendan, link to a photo (this was before twitter supported images), and geotag it so that we could make sure it was after sundown in your timezone.
i went super deep on 140-byte code golfing[1] back when twitter was taking off, and it changed the way i think about code. for a brief while we had a small community collaborating on byte-squeezing techniques[2], and i was constantly amazed at the creativity that this constraint brought about, from mandelbrot renderings to sudoku solvers. possibly the best part was more than a decade later when i found my golfed UUID implementation[3] deep in my employer's codebase.
A service worker would work fine; the connection would be instantiated from the SW and each window/worker could communicate with it via navigator.serviceWorker.
Instead of adding a non-standard API to opt-out of existing networking functionality, it would be great to see a lower-level networking primitive to unlock these kinds of use cases. I wrote more (with a proof-of-concept) here: https://readable.writable.stream
No. That's the whole point of using JSON.parse() instead of eval(). JSON is defined as a non-executing subset of JavaScipt syntax, one that contains only literal expressions. JSON.parse() will only parse valid JSON.
This is why, for instance, there's no native Date format in JSON. Dates in JavaScript require running a constructor -- new Date() -- so they aren't in JSON.
That would concern me too potentially, though if there isn't one already it should be easy to implement a switch that would turn this part of the behaviour off.
It looks very interesting to me from the point of view of dealing with certain data types better (at all, in fact), and handling circular references.
I was thinking more along the lines of turning it off at the generation side: only including anything in the persisted state that is safe.
Trying to detect the unsafe parts so they could be turned off after that point would be impossible as you suspect (the task would be constrained by the halting problem, https://en.wikipedia.org/wiki/Halting_problem).
It seems like it theoretically shouldn't be too hard to add the ability to validate that the data is a valid lave output if you're concerned about that. That more or less leaves only the issue of anonymous functions in the data being replaced with malicious functions, but frankly the only reason to be serializing functions is if they're user input, otherwise you should instead be serializing function name/key strings or some other well-defined form of function references and/or arguments.
Any type of code-serialization tool will be vulnerable to injection. This is why use of pickle is often discouraged in Python, in favor of serialization formats which don't deserialize to code. Anything that marks "valid output of the tool" could just as easily be produced by an attacker who uses the tool to serialize their malicious code, and even signing/secret-token systems aren't a guarantee since it's so incredibly easy to build or use them the wrong way.
I meant that your code could parse the supposed lave code before running it to verify that it is limited to the known lave constructs (which does not include arbitrary code execution). It would quite slow but enough to make it somewhat safe against an attacker providing malicious lave code.
If lave generates a well defined sublanguage, I don't think parsing would need to be much slower than parsing JSON. It would just be an extended JSON parser that happens to parse executable JavaScript.
Absolutely. The downside of running a full-blown eval() exists in JSON too, it's just that the eval() there is taking place in the reviver function, which requires a lot more coordination than a self-contained file.
As far as efficiency, I'd think for most uses the issue would be on the JSON.parse end. In this case, lave might be more efficient, since JSON reviving often ends up creating temporary objects that need to GC'ed after reification.
reply