
Writing custom tools with Swift - ingve
https://paul-samuels.com/blog/2019/01/12/writing-custom-tools-with-swift/
======
rgovostes
Swift tries to be a jack of all trades, but I think as a scripting language
(as in this example) it falls short. Having to start a run loop, write
asynchronous callbacks (completion handlers), and implement custom JSON
decoders just to make a web request is introducing a ton of complexity that
might make sense in an event-driven interactive GUI application, but not so
much in a quick shell script.

Swift tools might be a good choice for use cases where you need to integrate
with an existing Swift project, or if you need lower level APIs.

In this example, a Bash script would have been almost done by the time you
worked out the `curl | jq` command. But in other similar cases I would suggest
Python Requests, which will take perhaps 10% as much code and avoid issues of
Linux compatibility and mistakes like forgetting to call `resume()` on your
download task or `exit()` in some branch (there are five calls just to keep
the program from looping forever).

That said, I think this blog post is very informative and well-made for a
beginner interested in talking to a web-based JSON API from Swift.

~~~
jph00
Swift's APIs tend on the verbose side, but they can be wrapped up into much
more concise versions. Since few people have been using Swift in this way,
those wrappers haven't really appeared yet (and because Swift packaging is
still in such poor shape) but it will come - just like the "requests" library
made http so much more concise and easy in Python.

The obvious question, of course, is: why bother? The answer is that this code
runs at about the same speed as C. So if you're doing data munging of a big
file, this is a really interesting approach. For data scientists, I think
there is a lot of opportunity here.

~~~
yxhuvud
But then you might as well use Crystal instead, which already have scripting
language usability while retaining the performance.

I like the idea of swift and I want to like it, but everytime I look at APIs
it seems they dropped the ball.

~~~
coldtea
> _But then you might as well use Crystal instead, which already have
> scripting language usability while retaining the performance._

Without the libraries, documentation, maturity, and major support.

~~~
the_gipsy
Excuse me but swift libraries plain suck, because of the bad package
management. Documentation is also poor and mostly “look at the example, tests,
or source”.

~~~
coldtea
Documentation is poor? There is lots of documentation for every iOS/Mac class
and feature on developer.apple.com, and for the language and standard library,
and dozens of books (several of them made by Apple and free). Plus tons of
third party blogs and videos on Swift programming.

That's more than anything that can be said for Crystal documentation.

And bad package management or not (I don't see much problem with it -- and you
have several options to chose from, cocoa pods, carthage, etc), there are tons
more libraries than Crystal has again.

~~~
the_gipsy
Oh sure the standard lib is well documented, I thought we were talking about
3rd party libs.

> And bad package management or not (I don't see much problem with it -- and
> you have several options to chose from, cocoa pods, carthage, etc)

That's the problem. It should be SPM, period. But few libs use that, and some
still don't work on linux and you don't realize until you try to build.
Carthage is slow, hard to integrate with xcode project and CLI. CocoaPods, I
guess it was super useful before swift, but now it seems like it can only work
with xcode projects.

------
zwetan
I like it, being able to start with a shell script and then evolve the tool to
a static binary is pretty neat, I do that all the time with ActionScript

I don't think it's trying to be a "jack of all trades", sure Bash can do
plenty but when you reach few hundred lines of Bash and start to fight against
the syntax to do simple things well...

The shebang line is there to be used, you can use sh, bash, etc. but there are
other citizen like perl, php, python, etc. so why not swift or anything else
if it help you build quickly command-line tools?

------
BooneJS
Depending on your usage, a "script" done in a language like Swift, Go, or
Haskell will probably take a little longer to put together than a bash script.
Bash merely glues together generally-available command-line tools with pipes
and minimal error handling, whereas the other languages typically require you
to put forth some energy to use their library and validating outputs.

If all you care about is ticking a box in the shortest amount of time, I've
found that small scripts are best done in bash whereas longer "scripts" would
benefit from a safer language utilized in a JIT compilation paradigm (shebang
for Swift or Haskell, `go run`, etc).

------
FraaJad
Fsharp is a much better language for scripting than swift will ever be. F#
with the pipe operator used judiciously makes reading it a joy.

