lerno

28 ms·

361.
by lerno 12y ago
Actually, a Swift array is pretty much identical to a C array. You get an unsafe pointer to that array and treat it exactly as it was one. NSArray on the other hand is toll-free bridged to a CFArray. The current "solution" is to k
362.
by lerno 12y ago
No, but we have been told that the performance characteristics of the native Swift array should be the same as an array in C. Judging from what the compiler team at Apple regularly write in forums and on twitter, it seems that they consider
363.
by lerno 12y ago
In theory Swift's arrays are little more that a c array + length, and this is how we have been encouraged to use them. The issue here is nothing about "managed code", but about how the Swift compiler behaves without any optim
364.
by lerno 12y ago
We've essentially been told to use Swift arrays as we would C arrays, so your analogy is flawed. Another premise for Swift is that it should be usable for low level, high performance programming but "safer than C". This is so
365.
by lerno 12y ago
This problem has been understood and resolved by a number of thinkers. The Buddha, lots of buddhist masters, then we also have people like Eckhart Tolle who clearly realise it. The problem is that consciousness is goes beyond conventional l
366.
by lerno 12y ago
I see some programmers that work at it, but after 5 years their level is just as it was when they started out. At the same time, there are others who grow their skill at an amazing rate, going from almost clueless to great over like 2 years
367.
by lerno 12y ago
Here are some observations that may or may not help you: Average programmers tend to: * like new projects * want to build "new things" * not like fixing bugs * not like reading code * not like to redo their designs/code
368.
by lerno 12y ago
Interestingly, Swift may not even be a "better C++" for all domains dominated by C++: The memory model is strictly ref-counted which is unsuitable for certain tasks (e.g. high perf game programming) and the runtime performance is
369.
by lerno 12y ago
I wonder what's really best / possible. Most teams / companies start up homogeneous to some extent. Also, there is plenty of conflicts possible even in a homogeneous team - it's just more clear that assholes are assholes
370.
by lerno 12y ago
Regardless of whether you agree or not, it's very interesting in that it's challenging the merits of things we take for granted as being "good".
371.
by lerno 12y ago
Wrong. TCP has a lot of behaviour you can't work around. UDP is what you write it to be. When experiencing packet loss not due to bandwidth, TCP will delay recovery compared to what UDP can achieve. For games etc, you need to be able t
372.
by lerno 12y ago
Personally I went all-in on Swift. Unfortunately I found that the sceptics were largely right about Swift: The safety features did not make the code more safe, but caused new classes of bugs. Runtime performance fairly random. Generics caus
373.
Building a better Objective-C(owensd.io)
5 points by lerno 12y ago|0 comments
374.
Imagining features for an ObjC 3.0(swiftopinions.wordpress.com)
6 points by lerno 12y ago|2 comments
375.
An Objective-C 3.0 What-if(swiftopinions.wordpress.com)
2 points by lerno 12y ago|0 comments
376.
An inventory of Cocoa-compatible languages running on top of the ObjC runtime(swiftopinions.wordpress.com)
2 points by lerno 12y ago|0 comments
377.
To Swift and back again (comparing the same project in Swift and ObjC)(swiftopinions.wordpress.com)
12 points by lerno 12y ago|1 comments
378.
by lerno 12y ago
I tried to hunt down the statement but without success. If I didn't imagine it, then I'm fairly sure it was in the Apple dev forums. However, I did find a posting where someone said they hadn't found the Swift runtime libs bu
379.
by lerno 12y ago
Incidentally the problem is much smaller than in a statically typed language with containers. Compare the difference between a Java list prior to generics and afterwards. Using it in Java was an orgy of object casts. This is not the case fo
380.
by lerno 12y ago
"How does that analogy make any sense?" Well, I told you that the blog forms a narrative, of which the entry forms a part. His reasons for reaching the conclusions in this entry is based on earlier investigations, which are detail
381.
by lerno 12y ago
I regard Swift's inconsistent runtime performance and over-reliance on compiler optimizations as a major problem with the current state of the language. It does not help that some slowdowns are due to bugs, and some due to questionable
382.
by lerno 12y ago
Since we're talking about Swift generics here, you have to realize that the point is not whether generics / static typing can be useful, but if the type of generics and static typing as enforced by Swift is good enough. The proble
383.
by lerno 12y ago
You read the last chapters of books too just to see if they're worth reading?
384.
by lerno 12y ago
On the contrary, it is well known that ObjC and related languages represent a different strain of OO than Java or C++. In fact, people has gone so far as to say that C++/Java don't really represent "real" OO at all. It s
385.
by lerno 12y ago
Well, in practice the broken generics stop large amounts of reasonable uses of generics, the lack of co/contravariance force you into hideous workarounds everywhere. As for the promised runtime performance improvements they have yet to
386.
by lerno 12y ago
Regarding "blub" I already told you that this is unlikely given the amount of dialog and work Owens has done in the language so far. He is one of the few people who has written in depth about the language (not tutorials) If you di
387.
by lerno 12y ago
There are degrees of static typing. Swift tries to get close to Haskell, but without the full set of tools to do so without losing things along the way. This is sort of the worst of both worlds. In the meantime Strongtalk already demonstrat
388.
by lerno 12y ago
Look at Eero for to how a simple updated syntax could look. On top of that, many of Swift's features could run on an updated ObjC as well. The problem is that the features that required a whole new runtime and compiler model are very f
389.
by lerno 12y ago
I don't understand why people use Core Data. The sweet spot for Core Data is really tiny, yet everyone seems to be using it (and regretting it).
390.
by lerno 12y ago
They said they made a version of it in Swift. The actual version deployed on the App Store was written in Objective-C.

More ›