5 ms·

What did JPMorgan use for their next project?

gaius 10y ago
http://techcareers.jpmorgan.com/cm/BlobServer/athena_jpmc.pdf?blobkey=id&blobwhere=1320615212303&blobheader=application/pdf&blobcol=urldata&blobtable=MungoBlobs http://techcareers.jpmorgan.com/cm/BlobServer/athena_jpmc.pd... C++ and Python
- throwaway7645 10y ago
  Yea, I often wonder about this kind of thing. Compared to Fortran, Common Lisp is a tower of power and sorcery, but compared to Python it isn't as impressive. Yes, it is a more powerful language, but the power isn't always worth the learning curve and mostly abandoned libraries. I think Python + C++ seems to be an easy spot marrying rapid prototyping & raw speed when you need it in addition to all the developers you'd get from 2 of the top 5 languages in amount of use. The Smalltalk and Common Lisp ecosystems are pretty similar to me. Both have a few commercial products and a few open source projects and a fairly small and fragmented community despite some commercial success.
  - brudgers 10y ago
    A lot of Common Lisp libraries are done rather than abandoned [Clojure inherits this property]. Common Lisp is stable because the spec is about twenty-five years old. Hence new behaviors introduced by software updates are either implementation extensions or regressions. If a new version of a Common Lisp implementation breaks an existing library, it is more likely a regression than a library corner case...and because libraries are stable, it is practical to test against what people are using in the field. I think Python and C++ are great languages, but when comparing them to Common Lisp -- or Smalltalk or discussing their merits in general -- there is the question of which Python and which C++ form the basis of comparison.
    - gaius 10y ago
      That is true in the sense that the fundamental algorithms and data structures and so on are maths and maths doesn't change. But the vast majority of them are available in Python libraries, and if you need something right now say a library interfacing to a particular DB or protocol, there is a very high probability that in Python you can pip it in a minute and it will basically work, vs having to do it yourself in Lisp - and it's not cool fun stuff like a new algorithm, it's dull boring work of reverse engineering and hacking around the bugs in someone else's product, and Lisp doesn't give you any leverage there.
      - brudgers 10y ago
        Architecturally, how often is there a slam dunk engineering case that the core business logic should handle an obscure protocol or oddball database directly rather than abstracting over the requirements and leaving the implementation details to another layer in the stack? While Python is not Javascript, 'pip what?' For SQL: https://pypi.python.org/pypi?%3Aaction=search&term=sql&submit=search https://pypi.python.org/pypi?%3Aaction=search&term=sql&submi... For RabbitMQ?: https://pypi.python.org/pypi?%3Aaction=search&term=rabbitmq&submit=search https://pypi.python.org/pypi?%3Aaction=search&term=rabbitmq&... For Hadoop?: https://pypi.python.org/pypi?%3Aaction=search&term=hadoop&submit=search https://pypi.python.org/pypi?%3Aaction=search&term=hadoop&su... Having PiP (or Quicklisp) does not so much solve the problem as transfer it to a problem in a different domain. The new problem may or may not be easier to solve than the original one. Sometimes Nginx is a good answer. Sometimes SimpleHTTPServer is. Sometimes Sinatra. Sometimes Rails.
        gaius 10y ago
        Sure, knowing your way around the ecosystem is a thing. But that ecosystem has to exist and be kept up to date. And you wouldn't want to hire someone who was too keen on reinventing the wheel anyway... Plus, it is a slam dunk case that most organisations will not benefit from choosing a "best" language for every project or use case and should instead settle on as few as possible... One HLL (e.g. Python or Tcl or Perl) and one low-level (C or C++) is probably the best bet for 99% of organisations.

gaius 10y ago

http://techcareers.jpmorgan.com/cm/BlobServer/athena_jpmc.pdf?blobkey=id&blobwhere=1320615212303&blobheader=application/pdf&blobcol=urldata&blobtable=MungoBlobs http://techcareers.jpmorgan.com/cm/BlobServer/athena_jpmc.pd... C++ and Python

throwaway7645 10y ago
Yea, I often wonder about this kind of thing. Compared to Fortran, Common Lisp is a tower of power and sorcery, but compared to Python it isn't as impressive. Yes, it is a more powerful language, but the power isn't always worth the learning curve and mostly abandoned libraries. I think Python + C++ seems to be an easy spot marrying rapid prototyping & raw speed when you need it in addition to all the developers you'd get from 2 of the top 5 languages in amount of use. The Smalltalk and Common Lisp ecosystems are pretty similar to me. Both have a few commercial products and a few open source projects and a fairly small and fragmented community despite some commercial success.
- brudgers 10y ago
  A lot of Common Lisp libraries are done rather than abandoned [Clojure inherits this property]. Common Lisp is stable because the spec is about twenty-five years old. Hence new behaviors introduced by software updates are either implementation extensions or regressions. If a new version of a Common Lisp implementation breaks an existing library, it is more likely a regression than a library corner case...and because libraries are stable, it is practical to test against what people are using in the field. I think Python and C++ are great languages, but when comparing them to Common Lisp -- or Smalltalk or discussing their merits in general -- there is the question of which Python and which C++ form the basis of comparison.
  - gaius 10y ago
    That is true in the sense that the fundamental algorithms and data structures and so on are maths and maths doesn't change. But the vast majority of them are available in Python libraries, and if you need something right now say a library interfacing to a particular DB or protocol, there is a very high probability that in Python you can pip it in a minute and it will basically work, vs having to do it yourself in Lisp - and it's not cool fun stuff like a new algorithm, it's dull boring work of reverse engineering and hacking around the bugs in someone else's product, and Lisp doesn't give you any leverage there.
    - brudgers 10y ago
      Architecturally, how often is there a slam dunk engineering case that the core business logic should handle an obscure protocol or oddball database directly rather than abstracting over the requirements and leaving the implementation details to another layer in the stack? While Python is not Javascript, 'pip what?' For SQL: https://pypi.python.org/pypi?%3Aaction=search&term=sql&submit=search https://pypi.python.org/pypi?%3Aaction=search&term=sql&submi... For RabbitMQ?: https://pypi.python.org/pypi?%3Aaction=search&term=rabbitmq&submit=search https://pypi.python.org/pypi?%3Aaction=search&term=rabbitmq&... For Hadoop?: https://pypi.python.org/pypi?%3Aaction=search&term=hadoop&submit=search https://pypi.python.org/pypi?%3Aaction=search&term=hadoop&su... Having PiP (or Quicklisp) does not so much solve the problem as transfer it to a problem in a different domain. The new problem may or may not be easier to solve than the original one. Sometimes Nginx is a good answer. Sometimes SimpleHTTPServer is. Sometimes Sinatra. Sometimes Rails.
      - gaius 10y ago
        Sure, knowing your way around the ecosystem is a thing. But that ecosystem has to exist and be kept up to date. And you wouldn't want to hire someone who was too keen on reinventing the wheel anyway... Plus, it is a slam dunk case that most organisations will not benefit from choosing a "best" language for every project or use case and should instead settle on as few as possible... One HLL (e.g. Python or Tcl or Perl) and one low-level (C or C++) is probably the best bet for 99% of organisations.