Stories
Slash Boxes
Comments

SoylentNews is people

posted by martyb on Sunday June 14 2015, @10:44PM   Printer-friendly
from the swift-rise-in-popularity dept.

The hype around Swift is near non-existent by Apple standards, yet the language has attracted high praise since its release last year. Swift is essentially one of the very few Apple products representing a clear departure from the hardware-led approach Steve Jobs took to the business. If Stack Overflow's 2015 dev survey is anything to go by, it looks as if the Swift language might have potential to really shake things up.

Might the days of Apple programmers relying upon objective C be numbered?


Original Submission

 
This discussion has been archived. No new comments can be posted.
Display Options Threshold/Breakthrough Mark All as Read Mark All as Unread
The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
  • (Score: 3, Insightful) by MichaelDavidCrawford on Monday June 15 2015, @12:18AM

    My take is that I'll be happy to learn Swift after it's an ISO standard. This because Apple pulled Objective-C 2.0 as well as Objective-C++ out of its ass without the slightest pretense of standardization.

    There's a real good reason that language committees are so big and the process goes on for so long.

    I haven't even tried to learn Swift yet but from what I hear it's designed to prevent the kinds of bugs that cause crashes and security holes. Given that infinitely many monkeys are submitting to the app store the very instant their obstetrician spanks their first breathe into their wee little baby bottoms, I applaud that goal.

    There are some merits to Objective-C in that calling native apis is done directly rather than the byzantine ways one does that from Smalltalk. I enjoy smalltalk for many good reasons but don't care much for objective-c. If I write native code I'd far rather use either C++ or assembly.

    --
    Yes I Have No Bananas. [gofundme.com]
    Starting Score:    1  point
    Moderation   +1  
       Insightful=1, Total=1
    Extra 'Insightful' Modifier   0  
    Karma-Bonus Modifier   +1  

    Total Score:   3  
  • (Score: 2) by kaszz on Monday June 15 2015, @12:44AM

    by kaszz (4211) on Monday June 15 2015, @12:44AM (#196302) Journal

    Why not plain C for native code?

    • (Score: 2) by MichaelDavidCrawford on Monday June 15 2015, @01:04AM

      The correct use of C++ initialization lists as well as exception safe techniques such as smart pointers enables one to guarantee an object is correctly initialized or not created at all.

      For example Haim Zamir describes his Edge Highlighter algorithm - it's patented, look it up - as more-accurate when you use more memory, but it is not possible to predict the memory usage from the input parameters. So it if runs out of memory it throws an exception, then backs out as if the call to start the algorithm never took place. One then adjusts the input and tries again.

      Yes one certainly can do that in C but it is a huge pain in the ass and immensely error-prone.

      --
      Yes I Have No Bananas. [gofundme.com]
      • (Score: 0) by Anonymous Coward on Monday June 15 2015, @01:44AM

        by Anonymous Coward on Monday June 15 2015, @01:44AM (#196316)

        Excellent point, but can you you please tell me how to get a patent on an algorithm? Using your answer I would like to patent an algorithm for rare steak cooking. Then proceeded to collect royalties from every steakhouse, it's a first to file system after all...

        • (Score: 2) by MichaelDavidCrawford on Monday June 15 2015, @02:00AM

          I agree strongly with Richard that there should not be frivolous patents.

          For Haim to have invented the Edge Highlighter is no different that Bell inventing the telephone. The simple fact that something is an algorithm does not mean it is not an invention one should not be permitted to patent.

          I invented a compressor that I requested my employer patent. They got acquired before the patent was filed, the new owner dropped my invention on the floor. I have many improvements, one may patent improvements so quite likely I will file.

          --
          Yes I Have No Bananas. [gofundme.com]
          • (Score: 2) by bzipitidoo on Monday June 15 2015, @01:38PM

            by bzipitidoo (4388) on Monday June 15 2015, @01:38PM (#196480) Journal

            If you think algorithms should be patentable, then perhaps scientific discoveries and mathematical formulas should also be patentable? Should Einstein have been able to get a patent on e=mc^2?

            That many algorithms are genuinely innovative does not change the fundamental brokenness of the patent system. The point of patents is to encourage innovation, and the mechanism is through an artificial monopoly that, ideally, can be used to demand payment in exchange for permission to use, thereby simultaneously rewarding the inventor and determining just how valuable the invention really is. Nice, if it worked. But it doesn't. Often, the system hinders innovation. Ironic. Among the many problems, it unintentionally plays upon the fear of loss, makes otherwise sensible people cling to "their" inventions, hide them for fear of someone "stealing" the ideas. It also promotes a "mother may I" permission seeking culture that is completely unnecessary and detrimental to independent thinking. The notion that, before writing any code, you ought to search through thousands of patents to make sure you're not about to infringe some, is of course ridiculous, and is routinely ignored.

            There are other, better ways to encourage innovation. We should develop and refine them. Perhaps a system of independent crowdfunding organizations, all using different methods to raise money and different criteria to judge value. Free digital notary services would be invaluable for sorting out priorities, would be much better than the fallacious method of sending a sealed envelope to yourself, to "prove" the date.

    • (Score: 3, Insightful) by fleg on Monday June 15 2015, @03:49AM

      by fleg (128) Subscriber Badge on Monday June 15 2015, @03:49AM (#196351)

      as ever, it depends on the context. where context means, among other things, how much power do you have, which cpu, how much memory, are you on baremetal or do you have an os etcetc

      so generally...

      dont write assembler if the context allows you to write c
      dont write c if the context allows you to write c++
      dont write c++ if the context allows you to write java/c#/swift
      dont write java/c#/swift if the context allows you to write perl/ruby/python

      always go to the highest level of abstraction you can.

      well, i say always, but really it depends on context :)

      • (Score: 2) by CirclesInSand on Monday June 15 2015, @12:23PM

        by CirclesInSand (2899) on Monday June 15 2015, @12:23PM (#196453)

        And don't write perl unless your context allows you to delete the source code immediately after running the program once.

        • (Score: 3, Funny) by Marand on Monday June 15 2015, @02:23PM

          by Marand (1081) on Monday June 15 2015, @02:23PM (#196497) Journal

          And don't write perl unless your context allows you to delete the source code immediately after running the program once.

          I thought it already did that. Are you saying all that gibberish in .pl files isn't bytecode? Well, shit.

      • (Score: 2) by Marand on Monday June 15 2015, @02:31PM

        by Marand (1081) on Monday June 15 2015, @02:31PM (#196502) Journal

        so generally...

        dont write assembler if the context allows you to write c
        dont write c if the context allows you to write c++
        dont write c++ if the context allows you to write java/c#/swift
        dont write java/c#/swift if the context allows you to write perl/ruby/python

        And,finally, don't write in anything else if you can use a lisp dialect instead. :)

        Took me a while to give the lisps a fair shot but once I did I really liked them. Realised I'd been following a lot of functional patterns already in other languages and never even noticed before, so I wish I'd tried sooner.

        • (Score: 2) by kaszz on Tuesday June 16 2015, @06:32PM

          by kaszz (4211) on Tuesday June 16 2015, @06:32PM (#196979) Journal

          How would you say LISP compare to the above stuff?

          • (Score: 4, Informative) by Marand on Thursday June 18 2015, @07:54PM

            by Marand (1081) on Thursday June 18 2015, @07:54PM (#197955) Journal

            I'll try to answer that as best I can, but with the caveat that it's a recent thing I've picked up so I'm still new, and I've mostly used Clojure so that's the perpsective I'll be answering from. (In fact, looking for alternatives to working in Java is what got me to consider lisps again.)

            [Some general info here]
            The biggest difference is the style of programming. Functions always return values, and you're expected to avoid side effects (doing multiple things within a function) when possible (pure functions) for optimisation purposes. There are ways to do multiple things within a function to introduce side effects like IO (making it impure), but the idea is to isolate them so the other functions can be optimised.

            Another difference is that a lisp, at its core, is extremely simple. The language grammar is very basic: everything is basically represented in lists, so (+ 2 3 4 5) is a list where the first element is the function [+] and the next elements are the arguments to the function. This can result in a ton of nested parentheses, but Clojure, at least, provides syntactic sugar to let you reduce the nesting in many cases, which I find makes it more readable. Speaking of syntactic sugar, technically most of a lisp dialect is syntactic sugar. A simple lisp only has a handful of operations implemented specially, and everything else after that gets created in the language itself using compiler macros and new function definitions to simplify common uses. The end user of the language tends to do the same thing, which seems to make larger projects evolve in a way that sort of creates a sub-dialect as they add more and more convenience functions.

            [more specific comparisons follow]
            The end result of all this, from what I've seen so far, is that there's less thinking about the language and more thinking about the problem. It feels more like problem solving than language-wrangling. That alone seems different from dealing with other languages, especially other high-level ones that include everything-and-the-kitchen-sink.

            There is also not a lot of language-mandated boilerplate (unlike, say, Java), though you end up with a lot of application-specific functions, and there's a tendency to re-use suites of functions in a CPAN-esque way, similar to Perl. So, more akin to writing Perl, Python, or Ruby in this way.

            Functions are first-class in the same way objects are first-class in Ruby. You don't need pointers or other workarounds, because you can just assign a function to a name and work with it, and you can even pass functions as arguments to other functions (either anonymous ones, aka lambdas, or named functions). In fact, in Clojure the function definition (defn) is just syntactic sugar; you can get the same behaviour using def to assign an anonymous function to a variable. You can also replace existing functions like this, again like Ruby. These sorts of things are possible to a lesser extent in Python and Perl; you can do a lot of the same things, but with more exceptions in the language.

            Lisps lend themselves well to metaprogramming, too. Unlike most languages, the source code is a correct representation of the syntax tree, which simplifies code generation and modification. A lisp program is data, and can be modified at runtime like other data. This, again, is more on the Python/Perl/Ruby end of the spectrum, but a step further.

            I've also noticed a trend toward more interactive development with lisps. Work within the REPL, or with an editor that can interact with the REPL, and make changes on-the-fly, then save the changes. Clojure even lets you do this with Android applications; during the devleopment process the Android app has a REPL built in (later disabled for release) that you can connect to and make changes to the running android app, so you can create and modify the UI or application logic on a running device and test it real-time.

            ---

            Basically, if you're going for the "highest level of abstraction you can" like fleg suggested, you aren't going to find much higher than a lisp dialect. A lot of things lisps have done, other languages have picked up over time; as other languages attempt to become higher-level and more useful for the user, they move closer to acting like a lisp.

            Another interesting thing is, because the basic requirements for a lisp dialect are so simple, people tend to create lisps on top of other languages, either converting lisp expressions into another language's syntax (lisp-to-lua or lisp-to-javascript converters, for example), or into an equivalent representation in a language's AST (used for Hy [lisp to Python], with Clojure [Lisp to JVM] doing something similar).

            That means if you're familiar with, say, Python, you can use Hy [wikipedia.org] instead to have lisp syntax and flexibility while retaining access to parts of the underlying language, either for familiarity or because that language is powerful, or the only option in an area. For example, this means you can use Clojure to write Android applications. (Runtime speed seems prety good, though there's increased startup time and memory use vs a pure Java implementation.)

            ---

            I hope that helped. I'm not sure if I answered you in a way that's satisfactory, but did the best I can, and I'll keep responding if you have other questions that I can answer in any way.

            • (Score: 2) by kaszz on Thursday June 18 2015, @09:09PM

              by kaszz (4211) on Thursday June 18 2015, @09:09PM (#197984) Journal

              Your answer is great *thumbs up*. What is your experience with functional languages?
              Any good introduction book to Lisp?

              • (Score: 2) by Marand on Friday June 19 2015, @09:26PM

                by Marand (1081) on Friday June 19 2015, @09:26PM (#198438) Journal

                What is your experience with functional languages?

                Lisp (by way of Clojure) is my first experience with a proper functional language. I'd looked at it and Haskell briefly in the past but never considered them seriously for anything because I was happy with Perl (and more recently Ruby) for most things. For what it's worth, I still like Perl and Ruby, but there are a lot of places where they just aren't applicable for use. They're a pain in the ass to use for knocking together useful Android tools, for one big example.

                What got me interested finally was a search for Java alternatives, because everything I tried (such as Scala) still felt like supersets of Java, including the parts I disliked about Java. The closest I got was Mirah, which is a Ruby-like syntax on top of the JVM, but it explicitly avoids providing a runtime as a design decision, so as much as I liked the Mirah-specific parts (syntax mostly), it was just a thin wrapper over the warts of Java, so I started looking again. [for what it's worth, Mirah's nice and worth looking into if you don't mind Java but wouldn't mind a cleaner, more concise syntax to it. No runtime means full-speed Java and small class sizes]

                I finally realised that, with the exception of Ruby's smalltalk-esque design where everything is an object and can be mangled at will, I don't really like OOP for OOP's sake, so I decided to give the "dark side" a try and started looking for info on Clojure.

                It's definitely had a learning curve, because in addition to being functional, Clojure does some slightly odd things to make the language more concurrency-friendly, but I'm finding I like the style. In fact, as I mentioned in one of the other comments, I already did some functional-esque things in Perl code without ever realising it. I always made subroutines return their value, generally (but not always) avoided side effects though I didn't quite realise it, and I loved using anonymous subroutines. I'd stuff them into variables, pass them to other subs, dereference them, etc.

                As it turns out, that's a big part of functional programming, though it's much cleaner and easier in a lisp than it is in Perl, and I'm finding it much more enjoyable than I ever expected, though I'm still fighting with imperative programming habits some, so I'm not as efficient as I'd like to be yet. I'm doing it as a hobby, though, so luckily I don't have to worry about getting efficient fast.

                ---

                Small note about Clojure:

                As lisps go, it seems to be a contentious dialect. It does some unique, new things and there seem to be a lot of hard-liner lisp fans of the primary dialects (Common Lisp and Scheme) taking a bit of an elitist stance against it because of that. For example, you have to use transactions to change variables, in a SQL-esque way, so that variable changes are concurrency-friendly. It makes variables a little weird compared to other languages and has a learning curve to it, but it's just "this is different" rather than "this is good|bad".

                It also provides some nice shorthand tricks like a "threading macro", called ->, that lets you eliminate excess nesting for readability, and I think that annoys some purists as well. Swiping the example from Hy's documentation, you can take a line of lisp such as (loop (print (eval (read)))) and write it instead as (-> (read) (eval) (print) (loop)), which gives it a more natural left-to-right flow. There are a couple similar tricks for Java interop that makes it possible to reduce nesting when calling Java code, too.

                Also, I haven't used it, but there's also a way to turn Clojure into native code by way of the Gambit Scheme compiler. Gambit's a Scheme variant that can create native binaries, and someone made a tool to convert Clojure into valid Gambit Scheme, so the result is Clojure-to-native. Performance looked pretty good, though obviously you won't have access to Java-specific stuff that way, so I don't know what the caveats to this are. Still interesting...

                (There's also a subset of Clojure called ClojureScript that compiles to JavaScript instead of JVM bytecode)

                Any good introduction book to Lisp?

                Well, from a Clojure perspective at least, Pragmatic Bookshelf's Programming Clojure [pragprog.com] and O'Reilly's Clojure Programming [oreilly.com] have been useful. The Pragmatic one is a gentler introduction, though I think the O'Reilly one might be more useful overall. I've been juggling both at the same time. There's also a whimsical online tutorial called Clojure for the Brave and True [braveclojure.com] that I glanced over; I saw recommendations for it, but its style didn't help me much for some reason. Still, worth a look since it costs you nothing and people learn differently.

                Clojure itself is also extremely well documented, and self-documenting. Function definitions can supply docstrings in a Perl- or Ruby-like way and you can access the documentation from the REPL via (doc func-name), including functions you import or define yourself. You can get access to that, and more, from clojure.org's documentation page [clojure.org], which has the (doc) info + examples, a cheat sheet quick-reference for all the Clojure-provided functions, and some reference documentation about the language itself.

                Also useful are various Clojure learning tools like 4Clojure [4clojure.com] and the Clojure koans [clojurekoans.com], which present Clojure code with brief explanations and fill-in-the-blank problems. I didn't find them useful by themselves, but combined with the above sources and searching stackexchange they're helpful.

                If you're interested in the Lisp-on-Python, Hy, then Hy's documentation [readthedocs.org] is probably a good place to start. Haven't messed with it much because I'm more interested in Clojure, though.

                For CommonLisp and Scheme (including Racket, a popular Scheme variant) you should be able to find examples and tutorials all over the internet, because they're the Big Two, and for oddball things like Lisp-to-Lua (l2l [github.com]) the syntax is usually small enough that there isn't much to learn.

                For more general lisp information and learning, I've also been reading through the SICP [github.com] and Paul Graham's On Lisp [yimg.com]. They're older, but more general and available free online. Of the two, I'd say I've liked On Lisp more, though that viewpoint may be a minority -- everyone seems to love SICP. They're helpful in a more abstract way because I'm not working with Common Lisp or Scheme; the function names differ in places but the concepts are the same so there's still something to learn from them.

                ---

                Finally, a note about editors: get an editor that can highlight matching parens, and if possible also colourises paren matches. To see what I mean you can use KDE's editor, kate; it has both options built in, so if you make any sort of lisp file it'll show parens in a rainbow of colours and highlight the match to the one under your cursor. Emacs has the paren highlighting by default (show-paren-mode) and an extension (rainbow-delimiters-mode) to do the same. Not sure about other editors.

                They're not absolutely necessary, but those two things make dealing with the nested functions a lot easier.

                • (Score: 2) by kaszz on Friday June 19 2015, @10:31PM

                  by kaszz (4211) on Friday June 19 2015, @10:31PM (#198470) Journal

                  Thanks again for an interesting answer. The reason for interest in functional languages is that in the beginning they were slow snails and more or less a curiosity on computers. But now there's really fast processors >4 GHz with multiple cores. And definitely the latter property coupled with the ability to use many physical processors on the same motherboard. Should now make functional languages a good match. Perhaps it possible to scale a functional language down to 8- and 16-bit embedded microcontrollers too and allow them to chit chat over an interconnect? Anyway do you think multicore-SMP using functional languages has any bearing?

                  Perl is btw really nice to get things done fast, but it might show its more ugly side effects when a software project gets big. Python seems also nice but has this fascist indentation regime. So is there any other scripting language that is a suitable replacement?

                  • (Score: 2) by Marand on Saturday June 20 2015, @09:45PM

                    by Marand (1081) on Saturday June 20 2015, @09:45PM (#198808) Journal

                    No problem. Since it's still a new area for me the culture shock is still fresh and I haven't forgotten how alien parts of it can be.

                    The reason for interest in functional languages is that in the beginning they were slow snails and more or less a curiosity on computers. But now there's really fast processors >4 GHz with multiple cores.

                    There's also been work to make them faster, much like the sorts of optimisation projects we've seen for Javascript, Python, Ruby, etc. over the years. You can check things like the debian.org benchmark game [debian.org] and see that the performance of Clojure vs. Java in most of the benchmarks is very close, with Clojure even outperforming in one. And that's probably not even using the experimental Skummet [clojure-android.info] compiler.

                    It helps that it's compiled, but it's not just Clojure that's seeing benefits. SBCL (commonlisp) shows similar performance quality, and Haskell's faster than any of them in most of the benchmarks. You're right that the differences would have been a huge problem years ago, but between optimisation and hardware the disparity is small enough that you can shrug and go "good enough" and enjoy a nicer language.

                    On a related note, there's been an increase in interest in so-called transpilers [wikipedia.org] lately that turn one language into another, probably thanks to Javascript being ubiquitous but generally unpleasant to use directly. Things like Emscripten (turns anything that llvm can compile into javascript) or specific language-to-JS converters like ClojureScript (Clojure to JS), Opal (Ruby to JS), etc.

                    Sometimes those converters exist because you want to use a different language but are constrained by what language is available on a platform: Lua gets embedded into game engines, Python's popular with 3d modelers and the like, etc. Other times it's for performance: Crystal [crystal-lang.org] is a Ruby-like language that compiles to native code, as one example.

                    And definitely the latter property coupled with the ability to use many physical processors on the same motherboard. Should now make functional languages a good match. Perhaps it possible to scale a functional language down to 8- and 16-bit embedded microcontrollers too and allow them to chit chat over an interconnect? Anyway do you think multicore-SMP using functional languages has any bearing?

                    Can't say much about scaling down to lesser hardware, it's not an area I have much familiarity; I'm more of the "cobble something together when needed or when it sounds fun" systems programming/sysadmin type guy. Never really had to mess with embedded and tend to hate dealing with GUI stuff, though I've been trying to improve with that.

                    As for the rest, yeah, it seems like functional programming is in a position to shine thanks to the increased focus on multi-core and multi-threaded processors. Unless we hit some kind of epic breakthrough soon that allows massive single-core performance boosts vs. what we have now, more threads are going to be where it's at for performance for at least a while.

                    You still have to do some things differently to make your programs concurrency-friendly, but at least in the case of Clojure, the language itself does a lot to make it easier. Even if you don't explicitly do anything to take advantage of its concurrency you get some benefits out of its design, and it seems like (from my limited experience so far) the options it adds for concurrency aren't a huge cognitive hurdle like they can be in some languages.

                    There's also Erlang, which is sort of the opposite...It's designed for concurrency first, but is closer to functonal programming than imperative too, so I guess that counts as well.

                    Perl is btw really nice to get things done fast, but it might show its more ugly side effects when a software project gets big. Python seems also nice but has this fascist indentation regime. So is there any other scripting language that is a suitable replacement?

                    Of the main three, I think I like Ruby best these days. Perl's faster and CPAN's extensive selection is awesome, but it's also more of a crapshoot getting the modules to work. Ruby's like a cleaner Perl in a lot of ways, and the "gems" system (CPAN-esque) is pretty large and less error-prone. Also, I agree about Python's indentation, but Hy (the lisp-on-python) lets you bypass that and still get the benefits of Python, so that has potential as a way to make Python less onerous to use.

                    So, if a normal lisp isn't an option for some reason, I think I'd give Hy a shot for a project, though I do still like Ruby and Perl for knocking quick stuff together. If installing Hy isn't possible I'd say Ruby over the others. It's clean, easy to read, I like the smalltalk-esque object model, and the style of it works out well if you're familiar with Perl already.

                    An interesting one that isn't well known right now is Red [wikipedia.org]. It's based on Rebol, but has two components. The Red/System part is very fast and sort of low-level, while the higher-level portion is akin to Ruby/Python/Perl in features but slow -- far slower than Ruby, in fact, which is kind of scary and I hope is an optimisation issue to be addressed later. It doesn't quite seem ready for general use right now, but might be interesting if so.

  • (Score: 4, Funny) by fleg on Monday June 15 2015, @03:41AM

    by fleg (128) Subscriber Badge on Monday June 15 2015, @03:41AM (#196346)

    >I hear it's designed to prevent the kinds of bugs that cause crashes and security holes.

    well i cant speak on the security angle but i assure you that i have not noticed any tendency to "prevent the kinds of bugs that cause crashes" ;)