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

851–860 of 970 posts

Re: The Swift Programming Language

#851

Post by pjmlp »

kibwen wrote: post #777
mwcampbell wrote: post #608

Earlier quoted context omitted.

I'd be interested to know more about what you think of xenadu02's post. Practically, we can't completely stop coding in C/C++ yet, but a large class of software can be written in safer languages already, and it seems to me that once Rust is mature, we should strongly prefer it over C or C++. The security problems with non-memory-safe languages are really that bad.

We have to be realistic. C is never going away. C++ is never going away. When has any entrenched programming language ever gone away? As someone who has been paid to write code in RPG ( https://en.wikipedia.org/wiki/IBM_RPG#Example_code ), I can confirm: never ever, ever ever. The best that we can do is to offer an alternative. The reason why I put so much effort into Rust is because people who need to write the soft…

> We have to be realistic. C is never going away. C++ is never going away.

Not in the coming years, but it eventually will become a legacy language like RPG is, confined to old boxes running on long term maintenance contracts.

All is needed are a few mainstream OS where those languages are no longer part of the standard SDK. Like for example Microsoft just did with C as of Windows 8. Even their latest C99 compatibility changes were only done as they are required by C++11/14, nothing else.

> I feel like the vast majority of the new programming languages coming out these days were conceived to make programming more pleasurable for the programmer.

This was already possible with Lisp, Smaltalk, Mesa/Cedar, Modula-2, back when C was created, but then AT&T had better relationship with universities than Xerox PARC and ETHZ did.

Re: The Swift Programming Language

#852

Post by toyg »

rev087 wrote: post #827
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…

Apple is a big, rich corporation. But in that campus there are still human developers. Radical hypothesis: what if this started as a pet project, got the attention of more employees, then management (with or without convincing from said developers). Management sees the value in the project, and funds it officially. You know, like other big, rich corporations...such as Google.

When the project lead is one of the creators of LLVM (arguably the most fundamental low-level project in Apple after actual kernels), this sort of scenario is improbable.

Much more probable is that somebody asked top-developer Lattner for "a simpler language to compete with Java/Dalvik and C# with more casual developers" and he came up with Swift. The name itself is a message: "this thing is quick - quick to learn and quick to run, unlike VM-based stuff that must translate to Obj-C (fast to learn, slow to run) or Obj-C itself (fast to run, slow to learn)".

Re: The Swift Programming Language

#853

Post by axman6 »

chj wrote: post #719

There are cool things in Swift, but I hope they just promote Javascript to a system language so that all platforms can go towards a single code base.

iPhone apps need to be more webscale and NoSQL compliant too. And what about event based? (Hmm...)

Re: The Swift Programming Language

#854

Post by axman6 »

alex2014 wrote: post #819

Do we know if enums can be recursive? i.e. enum BinaryTree = { case Leaf(Int) case Node(BinaryTree, BinaryTree) }

I saw somewhere else today that someone tried it and it crashed the compiler, so I guess not. The string "recur" doesn't even occure once in the iBook. It seem though that you might be able to use a combination of objects and enums to get that.

Re: The Swift Programming Language

#855

Post by hrktb »

Glide wrote: post #609
hrktb wrote: post #596

Earlier quoted context omitted.

I don't think the problem disappears so easily. It puts a signifiant burden on the programmer (on the top of my head, if I have a set of 20 properties in an object, all optionals, I'll have to unwrap them all, even if I can guarantee by knowledge of the data that they're not nil), it will still throw an error if a value became nil after the test, and there is still the implicit unwrapping system that would cause runt…

I was looking through the programming language referenced that was published and the patterns that it uses to deal with Optionals isn't that bad. Having the question mark helps a great deal as a mental check when comparing syntaxes. In my opinion, having that as a language rule will probably force people to design their classes to have things set at initialization more often than not.

> In my opinion, having that as a language rule will probably force people to design their classes to have things set at initialization more often than not.

Good point. There are some interesting work in javascript, like Om, to mainly use immutable objects, it could go in the same direction.

Re: The Swift Programming Language

#856

Post by finnnk »

msie wrote: post #663
MichaelGG wrote: post #642

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.

No, F# runs everywhere C# does - you don't need a PC.

Re: The Swift Programming Language

#857

Post by jamra »

mseepgood wrote: post #674
jamra wrote: post #581

Earlier quoted context omitted.

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 o…

It reminds me of Go in what it omits from C. There are similarities. Go feels like a mix between python and C.

I haven't gotten to Swift in a deep enough way, but it looks like it tried to tackle the same problems with the exception of concurrency. There are differences such as classes and generics in Swift. There are also similarities such as functions as first class citizens (or so it appears so from the closures section of the free book).

All in all, it reminds me of Go just a bit. It doesn't remind me of all of those other languages that I do not know.

Re: The Swift Programming Language

#858

Post by Someone »

nl wrote: post #675
Someone wrote: post #517

Earlier quoted context omitted.

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...

The correctness of that image can be discussed. Fortran was specified in 1954, but the first compiler shipped in April 1957 (http://en.wikipedia.org/wiki/Fortran#History). That is earlier than Algol 58 (first two implementations in 1958 (http://en.wikipedia.org/wiki/ALGOL_58#Time_line_of_implement...), but close.

More importantly, "inspired by" does not imply that Fortran 58 is Algol-like (that same picture would declare Fortran Lisp-like, too)

For me, http://en.wikipedia.org/wiki/Fortran#Simple_FORTRAN_II_progr... certainly is nothing like Algol.

Re: The Swift Programming Language

#859

Post by austinz »

mwfunk wrote: post #816
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

I understand why ObjC's syntax makes some people bristle, but I've never felt that way myself. It's sort of like the people that really hate Python for no other reason than the meaningful whitespace. It's unconventional, but once you understand the rationale for it it makes sense in a way that is at least forgivable if not likable. There have been a lot of C-based object-oriented APIs over the years. GObject has a C…

According to http://en.wikipedia.org/wiki/Objective-C#History, that's actually almost exactly how it came to be. (Apple even experimented with changing the syntax: http://en.wikipedia.org/wiki/Objective-C#.22Modern.22_Object...)

Re: The Swift Programming Language

#860

Post by VeejayRampay »

timr wrote: post #684
VeejayRampay wrote: post #639

Earlier quoted context omitted.

Ruby is simple and beautiful, isn't it? Too bad it never got the shower of money from big backers Javascript, PHP and now Swift got blessed with.

Beauty is in the eye of the beholder, but Ruby is anything but simple. It has one of the most complicated syntaxes of any programming language in common use. Perl and C++ are still in the lead, but with stuff like the gratuitous introduction of alternate hash syntax, new-style lambdas, etc., Ruby is catching up.

Introduction of a new hash syntax wasn't gratuitous really. I think the point was to make up for the lack of proper keyword arguments. Now that they're available, it's true that it doesn't have a reason to stand on its own, but it does make the code more readable and concise, as does the stabby lambda syntax. Though I do agree with your point on simplicity really, the language does offer way too many ways to do the same thing sometimes.
Post reply on HN