Re: Smalltalk Article
Locked
 
|
You would be amazed what percentage of j.p. morgan's profit comes from
that app (and the group that uses it). This is one case where a case study didn't emphasise enough how important the app is to the business (though as someone pointed out, the app's success is probably due to GemstoneS as much or more than VW) Kelly Hall <[hidden email]> wrote in message news:<u8J6d.21636$[hidden email]>... > Jaroslaw Podgajny wrote: > > "JPMorgan Derives Clear Benefits From Cincom Smalltalk" - there is > > GemStone there too. > > As a practicing engineer who enjoys seeing niche programming languages > used successfully, I say bully for JP Morgan. > > As a JP Mogan shareholder who has watched the share price drop 15-30% > over the last 5 years, I say there's obviously a difference between > deriving "clear benefits" and deriving "significantly profitable benefits". > > Kelly |
|
|
allClass wrote:
> You would be amazed what percentage of j.p. morgan's profit comes from > that app (and > the group that uses it). This is one case where a case study didn't > emphasise enough > how important the app is to the business (though as someone pointed > out, the app's success > is probably due to GemstoneS as much or more than VW) In this case the value is from VisualWorks. I'm reliably informed by people at JPMC that GemstoneS is simply used to persist data and that all of the "analytics" that constitute the application are implemented on VisualWorks (apart from some matrix floating-point primitives coded in C). > Kelly Hall <[hidden email]> wrote in message news:<u8J6d.21636$[hidden email]>... > >>Jaroslaw Podgajny wrote: >> >>>"JPMorgan Derives Clear Benefits From Cincom Smalltalk" - there is >>>GemStone there too. >> >>As a practicing engineer who enjoys seeing niche programming languages >>used successfully, I say bully for JP Morgan. >> >>As a JP Mogan shareholder who has watched the share price drop 15-30% >>over the last 5 years, I say there's obviously a difference between >>deriving "clear benefits" and deriving "significantly profitable benefits". >> >>Kelly -- _______________,,,^..^,,,____________________________ Eliot Miranda Smalltalk - Scene not herd |
|
|
It's a configurable and complex object model. Mapping it to a relational
database would be non-trivial. GemStone/S adds value because it can store the objects natively. Anyone that has worked on a complex Smalltalk application with a relational persistence layer knows the pain of that kind of overhead. -- Bob Nemec Northwater Objects "Eliot Miranda" <[hidden email]> wrote in message news:P%F9d.26709$[hidden email]... > > > allClass wrote: >> You would be amazed what percentage of j.p. morgan's profit comes from >> that app (and >> the group that uses it). This is one case where a case study didn't >> emphasise enough >> how important the app is to the business (though as someone pointed >> out, the app's success >> is probably due to GemstoneS as much or more than VW) > > In this case the value is from VisualWorks. I'm reliably informed by > people at JPMC that GemstoneS is simply used to persist data and that all > of the "analytics" that constitute the application are implemented on > VisualWorks (apart from some matrix floating-point primitives coded in C). > > >> Kelly Hall <[hidden email]> wrote in message >> news:<u8J6d.21636$[hidden email]>... >> >>>Jaroslaw Podgajny wrote: >>> >>>>"JPMorgan Derives Clear Benefits From Cincom Smalltalk" - there is >>>>GemStone there too. >>> >>>As a practicing engineer who enjoys seeing niche programming languages >>>used successfully, I say bully for JP Morgan. >>> >>>As a JP Mogan shareholder who has watched the share price drop 15-30% >>>over the last 5 years, I say there's obviously a difference between >>>deriving "clear benefits" and deriving "significantly profitable >>>benefits". >>> >>>Kelly > > -- > _______________,,,^..^,,,____________________________ > Eliot Miranda Smalltalk - Scene not herd >
Bob Nemec
|
|
|
Dear Eliot and Bob,
in essence, you are both correct. Both VisualWorks and GemStone/S are essential to the system's power. Most of the code is in VisualWorks. GemStone/S adds certain important capabilities; as Bob suggests, an effective customisable native Smalltalk persistence mapping is one. In my talk at ESUG last month, I described how it was an early design decision to keep all the financial domain model code in VisualWorks, GemStone acting as a virtual memory extension at this level, whereas the infrastructure model that underlies the financial one has code in both VisualWorks and GemStone. I mentioned some corollaries of this decision. Then Adriaan van Os (of SOOPS) gave a talk in which he mentioned that, in their system, they write all the domain code in a common base smalltalk that runs in either dialect, so can be moved between VisualWorks and GemStone at will. These alternative design decisions seemed to me to represent the two extremes between the various patterns people can use for domain behaviour. It's great to have this choice. Yours faithfully Niall Ross "Bob Nemec" <[hidden email]> wrote in message news:4167dad1$[hidden email]... > It's a configurable and complex object model. Mapping it to a relational > database would be non-trivial. GemStone/S adds value because it can store > the objects natively. Anyone that has worked on a complex Smalltalk > application with a relational persistence layer knows the pain of that kind > of overhead. > -- > Bob Nemec > Northwater Objects > > "Eliot Miranda" <[hidden email]> wrote in message > news:P%F9d.26709$[hidden email]... > > > > > > allClass wrote: > >> You would be amazed what percentage of j.p. morgan's profit comes from > >> that app (and > >> the group that uses it). This is one case where a case study didn't > >> emphasise enough > >> how important the app is to the business (though as someone pointed > >> out, the app's success > >> is probably due to GemstoneS as much or more than VW) > > > > In this case the value is from VisualWorks. I'm reliably informed by > > people at JPMC that GemstoneS is simply used to persist data and that > > of the "analytics" that constitute the application are implemented on > > VisualWorks (apart from some matrix floating-point primitives coded in C). > > > > .... |
|
|
Another important aspect that GemStone provides is data sharing and
conflict resolution. A feature of a persistence layer, which people do not always appreciate - they usually think "storing data so one can read them tomorrow." And data sharing is very important in Kapital. Like Niall says GemStone and VisualWorks work in tandem in the application and I would not risk saying which is more important. Regards, Jaroslaw. Niall Ross wrote: > Dear Eliot and Bob, > in essence, you are both correct. Both VisualWorks and GemStone/S are > essential to the system's power. Most of the code is in VisualWorks. > GemStone/S adds certain important capabilities; as Bob suggests, an > effective customisable native Smalltalk persistence mapping is one. > > In my talk at ESUG last month, I described how it was an early design > decision to keep all the financial domain model code in VisualWorks, > GemStone acting as a virtual memory extension at this level, whereas the > infrastructure model that underlies the financial one has code in both > VisualWorks and GemStone. I mentioned some corollaries of this decision. > Then Adriaan van Os (of SOOPS) gave a talk in which he mentioned that, in > their system, they write all the domain code in a common base smalltalk that > runs in either dialect, so can be moved between VisualWorks and GemStone at > will. > > These alternative design decisions seemed to me to represent the two > extremes between the various patterns people can use for domain behaviour. > It's great to have this choice. > > Yours faithfully > Niall Ross > > > "Bob Nemec" <[hidden email]> wrote in message > news:4167dad1$[hidden email]... > >>It's a configurable and complex object model. Mapping it to a relational >>database would be non-trivial. GemStone/S adds value because it can store >>the objects natively. Anyone that has worked on a complex Smalltalk >>application with a relational persistence layer knows the pain of that > > kind > >>of overhead. >>-- >>Bob Nemec >>Northwater Objects >> >>"Eliot Miranda" <[hidden email]> wrote in message >>news:P%F9d.26709$[hidden email]... >> >>> >>>allClass wrote: >>> >>>>You would be amazed what percentage of j.p. morgan's profit comes from >>>>that app (and >>>>the group that uses it). This is one case where a case study didn't >>>>emphasise enough >>>>how important the app is to the business (though as someone pointed >>>>out, the app's success >>>>is probably due to GemstoneS as much or more than VW) >>> >>>In this case the value is from VisualWorks. I'm reliably informed by >>>people at JPMC that GemstoneS is simply used to persist data and that > > all > >>>of the "analytics" that constitute the application are implemented on >>>VisualWorks (apart from some matrix floating-point primitives coded in > > C). > >>>.... > > > |
«
Return to Dolphin Smalltalk
|
1 view|%1 views
| Free forum by Nabble | Edit this page |