Readable code, taken too far (too Swift)?
-
I did kinda like that when I first learned it but then... I think I'm too steeped in keeping code compact. Not Ruby-esque compact, but the need to explicitly name every input variable started grating. I do prefer the C# way where naming input parameters is opt-in instead of opt-out.
cheers Chris Maunder
-
I'm learning Swift. It's an interesting new(er) language that has some interesting new features. Functions Have External Param Names One of those features is the naming of external function params. Background Most of us are accustomed to named (internal) params. This is analogous to what we have in C# like the following:
int Add(int addend1, int addend2){
return addend1 + addend2;
}Of course we call it like:
Add(2,3);
Those internal params are the names we use inside the function body. That all makes sense. What About Swift? But in Swift you can also name the external params. Actually, you have to name them in your function definition unless you use an underscore to tell the compiler you're not using an external name. Here's the same function defined in Swift:
func Add(_ addend1: Int, _ addend2: Int) -> Int{
return addend1 + addend2;
}You can call that method like :
Add(2,3)
Magical Underscore However, if we do not supply the underscore, then we have to give the external param a name too, like the following:
func Add(a1 addend1: Int, a2 addend2: Int) -> Int{
return addend1 + addend2;
}So now you have to call the Add function like the following (or it will fail to compile):
Add(a1:2, a2:3)
All That Culminates In This The very good book I'm reading to learn Swift[^] has an example like the following:
func changeName(of d:Dog, to newName:String) {
d.name = newName
}What changeName Does The changeName function takes a
Dogclass and changes it's name property to the value that is sent in the 2nd param (String). The external variable for the first param (of typeDog) isofand the internal name of that same param isd. The external name of the 2nd param (Well I think we know where Osmo ended up. X| X| X| X| X| X| X| X| X| X| X| X| X| X| X| X| X| X| X| X| X| X| X| X| X| X| X| X| X| X| X| X| X| X| X| X| X| X| X| X| X| X| X| X| X| X| X| X| X| X| X| X| X| X| X| X| X| X| X| X| X| X| X| X| X| X| X| X| X| X| X| X| X| X| X| X| X| X| X|
-
I'm learning Swift. It's an interesting new(er) language that has some interesting new features. Functions Have External Param Names One of those features is the naming of external function params. Background Most of us are accustomed to named (internal) params. This is analogous to what we have in C# like the following:
int Add(int addend1, int addend2){
return addend1 + addend2;
}Of course we call it like:
Add(2,3);
Those internal params are the names we use inside the function body. That all makes sense. What About Swift? But in Swift you can also name the external params. Actually, you have to name them in your function definition unless you use an underscore to tell the compiler you're not using an external name. Here's the same function defined in Swift:
func Add(_ addend1: Int, _ addend2: Int) -> Int{
return addend1 + addend2;
}You can call that method like :
Add(2,3)
Magical Underscore However, if we do not supply the underscore, then we have to give the external param a name too, like the following:
func Add(a1 addend1: Int, a2 addend2: Int) -> Int{
return addend1 + addend2;
}So now you have to call the Add function like the following (or it will fail to compile):
Add(a1:2, a2:3)
All That Culminates In This The very good book I'm reading to learn Swift[^] has an example like the following:
func changeName(of d:Dog, to newName:String) {
d.name = newName
}What changeName Does The changeName function takes a
Dogclass and changes it's name property to the value that is sent in the 2nd param (String). The external variable for the first param (of typeDog) isofand the internal name of that same param isd. The external name of the 2nd param (I think partly this is a holdover from Objective-C. For example, this Cocoa method call:
UIAlertView* alert = [[UIAlertView alloc] initWithTitle:@"Hello!"
message:@"Hello, world!"
delegate:nil
cancelButtonTitle:@"Close"
otherButtonTitles:nil];which calls initWithTitle to create a new pop-up with a message for the user. It uses the external notation and if I remember correctly (always problematic) the notation was required on all but the first argument, where it was optional. This used to be more important when mixing Swift with Objective-C, but now most (if not all) of the various OS APIs are implemented in Swift, so it's less relevant. The exception is if you're using your own Objective-C code with Swift, or slowly converting a project over from one to the other.
-
I'm learning Swift. It's an interesting new(er) language that has some interesting new features. Functions Have External Param Names One of those features is the naming of external function params. Background Most of us are accustomed to named (internal) params. This is analogous to what we have in C# like the following:
int Add(int addend1, int addend2){
return addend1 + addend2;
}Of course we call it like:
Add(2,3);
Those internal params are the names we use inside the function body. That all makes sense. What About Swift? But in Swift you can also name the external params. Actually, you have to name them in your function definition unless you use an underscore to tell the compiler you're not using an external name. Here's the same function defined in Swift:
func Add(_ addend1: Int, _ addend2: Int) -> Int{
return addend1 + addend2;
}You can call that method like :
Add(2,3)
Magical Underscore However, if we do not supply the underscore, then we have to give the external param a name too, like the following:
func Add(a1 addend1: Int, a2 addend2: Int) -> Int{
return addend1 + addend2;
}So now you have to call the Add function like the following (or it will fail to compile):
Add(a1:2, a2:3)
All That Culminates In This The very good book I'm reading to learn Swift[^] has an example like the following:
func changeName(of d:Dog, to newName:String) {
d.name = newName
}What changeName Does The changeName function takes a
Dogclass and changes it's name property to the value that is sent in the 2nd param (String). The external variable for the first param (of typeDog) isofand the internal name of that same param isd. The external name of the 2nd param (What if it's a cat? (Using C#, interfaces and "named parms")
Cat cat = new Cat(){ Name = "Whiskers" };
ChangeName( of: cat, to: "Fluffy" );
// OR
ChangeName( to: "Fluffy", of: cat );
public STATIC void ChangeName(IRenameable of, string to) {
of.Name = to;
}public interface IRenameable {
string Name {get;set;}
}public class Cat: IRenameable {
public string Name {get;set;}
}"(I) am amazed to see myself here rather than there ... now rather than then". ― Blaise Pascal
-
What if it's a cat? (Using C#, interfaces and "named parms")
Cat cat = new Cat(){ Name = "Whiskers" };
ChangeName( of: cat, to: "Fluffy" );
// OR
ChangeName( to: "Fluffy", of: cat );
public STATIC void ChangeName(IRenameable of, string to) {
of.Name = to;
}public interface IRenameable {
string Name {get;set;}
}public class Cat: IRenameable {
public string Name {get;set;}
}"(I) am amazed to see myself here rather than there ... now rather than then". ― Blaise Pascal
-
I think partly this is a holdover from Objective-C. For example, this Cocoa method call:
UIAlertView* alert = [[UIAlertView alloc] initWithTitle:@"Hello!"
message:@"Hello, world!"
delegate:nil
cancelButtonTitle:@"Close"
otherButtonTitles:nil];which calls initWithTitle to create a new pop-up with a message for the user. It uses the external notation and if I remember correctly (always problematic) the notation was required on all but the first argument, where it was optional. This used to be more important when mixing Swift with Objective-C, but now most (if not all) of the various OS APIs are implemented in Swift, so it's less relevant. The exception is if you're using your own Objective-C code with Swift, or slowly converting a project over from one to the other.
-
I'm learning Swift. It's an interesting new(er) language that has some interesting new features. Functions Have External Param Names One of those features is the naming of external function params. Background Most of us are accustomed to named (internal) params. This is analogous to what we have in C# like the following:
int Add(int addend1, int addend2){
return addend1 + addend2;
}Of course we call it like:
Add(2,3);
Those internal params are the names we use inside the function body. That all makes sense. What About Swift? But in Swift you can also name the external params. Actually, you have to name them in your function definition unless you use an underscore to tell the compiler you're not using an external name. Here's the same function defined in Swift:
func Add(_ addend1: Int, _ addend2: Int) -> Int{
return addend1 + addend2;
}You can call that method like :
Add(2,3)
Magical Underscore However, if we do not supply the underscore, then we have to give the external param a name too, like the following:
func Add(a1 addend1: Int, a2 addend2: Int) -> Int{
return addend1 + addend2;
}So now you have to call the Add function like the following (or it will fail to compile):
Add(a1:2, a2:3)
All That Culminates In This The very good book I'm reading to learn Swift[^] has an example like the following:
func changeName(of d:Dog, to newName:String) {
d.name = newName
}What changeName Does The changeName function takes a
Dogclass and changes it's name property to the value that is sent in the 2nd param (String). The external variable for the first param (of typeDog) isofand the internal name of that same param isd. The external name of the 2nd param (Wow. I've recently learned Prolog (though I still have a much greater fondness for TLA+[^]) so I appreciate the _ "forget-about-it" convention but wow, requiring named parameters in absence of "anonymous" ones? FeelsBadMan :suss: Just use F#, C#, or others depending on your needs. Apple doesn't do anything well including their phone which is based mostly on advertising.
-
Wow. I've recently learned Prolog (though I still have a much greater fondness for TLA+[^]) so I appreciate the _ "forget-about-it" convention but wow, requiring named parameters in absence of "anonymous" ones? FeelsBadMan :suss: Just use F#, C#, or others depending on your needs. Apple doesn't do anything well including their phone which is based mostly on advertising.
-
I'm learning Swift. It's an interesting new(er) language that has some interesting new features. Functions Have External Param Names One of those features is the naming of external function params. Background Most of us are accustomed to named (internal) params. This is analogous to what we have in C# like the following:
int Add(int addend1, int addend2){
return addend1 + addend2;
}Of course we call it like:
Add(2,3);
Those internal params are the names we use inside the function body. That all makes sense. What About Swift? But in Swift you can also name the external params. Actually, you have to name them in your function definition unless you use an underscore to tell the compiler you're not using an external name. Here's the same function defined in Swift:
func Add(_ addend1: Int, _ addend2: Int) -> Int{
return addend1 + addend2;
}You can call that method like :
Add(2,3)
Magical Underscore However, if we do not supply the underscore, then we have to give the external param a name too, like the following:
func Add(a1 addend1: Int, a2 addend2: Int) -> Int{
return addend1 + addend2;
}So now you have to call the Add function like the following (or it will fail to compile):
Add(a1:2, a2:3)
All That Culminates In This The very good book I'm reading to learn Swift[^] has an example like the following:
func changeName(of d:Dog, to newName:String) {
d.name = newName
}What changeName Does The changeName function takes a
Dogclass and changes it's name property to the value that is sent in the 2nd param (String). The external variable for the first param (of typeDog) isofand the internal name of that same param isd. The external name of the 2nd param ( -
IMHO it's requiring coders do what's basically IDE's job. See the "Parameter name hints" in this Idea manpage: View code reference info - Help | IntelliJ IDEA[^]
Quote:
IMHO it's requiring coders do what's basically IDE's job.
Ding ding, we have a winner. Did not expect this from Apple.
-
Quote:
IMHO it's requiring coders do what's basically IDE's job.
Ding ding, we have a winner. Did not expect this from Apple.
-
The topic is on Swift language, not a particular IDE. And for the record, programmers at Apple are old-school idiots who think syntactic sparseness is compatible with security code worked by other 5000 people.
-
I'm learning Swift. It's an interesting new(er) language that has some interesting new features. Functions Have External Param Names One of those features is the naming of external function params. Background Most of us are accustomed to named (internal) params. This is analogous to what we have in C# like the following:
int Add(int addend1, int addend2){
return addend1 + addend2;
}Of course we call it like:
Add(2,3);
Those internal params are the names we use inside the function body. That all makes sense. What About Swift? But in Swift you can also name the external params. Actually, you have to name them in your function definition unless you use an underscore to tell the compiler you're not using an external name. Here's the same function defined in Swift:
func Add(_ addend1: Int, _ addend2: Int) -> Int{
return addend1 + addend2;
}You can call that method like :
Add(2,3)
Magical Underscore However, if we do not supply the underscore, then we have to give the external param a name too, like the following:
func Add(a1 addend1: Int, a2 addend2: Int) -> Int{
return addend1 + addend2;
}So now you have to call the Add function like the following (or it will fail to compile):
Add(a1:2, a2:3)
All That Culminates In This The very good book I'm reading to learn Swift[^] has an example like the following:
func changeName(of d:Dog, to newName:String) {
d.name = newName
}What changeName Does The changeName function takes a
Dogclass and changes it's name property to the value that is sent in the 2nd param (String). The external variable for the first param (of typeDog) isofand the internal name of that same param isd. The external name of the 2nd param (Smalltalk had similar readability, achieved differently. In this case, an object
kennelmay define a methodchangeNameOf:To:would be invoked as follows:kennel changeNameOf: d To: 'Fido'.
"If you don't fail at least 90 percent of the time, you're not aiming high enough." Alan Kay.
-
Smalltalk had similar readability, achieved differently. In this case, an object
kennelmay define a methodchangeNameOf:To:would be invoked as follows:kennel changeNameOf: d To: 'Fido'.
"If you don't fail at least 90 percent of the time, you're not aiming high enough." Alan Kay.
-
The topic is on Swift language, not a particular IDE. And for the record, programmers at Apple are old-school idiots who think syntactic sparseness is compatible with security code worked by other 5000 people.
My point was that language designers spent time to add a future which enforces some stupid rule on developers, instead spending that time implementing an IDE plugin which does the job (likely faster and better than developers anyway). Because everybody uses IDE nowadays, right? Uhm... wait. And for the recored, no-single-liners and no-assigment-in-comparison policies suddenly started to make sense... idiots.
-
I'm learning Swift. It's an interesting new(er) language that has some interesting new features. Functions Have External Param Names One of those features is the naming of external function params. Background Most of us are accustomed to named (internal) params. This is analogous to what we have in C# like the following:
int Add(int addend1, int addend2){
return addend1 + addend2;
}Of course we call it like:
Add(2,3);
Those internal params are the names we use inside the function body. That all makes sense. What About Swift? But in Swift you can also name the external params. Actually, you have to name them in your function definition unless you use an underscore to tell the compiler you're not using an external name. Here's the same function defined in Swift:
func Add(_ addend1: Int, _ addend2: Int) -> Int{
return addend1 + addend2;
}You can call that method like :
Add(2,3)
Magical Underscore However, if we do not supply the underscore, then we have to give the external param a name too, like the following:
func Add(a1 addend1: Int, a2 addend2: Int) -> Int{
return addend1 + addend2;
}So now you have to call the Add function like the following (or it will fail to compile):
Add(a1:2, a2:3)
All That Culminates In This The very good book I'm reading to learn Swift[^] has an example like the following:
func changeName(of d:Dog, to newName:String) {
d.name = newName
}What changeName Does The changeName function takes a
Dogclass and changes it's name property to the value that is sent in the 2nd param (String). The external variable for the first param (of typeDog) isofand the internal name of that same param isd. The external name of the 2nd param ( -
I'll have to learn and use Swift. This year ... :~
Press F1 for help or google it. Greetings from Germany
Good luck. I started writing some of it up here at CP : iOS 12 Programming Fundamentals With Swift: Intro & Chpt1[^] I find that learning Xcode (IDE) is a barrier too. I'm definitely accustomed to VStudio and Android Studio. The odd way that you add code when a button is clicked (see article) just doesn't feel natural to me.
-
Good luck. I started writing some of it up here at CP : iOS 12 Programming Fundamentals With Swift: Intro & Chpt1[^] I find that learning Xcode (IDE) is a barrier too. I'm definitely accustomed to VStudio and Android Studio. The odd way that you add code when a button is clicked (see article) just doesn't feel natural to me.
-
Rob Grainger wrote:
Smalltalk had similar readability, achieved differently
Interesting. So what you're saying is that Swift is trying to copy syntax that is used by a 46 year old language. :laugh: Just kidding.
I suppose it helps Swift code read more like Objective-C code. That's important in this context, because Objective-C basically grafted Smalltalk's object system onto C. And so ObjC's object syntax ended up being very Smalltalk-like. I really enjoyed it in Smalltalk. I felt that it made for very readable, understandable code. It didn't work as well and ObjC because there was a huge clash between the C syntax and the Smalltalk syntax. At first, I disliked this syntax in Swift. But in the end, I decided it was just one of those things that I disliked because it was different than what I was used to. After a while, I didn't mind it so much. I find it a lot uglier in Swift than in Smalltalk, however, since in Smalltalk you don't use brackets when sending a message to an object. The Smalltalk debugging environment is also way more fun. Test driven development is fun in Smalltalk, because if you write a test that calls a method that doesn't exist yet, it's no problem. The Smalltalk debugger will yell at you, pause execution, and then give you an opportunity to implement the method before resuming execution. Like many things in life, though, it's definitely a matter of taste and opinion. Some people will never like this aspect of Swift, and I think it's completely fine for them to feel that way. :)
-
I suppose it helps Swift code read more like Objective-C code. That's important in this context, because Objective-C basically grafted Smalltalk's object system onto C. And so ObjC's object syntax ended up being very Smalltalk-like. I really enjoyed it in Smalltalk. I felt that it made for very readable, understandable code. It didn't work as well and ObjC because there was a huge clash between the C syntax and the Smalltalk syntax. At first, I disliked this syntax in Swift. But in the end, I decided it was just one of those things that I disliked because it was different than what I was used to. After a while, I didn't mind it so much. I find it a lot uglier in Swift than in Smalltalk, however, since in Smalltalk you don't use brackets when sending a message to an object. The Smalltalk debugging environment is also way more fun. Test driven development is fun in Smalltalk, because if you write a test that calls a method that doesn't exist yet, it's no problem. The Smalltalk debugger will yell at you, pause execution, and then give you an opportunity to implement the method before resuming execution. Like many things in life, though, it's definitely a matter of taste and opinion. Some people will never like this aspect of Swift, and I think it's completely fine for them to feel that way. :)
That's a nice summary of what Swift is trying to do and I wouldn't have known any of that about it coming from smalltalk etc. I do like readable code, but I find this type of syntax almost gets in the way since things get named very oddly just to make them begin to make natural language sentences. I like things like a player object that has a bool property of hasSpecialAbility so I can do things like:
if (payer.hasSpecialAbility){
// do stuff
}Maybe the Swift stuff will grow on me as I use it more. Only time will tell. Thanks for the great discussion.:thumbsup: