Re: Swift
Re: Swift
- Subject: Re: Swift
- From: Drinktomi <email@hidden>
- Date: Thu, 05 Jun 2014 21:22:13 +0200
On Jun 5, 2014, at 20:18, Mark Bernstein <email@hidden> wrote:
> All the discussion of modulo arithmetic and the range operator syntax, it seems to me, is missing the boat. Surely these are minor features of the language.
I agree.
> Questions that I've not yet figured out in my first pass through the book -- and which I think will also matter a lot -- include:
>
> • support for polymorphism. In C++, we dispatch on the type of the operand:
>
> bool DoSomething(int);
> bool DoSomething(const string&);
> bool DoSomething(Widget*);
>
> ObjC doesn't do this, which complicated writing Visitor patterns among other things. Where does Swift land?
I suspect that generics will be your friend here.
> • the beefy switch statement is interesting, but I think lots of sentiment views switch() as a code smell. What’s its motivation?
In functional languages case statements are a primary element. I think the beefy switch learns from those languages. Remember, lots of things that are code smells in C/C++ are results of the design choices in those languages (and their decedents.)
> • the language is billed as offering better runtime performance, presumably because it's easier to optimize than ObjC. However, it does accept a number of performance hits, such as range-testing array references. I'm finding it a bit difficult to imagine that optimizations can make up for these; what am I overlooking?
Unchecked array accesses == buffer overflow attack.
> • the language appears to encourage inner classes and inner functions. My sense of the community is that inner classes are now thought to be a code smell in C++ unless they're trivial functors or comparators. What am I overlooking?
C++ is a poor measuring stick for language features. It’s a mess. Javascript is nothing but inner classes and functions.
> • All top-level definitions are implicitly visible to clients -- private and protected members are coming in the future. No header files, no formal declaration of external interface. This strikes me as an odd choice for a language intended for moderately large and large systems. No doubt I'm simply missing a feature: what is it?
I think what you’re missing is the impact of bounds checking, automatic memory management, ease of function definition (no header files!), and sane reference management.
The features of the C language family seem to make those languages particularly susceptible to both the desire to muck with internal structure representations (probably from the overhead of function definitions), and horrible side effects from doing so. C languages cry out for access control.
There are languages (Python, Ruby, Smalltalk) which depend upon convention and social standards to regulate access, and do a fairly good job of it. I think that in general visibility control is still somewhat of an open issue in language design.
I also think no language designer ever said, “What this language needs are header files like C."
> • The language has been touted for its performance, but it's not clear that it's been designed for runtime speed the way Go (say) was designed for compilation speed. The language has been touted for its accessibility to younger programmers, but the book is clearly pitched to pros, the frameworks are certainly pitched to pros, and a language that features generics, tuples, and functional programming so prominently is not going to be especially easy to teach. What am I missing?
Tuples, generics, and functional programming elements are pretty easy to deal with in a well designed language.
How many beginning programmers ask, ‘How do I make a bhah of foo's, just like an array of foo?’. Unfortunately without generics the answer to that is that you can't . The work-arounds for a lack of generic are what get really complicated. You can bend them to do amazing things, but the beginning cases are really easy to teach.
Python uses tuples all over the place and it has first class functions and lambdas, but nobody considers it a difficult language to learn.
Javascript is nothing but higher level functions and nobody really thinks of it as a difficult language to learn.
-jeff
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Xcode-users mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden
| References: | |
| | >Swift (From: Mark Bernstein <email@hidden>) |