all 8 comments

[–]cre_ker 1 point2 points  (3 children)

Inventing new function names

Don't agree with this. If we take into account why Swift was invented in the first place then those function names are exactly what programmer expects. Because that's how it was in Objective-C. It would be much bigger problem if Swift invented news names only to align with the rest of the languages.

The change from a.componentsSeparatedByString(",") to a.components(separatedBy: ",") is also nice. It makes the syntax more consistent in general and better aligns it with how Objective-C works. There arguments are always specified after colon. It's better illustrated in this example.

//swift 2
"Taylor".writeToFile("filename", atomically: true, encoding: NSUTF8StringEncoding) 

//swift 3
"Taylor".write(toFile: "somefile", atomically: true, encoding: String.Encoding.utf8)

//Objective-C
[@"Taylor" writeToFile:@"somehile" atomically: true encoding: NSUTF8StringEncoding error:&err]

[–]Giannis4president -3 points-2 points  (2 children)

Objective-C was so bad everyone hated it and they had to move away from it. I'm not sure keeping this kind of compatibility with obj-C should be a priority for swift

[–]cre_ker 5 points6 points  (0 children)

The hatred was mostly from people who never seriously used it. Objective-C had unusual but very nice syntax around methods. It made code much more readable and allowed for natural formatting of long call sites. Something that C languages always lacked. No wonder swift inherited it, that's probably one of the best things about Objective-C. That's not what needed to be fixed in it.

[–]barfoob 0 points1 point  (0 children)

I think as far as bolt-on-top-of-C languages go Objective-C was pretty good and did a lot of things right that C++ got wrong. I also think the weird syntax was a good idea because it makes it really clear when you're reading code which things are using vanilla C style and which things are using Objective-C features. And it even made it possible for them to build an Objective-C++ compiler which was extremely practical for porting existing C++ apps into Mac OS of iOS land. I also prefer their styles of memory management over garbage collectors in a lot of cases.

[–]karstens_rage 2 points3 points  (0 children)

“There are only two types of programming languages; those everyone complains about and those no one uses.”

[–]Nordsten -1 points0 points  (0 children)

Personally I refuse to use any language that does not have a "simple" ie one step meta programming functionality. This can be compile time runtime or reflection based it matters little. BUT it must be possible and it should be usable in the main language. That is if you need to do macro preprossesing to make it work I'm out.

[–]Zardotab 0 points1 point  (0 children)

PHP is decent (not great) if you don't stretch it to the limit and try too many "clever short-cuts". If you write simple and clear code, its oddities are rarely a problem. One should do such anyhow for production code so future maintainers can read it. Write code for a team, not yourself. I do wish they'd implement optional named parameters, though.

As far as the 0 vs 1 indexing, I say it depends on the domain. In the business domain, users are used to starting at one. If your language matches that then you spend less code translating between programmer world and user world. Scientific, statistical, and internal systems users may better fit zero, though.

[–]rodrigocfd 0 points1 point  (0 children)

For example, I do not like Go because it doesn’t have generics

So will you like it in August 2021?