On: 25 Years of PHP

[cutler]

I tried to like Swift but with Perl as my first language Swift's regex implementation made me want to throw up. That and having to escape opening brackets and double parameter definitions. I just don't get the love for Swift other than it being an improvement over Objective C.

[ChrisMarshallNY → cutler]

I consider Perl to be a “write-only” language. Damn good text processor, though. I wrote an entire CMS in Perl, back in the late 90s.

I still wake up, screaming...

Swift isn’t any worse than most modern languages, when it comes to text processing, but that’s not what I use it for.

In fact, it has some very powerful string handling, built-in, but it’s kind of weird, if you are used to more traditional languages.

[cutler → ChrisMarshallNY]

I never got the "write-only" criticism. If you understand a language thoroughly code is always readable. What's with the insane double param naming? And why do I have to escape and opening paren? No other language requires this.

[ChrisMarshallNY → cutler]

It’s designed to allow functions to have “two faces.” One face is the one presented to the caller, and the other to the function, itself.

The idea is to maximize grokability. The function’s purpose and argument list is clear to the caller.

It’s an attempt at that old “philosophers’ stone” of “self-documentation.”

Almost all the code I encounter has little to no method interface documentation. This is supposed to address that.

My experience is that many people circumvent it by using the “wildcard” (_).

I use it to add “in” prefixes to my parameters, like so:

func churn(butter inButter: String) {...}

The “in” prefix means nothing, outside the function context, but is an indicator that it is a function parameter, inside the function.

However, outside the function, the parameter name makes it clear that what is to be churned, is butter, as this is the published signature:

func churn(butter: String)

It also allows us to use parameters that are published with the names of class properties, without name collisions.

For example:

init(butter inButter: String) { butter = inButter }

Where using just “butter” would mean we need to do this:

init(butter: String) { self.butter = butter }

Small stuff, but Swift has a lot of these types of considerations.

But what is really cool about function parameters, is that we can “skip” optional parameters, like so:

func add(numberOne inFirst: Int = 0, numberTwo inSecond: Int = 0, numberThree inThird: Int = 0, to inTarget: Int) { return inFirst + inSecond + inThird + inTarget }

We can call it like so:

let result = add(numberThree: 4, to: 5)

I write about that sort of thing, here: https://littlegreenviper.com/miscellany/swiftwater/swift_fun...

It’s an enormously flexible language, and can be used to write almost inscrutable code, if we choose.

However, it can also be used to write extremely readable code.

I think it’s a sisyphean exercise, trying to get programmers to write readable code, but we keep trying.

Like I said, Swift is a bit like C, where it can be used to write obfuscated junk, if the programmers want.

My experience is that “idiomatic Swift,” as prescribed by many authorities, is starting to look like that.

I’m not exactly sure what you mean by “escape an opening paren.”

Do you mean inside of strings? That’s a direct inline shorthand that is similar to `...` in other languages. Totally optional.

For example: print(“There are \(numberOfSheep) sheep.”) is direct, as opposed to print(“There are “ + numberOfSheep + “ sheep.”), or print(“There are “, numberOfSheep, “ sheep”).

[cutler → ChrisMarshallNY]

The fact that most devs use _ to work around it surely suggests that it was a pointless idea in the first place. Of all the barmy ideas to make a programming language unique this surely tops the list. As for escaped opening brackets you have to ask why no other language found this necessary. Is the Swift parser really so dumb? These 2 language features prove that however clever a language creator may be he/she can end-up producing features which are frankly absurd.

[ChrisMarshallNY → cutler]

Not “most.” Just “many.” I do feel that "most" Swift programmers try to stay within the philosophy; even if only by rote.

I tend to eschew argument labels for the first argument; relying on the function name to provide context. That's a pattern that Apple also uses, and comes from ObjC, which came from Smalltalk, so Swift is actually informed by Smalltalk; a venerable OO language.

I’m sure that you can do amazing stuff in Perl, and I apologize for my "write-only" crack. It was not conducive to the conversation (which was about PHP). One of the reasons that I don’t use it, is that I guess I never got good enough with it to really sing.

The best tools can be misused.

Ever see a great musician play a beat-up old Univox, and sound like a chorus of angels, then someone buys a PRS, and sounds like a cat being tortured?

We can get hung up on the tools, and forget that the tool is secondary to skill and experience.

Well, toe-MAY-toe/toe-MAH-toe. No matter. I’ll keep programming in Swift, and limp along.