Re: [OT] RE: Swift [rant, etc]
Re: [OT] RE: Swift [rant, etc]
- Subject: Re: [OT] RE: Swift [rant, etc]
- From: has <email@hidden>
- Date: Fri, 24 Jun 2016 22:27:30 +0100
On 24/06/2016 20:40, Jacopille, David wrote:
Take it down a notch, brother. You’re so argumentative. And verbose. And not right.
Swift isn’t just C++ with a slightly modified syntax. Too dismissive of the effort they are making.
Out of the box Swift was designed to operate like a scripting language. That was the selling point. I think they’ve made progress towards that.
Rubbish. Eliminating a few braces and inferring some local types doesn't
make Swift a scripting language. And, what is a "scripting" language
anyway? Nowadays they're mostly just C knockoffs themselves: Python,
Ruby, JavaScript, etc. Swift is very much in the vein of C-family
languages, C++ in particular. Heck, it's even written in C++, by C++
developers. You think there's a significant difference, you _really_
need to get out more, because there is a VAST world of programming
languages and computation models already out there that you don't even
realize exist, and until you do your perspective on language design
ain't worth squat. Go read lambda-the-ultimate.org for a week and then
get back to us once you've managed to stuff your brains back inside your
head. Honestly, it will do you the world of good.
Perl is not a natural-language syntax.
Who said it was? You're reading the words you think you see, not the
words I actually wrote. I said Perl was designed to have a *level of
expressivity* comparable to natural languages. *Semantics*, not syntax,
are what matter. If you don't know the difference between the two then
you're simply not qualified to say that Swift is or isn't like C++.
It’s basically a C syntax, which no one ever accused of being natural-language like. The expressive and discretionary aspects of Perl drive people nuts because they make it harder to read, not easier.
Which people are those, exactly? Perl users? Non-Perl users? Because why
would a bunch of people for whom Perl wasn't designed be expected to
like or use it? Hey, you think Perl is rage-inducing, try APL. Every
programmer on the planet old enough to remember absolutely *despises*
APL. Which is only natural, because APL *wasn't designed for
professional programmers*, it was designed for *professional
mathematicians* and it is absolutely stunning to watch how those folks
use it and what they make it do:
https://www.youtube.com/watch?v=a9xAKttWgP4
Seriously, I'm not kidding when I describe mainstream programming as
"banging the rocks together". That really is the level of primitivism at
which mainstream programmers work; and worse, not only can they not
conceive of more sophisticated ways of working themselves, but they
outright oppose it even for anyone else. Because change is a threat.
Oh sure, they may _think_ themselves these brave libertarian
techno-pioneers constructing a wondrous new future for all, but in truth
they're such a bunch of stiflingly reactionary conservatives they'd make
John Birch look a longhair pinko hippy by comparison. Any other
profession, they'd have long gone the same way as all those proud
Linotype operators who confidently declared Macs could never replace
them, but since the 80s the rotten sods have done such a good job of
drowning out any other ways of thinking that they're now incredibly hard
to unseat through sheer mass and inertia. But hey, one man's strict
orthodoxy is another's soft underbelly. I may not be a highly skilled
programmer and my sales pitch is pure pish, but I've trounced the
useless bleeders on actual results before and I won't hesitate to do it
again, simply because I make the effort to learn the problem and listen
to the users. So while it may take me a bit (or lot!) longer to build,
at least my stuff works *right*.
I do a lot of development in Illustrator myself. Adobe has provided four great language interfaces that are pretty well documented and that work great - including AppleScript. We’ve built thousands of charts with it. Another language to do this work really seems unnecessary and undesirable.
Ah, the standard whine by every lazy complacent programmer who never
wants to learn anything new or be disrupted by anything different ever.
Don't expect to get any respect at all pulling that ridiculous canard.
Besides, who's making charts here? I'm flowing content into dozens of
complicated graphical elements built up of multiple text frames and
paths, and I'm doing it all in about the same amount of code it'd take
to generate a single one of your charts. Watch that video I linked and
do a quick back of envelope calculation of how many lines of AppleScript
and XML it would take you to do all that - data retrieval, decision
making, content insertion, formatting, fitting, toggling, repositioning,
and all. If AI's own templating facilities were even remotely up to the
task you don't think I wouldn't be using those? Oh, and you try telling
an artwork operator pulling 50-hour weeks doing it by hand he has now to
learn XML and AppleScript and programming skills as well if he doesn't
want his job swanning off to China or India where they'll also do it by
hand but at a quarter of the cost. Here's what it takes for an artworker
to start getting productivity gains in kiwi:
1. Type '{'.
2. Type the name of the pack copy field you want to use, e.g. 'product
description'.
3. Type '}'.
Repeat for each text box in your design trace. Congratulations, you now
have a working kiwi template. Now hit run, sit back, and watchen das
blinkenlights as it spends a few seconds flowing all your text in for free.
Kiwi isn't for veteran AppleScripters any more than APL is intended for
C++ wonks. It is intended first for frontline artworkers, so has a bar
for entry so low you'd have to feed AppleScript through an industrial
steel press to even think of squishing it under, and second for
back-of-house Python developers who can bring the formal coding
experience which combined with those artworkers' own domain expertise
enables them to develop very powerful and efficient workflows. Which is
why it can scale way up too: the language is very Lisp-like, homoiconic
and naturally metaprogrammable, and is highly extensible via Python when
you need to add completely new features. Oh, and it talks to Illustrator
using Apple events too (via Python-appscript), so "Hah!" as the joke's
on you there. Cos I've been doing "AppleScript" automation for 16 years,
and the stuff you can achieve with Python+appscript absolutely mops the
floor with anything that poor old AppleScript language can do.
If you want a super simple way to set up tons of charts of a similar genre just make an XML schema. Put all the properties, variabilities and data in the XML and have your script driven by what the XML calls for. You don’t have to touch code to build a new chart that way, and an hour would be a long time to set up a new chart. No new programming language needed. Building a schema is a lot easier and faster than a decent programming language.
Hey, if you can replicate my brand guidelines automation in an hour I
will delightedly toss my solution and adopt yours. Inlike programming,
in business nobody wins a prize for being the cleverest failure in the
room. Oh, and no cheating: it had better match the customer's brand
guidelines document point-for-point or they'll furiously fire your
automated ass, and probably sue it too. Plus don't forget that in a year
or two the customer will revamp their whole brand design so you'll have
to do it all over again for the same content but new artwork. And then
when you've done that, I've a boatload of swing tags and general
merchandise cutters needing done too. :)
Finally, just for the sake of not wasting my whole day, why is there a book on doing functional programming with Swift if it’s not possible to do functional programming with Swift.
Because 99% of mainstream programmers today are the living embodiment of
high-functioning Dunning-Kruger morons: they don't even know enough to
realize they're wrong, but that doesn't stop their unbridled enthusiasm
for propagating their wrongness everywhere they can. Also, please, don't
try pulling an Argument from Authority or Popularity again; I will smack
those down with zero mercy.
You may be living in Plato’s cave if your vision of functional program excludes the kinds of things you can do with Swift, or Perl for that matter. Yes, Perl can do functional programming also, just to give you something else disagree with.
No, it can't. Programming with functions != Functional Programming.
Being au-fait with filter-map-reduce is not FP; it's array programming
at most. FP is about getting the machine to figure out all the tedious
sequential processing stuff so you don't have to - i.e. what
computations it needs to perform and in what order to produce the
correct output for a given set of output - just as garbage collection is
about making the machine take care of all the tedious memory allocation
for you so you don't have to worry about your program springing leaks.
FP's far closer to analog computing or pure math than it is to any
imperative language. Can Swift give you massive parallelism 100% for
free? No? Well, there you go.
That the vast majority of modern mainstream programmers may think FP is
just a posher version of imperative programming is damning indictment of
both them and their educational establishments, not any kind of proof
they are right. Please don't bother arguing about what FP is or isn't
until you can show you've a better understanding of non-imperative
computation models and the languages that implement them than I do.
Which, given I'm a barely literate moron myself really shouldn't be
*that* hard. But having written a semi-declarative language myself, and
seen the benefits it yields first hand, I am just starting to
understand: not only what it can give us, but also just how bad we've
been ripped.
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