>The good developers / expert users will not do what you state. The eclipse >debug, inspector, watches >are very much part of a normal dev cycle in our >place with around 100 devs.
This is not a problem of being expert or not. In languages like C/C++ you often need to deploy additional debug infos with the runtime (debug symbols in COFF, ...) to get anything useful - which usually is not done by default and needs additional effort if you want to debug in production. Situation in Java is better from the tooling side because there are no different CPU architectures/instruction sets to consider - just one bytecode set and one JVM. There are nice tools to monitor or debug - but still you have to run the JVM with debug option and debugging from the external side to get the right debugging experience with stepping through the code. So if you want to debug a web-app in Java the same way you debug at development time you would have to restart your JBoss, Websphere, ... and connect to a specific debug port. That is usually not done in a productive Java app because of a production downtime, limited developer access to it, ... And yes - there is JMX with MBeans, but this is more for monitoring than real debugging. Comparing inspectors of Eclipse with the inspectors of Smalltalk is comparing apples with oranges. For sure Eclipse has catched up with the IDE and is now also providing inspectors in the UI, also allows evaluating limited expression and good watches. In Smalltalk you can implement you own inspectors/install them at runtime/change similar to anything other. You can even load new tools and later remove them while running. As we know Smalltalk is different in many regards. Typical Debugging in other languages is often dealing with the already deceased. Developers work with logging info from production or at a crashed heap dump, etc. Errors are then often reproduced back in the IDE/dev environment. Unfortunately this often means additional costs and more time before a fix is ready - but the World seems to be satisfied with this already In Smalltalk you can easily catch specific cases while running. You can easily add code at runtime to check issues (if developer tools are not stripped): shopItem id = 1234567 ifTrue: [ shopItem inspect ] and even save a copy of the image at a specific point in time/situation for offline inspection. This is not comparable to a dump because the time to debug in ST tends to zero. While in Java you have to resetup the environment/IDE with the code version, etc. You can even manipulate and fix data in production easily with Smalltalk: shopItem id = 1234567 ifTrue: [ shopItem price: 12.3s2 ] And ... you can also shoot yourself in the foot if not done carefully ;) Debugging in Smalltalk is different: you do not debug from the outside - you do not have to restart the program and navigate to the point where it happened. If the developer tools are included you can just switch and use them. You also do not have to recompile the whole thing when you found the problem. If there is an easy workaround you can directly apply it to your program and later fix it in the development stream. So Smalltalk - as a changeable dynamic object system - is here more comparable to a database. You do not have to stop while it is running in production and you can change and inspect or even fix the program at will. With all the up's and downs of this approach. I doubt that this could/should be marketed as a killer feature. We should keep it as our own little secret. But it is not only a question of technical feasability: often "production environment" is seen as "holy" and "untouchable" for other reasons like security. So nobody is missing something when the developers do not debug/work directly in production. Bye T.
