www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - [OT] Apple introduces Swift as Objective-C sucessor

reply "Paulo Pinto" <pjmlp progtools.org> writes:
Just thought it would be nice to give a heads up about Apple's 
plans to replace Objective-C in the long run.

The language was presented today at the WWDC Keynote, looks like 
Ruby, uses ARC alongside the Objective-C runtime.

http://live.arstechnica.com/apples-wwdc-2014-keynote/

It also has a nice REPL experience, similar to Python's 
worksheets in IPython.

--
Paulo
Jun 02 2014
next sibling parent reply "Paulo Pinto" <pjmlp progtools.org> writes:
On Monday, 2 June 2014 at 19:19:27 UTC, Paulo Pinto wrote:

 Just thought it would be nice to give a heads up about Apple's 
 plans to replace Objective-C in the long run.

 The language was presented today at the WWDC Keynote, looks 
 like Ruby, uses ARC alongside the Objective-C runtime.

 http://live.arstechnica.com/apples-wwdc-2014-keynote/

 It also has a nice REPL experience, similar to Python's 
 worksheets in IPython.

 --
 Paulo


More information now made available

https://developer.apple.com/swift/
Jun 02 2014
next sibling parent reply "Steven Schveighoffer" <schveiguy yahoo.com> writes:
On Mon, 02 Jun 2014 15:45:28 -0400, Paulo Pinto <pjmlp progtools.org>  =

wrote:


 On Monday, 2 June 2014 at 19:19:27 UTC, Paulo Pinto wrote:

 Just thought it would be nice to give a heads up about Apple's plans =




to  =


 replace Objective-C in the long run.

 The language was presented today at the WWDC Keynote, looks like Ruby=




,  =


 uses ARC alongside the Objective-C runtime.

 http://live.arstechnica.com/apples-wwdc-2014-keynote/

 It also has a nice REPL experience, similar to Python's worksheets in=




  =


 IPython.

 --
 Paulo


 More information now made available

 https://developer.apple.com/swift/


"Memory is managed automatically, and you don=E2=80=99t even need to typ=
e  =

semi-colons."

...

-Steve
Jun 02 2014
parent reply Nick Sabalausky <SeeWebsiteToContactMe semitwist.com> writes:
On 6/2/2014 3:49 PM, Steven Schveighoffer wrote:

 On Mon, 02 Jun 2014 15:45:28 -0400, Paulo Pinto <pjmlp progtools.org>
 wrote:

 More information now made available

 https://developer.apple.com/swift/


 "Memory is managed automatically, and you don’t even need to type
 semi-colons."

 ...



it probably sums up a lot about the language.

The whole thing sounds like "We love how JS and Python allow mediocre 
programmers to churn out bad software quickly, but since we *are* Apple 
and love strategic lock-in just as much as MS, here's our own goofy 
version of the exact same thing that we're going to push instead."
Jun 02 2014
next sibling parent reply "H. S. Teoh via Digitalmars-d" <digitalmars-d puremagic.com> writes:
On Mon, Jun 02, 2014 at 04:23:47PM -0400, Nick Sabalausky via Digitalmars-d
wrote:

 On 6/2/2014 3:49 PM, Steven Schveighoffer wrote:

On Mon, 02 Jun 2014 15:45:28 -0400, Paulo Pinto <pjmlp progtools.org>
wrote:

More information now made available

https://developer.apple.com/swift/


"Memory is managed automatically, and you don’t even need to type
semi-colons."

...


 

 like it probably sums up a lot about the language.
 
 The whole thing sounds like "We love how JS and Python allow mediocre
 programmers to churn out bad software quickly, but since we *are*
 Apple and love strategic lock-in just as much as MS, here's our own
 goofy version of the exact same thing that we're going to push
 instead."


Seems everyone is fixating on semicolons, but seriously, am I the only
one who sees the elephant in the room? Automatic memory management!!!
Where's Manu and his GC tirades when you need him? ;-)


T

-- 
Don't throw out the baby with the bathwater. Use your hands...
Jun 02 2014
parent reply "Steven Schveighoffer" <schveiguy yahoo.com> writes:
On Mon, 02 Jun 2014 17:00:40 -0400, H. S. Teoh via Digitalmars-d  =

<digitalmars-d puremagic.com> wrote:


 On Mon, Jun 02, 2014 at 04:23:47PM -0400, Nick Sabalausky via  =



 Digitalmars-d wrote:

 On 6/2/2014 3:49 PM, Steven Schveighoffer wrote:

On Mon, 02 Jun 2014 15:45:28 -0400, Paulo Pinto <pjmlp progtools.org=





wrote:

More information now made available

https://developer.apple.com/swift/


"Memory is managed automatically, and you don=E2=80=99t even need to=






 type

semi-colons."

...



 like it probably sums up a lot about the language.

 The whole thing sounds like "We love how JS and Python allow mediocre=





 programmers to churn out bad software quickly, but since we *are*
 Apple and love strategic lock-in just as much as MS, here's our own
 goofy version of the exact same thing that we're going to push
 instead."


 Seems everyone is fixating on semicolons, but seriously, am I the only=



 one who sees the elephant in the room? Automatic memory management!!!
 Where's Manu and his GC tirades when you need him? ;-)


It will be ARC. Same as Objective C.

But I don't like that the memory management is automatic. More likely th=
an  =

not, it will allocate things you don't want it to, or could avoid if you=
  =

had manual control. I'm skimming the book about this new language, and i=
t  =

certainly will be more D-like than Objective C, which is nice, but there=
  =

are some things that I really don't like. Significant whitespace is one =
of  =

them.

They have template constraints similar to D. It looks something like thi=
s:

func foo<T where T =3D=3D Int>(t: T)

I think everything after the where can be some condition, but I don't kn=
ow  =

how expressive that is. The examples aren't very telling.

I still haven't figured out whether generics are runtime-based or  =

compile-time based. But some form of generics will be very nice to have.=


-Steve
Jun 02 2014
parent Timon Gehr <timon.gehr gmx.ch> writes:
On 06/02/2014 11:15 PM, Steven Schveighoffer wrote:

 They have template constraints similar to D. It looks something like this:

 func foo<T where T == Int>(t: T)

 I think everything after the where can be some condition, but I don't
 know how expressive that is. The examples aren't very telling.
 ...


https://developer.apple.com/library/prerelease/ios/documentation/Swift/Conceptual/Swift_Programming_Language/GenericParametersAndArguments.html#//apple_ref/doc/uid/TP40014097-CH37-XID_774

You can have subtype and equality constraints on generic type parameter 
and their "associated types".


 I still haven't figured out whether generics are runtime-based or
 compile-time based.


It is actual parametric polymorphism and not a form of macro if that is 
what you mean. I.e. the declaration is type checked only once.


 But some form of generics will be very nice to have.
Jun 02 2014
prev sibling parent Timon Gehr <timon.gehr gmx.ch> writes:
On 06/02/2014 10:23 PM, Nick Sabalausky wrote:

 On 6/2/2014 3:49 PM, Steven Schveighoffer wrote:

 On Mon, 02 Jun 2014 15:45:28 -0400, Paulo Pinto <pjmlp progtools.org>
 wrote:

 More information now made available

 https://developer.apple.com/swift/


 "Memory is managed automatically, and you don’t even need to type
 semi-colons."

 ...



 it probably sums up a lot about the language.
 ...


Well, it's a sales pitch. I skipped right to the language reference, but 
there seemed nothing to be there that would support the statement

"Swift is the result of the latest research on programming languages,"

But more annoyingly,

"Syntax is tuned to make it easy to define your intent — for example, 
simple three-character keywords define a variable (var) or constant (let)."

i.e. Swift is another language that is confused about what 'variable' 
and 'constant' mean.


 The whole thing sounds like "We love how JS and Python allow mediocre
 programmers to churn out bad software quickly, but since we *are* Apple
 and love strategic lock-in just as much as MS, here's our own goofy
 version of the exact same thing that we're going to push instead."


It is typed.
Jun 02 2014
prev sibling next sibling parent reply "Paulo Pinto" <pjmlp progtools.org> writes:
On Monday, 2 June 2014 at 19:45:29 UTC, Paulo Pinto wrote:

 On Monday, 2 June 2014 at 19:19:27 UTC, Paulo Pinto wrote:

 Just thought it would be nice to give a heads up about Apple's 
 plans to replace Objective-C in the long run.

 The language was presented today at the WWDC Keynote, looks 
 like Ruby, uses ARC alongside the Objective-C runtime.

 http://live.arstechnica.com/apples-wwdc-2014-keynote/

 It also has a nice REPL experience, similar to Python's 
 worksheets in IPython.

 --
 Paulo


 More information now made available

 https://developer.apple.com/swift/


Manual now visible

https://developer.apple.com/library/prerelease/ios/documentation/Swift/Conceptual/Swift_Programming_Language/GuidedTour.html#//apple_ref/doc/uid/TP40014097-CH2
Jun 02 2014
parent reply =?UTF-8?B?Ik5vcmRsw7Z3Ig==?= <per.nordlow gmail.com> writes:
https://developer.apple.com/library/prerelease/ios/documentation/Swift/Conceptual/Swift_Programming_Language/GuidedTour.html#//apple_ref/doc/uid/TP40014097-CH2

Same mistake with syntatically ambiguous template syntax.
Jun 02 2014
next sibling parent reply "Brad Anderson" <eco gnuk.net> writes:
On Monday, 2 June 2014 at 20:07:00 UTC, Nordlöw wrote:

 https://developer.apple.com/library/prerelease/ios/documentation/Swift/Conceptual/Swift_Programming_Language/GuidedTour.html#//apple_ref/doc/uid/TP40014097-CH2

 Same mistake with syntatically ambiguous template syntax.


Maybe the deprecated that pesky less than operator.
Jun 02 2014
parent =?UTF-8?B?Ik5vcmRsw7Z3Ig==?= <per.nordlow gmail.com> writes:
 Maybe the deprecated that pesky less than operator.


Funny :)
Jun 02 2014
prev sibling parent reply "Paulo Pinto" <pjmlp progtools.org> writes:
On Monday, 2 June 2014 at 20:07:00 UTC, Nordlöw wrote:

 https://developer.apple.com/library/prerelease/ios/documentation/Swift/Conceptual/Swift_Programming_Language/GuidedTour.html#//apple_ref/doc/uid/TP40014097-CH2

 Same mistake with syntatically ambiguous template syntax.


Actually I find it better on my eyes, than D's one.



--
Paulo
Jun 02 2014
parent "H. S. Teoh via Digitalmars-d" <digitalmars-d puremagic.com> writes:
On Mon, Jun 02, 2014 at 08:37:30PM +0000, Paulo Pinto via Digitalmars-d wrote:

 On Monday, 2 June 2014 at 20:07:00 UTC, Nordlöw wrote:

https://developer.apple.com/library/prerelease/ios/documentation/Swift/Conceptual/Swift_Programming_Language/GuidedTour.html#//apple_ref/doc/uid/TP40014097-CH2

Same mistake with syntatically ambiguous template syntax.


 
 Actually I find it better on my eyes, than D's one.
 



[...]

Argh! I have also spent many years reading C++ template code... but I
still utterly hate using <> as template argument list delimiters. Not
only it makes my eyes bleed, it's also ambiguous and leads to lexers
that must parse before they can lex. Ugh!!

(Now that's not to say D's template syntax is perfect either... things
like func(A...)(B...) where A... and B... are long argument lists, are
also very taxing to read because when you first start scanning the
declaration, it's hard to tell whether the A... are compile-time
arguments or runtime-arguments. But nevertheless, I think D's syntax is
WAY saner than anything based on C++'s horrific <>'s.)


T

-- 
Democracy: The triumph of popularity over principle. -- C.Bond
Jun 02 2014
prev sibling next sibling parent "Meta" <jared771 gmail.com> writes:
On Monday, 2 June 2014 at 19:45:29 UTC, Paulo Pinto wrote:

 On Monday, 2 June 2014 at 19:19:27 UTC, Paulo Pinto wrote:

 Just thought it would be nice to give a heads up about Apple's 
 plans to replace Objective-C in the long run.

 The language was presented today at the WWDC Keynote, looks 
 like Ruby, uses ARC alongside the Objective-C runtime.

 http://live.arstechnica.com/apples-wwdc-2014-keynote/

 It also has a nice REPL experience, similar to Python's 
 worksheets in IPython.

 --
 Paulo


 More information now made available

 https://developer.apple.com/swift/


- "Closures unified with function pointers"
- "Tuples and multiple return values"

Sounds pretty neat, but I can't stand that horrid opening brace 
placement. It's something I really hate about Scala as well.

balloonConfigurator = { b in
     //...
}
Jun 02 2014
prev sibling parent reply Byron Heads <byron.heads gmail.com> writes:
On 2014-06-02 19:45:28 +0000, Paulo Pinto said:


 On Monday, 2 June 2014 at 19:19:27 UTC, Paulo Pinto wrote:

 Just thought it would be nice to give a heads up about Apple's plans to 
 replace Objective-C in the long run.
 
 The language was presented today at the WWDC Keynote, looks like Ruby, 
 uses ARC alongside the Objective-C runtime.
 
 http://live.arstechnica.com/apples-wwdc-2014-keynote/
 
 It also has a nice REPL experience, similar to Python's worksheets in IPython.
 
 --
 Paulo


 
 More information now made available
 
 https://developer.apple.com/swift/


"Use .. to make a range that omits its upper value, and use ... to make 
a range that includes both values."

That is going to be a source of a lot of bugs, so easy to type 3 when 
you ment 2
Jun 03 2014
next sibling parent "Chris Cain" <zshazz gmail.com> writes:
On Tuesday, 3 June 2014 at 13:18:38 UTC, Byron Heads wrote:

 "Use .. to make a range that omits its upper value, and use ... 
 to make a range that includes both values."

 That is going to be a source of a lot of bugs, so easy to type 
 3 when you ment 2


Agreed. But I think if the language made it differentiate better, 
having exclusive and inclusive versions could work...

inclusive: 0...8
exclusive: 0..<9

Personally, when I'm writing out pseudocode I almost always use 
"..<" because it's obvious and no one has ever wondered "What do 
you mean by that?" I've heard a few times from people that wanted 
to clarify whether I meant inclusive or exclusive by "0..9"
Jun 03 2014
prev sibling parent Jacob Carlborg <doob me.com> writes:
On 2014-06-03 15:18, Byron Heads wrote:


 "Use .. to make a range that omits its upper value, and use ... to make
 a range that includes both values."

 That is going to be a source of a lot of bugs, so easy to type 3 when
 you ment 2


Same as with Ruby ... but the other way around :)

-- 
/Jacob Carlborg
Jun 03 2014
prev sibling next sibling parent "Steven Schveighoffer" <schveiguy yahoo.com> writes:
On Mon, 02 Jun 2014 15:19:26 -0400, Paulo Pinto <pjmlp progtools.org>  
wrote:


 Just thought it would be nice to give a heads up about Apple's plans to  
 replace Objective-C in the long run.

 The language was presented today at the WWDC Keynote, looks like Ruby,  
 uses ARC alongside the Objective-C runtime.

 http://live.arstechnica.com/apples-wwdc-2014-keynote/

 It also has a nice REPL experience, similar to Python's worksheets in  
 IPython.


Uses same syntax for array literals as D. This is very nice, I hate how  
arrays are created in Objective C.

-Steve
Jun 02 2014
prev sibling next sibling parent reply "Brad Anderson" <eco gnuk.net> writes:
On Monday, 2 June 2014 at 19:19:27 UTC, Paulo Pinto wrote:

 Just thought it would be nice to give a heads up about Apple's 
 plans to replace Objective-C in the long run.

 The language was presented today at the WWDC Keynote, looks 
 like Ruby, uses ARC alongside the Objective-C runtime.

 http://live.arstechnica.com/apples-wwdc-2014-keynote/

 It also has a nice REPL experience, similar to Python's 
 worksheets in IPython.

 --
 Paulo


I like how the lambdas can omit the parameters then reference 
them by special $0, $1, etc (e.g., { $0 < $1 }). It reminds me of 
our string lambdas ("a < b") in brevity without the hacky feel 
those had. As much as I like the new lambda syntax I still miss 
how short string lambdas could be.

arr.sort!"a < b"();
arr.sort!((a, b) => a < b);

Maybe something like...

arr.sort!( => $0 < $1 )

...could be supported. Not a huge improvement but I like it 
anyway.
Jun 02 2014
next sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 6/2/2014 3:03 PM, Brad Anderson wrote:

 I like how the lambdas can omit the parameters then reference them by special
 $0, $1, etc (e.g., { $0 < $1 }).


We had something similar years ago, to support regexes, and people hated it so
I 
reverted it.
Jun 02 2014
next sibling parent "w0rp" <devw0rp gmail.com> writes:
On Tuesday, 3 June 2014 at 00:06:15 UTC, Walter Bright wrote:

 On 6/2/2014 3:03 PM, Brad Anderson wrote:

 I like how the lambdas can omit the parameters then reference 
 them by special
 $0, $1, etc (e.g., { $0 < $1 }).


 We had something similar years ago, to support regexes, and 
 people hated it so I reverted it.


It's a step down the slippery slope of things that made Scala not 
as good as it could have been.
Jun 02 2014
prev sibling parent "AsmMan" <lol.themask gmail.com> writes:
On Tuesday, 3 June 2014 at 00:06:15 UTC, Walter Bright wrote:

 On 6/2/2014 3:03 PM, Brad Anderson wrote:

 I like how the lambdas can omit the parameters then reference 
 them by special
 $0, $1, etc (e.g., { $0 < $1 }).


 We had something similar years ago, to support regexes, and 
 people hated it so I reverted it.


Well-done. It's really ugly. I hate it.
Jun 02 2014
prev sibling parent "Steven Schveighoffer" <schveiguy yahoo.com> writes:
On Mon, 02 Jun 2014 18:03:43 -0400, Brad Anderson <eco gnuk.net> wrote:


 On Monday, 2 June 2014 at 19:19:27 UTC, Paulo Pinto wrote:

 Just thought it would be nice to give a heads up about Apple's plans to  
 replace Objective-C in the long run.

 The language was presented today at the WWDC Keynote, looks like Ruby,  
 uses ARC alongside the Objective-C runtime.

 http://live.arstechnica.com/apples-wwdc-2014-keynote/

 It also has a nice REPL experience, similar to Python's worksheets in  
 IPython.

 --
 Paulo


 I like how the lambdas can omit the parameters then reference them by  
 special $0, $1, etc (e.g., { $0 < $1 }). It reminds me of our string  
 lambdas ("a < b") in brevity without the hacky feel those had. As much  
 as I like the new lambda syntax I still miss how short string lambdas  
 could be.

 arr.sort!"a < b"();
 arr.sort!((a, b) => a < b);

 Maybe something like...

 arr.sort!( => $0 < $1 )

 ...could be supported. Not a huge improvement but I like it anyway.


I think just $0 < $1 could infer the fact that it is a lambda, as this is  
not currently valid syntax.

I would like that too.

-Steve
Jun 03 2014
prev sibling next sibling parent reply "ponce" <contact gam3esfrommars.fr> writes:
On Monday, 2 June 2014 at 19:19:27 UTC, Paulo Pinto wrote:

 Just thought it would be nice to give a heads up about Apple's 
 plans to replace Objective-C in the long run.

 The language was presented today at the WWDC Keynote, looks 
 like Ruby, uses ARC alongside the Objective-C runtime.

 http://live.arstechnica.com/apples-wwdc-2014-keynote/

 It also has a nice REPL experience, similar to Python's 
 worksheets in IPython.

 --
 Paulo


My thoughts while browsing the site:
- function-leve type inference much like Rust
- no constness in the type-system (I like it)
- class are reference types, structs are values types, much like 

- runtime dispacthed OO interfaces called "protocols". Blend the 
difference between runtime or compile-time polymorphism. Classes, 
structs and enums can implement a protocol. Available as first 
class runtime values, so the protocol dispatch will be slow like 
in Golang.
- enumerations are much like Ocaml ADT, can be parameterized by a 
tuple of values, value types, recursive definitions
- worrying focus on properties.
- strange closure syntax
- optional chaining, another anti-feature in my eyes
- normal arithmetic operator throw a trap on integer overflow 
(!). This must be incredibly slow.
- looks like Array is a fat slice to a reference-counted array
- operator overloading is in, supercharged with custom operator, 
custom precedence (!?)
- builtin tuples syntax
- break with C integer promotion, like Rust.
- I haven't seen pointers
- convenience is a keyword!
Jun 02 2014
next sibling parent reply "ponce" <contact gam3esfrommars.fr> writes:
 My thoughts while browsing the site:
 - function-leve type inference much like Rust
 - no constness in the type-system (I like it)
 - class are reference types, structs are values types, much 

 - runtime dispacthed OO interfaces called "protocols". Blend 
 the difference between runtime or compile-time polymorphism. 
 Classes, structs and enums can implement a protocol. Available 
 as first class runtime values, so the protocol dispatch will be 
 slow like in Golang.
 - enumerations are much like Ocaml ADT, can be parameterized by 
 a tuple of values, value types, recursive definitions
 - worrying focus on properties.
 - strange closure syntax
 - optional chaining, another anti-feature in my eyes
 - normal arithmetic operator throw a trap on integer overflow 
 (!). This must be incredibly slow.
 - looks like Array is a fat slice to a reference-counted array
 - operator overloading is in, supercharged with custom 
 operator, custom precedence (!?)
 - builtin tuples syntax
 - break with C integer promotion, like Rust.
 - I haven't seen pointers
 - convenience is a keyword!


- no exceptions (!)
- unsigned integers; check
- type inference is "bidirectional by expression or statement"
- class have deterministic destructors, structs have no 
destructors; like D except reversed
- It seems the only RAII source is through RC and classes.
- no single root class
Jun 02 2014
next sibling parent reply "deadalnix" <deadalnix gmail.com> writes:
On Monday, 2 June 2014 at 22:53:10 UTC, ponce wrote:

 - no exceptions (!)


How do they do error handling ?


 - type inference is "bidirectional by expression or statement"


KAMOULOX ! (french people will understand)
Jun 02 2014
next sibling parent reply "ponce" <contact gam3esfrommars.fr> writes:
On Monday, 2 June 2014 at 23:01:56 UTC, deadalnix wrote:

 On Monday, 2 June 2014 at 22:53:10 UTC, ponce wrote:

 - no exceptions (!)


 How do they do error handling ?


I guess error codes, a proven technology!
The lack of exceptions put this language firmly in the 
"irrelevant" bracket.

Add that "goto" isn't here and the only way to release resources 
on error path is to use RC-managed classes, you can bet the 
cleanup lines will be numerous and frequently forgotten.
Jun 02 2014
parent reply "deadalnix" <deadalnix gmail.com> writes:
On Monday, 2 June 2014 at 23:12:15 UTC, ponce wrote:

 On Monday, 2 June 2014 at 23:01:56 UTC, deadalnix wrote:

 On Monday, 2 June 2014 at 22:53:10 UTC, ponce wrote:

 - no exceptions (!)


 How do they do error handling ?


 I guess error codes, a proven technology!


Well, for sure it is proven :D It is proven to never be checked !


 The lack of exceptions put this language firmly in the 
 "irrelevant" bracket.


I wouldn't do it that fast. I mean it is apple. You just had to
see the look in the eyes of peoples during the keynote. They were
listening to god itself. Apple could pull anything and would be
using it.

And quite frankly it can't be worse than Objective C, so people
will be using on iOS.
Jun 02 2014
parent reply "Chris" <wendlec tcd.ie> writes:
On Monday, 2 June 2014 at 23:54:27 UTC, deadalnix wrote:

 On Monday, 2 June 2014 at 23:12:15 UTC, ponce wrote:

 On Monday, 2 June 2014 at 23:01:56 UTC, deadalnix wrote:

 On Monday, 2 June 2014 at 22:53:10 UTC, ponce wrote:

 - no exceptions (!)


 How do they do error handling ?


 I guess error codes, a proven technology!


 Well, for sure it is proven :D It is proven to never be checked 
 !


 The lack of exceptions put this language firmly in the 
 "irrelevant" bracket.


 I wouldn't do it that fast. I mean it is apple. You just had to
 see the look in the eyes of peoples during the keynote. They 
 were
 listening to god itself. Apple could pull anything and would be
 using it.


Yep. I'm sure that all Apple fanboys & girls will hail it as _the 
ultimate_ super-hyper-mega-language of the century, ah, of the 
millenium. After all it was created by God, er, Apple. (Mind you, 
it was because of an apple that God evicted humans from paradaise 
:-)


 And quite frankly it can't be worse than Objective C, so people
 will be using on iOS.


Well, Objective C does its job, nothing special. It's not a great 
language but a reliable tool. I haven't used it for years now but 
I'm sure I would miss the powerful feartures of D, if I used it 
now.
Jun 03 2014
parent reply Nick Sabalausky <SeeWebsiteToContactMe semitwist.com> writes:
On 6/3/2014 5:03 AM, Chris wrote:

 After all it was created by God, er, Apple. (Mind you, it was
 because of an apple that God evicted humans from paradaise :-)


Heh heh :) Why has that never occurred to me before?

Side note: I've heard arguments that the biblical "apple" may have 
originally been a pomegranate. If so, then not surprising it would have 
been changed to an apple - pomegranates had kinda gotten lost from 
public awareness in certain cultures (like the US) until only fairly 
recently with all the renewed interest in healthy eating. (Not that 
apples aren't healthy, but poms are said to be *really* healthy, 
apparently.)
Jun 03 2014
next sibling parent "H. S. Teoh via Digitalmars-d" <digitalmars-d puremagic.com> writes:
On Tue, Jun 03, 2014 at 01:05:24PM -0400, Nick Sabalausky via Digitalmars-d
wrote:

 On 6/3/2014 5:03 AM, Chris wrote:

After all it was created by God, er, Apple. (Mind you, it was
because of an apple that God evicted humans from paradaise :-)


 
 Heh heh :) Why has that never occurred to me before?
 
 Side note: I've heard arguments that the biblical "apple" may have
 originally been a pomegranate. If so, then not surprising it would
 have been changed to an apple - pomegranates had kinda gotten lost
 from public awareness in certain cultures (like the US) until only
 fairly recently with all the renewed interest in healthy eating. (Not
 that apples aren't healthy, but poms are said to be *really* healthy,
 apparently.)


Note that NOWHERE in the original Hebrew Bible does it say that the
fruit was an apple or a pomegranate or anything like that. The
apple/pomegranate interpretation is entirely made up, probably by an
overly enthusiastic children's story author.


T

-- 
Shin: (n.) A device for finding furniture in the dark.
Jun 03 2014
prev sibling parent reply Jonathan M Davis via Digitalmars-d <digitalmars-d puremagic.com> writes:
On Tue, 03 Jun 2014 13:05:24 -0400
Nick Sabalausky via Digitalmars-d <digitalmars-d puremagic.com> wrote:


 On 6/3/2014 5:03 AM, Chris wrote:

 After all it was created by God, er, Apple. (Mind you, it was
 because of an apple that God evicted humans from paradaise :-)


 Heh heh :) Why has that never occurred to me before?

 Side note: I've heard arguments that the biblical "apple" may have
 originally been a pomegranate. If so, then not surprising it would
 have been changed to an apple - pomegranates had kinda gotten lost
 from public awareness in certain cultures (like the US) until only
 fairly recently with all the renewed interest in healthy eating. (Not
 that apples aren't healthy, but poms are said to be *really* healthy,
 apparently.)


Technically, all it's ever referred to is as "fruit" or the "forbidden fruit"
- and it's the fruit of one very specific tree which only existed in the
Garden of Eden. So, arguably associating it with any fruit currently in
existence is a bit of a misnomer. So, it shouldn't have any effect on your
fruit dietary choices. ;)

- Jonathan M Davis
Jun 03 2014
parent Nick Sabalausky <SeeWebsiteToContactMe semitwist.com> writes:
On 6/3/2014 1:34 PM, Jonathan M Davis via Digitalmars-d wrote:

 Technically, all it's ever referred to is as "fruit" or the "forbidden fruit"
 - and it's the fruit of one very specific tree which only existed in the
 Garden of Eden. So, arguably associating it with any fruit currently in
 existence is a bit of a misnomer. So, it shouldn't have any effect on your
 fruit dietary choices. ;)


Well, it wouldn't affect my diet anyway: I generally try to avoid eating 
*any* fruit (or other food) that's served by a serpent, or by any other 
non-humanoid that isn't a vending machine. :) I figure it's just the 
prudent thing to do. Yup.
Jun 03 2014
prev sibling next sibling parent reply "Messenger" <dont shoot.me> writes:
On Monday, 2 June 2014 at 23:01:56 UTC, deadalnix wrote:

 On Monday, 2 June 2014 at 22:53:10 UTC, ponce wrote:

 - no exceptions (!)


 How do they do error handling ?


segfault
Jun 02 2014
parent Walter Bright <newshound2 digitalmars.com> writes:
On 6/2/2014 4:13 PM, Messenger wrote:

 On Monday, 2 June 2014 at 23:01:56 UTC, deadalnix wrote:

 On Monday, 2 June 2014 at 22:53:10 UTC, ponce wrote:

 - no exceptions (!)


 How do they do error handling ?


 segfault


Best comment yet! ROFL
Jun 02 2014
prev sibling next sibling parent "Meta" <jared771 gmail.com> writes:
On Monday, 2 June 2014 at 23:01:56 UTC, deadalnix wrote:

 On Monday, 2 June 2014 at 22:53:10 UTC, ponce wrote:

 - no exceptions (!)


 How do they do error handling ?


 - type inference is "bidirectional by expression or statement"


 KAMOULOX ! (french people will understand)


It specifically says that the language has optional types, e.g., 
Maybe or Option. I don't know if they're a part of the ADT 

?.
Jun 02 2014
prev sibling next sibling parent reply "Chris Cain" <zshazz gmail.com> writes:
On Monday, 2 June 2014 at 23:01:56 UTC, deadalnix wrote:

 On Monday, 2 June 2014 at 22:53:10 UTC, ponce wrote:

 - no exceptions (!)


 How do they do error handling ?


I haven't read too much into Swift but languages with ADTs, 
pattern matching, and no exceptions can (and usually do) return 
using an ADT looking something like (pseudocode):

     adt Outcome(T) {
         Error(ErrorType e);
         Success(T result);
     }

and then for a "try catch" type block, you do things with switches

     switch(http.getResponse(someServer)) {
         case Success(r):
             // ... use r
         case Error(http.error.Http404(msg)):
             // handle the 404 error
         case Error(e):
             return Error(e); // Let the caller handle it
     }

Or some other similar construct. With macros you can easily write 
something that tries to get the outcome's success and if it 
can't, then it automagically returns the error for you, throwing 
the error to the calling function like you expect from 
exceptions. That said, if you're paying attention you'll see the 
similarity to checked exceptions...

So basically, those two features give you what is effectively 
exception handling, "nothrow", and so on. It's one of those 
really powerful language features with a lot of leverage that 
makes it easy to define constructs in the language instead of the 
compiler.
Jun 02 2014
parent reply "ponce" <contact gam3sfrommars.fr> writes:
On Tuesday, 3 June 2014 at 00:57:53 UTC, Chris Cain wrote:

 On Monday, 2 June 2014 at 23:01:56 UTC, deadalnix wrote:

 On Monday, 2 June 2014 at 22:53:10 UTC, ponce wrote:

 - no exceptions (!)


 How do they do error handling ?


 I haven't read too much into Swift but languages with ADTs, 
 pattern matching, and no exceptions can (and usually do) return 
 using an ADT looking something like (pseudocode):

     adt Outcome(T) {
         Error(ErrorType e);
         Success(T result);
     }

 and then for a "try catch" type block, you do things with 
 switches

     switch(http.getResponse(someServer)) {
         case Success(r):
             // ... use r
         case Error(http.error.Http404(msg)):
             // handle the 404 error
         case Error(e):
             return Error(e); // Let the caller handle it
     }

 Or some other similar construct. With macros you can easily 
 write something that tries to get the outcome's success and if 
 it can't, then it automagically returns the error for you, 
 throwing the error to the calling function like you expect from 
 exceptions. That said, if you're paying attention you'll see 
 the similarity to checked exceptions...

 So basically, those two features give you what is effectively 
 exception handling, "nothrow", and so on. It's one of those 
 really powerful language features with a lot of leverage that 
 makes it easy to define constructs in the language instead of 
 the compiler.


Ocaml and Haskell also have ADT and exhaustive matching.
Yet Ocaml provides exceptions. Haskell provide the Exception 
monad to avoid littering the code with error-checking.
Of course ADT are great and all but if error checking is verbose 
it won't encourage people to check for errors.
Jun 03 2014
parent "Chris Cain" <zshazz gmail.com> writes:
On Tuesday, 3 June 2014 at 08:33:14 UTC, ponce wrote:

 On Tuesday, 3 June 2014 at 00:57:53 UTC, Chris Cain wrote:

 On Monday, 2 June 2014 at 23:01:56 UTC, deadalnix wrote:

 On Monday, 2 June 2014 at 22:53:10 UTC, ponce wrote:

 - no exceptions (!)


 How do they do error handling ?


 I haven't read too much into Swift but languages with ADTs, 
 pattern matching, and no exceptions can (and usually do) 
 return using an ADT


 Ocaml and Haskell also have ADT and exhaustive matching.
 Yet Ocaml provides exceptions. Haskell provide the Exception 
 monad to avoid littering the code with error-checking.
 Of course ADT are great and all but if error checking is 
 verbose it won't encourage people to check for errors.


Of course not all languages with ADT and pattern matching have no 
exceptions. But the ones that don't have exceptions get by using 
the process I described. And verbosity is usually taken care of 
(somewhat) well with macros if the language supports them.

But yes, like I stated, it usually feels similar to a system with 
checked exceptions, which has the natural problem of "not 
encouraging people to check for errors." So I'm not going to 
suggest it's the perfect way, but it is quite impressive how the 
features added together can accomplish so much.
Jun 03 2014
prev sibling next sibling parent "Paulo Pinto" <pjmlp progtools.org> writes:
On Monday, 2 June 2014 at 23:01:56 UTC, deadalnix wrote:

 On Monday, 2 June 2014 at 22:53:10 UTC, ponce wrote:

 - no exceptions (!)


 How do they do error handling ?


With optional types like in most FP languages.

The language needs to keep compatibility with the Objective-C
runtime, and Objective-C exceptions never worked across all
scenarios. Just check the Objective-C and Cocoa documentation
about possible caveats.

--
Paulo
Jun 02 2014
prev sibling parent reply Jacob Carlborg <doob me.com> writes:
On 2014-06-03 01:01, deadalnix wrote:


 How do they do error handling ?


Objective-C does support exceptions, but libraries like Cocoa avoids 
throwing exceptions and leave those to the user (developer). Instead it 
usually returns a bool to indicate success or failure and then provides 
an NSError instance via an out parameter.

-- 
/Jacob Carlborg
Jun 03 2014
parent "w0rp" <devw0rp gmail.com> writes:
On Tuesday, 3 June 2014 at 20:26:52 UTC, Jacob Carlborg wrote:

 On 2014-06-03 01:01, deadalnix wrote:


 How do they do error handling ?


 Objective-C does support exceptions, but libraries like Cocoa 
 avoids throwing exceptions and leave those to the user 
 (developer). Instead it usually returns a bool to indicate 
 success or failure and then provides an NSError instance via an 
 out parameter.


Writing messages which set errors like that was always weird.

// The pointer needs to use __autoreleasing so it captures the 
correct
// reference semantics.
- (BOOL) doSomethingWithError:(NSError* __autoreleasing * error) {
     // You must set to nil, as Objective C won't initialise to 
nil implicitly.
     NSError* otherError = nil;

     // Pass pointer to object in a C-like way.
     [foo doSomethingElseWithError:&otherError];

     // We have to check that the out param is not nil.
     if (error && otherError) {
         *error = otherError;

         // We return a boolean flag for those people who
         // don't capture the error itself but want a convenient
         // if([foo doSomethingWithError:nil] == NO)
         return NO;
     }

     return YES;
}

What does this look like if you use exceptions instead in a saner 
language?

void doSomething() {
     doSomethingElse();
}

Oh! Right!
Jun 03 2014
prev sibling parent reply "Remo" <remo4d gmail.com> writes:
On Monday, 2 June 2014 at 22:53:10 UTC, ponce wrote:

 My thoughts while browsing the site:
 - function-leve type inference much like Rust
 - no constness in the type-system (I like it)
 - class are reference types, structs are values types, much 

 - runtime dispacthed OO interfaces called "protocols". Blend 
 the difference between runtime or compile-time polymorphism. 
 Classes, structs and enums can implement a protocol. Available 
 as first class runtime values, so the protocol dispatch will 
 be slow like in Golang.
 - enumerations are much like Ocaml ADT, can be parameterized 
 by a tuple of values, value types, recursive definitions
 - worrying focus on properties.
 - strange closure syntax
 - optional chaining, another anti-feature in my eyes
 - normal arithmetic operator throw a trap on integer overflow 
 (!). This must be incredibly slow.
 - looks like Array is a fat slice to a reference-counted array
 - operator overloading is in, supercharged with custom 
 operator, custom precedence (!?)
 - builtin tuples syntax
 - break with C integer promotion, like Rust.
 - I haven't seen pointers
 - convenience is a keyword!


 - no exceptions (!)
 - unsigned integers; check
 - type inference is "bidirectional by expression or statement"
 - class have deterministic destructors, structs have no 
 destructors; like D except reversed
 - It seems the only RAII source is through RC and classes.
 - no single root class


No exceptions (!) so this is at least something that this
language do better as C++ and D  :D
Not everyone think that exceptions are necessary or there is no
other way to handle errors.

But if there is no RAII and only automatic memory management then
it is very bad.
Jun 03 2014
parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 6/3/2014 2:44 PM, Remo wrote:

 No exceptions (!) so this is at least something that this
 language do better as C++ and D  :D
 Not everyone think that exceptions are necessary or there is no
 other way to handle errors.


Exceptions make ARC expensive, so this may be a reasonable decision for Swift.

Exceptions and GC go together like chocolate and coffee :-)
Jun 04 2014
next sibling parent reply Russel Winder via Digitalmars-d <digitalmars-d puremagic.com> writes:
On Wed, 2014-06-04 at 14:21 -0700, Walter Bright via Digitalmars-d
wrote:

 On 6/3/2014 2:44 PM, Remo wrote:

 No exceptions (!) so this is at least something that this
 language do better as C++ and D  :D
 Not everyone think that exceptions are necessary or there is no
 other way to handle errors.


 
 Exceptions make ARC expensive, so this may be a reasonable decision for Swift.
 
 Exceptions and GC go together like chocolate and coffee :-)


I think Pike, Cox, et al. disagree; for them exceptions are only a
termination mechanism and return codes are the way of communicating. If
Swift has no exceptions, then Apple must be following the Go model
rather than the D, Python, (C++ ?), etc. one.

I am still trying to work out what Rust conditions really are: they
language of exceptions is used but there is no stack unwinding.

-- 
Russel.
=============================================================================
Dr Russel Winder      t: +44 20 7585 2200   voip: sip:russel.winder ekiga.net
41 Buckmaster Road    m: +44 7770 465 077   xmpp: russel winder.org.uk
London SW11 1EN, UK   w: www.russel.org.uk  skype: russel_winder
Jun 04 2014
next sibling parent reply "deadalnix" <deadalnix gmail.com> writes:
On Thursday, 5 June 2014 at 04:35:18 UTC, Russel Winder via 
Digitalmars-d wrote:

 I am still trying to work out what Rust conditions really are: 
 they
 language of exceptions is used but there is no stack unwinding.


You may want to look at LISP. This mechanism is not new to Rust 
(abeit, it has its specificities, but the idea is the same). It 
allow the caller to plug some code where the error handling take 
place. It it doesn't, then an exception is thrown.

I proposed conditions for D a while ago, but didn't got much 
traction :(
Jun 04 2014
parent "deadalnix" <deadalnix gmail.com> writes:
On Thursday, 5 June 2014 at 05:49:17 UTC, deadalnix wrote:

 On Thursday, 5 June 2014 at 04:35:18 UTC, Russel Winder via 
 Digitalmars-d wrote:

 I am still trying to work out what Rust conditions really are: 
 they
 language of exceptions is used but there is no stack unwinding.


 You may want to look at LISP. This mechanism is not new to Rust 
 (abeit, it has its specificities, but the idea is the same). It 
 allow the caller to plug some code where the error handling 
 take place. It it doesn't, then an exception is thrown.

 I proposed conditions for D a while ago, but didn't got much 
 traction :(


http://web.mit.edu/rust-lang_v0.8/doc/tutorial-conditions.html
Jun 04 2014
prev sibling parent reply "ponce" <contact gam3sfrommars.fr> writes:
On Thursday, 5 June 2014 at 04:35:18 UTC, Russel Winder via 
Digitalmars-d wrote:

 I think Pike, Cox, et al. disagree; for them exceptions are 
 only a
 termination mechanism and return codes are the way of 
 communicating. If
 Swift has no exceptions, then Apple must be following the Go 
 model
 rather than the D, Python, (C++ ?), etc. one.



exceptions are for recoverable errors and crashing is for 
unrecoverable ones (I lost the link to the reference).
Jun 05 2014
parent reply Russel Winder via Digitalmars-d <digitalmars-d puremagic.com> writes:
On Thu, 2014-06-05 at 07:13 +0000, ponce via Digitalmars-d wrote:

 On Thursday, 5 June 2014 at 04:35:18 UTC, Russel Winder via 
 Digitalmars-d wrote:

 I think Pike, Cox, et al. disagree; for them exceptions are 
 only a
 termination mechanism and return codes are the way of 
 communicating. If
 Swift has no exceptions, then Apple must be following the Go 
 model
 rather than the D, Python, (C++ ?), etc. one.


 

 exceptions are for recoverable errors and crashing is for 
 unrecoverable ones (I lost the link to the reference).


This is very much the Java model: exceptions are for exceptional events
that can be handled or not. 

In Python of course exceptions are just control flow.

-- 
Russel.
=============================================================================
Dr Russel Winder      t: +44 20 7585 2200   voip: sip:russel.winder ekiga.net
41 Buckmaster Road    m: +44 7770 465 077   xmpp: russel winder.org.uk
London SW11 1EN, UK   w: www.russel.org.uk  skype: russel_winder
Jun 05 2014
parent Jacob Carlborg <doob me.com> writes:
On 2014-06-05 11:04, Russel Winder via Digitalmars-d wrote:


 This is very much the Java model: exceptions are for exceptional events
 that can be handled or not.

 In Python of course exceptions are just control flow.


Ruby has both "raise", for exceptions, and "throw", for control flow. 
But I suspect they're both implemented exactly the same.

-- 
/Jacob Carlborg
Jun 05 2014
prev sibling parent reply Jacob Carlborg <doob me.com> writes:
On 2014-06-04 23:21, Walter Bright wrote:

 On 6/3/2014 2:44 PM, Remo wrote:

 No exceptions (!) so this is at least something that this
 language do better as C++ and D  :D
 Not everyone think that exceptions are necessary or there is no
 other way to handle errors.


 Exceptions make ARC expensive, so this may be a reasonable decision for
 Swift.


I'm wondering how they'll handle exceptions thrown from Objective-C code 
which Swift calls.

-- 
/Jacob Carlborg
Jun 05 2014
parent reply "Remo" <remo4d gmail.com> writes:
On Thursday, 5 June 2014 at 09:55:21 UTC, Jacob Carlborg wrote:

 On 2014-06-04 23:21, Walter Bright wrote:

 On 6/3/2014 2:44 PM, Remo wrote:

 No exceptions (!) so this is at least something that this
 language do better as C++ and D  :D
 Not everyone think that exceptions are necessary or there is 
 no
 other way to handle errors.


 Exceptions make ARC expensive, so this may be a reasonable 
 decision for
 Swift.


 I'm wondering how they'll handle exceptions thrown from 
 Objective-C code which Swift calls.


Exceptions make a lot of other thing expensive and complicated.
IMHO Exceptions should only be used in really really exceptional 
cases and not all the way and for control flow.

Fortunately it is not really necessary to use Exceptions in C++.
A great example for this is LLVM and Clang code base.

I hope this is also possible to do this in D too.
Any way it would be better if D Language would better support 
alternative error handling system.
Jun 05 2014
parent Jacob Carlborg <doob me.com> writes:
On 2014-06-05 19:14, Remo wrote:


 Exceptions make a lot of other thing expensive and complicated.
 IMHO Exceptions should only be used in really really exceptional cases
 and not all the way and for control flow.

 Fortunately it is not really necessary to use Exceptions in C++.
 A great example for this is LLVM and Clang code base.


Even if you don't have to use exceptions, the language (Objective-C) 
does support them and someone will use them.

-- 
/Jacob Carlborg
Jun 05 2014
prev sibling next sibling parent "bearophile" <bearophileHUGS lycos.com> writes:
ponce:


 - normal arithmetic operator throw a trap on integer overflow 
 (!). This must be incredibly slow.


My experience in ObjectPascal tells me that this limited loss of 
performance is quite acceptable when you debug the code or in 
routines that don't need the max performance. So it's similar to 
D array bound checks. In some functions (like the  safe ones in 
D) you can even decide to keep it on. So I like checked 
arithmetic by default if there are ways to disable suck checks in 
specific functions/parts.


The good Graydon (one of the main designers of Rust) has written 
some quick notes on Swift:
http://graydon2.dreamwidth.org/5785.html

Currently Reddit-Programming is buzzing a lot about Swift.

Bye,
bearophile
Jun 03 2014
prev sibling parent "renoX" <renozyx gmail.com> writes:
On Monday, 2 June 2014 at 22:11:15 UTC, ponce wrote:
[cut]

 - normal arithmetic operator throw a trap on integer overflow 
 (!). This must be incredibly slow.


Well, Apple make their own CPU, so maybe they plan to add 'trap 
on integer overflow' operation to the CPU?

The most difficult part is finding where to put the 'trap on 
overflow' bit in the ISA, the implementation is nearly free..

renoX
Jun 03 2014
prev sibling next sibling parent reply "Dejan Lekic" <dejan.lekic gmail.com> writes:
On Monday, 2 June 2014 at 19:19:27 UTC, Paulo Pinto wrote:

 Just thought it would be nice to give a heads up about Apple's 
 plans to replace Objective-C in the long run.

 The language was presented today at the WWDC Keynote, looks 
 like Ruby, uses ARC alongside the Objective-C runtime.

 http://live.arstechnica.com/apples-wwdc-2014-keynote/

 It also has a nice REPL experience, similar to Python's 
 worksheets in IPython.

 --
 Paulo


"Thank God!!" I told my colleagues today when they told me about 
it. Swift is like 10x better langauge than that abomination 
called "Objective-C".
Jun 03 2014
next sibling parent "Paulo Pinto" <pjmlp progtools.org> writes:
On Tuesday, 3 June 2014 at 11:10:43 UTC, Dejan Lekic wrote:

 On Monday, 2 June 2014 at 19:19:27 UTC, Paulo Pinto wrote:

 Just thought it would be nice to give a heads up about Apple's 
 plans to replace Objective-C in the long run.

 The language was presented today at the WWDC Keynote, looks 
 like Ruby, uses ARC alongside the Objective-C runtime.

 http://live.arstechnica.com/apples-wwdc-2014-keynote/

 It also has a nice REPL experience, similar to Python's 
 worksheets in IPython.

 --
 Paulo


 "Thank God!!" I told my colleagues today when they told me 
 about it. Swift is like 10x better langauge than that 
 abomination called "Objective-C".


I kind of liked it back in 1999, when I had to port a Particle 
Engine from Objective-C/NeXT to C++/Windows.

However after so many languages in my toolbox, I would have to 
agree to the language's many warts.

--
Paulo
Jun 03 2014
prev sibling parent Nick Sabalausky <SeeWebsiteToContactMe semitwist.com> writes:
On 6/3/2014 7:10 AM, Dejan Lekic wrote:

 "Thank God!!" I told my colleagues today when they told me about it.
 Swift is like 10x better langauge than that abomination called
 "Objective-C".


You know, my first impression of Swift was "ugh, a 'me too' 
JS/Python-like language...", but I admit, the algebraic types, ARC and 
generics have my attention now. It's no D, but how many languages have 
even half-way decent generics, let alone that plus algebraics?

My only opinion of ObjC is "I've never quite been able to understand 
it". So Swift does, at the very least, seem like it may be a notable 
improvement.
Jun 03 2014
prev sibling next sibling parent reply "Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= writes:
On Monday, 2 June 2014 at 19:19:27 UTC, Paulo Pinto wrote:

 Just thought it would be nice to give a heads up about Apple's 
 plans to replace Objective-C in the long run.


Thanks for sharing, Swift looks good on the surface! Remains to 
see how well the dev environment is, but I guess this will kill a 
lot of the scripting platforms on iOS.

I look forward to do some iOS apps now, at least if it interops 
well with C++.

(Does it?)

Ola.
Jun 03 2014
parent reply Paulo Pinto <pjmlp progtools.org> writes:
Am 03.06.2014 16:34, schrieb "Ola Fosheim Grøstad" 
<ola.fosheim.grostad+dlang gmail.com>":

 On Monday, 2 June 2014 at 19:19:27 UTC, Paulo Pinto wrote:

 Just thought it would be nice to give a heads up about Apple's plans
 to replace Objective-C in the long run.


 Thanks for sharing, Swift looks good on the surface! Remains to see how
 well the dev environment is, but I guess this will kill a lot of the
 scripting platforms on iOS.

 I look forward to do some iOS apps now, at least if it interops well
 with C++.

 (Does it?)

 Ola.


You need to provide an Objective-C or C wrapper.

https://developer.apple.com/library/prerelease/ios/documentation/Swift/Conceptual/BuildingCocoaApps/index.html#//apple_ref/doc/uid/TP40014216

--
Paulo
Jun 03 2014
parent Jacob Carlborg <doob me.com> writes:
On 2014-06-03 17:27, Paulo Pinto wrote:


 You need to provide an Objective-C or C wrapper.


Or a D wrapper ;)

-- 
/Jacob Carlborg
Jun 03 2014
prev sibling parent reply "Brad Anderson" <eco gnuk.net> writes:
On Monday, 2 June 2014 at 19:19:27 UTC, Paulo Pinto wrote:

 Just thought it would be nice to give a heads up about Apple's 
 plans to replace Objective-C in the long run.

 The language was presented today at the WWDC Keynote, looks 
 like Ruby, uses ARC alongside the Objective-C runtime.

 http://live.arstechnica.com/apples-wwdc-2014-keynote/

 It also has a nice REPL experience, similar to Python's 
 worksheets in IPython.

 --
 Paulo


It appears they still have aways to go with the ARC
implementation: http://www.splasmata.com/?p=2798

HN discussion: http://www.splasmata.com/?p=2798

It's going to be very interesting to see how good they can get it
though. As far as I know, Apple has the most experience with ARC
and they certainly have the brainpower to push it to its limits.
Jun 04 2014
parent reply "Brad Anderson" <eco gnuk.net> writes:
On Thursday, 5 June 2014 at 03:12:05 UTC, Brad Anderson wrote:

 HN discussion: http://www.splasmata.com/?p=2798


That should be https://news.ycombinator.com/item?id=7849213
Jun 04 2014
next sibling parent "Kagamin" <spam here.lot> writes:
On Thursday, 5 June 2014 at 03:15:53 UTC, Brad Anderson wrote:

 On Thursday, 5 June 2014 at 03:12:05 UTC, Brad Anderson wrote:

 HN discussion: http://www.splasmata.com/?p=2798


 That should be https://news.ycombinator.com/item?id=7849213



 Turns out, at least 82.9% of it was just swift_retain / 
 swift_release (ref counting).


Probably interlocked arithmetic.
Jun 04 2014
prev sibling parent "Kagamin" <spam here.lot> writes:
On Thursday, 5 June 2014 at 03:15:53 UTC, Brad Anderson wrote:

 On Thursday, 5 June 2014 at 03:12:05 UTC, Brad Anderson wrote:

 HN discussion: http://www.splasmata.com/?p=2798


 That should be https://news.ycombinator.com/item?id=7849213


Also they said they don't use ARC in objc for performance, so 
it's not that fast, I suppose.
Jun 04 2014