419 karma · joined March 4, 2013
I use and love 1Password, but there's no way I'm switching to the subscription model. When my version stops working (either through incompatibility or serious security flaw), I'll begrudgingly find something else to use.
Personally, I'm familiar enough with Haskell to be able to slowly work my way through most code, but I'm not at the level where I would be confident in writing anything but simpler programs.
I find idiomatic Haskell suffers from what I call "have to limit my line length-itis" - i.e. "Ord" instead of "Ordered", using "x" and "xs" as identifiers instead of e.g. "first" and "rest". This makes for compact code, but not necessarily very readable code. And for anyone who wants to tell me that it's closer to mathematic notation, well, frankly, maths could take a few hints from modern software engineering about readability.
Then there's the dissonance between actually declaring an algorithm a la Haskell/FP, and actually describing how the algorithm works.
It is sometimes nice to declare algorithms compositionally. This thing I want is the max of this joined on to five of these filtered by this criteria. Lovely. But opaque as to the implementation.
I've found that in my experience with most software I write, the parts where the exact implementation isn't that important don't take a long time to implement. Immutability, idempotency, and removing side effects can work just the same in non-FP languages here. The other parts, which almost always involve some sort of IO, require very precise control over implementation, or state, or timing, and are often very difficult to declare with "is" - sometimes the only sensible way I can seem to think of them is a series of processes.
When I try to implement this sort of thing functionally it feels like a retrofit, and never as elegant as the simple imperative "do this, then this, then that".
I'm not trying to be anti-Haskell or anti-FP - I love and use FP principles every day. But I'm definitely in the camp that thinks "pure FP" is the best solution to only a small set of problems.
To me, where Haskell fails is that it has very little to offer for these imperative problems. Which, for many applications, makes it almost worse than even a crappy old imperative lang.
Though, will 200 hours spent learning Haskell gain you, well, anything productive?
Surely a non-genius would require at least 1000.
Putting scrolling in a tab bar doesn't allow the user to take full advantage of spatial and muscle memories.
And when those memories fail, because scrolling tabs literally removes tabs from view, the user can't even revert to a visual search to find them! Instead one has to slowly scroll through a list of identically sized tabs, hoping that window #5 is actually the one containing the desired tab in the first place.
Oh dang, it was actually window #4.
Compare and contrast this to non-scrolling tabs, where tab size continually shrinks as tabs grow in number. #1 - you can identify which window is relevant by the tab sizes alone (so even if you move your windows around you're not lost). #2 - you can identify tabs by spatial memory, because you know approximately where, horizontally within the window, your tab exists, cutting your search space down to a few tabs only. #3 - you have visual cues as to when you might need to split out into a separate window for ease of tab management.
Of course, 1px is hyperbole, but 15px-30px is most certainly not, and on a modern display you can fit very many 30px tabs in a row without scrolling.
That's not to say that there aren't limitations to shrink-to-1px tabs, of course there are. But in all circumstances as a UI tool they are objectively better than scrolling tabs, until they shrink to an unusable size. At which point, scrolling tabs still isn't a good solution to the problem (grids, multiple rows, tab lists, tab groups are all vastly better options here).
"Hey Dingbat, what's 10 percent of 50 times 33 times 125. Oh sorry, 10 percent of open parentheses 50 times 33 times 125 close parentheses".
Even just talking it is substantially slower than typing the number into a calculator. App, desktop, or phone.
I'll take 1px wide tabs over scrolling.
I feel like there's some sort of legitimate blockchain solution to be had here that doesn't involve a centralised authority. Who got there first, what domains they have owned continuously, and what products they control perhaps...
Thanks for wasting about 6 hours of my time a few months ago by forcing me to change all my non-https local DNS entries to something other than .app and .dev, and then dealing with various flow on repercussions.
Really helpful that was. Especially the latter. How many decades of man hours are you wasting from this I wonder...
My personal imposter syndrome feelings are almost always related to either a) not knowing the "replacement" to an existing technology I am already familiar with (in almost all cases it's two steps forward one step back anyway), or b) not using a technology for a somewhat extended period of time, then coming back to it and realising that the landscape and ecosystem has completely shifted from underneath me.
The latter has hit me most hard lately in iOS development with the move to Swift (and then v2, v3), deprecation of NS*, autolayouts, APNS' http2 etc etc, and in JavaScript development.
We have far too many technologies that have established niches that all accomplish largely the same goals, but aren't transferrable. These days, boosting the toolchain for these technologies is a big feature too, which increases the differences between ecosystems. They require sometimes hundreds of hours of learning to become competent in, even for an expert in another similar technology.
It's some sort of crazy arms race that we don't seem to want to stop...
It's only real flaw IMO was the superglossy glass screen. Fragile and extremely annoying under fluorescent lights. Plenty of the machines lasted a long time despite the glue deteriorating from heat.
You're right about them spending no money on maintenance because repair is a profit centre for them. Rossman is right about Apple's durability issues, too - almost every generation of MacBook has had at least one significant design flaw (from the 8600GT to delaminating screen coatings).
They're only getting worse as they go over the top with proprietary connectors and interfaces, and iDevice levels of integration. I mean, Apple have reimplemented M.2 and NVMe in their stupid proprietary SSDs at least 4 times now. It's utterly ridiculous. If your custom blade SSD dies, which it inevitably will at some stage, your only options are Apple support or OWC (or gamble with second hand parts).
At least in the past they used to get the human stuff right (mostly). No Apple MacBook has ever shipped with a low quality LCD panel, for example. I've never heard significant coil whine from any Mac. I've never heard any Mac that has loud fans at idle (except under an error condition). I've never had a Mac that burnt me. I've never had a Mac with poor speakers. The trackpads have always been best-in-class. The keyboards have always been very good.
Until 2016.
I share the frustration, mainly because both OS X and Windows are getting progressively worse over time as opposed to better, and the lack of a decent alternative is hugely frustrating.
Even Lenovo Thinkpads are incredibly diverse in terms of the hardware you can find in them compared to any generation of MacBook Pro.
I'm constantly amazed by the lack of product leadership at some of these companies. I guess the fact that they all focus on pleasing enterprises instead of actually making a decent product line-up and selling it hard is to blame.
Isn't it about time someone stepped up to fight Apple at their own game? Instead of shitting out SKUs like they have diarrhoea, have some restraint and release only a single model per machine, with SKUs modifying only inconsequential things like CPU speed, RAM quantity, and storage. Get rid of the myriad of awful Wifi and WLAN cards (that often cause issues in Windows as well).
Do this for several generations so that the basic hardware and drivers are the same for every machine in the line-up. Focus on getting the basics right - no sleep/wake issues, no finicky nonstandard hardware, no coil whine, no excessive fan noise etc.
Microsoft are trying this with the Surface range, but they're only just starting to actually position products in competition with Apple's.
If your product consists of somewhat reusable libraries that you compose together, and extend when needed, having strong unit tests for the low level functionality helps immensely when it comes time to refactor. You know, stuff like "when given int(2) and int(3) as arguments, add(int, int) returns int(5)".
Likewise those high level API tests that ensure the system-as-a-whole is still doing approximately what it's supposed to, regardless of what mess of wires and small aliens is inside the black box are super useful for moving forward as both proof of functionality and guard against regression.
It's the stuff in the middle that's icky IMO. Integration tests that are testing your glue that, especially these days with clouds, containers, microservices etc, can be quite far removed from any codebases you might maintain. I don't have a good solution for it, but I'm searchin'...
You can TDD top down by writing an end to end test, and recursing TDD down each level until you get to a single unit, repeat until all inception layers of the tests pass.
You can TDD bottom up, by starting with components you'll know you'll need, working out some APIs at their level, then doing the same to piece together larger components.
Ultimately you're in control of how your API looks, and this has nothing to do with TDD itself - if you get caught up exposing a bunch of inner workings and configurations, then you're simply not designing well. It has nothing to do with TDD.
Likewise, if you get caught short with an API that's too simple, well, that has little to do with TDD either.
What the hell are we doing?
I read text all day. Watching a video is novel and exciting, and I think I tend to pay more attention because of it. But that's just anecdotal. Grinds my gears when people suggest that "books are the best way to learn" any kind of programming language.
For the former though, I actually wish more designers had better knowledge of the "shallow and antiquated schools of thought" from the print world. A lot of that was born out of decades of iteration, and many of the toys that the web gives us aren't actually very useful for the kinds of content that many of them are tasked with publishing.
Apple's machines are far less likely to exhibit issues like coil whine, interference on audio outputs, creaks and squeaks, physically broken connectors, electrical noise on USB bus, unstable network cards, poor battery life or longevity, display flickering, poor display uniformity, backlight bleed etc etc etc.
Dell's XPS range has had massive issues with Killer wireless dropouts, crackling audio jacks, mysterious battery drain, flickering screens, and a bunch of other stuff I can't remember right now.
Lenovo's ThinkPads are consistently equipped with sub-par LCD panels (caveat: I have not tried their OLED models yet). I haven't yet met a ThinkPad that didn't have coil whine coming from either itself or its power adaptor. I haven't yet met a ThinkPad that didn't either have or develop some kind of creaking panel.
Until the last couple of years, Apple was about the only manufacturer that cared about making their laptops near-silent, whereas Dell and Lenovo were content putting in stock standard high-RPM fans and running them conservatively. I still find Apple machines superior in this regard.
These might seem like petty little things, but they are the sorts of things that drive me absolutely nuts over the ownership life of a machine.
I'd also posit that neither the high end ThinkPads, nor Dell's XPS, are actually really any cheaper than Apple's machines when you consider like for like.
The only reason, to me, that I remember Snow Leopard as being so good is because Leopard was a steaming pile of slow shit.
The degree of throttling that seems to be occurring does seem to be quite excessive. Excessive enough that I wonder whether they've had unexpected battery degradation in the field, or unexpected degradation of the power delivery circuit, or unexpectedly high load consumption or some kind of fault with the SoC.
Either that or they have just pushed the envelope a little too much knowing that their customers are likely to get fed up and buy new phones... hmmm...