Live data from Hacker News

The Swift Programming Language

developer.apple.com

661–670 of 970 posts

Re: The Swift Programming Language

#661
post #382

Earlier quoted context omitted.

I don't get the hate. Yeah, syntax is unfamiliar, bu once I got used to it I began to really enjoy objective-c. Ymmv etc., but it's now one of my fav languages - though I guess this is mostly due to cocoa

You may not hate Objective-C, but I doubt you love it either. Have you / would you ever use Objective-C to write a web back-end? To write a command-line tool?

I've done both, they were fun projects :)

The only thing that got in the way was the difficulty using the code away from OS X or iOS, and the fact that a lot of libraries for things like database access (especially those intended for iOS) were never intended to be used in a long running process. I found slow (3 week) memory leaks that someone writing an iOS app would never have hit.

Re: The Swift Programming Language

#662
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…

I think everybody can see their own favorite language in it... and that's a good thing.

For me it looks like Scala + a sprinkle of C++14 :)

Re: The Swift Programming Language

#663

Earlier quoted context omitted.

Visual Studio isn't free in that regard either. What exactly are you comparing this release to?

VS has non-paid versions. And C# and F# compilers are open source.

Yes, but you need Windows and a Windows PC to run them. I guess you could get Linux for C# and F# but you still need to buy a PC.

Re: The Swift Programming Language

#664

Earlier quoted context omitted.

The similarity to Rust should scare the hell out of Rust's creators and proponents. Swift could very well render Rust almost totally irrelevant within the OS X and iOS sphere of software development. If we end up eventually seeing Swift implemented for other platforms, then the chances of Rust's long-term success diminish even more. Things might have been different had a stable, even if somewhat imperfect, initial ve…

C++ moving to a 3 year standard cycle is a much bigger 'threat' to rust. But really, the fact that there's so much actual investment in improving mainstream languages from various well-funded sources is probably a rising-tide-lifts-all-boats kind of thing.

Yes, I do agree that the situation is improving across the board.

But as an industry, we need practical solutions that are available now, even if somewhat flawed. We need languages we can use today, and know that the code we write today will still compile fine next week and next year, if not a decade or more from now.

Modern C++ is getting pretty good at offering this, while offering far a greater degree of safety. Go isn't bad, either. Scala has its drawbacks, but it's often a reasonable option, too. The key thing to remember is that all of these languages have offered developers a stable target, and they are seriously usable in the present.

Given the announcement of Swift, and given that Apple will very likely deliver on it by the fall, we very well could see it becoming a major player during 2015.

The safety benefits that Rust could theoretically or potentially offer are virtually useless to huge swaths of the industry as long as the predictability of a stable release just isn't there. The longer this wait goes on, the better the competition becomes, and the less relevant Rust will unfortunately become in the long term.

Re: The Swift Programming Language

#665
post #454

Earlier quoted context omitted.

Please. Please. PLEASE don't be whitespace delimited! One of the prime examples I give for how HN/reddit has gone downhill was being downvoted by some clueless hipsters for suggesting that it would be easy to cross-compile from a whitespace-delimited language to a non-whitespace-delimited one. It's not some kind of huge fundamental divide in languages. For any non-whitespace delimited context free language, it should…

If the solution for a feature intended to save time and reduce hassle ends up being "write and maintain your own compiler extension" it's a bad feature. Period. I'm not a fan of whitespace delimiting or type inferencing because while they seems like they save you time and effort, I've found that in the long run you end up spending more time debugging your indentations here or type declarations there than you would ha…

I'm not sure how much Python you've written but I personally have never had to debug problems with whitespace. (I'm had to debug plenty of problems in other languages where the whitespace implied one thing but the curly braces said another).

Re: The Swift Programming Language

#666

Earlier quoted context omitted.

In addition to being a space-hogging recapitulation of an old, boring Usenet joke, a lot of your checks are wrong; some of them are because the Usenet joke is lame, but some of them are just you missing things, like the fact that Swift interacts directly with C/ObjC, uses the same IDE as Cocoa developers already use, &c. This lame Usenet joke was a way of punching down at people joining language newsgroups trying to…

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.

Well, I thought it was funny and I enjoyed reading through the list. You're absolutely right that it provides an insight into the past language efforts and the trade-offs that they inevitably encounter.

I hope you remember that when someone tells you something like 'it doesn't work here' that it's an opinion rather than a fact, regardless of how they phrase it.

The USENET era, while sometimes dated, was probably one of times in 'geek' history where we were the closest to one another. The internet was interpersonal, and i'm glad that someone is still trying to propagate the humor and spirit from that time.

Re: The Swift Programming Language

#667

Anyone know how Swift might achieve its claimed speedup vs. Objective-C? I can't see how it could get the advertised numbers without method inlining, which appears to be incompatible with the dynamic object model that it inherits from Objective-C

Why would method inlining be incompatible with dynamic dispatch?

Re: The Swift Programming Language

#668
post #663

Earlier quoted context omitted.

VS has non-paid versions. And C# and F# compilers are open source.

Yes, but you need Windows and a Windows PC to run them. I guess you could get Linux for C# and F# but you still need to buy a PC.

How are you doing development without a non-mobile OS? But I imagine http://www.tryfsharp.org/ works even for mobile.

Re: The Swift Programming Language

#669
post #397

Earlier quoted context omitted.

I never understood what the fuss was all about either. If you know one other language really well, Objective-C should take a week or two to get use to. To understand all the design patters, apple HIG, XCode, profiling, libraries, debugging, app submission, etc, these combined is where youll sink your time to learn iOS development. Imo, Objective-C is the easy part.

I recently translated one of my Apps from Android to iPhone. I had 0 objective-C experience, but I made it work. It was a bit of a frustrating experience. Many times I found myself writing Objective-C boilerplate-ish code that I had 0 clue what it was doing, considering this is a hobby / for fun project I just wanted it working. It's not easy to google the answer to, "Why did I just add this new keyword after this co…

I felt the same when working on iOS. I felt I was writing way too much boilerplate code, while Android and Windows Phone just gave me a lot more "for free".

Re: The Swift Programming Language

#670
post #667

Anyone know how Swift might achieve its claimed speedup vs. Objective-C? I can't see how it could get the advertised numbers without method inlining, which appears to be incompatible with the dynamic object model that it inherits from Objective-C

Why would method inlining be incompatible with dynamic dispatch?

I was thinking more about runtime method replacement.
Post reply on HN