Re: [OT] RE: Swift [rant, etc]
Re: [OT] RE: Swift [rant, etc]
- Subject: Re: [OT] RE: Swift [rant, etc]
- From: "Jacopille, David" <email@hidden>
- Date: Fri, 24 Jun 2016 19:40:26 +0000
- Thread-topic: [OT] RE: Swift [rant, etc]
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.
Perl is not a natural-language syntax. 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.
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. 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.
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. 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.
On 6/24/16, 2:26 PM, "applescript-users-bounces+djacopille=email@hidden on behalf of has" <applescript-users-bounces+djacopille=email@hidden on behalf of email@hidden> wrote:
>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
MFS Email system made the following annotation
---------------------------------------------------------------------------------------------------------------------------------------
This email communication and any attachments may contain proprietary, confidential, or privileged information. If you are not the intended recipient, you are hereby notified that you have received this email in error and that any review, disclosure, dissemination, distribution or copying of it or its contents is prohibited. The sender does not waive confidentiality or any privilege by mistransmission. If you have received this email in error, please notify the sender immediately, delete this email, and destroy all copies and any attachments.
_______________________________________________
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