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

741–750 of 970 posts

Re: The Swift Programming Language

#741

Post by jfb »

IanDrake wrote: post #515
te_chris wrote: post #202

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

My dislike is that it uses [] for method calls. It's like making Objective-English where we swap Z and A and j for o, just for the hell of it. If thzt sjunds like fun tj yju, thzn gj fjr Jboective-C.

This is in my opinion the best thing about Objective-C; it clearly delineates the object/class and C dichotomy, making it easier for a C programmer (or a Smalltalk programmer!) to pick up. For years, the only changes from vanilla C were the brackets, "#import" and the @ literal syntax (IIRC).

Re: The Swift Programming Language

#742

Post by Pacabel »

coldtea wrote: post #725
Pacabel wrote: post #690

Earlier quoted context omitted.

My apologies, I didn't realize that expecting a programming language to have a stable syntax, stable semantics, a stable standard library and at least one stable and robust implementation before using it seriously in industry was merely a "game". Perhaps this is news to you, but those of us who work on and are responsible for large-scale software systems tend to take such factors very seriously. This may sound harsh,…

> My apologies, I didn't realize that expecting a programming language to have a stable syntax, stable semantics, a stable standard library and at least one stable and robust implementation before using it seriously in industry was merely a "game" You also didn't realize that you just built the biggest strawman ever in the above sentence. Enough with the "I want a stable Rust now". Rust, like any other language, take…

Well, we aren't actually seeing stabilization when it comes to Rust.

Assuming this stabilization actually does happen, whether it happens in public or private is irrelevant.

What matters is that we've seen C++ stabilize. We've seen Go stabilize. We've seen Scala stabilize. And now we'll likely see Swift stabilize, well before Rust does. They are all serious competitors to Rust.

As these other languages continue to evolve, but at the same time remaining usable, the relevance of Rust will continually decrease. It may still have drawing power today. A few years from now, it will have less appeal.

Re: The Swift Programming Language

#743

Post by coldtea »

Udo wrote: post #687
curveship wrote: post #681

Earlier quoted context omitted.

> In this example, the compiler could not possibly have known I was going to access x. Right, but it knew you were going to use eval, and to support that, it had to allocate all local variables in the closure. That's why you saw this behavior. The same would happen if you used a 'with' construct.

> Right, but it knew you were going to use eval, and to support that, it had to allocate all local variables in the closure. Wow, so there is actually special handling in the engine for this? So it does static analysis whenever it can, but not in these two cases?

Yes, and in articles describing it (v8), they explicitly warn you to not use "eval" or "with" for the performance impact.

Re: The Swift Programming Language

#745

Post by Pacabel »

coldtea wrote: post #734
Pacabel wrote: post #709

Earlier quoted context omitted.

Are you honestly suggesting that Rust is stable at this point? I think that the recent, and very disruptive, ~ and box changes should completely dispel that notion. I'm merely pointing out the reality of the current situation, which some in the Rust community do not wish to acknowledge, for whatever reason. The situation has yet to change, so what I'm saying is still valid, and will remain so until some actual improv…

> Are you honestly suggesting that Rust is stable at this point? I think that the recent, and very disruptive, ~ and box changes should completely dispel that notion. No, he merely suggests that you bored a lot of people by repeating that it's unstable, instead of accepting the fact and using something else. If being unstable is that bad, then by all means, go and use a stable language.

I, and many others, do use something else. That's the big problem facing Rust, whether or not its creators wish to admit this fact.

There are numerous alternatives to Rust that offer many of its benefits, but they're usable today. We can rely on them today, tomorrow, and likely for some time to come.

And by this fall, we'll likely have Swift as yet another option to add to our growing list.

I think Rust has a lot of potential. But each month that goes by squanders that potential. It has less and less of a chance of making a real impact the longer it isn't usable, especially while its competitors keep evolving.

Re: The Swift Programming Language

#746

Post by hornetblack »

outworlder wrote: post #423
abruzzi wrote: post #88

Unicode variables, I love it: let 🐶🐮 = "dogcow" Moof!

The only practical use is that we can assign functions to a variable named λ Or define a type alias to that. On a more serious note, several languages have that, Ruby included.

I've only seen one thing actually use it in Go:

    	func Polar(x complex128) (r, θ float64) {
    		return Abs(x), Phase(x)
    	}
It seems to be good for documentation reasons.

Re: The Swift Programming Language

#747

Post by coldtea »

reuven wrote: post #739

I find it a bit sad that with all of the languages that already exist, Apple found it necessary to invent a completely new one -- and then make it proprietary. Why not use Ruby, or Python, or JavaScript -- or even Go, Rust, Clojure, or Scala? (Yes, I realize that the latter two run on the JVM, which would have been problematic in other ways.) Heck, they could have bought RubyMotion and made Ruby the high-level langua…

>Why not use Ruby, or Python, or JavaScript -- or even Go, Rust, Clojure, or Scala? (Yes, I realize that the latter two run on the JVM, which would have been problematic in other ways.) Heck, they could have bought RubyMotion and made Ruby the high-level language of choice for development.

Because OBVIOUSLY none of them solve the problems they wanted to solve (interoperabillity with Objective-C, fast, native, IDE integration, etc. Including RubyMotion which is a half-arsed implementation.

Re: The Swift Programming Language

#748

Post by curveship »

kevingadd wrote: post #723
curveship wrote: post #705

Earlier quoted context omitted.

So go ahead and run his test. Things have changed :). Memory builds up 1mb/second, then after a few seconds, you'll see it drop back to zero, as the GC runs. V8 has seen a lot of really nice optimizations to closures over the last year. My favorite is that closures are no longer considered megamorphic.

Oh wow, when did that land? I was getting hit by that leak with JSIL in the last couple months. Can you link to the commit?

Not sure the date. I first noticed the change back in April, when I was profiling some code. Ask vegorov: http://mrale.ph/blog/2012/09/23/grokking-v8-closures-for-fun... .

Re: The Swift Programming Language

#750

Post by georgewfraser »

serf wrote: post #666
georgewfraser wrote: post #574

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.

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…

I'm not actually familiar with the context in which this checklist was originally written. But I really love it for two reasons:

First, it demonstrates how programming languages have been making the same tradeoffs for years, to the point that someone was able to make a checklist of what's wrong with any programming language that still works years later.

Second, you can fill this out for any of the big programming languages and many will do very badly. It shows how whether a programming language succeeds is unrelated to how good it is. An actually accurate checklist would have one item:

You're programming language will succeed because:

[X] It is tied to a popular platform.

Post reply on HN