[swift-evolution] A mode with no type checking to compete with Python.

[Alex Lew]

Yes! As a high school CS teacher, agreed 100%. This is what makes Racket /
Scheme such a great introductory language: there is really only one type of
syntax mistake you can make, and it's having mismatched parens (something
that the IDE makes it easy for students to see). When students move on to
Java for AP, in come the errors. I've seen students give up on CS because
they can never compile their code -- in one case, for example, a student
was putting semicolons after every if statement, for loop, while loop, and
method definition, before the opening curly brace. (In my experience,
syntax presents a bigger hurdle than type errors.)

Swift is not, primarily, a teaching language *for beginners*. (It makes a
great teaching language for intermediate and advanced students, or students
who want to learn about fancy type systems.) Its type system is extremely
powerful but also beyond the scope of an introductory programming course.
That said, playgrounds *are* very cool and help alleviate some of the
frustration of writing a long program and having it not compile.

On Sun, Dec 6, 2015 at 1:42 PM, Paul Cantrell via swift-evolution <
swift-evolution at swift.org> wrote:

> I think Python's biggest appeal to new programmers is the fact that it has
> such a great standard library
>
>
> This is not the case, at least in my teaching experience.
>
> One of the largest hurdles for new programmers, and the one that
> differentiates beginning languages more than any other, is compiler
> strictness. This includes both syntax and static type checking.
>
> We easily forget how hard learning syntax is: to see every piece of
> punctuation as significant, to read code as a parse tree, to think inside
> the box of the language’s type system. Programmers in their first months
> easily spend 50% of the time getting their code to compile, usually more
> like 80%.
>
> The problem with compile-time strictness of any kind is that the compiler
> won’t do _anything_ until _everything_ compiles. I’ve seen this drive
> beginners to burnout, even drive them away from CS altogether. (To help
> calibrate your thinking about just how much we’ve forgotten that we
> learned: eons and eons ago, when my department taught its intro courses in
> Pascal and C++, the main first-year hurdle was not dealing with unsafe
> pointers, but knowing where to put the semicolons. Semicolons!)
>
> When you don’t understand what a failure looks like, it’s tremendously
> helpful to be able to actually run the code and see the failure happen.
> Having the language say “this can’t possibly work so I won’t run it” is not
> helpful to beginners; it’s just bottled frustration. Having the language
> say “it worked until I got here, at which point this happened” is
> infinitely more helpful.
>
> The biggest hurdle to a beginning programmer is how _stupid_ programming
> makes one feel. We experience programmers are all used to this. Beginners
> are not. Their successes are rarer, the obstacles more daunting. Every
> stumble feels intensely personal. Anything that makes success more
> incremental and more self-discoverable helps.
>
> • • •
>
> You might think at this point that I’m arguing in favor of the “no types
> to compete with Python” mode, but I’d vote against it.
>
> The ideal beginner language has a flexible, forgiving syntax that rewards
> guessing; the least compile-time type checking possible; and very clear
> error messages (both compiler and runtime). On all three counts, this
> sounds very far from Swift today. Better error messages would be good for
> all of us, but the other two just don’t sound like Swift.
>
> Good beginner languages reward exploration by empirical experimentation.
> Good professional development languages reward clarity of intent. Those two
> things are often in tension, and Swift’s core aesthetic clearly lands on
> the side of the second.
>
> Is making it a good language for new beginners truly a design goal of
> Swift? I don’t think it should be. It _does_ seem like an excellent design
> goal to keep the language as simple, approachable, and learnable as it can
> be within its aesthetic.
>
> Cheers,
>
> Paul
>
> P.S. The Bret Victor article that describes the thinking behind
> playgrounds has some oustanding ideas on making languages more learnable:
> http://worrydream.com/#!/LearnableProgramming
>
> –––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––
> https://innig.net • @inthehands • http://siestaframework.com/
>
>
> On Dec 5, 2015, at 6:13 PM, Austin Zheng via swift-evolution <
> swift-evolution at swift.org> wrote:
>
> No, I don't. I think Python's biggest appeal to new programmers is the
> fact that it has such a great standard library, making it really easy to do
> whatever you want to do without figuring out how to find or add in external
> dependencies.
>
> Anyways, mistyped Python code still breaks, it just breaks at runtime
> instead of compile time. In fact, I'd argue that this is even less beginner
> friendly, since you might write a function that works with some inputs and
> then inexplicably breaks with others.
>
> Austin
>
> On Dec 5, 2015, at 4:09 PM, Amir Michail < a.michail at me.com> wrote:
>
>
> On Dec 5, 2015, at 7:05 PM, Austin Zheng via swift-evolution <
> swift-evolution at swift.org> wrote:
>
> ml>
> I disagree with the idea that a type system is too much of a hurdle for
> beginner programmers to overcome.
>
>
> Don’t you think that Python currently provides a better introduction to
> programming due to its simplicity?
>
>
> Austin
>
> On Dec 5, 2015, at 4:01 PM, Kevin Lundberg via swift-evolution <
> swift-evolution at swift.org> wrote:
>
> This is somewhat possible today on Apple platforms with AnyObject. You can
> call any objc-visible method on AnyObject and it will compile, and the
> return type will also be AnyObject (I don't recall if the return type is
> optional as well or not). This doesn't work with value types, but neither
> does id in objc.
>
> Having a more complete lax typed mode similar to Python or php I think is
> of limited usefulness, would add too much complexity to the language, and
> yield too much uncertainty about any given piece of swift code.
>
> --
> Kevin Lundberg
>
> On Dec 5, 2015, at 6:50 PM, Adrian Kashivskyy via swift-evolution <
> swift-evolution at swift.org> wrote:
>
> I can't believe I'm seeing a proposal to remove type safety, one of the
> fundamental features of Swift...
>
> Regards,
> Adrian Kashivskyy
> iOS Developer at Netguru
>
> Wiadomość napisana przez Amir Michail via swift-evolution <
> swift-evolution at swift.org> w dniu 05.12.2015, o godz. 20:51:
>
> Python is still easier than Swift for beginning programmers. But maybe
> such a mode can allow Swift to be used by beginners also?
> *____________________________________________*_ swift-evolution mailing
> list swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
>
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
>
> --r‡bž Úḟîẁ
> ‰íz{CŠÊhĠ+bḃx§–)Ŷ_______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/ma
>
>
>
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
>
> Untracked with Trackbuster <https://trackbuster.com/?sig>
>
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20151206/c86e2160/attachment.html>