5 ms·

> They add way too much surface area to the language by allowing too many ways to do a given thing. Not relevant to most situations, but I'll just add that thi

> They add way too much surface area to the language by allowing too many ways to do a given thing. Not relevant to most situations, but I'll just add that this also makes it extremely difficult to teach a language. I have taught Ruby -- a language with quite a sweet tooth -- for almost twenty years, and I feel like it gets worse and worse every year. Students run off to look at example code online (as they should), but discover that I have been teaching them what seems to them like a different language. It really leaves me with no choice but to spend a lot of time in lectures saying, "You can do it this way . . . or this way . . . or this way . . . and by the way, these are all semantically equivalent."

favorited 7y ago
The concept of progressive disclosure means that you shouldn't teach this kind of stuff to beginners. Stuff like callAsFunction, dynamic member lookup, etc. are for people who are writing DSLs, providing rich libraries, etc.
- zionic 7y ago
  Progressive disclosure does absolutely nothing for your students looking up example code only to be greeted by alien syntax that does the same thing. Pretend you know nothing about a language, why would you assume .map { $0.thing } and .map(\.thing) are even remotely similar?
  - Razengan 7y ago
    You would look it up, as you would for anything else you see for the first time.
    - keenmaster 7y ago
      I wonder if there's a coding interface for beginners that works as follows: The beginner types a declaration of "I want to _____" and the interface uses ML to auto-suggest code. The auto-suggest would be context-sensitive and fit in with previously written code. Auto-correct would work similarly. If the declaration isn't specific enough, then the auto-suggest tool would ask a series of questions that illustrate the different choices a programmer can make in achieving their goal. Finally, the tool would output code that reflects the beginner's choices. This would increase the speed of the think-do feedback loop. Beginners would be able to jump into coding with very minimal education and "make" the application they want straight away. Of course, it would usually behoove them to eventually read some programming books and take classes, but this tool would pique their interest. The power of the auto-complete would scale back as the beginner progresses unless they get stuck. Maybe this would only work on a finite set of projects that the ML was trained on, which is fine because you can just give a lot of projects to choose from. That is until the ML becomes more powerful and generalizable.
    - hndc 7y ago
      Among the drawbacks of excessive syntactic sugar is that it is often difficult or impossible to look up
      - Razengan 7y ago
        Do you have examples of that?
zionic 7y ago
Syntax duplication has a huge cognitive overhead.
- pkolaczk 7y ago
  Scala knows something about this and made a 180-degrees turn recently. Swift is a lot like Scala. Swift creators, please not repeat Scala's mistakes.
  - cmollis 7y ago
    I use Scala everyday (in spark) and generally prefer it over java but I agree that the surface area is too large. This is really evident when you start to import someone else’s libraries. The breadth of the language affords many different paths for the library writer depending On how much of a language sniper they are.

favorited 7y ago

The concept of progressive disclosure means that you shouldn't teach this kind of stuff to beginners. Stuff like callAsFunction, dynamic member lookup, etc. are for people who are writing DSLs, providing rich libraries, etc.

zionic 7y ago
Progressive disclosure does absolutely nothing for your students looking up example code only to be greeted by alien syntax that does the same thing. Pretend you know nothing about a language, why would you assume .map { $0.thing } and .map(\.thing) are even remotely similar?
- Razengan 7y ago
  You would look it up, as you would for anything else you see for the first time.
  - keenmaster 7y ago
    I wonder if there's a coding interface for beginners that works as follows: The beginner types a declaration of "I want to _____" and the interface uses ML to auto-suggest code. The auto-suggest would be context-sensitive and fit in with previously written code. Auto-correct would work similarly. If the declaration isn't specific enough, then the auto-suggest tool would ask a series of questions that illustrate the different choices a programmer can make in achieving their goal. Finally, the tool would output code that reflects the beginner's choices. This would increase the speed of the think-do feedback loop. Beginners would be able to jump into coding with very minimal education and "make" the application they want straight away. Of course, it would usually behoove them to eventually read some programming books and take classes, but this tool would pique their interest. The power of the auto-complete would scale back as the beginner progresses unless they get stuck. Maybe this would only work on a finite set of projects that the ML was trained on, which is fine because you can just give a lot of projects to choose from. That is until the ML becomes more powerful and generalizable.
  - hndc 7y ago
    Among the drawbacks of excessive syntactic sugar is that it is often difficult or impossible to look up
    - Razengan 7y ago
      Do you have examples of that?

zionic 7y ago

Syntax duplication has a huge cognitive overhead.

pkolaczk 7y ago
Scala knows something about this and made a 180-degrees turn recently. Swift is a lot like Scala. Swift creators, please not repeat Scala's mistakes.
- cmollis 7y ago
  I use Scala everyday (in spark) and generally prefer it over java but I agree that the surface area is too large. This is really evident when you start to import someone else’s libraries. The breadth of the language affords many different paths for the library writer depending On how much of a language sniper they are.