|
This is very impressive. Congratulations on having your work featured on pretty much the biggest stage possible.
|
#
¿
Jun 2, 2014 21:22
|
|
|
|
| # ¿ May 3, 2024 07:04 |
|
|
quote:Methods on classes have one important difference from functions. Parameter names in functions are used only within the function, but parameters names in methods are also used when you call the method (except for the first parameter). By default, a method has the same name for its parameters when you call it and within the method itself. I'm curious about this distinction. Why not let function calls also include parameter names?
|
|
#
¿
Jun 3, 2014 08:00
|
|
|
I've now converted a couple of tiny classes to Swift for fun. It's certainly much cleaner looking than the code it replaced. I think the language's true potential won't be clear until the Cocoa APIs start to be rewritten with Swift in mind. It looks like a modern, friendly language until you try to do something that would be simple in a scripting language like capture substrings using regular expression matches. Then you're neck deep in objective C APIs, creating NSRegularExpression objects with bitmask options and pointer based error handling to do something that is baked into strings in a scripting language.
|
|
#
¿
Jun 4, 2014 20:39
|
|
|
I am absolutely amazed at Swift's progress as I read the new iBook and this thread. Really makes me want to make an iOS app in my spare time just to learn the intricacies. One general question: Do any of us think (or maybe know) if Swift is ever going to bake Regular Expression literals into the main library? I know the current solution is to use NSRegularExpression or rangeOfString, but boy does that feel janky and archaic compared to other languages. I may be an edge case, but 90% of the stuff I work on involves using regular expressions to deal with user text and convert it into something else.
|
|
#
¿
Jun 20, 2015 18:36
|
|
|
fleshweasel posted:/big list of things unpleasant about using Regular Expressions in Cocoa/g Yes! Exactly. Thanks for writing that out. I can see why it might be a weird fit for the Cocoa libraries for Swift to have its own special regular expression functionality that operates differently from NSRegularExpression, but the current system feels like a ton of boilerplate weirdness just to accomplish simple tasks. Even having to write out regular expressions with double slashes (e.g. writing \d as \\d so NSString doesn't freak out) stands my hair on end. RegExes are ugly enough without extra slashes. The transition to Swift seems like an excellent opportunity to simplify things.
|
|
#
¿
Jun 21, 2015 03:39
|
|
|
That pipermail interface is barely an interface. I feel like the Swift guys are intentionally clinging to the mailing list as a method of weeding out contributors. If you want to participate, you have to put up with a pretty arcane communication system. As a lurker curious about the language but not dedicated enough to read through a daily email log, I mostly get by with Erica Sadun's recaps. If I want to find an actual post, the only not totally lovely solution I've found is to use Gmane's still operational NNTP server and browse with a newsreader: nntps://news.gmane.org/
|
|
#
¿
Aug 1, 2016 01:41
|
|
|
I'm sorry if I was flippant in my criticisms of the mailing list or too uncharitable in assuming dark motives behind the choice, but I think we just fundamentally disagree about mailing lists. I called them arcane because they match the dictionary definition of arcane: "understood by few." I haven't used one since university, and even then they felt crufty and on their way out. It's asking people, many of whom at this point don't even like using email anymore, to turn their email client into a discussion forum by learning special unwritten community rules about how and where to reply. Most people, even tech people, suck at email, so why turn an email client into a discussion forum rather than make a discussion forum? Pointing at the availability of an email archive and saying "Go ahead and make your own archive" is also not a good or friendly solution for a publicly developed programming language. The lack of a quality official archive on the internet makes it much harder for people to see what has and hasn't been discussed. The idea of "just search your email" or "just make an archive out of the mbox format" is essentially asking every person who may have an idea for the language or something to contribute to also take on the role of librarian. It's not a theoretical problem either. Because the current piper mail archive is so unpleasant, a ton of swift evolution proposals now have dead links to defunct gmane archived posts. Why did that happen? Because people want web links and an easy way to search and an easy way to read discussion threads. Navigating a giant chain of re: re: re: emails with fifteen layers of nested quoted text and interspersed replies is not friendly and creates an atmosphere of "Only those who know the ancient ways of the pre-web may enter." To be clear, I'm not angry about any of this. I wish it was handled in a friendlier way, but I think the current solution's weeding out element may actually be useful in a language that has very smart people at the helm and a dedicated community of iOS/Mac developers who are willing to put in the time with the mailing list system. Again, maybe there should be a modest barrier to entry for participating in the design of a programming language, but I think it's a little silly to argue that the mailing list is obviously the best way to handle things and to ignore how it biases the group participating in the language toward a particular subset of older programmers who grew up on mailing lists.
|
|
#
¿
Aug 1, 2016 07:05
|
|
|
Gul Banana posted:using mailing lists isn't for old people, it's for people whose job regularly, rather than peripherally, involves this sort of collaboration. as soon as you are involved in the development of more than one thing, mailing lists for each is superior because it lets you have a single mail client rather than separate accounts on multiple differently-interfaced websites That's a great point and I see how it would work better for someone in that situation. I'm fine with Swift prioritizing those people since they do the vast majority of the work, but it's definitely a small minority of all the people who might be more interested in participating in a more public forum.
|
|
#
¿
Aug 1, 2016 15:34
|
|
|
|
| # ¿ May 3, 2024 07:04 |
|
|
Swift String Manifesto Very cool to see how much thought is being put into better Unicode strings for Swift 4 and 5. A lot of the details here fly over my head because I'm not well versed in the complexities of Swift's type system, but I'm glad to see the team is going back to treating Strings as collections. I understood why they went away from collections, but working with strings in Swift 3 feels like it requires you to learn all the intricacies of Unicode to do any operation.
|
|
#
¿
Jan 20, 2017 19:46
|
|