[swift-evolution] Please allow me to introduce myself

[Ted F.A. van Gaalen]

as Brent Royal-Gordon correctly wrote to me in swift-dev,
my introduction was meant to be in swift-evolution,
not in swift-dev. By my mistake, it landed there a few days ago…

Swift-dev is for compiler magicians, which I deeply respect.
I know nearly nothing about making complies and linkers.

Anyway, here it is. after this I wil be more concise and
bring up single topics in separate emails. 
Thanks
Ted 


> 
> 
> Hello. This is my first time here, so please allow me to introduce myself.. thank you.
> Grab a chair. Coffee? 
> I've worked with many programming languages since 1979. Interesting years.
> Fortran, Cobol, PL/1 C, CSP, C++, Java, Microprocessor, Assembler, Rexx, Pascal, 
> Smalltalk, APL,  etc. Objective C, and also Swift since it became available. 
> OOD/OOP is my Holy Grail: the thing we found "somehow-something-is-missing-but-dunno-what?”
> before it came along :o)  My current creativity is RavelNotes, an ObjC/Swift hybrid iPad app 
> and under construction is a 3D game app with Swift/SceneKit for Apple TV. 
> I am 65: Now that I am retiring, app development will be the main thing for me to do 
> because it is fun and  also because I simply cannot stop making software… 
> and I have lots of time for it.. without any quality compromising deadlines...
> 
> 
> I am quite happy with Swift! It connects really good with the stuff that is already inside 
> my head allowing me to transfer my ideas and creativity into the virtual world without
> too much hassle in-between. Swift is still new, but right from the start it has everything 
> I need and could wish for!  There is really not that much missing, if any. 
> Thanks to Chris Lattner and team: you guys did a really amazing job!  
> 
> Thanks for reading.. 
> still here? OK
> --------------------------------------------------------------------------------
> 
> 1. On removing (possibly) superfluous language elements
> 
> IMHO it is nearly impossible to estimate whether or not a certain language element
> will or will not useful now or in the future. It's like Lego. So don't remove bricks from the 
> box that you might think will not be used anymore, just because a quick scan in the 
> neighborhood in GitCity  reveals that at the moment no others are using this kinda bricks...
> 
> So why not keep these things like i++ i--
> and the C-style for loop? More important imho: do the best to maintain downward compatibility 
> e.g. save us from modifying 10000 source files written in 2016 in say 2021 when Swift 8.0 arrives..
> 
> --------------------------------------------------------------------------------
> 
> 2: Swift "for" statement: why not add this variants:
>  (to get rid of reverse, strides, generators..and other indirect stuff)
> 
> for i in 12 to 0 by -2 
> 
> for v:Double in x1 to -2.8 by -0.1   
> 
> Swift could handle that implicitly. Most languages have these loops.
> --------------------------------------------------------------------------------
> 
> 3 . I beg you! Please, please, please implement implicit conversion between Floats/CGFloats/Double..
> Why does one need to convert floating point vars explicitly?
> Yes, one can loose precision, but we know that, don't we? 
> --------------------------------------------------------------------------------
> 
> 4 Tuples:  please take a look at this code:  
> 
>  static var z: UInt8 = 0  // initalize tuple with 256 UInt8 values, bytes:
>     
>     // Silly: why not an array instead of this.. a tuple is needed.. length must be exact 256..
>     // know of no other way to create a tuple with 256 elements...
>     var midiDataTuple = (z, z, z, z, z, z, z, z, z, z, z, z, z, z, z, z, z, z, z, z, z, z, z, z, z, z, z, z, z, z, z, z, z, z, z,
>  z, z, z, z, z, z, z, z, z, z, z, z, z, z, z, z, z, z, z, z, z, z, z, z, z, z, z, z, z, z, z, z, z, z, z, z, z, z, z, z, z, z, z, z, z, 
> z, z, z, z, z, z, z, z, z, z, z, z, z, z, z, z, z, z, z, z, z, z, z, z, z, z, z, z, z, z, z, z, z, z, z, z, z, z, z, z, z, z, z, z, z, 
> z, z, z, z, z, z, z, z, z, z, z, z, z, z, z, z, z, z, z, z, z, z, z, z, z, z, z, z, z, z, z, z, z, z, z, z, z, z, z, z, z, z, z, z, z, 
> z, z, z, z, z, z, z, z, z, z, z, z, z, z, z, z, z, z, z, z, z, z, z, z, z, z, z, z, z, z, z, z, z, z, z, z, z, z, z, z, z, z, z, z, z,
>  z, z, z, z, z, z, z, z, z, z, z, z, z, z, z, z, z, z, z, z, z, z, z, z, z, z, z, z, z, z, z, z, z, z, z, z, z, z, z, z, z)
> 
>     
>     func midiSend(status: Int, val1: Int, val2 :Int)
>     {
>         var midipacket = MIDIPacket()
>         
>         midipacket.timeStamp = 0
>         midipacket.length    = 3
>         midipacket.data      = midiDataTuple  //<-=<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<
>         
>         midipacket.data.0 = UInt8(status)
>         midipacket.data.1 = UInt8(val1  )
>         midipacket.data.2 = UInt8(val2  )
>         
>         var midipacketlist = MIDIPacketList(numPackets: 1, packet: midipacket)
>         
>         MIDIReceived(midiSource, &midipacketlist)
>     }
>     
> I can't treat tuples as an array, which in this case would be handy to initialize all the tuple elements.
> 
> IfTrue: Why are tuples the only data type to use for unmanaged byte arrays? 
> 
> --------------------------------------------------------------------------------
> 
> Sideways: fun & inspiration: take a look at APL.. [I'll wait here]  this language uses mostly symbols for operations. 
> E.g. it has an excellent set of chars for Set operations. To experiment with this,  replaced Xcode's source font with 
> an APLFont and then define operator extensions for some APL characters like e.g. Ro to get or alter the shape 
> of a multi dimensional array    or  +/   to sum a vector.
> 
> 
> Regards
> Ted
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160217/fdd8ee7a/attachment.html>