Can anyone answer this?
Locked
 
|
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. |
Administrator
|
Miles seems to be conflating managing a development environment with managing a production environment. All large Smalltalk business users lock down their production environments and know *exactly* what's in them. I suspect Miles doesn't really understand what a “live coding environment” really means. Typically, it refers to an individual developer working on his own image. (Individual may encompass more than one person in e.g. a pair programming scenario.) Any shared environment, whether production, pre-prodcution/emergery fix, user acceptance testing, training, are all controlled environments. It would be insane to try otherwise.
Typical? No, I don't think so. GemStone customers definitely do not deploy all new images to their databases, as their database is their image. They load change sets, by necessity. GemStone customers who use GBS to replicate server data to a different "client" image, such as VisualWorks, *may* build a new image from scratch and deploy that in addition to the code deployed to the server/database. Generally, they do so because they feel that being able to build an environment from scratch and deploy it is an essential safety measure for their business. Many Smalltalk production operations include the ability to deploy patches, because it makes sense to leverage such capabilities. In a GemStone database, you always file-in just what you want. You could file-in all the code every time, rather than a delta, but that just creates unnecessary garbage. A VisualWorks/GBS client image could easily read and load patches from a designated directory when restarted or at any other controlled point in time. Umm. Yeah. (So is arguing from a false premise.) |
|
|
In reply to this post by horrido
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. |
Re: Can anyone answer this?
|
|
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 <[hidden email]> 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.
|
|
|
In reply to this post by horrido
On Wed, Jul 19, 2017 at 9:47 AM, horrido <[hidden email]> wrote:
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 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. |
|
In reply to this post by Stephane Ducasse-3
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 <[hidden email]> wrote: I do not see why live coding programming languages could not manage |
|
|
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
|
«
Return to Pharo Smalltalk Users
|
1 view|%1 views
| Free forum by Nabble | Edit this page |