Apple is a year in with its voice to text system. I’ve been using it since release, but also continue to use Dragon for Mac which, while no longer supported, continues to work. This video demonstrates the differences and where Apple still has some catching up to do.
See also: Mac Dictation 101.
Previously:
Rasmus Lerdorf, in 1995 (via Reddit):
Announcing the Personal Home Page Tools (PHP Tools) version 1.0.
These tools are a set of small tight cgi binaries written in C. They perform a number of functions including:
- Logging accesses to your pages in your own private log files
- Real-time viewing of log information
- Providing a nice interface to this log information
- Displaying last access information right on your pages
[…]
The tools also allow you to implement a guestbook or any other form that needs to write information and display it to users later in about 2 minutes.
Like JavaScript, PHP has gotten a lot better over time, though it also retains many old flaws. The biggest surprise for me is that nothing else has come along that’s as easy to use and deploy. There are multiple templating systems for Python and Ruby, but none ever got integrated to the point where you could use it right out of the box.
The PHP system evolved into one that now drives nearly 80 per cent of websites using server-side programming, according to figures from w3techs.
[…]
The Danish-Canadian programmer’s original idea was that developers still wrote the bulk of their web application in C but “just use PHP as the templating language.” However nobody wanted to write C, said Lerdorf, and people “wanted to do everything in the stupid little templating language I had written, all their business logic.”
[…]
Obsolete versions of PHP are commonplace all over the internet on the basis that as long as it works, nobody touches it. It has become the language that everyone uses but nobody talks about.
See also: What’s new in PHP 8.0.
Previously:
Update (2020-06-11): See also: This timeline (via Colin Devroe).
One of the big questions on my mind is how well the fully declarative approach scales to complex apps. You can already build quite reasonable portal apps for your favorite web service with SwiftUI, which is 90% of the iOS app market, but I am much more interested in the other 10%. Can you build an advanced iOS app or serious macOS app with SwiftUI? Could you develop an app like Keynote or Xcode using SwiftUI?
[…]
This process is fast for a few standard views, but there are bigger challenges looming. For example, take a large array of values that you want to present in a
List. We encountered some serious performance issues when updating data in such aList, as SwiftUI would attempt to diff thousands ofViewnodes. You could restructure your UI in order to avoid such large lists, but that is a bit of a cop out, because the technologies SwiftUI is designed to supplant can handle such large lists.The problem is perhaps even more apparent in a text view. We briefly saw a
TextViewtype appear during the SwiftUI beta in 2019, but it didn’t make the final release.
There’s also no outline view or Mac-style table view.
Previously:
Update (2020-08-27): Sebastián Benítez:
I heard many other people are having problems with other advanced AppKit controls, such as NSTextView, NSTableView, NSOutlineView. Any non-trivial Mac application is bound to use one of these, so if you were to use them, you either wrap them in a representable + coordinator or go the traditional way and build with SwiftUI around it.
Despite all of this, I have no plans to abandon SwiftUI.
As much as I enjoy SwiftUI, it becomes quickly frustrating by its limitations and having to resort to UI/NSViewRepresentable for trivial things such as making a text field first responder.
SwiftUI is still a few years from being a real alternative to UIKit/AppKit.
SwiftUI List performance on AppKit is very bad. We did a version of our Timeline (the middle view) that used LazyVStack and it was fast. We need List for animations and other things, so hopefully the SwiftUI team gets things tuned on AppKit.
The part of the SwiftUI story I’m waiting for is how to build SwiftUI.
One of the problems of SwiftUI is you’re not building views. The View name is misleading. You’re building a description of something that somehow is turned into views. Completely out of your control.
So you’re completely limited to what the DSL allows you to express. Unlike AppKit/UIKit, you can’t actually BUILD something. You can only pick from a catalog the parts you want and assemble them according to the instructions.
This article explores how apps link differently against the runtime depending on the deployment target.
[…]
How can you link against the same dylib, which has a single install name, but any linked binaries record different dylib install names?
[…]
ld64sources are published by Apple, so we can see how the linker actually works. The code can be found in macho_dylib_file.cpp inside the methodFile<A>::addSymbol(). It defines the magic format as$ld$ <action> $ <condition> $ <symbol-name>.
The various
$ld$magic symbols are used heavily by Apple’s system frameworks to maintain backwards compatibility while moving symbols between frameworks. If you look at the various .tbd files in the Xcode SDKs you’ll see all sorts of shenanigans along these lines.
Example: class
NSObjectmoved from CoreFoundation to libobjc in macOS 10.8. libobjc has$ld$hidesymbols for old OS versions (“NSObjectis here, but it used to be somewhere else”). CF has$ld$addsymbols for old OS versions (“NSObjectis elsewhere, but it used to be here”).
