Live data from Hacker News

The Swift Programming Language

developer.apple.com

611–620 of 970 posts

Re: The Swift Programming Language

#611
post #419

Reading people compare Swift to other languages is pretty hilarious. OCaml.. Haskell.. CoffeeScript.. Ruby.. Go... Kotlin... JavaScript.. Scala... No one is saying it so I will: It looks like damn Java 8. It is probably not a good sign that it can be immediately compared to every modern (and not so modern) language in existence.

And Swift seems to resemble another Apple language Dylan, which was based on Scheme/Lisp. All languages since the are in trouble!

I really like that it is incorporating good parts of many, more terse languages. Nothing wrong with selectively absorbing good ideas.

But a huge part is the interactive nature. I dabbled in Smalltalk some years ago and have been annoyed at compiled languages ever since, resorting to things like http://injectionforxcode.com to gain some of that back (on iOS).

Having a live environment can only be appreciated once it has been taken away. I think developing for Apple devices might just become one of the more programming pleasant experiences.

Re: The Swift Programming Language

#612
post #559

Earlier quoted context omitted.

It's not only possible, it's even not uncommon for a C programmer to get a 90X improvement in speed in their own C program. If you have naive memory management, or incorrectly implemented concurrency or parallelism, you can easily lose 2 orders of magnitude speed.

This. In my case a 1Mbyte memcpy in the middle of a loop this morning. Enough to blow the CPU cache out of the water... 300x improvement instantly by moving it out of the loop.

Are you sure it wasn't just because you were then no longer doing a large memcpy repeatedly?

Re: The Swift Programming Language

#613

Earlier quoted context omitted.

I posted the checklist partly in jest, but also because I think it illustrates how every programming language ends up stuck with the same trade-offs.

It really doesn't work here, but also, while I appreciate the spirit you pasted it in, that wasn't the spirit it was written in. (And it takes up a huge amount of space).

It is kind of huge. I tried deleting all the non-checked ones but that defeats the purpose, which is for everyone to form their own opinion of what should be checked.

Re: The Swift Programming Language

#614

Earlier quoted context omitted.

Bret victor's demos really have nothing to do with FP. The textual code demos in his learnable programming essay are all JavaScript and fairly imperative.

As were a lot of the things you could do years earlier in Smalltalk. FP with referential transparency makes it a whole lot easier and slicker. (Can also do it with data flow analysis.)

By 'FP' here you guys mean 'functional programming?'

Re: The Swift Programming Language

#616
post #560

Earlier quoted context omitted.

It's not for the hell of it. [ ] does not mean method call, it is the syntax for a message send. Objective-C is a super set of C, adding an Smalltalk like object system to C. The delimiters say "I am sending a message", which is different to a method call. Also, without them the language would be much more difficult to parse, and future changes to C could break the language. It's lasted well (first appeared in 1993).…

> It's lasted well (first appeared in 1993). 19 8 3, actually.

Thanks - I felt I should type 1983, but if felt wrong! I still had my Apple ][ back then.

Re: The Swift Programming Language

#617
post #432

Earlier quoted context omitted.

I really don't see the Golang influence at all. The multiple- return- value semantic is closer to Ruby's than to Golang's; you're returning a tuple, which happens to have natural syntax in the language. Defining Golang features that don't exist in Swift: - Interface types with implicit adoption (Swift takes explicit protocols from ObjC) - Error types - Relatedly, the "damnable use requirement" and its interaction wit…

> - Interface types with implicit adoption (Swift takes explicit protocols from ObjC) Objective-C has informal protocols, and so does Swift.

Informal protocols and implicit interfaces are not the same thing. In particular, implicit interfaces are type checked statically at compile time, while informal protocols are checked dynamically at runtime.

Re: The Swift Programming Language

#618
post #2

As someone who always disliked Objective C, I think Swift looks very promising. I'll check it out right away :) Software-wise, I feel these current WWDC announcements are the most exciting in years. Looking at the Swift docs right now, I can see many interesting inspirations at work: there's some Lua/Go in there (multiple return values), some Ruby (closure passed as the last argument to a function can appear immediat…

Is it realistic to try to dive right in to the 500-page book they provided without a computer science background, just HTML/CSS/PHP self-taught experience, to learn the language? Or should I take other steps first?

Reading a book cover-to-cover is, for me, a bad way to learn a language. I usually pick things up very quickly when I try to implement things using them that I am both familiar with and faced with annoying issues stemming to the language they are currently implemented in. If you don't have one of those, think about something you hate, and fix it with this.

If the book is good documentation, then use it. But you may benefit from focusing more on problems than completing a book.

Re: The Swift Programming Language

#619

Earlier quoted context omitted.

It's not hate, but Objective-C can be intimidating.

I just spent the past 2 months learning obj-c, about to release my first app and boom, X out obj-c. my luck.

I don't know very much at all about objective C, but the way these things generally work is that you will benefit from the experience as you learn new languages, as it will be an anchor of context against which you may base fresh perceptions.
Post reply on HN