3 ms·

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

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.

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.