pcr910303

For that to happen, China Italy has to start a war. HK was under control of mainland China since 1997, Taiwan isn’t. They have a separate government.

Similar to South/North Korea.

> I think we'll see this happen with Facebook Messenger. Both the apps and the website have become slow and painful to use and get worse every month. I think we'll start to see engagement numbers dropping because of this.

In fact, I think the iOS app for FB Messenger did get a redesign due to problems and it’s rewritten from scratch? I remember being pleasantly surprised after the big update… It became lightweight, integrates well with iOS and supports platform features.

On the other hand, the desktop app or the website is a shitshow :-(

While they might not know the specific term, they do know that something is different with those services b.c. they can’t save the ‘gif’ videos as easily as they can with real gifs.

To me, the most impressive use of tree-sitter was an iOS text editor that uses it to parse huge JSON files / mixed language files and highlight them in a very robust way. [0][1] I’m hoping tree-sitter becomes more common like LSP and Emacs can get exact highlighting and other tools with it…

[0]: https://twitter.com/simonbs/status/1352697855845273600

[1]: https://twitter.com/simonbs/status/1362492842141171720?s=21

So a bunch of people on HN are now arguing that GraphQL should disappear?

GraphQL is a genuinely objectively useful technology in places that have a frontend-backend split (including non-web frontends). It doesn’t require building specific APIs for specific pages for speed concerns. It allows backends to add fields non-destructively (RESTful JSON does work at the cost of a bigger network payload).

GraphQL provides the right tools for the right problem, and has created an ecosystem around it. (How should I reliably compute a SQL query cost? How should I control data access policy in SQL? How should I return the SQL result in a easily-parsable format?)

If you're using 1Blocker, you might want to turn off the (memory-leaking) 1Blocker Button until an update shows off...

Worked like a charm at least to me :-)

https://twitter.com/kb091412/status/1330470681813934086

Wow, HN is so much strict to Apple. I'm already seeing 4 ~ 5 top level comments on how Apple "locks down" computers and they are "taking our freedom"...

Apple have stated multiple times that they don't have any intention to lock down macOS more or less - I can't really think why anyone would think Apple would lock down macOS. There's... really no reason right?

My gut feeling is that there are a lot of people that don't like Apple, mostly due to their proprietary nature, and they just... argue against Apple. Before the M1 appeared, the argument was that Apple's Macs are expensive for nothing, they have terrible hardware, Touch Bar is bad, software quality has declined, etc... and now it's all about the user's freedom.

Seriously people. This article is about using dev tools on the M1 Mac. Let's not start arguing about how Apple is bad for freedom, etc.

While I won’t go that far, arguing that macOS with a Windows 95 UI is a good idea, I do agree that Big Sur’s current UI is a mess.

Traditional macOS users valued the Mac user interface deeply, and IMO that was why while iOS 7 got a big refresh, macOS got a much smaller one, only with flatness refinements. Big Sur feels like the iOS 7 for the Mac, and I’m very sad that I’ll have to wait at least 4~5 years to see the new interface improve in a better state.

Some of my key annoyances (except for bugs):

* The new control center now requires more clicks, but due to the padding getting bigger, I can’t put all of the shortcut icons in the menu bar

* The new control center and notification center’s UI is so foreign from other parts of the macOS. It’s just… so custom.

* There are now multiple variants of the title bar thickness, and all of the Apple apps now use all four. It just feels ugly. The title ban of the Photos app and the Calendar app are almost the same — why does one use a .unified one and one uses a .unifiedCompact one? And why does Safari uses a .unified one when it doesn’t really have any information to convey?

* This is from Catalina, but the NSSwitch stuff collides with checkboxes… but well I’m guessing that’s for Catalyst trying to look native

I can go on and on… but my general feeling of Big Sur’s UI is that it would take multiple years to make this better.

I consider the libraries of the languages that allow the programmers to do everything (e.g. Python or JavaScript) are good at this: The library authors signal that these functions should not be called and these can be, but ultimately if you’re monkeypatching or something you can really do this. Obj-C is also a good language in doing this too…

I’m not sure if I would call SQLite’s needs incommon — in a perfect world, every app should have SQLite’s properties like preserving user data on power loss, etc… It’s just that other apps just don’t care enough about these issues as much as SQLite.

For example, I’m pretty sure I would like every app to automatically handle cases where the underlying file gets renamed or removed. (AFAIK apps that use the Cocoa API automatically does these.) However there really isn’t any POSIX API that allows handling these kind of situations — and to do these now you need to do all of these nitty-gritty things that SQLite does.

In fact, I think that the reason why SQLite needs all of these nitty-gritty details that does everything is because of an insufficient abstraction. If the file APIs were better and didn’t require everyone to consider whether you have to call fsync or not, SQLite wouldn’t have needed any of these. But well POSIX have flied and here we are.

Oh, I didn't realize that! That's great to hear!

This would be great if I can upload & select my own fonts, or to have other fonts than Roboto. That would truly allow multiple character-favicon variants from one site, which would be very useful.

You can look at Smalltalk, which is a great example where names parameters without parens works great. But that doesn't mean that named parameters with parens are bad, yet that's what GP is suggesting. (For context, he's the designer/implementor of Obj-Smalltalk that runs on the Obj-C runtime.)

> It unwisely rejected the parsimonious case and chose tremendous complexity.

Swift's keyword syntax isn't complex at all.

> Keywords? Or parens? Both!

I know you like Smalltalk, but keywords and parens are used together in a lot of languages (e.g. Python) so it's a tested idea.

> And the weird case of having two keywords, one with a colon and one without, because we decided to make the keywords the names of the parameters. Sometimes.

You don't have two keywords, you have an optional variable name. It's intuitive at the first time you see it - you're phrasing makes it seem much more complex than it really is.

I think you're trying to imply that Swift isn't an elegant language with it's syntax fitting in a postcard, but that doesn't mean it's 'tremendous complexity'. This whole comment is a bit too harsh to Swift, calling the legitimate differences between Swift and Smalltalk as 'complexity'.

Well, the syntax is same - the ideas are different. Trailing closure syntax is basically 'you can remove the parens if there are trailing closures'. Which, if you apply that to multiple closures, you get the syntax that also looks like Smalltalk. Which is understandable, since Swift keyword calling syntax was always 'keyword followed with a colon' since Swift 1, which was inspired by Objective-C, which was inspired by Smalltalk. But then that's not adding Smalltalk syntax in a later stage, it was baked into the language since day 1. That multiple trailing closure syntax - that syntax can come out from anyone knowing Swift without any Smalltalk knowledge, it's a logical next step. So it feels a bit weird to call it 'adopting Smalltalk syntax' since I don't think Smalltalk influenced that syntax any more than other parts of the language.

I think OP is claiming that if Swift had better meta programming abilities that GP have suggested, differentiable programming would have been a prime example for a good use of the capability.

I don't think that adopting a syntax that looks similar to Smalltalk means it has 'adopted Smalltalk syntax'. I like Smalltalk as a language, I do think that Swift would have been better if it's runtime model was more similar to Objective-C and Smalltalk, but it's not fair to say Swift 'added Smalltalk syntax to address a special case'.

I do agree in general that Swift can benefit from a reduction of special cases, but my personal feeling is that Swift is getting more consistent every version (at least in the features that already existed). YMMV, of course.

Related: There recently was a Twitter thread that you might be interested in: It's about the need for a new ABI which covers the middle ground of Rust, Swift, Zig, Nim, and other mid/low level languages, with lifetime annotations baked in so that the language can read them and manage memory without the need of developer's manual help.[0]

[0]: https://twitter.com/bitshiftmask/status/1286411475658178561

While I don't think adding C++ interoperability is one of the'mashup of features', one example of a feature that adds complexity and conflicts is the function builders (result builders)[0].

It doesn't interact well with other language features (e.x. if let wasn't supported for a long time), it isn't really extensible (transforms are specified by the language), and yet it adds a bunch of complexity in both the language, implementation and reading code.

It seems clear, at least to me, that this is something that happens if you try to make a feature 'generic' without a lot of time and design consideration, due to Apple's internal politics on SwiftUI. I like SwiftUI, and some features that support it are great (like custom attributes), but I firmly think that they should have taked the time to produce a better design.

[0]: https://github.com/apple/swift-evolution/blob/main/proposals...

Well, I don't know about your nationality, but as a Korean person I found that the lack of CJK characters in a coding font is usually a non-problem, mostly because there are almost none that have them. (Apart from some local-company made fonts, Noto CJK Mono is almost the only one... which I do not like.)

Usually you just set a fallback CJK font and just not use my native language while coding - I just got better at English while writing comments in it.

Well, that still works! (Just confirmed it in Big Sur.)

> Nowadays native apps on Mac are dead.

I know you’re saying that in a subjective way, and definitely the percentage of non-Cocoa apps have gone up, but I’m not sure if they’re dead. In fact, I feel that they are thriving once again in 2020 — a lot of indie devs that care about making Mac-assed Mac apps[0] are present and are releasing great apps and replacing ones that were filled with Electron.

Some examples that pop up in my mind: NetNewsWire 5[1] (an RSS feed reader), Shrungs[2] (a Cocoa Slack client), MimeStream[3] (a Gmail email reader), Chime[4] (a Go IDE that’s entirely Cocoa! I seriously considered learning Go because of this app), ProxyMan[5], and I can go on and on...

My feeling is that Electron got a bit of traction in like 2014~6 but people started to realize they really do like Cocoa better.

[0]: https://daringfireball.net/linked/2020/03/20/mac-assed-mac-a...

[1]: https://ranchero.com/netnewswire/

[2]: https://shrugs.app/

[3]: https://mimestream.com/

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

[5]: https://proxyman.io/

Ok, so I guess since here is HN, everyone is going to say... "Why would you 'modernize' your bash scripts? Isn't the point of scripts to avoid the GUI altogether? GUIs are inefficient, blah blah blah...". And there is a bit of truth in that, but that's not the whole story. (And since I guess I'll be downvoted heavily, I would suggest you to read this block of text before you do.)

This blog post is basically about using GUI inputs to get user input. Which means it's an interactive script, and the direct non-GUI equivalent is a TUI. Which means the script is not something that you will be automating for, but more just of a convenient interactive tool.

And by definition TUIs are an inferior version of a GUI, for example it usually won't handle terminal size changes, localization, etc... So it makes plenty of sense to make that a GUI for the sake of having a better input. (And I won't call that 'modernization', but it's a better option than presenting a calendar UI from your bash script or having me input a unix timestamp or something else.)

So then you might say that hey the command line equivalent of that GUI input is flags, not interactive input, but well you can make a CLI that gets it's parameters from flags and gracefully fallback to interactive input if you don't have sufficient information.

(And no, TUIs are not more efficient than GUIs. CLIs might be, because of shell piping and it's automation techniques. But TUIs are inferior, full stop.)

Because that means you’re writing a different dialect of JS. Especially in the Svelte case, where you just need to be aware of what the compiler knows and what they don’t. A leaky abstraction, broken magic IMO.

BTW) I would say that writing a whole compiler to add UI update logic is much ommore over engineering than this solution, or just about any JS reactivity system.

I think hooks aren't really making React more of a black box, but just that it's invalidating a lot of people's incorrect mental models on how React works. (It's like C's undefined behaviors in that sense.) And the reason why a lot of people have these incorrect mental models is that React is a very thick abstraction.

For a long, long time, I thought that to provide the values that React brings, the UI framework being a black box is inevitable. Almost all React-esque libraries including but not limited to React, Preact, Mithril felt like a very thick abstraction over the DOM APIs.

But then I saw Crank.js[0], and that felt very intuitive and a thin abstraction, while retaining the good parts of React-esque libraries. I don't really know why it feels like that - I'm guessing it's because it uses native JS features that you already have a good understanding instead of some magic that happens in the React runtime.

I'm very looking forward to it, and I would like to urge everyone to try out Crank.js if you feel that React is now not intuitive enough.

[0] https://crank.js.org

Really, am I the only person here who can't understand the complaints on hiding scrollbars? I do agree with a lot of things that resonates HN, but this is one thing that I have never understood.

Stop complaining about discoverability, everyone that knows how to browse the web knows how to scroll. It's like worrying whether the user will know how to use a mouse when you're designing a web page. Scrolling is not something like shortcuts or tabs - you need it to move around, which means you get to know it as soon as you start your computer and after the first knowing phase it's visual clutter.

Also, I would like to ask whether users will usually even want to click on the scrollbar to move around. Unless the small number of cases where the page is long and you want to move around quickly (and if you have ever been in that case, you know that even there using the scrollbar is pretty useless because it's too sensitive - you are usually less precise when you use a scrollbar, not more), there's virtually no reason to click it. Computer screen estate is precious because not everyone is using a 27-inch display (13-inch display here), so that's a pretty big reason to hide the scrollbar.

The docs would benefit from some mobile support, it's a pity that documentation sites usually don't have mobile support as if people only use documentation sites when they're coding. In fact, there are a hell lot of reasons to view them while on mobile... and yet so many documentation sites don't have responsive designs. :-(

Two devs, each frontend and backend will work out pretty well even in a super-small startup I guess?

Yeah, I'm guessing that more recent startups will have much less Ruby usage.

While this isn't a generic feature, I want to say that everyone should try embracing the non-keyboard nature of macOS (as it always has been done), not just complaining that some of the elements are not reachable in the keyboard.[0] Try using the mouse, trackpad (which is top-quality), and the Touch Bar (which I guess will be the most controversial?).

Especially drag-n-drop. I'm not sure if it's already mentioned, but the proxy icon (the icon in the title bar) is super-useful in situations when you need to find (e.g. upload/attach the file in Safari, opening the file with another app) the file somewhere else. Just drag the proxy icon and drop it to the destination, and it usually will do what you want.

Also the Touch Bar. Everybody complains about it while not even trying to take advantage of it...[1] Customize your Touch Bar so that the buttons are in a consistent way, e.g. I always put the new tab button (if it exists) in the far right, where I can reach without looking, and I put the most useful actions (like getting information, trashing files in Finder, tab switching in Safari, text suggestion, etc...) in the middle, and put the less-useful but somewhat frequent actions (like toggling the sidebar, emojis, etc..) in the left. If you consciously try using them for a week or two, you realize you're much productive using the Touch Bar than using obscure shortcuts or moving the mouse.

[0]: BTW, good news for people who were complaining - macOS Big Sur greatly increases the amount of controls reachable with the keyboard, although I dislike the fact that I have to bang more tabs to reach some button.

[1]: There's definitely Apple's fault here too, if you're using a Touch Bar equipped Mac, 'brew cask install haptickey' so that you get haptic feedback on your Touch Bar touches.