pcr910303

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.

AFAIK It’s http://libdill.org now :)

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.

[0]: https://www.areweguiyet.com

[1]: https://www.barebones.com/products/bbedit/

[2]: https://www.chimehq.com

[3]: https://nova.app

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.

> you’re manipulating lightweight structs that are rendered into heavyweight views by the system

Yes, and I’m arguing that not exposing the ‘heavyweight views’ to the programmers at all is a mistake.

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.

[0]: https://malisper.me/category/debugging-common-lisp/

FYI: The language was released a few hours ago.

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.)

An off-topic comment:

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.

My theory on this is that GUI automation is way harder because most solutions requires the developer to explicitly spend more time on implementing something that is not usually useful to sales (non-automatable applications are the norm, and people don't decide to buy apps based on whether it supports automation or not).

CLIs are much easier because the primary interface (standard out) to communicate with the user is basically the automation API (whether it is stable or not). If you're a command line program, (unless you're doing something super wary), you're automatable.

My personal opinion is that the best way should support automating based on GUI interfaces… although I don't have any great ideas how to support various interfaces that are e.g. modal or contextual. The clipboard is basically poor man's pipes in the GUI world so we could take some ideas on how the clipboard and the source/destination application negotiate data types, and there probably are better ideas.

A bit different, but I really appreciate when web apps use the HTML5 history API to implement back buttons, e.g. Twitter. It makes the history queue that appears when long-clicking the back button so much more useful.

It looks like the browser crashes on every screen change on Safari 15 on macOS...

I'm not sure if this is something I am fine to say, but I've never signed an NDA or something so I'll just say: (Moderators, feel free to hide this comment if you would rather not like an influx of alpha testers.)

If you sign up to the alpha-testing HN[0], you get access to the thread feature, which is... (quoted from my forwarded mail)

> New feature: when you visit a thread, the software now highlights

> comments that are new since you last viewed the page. These are

> displayed with an orange (or whatever your topcolor is) bar to the

> left of the new comment. Refreshing the page will reset these.

Very useful, I can't imagine having HN without these indicators any more.

[0]: https://news.ycombinator.com/item?id=22788678

I think the throwback on HN on this decision is due to the lack of details and context on the news?

From what I've understood from the local news (I'm a South Korean), It's not about blocking handsets with forked Android (that already happens regularly AFAIK), but the requirement of shipping Google apps like Chrome and Google Assistant. The big elephant in the room here is Samsung phones, which do ship it's own custom browser Samsung Internet (BTW, with ad blocking capabilities!) and a separate virtual assistant, Bixby. That's the part where the KFTC decided was monopolistic.

I don't have a personal opinion this, but seems that the comment threads are focusing on the wrong part. Manufacturers were always able to bundle up their fucked-up version of Android. They were always able to ship super-custom UIs. Google never prevented that... but they did force the UIs bloat by having two separate default apps.

The law isn't even active yet, to say nothing of retroactive. It just only passed the National Assembly (i.e. Congress), not even announced by the government. It probably won't happen, but theoretically the government can reject the law as well.

> Korea is probably the most fanatical about gaming

But Fortnite has never cared about Korea, most of the fanaticism on gaming is for PC games (mobile non-casual games were never big), and Fortnite has never even had any relevance here.

As a Korean, it feels very, very bitter and spiteful for Epic to mention Korea like this. As if... Epic has ever thought of Korea as a somewhat meaningful market for Fortnite.

This blogpost shows how learning how to make languages are useful. I would’ve never considered making a comment DSL that describes code snippets in books.

The blogpost on actually typesetting it is also very interesting[0] — you should really check that post out as well.

[0] http://journal.stuffwithstuff.com/2021/07/29/640-pages-in-15...

Mostly because the dev linked to the Homebrew installer when announcing(?) it on her Twitter account[0], but also because the forked repo[1] that contains the patches just shows the original README.

This isn’t an official port to the M1 — it’s a custom version patched by a different dev.

[0]: https://twitter.com/simnalamburt/status/1434244533001224192

[1]: https://github.com/simnalamburt/podman

I did not realize that SQLite now has a pending feature called 'Strict Tables'[0][1]. Mindblowing. I can't wait to try using this in the wild.

> In a CREATE TABLE statement, if the "STRICT" table-option keyword is added to the end,

> after the closing ")", then strict typing rules apply to that table.

I'm guessing that addition is reason why this document was recently written and is a draft, I guess.

[0] https://www.sqlite.org/draft/flextypegood.html#if_you_insist...

[1] https://www.sqlite.org/draft/stricttables.html