Geez, as a Korean I routinely feel the western media likes to picture East Asia as some Sci-Fi world.
The mentioned ‘serving robots’ are just a table with wheels, nothing else. No reason for people to feel them as ‘companions’ or such. You just pick your menu in your tablet on the table, and when time passes, the food rolls over. This is not rocket science, people.
The mentioned ‘greeter robot’ is literally a tablet with wheels, and is useful because it doesn’t try to do anything clever; it’s really just a rolling kiosk, and people use them as such.
I mean, like come on. This isn’t anything headline worthy, especially not something to describe East Asians as people who routinely interact with ‘warm-hearted’ humanoid robots.
(Not to mention that 1/3 of the story is about a Japan-heavy robot-concept hotel chain… but that’s a different issue.)
Hmm… can you elaborate? AFAIK MacPorts never touches outside /opt/local in it’s default configuration, and it requires sudo, so it doesn’t have the finicky permission problems that homebrew had on multiuser systems.
It's funny to see one arguing that Rust programs will be higher quality... in the GUI space. The AreWeGUIYet[0] website shows clearly that a GUI editor written in Rust won't cut. I'd rather argue that editors written in the platform-native language (e.g. ObjC/Swift on macOS) will result in higher quality editors.
If the author is viewing this comment, I'd recommend BBEdit[1], a solid & classic option. Other options might include Chime[2], a Go/Ruby-focused native IDE, or Nova[3], a VSCode-alike native-focused editor. I'm not sure if Chime or Nova would be as stable as TextMate though.
Documenting the ‘how’ part, i.e. the documenting the assumptions that the author had on the context this code runs is important; you guess just enough by grepping calls to the function in the codebase, add add some code that works now… and then the original author or another person adds a call that breaks the assumptions you made, and breaking everything… subtly.
I’ve felt the same way with GP; IMO the big issue is that the thing that I’ve written or drawn changes during writing. This removes the pen feeling of the Apple Pencil and feels more like a graphic tool? So like drawing circles feels fine, but writing text and seeing that the text feels wobbly while writing gives me the perception that the pencil is not meant to write text in Muse.
That’s more of a compatibility solution than an escape hatch. An official SwiftUI escape hatch should have access to the underlying imperative object, call methods on it, etc… Unfortunately the underlying ‘things’ in SwiftUI is implementation detail, inspecting the view hierarchy and finding the UIViews that implement a SwiftUI view is a hack.
IMO SwiftUI feels limited b.c. it breaks itself away from the UIKit world: React succeeded because it is the DOM with all of raw HTML & CSS, a thin abstraction with official escape hatches. Mixing imperative and declarative code is natural and more abstractions can be built.
Instead, SwiftUI adopted a whole new set of primitives that doesn’t mix. Accessing the underlying UIView is discouraged, and wrapping up UIKit in SwiftUI feels like a legacy feature. IMO SwiftUI should have been a thin wrapper on UIKit.
Admittedly I’ve never seriously investigated Clojure debugging tools so it might be that Clojure already supports something similar; but the Debugging Common Lisp[0] series might showcase how Common Lisp (with signals, restarts, mechanisms for redefining classes, p and more…) and SLIME aids debugging in how other ‘usual’ languages don’t.
I find the argument that you shouldn’t be using serverless because you don’t have money to throw on devops a bit… strange? Isn’t the big reason on using serverless to avoid spending money and time to managing your own server?
And IMO the lambdas-are-cheap argument is more like that lambdas are expensive, but they multiply to your scale, so it’s super-cheap in small startups. I view lambdas as a starting point for PoCs — they eventually have to move to VPCs, but lambdas are free if it gets no traffic.
And that’s why I’ve mentioned lockin-free APIs: lambdas are terrible if you can’t migrate away from it. But if you can without much effort, it provides pretty good value.
There was a hype on serverless, so a lot of people here on HN is a bit allergic on them and tell ‘an EC2 instance is all you need’. And it’s not wrong — I’ve seen seriously over-engineered serverless systems with so much AWS-specific code. But a few years passed now a lot more services now provide (almost) lockin-free APIs that are pretty useful for simple.
IMO blindly recommending ‘just self host’, a sentiment that I see a lot in HN isn’t a good answer.
Hmm, at a glance this looks like it’s aiming to share funds of big, top-level projects to it’s dependencies. And for that, a big component of the project is a package manager… and the whole system is notably designed by the creator of homebrew. Seems like the blockchain is involved to guarantee that the fund sharing happens automatically.
I’m almost always doubtful on blockchain projects, but this does feel like something that might have a slightly bigger chance to succeed than other more scammy projects. I’d appreciate a less buzzword-heavy site though.
My main objection of this would be that dependencies might start gaming the system though. Would expect a bit more info on this in the webpage.
Yes, it does. But then creating TUIs now require as much complexity as creating single window GUIs (requiring handling events outside the program), and you lose the aspect of 'creating TUIs are just printing VT codes'.
That's an argument for making GUI libraries more ergonomic, not to keep making TUIs. And TUIs made by "just printing VT codes" will break when you resize the terminal, change the font size, or more.
CLIs (that read input from stdin and spit out results to stdout/stderr) are useful in an automation/data processing pipeline. But TUIs are a gimmick that should have been just GUIs. (And text selection is not a reason to resort to TUIs — it’s a reason to improve GUIs.) Unfortunately native GUI programming doesn’t have the coolness/geekiness factor of TUI apps…
Edit: Looks like I should clarify – I'm not saying that people should stop creating TUIs right now: in the current landscape, TUIs do have advantages like being usable over ssh, text selection, a simpler programming model in most languages... but I'm arguing that these advantages aren't inherent to TUIs. We should aim to improve GUIs, not stuck in a interface from the 70s. Unfortunately I've seen too many people (including a big chunk of HN) that argue that TUIs are just inherently superior.
Macs does support non-integer scaling. In fact, macOS currently ships non-integer scaling by default in certain MBP models. It gets criticized from time to tome, though the newer 14/16” MBPs ship 200% as default again.
I'm viewing that this is an effort (not probably appealing to the HN crowd) to gather developer interest and make desktop apps make sense again. This is probably Microsoft eating their dogfood on their critical components rather relying on a cross platform code base. (FYI, the whole React Native for Desktop thing was started and is being pushed by Microsoft.)
Interesting for the “GIF” section to have links to .mp4 videos — the “GIF” word now seems to be synonymous to short playable animations. Love that the author did that though, I’ve seen too many repos with multiple giant (~10MB) GIFs on the README and burn my mobile data plan.
The mentioned ‘serving robots’ are just a table with wheels, nothing else. No reason for people to feel them as ‘companions’ or such. You just pick your menu in your tablet on the table, and when time passes, the food rolls over. This is not rocket science, people.
The mentioned ‘greeter robot’ is literally a tablet with wheels, and is useful because it doesn’t try to do anything clever; it’s really just a rolling kiosk, and people use them as such.
I mean, like come on. This isn’t anything headline worthy, especially not something to describe East Asians as people who routinely interact with ‘warm-hearted’ humanoid robots.
(Not to mention that 1/3 of the story is about a Japan-heavy robot-concept hotel chain… but that’s a different issue.)