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 <[email protected]> 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 <[email protected]> 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 [email protected]. >>> To post to this group, send email to [email protected]. >>> 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 [email protected]. > To post to this group, send email to [email protected]. > 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 [email protected]. > To post to this group, send email to [email protected]. > Visit this group at http://groups.google.com/group/javaposse. > For more options, visit https://groups.google.com/d/optout. > -- Kevin Wright mail: [email protected] gtalk / msn : [email protected] quora: http://www.quora.com/Kevin-Wright google+: http://gplus.to/thecoda <[email protected]> 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 [email protected]. To post to this group, send email to [email protected]. Visit this group at http://groups.google.com/group/javaposse. For more options, visit https://groups.google.com/d/optout.
