"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."
Visual Studio can do this with Edit and Continue https://www.youtube.com/watch?v=M6J34B37wUc So the world definitely starts to catch up with Smalltalk. Which can only be a good thing. On Thu, Apr 24, 2014 at 12:26 PM, Torsten Bergmann <asta...@gmx.de> wrote: > >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. > > > > > > > > >
