Do We Need an "IDE 2.0" Revolution?

Discussions

News: Do We Need an "IDE 2.0" Revolution?

  1. Do We Need an "IDE 2.0" Revolution? (29 messages)

    If most of us were to be asked who godfathered the printing press, the majority of responses would cite Johannes Gutenberg, a German goldsmith in the 1400's, for his work in bringing the Bible to the masses. Very few would eloquate that a Chinese man named Bi Sheng invented one of the most influential pieces of equipment in history, and this just before 1050 AD. Few would mention that Bi's original press was made using baked clay characters, and was created and fostered in provincial China (including what is now Korea) for hundreds of years prior to the European version in 1450.

    As Bi's printing technology evolved over the centuries into wood and metal typesets and then even more efficient printing methods, the desire to keep the Chinese art of calligraphy and hand copying of documents stamped the demand for large-scale, printed messaging. By the late 1490's, as the Chinese and European technologies for printing were comparable (though mostly unaware of one another) the Gutenberg press was revolutionizing European society, while the Chinese press labored almost as a novelty of technological prowess rather than a tool for mass education.

    So why do you not hear about the Chinese press? Why is Gutenberg so heralded, but Bi Sheng is nearly forgotten? The reason is mostly cultural and rooted in what various people groups value as important. The Chinese highly valued (and to a point still value) the hand-written, artful, calligraphic style of their language.

    While the artistic value of Asian character calligraphy is indisputable, it is widely regarded that Gutenberg's press is the single most influential invention of the second millennium. With the rapid dissemination of information made possible through Europe, the spread of knowledge from the few to the masses was catalyzed for religion, politics, history, philosophy and sciences. Moving forward, literacy and rapid knowledge accumulation became the standard, and the handwritten, artful volumes previously available only to the elite became relics in the hands of the newly-enlightened populous. The consequences of this invention are still felt today, as printing and publishing is going through a new quantum shift into a completely digital age, allowing electronic distribution of information around the globe in the blink of an eye.

    Are we following a similar evolutionary pattern in the development tools space? And if so, how did we get here, and what do we need to move the tools industry into the new "digital printing" age for software development?

    Software development has, we would all admit, emerged out of the "baked clay characters" of simple source code. Over the last few decades as source code became more complex, it became necessary to develop environments around the "code" so that coding itself was more easily addressed. Thus, evolution one in development tools necessarily made it easier to hand-code with new, multi-use "wooden typeset" tool kits.

    Then, as the code got even more complex, developers found themselves juggling a number of technologies to complete the simplest of projects. Evolution two crept in. "Metallic," more complex tools were developed to manage the code-writing process and partition it into segments that were easier to address individually alongside each technology concern. Code completion/generation, color coding, refactoring support etc., are extensions of this concept, and this is where we presently live with the majority of IDEs and other tool sets.

    However, despite these advances, today's enterprise developers spend less than half of their day interacting with code. The rest is spent setting up and configuring their work environment, packaging projects, starting and stopping servers, and twiddling their frustrated thumbs while waiting to see how their application will behave, all the while pulling their hair trying to figure out which one of the many variables in their environment or technology stack is the source of the endless trial and error.

    When source code alone is the golden hammer, calls for productivity by getting past the trial and error stage are often answered by writing more code in the form of deployment scripts, configuration wizards, persistence and architectural frameworks, and other automation logic (all of which have little to do with the project at hand). This turns each developer into a tools smith rather than an application engineer. But, in an industry where less than a third of projects succeed in meeting their scope, time lines and budget, can we afford to continue fixating on this art of source in the face of global delivery mandates?

    As the world has gotten smaller and a globally-networked, "technical renaissance" economy has emerged, the competition has become fierce. The evolution of tools and the rise in the number of skilled workers has skyrocketed over the past decade. We continue to see new languages, environments and specialized tools every day. The rapid dissemination of these ideas and the sheer amount of information available make it nearly impossible for cutting-edge technologists to accomplish the predetermined tasks before them as well as become fluent in each new progression.

    Understandably then, most developers today pick and choose one of these very specific tools for specific results. The natural selection of tool deprecation and the survival of the fittest companies is ongoing, but this multi-tool phenomenon creates its own difficulties, with users (sometimes inefficiently) moving back and forth between tool kits for various tasks.

    Regardless of their chosen tools, or even the number of them being used simultaneously, the overarching message for and from developers is clear: a favored code management solution/environment is now necessary to manage how to code each piece of any given project, environmental preferences and to manage servers and external data sources. If the environment cannot do this and developers have to tool smith the productivity gap, most find themselves trapped chasing environmental ghosts rather than focusing on the task at hand. But, most importantly, developers lose the one constant factor that has remained steady through all these centuries: time.

    IDE 2.0 – The Integrated DELIVERY Environment
    Enter the IDE 2.0. A proper IDE in today's world needs to be a fully integrated solution that handles all of a project's data from the UI all the way down to the data side and be ultra sensitive to run-time requirements. Without this type of management ability, todays' developers will find themselves spending far too much time debugging and error-searching, and less time delivering. The old, siloed, trial and error methods of develop, deploy and debug are becoming less and less economical as the layers of technology get more and more extensive.

    "But wait," some may say. "I like having control of my code. I can do it myself and don't need the management features. Plus, when something auto-completes, I don't know what's in it and it may not be the way that I would code it."

    It is understandably easy to turn this type of conversation into a "black box vs. build it from scratch" conversation as though they must be mutually exclusive options. This would errantly cause us to lose sight of the forest for the trees. In an IDE 2.0 world, that conversation should not be a debate because the tool should allow you to "get it done" first and then anguish over the details, rather than debate over the "art" of what it should be at the expense of delivery (the full exploration of what an IDE 2.0 should include and what developers should expect from it can be explored in a future post).

    Bringing this conversation back to our printing-press-to-digital-printing evolutionary analogy to solidify this point; today's printed publications are created in some form of word processing software, sent electronically to editors who modify the electronic documents and then submit them electronically to printing houses. The printers take the electronic copies and insert them into large-scale presses that read the data and print it on the page.

    This seems normal and simple enough. But, if the writer and editor were to spend time snail mailing back and forth with handwritten notes for weeks on end, we would say they were incredibly inefficient and not shrewd when it comes to competitive business practices. Analogously, it is not a concern about whether or not today's developers CAN write all the code and set up their environments. Certainly they can. Developers are a smart bunch. The question is: SHOULD they? Perhaps even more importantly: Is that what their bosses want them to be doing? Are developers being paid to code "their way," or to get the project completed? And that is not a trick question.

    In the competitive global marketplace, we can see that skillfully-composed, handwritten source code is NOT all that is needed in today's projects. Hand-writing, packing, deploying and testing all of the code necessary takes far too much time and maintenance for today's discerning developer, and is most likely frowned upon by executives. Today's developer needs a fully stable, packaged, out-of-the-box solution that allows them to code, test, debug, manage and play with technology in a single environment with cross-layer management ability, speed, accuracy and confidence.

    In short, today's developers demand an IDE 2.0, one that truly integrates the developer into their technologies and helps them along the way. Discerning developers need the next generation of developer environments using today's best, ever-improving technologies.

    What are the consequences of ignoring this IDE 2.0 phenomenon?

    China at one point passed on the power of emerging, fast, behavior-changing technologies in favor of a simpler, more artful existence. That was a choice they made, and a very deliberate and noble one. The art forms they created are still admired to this day as some of the greatest in the world, and their culture is inarguably among the richest in history. However, the Renaissance economies of Europe and the New World that emerged as a result of the printing press' mass adoption and evolution changed the global marketplace forever and set new standards for technology and commerce that are still felt to this day.

    Will today's software developer be marketable tomorrow by choosing art or productivity? We will see.

    Threaded Messages (29)

  2. Writing better IDE's to generate even more source code might help in the short term, but sooner or later even the most sophisticated tools will run out of Steam. If we look at the latest trends , you'll see that their focus is to reduce the amount of source code: - Software as a Service, reducing the number of Libraries needed and just 'being available' - Annotations, reducing the amount of config files - Maven , reducing the size of build files by using common conventions. - Graphical tools for creating User Interfaces; The latest incarnation being Adobe Flex, going as far back as Visual Basic in the 90's , with a String of failed attempts in Java. - Open Source Frameworks and Libraries, reducing the need to roll your own solution, and able to re-use somebody elses work instead. The ideal approach would be one that most of the time hid complexity, but that allows you to look 'under the hood' when you needed / wanted to. Paul Browne, Technology and People
  3. I think the target should not be to just reduce the amount of code, but find some way to express it in a easy to understand way. With this I'm neither advocating that a more verbose syntax is better than a terse one, nor the inverse. Again, it's not about the amount of code, but how it expresses the intent, without too much noise, but in a deterministic and easy-to-understand way (some 'noise' in programming languages exist to avoid ambiguities and easy 'mental code parsing'). But too much configuration do contribute to make the code unreadable. DSLs come to mind. And DDD, and Intentional Programming...
  4. - Annotations, reducing the amount of config files
    Annotations have their own problems as a tool. A lot of people have issue with configuration IN code.
    - Maven , reducing the size of build files by using common conventions.
    Noooooooooooooo.... :)
    The ideal approach would be one that most of the time hid complexity, but that allows you to look 'under the hood' when you needed / wanted to.
    I completely agree. The issue is how lightly we tread on the main thing, the code. Many architectures require such commingling of core code and the architecture around it. The movement to POJOs (what a ridiculous name..) is a great shift. Spring's bean container (pico and the likes), followed and they work well. The thing I care about most as a programmer, not a deployment person, designer or anything else, or a designer or anything else, is the code and making sure it is in good shape. The less I can tie my code to configuration, my IDE, my other thing, the better. Keep things dead simple. We need less software, but we need it not to embrace our code, not invade it.
  5. exaggeration[ Go to top ]

    However, despite these advances, today's enterprise developers spend less than half of their day interacting with code. The rest is spent setting up and configuring their work environment, packaging projects, starting and stopping servers, and twiddling their frustrated thumbs while waiting to see how their application will behave, all the while pulling their hair trying to figure out which one of the many variables in their environment or technology stack is the source of the endless trial and error.
    Half of our day configuring our work environment, packaging projects, and starting/stopping servers? Man, you must be a Websphere user... Seriously though, this is a huge exaggeration. In most competently run projects, the working environment is hammered out in the initial phases of a project. Most projects either have unit tests that run outside of the container, or work with an application server that is very good at hot/redeployment. All and all, if you have a greater than 5 year perspective on things, development has improved greatly over the past 20 years. -- Bill Burke JBoss, a division of Red Hat http://bill.burkecentral.com
  6. Re: exaggeration[ Go to top ]

    Half of our day configuring our work environment, packaging projects, and starting/stopping servers? Man, you must be a Websphere user... Seriously though, this is a huge exaggeration.
    Seriously though ... not an exaggeration for websphere users. Working with all of RAD code wizards really shows you how evil wizards are. How I miss my old Jboss days...
  7. Re: exaggeration[ Go to top ]

    Half of our day configuring our work environment, packaging projects, and starting/stopping servers? Man, you must be a Websphere user... Seriously though, this is a huge exaggeration.


    Seriously though ... not an exaggeration for websphere users. Working with all of RAD code wizards really shows you how evil wizards are.

    How I miss my old Jboss days...
    These can usually be scripted out, including on WebSphere. It adds overhead to the development "day", but w/ proper use of unit tests, modular design and a well setup environment, one should rarely have to think of these things. When they become fussy then it becomes an issue. Servers that hang, in container testing, difficult build processes all undo the entire thing. The wizard parts of RAD are to give you an initial speedup through higher level design. Get the pieces in place, generate what you need, then go muck around. If your RAD stuff is impeding on you, you may want to stop using it if you can. :)
  8. Re: exaggeration[ Go to top ]

    The wizard parts of RAD are to give you an initial speedup through higher level design. Get the pieces in place, generate what you need, then go muck around. If your RAD stuff is impeding on you, you may want to stop using it if you can. :)
    I have actually just deleted my last project from RAD and moved them all to Eclipse. It's amazing how much faster and less annoying Eclipse is than RAD especially since the are branches on the same tree. IBM seems really to suck at writing code in Java. They apparently can't produce a decent API, anyway. Adding in Rational turds isn't helping the equation. I've never understood the attraction of RUP given that it's ostensibly the process that Rational uses and that their software is so painful to use.
  9. Pictrures are worth 1000 lines of code[ Go to top ]

    I've been working with a proprietary tool that combines glorified flow charts (BMPN) diagrams with a screen designer and good old code. It's a wonderful combination that really helps you visualize how all the pieces work together to automate a sophisticated multi-party process (workflow). Pictures AND text... what a concept. -John
  10. I think the problem is not so much a weakness of the IDE, but a weakness of the platform being developed for. Lets face it, most of the complexities of web development is brought about by the need for frameworks to address the simplicity of the web platform. I think if we all developed desktop apps, then the notion of needing a revolution for our IDEs would be redundant. As it is, we are scrambling to develop web based solutions that act similar to those that have been on the desktop for decades. Perhaps we need more of a 2.0 revolution on the handling of the web.
  11. I think the problem is not so much a weakness of the IDE, but a weakness of the platform being developed for.
    Or perhaps it's less to do with the distributed nature of the web, but a weakness of the underlying communication protocol. IP is purely a packet donkey, TCP is a marshaller of packets, and http is nothing more than a widely adopted data exchange mechanism. The big issues we face with enterprise software (remoting, distribution, reliability, security, transactions) is a direct result of the stateless (ok https has state but who uses it for that purpose alone?), insecure, connectionless nature of the protocols under the hood. Until and whilst this is the case, enterprise software development will be a nebulous infrastructure of competing high-level methodologies trying to outdo (or monopolise) everyone else. And the competing IDE's will continue to reflect that state of the world.
  12. Really bad analogy[ Go to top ]

    I don't get all these people moaning about coding. If you don't like to program and write code, then change your job. All this non-sense about having an IDE do everything for you and magically making code disappear is pointless. For somethings, a high level approach is good. For other things, writing code is good. All this non-sense about IDE 2.0 is just a waste of everyone's time. my bias 2 cents
  13. Re: Really bad analogy[ Go to top ]

    I have to agree that any concept of hiding code is going down a well-worn dead end. To me it is akin to asking for a better Microsoft Word so that we don't have to write so many words manually. Where is that "interesting paragraph generator" button again? In most cases, software development is best done in text. Humans can read and understand text and text is easy to manipulate. In some of the most interesting languages the text of the code can also be the data. I'm all for advancements in language design that optimizes meaning over template code since I feel that does improve productivity. Getting back to IDEs, I'm for features and standards that can help reduce repetitive tasks while staying out of the way. I shouldn't have to reinvent a build structure, library management, automated build, packaging etc for every project - especially if the project is at the same company/team. I'm also for features that help with testing, refactoring, built in documentation, decompiling, etc. We have a lot of this today but I'm wondering if it could be done better? I spend half the time in IntelliJ (or Eclipse) and half the time in a text editor/terminal combo depending on the task. I'm not sure if a single IDE can ever do it all any more than a single programming language should be used for all purposes.
  14. Re: Really bad analogy[ Go to top ]

    I have to agree that any concept of hiding code is going down a well-worn dead end. To me it is akin to asking for a better Microsoft Word so that we don't have to write so many words manually. Where is that "interesting paragraph generator" button again?

    In most cases, software development is best done in text. Humans can read and understand text and text is easy to manipulate.
    My take is that graphical interfaces to-date are good for making specific simple tasks less monotonous. But the more complex the task, the more the GUI gets in the way. One example I use often is that in a windowing environment, if I need to copy a few files from one place to another, I'll use a graphical interface. But if I need to change all 1000 filenames, I'm going to open up a prompt and do it with a text-based command. It's possible that a graphical language could be created. As I understand it, the ancient Greek mathematicians did a lot of their proofs using graphics. The pictures had specific clear meanings. There's no reason we can't have a graphical language. It's just that we don't have any really good ones. UML is the only one that comes to mind and personally I think there's a lot of room for improvement.
    In some of the most interesting languages the text of the code can also be the data.
    As I understand it, this violates the cardinal rule of secure software design: do not mix data and instructions.
  15. Re: Really bad analogy[ Go to top ]

    As I understand it, this violates the cardinal rule of secure software design: do not mix data and instructions.
    Tell that to the LISP folk. I suppose another example would be JSON and JavaScript where the data structure definition is the same as the data. But I guess I'm getting way off topic.
  16. Re: Really bad analogy[ Go to top ]

    As I understand it, this violates the cardinal rule of secure software design: do not mix data and instructions.


    Tell that to the LISP folk.

    I suppose another example would be JSON and JavaScript where the data structure definition is the same as the data.

    But I guess I'm getting way off topic.
    I don't disagree that it's pretty cool and that it's useful but it's also something that security experts hate. A good example is how adding scripts to email (and actually executing them) made email much more dangerous. Before that, email was just text and any virus would have to get in through a bug in the email program like a buffer overflow. Code that is subject to SQL injection is an example of not keeping data and instructions properly separated. With regard to LISP, I read somewhere about how LISPers were suggesting that logging should be done as LISP. That is, instead of writing out plain strings and then building code to parse them, write actual LISP to the log. Now, it seems to me that this allows for some serious security holes. For example, if I know enough about the system, I could theoretically send a request that I know would be logged and include malicious instructions in my request such that they would be executed when the log was read. Maybe these are things that people have already resolved but there's a downside to making your system able to do things that you didn't think of.
  17. Re: Really bad analogy[ Go to top ]

    Code that is subject to SQL injection is an example of not keeping data and instructions properly separated.
    More accurately, it's code that's wrapped in other code, with no secure, good protocol, binding the two. The data is in the DB, which is kind well protected outside of the SQL run on it. SQL in say a property file or XML file because it promotes you do it the nicer way: prepared statements and bind variables. Concatenation and hand escaping is more dangerous. What relation do you see between IDEs and separation of concerns beyond where you put your SQL? That alone is already a solved problem, no?
    For example, if I know enough about the system, I could theoretically send a request that I know would be logged and include malicious instructions in my request such that they would be executed when the log was read.
    I hope that the data that is logged is at least written out in a sane manner, making sure the language tokens are properly escaped etc. If so, it doesn't sound so insane, though I can't find a use for it personally.
  18. Re: Really bad analogy[ Go to top ]

    Code that is subject to SQL injection is an example of not keeping data and instructions properly separated.
    More accurately, it's code that's wrapped in other code, with no secure, good protocol, binding the two.
    The common flaw that allows an SQL injection attack is taking data (usually user input) and combining it with other text to create an instruction (an SQL statement). There's nothing inaccurate about that description. The cure for this is to treat the user input as data and not as part of an instruction.
    What relation do you see between IDEs and separation of concerns beyond where you put your SQL?
    I don't really know what you mean. Perhaps you missed the context of that response.
    For example, if I know enough about the system, I could theoretically send a request that I know would be logged and include malicious instructions in my request such that they would be executed when the log was read.
    I hope that the data that is logged is at least written out in a sane manner, making sure the language tokens are properly escaped etc.
    I kind of get the feeling that this defeats much of the purpose of writing logs as LISP but I could be wrong.
  19. Re: Really bad analogy[ Go to top ]

    The common flaw that allows an SQL injection attack is taking data (usually user input) and combining it with other text to create an instruction (an SQL statement).
    Ah, that. Yup, evil as can be. It's a solved problem though within the language and utilities built on it. PreparedStataement, iBatis, etc..
    I kind of get the feeling that this defeats much of the purpose of writing logs as LISP but I could be wrong.
    If it's done like AOP, one could write log statements of what was run and the result for debugging purposes. Equate it to AOP over all methods recording what was run etc. Perhaps more useful for debugging.
  20. Re: Really bad analogy[ Go to top ]

    The common flaw that allows an SQL injection attack is taking data (usually user input) and combining it with other text to create an instruction (an SQL statement).


    Ah, that. Yup, evil as can be. It's a solved problem though within the language and utilities built on it. PreparedStataement, iBatis, etc..
    Right. That's my point. For example a prepared statement doesn't send the users data as part of the command, it send it as data to be plugged into a compiled query. It eliminates a lot of possible flaws.
    I kind of get the feeling that this defeats much of the purpose of writing logs as LISP but I could be wrong.


    If it's done like AOP, one could write log statements of what was run and the result for debugging purposes. Equate it to AOP over all methods recording what was run etc. Perhaps more useful for debugging.
    I have no idea how familiar you are with LISP and I'm no LISP expert but allow me to try to make sure what I am saying is clear. In LISP there is no clear distinction between data and instructions. Writing logs as LISP, as I understand it, not only makes the logs hierarchical like XML, it could make the logs actually executable code. I'm not really suggesting that these techniques are bad. What I am trying to get across is that we need to consider issues like security when we start talking about mixing data and code because what that generally means is taking data and treating it as instructions. It's very hard to account for every possible thing that an attacker might try. If you are only taking data from trusted sources, then there's not too much to be concerned about. But once you start taking data from unknown sources, you've left yourself wide-open for attack.
  21. Re: Really bad analogy[ Go to top ]

    I have no idea how familiar you are with LISP and I'm no LISP expert but allow me to try to make sure what I am saying is clear. In LISP there is no clear distinction between data and instructions. Writing logs as LISP, as I understand it, not only makes the logs hierarchical like XML, it could make the logs actually executable code.

    I'm not really suggesting that these techniques are bad. What I am trying to get across is that we need to consider issues like security when we start talking about mixing data and code because what that generally means is taking data and treating it as instructions. It's very hard to account for every possible thing that an attacker might try. If you are only taking data from trusted sources, then there's not too much to be concerned about. But once you start taking data from unknown sources, you've left yourself wide-open for attack.
    Actually, the "Log in Lisp" is a clever idea. I mean, send: (log debug "com.example.ClassName" "My log message {0} {1}" "arg1" "arg2") to a Lisp listener, and there all sorts of things that it could do with that statement. After all, "log" is simply a Lisp function that can be defined however you like by the logging system. Of course there are all sorts of issues with this. For example, it works great in Lisp system but if you want to write to a Lisp logger from Java, you have the Great Serialization Problem of render Java objects as Lisp S-expressions (assuming you wish to convey data richer than simple scalars and strings, like, say, a stack trace). That can be very expensive. I'm not worried about security, because Lisper have this problem everytime they call LOAD, COMPILE, or EVAL. They've always had this problem, and they have all sorts of mechanisms that they can use to get around it (it's not that difficult to expose a limited subset of the language to a specific environment for execution -- packages and symbols are all first class objects and readily manipulatable -- far, far easier than in Java). But, the simple fact is, that we already have this feature in the Java loggers today. None of the loggers are bound to just sending text streams to files. We can readily create loggers that work with classes and what not, and route the messages however we like. If we want to write a network based Handler streaming serialized LogRecord objects to a centralized logging server, with which it can do what it will, then that's a straightforward procedure. What we can't do (easily) via that mechanism is "reprogram" the Logging server on the fly, but I've yet to see that as any kind of requirement.
  22. Re: Really bad analogy[ Go to top ]

    I'm not worried about security, because Lisper have this problem everytime they call LOAD, COMPILE, or EVAL. They've always had this problem, and they have all sorts of mechanisms that they can use to get around it (it's not that difficult to expose a limited subset of the language to a specific environment for execution
    It seems like you think you are disagreeing with me but you are making my point here. There is a security concern and you need to think about it. The remedy you mention is not inherent. It requires that the developer/designer realize this concern and take actions to mitigate it. I disagree that we have this issue in Java today. You can create many types of logging appenders but unless you specifically create one to parse the log and treat it as instructions, they will all treat the log file as data and do only what the developer has programmed them to do. Of course if you write an appender that acts as an interpreter you run into the same issue specifically because you are treating data as instructions.
  23. Re: Really bad analogy[ Go to top ]

    It's possible that a graphical language could be created. As I understand it, the ancient Greek mathematicians did a lot of their proofs using graphics. The pictures had specific clear meanings. There's no reason we can't have a graphical language. It's just that we don't have any really good ones.
    I suppose for serious math it would be nicer to have a graphical language that can use mathematical symbols instead of code - I guess that's what MathLab does. Maybe we'll get an IDE revolution when we need it. Right now we've been doing a lot of the same kinds of apps targeting the same kinds of servers for quite awhile.
  24. Re: Really bad analogy[ Go to top ]

    It's possible that a graphical language could be created. As I understand it, the ancient Greek mathematicians did a lot of their proofs using graphics. The pictures had specific clear meanings. There's no reason we can't have a graphical language. It's just that we don't have any really good ones.


    I suppose for serious math it would be nicer to have a graphical language that can use mathematical symbols instead of code - I guess that's what MathLab does.
    I don't mean symbols. Letters and numbers are symbols. Allowing for more or different symbols is not a significant change. I mean pictures/diagrams. Some things are just much more naturally expressed in pictures. A graph can be represented as a picture and as a string but I think I can safely say that most people find the picture easier to understand. The same is true for finite-state automata. The picture is more easily understood than the code that implements it. The other side of pictorial representations is that there is a large segment of the population that struggles with symbolic representations but have very strong cognitive abilities with respect to complex problems especially in three dimensions. These peoples' skills remain largely untapped in science and math.
    Maybe we'll get an IDE revolution when we need it. Right now we've been doing a lot of the same kinds of apps targeting the same kinds of servers for quite awhile.
    Personally, I don't get the value of the original post which is why I didn't get involved until it went off-subject. I don't really get the point of suggesting that there may be some vague suggestions that perhaps a better IDE might be possible. A better IDE will be created when someone creates it. Sitting around and saying that it would be great if cars could fly isn't going to get them off the ground.
  25. IDE != Eclipse/NetBeans/JBuilder/etc[ Go to top ]

    My take is that graphical interfaces to-date are good for making specific simple tasks less monotonous. But the more complex the task, the more the GUI gets in the way. One example I use often is that in a windowing environment, if I need to copy a few files from one place to another, I'll use a graphical interface. But if I need to change all 1000 filenames, I'm going to open up a prompt and do it with a text-based command.
    Not to be a Luddite or anything, but the Unix shell environment is still one of the best IDEs. With some technology-specific tools (e.g., Ant) and some shell scripts, it's possible to be at least as productive as with a graphical tool shell. It's infinitely extensible, configurable and powerful. Sure, there are some things that a GUI will be better at (like cut-n-paste :P), but for a lot of the tasks required to develop software, a command line is often a better way to do it.
  26. Not to be a Luddite or anything, but the Unix shell environment is still one of the best IDEs. With some technology-specific tools (e.g., Ant) and some shell scripts, it's possible to be at least as productive as with a graphical tool shell. It's infinitely extensible, configurable and powerful. Sure, there are some things that a GUI will be better at (like cut-n-paste :P), but for a lot of the tasks required to develop software, a command line is often a better way to do it.
    I find it hard to draw pictures in a shell but perhaps you are better at ascii art than me.
  27. Not to be a Luddite or anything, but the Unix shell environment is still one of the best IDEs. With some technology-specific tools (e.g., Ant) and some shell scripts, it's possible to be at least as productive as with a graphical tool shell. It's infinitely extensible, configurable and powerful. Sure, there are some things that a GUI will be better at (like cut-n-paste :P), but for a lot of the tasks required to develop software, a command line is often a better way to do it.
    Any good shell-based tool that does decent refactoring, JUnit integration, graphical debugging? :-) I mean, c'mon, it's 2007 already. Best, Nikita Ivanov. GridGain - Grid Computing Made Simple
  28. Re: Do We Need an "IDE 2.0" Revolution?[ Go to top ]

    I think the analogy is a bit awkward. It sounds as though you're suggesting that adopting a mechanised and automated approach to software is superior to the craftsmans approach. It sometimes seems that there is a never ending quest to eliminate the act of coding as though it is somehow wrong or 'evil'. As though software development is actually really easy, it's just these damn programming languages and platforms that get in the way. 4GLs have been around for a long, long time... Quality software development *is* hard and *is* complex and there is no escape from the merciless logic that computers impose on us. Adding layers of abstraction such as high level tools may hide underlying complexity of the platform but it cannot save you from the complexities of the problem domain.
  29. Re: Do We Need an "IDE 2.0" Revolution?[ Go to top ]

    So I'm starting to read this long winded articl... ..oh look! a butterfly. ooh!
  30. Re: Do We Need an "IDE 2.0" Revolution?[ Go to top ]

    Jens, I can certainly relate to this post. When I manage software projects, a considerable amount of effort at the start has to be given to setting up developer environments, choosing which frameworks, build, test case, code management, templating, etc. The time involved directly proprotionate to the number of more senior developers who brought their grab bag of scripts, config files, etc. More junior and new grads required having an "environment" designate to ask questions to throughout the project. I thought many times the art of development & problem solving was overshadowed with environment & tool details. The thought of abstracting the development to a level higher was something we always had discussions about. So we thought about building a tool that brought development to a level higher and enable us to get projects off the ground much faster. We didn't intend to build an IDE but it has evolved where users have used that term. The idea was to immediately start building the app in the first minute to start focusing on the problem & application, not the environment and build details. Not to mention address the constant pressure to show "progress" and show the end "agile" customer. So Jen (or anyone else interested reading this), I set up a demo server so if you'd like to give this tool a try, hit this link and I'd be happy to discuss your impressions http://simvm1.simunication.com/deployed-sim/viewSimulation.sim?simId=11521249067161543&uid=1145365660939202 (BTW, we currently market this tool for a different market but the IDE reference has percolated up from customers a number of times so your post was a good forum to get some feedback) Bryan bmaclean@simunication.com