ankhmoop

You're technically correct in regards to Mach, but in the context of Mac OS X a very large percentage of the kernel is composed of BSD-derived code.

Unfortunately, none of this is particularly relevant to clang, as the kernel design (in respect to Mach or BSD) really has little bearing on its compiliability.

[Edit]

I'm very surprised that this was downvoted to 0. The discussion was in context of Mac OS X, and the technical veracity is easily confirmed:

http://en.wikipedia.org/wiki/Xnu http://fxr.watson.org/fxr/source/bsd/?v=xnu-1228

The capacity for a specific purpose is not demonstrative of an aptitude for that purpose.

Can you elaborate on where you're seeing the most bottlenecks in your performance profiling? I'd be very curious to hear what sort of performance issues a site like github runs into.

The plane isn't pressurized, and often, the cabin has no door at all -- you are free to step right out of the aircraft. The maximum altitude is kept below 12-15k ft -- above that, a jump would require special breathing equipment for the dive.

Some planes do have closing doors -- for instance, rear-loading cargo planes. Those are the most fun to jump out of, since you can take a running James Bond-style leap out the back of the airplane.

I much prefer Sparkle's approach of opt-in, in-application updates, and I sincerely hope that Mac application developers will not adopt Omaha.

http://sparkle.andymatuschak.org/

sqlite also provides sqlite3_busy_timeout() and sqlite3_busy_handler() to customize its contention handling behavior.

http://www.sqlite.org/c3ref/busy_timeout.html http://www.sqlite.org/c3ref/busy_handler.html

"Multi-objective optimization (or programming),[1][2] also known as multi-criteria or multi-attribute optimization, is the process of simultaneously optimizing two or more conflicting objectives subject to certain constraints."

Note "conflicting objectives". Why do you believe the objectives are conflicting?

I rate three across the board, which simply implies to me that the author of the chart had similar interests and focus.

The management modules are often considerably more powerful than what is necessarily exposed via IPMI -- A number of SuperMicro's IPMI modules have more than a few megabytes of flash, and do run an embedded version of Linux.

The module's capabilities are not all that different from OpenWRT; they run Linux, have a network connection, provide a web UI including a 'VNC' server for the VGA console, run (IIRC) net-snmp ...

If I wanted to obscure my intentions, I definitely would leverage such non-obvious embedded systems.

Our servers actually have a full embedded ARM Linux installation to support IPMI[1]. It has a separate processor, power management, flash storage, et al, and operates independently of the installed OS. The onboard IPMI module runs as long as the machine is connected to a power source.

The card can be re-flashed from the running OS, and actually runs a number of open source network daemons with known vulnerabilities.

It can interact with the BIOS, provide network access to the console, access the network via the host's ethernet chipset, supply the OS with pseudo-disk devices (CD-ROM, floppy) ...

[1] http://en.wikipedia.org/wiki/Intelligent_Platform_Management...

The irresponsibility of the general population is such that I am alarmed by a significant increase in gun ownership, irrespective of my belief in the right to bear arms.

Additionally, gun collecting is demonstrative of collecting behavior, rather than treatment of the gun as purely a tool. Guns, especially given their purpose as tools, are simply not collectible totems.

A well-designed type system reduces the number of tests needed by allowing the programmer to enforce correctness through the type system itself.

Then your knowledge may be too constrained to derive sufficiently representative generalizations.

I can highly recommend:

http://www.xoltar.org/old_site/misc/static_typing_eckel.html...

The article (from 2003!) is an excellent treatise on the value of a proper type system as compared to Python, and moreover, how Java's type system (or C++, ...) should simply not be equated with "static typing".

It's a surprisingly common fallacy to equate Java with Type Systems.

Type systems can be far more expressive than what is available in Java, and can and should be used to enforce program correctness, reducing the necessity for additional testing.

Type inference, polymorphic typing, structural types -- the available tools in a comprehensive type system are woefully under-explored by most practitioners who consider Java to epitomize type systems.

"Being good at all three may be possible, but being optimal at all three is probably impossible."

Why?

Beggars in Spain is an interesting treatment of that idea:

http://www.amazon.com/Beggars-Spain-Trilogy-Nancy-Kress/dp/0...

What technical limitation prevents a language from being fast, easy to use, and well designed? Alex seems to argue that Scala is 'fast, good, and easy', and I would tend to concur.

What I've seen of C# 3.0 and F# also implies that those languages could meet this criteria, but my experience with them is limited.

Obie's appeal to emotion while flying the flag of rationality does us all an intellectual disservice. The article contains many accusations, but few reasoned arguments to support them, and could not be any more antithetical to Alex Payne's appeal for calm, reasoned discussion.

"Alex is indeed scapegoating Ruby for Twitter's shitty legacy codebase"

"... frankly the timing of his essay made me throw up a little in my mouth. The nausea only grew this morning when I checked on how much it's being re-tweeted."

A false dilemma.

JRuby is not a 1:1 mapping of a Ruby to Java bytecode -- there's significant additional book-keeping that must be done by JRuby's runtime (for example, maintaining the Ruby call frames).

In contrast, Scala maps to the JVM as closely as possible. Scala classes are Java classes -- Scala and Java are bidirectionally interoperable, and Scala's performance subsequently benefits.

I do not believe that forthright explanations of genuinely complex topics can ever be a disservice to users -- accurate and complete information is critical to "make[ing] the right choices".

The suggestion to provide patches is a simple displacement mechanism. A correct, reasoned evaluation is not predicated on also including patches, and a reasoned evaluator may have significant cause to not invest further effort in providing improvements to the evaluated software.

The regular expression engine and large number support are simply not broadly representative of Ruby performance, and do little to refute empirical observations of properly representative benchmarks and the many educated critiques of Ruby's implementation.

Your final example of development time is wholly unrelated to runtime implementation performance, and its use as a justification to assuage cognitive dissonance is predicated on a false dilemma -- that a language can not both support rapid development and a well performing runtime.

It is not necessary to introduce a false dilemma to justify an individual preference for Ruby development, in spite of its measured performance.

"One comment that seemed particularly uncontroversial to me was at the core of this nerd firestorm: Ruby is slow. For the next several days, I could think of only one thing: why is something you can measure controversial?"

This is exactly what needed to be said, and repeated until it is fully and widely understood. Cognitive dissonance should not be assuaged at the cost of the rational and empirical.

This (and the rest of the article) is just ignorant cheerleading — an attempt to justify the lackings of the author's chosen technology, and thus resolve cognitive dissonance.

Why is it "over-optimization" to use language with a genuinely well-implemented runtime?

One way to do this in Scala:

  def print[T] (value:T) = System.out.println(value)
  1.until(10).foreach(x => print x)

This is a fairly uninteresting example, however. Something more interesting would be, for instance, the use of structural types to implement type-checked duck typing.

Scala example:

  // Declare a structural type for any class implementing close()
  type Closable = {def close(): Any}
  
  // Executes the provided function with the given
  // closable generator, creating a new instance which
  // will then be closed on completion. The provided
  // function's value will be returned.
  def withClosable[T, C <: Closable] (c: => C) (f: (C) => T) = {
    val closable = c
    try {
      f(closable)
    } finally {
      closable.close
    }
  }
  
  // Example usage
  def usage = {
    val updated = withClosable(db.openConnection) { conn =>
      conn.update("INSERT INTO example VALUES (...")
    }
    System.out.println("Rows updated: " + updated)
  }

This could be compared with Python's new 'with' syntax.

Hopefully a user of C# will chime in -- I've spent very little time with it, and only recently evaluated C#'s extension mechanism for the purpose of comparing it against other language's implementations.

That said, elegant and concise syntax does not require eschewing an internally consistent, fully specified type system -- the two are not incompatible, as demonstrated (subjectively) -- by many existing FP languages. I argue that elegance/conciseness requires either FP language features and advanced type system, or abandonment of rigorous typing.

How can one effectively argue against an entirely subjective judgment of difficulty in terms of dealing with a type system?

Anecdotally, I find that leveraging functional language programming features coupled with type inference and polymorphism leads to considerable productivity gains as code correctness can be ensured through judicious use of types -- without requiring extensive testing or programmer effort -- while excess verbosity can be eliminated through the use of FP features such as type-safe anonymous functions, currying, etc.

As noted in Werner Schuster's article, many languages (such as C# or Scala) do support type-safe, non-ambiguous, non-conflicting extension of existing classes, demonstrating that extension of existing classes can be safely implemented and does not require the use of dangerous monkey-patching.

The author claims that monkey-patching private methods to expose them publicly is representative of Ruby's beauty, and specifically:

"... later upgrades to the library don’t need to be re-fixed: the one-time patch will automatically get re-applied by application code automatically!"

Anyone who fails to realize how monkey-patching can and will break both subtly and catastrophically across library upgrades has no business advising anyone regarding language choices.

[Edit] I hate April Fool's Day. Depressingly, the author's satire is so subtly aligned with common arguments as to so thoroughly fool.