[OT] RE: Swift [rant, etc]
[OT] RE: Swift [rant, etc]
- Subject: [OT] RE: Swift [rant, etc]
- From: has <email@hidden>
- Date: Fri, 24 Jun 2016 19:26:24 +0100
Jacopille, David wrote:
> Swift does take things in a new direction. It's not surprising that
someone with a C++ background might clash with it a bit.
Wut? Swift is just a C++ pig with lipstick on. It has the same rampaging
over-complexity and incoherence out of the bag that C++ worked years to
achieve; just with prettier syntax and new car smell. It's the Brexit of
programming languages: the only people whose interests it truly advances
are its authors; everyone else is just a starry-eyed sucker taken in by
all its flashy promises or unhappily dragged by its unstoppable
Dunning-Kruger mass for lack of any choice.
> I see similarities to Perl, not so much syntactically, but rather in
Perl's ability to drive programmers that like definition and structure
absolutely nuts. Perl's motto is that there is 'more than one way to do
it.' Want to do object oriented programming in Perl - there's lots of
ways, including lots of approaches outside core Perl via modules. With
30,000 modules very little has not been explored by the community.
Nope, Swift is _nothing_ like Perl. Perl was created by a linguist
almost as an experiment to see what benefits (and challenges) a natural
language-like expressivity might provide to its users. Swift supports no
such flexibility; any impression of "more than one way to do it" it may
give is simply the consequence of failing to factor the design properly,
resulting in lots of almost-but-not-quite overlapping special cases
instead of a single general case that covers them all (e.g. Dictionary
structs vs Dictionary classes). Swift was devised by programmers who've
lived their whole lives happily shackled in Plato's cave, diligently
banging the rocks together. Swift's actually much more like AppleScript,
although even AppleScript did at least _try_ to do something new. Swift
merely encodes the same old same-old for the next several decades.
> Sure, it has a lot of programming features. I remember they made a
big deal about closures when announcing Swift 1.0. So you can do
functional programming in Swift.
No, you can't! This is a frequent lie/delusion put about by the clueless
rock-bangers whose idea of learning anything new is simply to
reinterpret it as what they already know. Functional programming is a
type of *declarative* programming, where you're describing the
*relationships* between a program's inputs and outputs. Swift is an
imperative language, where you're describing an exact sequence of
operations in the exact order to perform them. Declarative programming
is much higher level than imperative programming, automating away all
that tedious low-level decision-making and freeing up users to
concentrate on saying what they *want* while leaving the machine to
figure out the exact details of *how* on their behalf.
BTW, I get similarly tetchy when people talk about doing functional
programming in Lisp, because Lisp itself is imperative and so cannot do
FP as-is. The difference with is that McCarthy's Lisp isn't so much a
programming language itself but a language for making new programming
languages. So at least with Lisp you can completely remake it into a
language that does what you want to do. Whereas with Swift you're
utterly stuck with the language its original author decreed it to be,
and if it doesn't fit your needs then tough.
The irony is that Swift comes from the same house as LLVM, which is to
GCC as Lisp is to C: flexible, extensible, componentized, reusable, vs
big ball of mud. Had the Swift devs modularized Swift in the same way as
LLVM or Lisp, users could have easily created Swift variants for
functional programming, scripting, and anything else they wanted: just
take the bits they want - e.g. datatypes + type system for FP, or
datatypes + evaluator for scripting - and combine with whatever other
bits needed to complete the language (e.g. a functional-style evaluator
for FP). They even almost did achieve such modularity - Swift's standard
operators are all defined as a library, not part of the core language -
but never followed it through as they were obviously more interested in
getting it out and getting it right. But if you're building a language
upon which the next 20 years' worth of apps are all going to be written,
that is precisely the wrong stage at which to take ANY shortcuts: just
look at C's legacy - generations of cowboy coders and enormous
impossibly complex software systems manifestly unfit for purpose, and
data integrity and security failures up the wazoo. All Swift has
actually done is polish this idiocy for generations to come.
Oh, and lest you think this is purely academic concern, a
Swift.Functional language would have been the perfect foundation for
writing the Controller layer in Model-Controller-View based apps (i.e.
all of them), blowing away fragile obfuscated crap like Cocoa Bindings
and its atrocious Interface Builder-based UI. Suddenly gluing Models to
Views would've been as simple as writing `a=b`, because in a real FRP
what you're describing is the _relationships_ between nodes in the
system, after which you can leave the machine to do all the tedious work
of binding names, setting up triggers, handling triggered events,
updating state, and all that other noxious imperative bit-twiddling all
by itself. Eliminate all that tiresome repetitive work and you free up
developers to work on far more useful and interesting and productive
stuff instead. It's just Good Automation.
> You're not forced to, but you can do it. Do you really want to use
a separate programming language for functional programming? And separate
languages for each specialized type of programming?
Yes! That's the *whole point* of creating new languages, especially
domain-specific ones: so that *they* take care of the complexities of
the task at hand instead of forcing you to micromanage every detail
yourself. But for that to work, each language needs to be as small and
focused as possible, firstly so that programs can't do stuff that would
break the languages' ability to reason on the users' behalf (e.g. no
side-effects in FP, because that violates the integrity of the
input-output relationship), and secondly so that they're quick and easy
to learn and use. Anyone who tells you that "One Size Will Fit All" is
either a liar or an incompetent (or both), and most likely is trying to
sell a bridge in Brooklyn too.
To give a first-hand example: I've spent the last couple of years
developing the kiwi language to drive template-based artwork generation
in Adobe Illustrator, and because kiwi's designed from the ground-up for
that specific task it enables even non-programmers to build extremely
sophisticated artwork automation workflows in a TINY fraction of the
time and code it would take an expert user to develop in a traditional,
general-purpose, imperative language like AppleScript. For instance,
here's a demo workflow that generates the back-of-pack information for
food packaging:
http://mantasystems.co.uk/automated-brand-guidelines-demo.html
ALL of that Adobe Illustrator automation is driven by simple kiwi tags
attached to the artwork elements, e.g.:
{country of origin}
{ingredients @ format compound ingredient, fit frame to text}
plus maybe a hundred lines of kiwi code in separate files to define the
custom rules that prepare and assembe the more complicated text content,
e.g.:
define rule (
format compound ingredient ((input, text), (output, text)),
replace pattern (
"\n(.+?)(\scontains?:)\s",
{$return}
{$1 @ font (Frutiger LT Com: 67 Bold Condensed)}
{$2 @ font (Frutiger LT Com: 57 Condensed)}
{$soft return}
),
"Given ingredients pack copy text, searches for line break
followed by a
phrase (the composite ingredient name) followed by the word
'contain'
(or 'contains') followed by a colon, and automatically reformats
it as per
brand guidelines."
),
Took me maybe a week to set that whole artwork file up - but I was
learning the requirements and writing the custom rules as I went. And
most of that work is reusable too, so the next BOP job will take maybe
half as long: just tag the artwork, add the rules, and off it goes. You
simply couldn't match that level of productivity in AppleScript - you'd
be weeks writing great sprawling AppleScripts intimately wired to just
that one file, and you'd need a veteran AppleScripter even to start it
whereas any experienced artworker can get rolling in kiwi in an hour or
two. Hell, even the big-iron systems like Kallik and Esko can't get
close touching it; and these are established industry-standard vendors
I'm now going up against single-handed. And if I don't end up dead or in
the crazy bin I could just succeed too, because people who've been in
the packaging business 20-30 years are already blown away 'cos they've
never seen anything like it - just can't believe their eyes - and I
haven't even started scratching the surface of what this technology can do.
One tool, built by the users, for the users.
Now imagine a million.
THAT is the power you get when you can write your languages to fit your
problems, instead of hammering your problems to try to make them fit the
language you've got. And that power is what these idiot priesthoods
every day cheat us all (even themselves!) out of, through arrogance,
ignorance, and sheer constant stupidity. Frankly the only really good
reason to learn Swift is so you can more effectively use it against
itself later on: douse that fire, smash those chains, and kick all the
bleeders out of their precious bloody cave whether they go willingly or
not. Revolution, not evolution - that's what programming _languages_
should be about!
Best,
has
_______________________________________________
Do not post admin requests to the list. They will be ignored.
AppleScript-Users mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
Archives: http://lists.apple.com/archives/applescript-users
This email sent to email@hidden