3 ms·

> I believe an influence was actually an old system that used smalltalk in the 90ies at JPM. Imagine the benefit to the business had they just stuck with Small

by zeveb 6y ago

> I believe an influence was actually an old system that used smalltalk in the 90ies at JPM. Imagine the benefit to the business had they just stuck with Smalltalk the whole time! It is remarkable how many businesses could have been quietly making money for years using a high-quality dynamic language such as Smalltalk or Lisp rather than going through the whole C/C++/Java/Python/Ruby/JavaScript/Go treadmill. But I guess if they had done that then their programmers might not have gotten to type as many {}! Nor gotten to reinvent the wheel so often.

lucozade 6y ago
Kapital (the Smalltalk system) wasn't much of an influence on Athena. Athena was very much a SecDB/Slang derived effort. And Kapital was an interesting experiment but rightfully died. Smalltalk just wasn't the right environment for something that complex and scale. I'd expect most lisps to suffer in the same way. And TBH it was more the image based model rather than the dynamic language per se though that was an issue. There's a point where dynamism becomes a liability and Kapital went way beyond that point. Python fares a bit better but still, a huge effort is needed to control its failings at scale. This isn't helped at all by sticking a DAG in the middle of it as was done with Athena and its ilk. This all can be made to work but in the "cos its Turing complete" sense rather than the language helping in any meaningful way. Source: I suffered through it.
- FabHK 6y ago
  > This all can be made to work but in the "cos its Turing complete" sense rather than the language helping in any meaningful way. I had to LOL. You have very nicely put into words an experience I bet many have had.
- JackFr 6y ago
  Kapital was also rewritten in Java and survived in a few successor places ('Derivatives Studio' at CSFB). There it was my introduction to 'thunks'.
- eru 6y ago
  > I'd expect most lisps to suffer in the same way. Why? Eg Scheme or even the uglier Common Lisp are quite disciplined. And Clojure ain't too bad either. As far as I can tell, Lispers don't usually go around monkey-patching things.
  - barrkel 6y ago
    Elispers certainly do!
    - eru 6y ago
      Oh, definitely. But no one in their right mind would use emacs lisp. Or any dynamically-by-default scoped Lisp.
eitland 6y ago
And all the time they saved they could have used to train new devs, reinvent a(nother) new vcs, figured out a new way to deploy image based software etc? (I realize Smalltalk is great, but my point is it has its issues as well otherwise I recon sooner or later the advantages would be so clear that Amazon or Google or someone would be all over it since it would give them a competitive edge ...)
cdavid 6y ago
I don't anything about smalltalk, but one issue that was highlighted at that time was the inability to scale the number of "objects" to the required numbers (I can't remember exact typology, sorry). They used one of the smalltalk provider at that time, and went way beyond the upper limit. That was the official story anyway. A lot of things were claimed when I worked there, a lot of it BS. The culture in banking was definitely not for me: generally fairly smart people, but very perverse culture. This was the only environment I ever worked where people who actually lie to my face to make sure I made mistake when coding and fail. Everything was custom, and sometimes that meant athena, sometimes that meant terrible systems such as a "distributed database" that was a single threaded wrapper on top of an C++ STL hashmap running on NFS. The guy behind it was reworking its own protocol based on UDP instead of TCP because said system was too slow... There was 0 abstraction, so if you wanted something such as EUR/USD pair, you had to ask the one guy who knew which id it was, so that you could get the data from in code. To this day I am convinced this was done on purpose for job security.

by zeveb 6y ago

lucozade 6y ago

Kapital (the Smalltalk system) wasn't much of an influence on Athena. Athena was very much a SecDB/Slang derived effort. And Kapital was an interesting experiment but rightfully died. Smalltalk just wasn't the right environment for something that complex and scale. I'd expect most lisps to suffer in the same way. And TBH it was more the image based model rather than the dynamic language per se though that was an issue. There's a point where dynamism becomes a liability and Kapital went way beyond that point. Python fares a bit better but still, a huge effort is needed to control its failings at scale. This isn't helped at all by sticking a DAG in the middle of it as was done with Athena and its ilk. This all can be made to work but in the "cos its Turing complete" sense rather than the language helping in any meaningful way. Source: I suffered through it.

FabHK 6y ago
> This all can be made to work but in the "cos its Turing complete" sense rather than the language helping in any meaningful way. I had to LOL. You have very nicely put into words an experience I bet many have had.
JackFr 6y ago
Kapital was also rewritten in Java and survived in a few successor places ('Derivatives Studio' at CSFB). There it was my introduction to 'thunks'.
eru 6y ago
> I'd expect most lisps to suffer in the same way. Why? Eg Scheme or even the uglier Common Lisp are quite disciplined. And Clojure ain't too bad either. As far as I can tell, Lispers don't usually go around monkey-patching things.
- barrkel 6y ago
  Elispers certainly do!
  - eru 6y ago
    Oh, definitely. But no one in their right mind would use emacs lisp. Or any dynamically-by-default scoped Lisp.

eitland 6y ago

And all the time they saved they could have used to train new devs, reinvent a(nother) new vcs, figured out a new way to deploy image based software etc? (I realize Smalltalk is great, but my point is it has its issues as well otherwise I recon sooner or later the advantages would be so clear that Amazon or Google or someone would be all over it since it would give them a competitive edge ...)

cdavid 6y ago

I don't anything about smalltalk, but one issue that was highlighted at that time was the inability to scale the number of "objects" to the required numbers (I can't remember exact typology, sorry). They used one of the smalltalk provider at that time, and went way beyond the upper limit. That was the official story anyway. A lot of things were claimed when I worked there, a lot of it BS. The culture in banking was definitely not for me: generally fairly smart people, but very perverse culture. This was the only environment I ever worked where people who actually lie to my face to make sure I made mistake when coding and fail. Everything was custom, and sometimes that meant athena, sometimes that meant terrible systems such as a "distributed database" that was a single threaded wrapper on top of an C++ STL hashmap running on NFS. The guy behind it was reworking its own protocol based on UDP instead of TCP because said system was too slow... There was 0 abstraction, so if you wanted something such as EUR/USD pair, you had to ask the one guy who knew which id it was, so that you could get the data from in code. To this day I am convinced this was done on purpose for job security.