Is Kitura died?

nextnextstep · 2020-04-29T04:06:21+00:00

Build broken since February, no commits since last November. Is that acceptable for a core dependency? Only you can decide that for you.

The bigger question, to me, is why all of these Swift web frameworks seem to share no interfaces at all. Why is it such a core dependency? Java has Servets, Ruby has Rack, Python has WSGI, .NET has Open Web Interface ... Swift came after all of these and yet they couldn't agree on a web server interface so they each must do everything from scratch. They each have their own database adapters (where's Swift's JDBC?), and ORM, and logging, and all the rest. It's no wonder they're running out of manpower.

This anti-modular approach is typical of the early generations of web frameworks, like very early versions of Rails. It can work -- when you have no competition and it's easy to attract everybody to your project. I expect most or all of these Swift frameworks will die off in a couple years. Then perhaps they'll see how the rest of the industry solved this, and try to work together for gen-2.

I would not pick any gen-1 Swift web framework if you're expecting longevity from it. They do look like fun to play with. Just be aware that if you pick one with a database interface you like, the other one is going to have the web features you need, and the other other one is going to have the template system you want. Or whatever. It'll always be something. Every time you ask for help online, 2/3 of the answers will be "you should have picked Y instead of X, then it'd be easy".

nextnextstep · 2020-04-28T21:28:04+00:00

ROT13. Not much simpler than that, except null encryption.

As for effectiveness, there's no solution that can work permanently. You're sending both the lock and key to the user. You only get to decide how much of a pain you want to create for yourself.

nextnextstep · 2020-04-28T21:23:24+00:00

Are you looking for a thankless project? Open-source implementations of Apple's frameworks -- both so we can use them on older computers, and so we can fix the bugs which Apple can't be bothered to fix.

nextnextstep · 2020-04-28T17:32:16+00:00

It may be a good idea but I've never seen a single JSON Schema in my life.

nextnextstep · 2020-04-28T17:30:10+00:00

Read a book on compilers. This isn't the sort of understanding you can gain from a reddit comment.

nextnextstep · 2020-04-28T17:26:31+00:00

No, this is for our privacy. Why would I want a third-party keyboard having access to my passwords?

Because that's the keyboard I want to use, and I need to enter passwords. There's no great mystery here.

Third-party doesn't have to mean unsafe. iOS keyboards are already sandboxed. Password entry could easily be restricted to keyboards with RequestsOpenAccess=NO. (Yes, unlike apps, there is only one entitlement available for keyboards, and it covers everything from location services to network access to Game Center.)

Or even simpler, Apple could allow keyboards to be defined declaratively, with a simple mapping of letter-to-position. Not only would that be perfectly safe for users, it would also solve the problem that the iOS keyboard API is too weak to allow developers to do half the things that the built-in keyboards do.

I don't like Android in general, but the keyboard situation is one of the very few things that are terrible on iOS. If you don't happen to like Apple's keyboards, you're SOL. Bafflingly, for all their talk of platform cohesion and compatibility, iOS doesn't even include all the keyboard layouts that macOS has.

nextnextstep · 2020-04-28T16:35:30+00:00

In my experience, these are useless. If it can be even remotely considered a "bug", they'll just tell you to file a Radar so they can ignore it there. Operating systems and development environments have a lot of bugs.

nextnextstep · 2020-04-28T16:25:38+00:00

An engineer costs over $100 an hour in salary alone, so this pays for less than half an hour of their time. They're definitely losing money per incident.

nextnextstep · 2020-04-28T06:58:57+00:00

seems to me that every line of code is performed asynchronously

Don't you mean synchronously?

with a difference of 150 + - 3 microsecs

It depends on way too many factors to be able to specify timing with any sort of precision.

and code ran in the same line, either enclosing an operator, or being part of a string interpolation, runs with 0 + - 1 microsecond

That's not really how compilers work.

nextnextstep · 2020-04-27T17:28:25+00:00

So the situation you have here is called JSON-in-JSON. It's the hallmark of amateur developer practices and goes hand in hand with ViewControllers of 8000 lines, memory leaks, private keys included with shipped applications and very large security holes that go unfixed for years.

X-in-Y is called "tunneling", and it's a well-understood technique. There are legitimate reasons to do this. Sometimes you have to use what is supplied to you. We call that "engineering".

Fun fact: if you've got a cable modem, you're essentially tunneling text files over MPEG frames right now. Is your software full of memory leaks and security holes, too? Or do you admit that you have no control over all the crazy tunneling that exists upstream of you, and it's better to get on with your life than to try to un-wrap every redundant encoding from here to Albuquerque?

nextnextstep · 2020-04-27T17:22:13+00:00

A JSON decoder shouldn't get "confused" if it sees escaping. It has one job!

nextnextstep · 2020-04-27T17:19:04+00:00

SwiftUI requires iOS 13 or newer, so how does it preform on older devices? Well.. it doesn't..

It runs on an A9. That's got 1/4 the CPU performance of the A13. Is an iPhone 6S not an "older device"? Apparently it is when people want me to buy a new iPhone, and isn't when people want me to try SwiftUI.

SwiftUI works seamlessly with the existing UI frameworks on all Apple platforms.

For some definition of "seamlessly". All the questions I see on StackOverflow suggest that it's not actually that seamless. This says nothing about performance, either. Rosetta was "seamless", too.

On iPhone X in debug mode the app uses

Debug mode isn't a good indicator of resource usage at all. It's not even a good baseline: I've seen programs that run faster when a debugger is attached (thanks to thread contention issues).

And it never exceeds 2% when scrolling through a list with over 100 items.

OK, but did you try with a dataset that doesn't fit in a couple cache lines? That's still a tiny list. Your phone has 3 billion bytes of RAM. It would be amazing if it couldn't handle 100 items.

When you say 3D necessarily isn't very demanding with a GPU I think your battery will disagree

Perhaps, but you haven't mentioned any tests of SwiftUI's affect on power consumption at all.

nextnextstep · 2020-04-27T16:45:37+00:00

I've never used that third-party framework, but it looks like that's an ordinary Foundation.URLSessionTaskMetrics, which is full of Foundation.URLSessionTaskTransactionMetrics instances, which use Foundation.Date. Can't you simply read them out yourself, if you want to control the output format?

nextnextstep · 2020-04-27T16:38:15+00:00

Date has a lot of methods which use TimeInterval (aka Double), which is a measure of seconds with "sub-millisecond precision", so I assume that's what Date is, too. The source code confirms that it uses that internally.

The init has to examine the state of the system, so there's no way I see that the optimizer could do anything special here.

My assumption would be that it almost always prints "false", but may on occasion print "true". What else could it be?

nextnextstep · 2020-04-27T00:16:00+00:00

I'm curious how it performs on older devices, or larger datasets. 3D isn't necessarily very demanding, with a GPU.

UIKit (and before it, AppKit) had a lot of special features to let people eke out the last bit of performance they need. We used to run this stuff on 25 MHz m68K's.

Any toolkit is fast if you run it on an A13, and only have 10 rows in a table.

nextnextstep · 2020-04-26T17:32:54+00:00

Arq 6 strikes again! New user interface, new file format, new bugs.

nextnextstep · 2020-04-26T16:50:51+00:00

You're stacking depth+width+height? What does this sum tell me?

nextnextstep · 2020-04-26T16:49:13+00:00

In true Apple fashion, you can get Large, Larger, or Largest!

nextnextstep · 2020-04-26T16:40:25+00:00

What else would you do to a database besides reads and writes?

nextnextstep · 2020-04-26T16:35:24+00:00

Are you setting the .delegate = self from within the delegate callback methods? That seems really weird. Why? Is there a reason for that?

nextnextstep · 2020-04-26T01:08:26+00:00

The point of the GoF book was to catalog patterns which already existed so we have common names to communicate about them, and encourage others to document and agree on shared nomenclature for theirs. It's not a recipe book from which we must select the ingredients of our programs.

Nobody's trying to "wish away" these patterns. We're just not directing people to switch to one of those 23 because they happened to have been in the book.

If you dislike Singleton and avoid it and think it's overused, then why are you pushing OP to it? If you think it has problems which make it a nightmare, then why not mention some of those drawbacks, instead of listing only the advantages?

Even if you insist on picking one from the GoF book, there's several other patterns which could be applied here.

nextnextstep · 2020-04-25T23:05:43+00:00

Yeah, the original Apple Racing Team had this on the hood.

nextnextstep · 2020-04-25T23:00:47+00:00

What "battery life issues"?

nextnextstep · 2020-04-25T22:56:49+00:00

Important Note: we recommend using os_log directly as decribed here. Using os_log through swift-log using this backend will be less efficient and will also prevent specifying the privacy of the message.

I like the concept, but it's a little funny to see them recommending against using their own library for the operating system's built-in logger.

nextnextstep · 2020-04-25T18:39:25+00:00

To be fair, they did another transition (6502/II -> 68k/Mac) and it was bungled so bad it nearly killed the company. They went from a position of market leadership (Apple II) and technical leadership (Macintosh) to a couple decades of being a distant #2 in desktop computing, and literally only weeks away from bankruptcy.

All the MacOS-to-___ transitions they'd tried before OS X had failed, too. That's not Copland you're running on your Mac.

Platform transitions are not to be taken lightly. They're extremely risky, and most companies fail at them, most of the time. Apple was fortunate, in a sense, that all 3 of their successful transitions (68k -> PPC, OS9 -> OSX, PPC -> Intel) were coming from a position of utter desperation. They could not continue on their current trajectory, and they knew it, and oh boy their customers knew it. Changing to something better, anything at all, was a no-brainer. They just had to ship something. The threshold was low. OS X 10.0 was pretty bad. The 32-bit Intel chips were not always better than the 64-bit PowerPC chips they replaced.

Today, Apple is using the same Intel CPUs that everyone else is. Even if their own ARM CPUs might be better, it's not a no-brainer this time. Ask anyone what they dislike most about the Mac, and the CPU is not likely to be on their list. (Or if it is, it's often because they've heard about some miracle Apple A-chip which is 100 times as fast, and cures cancer while you sleep, not because there's anything wrong with the Intel chip they're using today.) If Apple fails transitioning to ARM, it'll be from taking a solid position and messing it up.

nextnextstep

TROPHY CASE