Yeah, except for the facts that the leaky bolts that were the primary source of consternation last year (?) weren't part of the Chinese-built part of the bridge.
For someone who laments the failure of modern programmers to learn from the work of the past, the author seems to completely ignore the contributions of ML, ML-style type systems, and related languages to the profession of software engineering. Perhaps this explains the snide (and, frankly, uninformed) dismissal of Swift as a hype-ridden "subset of Lisp".
Aside from that, I agree with the author's points.
I think an interesting life is important. I also think, though, that many people lead far more interesting lives than they realize. Some people are better than others at noticing and extracting the interesting parts of what would otherwise be humdrum everyday tedium.
What a great summary of the utter baseness of this type of advertising: a stomach-turning body horror image I never wanted to see, some article calling strangers "morons" based on some stupid superficiality, and gossip about the private lives of strangers that is, quite frankly, none of my business.
That being said, if these companies vanished tomorrow it wouldn't be a complete positive either, since the fine sociopaths of the advertising industry would simply use the resultant vacuum to come up with something even more contemptible. Fuck that industry.
"Advanced manufacturing requires management and communication skills and the ability to operate complex information-based factories" is meaningless consultant jargon. It would have been better to explain exactly what about advanced manufacturing makes it so special that it requires 'management' and 'communication' skills that the managers and workers in non-advanced factories apparently lack. Meanwhile, "ability to operate complex information-based factories" is almost a tautology. Maybe talk about industrial IOT, or what specialized skills are necessary to efficiently operate a factory full of robots, or _something_?
I'm not particularly enthused with how the code was presented. Here's a marginally more readable version of the first large snippet that still doesn't exceed 77 (or 79) characters in width:
I've seen interest on the lists for modifying the model to allow a single failure type to be specified. I hope someone will write up a proposal once August rolls around and the lists are open again to new feature ideas.
Scala tries a lot harder than Swift to unify object-oriented and functional programming principles.
For example, in Scala operators are (IIRC) implemented as methods on objects, there's a 'Nothing' bottom type that is used for covariant generic parameterization, and ADTs are implemented using inheritance in the form of case classes.
Swift has no top-level object type or bottom type, and a lot of its more functional style features (ADTs in the form of 'enums', value types that enforce immutability) are completely divorced from the object-oriented part of the language.
One thing I've noticed is that performing the string scanning operation is relatively cheap. (If the splitAndTrim code is modified to not use Strings and to return a [String.UTF16View], the runtime is around 1.2 seconds.) It's the process of building Strings out of those UTF16 views that is destroying performance.
I still don't know why changing the way the input data are constructed would have that effect, except to guess that the underlying representation is different somehow. I'll file a ticket.
After a bit more investigation, I found that if you replace the following code:
result.append(begin == eos ? "" : String(cs[begin..<end.successor()]))
with this:
if begin == eos {
result.append("")
} else if let str = String(cs[begin..<end.successor()]) {
result.append(str)
}
runtime goes down from ~3 seconds to ~2.2 seconds.
This is due to a rather insidious API design decision:
init?(_ view: String.UTF16View)
constructs a string out of a UTF16 view, but it can fail. If used in a context where its type is inferred to be non-nullable, the following generic reflection-related init is used instead:
init<T>(_ instance: T)
I'm going to bring this up on the list and see if there are better ways of doing things.
As far as I can tell most of the rest of the time is spent in the Swift native Unicode --> UTF16 decoding machinery, and NSCharacterSet.
To be clear, that document contains brainstorming by some core Swift team developers. It's neither implemented in Swift nor officially accepted as a guideline for future development.
Long story short, it looks like the reflection machinery in the standard library is improperly being used to construct String instances. Doing so, while probably not sufficient to account for the entirety of the awful performance, is probably quite expensive. This looks like a bug and I'll try to dig deeper into it this week.
Swift also badly needs a native version of NSCharacterSet, even if only for programmer ergonomics.
The developer in charge of the standard library has mentioned that that team intends on redesigning the String API in the near future; this should provide an opportunity to reexamine the performance implications of the current implementations.