Things I learnt from Swift Summit

Pete Barber from C#, C++, Windows & other ramblings

I attended the first Swift Summit on 21st of March; there were two days but I only went to the first. Here are some of the facts I learned:
  • Int is not a fundamental type as you would think of it in most languages. 
    • Instead it's a struct that derives SignedIntegerType with the actual value being an instance of the really fundamental type Bultin.World
    • Being a struct means it's a proper object hence its methods, the ability to extend (see later) and can (& does )implement protocols
  • Int can be extended
    • As it's an object (see above) it's possible to write extensions methods.
  • I have a far better understanding of what @autoclosure does now
    • It basically captures  the function rather than invoking it
  • nil is never actually treated as nil when used
And now for some opinion about the day.
  • People seem to be struggling with error handling
    • A couple of talks presented code to avoid pyramids of doom in regard to making a call, checking for success/failure and if successful continuing.
  • People think they're doing Functional Programming
    • Just because Swift supports Functional Programming style and some people use elements of FP they assume Swift is mainly a Functional language and that they are doing Functional Programming.
    • Passing functions arounds as first-class objects does not make your program functional
  • Some people now hate Objective-C

Software Process Dynamics

Rob Smallshire from Good With Computers

At the Software Architect 2015 conference in London I presented "What if? Supporting decisions with software dynamics simulations". [1] This talk introduces the idea of performing numerical simulations of software development teams and the products they build. The value in such simulations is to inform policy decisions and guide deliberate perturbations to the software development process, such as whether and when to add or remove personnel from a project. Simulations should not be used to make hard predications about, for example, when a particular project will be finished.