1. 6

    I’m all in on Apple keyboards these days: a Magic Keyboard at the office, gathering dust, and an older USB model at home. I’m not religious about them being Apple, but I want a small keyboard (none of that stuff to the right of the Return key, forcing me to move my hand farther when reaching for the trackpad), I need the Mac layout, and I want a chicklet keyboard or whatever you call the laptop style keys. I’ve been on those since the turn of the century, a lot longer than I’ve been on Apple hardware. I’d like to get a Magic Keyboard at home, too — I really like it not being quite as mushy as this old one — but I’m it’ll return to the inverted-T style arrows the way the laptop keyboards did.

    1. 4

      I’m already tired by all those articles about Apples new chip. 🤷‍♂️ Are people now hyping every new chip as long as it is coming from Apple? Will anyone say a word if the next generation of Intel chips beats the M1 except of course “Apple will surely bring out the M2 soon”? And when do people finally stop to try to bend their needs towards apple products? How many complaints did I hear years ago about how docker is shit on macbooks and how many people celebrated the fixes to those issues that are now suddenly “ok without docker and surely Apple will fix this issue in the next generation”? [/rant]

      1. 6

        (Disclaimer: I’m a Mac user, don’t have a M1 Mac, don’t know when I will have.)

        I think there’s a worthwhile secondary point to this hype: it’s not just how great the new chips are, it’s also about how slow the progress of x86 (and especially Intel) has been. Apple is showing what’s possible right now; people buying non-Apple products should be demanding similar performance from their suppliers.

        1. 3

          Probably because Apple’s the only one:

          1. Making chips that are fast. Intel and Qualcomm have been stagnating and we’re celebrating AMD for catching up. As soon as A7 came out, people drew comparisons to “shit, this is fast as Haswell-U”, and then the rumour mill started. From them on it’s been basically just linear improvements every year like clockwork - something Intel hasn’t done in a while. We’d be singing a different tune if Intel actually was improving their CPUs.
          2. Making chips in devices that people can just go out and buy, and are likely to use. Yeah, Neoverse might be nice, but it’s a lot harder to get your hands on it other than “mmm rent from AWS”. This is something you can walk up to the store and buy in a phone/tablet/laptop - one of the most popular makes, at that.

          Disclaimer: I bought a new MBA, and I wouldn’t have otherwise if it weren’t for M1. I know a lot of people in the same boat (buying Macs when they wouldn’t have otherwise) because it’s that significant of an event. If they aren’t buying now, they will next year when the other models get refreshed

          1. 2

            I may be incorrect, obviously, but it seems the point is that the next round of Intel chips won’t compare IF Apple ARM can continue increasing core count, with excellent compilers.

          1. 21

            The responses to this post are pretty spot on. Asking people to hand-edit XML files to do UI design is stupidly backwards and I can’t even…

            1. 18

              … poster proceeds to edit HTML and CSS in an IDE, watching results in a browser.

              1. 9

                Yes, this blog post is missing the part where another better tool is recommended.

                1. 5

                  Yes, we should be drawing mini ASCII art instead:

                  "H:|-[button1(200)]-(>=10)-[button2(200)]-|"
                  
                  1. 3

                    Do Apple developers still use this?

                    1. 3

                      No, that was the first version of auto layout. I remember using this syntax for one year, iOS SDK 6 I think? Tools / SDK releases are annual just like phone hardware, and we’re on SDK 14 now, so it has been a good while. Anyway there was one initial year where Interface Builder, the visual layout tool, made constraints hard to get right, and that year my teams did constraints in code. We came around to IB again when they improved it a year later.

                      The primary ways to define constraints now are either to draw them in Interface Builder or use a new more expressive and type-safe code syntax. If I recall, that was new with SDK 8. I believe all of this was pre-Swift.

                      However the true new hotness is SwiftUI, which is a React-like declarative UI system that tends to operate in flexbox-like stacks and permits specific, dynamic layout in ways other than a system of linear equation constraints, so your don’t then have to debug them for over- or under-definition. SwiftUI cannot yet do everything, so adoption is slow, but that’s the state of the art over in Apple dev world.

                      Suffice to say, VFL is ancient history.

                      1. 2

                        I suspect it’s not very popular these days. VFL dates back to the time before Swift when ObjC would have forced extremely bracket-y APIs. With Swift we get more fluent APIs.

                        Many new projects probably start with SwiftUI, a completely new UI toolkit. It’s still limited, but nice where it works. Most UIKit/AppKit apps use Interface Builder, Xcode’s graphical GUI builder. Of those that prefer UIs in code (I certainly do), many probably use a third party wrapper around auto layout, such as SnapKit:

                        box.snp.makeConstraints { (make) -> Void in
                            make.size.equalTo(50)
                            make.center.equalTo(container)
                        }
                        

                        Or they use Apple’s newer anchor API which is almost as nice:

                        NSLayoutConstraint.activate([
                            box.widthAnchor.constraint(equalToConstant: 50),
                            box.heightAnchor.constraint(equalToConstant: 50),
                            box.centerXAnchor.constraint(equalTo: container.centerXAnchor),
                            box.centerYAnchor.constraint(equalTo: container.centerYAnchor),
                        ])
                        
                  1. 2

                    I always just kind of felt like it was done. Complete. Nothing left to take away and little left to add. I used it almost daily for about eight years starting in 2009 in a proprietary product that relied very heavily on xml, xslt, and XPath. I will admit, though, that the things that were missing that I kind of wanted we ended up adding in the form of xslt extensions. So, I may be looking back through rose-colored glasses.

                    1. 2

                      I haven’t used XPath in several years, to the point where I tried to use it a few years ago with xmlstarlet and discovered I had forgotten all about it, but I recall from my years in the enterprise and semantic web world it being the one XML technology that basically just worked without any problems.

                      1. 1

                        Can you share what some of those missing things were?

                        1. 2

                          I had a version of this documentation open in a browser window or tab almost continuously for at least five of those years

                          https://www.ibm.com/support/knowledgecenter/SS8NLW_11.0.0/com.ibm.swg.im.infosphere.dataexpl.engine.doc/c_xml-xsl-viv-extensions.html

                          Things I can easily remember are some conditionals like simple if-else and switches, easy string concatenation and some other string operations, and tokenization including iteration (if we needed to do something an arbitrary number of times, we would have to create a string with N spaces and then iterate on tokens within that string).

                          We had to do some calisthenics sometimes to get the job done but this stuff formed the foundation of a 100 million dollar product so it wasn’t complete garbage!

                      1. 3

                        As often comes up here and on HN, it seems like self-hosting is often a step that young languages take to stress-test the language, but compiling a programming language is a different tasks than general purpose programming tasks.

                        I’m curious if anyone knows of any relatively popular languages that did not go through the self-hosting-compiler stepping stone, and, if any, what project did those languages use to sort of “prove themselves”?

                        1. 3

                          Swift hasn’t gone self-hosting at least yet, the compiler is still in C++.

                          1. 2

                            Rust is not self-hosting too since they rely on LLVM and rustc is not sufficient to build rustc from source.

                            1. 2

                              Thinking for like 30 seconds more, I have a list:

                              • C# (recently it is self-hosting but was popular before self hosting)
                              • python, javascript, ruby, php, R; although not sure if interpreted languages count

                              It looks like most of the other relatively-mainstream (non-interpreted) languages took the self-hosting route so maybe there aren’t any success stories/project examples for languages that took a different approach

                              1. 1

                                Sticking with just compiled languages, these don’t have self-hosting compilers (brackets show compiler implementation language): Java (C++), D, Objective-C, Julia (all C/C++ and LLVM), Elm (haskell), etc. Fortran probably had a self-hosted compiler at one point, but nowadays all the implementations are in C.

                                1. 2

                                  I didn’t include java b.c. this wikipedia page lists it as a language with self-hosting compiler: https://en.wikipedia.org/wiki/Self-hosting_(compilers) but I don’t see any evidence of that anywhere else.

                                  Objective-C and Fortran/Julia are both interesting as far as the how did they prove themselves question goes. Both sort of had a target market in mind, so they just started building things to meet the needs of that market. I suppose elm falls into that category as well.

                                  I guess something like a web server or database might be a good proof-of-viability for a language like zig as well, however, it looks like my premise for “why selfhost” is wrong in zig’s case, see: https://github.com/ziglang/zig/issues/89#issuecomment-328214707

                                  1. 4

                                    IMO the most compelling pro for self-hosting is that everyone who uses the language can read/debug/extend the compiler. Its much easier to onboard new contributors if you don’t require expertise in an additional language.

                            1. 1

                              From what I’ve seen I really like Swift a lot. I like it way more than Rust, but I feel like all the momentum is with Rust, at least if you’re writing on non-Apple platforms. I’m working on a new project and I chose Rust for that reason.

                              How do people feel about the future of Rust vs Swift, especially on Linux?

                              1. 2

                                I think Swift may be a more suitable choice than Rust if you aren’t doing systems programming. You get most of the speed, a very similar type system and nice immutable value types, and don’t have to deal with the borrow checker. But they’re similar enough that it wouldn’t surprise (but would disappoint) me if Swift didn’t find its niche outside the Apple ecosystem.

                                1. 2

                                  It is … just different. Swift for most is an application language, much like C# / Java before it. I use Swift more and more in Linux as a more serious language than Python if I want to keep some logic for production use.

                                  Swift has certain constructions (such as object references) make writing abstraction-free code impossible. It also has certain performance cliffs that to optimize away means you need to write non-Swift Swift code. Otherwise, the language itself is very expressive, if you stick with the latest version. Protocol / associated-type based programming can produce some very satisfying interface if you don’t need backward compatibility (you don’t if you do Swift on Linux). Hence, I really thought Swift as “static typed, faster” Python for my Linux usage.

                                1. 2

                                  NetNewsWire (Mac), Reeder (iOS). Feedbin for syncing. I used FeedWrangler for syncing for a while but its Unicode support was broken. I’ve also used Reeder and ReadKit on Mac; using a sync service makes it easy to experiment with different apps.

                                  1. 3

                                    I was just thinking the other day I should blog about one (super trivial) Alfred workflow I wrote and how Alfred’s choice of export format, a zip with a custom extension, makes it unnecessarily difficult to version control and share these things. Having a project folder format with a plist/json file describing the relationships of objects and plain text files for individual elements would both help during development and make it easier to inspect other people’s workflows.

                                    1. 3

                                      Interesting, I came to a similar conclusion.

                                      I’m not familiar with aldredworkflow-files and wanted to inspect the code so I downloaded it and begun by opening the binary in view, saw that it was a binary archive resembling something of a zip by the file-headers so sent it to file and confirmed it, the nice thing is that unzipping it showed that the actual code is in a plist-xml-file so the code is readable.

                                      From my point of view it would make more sense to check in the individual files of the .alfredworkflow-file instead and create the zip as a part of the build process instead (since it’s essentially a build artefact), a simple makefile which zips and renames would do.

                                      To take another example python have the exact same thing with .pyz (and pex) which is a zip-file containing the files of a project (and commonly vendored dependencies) but I wouldn’t check the .pyz-file into my git-repository, that’s just an artefact produced by my build scripts.

                                      1. 2

                                        I just went to view the code and thought similar.

                                        I’ll ask the Alfred authors if they already have a systematic way to version control workflows.

                                        1. 1

                                          Agree! If you find a better way I’d love to know. I also don’t like installing workflows from other devs without vetting them first.

                                        1. 3

                                          Can any lobsters using HTTPie explain what drew them away from curl or what about curl pushed them to HTTPie?

                                          1. 8

                                            I haven’t been using it for long but for me the nicest thing so far is being able to see the whole response: headers, body, and all of it syntax-highlighted by default. The command-line UI is a little nicer as well, more clear and intuitive.

                                            It will probably not replace my use of curl in scripts for automation, nor will it replace my use of wget to fetch files.

                                            Now if someone took this and built an insomnia-like HTTP client usable from a terminal window, then we’d really have something cool.

                                            1. 1

                                              I’m guessing you mean this Insomnia. Looks cool. Good example of an OSS product, too, given most features people would want are in free one.

                                            2. 4

                                              I use both depending on circumstance (more complex use cases are better suited for curl IMO), but the significantly simpler, shortened syntax for HTTPie as well as the pretty printing + colorization by default for JSON APIs is pretty nice.

                                              1. 3

                                                I wouldn’t say I’d been ‘pushed away’ from curl, I still use curl and wget regularly, but httpie’s simpler syntax for request data and automatic coloring and formatting of JSON responses makes it a great way to make quick API calls.

                                                1. 3

                                                  Sensible defaults and configurability.

                                                  1. 3

                                                    It’s all in how you like to work. Personally I enjoy having an interactive CLI with help and the like, and the ability to build complex queries piecemeal in the interactive environment.

                                                    1. 3

                                                      I like short :8080 for local host syntax.

                                                      1. 2

                                                        I need a command line HTTP client rarely enough that I never managed to learn curl command line flags. I always have to check the manual page, and it always takes me a while to find what I want there. I can do basic operations with HTTPie without thinking twice and the bits I need a refresher on — usually the syntaxes for specifying query parameters, form fields or JSON object fields — are super fast to locate in http --help.

                                                        1. 1

                                                          curl is the gold standard for displaying almost anything including tls and cert negotiation. i use bat mostly now though for coloured output and reasonable json support. https://github.com/astaxie/bat

                                                        1. 4

                                                          I agree in principle, but in practice Instagram — despite the flood of ads — is the one social network I still find a pleasure to use, because of the focus on the photos instead of links. Compare it to the bullshit on Twitter and Facebook, both filled with links to polarizing clickbait instead of actual personal content. Maybe there’s a middle ground where they could allow links without thumbnails/excerpts, but in their position I’d be extremely conservative about what to change.

                                                          1. 1
                                                            • Your standard iOS development setup: macOS, Xcode, Terminal.app (using Fish as the shell.) Lots of other standard macOS and iOS apps too: Safari, Mail, Messages, iTunes/Music, Calendar, Reminders, Notes.
                                                            • Git: Fork
                                                            • Documentation: Dash
                                                            • For non-iOS development needs: Visual Studio Code, and Vim for quick editing tasks in the shell.
                                                            • Notes (I use some kind of very fuzzy logic to split between this and Apple’s Notes): Bear
                                                            • Calculator: Soulver
                                                            • Twitter: Tweetbot
                                                            • Password management: 1Password
                                                            • RSS reader: Reeder
                                                            • Todo lists: OmniFocus
                                                            • Work related: Slack for chat, Basecamp for project management, Clockify for time tracking, Figma and Zeplin for working with designers
                                                            1. 8

                                                              To me Mercurial was nothing but a barrier to collaboration. Maybe it’d be fine in a parallel universe where it won, but in this one it was yet another odd tool to learn.

                                                              I’ve been told it’s much better than git, but when I tried it I found it merely had a different set of quirks. I’ve created a branch and couldn’t find a way to delete it (apparently there’s closing vs stripping, and all my experimental garbage branches called asdfsadlkjl were supposed to keep permanent tombstones? No thanks). I’ve tried to clean it up by rebasing, but it required adding a plugin in 3 places.

                                                              1. 7

                                                                Mercurial “branches” are very different from git branches. Yeah, the naming is confusing now because git won, and everybody thinks in terms of git naming conventions. In my experience, mercurial is less inherently quirky than git. As other people have said, the UI is much much cleaner for hg. git and hg are almost identical internally, hence why it’s possible to use git-hg and hg-git bridges. The only real differences are in UI, culture around usage, and the tooling ecosystem. On both UI and culture, mercurial wins imho, but the ecosystem is much much bigger for git. Today, the ecosystem for mercurial just got that much worse sadly…

                                                                1. 3

                                                                  I’m happy to believe hg is better. That’s not a big ask.

                                                                  I already have to know git in order to function in my part of the industry. HG is another, also-imperfect thing I’d have to learn.

                                                                2. 1

                                                                  Just add some more detail to the discussion about branches: hg’s branches are indeed more heavy weight and permanent than git’s. If you want git style branches, hg’s bookmarks are what you’re looking for.

                                                                  The last time I looked Bitbucket still didn’t support creating PRs from hg bookmarks, which was annoying for a feature branch/PR style workflow. Their focus had been away from hg support for several years.

                                                                1. 5

                                                                  UpCloud has its headquarters in Finland. I had some issues with their service when I tried it, but it was six years ago and I expect it has matured since then.

                                                                  1. 1

                                                                    Haven’t had any problems with UpCloud, and their disk speed seem far superior to any other provider

                                                                  1. 3

                                                                    I instead have a script at ~/bin/git-bs, with contents:

                                                                    git branch --sort=-committerdate "$@"
                                                                    

                                                                    This allows me to see a list of all branches, sorted by Most Recently Used, by typing: git bs.

                                                                    1. 2

                                                                      In a similar vein, I use a git-bsel script that runs peco:

                                                                      git branch | peco --query "$*" | cut -c 2- | xargs git checkout
                                                                      

                                                                      That gives me interactive selection with search.

                                                                    1. 3

                                                                      Whenever I look at git log‘s man page I get sad. In mercurial almost all of git log’s options are covered by the revset and template system. These systems are general enough that they can be used for lots of other commands besides hg log. On the whole it’s things like this that make mercurial much easier to use from the command line than git.

                                                                      1. 1

                                                                        Yeah, the forest of options Git has for doing what Mercurial does with revsets and templates makes the already bad CLI design even more painful to live with. At least the rest of the documentation would be easier to browse if they had similar systems in place.