Miles Fidelman (at Quora) and I were having an argument about the suitability of Smalltalk (Pharo) for large maintainable software projects. The problem is, I've never used Smalltalk in a commercial setting, esp. with respect to large projects. Without that experience, I am wholly unqualified to answer his response, which follows... *I just spent a little time looking at a couple of big projects that use(d) Smalltalk - JWARS & the Seaside web server. And I discovered that both have basically avoided the âlive coding environmentâ aspects of Smalltalk. JWARS incorporates a lot of access & configuration controls that limit who can change which parts of the system. Seaside seems to follow standard development processes - with a version control system, and formal releases. Which kind of reinforces what I see as issues with Smalltalk from a system building & maintenance point of view: 1) When everything is a work in progress, itâs impossible to manage a project, maintain deployed code (âwhat version do you have, what did you modify? clearly thatâs where the bug isâ), update things (interfaces change, updates overwrite local mods), etc. 2) The typical deployment model is to deploy a completely new virtual machine & environment. For some things (e.g., servers), that works - and seems to be the way of the world with containerization - but for other things (e.g., desktop applications), deploying an entire new environment for every patch is just a bit match. 3) Gross violation of âprinciple of least privilege.â Live code, particularly multi-user code, that can be modified by its users - now that is a surefire recipe for disaster.* -- View this message in context: http://forum.world.st/Can-anyone-answer-this-tp4955861.html Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com.
Well ..... I worked on JWARS for 13 years until the Navy killed it at the end of 2010, and I have never heard of Miles Fidelman. JWARS was run almost exclusively in SCIFs (secure facilities), and most of the users did not have access to the source code. So I do not know where Miles gets his information. JWARS had extensive version control. All new versions of the main config maps were tagged with extensive information about what was included. I agree with what Richard says below, "I suspect Miles doesn't really understand what a âlive coding environmentâ really means.", although I would phrase it less gently. -- View this message in context: http://forum.world.st/Can-anyone-answer-this-tp4955861p4955916.html Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com.
I do not see why live coding programming languages could not manage their source code in versioning control system. To me, people opposing live coding and released/versioned software are just **PLAIN** idiots. Period. You can have a live reflective system and still want to have a fully reproducible built system. This is what we do with Pharo. We manage everything with a version control system and still Pharo is fully dynamic. And No not everybody can commit and change Pharo. About large and complex systems, I heard that an insurance company has 30 Millions lines Smalltalk application. and this system is live and also versioned! Hopefully. So do not lose your energy with idiots. Stef On Wed, Jul 19, 2017 at 8:18 PM, jWarrior <dmacq@erols.com> wrote:
Well .....
I worked on JWARS for 13 years until the Navy killed it at the end of 2010, and I have never heard of Miles Fidelman. JWARS was run almost exclusively in SCIFs (secure facilities), and most of the users did not have access to the source code. So I do not know where Miles gets his information.
JWARS had extensive version control. All new versions of the main config maps were tagged with extensive information about what was included.
I agree with what Richard says below, "I suspect Miles doesn't really understand what a âlive coding environmentâ really means.", although I would phrase it less gently.
-- View this message in context: http://forum.world.st/Can-anyone-answer-this-tp4955861p4955916.html Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com.
JWARS has 1.2 million lines of code. The longest method did Object to Relational database mapping. -- View this message in context: http://forum.world.st/Can-anyone-answer-this-tp4955861p4955922.html Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com.
I agree The stupidity of opposing live coding is that they only language that a computer can execute , machine code, is a live coding language. Live coding is extremely essential for machine coding and it does this through several way , using pointer registers to control flow of execution giving access to its registers that can even store execution instructions etc etc. To make matters worse for those opposing live coding , live coding is not only implemented at machine code level but also OS level. Memory mapped files are equivalent if not more powerful than Pharo images and there is also system exceptions to capture errors and lively replace code and of course shared memory which is crucial for the use of DLLs. There is also the ability of loading code as data in a place in memory and then mark that area executable and execute the code. It's the programming languages themselves that don't support live coding out of the box with the convenience of Pharo but because they are obliged to support OS features live coding is also something you can use with any programming language out there. Live coding is pretty much in the core of computer technology. It's pretty much obligatory for testing and debugging purposes which why also C debuggers com with live coding features. Version control systems and sandboxes environments are unrelated to live coding which is merely a way of coding and by no means against it with some exceptions. On Wed, 19 Jul 2017 at 22:11, Stephane Ducasse <stepharo.self@gmail.com> wrote:
I do not see why live coding programming languages could not manage their source code in versioning control system. To me, people opposing live coding and released/versioned software are just **PLAIN** idiots. Period. You can have a live reflective system and still want to have a fully reproducible built system. This is what we do with Pharo. We manage everything with a version control system and still Pharo is fully dynamic. And No not everybody can commit and change Pharo.
About large and complex systems, I heard that an insurance company has 30 Millions lines Smalltalk application. and this system is live and also versioned! Hopefully. So do not lose your energy with idiots.
Stef
On Wed, Jul 19, 2017 at 8:18 PM, jWarrior <dmacq@erols.com> wrote:
Well .....
I worked on JWARS for 13 years until the Navy killed it at the end of 2010, and I have never heard of Miles Fidelman. JWARS was run almost exclusively in SCIFs (secure facilities), and most of the users did not have access to the source code. So I do not know where Miles gets his information.
JWARS had extensive version control. All new versions of the main config maps were tagged with extensive information about what was included.
I agree with what Richard says below, "I suspect Miles doesn't really understand what a âlive coding environmentâ really means.", although I would phrase it less gently.
-- View this message in context: http://forum.world.st/Can-anyone-answer-this-tp4955861p4955916.html Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com.
It would be nice if the JPMorgan folks could comment on this one (their system is now 20 years old I think, its huge, has had large numbers of people successfully working on it - concurrently) and I know they did leverage live coding ability particularly in error scenarios however there is a caveat - in that I think financial regulations curbed some of the live changeability to prevent any hint of fraud. Tim
On 20 Jul 2017, at 09:19, Dimitris Chloupis <kilon.alios@gmail.com> wrote:
I agree
The stupidity of opposing live coding is that they only language that a computer can execute , machine code, is a live coding language. Live coding is extremely essential for machine coding and it does this through several way , using pointer registers to control flow of execution giving access to its registers that can even store execution instructions etc etc. To make matters worse for those opposing live coding , live coding is not only implemented at machine code level but also OS level. Memory mapped files are equivalent if not more powerful than Pharo images and there is also system exceptions to capture errors and lively replace code and of course shared memory which is crucial for the use of DLLs. There is also the ability of loading code as data in a place in memory and then mark that area executable and execute the code.
It's the programming languages themselves that don't support live coding out of the box with the convenience of Pharo but because they are obliged to support OS features live coding is also something you can use with any programming language out there.
Live coding is pretty much in the core of computer technology. It's pretty much obligatory for testing and debugging purposes which why also C debuggers com with live coding features.
Version control systems and sandboxes environments are unrelated to live coding which is merely a way of coding and by no means against it with some exceptions.
On Wed, 19 Jul 2017 at 22:11, Stephane Ducasse <stepharo.self@gmail.com <mailto:stepharo.self@gmail.com>> wrote: I do not see why live coding programming languages could not manage their source code in versioning control system. To me, people opposing live coding and released/versioned software are just **PLAIN** idiots. Period. You can have a live reflective system and still want to have a fully reproducible built system. This is what we do with Pharo. We manage everything with a version control system and still Pharo is fully dynamic. And No not everybody can commit and change Pharo.
About large and complex systems, I heard that an insurance company has 30 Millions lines Smalltalk application. and this system is live and also versioned! Hopefully. So do not lose your energy with idiots.
Stef
On Wed, Jul 19, 2017 at 8:18 PM, jWarrior <dmacq@erols.com <mailto:dmacq@erols.com>> wrote:
Well .....
I worked on JWARS for 13 years until the Navy killed it at the end of 2010, and I have never heard of Miles Fidelman. JWARS was run almost exclusively in SCIFs (secure facilities), and most of the users did not have access to the source code. So I do not know where Miles gets his information.
JWARS had extensive version control. All new versions of the main config maps were tagged with extensive information about what was included.
I agree with what Richard says below, "I suspect Miles doesn't really understand what a âlive coding environmentâ really means.", although I would phrase it less gently.
-- View this message in context: http://forum.world.st/Can-anyone-answer-this-tp4955861p4955916.html <http://forum.world.st/Can-anyone-answer-this-tp4955861p4955916.html> Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com.
On Wed, Jul 19, 2017 at 9:47 AM, horrido <horrido.hobbies@gmail.com> wrote:
1) When everything is a work in progress, itâs impossible to manage a project, maintain deployed code (âwhat version do you have, what did you modify? clearly thatâs where the bug isâ), update things (interfaces change, updates overwrite local mods), etc.
I've been working on a big production Smalltalk application (IBM Smalltalk / VisualAge) for a long time, and the approach we take is to use the development environment for R&D, and with select beta customers, and then periodically package a runtime when we want to release to the customer base. It gives the best of both worlds: a live development environment with the myriad debugging and productivity advantages that that brings, and a more conventional deployment model for the customers.
2) The typical deployment model is to deploy a completely new virtual machine & environment. For some things (e.g., servers), that works - and seems to be the way of the world with containerization - but for other things (e.g., desktop applications), deploying an entire new environment for every patch is just a bit match.
Don't know why you'd need to deploy a completely new VM and environment with each release. When we give a customer an update, we give them a new packaged runtime image, which is a small fraction of the size of the VM and its supporting files. When we had a Smalltalk "fat client" (now our UI is RESTful web services and XHR-heavy web app), deploying the runtime image for each release worked well.
participants (6)
-
Bob Hartwig -
Dimitris Chloupis -
horrido -
jWarrior -
Stephane Ducasse -
Tim Mackinnon