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. On Wed, Jun 11, 2014 at 3:12 PM, Kevin Wright <kev.lee.wri...@gmail.com> wrote: > 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. > > > > On 11 June 2014 21:29, Jess Holle <je...@ptc.com> wrote: > >> 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 >> >> >> On 6/11/2014 2:28 PM, clay wrote: >> >> 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. >> >> >> On Wednesday, June 11, 2014 11:41:38 AM UTC-5, Ricky Clarkson wrote: >>> >>> 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). >>> >>> >>> On Wed, Jun 11, 2014 at 7:45 AM, clay <clayt...@gmail.com> wrote: >>> >>>> >>>> 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. >>>> >>>> >>>> -- >>>> 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. >>>> 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. >>>> >>> >>> -- >> 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+unsubscr...@googlegroups.com. >> To post to this group, send email to javaposse@googlegroups.com. >> Visit this group at http://groups.google.com/group/javaposse. >> For more options, visit https://groups.google.com/d/optout. >> >> >> -- >> 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+unsubscr...@googlegroups.com. >> To post to this group, send email to javaposse@googlegroups.com. >> Visit this group at http://groups.google.com/group/javaposse. >> For more options, visit https://groups.google.com/d/optout. >> > > > > -- > Kevin Wright > mail: kevin.wri...@scalatechnology.com > gtalk / msn : kev.lee.wri...@gmail.com > quora: http://www.quora.com/Kevin-Wright > google+: http://gplus.to/thecoda > <kev.lee.wri...@gmail.com> > twitter: @thecoda > 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 > > -- > 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+unsubscr...@googlegroups.com. > To post to this group, send email to javaposse@googlegroups.com. > Visit this group at http://groups.google.com/group/javaposse. > For more options, visit https://groups.google.com/d/optout. > -- 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+unsubscr...@googlegroups.com. To post to this group, send email to javaposse@googlegroups.com. Visit this group at http://groups.google.com/group/javaposse. For more options, visit https://groups.google.com/d/optout.
