Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The Swift Programming Language

developer.apple.com

Post reply on HN
Print view View original

671–680 of 970 posts

Re: The Swift Programming Language

#671

Post by mseepgood »

mythz wrote: post #598
tptacek wrote: post #403

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…

It does share Go's `func` keyword, parens-free conditionals, optional semi-colons

That's really not a lot. The optional semicolons could also be influenced by BCPL or JavaScript.

Re: The Swift Programming Language

#672

Post by Pacabel »

mantrax5 wrote: post #607
cratermoon wrote: post #564

Earlier quoted context omitted.

There's no real objective measure for either 'conciseness' or 'safety', in general terms. Whether or not it's faster in the real world is yet to be seen, and creeping featuritis has never been the hallmark of a great programming language. It makes good press release and marketing speak, but those assertions are a long way from making the OP 'wrong'.

So you take a language with null pointers, unsafe pointer access, possibility of array and buffer overflows (C and Objective-C). And then you take another where you have no null pointers, no direct pointer access, and no possibility for array and buffer overflows (Swift). And you say "nah, I look at these two, and I can't objectively tell which is safer"? Are you fuckin' kidding me? Regarding speed, it's been proven…

I think you're putting words into his mouth, and perhaps intentionally misrepresenting what he wrote.

Swift was announced just a few hours ago. While we can make assumptions about its safety based on its feature set, or we can assume that the very vague performance details Apple provided are valid in a real-world setting, none of this has really been tested or verified independently yet.

What cratermoon wrote is perfectly legitimate. Let's try Swift out in the real world, perhaps for a year or two. Let's get some real data. Then let's analyze that actual data, rather than engaging in unsubstantiated speculation, or trusting some vague performance graphs shown in a conference presentation.

Re: The Swift Programming Language

#673

Post by jsmthrowaway »

kibwen wrote: post #643
Pacabel wrote: post #630

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…

Oh hello again, Pacabel. I'm familiar with your game by now. :) We're not scared in the slightest. I'll reconsider when Swift has inline ASM, allocators, linear types, move semantics by default, region analysis, and a type system that guarantees freedom from data races (oh, and when the code is open-sourced, and targets both Linux and Windows as a first-class citizen). Swift isn't intended to be a systems language: i…

It's interesting that inline assembly is your first bullet point, since there's nothing I can think of that ruins a code file more than inline assembly in a host language. Put that crap in a .S file and link it in like everything else, for crying out loud. The one time you need inline assembly is when you don't want to build a function frame, such as a tight loop, but come on.

Also, even in systems, I can think of about once a decade I even need to write assembly, so... maybe grasping at straws a bit?

Re: The Swift Programming Language

#674

Post by mseepgood »

jamra wrote: post #581
tptacek wrote: post #403

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…

Perhaps if you take language features directly, it's not a good comparison with Go. There are some things that did strike me as similar. The approach Go takes is to bring C language to a more modern world (i.e. C without some of the language burdens that we know so well). Swift is attempting to do the same. The way it does type inference is nice. var x = "Hi" reminds me of Go's const types. The ARC usage reminds me o…

> The approach Go takes is to bring C language to a more modern world

Like all the other thousands of languages with C based syntax.

> var x = "Hi" reminds me of Go's const types

Why does it remind you of Go and not of all the other languages that use 'var x = "Hi"' like JavaScript, ActionScript, C#, Scala, Kotlin?

> The ARC usage reminds me of Go's garbage collection

Why does it remind you of Go and not of all the other languages with garbage collection?

Re: The Swift Programming Language

#675

Post by nl »

Someone wrote: post #517
stcredzero wrote: post #206

Earlier quoted context omitted.

It's probably a wise decision to have an "Algol patterned" language. No non Algol patterned language has ever become a mainstream programming language to my knowledge.

I agree with the first, but disagree with the second part: COBOL, Fortran, JCL (not Turing complete, AFAIK), SQL, Excel, DOS batch files all were (fairly) mainstream at some time.

Fortran came before Algol and arguably influenced it[1]. I agree with COBOL and SQL in particular, though.

[1] http://www.digibarn.com/collections/posters/tongues/Computer...

Re: The Swift Programming Language

#676

Post by stcredzero »

cobbal wrote: post #590
stcredzero wrote: post #270

Earlier quoted context omitted.

Yes, but with something CSP-derived, you could design a runtime where you're covered if you use the concurrency facilities correctly, and you're SOL if you don't. Then only the concurrency primitives need atomic refcounts.

Possibly, but it's very handy to let immutable data be read by any thread that wants to. If, however, it's very slightly mutable due to a ref counter, you have to atomically manage the counter, even for what should be free immutable reference.

Possibly, but it's very handy to let immutable data be read by any thread that wants to. If, however, it's very slightly mutable due to a ref counter, you have to atomically manage the counter, even for what should be free immutable reference.

I'm managing something like this in Go. There are no refcounts, but everything is very much mutable. I'm basically arranging for a span of time where I know nothing unprotected by a channel is going to be mutated, then I simply let every thread in the app that cares to read data from every part of the heap, but only during this span of time. The same technique could be applied to a ref counted app. (It would probably work best for games that have a tick.)

Re: The Swift Programming Language

#677

Post by Udo »

Sheepshow wrote: post #660
Udo wrote: post #651

Earlier quoted context omitted.

> Only variables used in the closure are allocated into the closure I'm not sure that's true. Look at the following code: var x = 123; var f = function(xname) { eval('console.log('+xname+');'); } f('x'); It's a dynamically named variable. Clearly, f() has access to the entire context that surrounds it, not just the objects explicitly used in the function code. In this example, the compiler could not possibly have kno…

In your example, X is still in scope when f('x') is called. It doesn't require closure to work.

I think you misunderstand what I'm trying to say. The point is not that x should be out of scope (why would it be?)

The original assertion by curveship was that the outer context is not kept alive for the function, and that f() only gets access to the variables it explicitly imports from the outer context. And I thought this might be wrong, so I cooked up the example.

Again, this is not about scope. This is about the fact that the function itself keeps a reference to the entire context it was created in, as opposed to just the things it explicitly imports.

In this, it appears, Javascript works exactly as Ruby, which again makes the entire outer context available through the binding facility.

I'm sorry if that wasn't clear from my description.

Re: The Swift Programming Language

#678

Post by mblakele »

In the playground REPL, am I missing an easy way to display errors as they happen?

It seems any error messages aren't visible by default. Xcode shows a red "!" disc next to the line, and that's it.

The usual shortcuts for "Jump to next/previous issue" are disabled. Opening the issues tab with command-4 works, but it's empty. Apparently I have to mouse over and click on the tiny red disc to see any error message at all, and then it displays as text that can't be selected or copied.

EDIT: ctrl-command-M turns "Show all issues" on or off. It seems to be a little buggy, which may be why it's off by default. Hopefully we'll get the ability to copy the error text in the next refresh.

Re: The Swift Programming Language

#679

Post by rayiner »

tptacek wrote: post #403
Udo wrote: 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 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…

Not just generics, but pretty fleshed out generics, with type variables constrained by class or protocol.

Re: The Swift Programming Language

#680

Post by kevingadd »

curveship wrote: post #629
Udo wrote: 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…

> It has the concept of explicitly capturing variables from the surrounding context inside closures, like PHP does, instead of keeping the entire context alive forever like Ruby or JS. Just as a point of fact, javascript -- at least the v8 implementation I'm most knowledgeable of -- doesn't "keep the entire context alive forever." Only variables used in the closure are allocated into the closure (i.e. on the heap), t…

This is not accurate. SpiderMonkey and V8 still retain the entire outer scope if any of the variables are used.

See here for an example: https://www.meteor.com/blog/2013/08/13/an-interesting-kind-o...

This bug is still not fixed. There's an issue open for it on the V8 tracker, I believe. It seems to have not gotten fixed in either engine because it's a difficult problem that affects a small subset of JS applications.

Post reply on HN