Definitely with Scott on this one...

Post #114,433 by gdaustin 8/19/03 11:06:10 PM 8/19/03 11:18:17 PM Reply	Definitely with Scott on this one... IDEs make GUI development a breeze. But I generally draw the GUI components, then change the code to dynamically create them. I had a Java program that would dynamically draw different JPanel areas based on the type of object you selected. That's the kind of code I like. Here's the Truth Maggie. The deeper one understands the language, libraries and features, the faster and better their code will be. Deep understanding of a language and supporting libraries doesn't come from "pointy clicky". It comes from using the GUI to 'draw the screen' then being able to use the code to make objects appear and disappear in response to user events. It comes from knowing what to do with Property objects and Vectors, and Maps. It comes from understanding how JDBC interacts with your database. It comes from working with a language for at least 12 months. It comes from having enough computer science background to build the right data structures and algorithms. It comes from exactly the kind of development experience that most U.S. companies are laying off in droves right now. Bosses understand "pointy clicky". It can be demoed to them. However, it takes a long time to understand EDI protocols, and sockets, and standard Unix libraries, and standard C libraries, and base Java libraries, etc. etc. etc. Smart bosses balance the fact that there "is no silver bullet" with some respect for new technology. JBuilder has some other cool features, too. We tied it into VSS, so we could pull the project directly into the IDE and check it in, too, from the IDE. We used the debugger heavily, even debugging code on Unix systems from Windows. The optimize it profiler was awesome, making our code very fast. However, if you're in the Windows environment, with JBuilder basic edition so inexpensive, does it qualify as an Editor? But then you get some debugging, too. But you don't get VSS integration, or drag and drop data tools (which aren't worth much anyway), or Optimize It. But at $99, it's probably a pretty good code editor (but it might not beat Visual SlickEdit). Edited by gdaustin Aug. 19, 2003, 11:08:44 PM EDT Definitely with Scott on this one... IDEs make GUI development a breeze. But I generally draw the GUI components, then change the code to dynamically create them. I had a Java program that would dynamically draw different JPanel areas based on the type of object you selected. That's the kind of code I like. Here's the Truth Maggie. The deeper one understands the language, libraries and features, the faster and better their code will be. Deep understanding of a language and supporting libraries doesn't come from "pointy clicky". It comes from using the GUI to 'draw the screen' then being able to use the code to make objects appear and disappear in response to user events. It comes from knowing what to do with Property objects and Vectors, and Maps. It comes from understanding how JDBC interacts with your database. JBuilder has some other cool features, too. We tied it into VSS, so we could pull the project directly into the IDE and check it in, too, from the IDE. We used the debugger heavily, even debugging code on Unix systems from Windows. The optimize it profiler was awesome, making our code very fast. However, if you're in the Windows environment, with JBuilder basic edition so inexpensive, does it qualify as an Editor? But then you get some debugging, too. But you don't get VSS integration, or drag and drop data tools (which aren't worth much anyway), or Optimize It. But at $99, it's probably a pretty good code editor (but it might not beat Visual SlickEdit). Edited by gdaustin Aug. 19, 2003, 11:15:47 PM EDT Definitely with Scott on this one... IDEs make GUI development a breeze. But I generally draw the GUI components, then change the code to dynamically create them. I had a Java program that would dynamically draw different JPanel areas based on the type of object you selected. That's the kind of code I like. Here's the Truth Maggie. The deeper one understands the language, libraries and features, the faster and better their code will be. Deep understanding of a language and supporting libraries doesn't come from "pointy clicky". It comes from using the GUI to 'draw the screen' then being able to use the code to make objects appear and disappear in response to user events. It comes from knowing what to do with Property objects and Vectors, and Maps. It comes from understanding how JDBC interacts with your database. It comes from working with a language for at least 12 months. It comes from having enough computer science background to build the right data structures and algorithms. JBuilder has some other cool features, too. We tied it into VSS, so we could pull the project directly into the IDE and check it in, too, from the IDE. We used the debugger heavily, even debugging code on Unix systems from Windows. The optimize it profiler was awesome, making our code very fast. However, if you're in the Windows environment, with JBuilder basic edition so inexpensive, does it qualify as an Editor? But then you get some debugging, too. But you don't get VSS integration, or drag and drop data tools (which aren't worth much anyway), or Optimize It. But at $99, it's probably a pretty good code editor (but it might not beat Visual SlickEdit). Edited by gdaustin Aug. 19, 2003, 11:18:17 PM EDT Definitely with Scott on this one... IDEs make GUI development a breeze. But I generally draw the GUI components, then change the code to dynamically create them. I had a Java program that would dynamically draw different JPanel areas based on the type of object you selected. That's the kind of code I like. Here's the Truth Maggie. The deeper one understands the language, libraries and features, the faster and better their code will be. Deep understanding of a language and supporting libraries doesn't come from "pointy clicky". It comes from using the GUI to 'draw the screen' then being able to use the code to make objects appear and disappear in response to user events. It comes from knowing what to do with Property objects and Vectors, and Maps. It comes from understanding how JDBC interacts with your database. It comes from working with a language for at least 12 months. It comes from having enough computer science background to build the right data structures and algorithms. It comes from exactly the kind of development experience that most U.S. companies are laying off in droves right now. Bosses understand "pointy clicky". It can be demoed to them. However, it takes a long time to understand EDI protocols, and sockets, and standard Unix libraries, and standard C libraries, and base Java libraries, etc. etc. etc. JBuilder has some other cool features, too. We tied it into VSS, so we could pull the project directly into the IDE and check it in, too, from the IDE. We used the debugger heavily, even debugging code on Unix systems from Windows. The optimize it profiler was awesome, making our code very fast. However, if you're in the Windows environment, with JBuilder basic edition so inexpensive, does it qualify as an Editor? But then you get some debugging, too. But you don't get VSS integration, or drag and drop data tools (which aren't worth much anyway), or Optimize It. But at $99, it's probably a pretty good code editor (but it might not beat Visual SlickEdit). Collapse All History
Post #114,554 by tuberculosis 8/20/03 11:29:04 AM Reply	Disagree RE GUI development I can write the GUI faster than I can draw it in nearly every environment. I learned this from some guys on a team I worked on long ago. I always used to think GUI's were too expensive to write by hand. Some guys on our team who were responsible for the UI eschewed GUI builders - they said that GUI builders only seem more productive - if you measure the actual amount of time they take to use its longer. They told me to sit down and try it - I found they were right. The only ones I consider an exception is using InterfaceBuilder on OS X. That's because nib files are so thoroughly baked into the toolkit that its harder to do things without them. The rest of them generate code which violates Blanchards Law - code generation is to be avoided at all costs. IB serializes object archives (ditto Morphic - the UI toolkit in Squeak). Smalltalk is dangerous. It is a drug. My advice to you would be don't try it; it could ruin your life. Once you take the time to learn it (to REALLY learn it) you will see that there is nothing out there (yet) to touch it. Of course, like all drugs, how dangerous it is depends on your character. It may be that once you've got to this stage you'll find it difficult (if not impossible) to "go back" to other languages and, if you are forced to, you might become an embittered character constantly muttering ascerbic comments under your breath. Who knows, you may even have to quit the software industry altogether because nothing else lives up to your new expectations. --AndyBower
Post #114,611 by FuManChu 8/20/03 5:08:37 PM Reply	I like your Law so much I twikified it. [link\|http://twiki.iwethey.org/twiki/bin/view/Main/BlanchardsLaw\|http://twiki.iwethey...ain/BlanchardsLaw] Feel free to flesh it out. If I get time, I'll add my own discussion of why I avoid code generation. "There's a set of rules that anything that was in the world when you were born is normal and natural. Anything invented between when you were 15 and 35 is new and revolutionary and exciting, and you'll probably get a career in it. Anything invented after you're 35 is against the natural order of things." Douglas Adams
Post #114,651 by tuberculosis 8/20/03 8:42:36 PM Reply	heh - cool Smalltalk is dangerous. It is a drug. My advice to you would be don't try it; it could ruin your life. Once you take the time to learn it (to REALLY learn it) you will see that there is nothing out there (yet) to touch it. Of course, like all drugs, how dangerous it is depends on your character. It may be that once you've got to this stage you'll find it difficult (if not impossible) to "go back" to other languages and, if you are forced to, you might become an embittered character constantly muttering ascerbic comments under your breath. Who knows, you may even have to quit the software industry altogether because nothing else lives up to your new expectations. --AndyBower
Post #115,052 by slugbug 8/23/03 11:02:42 AM Reply	What he said... ...I could not agree more: "The deeper one understands the language, libraries and features, the faster and better their code will be. Deep understanding of a language and supporting libraries doesn't come from "pointy clicky"." "pointy clicky" is a real frustration point for me. At my current gig, I spend a fair amount of time writing code, but I also have to help others debug their code -- much of it "point clicky" derived. Just yesterday, I was helping a coworker who could not get his code to work. After verbally describing to him what he needed to do and seeing his glazed over expression, I opened the manual and read the documentation with him. I could then see the lightbulb go off over his head and he said "you are so smart". No, I just RTFM. As Scott mentioned in his post, "pointy clicky" makes for programmers who know the tool (I concur). I'd add that this trend also makes for programmers who don't RTFM or understand a given language and its libraries. -Slugbug

Welcome to IWETHEY!