Apple publiceert broncode van Swift-programmeertaal onder opensourcelicentie

Apple heeft donderdag de programmeertaal Swift na eerdere beloftes open-source gemaakt. Daarmee nodigt Apple de community uit om Swift 2 beter te maken door bij te dragen aan de ontwikkeling van de taal.

De Swift-site zelf geeft aan dat 'kleine, incrementele veranderingen' de voorkeur hebben. Apple beloofde in juni dit jaar al dat het de programmeertaal open-source zou maken zodat ook andere fabrikanten de taal kunnen adopteren.

De software is vrijgegeven onder de Apache-licentie en is beschikbaar voor OS X- en iOS-ontwikkelaars. De taal kan gebruikt worden om desktopapplicaties mee te ontwikkelen, maar ook iOS-applicaties. Er zijn ook Linux-binaries en de code kan op elk platform gecompileerd worden. Er is ook een Git-repository.

Reacties (62)

[BikkelZ]

Ik werk nu een half jaar exclusief in Swift, al iets langer gedeeltelijk. Swift 1.x was een mooie belofte maar in de praktijk afschuwelijk om mee te werken. Iedere update aan Xcode veranderde fundamentele zaken aan Swift waardoor je hele codebase herschreven moest worden, de tooling was extreem buggy en veel dingen waren nog zéér omslachtig of zo goed als onmogelijk (C interpo bijvoorbeeld).

Vanaf de Xcode 7 betas met Swift 2 gelijk overgeschakeld en nooit meer omgekeken. Swift is zo'n ongelooflijk veilige taal om mee te werken vergeleken met Objective-C dat ik eigenlijk nooit meer null-pointer achtige errors heb. Ook als je eens vergeet om een outlet te connecten dan werkt iets misschien niet* maar je applicatie blijft doordraaien. Een app die crasht is vele malen erger dan een app waarbij een bepaald knopje niet reageert of geen spinner getoond wordt terwijl er data verstuurd wordt.

Het systeem met wrapped (nullable) / unwrapped (non-nullable) values werkt enorm goed en je wordt ook gedwongen door de compiler om na te denken over wat je met wrapped variabelen doet. Ik ben nu inmiddels zo ver dat voor mij forced unwrapping (met variable!.property of variable as! SomeClass) simpelweg gelijk staat aan een code smell en *altijd* gerefactord wordt naar een guard statement of ik blijf optional (?) gebruiken.

Ook is Swift wat krachtiger en expressiever dan Objective-C, collecties en arrays zijn heel makkelijk te bewerken en enums zijn echt fantastisch qua flexibiliteit. Je raakt een groot deel van je boiler plate code kwijt maar je blijft natuurlijk wel vrij verbose code schrijven op het moment dat je met Cocoa (Touch) en andere Objective-C stijl libraries werkt. Maar je kunt bij Cartography bijvoorbeeld al zien dat er een hele korte maar wel krachtige custom syntax mogelijk is net zoals je in C# bijvoorbeeld kunt. Ik ben zelf ook met een library bezig die op een zeer expressieve manier je met een korte en leesbare syntax veel laat doen.

Nadeel op dit moment is nog steeds de tooling. Het is niet te vergelijken met Xcode 6 maar om de zoveel tijd raak je je code completion even kwijt, of klapt hij in een endless loop als je iets invoert waar hij van in de war raakt. Bepaalde delen van refactoring werken nog niet, en last but not least compiler duurt tot vijf keer langer dan bij Objective-C. Natuurlijk valt er ook gewoon meer te checken compile time in Swift maar desalniettemin is daar echt nog een hoop winst te halen.

[BugBoy]

Ik ben eigenlijk wel eens benieuwd of er iemand is die veel ervaring heeft met zowel Swift als C# en die wat voor en nadelen naast elkaar kan zetten. Die laatste vind ik een vrij elegante taal en ik heb eigenlijk nooit begrepen waarom Apple zelf weer een taal heeft bedacht in plaats van iets van de plank te trekken.

[BikkelZ]

Ik doe heel veel in C# ook. C# was voorheen mijn favoriete taal, maar ik loop al een tijdje om non-nullable references te zeuren en het is ook een van de meest favoriete changes van andere users maar volgens de ontwikkelaars (in een podcast die ik niet meer kan vinden) wordt het erg lastig om dat nog toe te voegen. ReSharper ondersteunt het een beetje met annotaties.

Qua expressiviteit lijken ze wel sterk op elkaar. Weliswaar is flapMap, filter en bijvoorbeeld reduce wel wat anders dan LINQ maar het lijkt heel sterk op elkaar als je de cosmetische eigenschappen even negeert. Swift heeft buiten var ook let wat een immutable variant is (NSArray vs NSMutableArray) en performance voordelen heeft.

Veel nieuwe features in C# zijn allerlei shorthands zoals object?.something?.maybe?, Swift heeft het allemaal al. Getters / setters met default values, willSet en didSet (zeer handig voor outlets waar je nog even wat aan wil toevoegen, bijvoorbeeld een UITableView met automatische rijhoogte).

C# werkt wat meer old school met puntkomma's aan het einde van iedere regel, gebruikt wat meer accolades en haakjes. Swift heeft een guard statement wat specifiek gericht is op het checken van parameters, vaak heb ik een guard / let / where / else statement van een aantal regels voordat ik iets doe, C# heeft geen specifieke check logica.

C# heeft attributes en Swift heeft ze niet. Dat is echt een groot gemis. Enums zijn enorm sterk onder Swift, ze kunnen functies hebben en allerlei onderliggende datatypes.

Swift werkt met ARC en C# met garbage collection. Afhankelijk van het scenario is meestal ARC sneller en voorspelbaarder.

Initializers zijn strikter onder Swift dan onder C#. Als je unwrapped values wil in je class / struct dan moet je alles opzetten in je init method.

Ik ben nog wel wat dingen vergeten waarschijnlijk....

[MSalters]

"old school met puntkomma's aan het einde van iedere regel" - grappig dat je dat aanhaalt. De ontwikkeling van programmeertalen is nog steeds trial and error en geen wetenschap, maar precies die puntkomma's zijn wél goed onderzocht. Het exacte karakter maakt natuurlijk niet uit, maar statement terminators zijn bewezen effectief in het voorkomen van fouten.

[BikkelZ]

Ben ik het niet zo mee eens. Ik mis ze in Python en Swift totaal niet. Zeker in Swift ben ik nog nooit tegen een probleem aangelopen wat daar aan gerelateerd was. Ik denk dat het het werk van de compiler wat makkelijker maakt, maar aan de andere kant snapt Visual Studio of ReSharper het meestal zélf al wel dat je een ; vergeten bent en waar die hoorde te staan.

[MSalters]

Nee, de compiler maakt het geen bal uit. Het gaat echt om het aantal fouten wat professionele programmeurs maken. Dat is echt gemeten.

[BikkelZ]

Geef me maar een linkje dan kan ik er ook wat zinnigs over zeggen. Bij geïnterpreteerde talen deal ik liever met Python dan met JavaScript, tussen C# en Swift merk ik geen verschil in de dagelijkse praktijk behalve de vergeten ; hier en daar waardoor C# niet compiled.

[BoringDay]

Swift en C# lijken wel wat op elkaar qua syntax.
http://swiftcomparsion.qiniudn.com

Maar dat is puur syntax, veel interessanter is wat je met de IDE kan,geleverde libraries, commandline tools/compiler.

[Reactie gewijzigd door BoringDay op 23 juli 2024 03:11]

[AB-Testing]

In jouw voorbeeld vrij logisch, C# is .net en dus enkel op Windows beschikbaar. Object C is niet echt met C# te vergelijken.

[geertdo]

Enkel op Windows? Nope.
CoreClr draai je op Windows, Linux en Osx.
https://github.com/dotnet/coreclr
Allemaal Open Source.

[Jackax]

En je hebt natuurlijk nog het Mono framework: http://www.mono-project.com/. Ook open source en bestond al een poosje langer dan CoreClr.

[BoringDay]

" forced unwrapping (met variable!.property of variable as! SomeClass) "
Dat is gewoon typecasting kon ook al met objective-C de notatie is nu alleen wat netter.

Ik mis nog in Xcode refactoring en header2doc, handige hulpmiddelen.
Helaas werkt self sizing cells ook niet zoals vermeld in de WWDC werd vermeld (best wel irritant).

Wat ook nog veel problemen oplevert is de Xcode server voor continious intergration (in veel gevallen certificaten wat nog niet lekker gaat) maar vooral UI testen dat mogen ze wel eens op orde maken. Het idee is prachtig maar niet echt werkbaar in de praktijk (nog niet reliable genoeg).

Verder een prachtige taal.

[BikkelZ]

Dat is gewoon typecasting kon ook al met objective-C de notatie is nu alleen wat netter.

Nope. Nope. Nopenopenopenope.

Objective-C references zijn altijd nillable. Het enige wat je sinds Xcode 7 hebt zijn annotations waarmee je kunt aangeven dat een bepaalde functie nooit een nil reference mag ontvangen en dat is met name om Swift met Objective-C code samen te laten werken, anders zijn alle parameters en return values in een functie optioneel.

In Swift is een unwrapped variabele *nooit* nil en moet je altijd iéts doen met een variabele die wrapped is voordat je hem kunt gebruiken:

- object?.doSomething() // I don't care if it's not there, but if it's not nil call the method
- object!.doSomething() // I want this to crash if it's not there (don't use this)
- guard object = object else // I make sure ("guard") that it's an unwrapped value, if it's nil I return/continue/break

Bij Objective-C kan alles in principe nil zijn.

Helaas werkt self sizing cells ook niet zoals vermeld in de WWDC werd vermeld (best wel irritant).

Het werkt wel maar je moet eerst met een volle maan 's nachts een pentagram tekenen met benzine, aansteken en jezelf naakt insmeren met kippenbloed om het voor elkaar te krijgen. Het gekke is dat nu het me één keer gelukt is ik het negen van de tien keer ook wel voor elkaar krijg maar het is vrij complex en je moet echt even simpel beginnen, niet gelijk met propvolle cellen.

[BoringDay]

Wat je meld dat klopt maar ik doelde meer op het downcast gedeelte
iets als: object as! String

"is dat nu het me één keer gelukt is ik het negen van de tien keer ook wel voor elkaar krijg"
Mij lukte het juist voorheen wel maar nu niet meer wanneer je een in de detailed label text gaat wordwrappen en numberOflines op 0 zet. Dan krijg je soort van spaghetti text.

[BikkelZ]

Text size heeft prioriteit 750 standaard. Dus als je ergens anders een hogere prioriteit instelt dan overruled hij dat.

[BoringDay]

Dat snap ik maar daar ligt het probleem niet.

[BikkelZ]

Stuur me anders een PB'tje of open een topic op GoT?

[runelaenen]

Nu nog iemand die een compiler schrijft om het ook naar Windows/Linux (misschien zelfs Android) te compilen, en dan zou ik écht blij zijn
Of een manier om apps te maken zonder een mac-toestel te hebben

[Reactie gewijzigd door runelaenen op 23 juli 2024 03:11]

[WhizzKid-Eddy]

Of je bouwt gewoon een hackintosh...

[SBTweaker]

Kan je nog geen iphone apps draaien. wat hij bedoeld is dat je in xcode (swift) ontwikkeld voor android, zodat je je app niet hoeft te porten naar android en visa versa.

[z1rconium]

er is een proof of concept dat het mogelijk is (naar android)

[rwvdw]

Misschien heb je hier wat aan: http://www.elementscompiler.com/elements/default.aspx

[johnkeates]

https://github.com/apple/swift-llvm

Edit: voor de mensen die de link niet snappen: dit is de llvm code voor Swift zodat je het kan compileren. LLVM kan je ook op Windows draaien, en er zijn ook Windows-specifieke toevoegingen gemaakt om het beter te laten integreren.

[Reactie gewijzigd door johnkeates op 23 juli 2024 03:11]

[BoringDay]

LLVM is de compiler, deze komt er ook voor linux.
Ik denk alleen niet dat je Mac apps moet maken onder windows, immers moet je goed kunnen testen.

[Exirion]

Voor een paar honderd euro heb je een Mac Mini die je zo ergens wegstopt. Dat kan de drempel niet echt zijn. Als je serieus wilt testen, wat inherent is aan je ontwikkelwerk, moet je toch een echte Mac hebben.

[biteMark]

Zonder benen kan je niet lopen... Als je iOS apps wil ontwikkelen met de officiele SDK dan zul je toch een Mac moeten aanschaffen, Apple zou wel gek zijn om die SDK voor andermans besturingssystemen vrij te geven!

[Luca]

Maar waarom moet dat vraag ik me af. Hierdoor mis je de nodige ontwikkelaars. Niet iedereen koopt zomaar even een Mac(book).

[gjmi]

In het artikel staat dat het op elk platform gecompileerd kan worden.

[biteMark]

De taal wel ja, maar ik denk niet dat de iOS en OS X SDK's open source zijn gemaakt

[biteMark]

Aan de ene kant mis je ontwikkelaars, aan de andere kant trek je ze aan: ontwikkelaars die per sé willen ontwikkelen voor iOS in Swift gaan vroeg of laat toch wel overstag - en het is niet alsof ze gebrek hebben aan enthousiaste ontwikkelaars

Waarom het "moet" is heel simpel: cross-compiling is dodelijk voor commerciele besturingssystemen... Beter zorgen ze dat ontwikkelaars per sé een Mac moeten hebben.

[geertdo]

Waarom het "moet" is heel simpel: cross-compiling is dodelijk voor commerciele besturingssystemen...

Vendor lock-in dus. Bah. Dat moet je toch niet willen? Leg uit waarom jij dat wel wil...

Als ik de reacties hier lees over Swift, over null pointers etc. geen haar op mijn hoofd...

[biteMark]

Ho, ik heb nooit gezegd dat ík het wil! Ik kan alleen wel begrijpen waarom Apple het wil... Maar als je er niet aan wil beginnen, dan doe je dat toch niet?

[Lethalis]

Het ios platform is zo populair dat het ze niet interesseert. Daarnaast worden er veel meer mac's verkocht dan een aantal jaar geleden, dus de strategie lijkt ook te werken.

Ik ben ook via mijn werk ermee in aanraking gekomen en een collega van mij is een echte mac liefhebber geworden.. Alleen maar omdat de directeur graag een ipad app wou

Dus kregen we een paar ipad's en een imac op kantoor.

Het duurde niet lang voordat we zelf ook mac's hadden gekocht.

[Verwijderd]

Dat is niet helemaal waar. Je bent niet verlicht om je Apps met Xcode te bouwen.
https://developer.xamarin...in_ios_for_visual_studio/

[Reactie gewijzigd door Verwijderd op 23 juli 2024 03:11]

[biteMark]

Klopt, maar als je wil compilen dan heb je wel een Mac nodig Het is absoluut een leuk alternatief trouwens en ik heb er ook met veel plezier mee gewerkt, maar eigenlijk alleen maar goed voor een gedeelde codebase

[Verwijderd]

Ja daar had ik nog niet aan gedacht. Ik programmeer alleen op OSX met Xcode en Tangler.

[Verwijderd]

Volgens apple zou het ook met Ubuntu werken: https://github.com/apple/...ME.md#system-requirements

Windows versie kan best door Microsoft gemaakt worden voor het UWP zoals ze dit ook met objective-c gedaan hebben.

[macnerd]

Dat had je ook in het artikel kunnen lezen... er zijn Linux binaries, dus het lijkt me logisch dat het ook op een Linux distributie als Ubuntu werkt

[Verwijderd]

quote: http://tweakers.net/nieuw...eaction=8052005#r_8052005

Nu nog iemand die een compiler schrijft om het ook naar Windows/Linux (misschien zelfs Android) te compilen

Het was dan ook een reactie op runelaenen voor wie dit niet duidelijk was. Een bron van Apple staat ook altijd sterker dan het artikel waaruit geen duidelijkheid gehaald kon worden. Dus ja, dit heb ik gelezen

[Sjenker]

Begrijp ik dus goed dat ik binnenkort of over een tijdje niet meer verplicht ben om een mac(book)met en of osx vm's te gebruiken voor het compilen van iOS applicaties?

[BikkelZ]

Compilen is niet het probleem, het ondertekenen kan alleen op een Mac. En je kunt alleen ondertekende binaries runnen op iOS devices, zoals de telefoon waarmee je test. De simulator draait ook alleen op OS X.

De tooling voor het compileren zelf is gebaseerd op LLVM dus daar heeft nooit echt een beperking gezeten.

[Sjenker]

En daar gaat de opensource licentie dus wel of geen verandering in brengen, want dat kan ik dus niet uit de tekst opmaken.

[BikkelZ]

Nee, je gaat wel in de toekomst officiële implementaties voor server side implementaties krijgen of Swift for Android achtige projecten. Maar de certificaten hebben niks met de programmeertaal of de compiler te maken.

[Sjenker]

Hmm , dat is jammer. Had eerlijk gezegd graag gezien dat ik code op windows of linux alleen al kan debuggen met een simulator zonder mac als buildhost. Voor het signeren zou ik dan gerust geld voor over hebben om een apple machine aan te schaffen om vervolgens mijn app op een echte iphone te kunnen draaien.

[BoringDay]

Windows heeft een ander architectuur, maar het is toch ook veel leuker om met Xcode iets te ontwerpen voor iOS, voor Android met Android Studio en voor windows iets als Visual Studio?

Je kan beter wat meer tijd erin stoppen met de juiste tools i.p.v. gebrekkige oplossingen voor 1 codebase?

[Verwijderd]

https://developer.xamarin...in_ios_for_visual_studio/

Dat kan al een tijdje eigenlijk.

[Sjenker]

Nee, je hebt als nog een machine met osx als build host nodig ik werk zelf met xamarin. Ik bedoel dus dat je gewoon op je linux of windows code kunt compilen en uitvoeren.

[Verwijderd]

O zo. Dat weet ik niet ik ontwikkel uitsluitend op OSX. Heb zelf geen ervaring met Xamarin, maar kwam het een tijdje geleden tegen.

[SBTweaker]

Zoals in het artikel aangegven is er een linux port.

[Zumpelvelder]

Dat ze bijdragen aan de opensource community vind ik een mooi gebaar, maar zitten we hier eigenlijk wel op te wachten? Ik bedoel dan specifiek het volgende: We hebben C++ voor degelijke programma's en Python om snel even iets in elkaar te hacken en voor de wat minder belangrijke programma's. Meer hebben we toch niet nodig? Er zijn al zo ongelofelijk veel programmeer talen..

Sorry voor de slechte classificatie van programma's maar dit was wat er in me op kwam.

Mijn vraag is dus eigenlijk: Wat is het voordeel ten opzichte van C(++/#) en Python? Waarom zou ik deze taal moeten leren en gebruiken?

[BoringDay]

Dat is een keuze die bij jezelf ligt, het heeft alleen nut als je er ook wat mee gaat doen.

[curumir]

Jouw vraag vind ik een beetje hetzelfde als de vraag waarom er nog onderzoek gedaan wordt naar auto's - jawel, een slechte autometafoor. De vrachtwagens zijn er voor goederenvervoer en personenauto's voor het vervoer van personen. Meer hebben we toch niet nodig? Waarom wordt er dan toch nog onderzoek gedaan naar nieuwe modellen. Nou, voor meer rijgemak, veiligere auto's, efficiënter rijden etc. Ditzelfde geldt in zekere zin voor programmeertalen.

Ooit heeft Turing bewezen dat je in principe met de simpelste taal theoretisch alles kunt maken wat je met de meest complexe talen kunt dmv Turing Machines. Inmiddels hebben we functionele talen, objectieve talen, en wat al niet meer. Allemaal pogingen om het schrijven van programma's makkelijker, meer bug-vrij en efficiënter te maken. Dit onderzoek ligt gelukkig niet stil want getuige de enorme hoeveelheid bugs in applicaties is dat hard nodig.
Een deel van dat onderzoek vind plaats op het gebied van compilers en bestaande talen, maar Swift is een voorbeeld waar inzichten van de afgelopen jaren in een nieuwe taal worden gestopt. Zie ook BikkelZ hierboven waarom sommigen er best enthousiast over zijn. Of je het zelf wilt gebruiken is zoals BoringDay terecht zegt iets wat je zelf moet kijken. Het leuke van programmeren is dat je voor de meeste zaken gewoon keuze hebt.
O, en er zijn ook mensen die vinden dat je vooral een betere programmeur wordt als je meerdere talen kent en regelmatig iets nieuws probeert...

[Verwijderd]

Prima werk, bijdragen aan de open source community moet door ieder zichzelf respecterend bedrijf worden gedaan, zeker de grote open source binnen harkende IT bedrijven

[Isheara]

En het is ook nog eens keurig gerubriceerd en gedocumenteerd! Hulde!!

[Verwijderd]

Goeie ontwikkeling. Ik moet eerlijk zijn dat ik Swift een van de makkelijkere programmeertalen vind als je het vergelijkt met Java of Objective-C.

Ik was al aan het kijken of ik Swift op mn Raspberry Pi kon laten werken. In verband met een projectje dat ik bij een vriendin ga aanleggen.

[Reactie gewijzigd door Verwijderd op 23 juli 2024 03:11]

[Verwijderd]

Er is ook een GitHub-repository, maar die is op moment van schrijven, net als de site zelf, down.

Ik denk dat je git-repository bedoelt, maar toevallig staat het ook op github, en die is niet down:
https://github.com/apple/swift

Update: Ok misopvatting. Ik heb geen bewaar met de term github-repo (zolang mensen maar snappen dat git losstaat van github, waar ik op tweakers wel vanuit ga). Ik verwacht dan wel dat een linkje wat erna volgt ook naar github verwijst, dat deed het hier niet. Wat bleek later nou toen de site niet meer down was? is dit de eerste zin:

The code for the Swift project is divided into several open-source repositories, all hosted on GitHub.
met github als link naar de github pagina. Tja als ik dat had gezien dan had ik mijn reactie nooit geplaatst.

[Reactie gewijzigd door Verwijderd op 23 juli 2024 03:11]

[Wraldpyk]

"In de volksmond" word een Git-repository op GitHub ook wel een GitHub repository genoemd.

[xoniq]

Neemt niet weg dat het onjuist is.

[Kettrick]

Daar is niets onjuist aan, repository een gewoon de naam van het beestje op github:

https://developer.github....ing-started/#repositories

Of het wel of geen geldige git term is doet niet ter zake.

[Blizz]

+

De Swift-site zelf geeft aan … wroden. Er is ook een GitHub-repository, maar die is op moment van schrijven, net als de site zelf, down.

De site is niet down, maar de site is wel down.

Edit: overigens zijn beide sites en de repo sinds 40 seconden up en bereikbaar.

[Reactie gewijzigd door Blizz op 23 juli 2024 03:11]

[xoniq]

De site is niet down, maar de site is wel down .......

Eh?

[Dutch-gabber]

De Swift-site zelf geeft aan … wroden. Er is ook een GitHub-repository, maar die is op moment van schrijven, net als de site zelf, down.
--------
De site is niet down, maar de site is wel down.

Hij bedoelt het volgende;
- De Swift-site zelf geeft aan (= de site lijkt bereikbaar)
- Er is ook een GitHub-repository, maar die is op moment van schrijven, net als de site zelf, down. (de site is down, tegenstrijdig)