3 ms·

Good points, but you made that sound kind of complicated. Here's an example of a Leaky Abstraction. My programming language is called Ben (hey that's my name!)

by bprater 18y ago

Good points, but you made that sound kind of complicated. Here's an example of a Leaky Abstraction. My programming language is called Ben (hey that's my name!) -- # build_webpage() Tada. Fire up your browser, point it to localhost and bam! you have your own personal webpage with a photo section and a forum. See how easy it was. Then you think to yourself, wait -- I want a classified ads section, too! Ah, this is when the big leak happens. My Ben framework doesn't include that bit, so you are going to have to dive down into the C that I wrote Ben with and muddle about it to write that code yourself. It gets nastier too. You could probably hack together a classified ads section in your favorite language in a couple hours, but since you've bet the farm on Ben, you have to get up to speed on how my framework works and you have to use my language of choice. The abstraction is now leaking so much that you get out PHP and just do it all by hand.

Zak 18y ago
What point are you trying to make here? That using frameworks is bad because they won't magically solve all your problems? That no magic fix exists? That everybody should use PHP? That C is a bad language for writing a web programming DSL?
- drawkbox 18y ago
  It takes 10 years to get good at anything. This quote is from OOAD. >>The amateur software engineer is always in search of magic, some sensa-tional method or tool whose application promises to render software development trivial. It is the mark of the professional software engineer to know that no such panacea exists. Amateurs often want to follow cook-book steps; professionals know that such approaches to development usually lead to inept design products, born of a progression of lies, and behind which developers can shield themselves from accepting responsi-bility for earlier misguided decisions. The amateur software engineer either ignores documentation altogether or follows a process that is docu-mentation-driven, worrying more about how these paper products look to the customer than about the substance they contain. The professional acknowledges the importance of creating certain documents but never does so at the expense of making sensible architectural innovations. The process of object-oriented analysis and design cannot be described in a cookbook, yet it is sufficiently well defined as to offer a predictable and repeatable process for the mature software development organization. Frameworks are just fine, tools are just fine, any language is just fine. It is all about the skill of the person using it. I have seen good PHP code. I have seen bad Python code. It is about the developer, their understanding and how much they can handle of the system. If a framework lessens what they need to know to something they can manage at their level then it will work. The job of a good engineer, is to take something complex and make it simple. So there are and will always be great tools to help people get better and the best will dig deeper and after 8-10 years it seems like most of the marketing and b.s. and jungle of software starts to come clear.

by bprater 18y ago

Zak 18y ago

What point are you trying to make here? That using frameworks is bad because they won't magically solve all your problems? That no magic fix exists? That everybody should use PHP? That C is a bad language for writing a web programming DSL?

drawkbox 18y ago
It takes 10 years to get good at anything. This quote is from OOAD. >>The amateur software engineer is always in search of magic, some sensa-tional method or tool whose application promises to render software development trivial. It is the mark of the professional software engineer to know that no such panacea exists. Amateurs often want to follow cook-book steps; professionals know that such approaches to development usually lead to inept design products, born of a progression of lies, and behind which developers can shield themselves from accepting responsi-bility for earlier misguided decisions. The amateur software engineer either ignores documentation altogether or follows a process that is docu-mentation-driven, worrying more about how these paper products look to the customer than about the substance they contain. The professional acknowledges the importance of creating certain documents but never does so at the expense of making sensible architectural innovations. The process of object-oriented analysis and design cannot be described in a cookbook, yet it is sufficiently well defined as to offer a predictable and repeatable process for the mature software development organization. Frameworks are just fine, tools are just fine, any language is just fine. It is all about the skill of the person using it. I have seen good PHP code. I have seen bad Python code. It is about the developer, their understanding and how much they can handle of the system. If a framework lessens what they need to know to something they can manage at their level then it will work. The job of a good engineer, is to take something complex and make it simple. So there are and will always be great tools to help people get better and the best will dig deeper and after 8-10 years it seems like most of the marketing and b.s. and jungle of software starts to come clear.