Any thoughts on Swift?

214 views
Skip to first unread message

BoD

unread,
Jun 3, 2014, 1:03:23 PM6/3/14
to java...@googlegroups.com
Yesterday Apple announced the Swift language.
Personally, I've never liked Objective C so it's definitely a step up -
and as a Java developer I have to admit Swift definitely looks good!

Any thoughts, observations, etc.?

--
BoD

Cédric Beust ♔

unread,
Jun 3, 2014, 1:19:31 PM6/3/14
to java...@googlegroups.com
Pretty interesting overall, certainly a more modern language than Objective C. I posted a quick overview on my blog (interesting discussion on reddit at the bottom of the page):



-- 
Cédric





--
BoD

--
You received this message because you are subscribed to the Google Groups "Java Posse" group.
To unsubscribe from this group and stop receiving emails from it, send an email to javaposse+unsubscribe@googlegroups.com.
To post to this group, send email to java...@googlegroups.com.
Visit this group at http://groups.google.com/group/javaposse.
For more options, visit https://groups.google.com/d/optout.

BoD

unread,
Jun 3, 2014, 3:30:48 PM6/3/14
to java...@googlegroups.com
Thanks Cedric this is a nice summary / first look at the language!

I notice the language features something they call "Automatic Reference Counting". Is this the same as a Garbage Collector?

--
BoD

Kevin Wright

unread,
Jun 4, 2014, 4:25:04 AM6/4/14
to java...@googlegroups.com
No, ARC is emphatically *not* garbage collection.  It's not new either, Objectionable-C does it, as does auto_ptr in C++


Though I'm upset that the most popular answer fails to mention the complete lack of features for tackling concurrency!

BoD

unread,
Jun 4, 2014, 11:29:04 AM6/4/14
to java...@googlegroups.com
Ok thanks for this link, interesting stuff there indeed :)
I guess I'll google a bit to see if I can understand the difference between ARC and a GC.

--
BoD
--
You received this message because you are subscribed to the Google Groups "Java Posse" group.
To unsubscribe from this group and stop receiving emails from it, send an email to javaposse+...@googlegroups.com.

Cédric Beust ♔

unread,
Jun 4, 2014, 11:50:37 AM6/4/14
to java...@googlegroups.com

On Wed, Jun 4, 2014 at 1:23 AM, Kevin Wright <kev.lee...@gmail.com> wrote:
Though I'm upset that the most popular answer fails to mention the complete lack of features for tackling concurrency!

I'm unconvinced there is any point to syntactic support for concurrency.

Support concurrency in the runtime/bytecode and the libraries, absolutely. But in the syntax? What does that buy you besides complicating the grammar?

-- 
Cédric


-- 
Cédric

Carl Jokl

unread,
Jun 4, 2014, 11:55:54 AM6/4/14
to java...@googlegroups.com
I wonder about Swift in terms of performance of apps. Traditionally Games companies use C++ for their games engines and on iOS just use the minimum Objective-C to act as the glue to the operating system. For all Objective-C apps then yes Swift will be a big improvement but for those where it was kept to a minimum the difference may not be as dramatic. 

I think it is good that Apple are moving away from Objective-C. Objective-C did feel like a pet project of Steve Jobs and now that he is no longer leading Apple they have the opportunity to replace it with something more modern. It shouldn't be hard for swift to be more modern than Objective-C.

I expect as I will be developing mobile apps for my company I will have the chance to give a first hand verdict of what I think of Swift. To be honest it is kind of nice to think I may manage to dodge having to do so much Objective-C as long as swift is backwards compatible with older versions of iOS. I hope it is.

Carl


--
You received this message because you are subscribed to the Google Groups "Java Posse" group.
To unsubscribe from this group and stop receiving emails from it, send an email to javaposse+...@googlegroups.com.

Josh Berry

unread,
Jun 4, 2014, 12:21:48 PM6/4/14
to javaposse
On Wed, Jun 4, 2014 at 11:55 AM, Carl Jokl <carl...@gmail.com> wrote:
I wonder about Swift in terms of performance of apps. Traditionally Games companies use C++ for their games engines and on iOS just use the minimum Objective-C to act as the glue to the operating system. For all Objective-C apps then yes Swift will be a big improvement but for those where it was kept to a minimum the difference may not be as dramatic.

Pretty sure c/c++ will remain the best cross platform option for a long time.  Whatever promise of Java and related languages as providing cross platform environments, this just never happened.  Closest would actually be .net and friends, I believe.

Even the rise of such interesting projects as the unreal engine in the browser seems to be taking advantage of the fact that the "cross platform" portion is just a c dialect language.

Fabrizio Giudici

unread,
Jun 5, 2014, 6:27:52 AM6/5/14
to java...@googlegroups.com, BoD
On Wed, 04 Jun 2014 17:28:56 +0200, BoD <bodl...@gmail.com> wrote:

> Ok thanks for this link, interesting stuff there indeed :)
> I guess I'll google a bit to see if I can understand the difference
> between ARC and a GC.
>

I'm just catching up with the email and feeds after four days of totally
isolation and I'm still reading Cédric's post... In any case, this ARC vs
GC subject recalls me of the first days with Java. ARC is just a primitive
way to do automatically memory management and it's definitely more limited
than GC. It basically keeps a counter of users of a given object releasing
it when the counter decrements back to zero, so -for instance - pure ARC
can't solve circular references: two objects linking each other will keep
at least a value of 1 on their linked objects, preventing collection.

--
Fabrizio Giudici - Java Architect @ Tidalwave s.a.s.
"We make Java work. Everywhere."
http://tidalwave.it/fabrizio/blog - fabrizio...@tidalwave.it

Jess Holle

unread,
Jun 5, 2014, 10:38:18 AM6/5/14
to java...@googlegroups.com, BoD
With Swift's ARC you have unowned and weak references, which you're
expected to use to resolve such issues.

So the programmer certainly has more responsibility for memory
management -- hopefully with greater speed as a result, else it's just a
universally bad idea.

Fabrizio Giudici

unread,
Jun 5, 2014, 11:00:09 AM6/5/14
to java...@googlegroups.com, BoD, Jess Holle
On Thu, 05 Jun 2014 16:38:11 +0200, Jess Holle <je...@ptc.com> wrote:

> With Swift's ARC you have unowned and weak references, which you're
> expected to use to resolve such issues.
>
> So the programmer certainly has more responsibility for memory
> management -- hopefully with greater speed as a result, else it's just a
> universally bad idea.

How much greater? Because in Java GC is hardly a speed problem nowadays
(unless we're talking of games, which at this age I'm completely unaware
of).

Josh Berry

unread,
Jun 5, 2014, 11:42:13 AM6/5/14
to javaposse
On Thu, Jun 5, 2014 at 10:59 AM, Fabrizio Giudici <Fabrizio...@tidalwave.it> wrote:
How much greater? Because in Java GC is hardly a speed problem nowadays (unless we're talking of games, which at this age I'm completely unaware of).

I think it is less "unless we're talking of games" and more "unless we are talking of somewhat resource constrained devices."  Games are easy to discuss in this context as they are usually attempting to use every resource of their host platform as efficiently as possible.

So, while it is great that memory is getting cheaper and cheaper every day, I am at a loss as to why the twitter app requires upwards of 80megs on my phone.  More, if I can let it.  And that is just twitter.

I am also curious is to how this affects battery life. 

And, of course, I could probably get by with just buying a newer phone.  :)  I've thus far avoided the upgrade cycle of "disposable" electronics.  Just doesn't feel responsible.

-josh

Kevin Wright

unread,
Jun 5, 2014, 12:51:20 PM6/5/14
to java...@googlegroups.com
This one has also been doing the rounds recently:

Jess Holle

unread,
Jun 5, 2014, 12:59:19 PM6/5/14
to java...@googlegroups.com
I also assume ARC requires less memory than GC does for decent performance.

GC is maximally easy for the developer, but conversely assumes a certain wealth of computing resources.

Cédric Beust ♔

unread,
Jun 5, 2014, 1:22:03 PM6/5/14
to java...@googlegroups.com
Funny how everyone wants to claim that Swift was inspired by their ${favorite_language} when the definitive answer is available directly from the presentation:

Inline image 1

C, C++, Objective C, Java, Ruby, Python, Javascript, Perl, Groovy and LUA.

Like I said in my post, I think the language that Swift has the most overlap with is Kotlin, but the language name game is boring, we should just focus on the functionalities that this language supports.


-- 
Cédric



Ricky Clarkson

unread,
Jun 5, 2014, 2:06:06 PM6/5/14
to javaposse

The original source isn't always the most accurate. For instance, the C# specs don't mention Java at all, and the fact that C# is based on Java is really obvious. It does mention C++ a lot though.

Kevin Wright

unread,
Jun 5, 2014, 2:14:27 PM6/5/14
to java...@googlegroups.com
"everyone wants to claim that Swift was inspired by their ${favorite_language}"

Not so.  My *favourite* language is probably Idris!
But I'm a pragmatic kinda guy, so yes, I favour Scala for commercial work at the moment.
--
Kevin Wright
mail: kevin....@scalatechnology.com
gtalk / msn : kev.lee...@gmail.com
vibe / skype: kev.lee.wright
steam: kev_lee_wright

"My point today is that, if we wish to count lines of code, we should not regard them as "lines produced" but as "lines spent": the current conventional wisdom is so foolish as to book that count on the wrong side of the ledger" ~ Dijkstra

shellac

unread,
Jun 6, 2014, 6:46:20 AM6/6/14
to java...@googlegroups.com, ced...@beust.com
On 05/06/14 18:21, Cédric Beust ♔ wrote:
Funny how everyone wants to claim that Swift was inspired by their
${favorite_language} when the definitive answer is available directly
from the presentation:

Inline image 1

C, C++, Objective C, Java, Ruby, Python, Javascript, Perl, Groovy and LUA.
I raise your definitive answer with:

"...drawing ideas from Objective-C, Rust, Haskell, Ruby, Python, C#,
CLU, and far too many others to list." [1]

(More seriously it's very clearly part of a generation of OO languages
that have picked up tricks from ML and Haskell -- start java-ish, favour
optional / maybe over null, enum / either, switch / match pattern
matching with destructuring).

Damian

[1] <http://nondot.org/sabre/>

Cédric Beust ♔

unread,
Jun 6, 2014, 12:20:27 PM6/6/14
to shellac, java...@googlegroups.com
I find all these "inspired by" conjectures a bit vapid, but just to play along, I would argue that Swift belongs in the generation of languages sparked by C and C++, with which it has much more in common than with Haskell and ML languages.

To me, Swift seems to validate the "pendulum in the middle" approach that we started seeing with Ceylon and Kotlin. Java looks fairly primitive today (pendulum left), Scala is reasonably advanced and pioneered a lot of interesting features in that family of languages (pendulum right) and Ceylon/Kotlin/Swift advocate a middle ground approach that takes the best of both extremes (pendulum in the middle).

-- 
Cédric


-- 
Cédric

Kevin Wright

unread,
Jun 6, 2014, 12:49:22 PM6/6/14
to java...@googlegroups.com, shellac
In the interests of playing Devil's advocate here, there's a very convincing argument to be made here for "the middle" not being the best at all:

Courtesy of Erik Meijer:

Cédric Beust ♔

unread,
Jun 6, 2014, 1:01:21 PM6/6/14
to java...@googlegroups.com, shellac
So you're arguing for the Java approach then?



-- 
Cédric



Kevin Wright

unread,
Jun 6, 2014, 1:31:34 PM6/6/14
to java...@googlegroups.com, shellac
Nope!

C or Idris, I'll also accept Assembler.

and Scala's the least bad you can get if otherwise tied to the JVM. :)

clay

unread,
Jun 10, 2014, 7:12:45 PM6/10/14
to java...@googlegroups.com
On Wednesday, June 4, 2014 11:21:48 AM UTC-5, Josh Berry wrote:
Pretty sure c/c++ will remain the best cross platform option for a long time.  Whatever promise of Java and related languages as providing cross platform environments, this just never happened.  Closest would actually be .net and friends, I believe.

The Java cross platform model targets Win/Mac/Linux workstations and it does that extremely well. It's not just cross platform, but largely write once, run anywhere, where same compiled .jar file can run on Win/Mac/Linux.

What Java doesn't do is target game consoles at all. Technically it's possible, but it's not a practical reality for end developers at the moment. Java/JVM->iOS is limited, although lots of games use RoboVM for this. And Android uses Java, but the API is completely separate from other platforms, so there is no write once type code sharing.

Most high-level languages are extremely cross platform. Lua, for example, is extremely cross platform and is often used on top of a C-based game engine.

Most of .NET's cross platform success is through the Unity game engine, which is mostly written in C, but uses Mono/C# for scripting like other games use Lua or UnrealScript. They also have MonoGame and tools for making Android/iOS apps in C# using largely platform native APIs which prohibits any type of write once code sharing.

Many languages like Haskell, usually just compile down to C, so I don't see why those would be less cross platform friendly. 

Josh Berry

unread,
Jun 10, 2014, 10:47:13 PM6/10/14
to javaposse
On Tue, Jun 10, 2014 at 7:12 PM, clay <clayt...@gmail.com> wrote:
On Wednesday, June 4, 2014 11:21:48 AM UTC-5, Josh Berry wrote:
Pretty sure c/c++ will remain the best cross platform option for a long time.  Whatever promise of Java and related languages as providing cross platform environments, this just never happened.  Closest would actually be .net and friends, I believe.

The Java cross platform model targets Win/Mac/Linux workstations and it does that extremely well. It's not just cross platform, but largely write once, run anywhere, where same compiled .jar file can run on Win/Mac/Linux.

Apologies, I was a definitely too absolute in my claim.  I was more just going on admittedly anecdotal evidence that most truly cross platform applications that aren't a) ugly, or b) dog slow are not written in Java and related languages.  I'm definitely open to counters.

But, once you get that list made, compare it to the number of applications that are heavily used in many platforms and the language they used.  From the Kernel, which is on near everything, to browsers.  Mozilla is at least making a stab with a new language that will compete with C/C++.  It isn't clear this will win, though.

 
Most high-level languages are extremely cross platform. Lua, for example, is extremely cross platform and is often used on top of a C-based game engine.

Lua doesn't try to be "the language" that you write your application in, though.  Or does it nowdays?  Last I saw, it was picked specifically because it was easy to embed in a C program.

 

Many languages like Haskell, usually just compile down to C, so I don't see why those would be less cross platform friendly. 

I want to agree with you, but I would prefer evidence.   :)


Also, and I apologize if this is basically goal post shifting, but when I refer to cross platform, I don't necessarily mean just linux/mac/windows.  I mean something that can run on the raspberry pi, or aduino, or *any* phone/tablet/whatever.  Obviously, not just any C program can be made to fit this bill.  But, to my knowledge, no Java program can.  (Of course, maybe Angry Birds is all it takes to prove me wrong.  Or Scumm games, in general.  :) )

clay

unread,
Jun 11, 2014, 10:23:21 AM6/11/14
to java...@googlegroups.com


On Tuesday, June 10, 2014 9:47:13 PM UTC-5, Josh Berry wrote:
Apologies, I was a definitely too absolute in my claim.  I was more just going on admittedly anecdotal evidence that most truly cross platform applications that aren't a) ugly, or b) dog slow are not written in Java and related languages.  I'm definitely open to counters.

But, once you get that list made, compare it to the number of applications that are heavily used in many platforms and the language they used.  From the Kernel, which is on near everything, to browsers.  Mozilla is at least making a stab with a new language that will compete with C/C++.  It isn't clear this will win, though.


When you say Java apps are "slow", "ugly" and not "heavily used", you are talking about apps like web browsers, chat clients, shell terminals, and media player apps: Java isn't the best fit for that.

At university, I used lots of Windows only apps like PSpice for simulating electric circuits, and CAD desktop apps, and various instrumentation desktop applications: they weren't cross platform, and the GUIs were extremely ugly, wonky, glitchy. Java would be a better fit if those tools were ever rewritten.

I worked for a company that made CAE desktop application software. Their GUIs were either Tcl/Tk or based in Windows only C++ MFC and used some porting technology: Java would have been radically easier to develop, looked better, and ran faster for end users.

IDEs are often the standard example of where Java GUI is an appropriate dev tool. They aren't unusually ugly and the slowness is a direct result of their functionality, not the GUI technology.

Some guys I work with do graph data analysis, and use many tools including a visualization tool called GePhi that is written in Java: it's a very appropriate GUI technology. The GUI is nice, pleasant, and responsive, and we have people using it flawlessly on Mac/Linux/Windows.
 
Also, and I apologize if this is basically goal post shifting, but when I refer to cross platform, I don't necessarily mean just linux/mac/windows.  I mean something that can run on the raspberry pi, or aduino, or *any* phone/tablet/whatever.  Obviously, not just any C program can be made to fit this bill.  But, to my knowledge, no Java program can.  (Of course, maybe Angry Birds is all it takes to prove me wrong.  Or Scumm games, in general.  :) )

Sure, lots of people want phones, Raspberry Pi, etc beyond workstation OS. People do have Java apps including JavaFX running on iPhone and Rasberry Pi, although it may not be the best option. People have Java games using libgdx running from mostly one source code base on iOS and Android and Win/Mac/Linux


clay

unread,
Jun 11, 2014, 10:45:24 AM6/11/14
to java...@googlegroups.com, pldms+...@mac.com

On Friday, June 6, 2014 12:31:34 PM UTC-5, KWright wrote:
Nope!

C or Idris, I'll also accept Assembler.

and Scala's the least bad you can get if otherwise tied to the JVM. :)

I completely understand why you prefer Idris/Haskell over Scala and Scala over Java.

But why on Earth would you also prefer C? That seems to go the opposite direction and be a big step down from Java?

All the things Scala fixes from Java are broken in C as well: if expressions, for/monad comprehensions, focus on immutability, pervasive type inference, cleaned up generics, array syntax that is unified with generics (Array[Type] rather than Type[]), language level currying and partial functions, overridable var/val and ideal property system, singleton objects instead of static.

And C/C++ is worse than Java: #define/#include, header files, __declspec, library dependency system is a wreck, ABI issues across binaries, hairy legacy issues that are far worse than Java, wildly varying implementations of the "standard", super complex networking/threading/file apis that make the Java standard library a work of art. Did you ever use COM/ActiveX? Have you ever worked with international strings in C? It's a major pain, it's wildly non-standard between different compiler vendors, and makes every other language ridiculously elegant in comparison.

Programmers often hate the tool they use for work, because they have to deal with lots of legacy code and annoying coworkers with conflicting styles. When they use another language/tool on the side, they can do everything exactly how they want, so the other tool seems better. If you had to deal with large amounts of typical legacy business C code, I expect you would appreciate Java a lot more. And if you used Idris for work with tons of legacy code and annoying coworkers, it would be better because Idris/Haskell are so strict about enforcing certain conventions, but it still wouldn't be ideal.

 

Josh Berry

unread,
Jun 11, 2014, 11:25:41 AM6/11/14
to javaposse
On Wed, Jun 11, 2014 at 10:23 AM, clay <clayt...@gmail.com> wrote:


On Tuesday, June 10, 2014 9:47:13 PM UTC-5, Josh Berry wrote:
Apologies, I was a definitely too absolute in my claim.  I was more just going on admittedly anecdotal evidence that most truly cross platform applications that aren't a) ugly, or b) dog slow are not written in Java and related languages.  I'm definitely open to counters.

But, once you get that list made, compare it to the number of applications that are heavily used in many platforms and the language they used.  From the Kernel, which is on near everything, to browsers.  Mozilla is at least making a stab with a new language that will compete with C/C++.  It isn't clear this will win, though.


When you say Java apps are "slow", "ugly" and not "heavily used", you are talking about apps like web browsers, chat clients, shell terminals, and media player apps: Java isn't the best fit for that.


Isn't this just restating my point, in some respects?  There are some niches where Java works really well.  It probably *could* work better than it gets credit for cross platform development.  Especially in a world of lots of resources.  However, by and large, it just hasn't.  Any of the cases that are pointed out are often perfect fits for "the exception proves the rule."

 
At university, I used lots of Windows only apps like PSpice for simulating electric circuits, and CAD desktop apps, and various instrumentation desktop applications: they weren't cross platform, and the GUIs were extremely ugly, wonky, glitchy. Java would be a better fit if those tools were ever rewritten.

I worked for a company that made CAE desktop application software. Their GUIs were either Tcl/Tk or based in Windows only C++ MFC and used some porting technology: Java would have been radically easier to develop, looked better, and ran faster for end users.

These are convenient assertions, but again, I would like evidence.  Especially since I've heard nothing but good things for Tcl/Tk. 

 

IDEs are often the standard example of where Java GUI is an appropriate dev tool. They aren't unusually ugly and the slowness is a direct result of their functionality, not the GUI technology.

IDEs are an interesting bag, though.  Eclipse had to invent their own toolkit to come  close to making it work.  And, I have not heard anyone praise any of the main IDEs for looks in a long time.  IDEA comes close, yet they are almost a definite exception to this rule.  Just as Minecraft stands up as the definitive (and nearly only) java game worth talking about.  (There is also the fact that it seems only java IDEs are written in java.)
 
 
Some guys I work with do graph data analysis, and use many tools including a visualization tool called GePhi that is written in Java: it's a very appropriate GUI technology. The GUI is nice, pleasant, and responsive, and we have people using it flawlessly on Mac/Linux/Windows.
 

I'll have to take a look.  Sounds nice.

 
Also, and I apologize if this is basically goal post shifting, but when I refer to cross platform, I don't necessarily mean just linux/mac/windows.  I mean something that can run on the raspberry pi, or aduino, or *any* phone/tablet/whatever.  Obviously, not just any C program can be made to fit this bill.  But, to my knowledge, no Java program can.  (Of course, maybe Angry Birds is all it takes to prove me wrong.  Or Scumm games, in general.  :) )

Sure, lots of people want phones, Raspberry Pi, etc beyond workstation OS. People do have Java apps including JavaFX running on iPhone and Rasberry Pi, although it may not be the best option. People have Java games using libgdx running from mostly one source code base on iOS and Android and Win/Mac/Linux


I am still not seeing much to dissuade me of the believe that Java just isn't that good for this.   Can it be done?  I mean, obviously in a turing complete sense of the word, yes.  Does it truly make things easier?  I'm not convinced.  Evidence seems to show it doesn't.


Don't get me wrong.  I still agree that it *should*.  I'm just saying it has far from lived up to that promise.  To the point that I don't even see it touted much anymore.

Ricky Clarkson

unread,
Jun 11, 2014, 12:41:38 PM6/11/14
to javaposse, pldms+...@mac.com
I'm not saying I agree, but there are reasons.  C works.  You aren't going to get a compiler segfault, then discover a debugger bug while trying to debug the compiler, then fix that only to find that your build tool doesn't work when your path contains spaces, and then find that you can't read MP3 files without an extra library that hasn't been maintained since the big bang, etc.  If you need to write your own C compiler for any reason, nobody is going to sue you.

C will still exist when Objective-C, PHP, ASP, VB, Perl, Python, Ruby and probably C# and Java, have all bitten the dust, because it *actually* works everywhere and is kind of a base on which pretty much everything else can be built without incurring 'the VM cost', however imaginary or real that cost may be.

It's also almost one of *the* bases, barring the 100s of special cases it is a really simple language, kind of fundamental the same way Scheme, Smalltalk and Forth are (i.e., hard to reduce further without losing real capability).


--

Fabrizio Giudici

unread,
Jun 11, 2014, 12:45:55 PM6/11/14
to javaposse, Josh Berry
On Wed, 11 Jun 2014 17:25:15 +0200, Josh Berry <tae...@gmail.com> wrote:

> IDEs are an interesting bag, though. Eclipse had to invent their own
> toolkit to come close to making it work. And, I have not heard anyone

True, but this happened ages ago. In the meantime, native Java UIs are ok
today.

But weren't we talking about a *language*?

clay

unread,
Jun 11, 2014, 3:28:49 PM6/11/14
to java...@googlegroups.com, pldms+...@mac.com
Your reasons for preferring C are stability and long term longevity? 

Are those factors really that important? If a language only lasts 40 years rather than 100 or 1000 years, do you actually care? Like in a roaches will outlast human kind sort of way? Is stability the big thing holding you back from Java or C#? For all the legitimate gripes about Java/C#, basic stability and compiler crashes generally are not among them.

Secondly, that isn't consistent with your preference of Scala on the JVM and Idris off the JVM. I find it hard to believe that Scala+Idris have better stability than Java and will be around longer than Java. I prefer Scala over Java for the advanced elegance, conciseness, and expression, but IMO, Scala has been a buggier language than Java, it's less serious about backward compatibility, and it probably won't last as many decades into the future as a legacy technology as Java will.

Other tools might not have "the VM cost", but they all have some performance profile that can be quantified and logically compared. Java often does fairly well in those tests.

Ricky Clarkson

unread,
Jun 11, 2014, 4:19:05 PM6/11/14
to javaposse, pldms+...@mac.com
Holy moly. I was explaining (my interpretation of) Kevin's assertion that he'd go for C. I even started with "I'm not saying I agree". I don't really have a strong opinion, but I'm not going to pre-judge a group who has developed in C for the reasons I gave. C++, sure, I'll pre-judge you if you're using that. :)

Jess Holle

unread,
Jun 11, 2014, 4:30:05 PM6/11/14
to java...@googlegroups.com, pldms+...@mac.com
C is essentially the recognized, practical "high-level portable assembler" language.  It's the closest thing to assembler that allows production of portable source code that has been proven to work for developing a huge range of software (drivers, operating systems, embedded control, servers, desktop applications, etc...) for a huge range of hardware and operating systems.

C is essentially never "too big" or "too slow".  Combined with its huge mindshare it seems almost permanently ensconced as the "almost bare metal" tool.  Sure something will likely dethrone it someday -- but I'd not bet on that day being soon.

On the other hand, is C truly a high enough language for effective development of some of the world's biggest applications?  Not really.  Is it really the most effective tool for developing smaller applications that don't really have to be "to the metal"?  Arguably not.  As such C will frequently be passed over for many of these sorts of projects (at the very least by C++, but often by Java, C#, and a long list of languages).

--
Jess Holle

Kevin Wright

unread,
Jun 11, 2014, 6:12:27 PM6/11/14
to java...@googlegroups.com, pldms+...@mac.com
Yes.  Exactly what Jess said!

With the best will in the world, I'd never even consider writing e.g. a device driver in Scala.  Nor code for an embedded device with tightly constrained resources.

C is small, well-defined, and can produce some incredibly tiny executables.  It focuses tightly on what it does well.

I also like Go for systems work, and Rust - or at least I would if it settled down a bit more.



Swift is the opposite.  It's very much an applications language.  We played with it at the Posse roundup today :)

In many ways, it really does look too much like Scala to be mere coincidence.  We also discovered that:
- The Xcode beta is a *big* download, took us almost an hour
- You must be a paid-up Apple dev to get it
- The lack of flatMap on arrays and Optional is a gross oversight
- We couldn't implement flatMap ourselves either, as it seems you can extend an Array, but we couldn't find a way to get at the generic type information
- There's no way to catch exceptions

Overall, it felt (to me) very much like a work-in-progress.

Ricky Clarkson

unread,
Jun 11, 2014, 6:37:51 PM6/11/14
to javaposse, Shellac Plumpton
I was looking into xcode 6 last night, the bit about being a paid-up developer is right, but apparently only while it's in beta.

So Kevin, are you the English guy with the strong regional accent on the roundups? I can't remember which accent, Newcastle or Cornwall or something.

Kevin Wright

unread,
Jun 11, 2014, 6:51:27 PM6/11/14
to java...@googlegroups.com

The English guy you're probably thinking of is Peter Pilgrim. This is my (and London's) first roundup.

It'll appear on the podcast sooner or later. We have video too!

clay

unread,
Jun 12, 2014, 2:01:46 PM6/12/14
to java...@googlegroups.com, pldms+...@mac.com

On Wednesday, June 11, 2014 5:12:27 PM UTC-5, KWright wrote:

With the best will in the world, I'd never even consider writing e.g. a device driver in Scala.  Nor code for an embedded device with tightly constrained resources.

I would never consider using any language for a task completely outside it's zone of relevance.

That goes without saying.

Reply all
Reply to author
Forward
0 new messages