Interesting article on IDE's
Came across the article below and it got me thinking a bit.
http://blog.deliciousrobots.com/2010/6/26/so-long-and-farewell-to-the-IDE/
I wouldn't agree with him thoroughly. In fact I don't think I agree that it is the IDE's which are problematic at all. But there are certainly some good points thrown into the mix. In my opinion it is all of the added things the IDE's try to handle which are the issue for the IDE. I've made similar comments about UI development numerous times. For example, while I love the designers in Visual Studio for creating WinForms, they don't and likely never could expose all of the functionality. Eventually which leads to a double learning curve, you went and learned the designer, only to eventually hit a point where you needed to learn the API's the designer uses anyway.
I found that when I first started working with the Windows forms designer I couldn't find the toolbox because it was auto-hiding by default, then I would add things and not notice the property box, and then I found the property box and to this day I don't know what some of the properties are there for. I'll admit I learn everything the hard way when I can. But the double edged part of the learning curve came when I wanted to add things which the visual editor didn't do... for example if I double click on a list view it creates the event handlers for the selected index changing, but I wanted to handle a mouse double click. After all of that effort getting comfortable with the Designer, I still needed to crack open the code and learn the API's. Well, the funny thing, the visual designer has made so many developers lazy that every tutorial relies so heavily the designer that you can't find what you want on the web, unless you know the correct terminology in API, and most times if you knew that you probably wouldn't need to search for tutorials.
By contrast, in university they taught me Java. And we were taught to code Java, UI and all, in wordpad! Then we used the command line tool to compile and run. It seemed painstaking at the time. But after less than 2 months I was able to do more with my UI's in Java than I am able to do in C# after 2 years now. The reason? I had absolutely no designer to give me false delusions about how well I knew the UI API's. Also, at the time there weren't many visual designers for Java code so tutorials and other search results almost always had snippets of code that showed me what I needed and often even helped me in areas I didn't even realized I needed help in.
I know the article doesn't even mention UI development, but that was what the complaints reminded me of from my own experiences. And I find myself wondering how much code I'm using inefficiently because someone else has abstracted it out for me in a framework. I don't find I feel more or less like a "code generating machine" because I code in Visual Studio vs. when I wrote entire Java apps in wordpad, but the frameworks and the toolkits and all of the other aspects you often need to plug into an SDK to get a certain package integrated into a project does always gnaw at me.
This is in fact the one reason I have made every attempt possible to stay away from Web Development. I remember, in my last year at Carleton I took a grad level class on open source software. It was basically a grab bag of goodies where I got exposure to some much more interesting frameworks and open source projects. We had a brief period where we focussed on web development and Apache Tomcat. To start building the project using the framework the prof was recommending we needed to download 1 specific version of the IDE pre-bundled with a bunch of packages, then we had to download and install other packages in a specific order and then start the project from a pre-defined template. When we got to that point in the lecture the prof stopped and said "see these files here... don't EVER edit them or you'll never be able to get your project to run again". I hadn't written a single line of code and I had a project with hundreds of files and tens of thousands of lines of code that was non-sense to me, and which I couldn't alter and which I had no understanding of. .Net and other languages are the same way in many respects... you just don't always have to see the files and feel as helpless about it. In those projects they are just better hidden either in DLL's or by some other mechanism.
So, to bring this back full circle to back to windows forms. Was my prof serious when he said that if we altered the files we would never get our app running? I doubt it. Someone knew what all of the underlying code meant and edited to get it to that point. So obviously it must be editable. However widespread adoption of the template and technologies lead to a community that had no clue what was going on behind the scenes. I think that if this were a Windows Forms class he would have shown us the designer first, then opened the designer generated code and said the same thing there about it being un-editable.
The abstractions and frameworks can speed development and/or improve quality of code but it seems like there is always a cost. In my examples, you get code churned out faster, but you lose the understanding in the process. IDE's that crash due to poorly implemented integrations are just an innocent bystander in my opinion, just another sign of the root problem.
Just some random thoughts... I'm not yet ready to part either with my IDE's or my libraries full of abstractions and frameworks. But at least I will do so acknowledging how they might be negatively impacting me.
Edit: Over lunch today I was re-reading "No Silver Bullet" by Frederik Brooks and came across the following quote regarding high level languages and abstractions. Having just written this post it seemed amusingly relevant:
"Moreover, at some point the elaboration of a high-level language creates a tool-mastery burden that increases, not reduces, the intellectual task of the user who rarely uses the esoteric constructs.
"
http://blog.deliciousrobots.com/2010/6/26/so-long-and-farewell-to-the-IDE/
I wouldn't agree with him thoroughly. In fact I don't think I agree that it is the IDE's which are problematic at all. But there are certainly some good points thrown into the mix. In my opinion it is all of the added things the IDE's try to handle which are the issue for the IDE. I've made similar comments about UI development numerous times. For example, while I love the designers in Visual Studio for creating WinForms, they don't and likely never could expose all of the functionality. Eventually which leads to a double learning curve, you went and learned the designer, only to eventually hit a point where you needed to learn the API's the designer uses anyway.
I found that when I first started working with the Windows forms designer I couldn't find the toolbox because it was auto-hiding by default, then I would add things and not notice the property box, and then I found the property box and to this day I don't know what some of the properties are there for. I'll admit I learn everything the hard way when I can. But the double edged part of the learning curve came when I wanted to add things which the visual editor didn't do... for example if I double click on a list view it creates the event handlers for the selected index changing, but I wanted to handle a mouse double click. After all of that effort getting comfortable with the Designer, I still needed to crack open the code and learn the API's. Well, the funny thing, the visual designer has made so many developers lazy that every tutorial relies so heavily the designer that you can't find what you want on the web, unless you know the correct terminology in API, and most times if you knew that you probably wouldn't need to search for tutorials.
By contrast, in university they taught me Java. And we were taught to code Java, UI and all, in wordpad! Then we used the command line tool to compile and run. It seemed painstaking at the time. But after less than 2 months I was able to do more with my UI's in Java than I am able to do in C# after 2 years now. The reason? I had absolutely no designer to give me false delusions about how well I knew the UI API's. Also, at the time there weren't many visual designers for Java code so tutorials and other search results almost always had snippets of code that showed me what I needed and often even helped me in areas I didn't even realized I needed help in.
I know the article doesn't even mention UI development, but that was what the complaints reminded me of from my own experiences. And I find myself wondering how much code I'm using inefficiently because someone else has abstracted it out for me in a framework. I don't find I feel more or less like a "code generating machine" because I code in Visual Studio vs. when I wrote entire Java apps in wordpad, but the frameworks and the toolkits and all of the other aspects you often need to plug into an SDK to get a certain package integrated into a project does always gnaw at me.
This is in fact the one reason I have made every attempt possible to stay away from Web Development. I remember, in my last year at Carleton I took a grad level class on open source software. It was basically a grab bag of goodies where I got exposure to some much more interesting frameworks and open source projects. We had a brief period where we focussed on web development and Apache Tomcat. To start building the project using the framework the prof was recommending we needed to download 1 specific version of the IDE pre-bundled with a bunch of packages, then we had to download and install other packages in a specific order and then start the project from a pre-defined template. When we got to that point in the lecture the prof stopped and said "see these files here... don't EVER edit them or you'll never be able to get your project to run again". I hadn't written a single line of code and I had a project with hundreds of files and tens of thousands of lines of code that was non-sense to me, and which I couldn't alter and which I had no understanding of. .Net and other languages are the same way in many respects... you just don't always have to see the files and feel as helpless about it. In those projects they are just better hidden either in DLL's or by some other mechanism.
So, to bring this back full circle to back to windows forms. Was my prof serious when he said that if we altered the files we would never get our app running? I doubt it. Someone knew what all of the underlying code meant and edited to get it to that point. So obviously it must be editable. However widespread adoption of the template and technologies lead to a community that had no clue what was going on behind the scenes. I think that if this were a Windows Forms class he would have shown us the designer first, then opened the designer generated code and said the same thing there about it being un-editable.
The abstractions and frameworks can speed development and/or improve quality of code but it seems like there is always a cost. In my examples, you get code churned out faster, but you lose the understanding in the process. IDE's that crash due to poorly implemented integrations are just an innocent bystander in my opinion, just another sign of the root problem.
Just some random thoughts... I'm not yet ready to part either with my IDE's or my libraries full of abstractions and frameworks. But at least I will do so acknowledging how they might be negatively impacting me.
Edit: Over lunch today I was re-reading "No Silver Bullet" by Frederik Brooks and came across the following quote regarding high level languages and abstractions. Having just written this post it seemed amusingly relevant:
"Moreover, at some point the elaboration of a high-level language creates a tool-mastery burden that increases, not reduces, the intellectual task of the user who rarely uses the esoteric constructs.
"
Comments
Post a Comment