Comments on: Building a Solution Instead of a New Problem http://jungleg.com/2009/03/05/building-a-solution-instead-of-a-new-problem/ Life is a Startup Wed, 08 Feb 2012 07:46:41 +0000 hourly 1 http://wordpress.org/?v=3.2.1 By: Steve Yakoban http://jungleg.com/2009/03/05/building-a-solution-instead-of-a-new-problem/comment-page-1/#comment-817 Steve Yakoban Sat, 28 Mar 2009 04:48:57 +0000 http://jungleg.com/?p=327#comment-817 Well... I'm not a programmer but I've run a number of software projects. In the early 2000's we did a lot of "multimedia" applications using Macromedia Director. There were often issues with memory leakage and conventions that needed to be used to clear the issue. In a sense, it can be considered a platform in the way something like Ruby is now. I know, I know, not the same thing. As machines got bigger and faster, bloatware (what's that company in Redmond?) was able to hide in machine capability and escape scrutiny. Either machines will be powerful enough to overcome the inherent application slop and those in the know will be annoyed but look the other way, or a frameworks 2.0 mentality will evolve and the frameworks will have tools to clean up shoddy coding. We'll see! Well… I’m not a programmer but I’ve run a number of software projects. In the early 2000′s we did a lot of “multimedia” applications using Macromedia Director. There were often issues with memory leakage and conventions that needed to be used to clear the issue. In a sense, it can be considered a platform in the way something like Ruby is now. I know, I know, not the same thing.

As machines got bigger and faster, bloatware (what’s that company in Redmond?) was able to hide in machine capability and escape scrutiny. Either machines will be powerful enough to overcome the inherent application slop and those in the know will be annoyed but look the other way, or a frameworks 2.0 mentality will evolve and the frameworks will have tools to clean up shoddy coding.

We’ll see!

]]> By: Mike Johnston http://jungleg.com/2009/03/05/building-a-solution-instead-of-a-new-problem/comment-page-1/#comment-587 Mike Johnston Tue, 10 Mar 2009 23:15:31 +0000 http://jungleg.com/?p=327#comment-587 I agree that frameworks are here to stay, and I welcome the time efficiencies they create. It really is now possible to develop and deploy web apps very rapidly - but at an extreme cost machine resources: most appallingly memory and CPU. I'm not sure what the answer to this is. I have no desire to go back to my days of writing bare-metal machine code, but it seems something has been lost in the last several decades. Languages and frameworks are abstractions often built upon earlier abstractions, which tend to multiply the inefficiencies of lower layers, and further distancing those who build systems from the heart of the machine. In short, there are too many layers and too few people who understand them or that they even exist at all. I think your point is that scalability and performance suffer, and I have to say that I absolutely agree. The number of people I've worked with who fully understand and internalize those last two points when designing systems are few. I agree that frameworks are here to stay, and I welcome the time efficiencies they create. It really is now possible to develop and deploy web apps very rapidly – but at an extreme cost machine resources: most appallingly memory and CPU.

I’m not sure what the answer to this is. I have no desire to go back to my days of writing bare-metal machine code, but it seems something has been lost in the last several decades. Languages and frameworks are abstractions often built upon earlier abstractions, which tend to multiply the inefficiencies of lower layers, and further distancing those who build systems from the heart of the machine. In short, there are too many layers and too few people who understand them or that they even exist at all.

I think your point is that scalability and performance suffer, and I have to say that I absolutely agree. The number of people I’ve worked with who fully understand and internalize those last two points when designing systems are few.

]]>