71–80 of 145 posts
Earlier quoted context omitted.
Swift was released before kotlin
But wasn't open source till the end of 2015 ( https://developer.apple.com/swift/blog/?id=34 ) Kotlin was open sourced around 2012 and people were using it in Android apps before Google officially started supporting it in 2016.
Swift open source 2015/12/3: https://developer.apple.com/swift/blog/?id=34
Earlier quoted context omitted.
The directory thing is more due to sandboxing than anything else. They don't want someone to be able to write an app that can read anything anywhere on your phone, so it has specific directories that have different levels of access and temporality (i.e. one is a temp folder that gets flushed each time you quit the app, if I remember correctly). It's not that complicated once you look it up, and like most of this stuf…
> They don't want someone to be able to write an app that can read anything anywhere on your phone, And that's the main problem with Foundation which hurts Swift as a language: it was made for iPhone apps, and hardly anything else. I was trying to make a CLI app on the desktop. I gave up and used something else. > It's not that complicated once you look it up, and like most of this stuff Yeah, I tried to look it up.…
let fileContents = try? String(contentsOfFile: "file.txt")
In the context of an iOS or MacOS app, that of course won't work, because apps only have access to certain directories. That is why you typically use the FileManager object to get the path to the directory you'll need.
Earlier quoted context omitted.
> One thing I forgot to mention in my previous post is paths in Python, which has this whole fun page on it in the Python documentation: https://docs.python.org/3/library/os.path.html . Part of the reason for this in the first place is because pathing is handled differently between Unix and Windows systems, so you're supposed to use this library to navigate (or something completely different, glob, which is another t…
Good to know, thanks :) I've only ever used Python for my own tinkering purposes so I haven't been too aware of any new developments. But I assume the old ways are still valid code, so if you're working with Python code you may encounter any of now 3 different systems of just navigating paths for file i/o, what the parent claims should be dirt simple.
The method in my link (which changed rather drastically between versions):
- is very much iOS and MacOS specific
- requires knowledge of quite a few iOS/MacOS-related things (FileManager.SearchPathDirectory is probably 80% Apple-specific)
- even though it's a "FileManager", it doesn't even let you access/open a file. You have to perform additional operations on the resulting Directory type (.appendingPathComponent)
- even that doesn't give you a means of opening a file, because in order to read a file, you have to invoke a String constructor. In order to write to a file, you need to invoke a method on a String type. Talk about coupling entirely unrelated things
That is an example of objectively bad API design.
And it's clear from API evolution that it's not even Swift APIs. These are very thin wrappers for OS's existing Obj-C APIs. I think it's the first among languages: to provide OS APIs and call them a standard library for a language. I don't think even MS did that when they were creating .NET.
Earlier quoted context omitted.
> They don't want someone to be able to write an app that can read anything anywhere on your phone, And that's the main problem with Foundation which hurts Swift as a language: it was made for iPhone apps, and hardly anything else. I was trying to make a CLI app on the desktop. I gave up and used something else. > It's not that complicated once you look it up, and like most of this stuff Yeah, I tried to look it up.…
let fileContents = try? String(contentsOfFile: "file.txt") That works perfectly fine. In the context of an iOS or MacOS app, that of course won't work, because apps only have access to certain directories. That is why you typically use the FileManager object to get the path to the directory you'll need.
I would never in my life figure out that
- reading from and writing to a file is not the job of file-related modules, but of a string
- that it would just work like this wothout getting a proper handle to the file (what I assumed what the whole FileManager bruhaha was about)
Earlier quoted context omitted.
Nah, Swift is an easy language. I have a Cookbook here: http://www.h4labs.com/dev/ios/swift_cookbook.html I’m in the process of putting it on Github. https://github.com/melling/SwiftCookBook SwiftUI probably means that millions of apps will eventually move to Swift, making Swift a top 10 language. https://www.tiobe.com/tiobe-index/
Swift is already a top 10 language according to TIOBE.
Red Monk seems much closer to reality: https://redmonk.com/sogrady/2019/07/18/language-rankings-6-1...
Earlier quoted context omitted.
Swift for Tensorflow also isn't at 1.0 AFAIK and hasn't been deemed "ready for primetime". I think it's going to be hard to get data-scientists using anything other than Python any time soon, but I'm hopeful it will take off at some point, since it's really painful to work with scripting languages once you get used to a decent type system. It's also a super interesting project to follow. The stuff they are doing with…
Yes it’s not at 1.0, but my point when I mention to people actually doing deep learning that Swift is coming and has support for native differentiation and static typing, the response is underwhelming to the point that I wonder if either of those features provide enough pull to get people to ever drop Python for Swift.
Still given the growth of that industry, it's hard to imagine that Python can bear the burden of the increasingly complex work there forever.
Earlier quoted context omitted.
Swift is already a top 10 language according to TIOBE.
TIOBE’s methodology and rankings seem very dubious to me. When was the last time you met someone who primarily programs in C? (I was one of those people for 14 years, but that was a while ago). Red Monk seems much closer to reality: https://redmonk.com/sogrady/2019/07/18/language-rankings-6-1...
I hate to say this, but Swift is to Objective-c, what Scala is to Java.... It was very exiting and promising at first, but it became bogged down due to its sheer run-away complexity and over-academic approach to programming.... To an outsider, or iOS new comer, Swift looks much better than Objective-c, (due to Objective-c weird syntax), but to many insiders, Swift seems like a huge missed opportunity... The use of Sw…
swift is as pragmatic as kotlin
I hate to say this, but Swift is to Objective-c, what Scala is to Java.... It was very exiting and promising at first, but it became bogged down due to its sheer run-away complexity and over-academic approach to programming.... To an outsider, or iOS new comer, Swift looks much better than Objective-c, (due to Objective-c weird syntax), but to many insiders, Swift seems like a huge missed opportunity... The use of Sw…
Earlier quoted context omitted.
Yes it’s not at 1.0, but my point when I mention to people actually doing deep learning that Swift is coming and has support for native differentiation and static typing, the response is underwhelming to the point that I wonder if either of those features provide enough pull to get people to ever drop Python for Swift.
Yeah I think it will be a really hard sell since my perception is that programming is python for a lot of data scientists. Also static typing is something you have to use for a bit before you can understand that the little bit of extra formality is actually saving you a lot of trouble in the medium and long term. Still given the growth of that industry, it's hard to imagine that Python can bear the burden of the incr…
Once you get to the modelling step all of the data is in typed arrays.
Static types start to shine once the project grows and the new type annotation syntax works great for that.
I've tried doing machine learning in C++, Java, Scala and JavaScript and all of them are a pain compared to python.
Python would be perfect if I could annotate parts of my code and compile them. (Pretty much what's commonly done with cython or numba jit.