3 ms·

Swift started out as a pretty nice language, but in my opinion there are some major problems: The combination of ubiquitous closures and reference counting is

Swift started out as a pretty nice language, but in my opinion there are some major problems: The combination of ubiquitous closures and reference counting is dangerous. Avoiding circular references is not nearly as easy as you might think and reference counting is slow (low memory usage is an upside though). And lately, the language has become rather convoluted. They have added features that make Swift code hard to read. Function builders in particular are a terrible idea. I know many people like internal DSLs. I don't. I think it's a big mistake to overload the syntax of a language to such a degree that reading a piece of code in isolation tells you very little about what it does, because somewhere far away there may be a mode switch that completely changes the semantics of that piece of code. Consistency is more important than "looking clean" at all cost.

ralmidani 6y ago
I agree function builders have a lot of potential for abuse. But I prefer to take a "with great power comes great responsibility" approach over saying a feature should _never_ be allowed in a language. If I'm promoting a DSL that makes heavy use of something like function builders, I should provide robust documentation so other developers know what to expect. And those developers should, on the other hand, at least skim the docs in order to get a basic understanding of how the DSL works. If someone goes through the trouble of providing docs to accompany a DSL, and a downstream developer doesn't bother to read them, is that really the original developer's fault?
- fauigerzigerk 6y ago
  Consistency is a good thing, because it allows you to infer how something works based on what you already know. If you can't infer it then you have to go read the docs. That's more work you have to do. There's clearly a trade-off between expressing a specific task as succinctly as possible and for our knowledge to be transferable between different tasks. It is the job of a programming language to guarantee a minimum level of transferability while allowing maximum expressivity. To do that, it has to put restrictions on how the semantics of syntax can be redefined. It's clearly an art to get that balance right. In my view, Swift hasn't got it right and is moving in the wrong direction.
  - ralmidani 6y ago
    I sympathize with your concern. I actually chose Python/Django over Ruby/Rails because I found it almost impossible to understand how Rails really works. The biggest offenders in my book are Rails doing auto-import and (at least when I was learning it) lots of reopening of classes. Even if a person wanted to read the docs to understand where a piece of functionality came from, it was very easy to get lost. Swift does risk getting carried away and becoming just a safer and faster version of Ruby, but I still think it's too early to write it off just because they introduced some syntactic sugar. I've said before that writing an import statement never killed anyone. If Swift were to make something like auto-imports mainstream, I would definitely take it as an indication they were going in the wrong direction. But so far that doesn't seem to be the case.
saagarjha 6y ago
Nit: closures are problematic when they escape. The ubiquitous ones that the functional constructs take (for example) are totally fine.

ralmidani 6y ago

I agree function builders have a lot of potential for abuse. But I prefer to take a "with great power comes great responsibility" approach over saying a feature should _never_ be allowed in a language. If I'm promoting a DSL that makes heavy use of something like function builders, I should provide robust documentation so other developers know what to expect. And those developers should, on the other hand, at least skim the docs in order to get a basic understanding of how the DSL works. If someone goes through the trouble of providing docs to accompany a DSL, and a downstream developer doesn't bother to read them, is that really the original developer's fault?

fauigerzigerk 6y ago
Consistency is a good thing, because it allows you to infer how something works based on what you already know. If you can't infer it then you have to go read the docs. That's more work you have to do. There's clearly a trade-off between expressing a specific task as succinctly as possible and for our knowledge to be transferable between different tasks. It is the job of a programming language to guarantee a minimum level of transferability while allowing maximum expressivity. To do that, it has to put restrictions on how the semantics of syntax can be redefined. It's clearly an art to get that balance right. In my view, Swift hasn't got it right and is moving in the wrong direction.
- ralmidani 6y ago
  I sympathize with your concern. I actually chose Python/Django over Ruby/Rails because I found it almost impossible to understand how Rails really works. The biggest offenders in my book are Rails doing auto-import and (at least when I was learning it) lots of reopening of classes. Even if a person wanted to read the docs to understand where a piece of functionality came from, it was very easy to get lost. Swift does risk getting carried away and becoming just a safer and faster version of Ruby, but I still think it's too early to write it off just because they introduced some syntactic sugar. I've said before that writing an import statement never killed anyone. If Swift were to make something like auto-imports mainstream, I would definitely take it as an indication they were going in the wrong direction. But so far that doesn't seem to be the case.

saagarjha 6y ago

Nit: closures are problematic when they escape. The ubiquitous ones that the functional constructs take (for example) are totally fine.