Re: REST impact paper

Okay, point granted.  While there are commercial packages that are 
optimized in a performance tuning way, there exists multiple ways to 
optimize a program.  Optimizing for "what" is the key--and I think I 
meant optimized for elegance (in the information theory sense of hte 
word), maintainability and ability to understand.

I based that on my long ago experience with visiting and advising 
aerospace companies on their software architectures and code where 
portions of the code were written once and never revisited versus open 
source where modules are constantly being improved.  You would be right 
to point out that my experience is grounded in the state of the industry 
over 20 years ago.

Greg


On 9/8/2017 8:42 PM, J. Andrew Rogers wrote:
> 
>> On Sep 8, 2017, at 6:30 PM, Greg Bolcer <[email protected]> wrote:
>>
>> While I completely understand where you are coming from and agree in some small way at the edges, I strongly disagree about the state of open source.  The packages I use are politics free, well tested, widely reviewed,
> 
> 
> I agree with the above.
> 
> 
>> and optimized as all hell in ways that are better than any proprietary code.
> 
> 
> This is simply false, there is no evidence to support it. Properly designed code is typically 10-100x higher throughput and efficiency than open source, virtually across the board. Open source doesn’t prioritize it. I’ve made a living demonstrating this across most parts of the tool chain, often with code bases that are smaller than the open source they replace. Open source software is atrociously inefficient. This is its Achilles’ Heel. There are exceptions in open source, like compilers, but they are rare.
> 
> Which isn’t to say there isn’t terrible closed source code, just that some proprietary code vastly out-performs open code in most cases.
> 
> An easily verifiable example is that open source databases don't implement an I/O scheduler; virtually every closed source database of note has for a long time. The difference in throughput is 2-5x depending on the details, assuming all else is equal (it's not). You can demonstrate the same kinds of things in several places across every part of the software stack. Open source ignores mountains of low hanging fruit, and the open source contributors frequently lack the domain expertise to recognize many other optimizations that are not in the literature.
> 
> No one wants to hear it but I’ve been beating this drum for a long time. If open source wants to remain relevant, it cannot have the abysmal efficiency it currently has. Unfortunately, it is really, really poorly optimized from top to bottom in most cases. Anecdotally, the only open source software my teams use that hasn’t been superseded by vastly better closed source is LLVM. Everything from JSON parsing to computational geometry to database engines, on the other hand, migrated to proprietary implementations. And the difference in optimization isn’t even close. Open source communities are typically hostile to a wholesale overhaul of fundamentally broken architecture.
> 
> Open source software has many positive properties, but performance, throughput, and efficiency are not remotely among them. Arbitraging this is a cloud company business model.
> 
> 
> 
> _______________________________________________
> FoRK mailing list
> http://xent.com/mailman/listinfo/fork
> 
_______________________________________________
FoRK mailing list
http://xent.com/mailman/listinfo/fork