I consider Unreal Blueprints to be essentially a 2D language with the data flow and the execution flow modelled in separate dimensions.
Readit Newsabraxas commented on Recto – A Truly 2D Language masatohagiwara.net/recto.... · Posted by u/mhagiwara
abraxas commented on Is the A.I. Boom Turning Into an A.I. Bubble? newyorker.com/news/the-fi... · Posted by u/FinnLobsien
Just buy $RSP or a similar equal-weightage ETF.
Those techniques rarely worked in the past as the broad stock market retreat usually affects stocks across the board. The best diversification is into uncorrelated asset classes. But there is some art in determining what's likely to remain uncorrelated. Bonds and gold are usually decent guesses.
abraxas commented on Evaluating LLMs playing text adventures entropicthoughts.com/eval... · Posted by u/todsacerdoti
related research that was also announced this week: https://www.textquests.ai/
that's a great tracker. How often is the laderboard updated?
Very nice project. Do you have plans to commercialize it next?
Me too. Do you mean USA cities or worldwide? I'm told that some of the most walkable cities worldwide are: Copenhagen, Amsterdam, Vienna, and Barcelona. Which other ones should be on there and which ones from USA?
Devon also made this list: https://airtable.com/appcoaCeTbl22Few2/shrWJYzc04FQZIkP5
I visited Amsterdam this summer. It's amazing, almost eerie how you get off the train at Cetraal station and you are greeted by a city that is nearly silent. Instead of the usual groan of the combustion engines you just hear the gentle sounds of bicycle chains all around you.
Setting aside the objections some have to exceptions generally: Checked exceptions, in contrast to unchecked, means that if a function/method deep in your call stack is changed to throw an exception, you may have to change many function (to at least denote that they will throw that exception or some exception) between the handler and the thrower. It's an objection to the ergonomics around modifying systems.
Think of the complaints around function coloring with async, how it's "contagious". Checked exceptions have the same function color problem. You either call the potential thrower from inside a try/catch or you declare that the caller will throw an exception.
That's a valid point but it's somewhere on a spectrum of "quick to write/change" vs "safe and validated" debate of strictly vs loosely typed systems. Strictly typed systems are almost by definition much more "brittle" when it comes to code editing. But the strictness also ensures that refactoring is usually less perilous than in loosely typed code.
I think checked exceptions were maligned because they were overused. I like that Java supports both checked and unchecked exceptions. But IMO checked exceptions should only be used for what Eric Lippert calls "exogenous" exceptions [1]; and even then most of them should probably be converted to an unchecked exception once they leave the library code that throws them. For example, it's always possible that your DB could go offline at any time, but you probably don't want "throws SQLException" polluting the type signature all the way up the call stack. You'd rather have code assuming all SQL statements are going to succeed, and if they don't your top-level catch-all can log it and return HTTP 500.
It's fine to let exceptions percolate to the top of the call stack but even then you likely want to inform the user or at least log it in your backend why the request was unsuccessful. Checked exceptions force both the handling of exceptions and the type checking if they are used as intended. It's not a problem if somewhere along the call chain an SQLException gets converted to "user not permitted to insert this data" exception. This is how it was always meant to work. What I don't recommend is defaulting to RuntimeException and derivatives for those business level exceptions. They should still be checked and have their own types which at least encourages some discipline when handling and logging them up the call stack.
An adjacent point is to use checked exceptions and to handle them appropriate to their type. I don't get why Java checked exceptions were so maligned. They saved me so many headaches on a project where I forced their use as I was the tech lead for it.
Everyone hated me for a while because it forced them to deal with more than just the happy path but they loved it once they got in the rhythm of thinking about all the exceptional cases in the code flow. And the project was extremely robustness even though we were not particularly disciplined about unit testing
If I'm being honest, this list is really daunting. I had no idea that so much red tape stood between North America and pedestrian (i.e. human) friendly places.
There are 3 primary decisions Google made that click with me, while Apple's choices are a mystery to me:
1: When I put a Pixel on a table, it sits there stable. Because the backside is symmetrical. When I put an iPhone on a table, it wobbles.
2: When I sort my photos on a Pixel, I sort them in folders. The "camera" folder is where the unsorted photos are. When I sit in a bus or in a cafe, I go through it and sort the new photos into folders. This seems impossible on iPhones. Everything stays in the main folder forever. You can add photos to albums, but that does not remove them from the main folder. So there is no way to know which photos I have already sorted.
3: On Android I can use Chrome. Which means web apps can use the File System Access API. This makes web apps first class productivity applications I can use to work on my local files. Impossible on iPhones.
I'm sure people who prefer iPhones have their own set of "this clicks with me on iPhones and puzzles me on Pixels" aspects?
Is this a "left brain vs right brain" type of thing? Do most HNers prefer Androids?