Swift Programming Language Evolution • Hacker News Board

Re: Swift Programming Language Evolution

#131

Post by allsystemsgo » Mon, May 09, 2016, 7:34 PM UTC

tyingq wrote: post #61

matthewmacleod wrote: post #57

Earlier quoted context omitted.

Languages don't have UIs - frameworks do. I realise it's a pedantic distinction, but it's an important one.

I get the distinction, but there appears to be a deliberate direction to make Swift more portable. Thus, I was curious if that effort might include something UI related in the future. The interest level would certainly spike up if something were available.

But, that wouldn't make any sense to include UI components in a programming language. And I think the interest level is already "spiked".

Re: Swift Programming Language Evolution

#132

Post by jaegerpicker » Mon, May 09, 2016, 7:39 PM UTC

riyadparvez wrote: post #109

jaegerpicker wrote: post #89

Earlier quoted context omitted.

I have a production app in the AppStore in 100% swift 2.2. To me it's the most exciting new language out right now. It does not have too many brand new features that other languages don't have but it's implemented most of those modern features in a very solid robust easy to understand and use way. It's functional but not purely, it's object oriented but has great ways to avoid the worst of the designs most of us have…

Can you elaborate more on Swift vs Scala? What are the strong and weak sides of each language?

Very similar languages IMO. Scala is a little heavier on the functional and academic fronts. It's syntax is also much heavier on symbols. In general I think scala has a steeper learning curve. I like scala though. Similar ideas at their core, a mixed paradigm approach. Similar also in that both have a legacy language that they need to interop with. That legacy also bleeds through to both pretty heavily. I also much prefer a native ecosystem vs the jvm.

The one big area that separates the languages is tooling. I personally think Swift's tooling is much better. Faster compilation, faster runtime, faster startup, and better ide tooling.

Re: Swift Programming Language Evolution

#133

Post by grayrest » Mon, May 09, 2016, 7:47 PM UTC

dang wrote: post #103

Submitters: Please don't rewrite titles to say what you think is important about an article. Cherry-picking a single detail is a form of editorializing, which HN doesn't allow in story titles. The guidelines ask you to change titles only when they're misleading or linkbait, which wasn't the case here. If you think one detail is most important, you're welcome to comment on that in the thread. Then your opinion is on t…

Enforcement of this particular policy is one of the things I dislike most about HN. The current title is awful. It gives no information that the URL itself does not and doesn't explain why I'd care about the contents now given I've visited the repo in the past. I'm not opposed to the removal of editorializing but it should get replaced with something neutral that still captures why the URL was submitted, e.g. "Swift 3 Roadmap Update".

Re: Swift Programming Language Evolution

#134

Post by austinz » Mon, May 09, 2016, 7:50 PM UTC

riyadparvez wrote: post #109

jaegerpicker wrote: post #89

Earlier quoted context omitted.

I have a production app in the AppStore in 100% swift 2.2. To me it's the most exciting new language out right now. It does not have too many brand new features that other languages don't have but it's implemented most of those modern features in a very solid robust easy to understand and use way. It's functional but not purely, it's object oriented but has great ways to avoid the worst of the designs most of us have…

Can you elaborate more on Swift vs Scala? What are the strong and weak sides of each language?

Scala tries a lot harder than Swift to unify object-oriented and functional programming principles.

For example, in Scala operators are (IIRC) implemented as methods on objects, there's a 'Nothing' bottom type that is used for covariant generic parameterization, and ADTs are implemented using inheritance in the form of case classes.

Swift has no top-level object type or bottom type, and a lot of its more functional style features (ADTs in the form of 'enums', value types that enforce immutability) are completely divorced from the object-oriented part of the language.

Re: Swift Programming Language Evolution

#135

Post by matthewmacleod » Mon, May 09, 2016, 7:51 PM UTC

carlosrg wrote: post #100

danielrhodes wrote: post #87

Earlier quoted context omitted.

If there was a common native language between Android/iOS, it would make things easier for sure. But using a third language to solve the existing problem is a rookie error. > 90+% of your mobile code can be shared between Android and iOS This stat depends on how complex your app is, but it usually only applies to gaming. Otherwise it's almost always false. We've already been down this path with the webview craze a fe…

I can see you have no idea what Xamarin is. With Xamarin, you still use UIKit and the native Android UI, the difference is that you program it in C# and thus the non-UI code can be shared seamlessly. Performance is not "very meh" as the UI is completely native and Xamarin compiles the C# to native code ahead-of-time. It has literally nothing to do with WebViews.

Hey, you need to read the parent a bit closer.

Nobody's saying that Xamarin uses web views, but clearly there's a comparison to be drawn with the craze a few years back for writing mobile apps using web views. This was advocated as being cross-platform, allowing developers to write the same code and run it on multiple platforms. The downsides are the same in some ways, as the parent enumerated.

Xamarin's use of native UI is important, but in my experience it's clearly not as seamless as you think; while you access the UI natively, there are intrinsic architectural differences that make it difficult to do so in a high-performance manner without a lot of fairly hacky code.

Re: Swift Programming Language Evolution

#136

Post by matthewmacleod » Mon, May 09, 2016, 7:54 PM UTC

skrowl wrote: post #117

zepto wrote: post #108

Earlier quoted context omitted.

There have been 30% stock price drops multiple times during the 13 years of continuous growth. They are clearly not correlated with the actual growth prospects, and if the stock market actually thought that Apple was dropping like a rock as you claim, you would expect to see a far higher discounting. You mention the Mac, which as declined in absolute terms but has continued to grow relative to the declining market. T…

I apologize, as I seem to be failing to convey my message to you. My assertion: Apple is dropping. Be careful about investing in Apple-only techs like Swift. Your argument (I think): Apple is not dropping like a rock. To support your argument, please provide a sources for the following: - The last time Apple stock was down 30% from same day prior year. - iPhone sales are not dropping > 10% (hence 'like a rock') . - M…

Your message isn't really that convincing. Apple, while it may be "dropping", is far from doing so "like a rock" – the platform is clearly huge and will very obviously continue to be so for quite some time. Added to that, Swift is not an Apple-only technology.

Re: Swift Programming Language Evolution

#137

Post by steveklabnik » Mon, May 09, 2016, 7:54 PM UTC

PeCaN wrote: post #120

protomyth wrote: post #37

Earlier quoted context omitted.

Fortran especially. Forth seems to depend on processor characteristics. I seem to remember that Ada compilers routinely produce faster code than C compilers.

Ada and Rust are both significantly easier to perform aliasing analysis on, so frequently you can get much better code. Both languages have slight overhead for bounds checking and such, but you can turn it off (at least in Ada) if it's a problem (hint: it isn't). Same reason Fortran is fast actually: it just disallows pointer aliasing entirely¹, meaning you get none of the flexibility of C pointers (heck, you don't e…

You can call get_unchecked() instead of [] to elide the bounds checking at any place that does it in Rust.

Re: Swift Programming Language Evolution

#138

Post by Razengan » Mon, May 09, 2016, 7:55 PM UTC

shiny wrote: post #14

dalbin wrote: post #13

Earlier quoted context omitted.

There is a pretty good comment from Chris Lattner about ARC versus GC : https://lists.swift.org/pipermail/swift-evolution/Week-of-Mo...

I really like the `deinit` construct that comes with ARC, which lets you know when an object is about to be deallocated. Makes it much easier to find memory leaks, imo.

Indeed. `deinit` has saved me from things that would have caused much greater problems later on. It's probably one of the more subtle features that one would miss the most when moving to a language that doesn't have it.

Re: Swift Programming Language Evolution

#139

Post by mpweiher » Mon, May 09, 2016, 8:03 PM UTC

LeoNatan25 wrote: post #116

mpweiher wrote: post #115

Earlier quoted context omitted.

Not just is reference counting a form of garbage collection (as pcwalton pointed out), it is also not the case that you had to retain/release stuff yourself, certainly not since Objective-C 2.0's properties. Here is the code to define and use a property pre ARC with properties: @property NSString *name; ... object.name = @"Marcel"; And here is the same code with ARC: @property NSString *name; ... object.name = @"Marc…

This is one of the most uninformed posts I have read in a while. As someone who has been developing in Objective C for the last 6 years, and been through the transition of MRC to ARC, none of what is stated in this post is accurate.

Actually, all of it is accurate. Since you're spouting off your credentials as the only evidence for why what I wrote is wrong [not sure how that works], here are mine:

- programmed in Objective-C for ~30 years

- implemented my own pre-processor and runtime (pre NeXT)

- programmed in the NeXT ecosystem professionally since 1991

- additionally, worked in Objective-C outside the NeXT/Apple ecosystem for many years

- worked with Rhapsody and with OS X since the early betas

- worked at Apple for 2 years, in performance engineering (focus: Cocoa)

- one of my projects was evaluating the GC

With that out of the way (and just like your 6 years, it has no actual bearing on correctness): which specific parts do you believe are inaccurate? I'd be happy to discuss, show you why you're wrong, or correct my post if you turn out to be right on something that can be verified (your opinion as to how awesome ARC is doesn't count).

Re: Swift Programming Language Evolution

#140

Post by zepto » Mon, May 09, 2016, 8:25 PM UTC

quux wrote: post #82

zepto wrote: post #18

Earlier quoted context omitted.

No - they already had GC working with Objective-C and could have chosen it for swift if they had thought it was the best technology. Here's a quote from Chris Lattner: "GC also has several huge disadvantages that are usually glossed over: while it is true that modern GC's can provide high performance, they can only do that when they are granted much more memory than the process is actually using. Generally, unless yo…

Yes, they had GC working with Objective-C but there were so many problems with it that they dropped the GC in favor of ARC years ago. By the time Swift came along, GC with Objective-C was no longer an option.

Chris Lattner was already working on Swift when the decision to drop GC was made. Guess who made the decision? Chris Lattner. If anything, GC was dropped because of Swift, not the other way around.