(next Rich)
101–110 of 158 posts
Re: (next Rich)
#102I wrote my first trading system in Clojure because a few of the libraries we relied on were in java. It was 2011 and I'd had about 3 years of lisp experience. I got a bit of side eye from people when I told them I was using a relatively new programming language but the fact that it was based on the JVM, which alot of HFT firms were using helped make the case. We didn't use if for more than a few years before it was r…
So you had to switch to C++ because Clojure / Java wasn't performant enough?
Languages aren't "performant". You can write good or bad code in most languages, or code that isn't a good fit for a language.
That said, there are languages which will make you incur certain penalties, as there is a price to be paid for automatic memory management with garbage collection, for example. These penalties generally do not matter except for edge cases (and HFT trading might very well be one!).
There are also languages which help you write much faster code, but on a higher level. Clojure transducers are a good example: pipelines built of composable transformations, where data sequences are not fully realized between the transformations. These can provide significant performance (and memory allocation) improvements, while still letting you write high-level code.
Re: (next Rich)
#103Earlier quoted context omitted.
Hah, very fitting way to put it :)
Agree. For those not familiar with Rich's famous use of etymology, see his 2011 presentation "Simple made Easy" as a good example: https://www.infoq.com/presentations/Simple-Made-Easy/ Side question: Rich seems to use etymology as a tool for original thinking and clear explanations. Are there other people who do this as well as he does?
Re: (next Rich)
#104Re: (next Rich)
#105Re: (next Rich)
#106Rich, thank you for creating and maintaining a tool that has helped me build a successful SaaS business. I could not have done this without your work and your insights. I also learned a lot from your talks, and I do hope to meet you again at one of the Clojure conferences.
Re: (next Rich)
#107Rich has to be my favorite thinker in this space, absolutely love his talks and the way he articulates things, and I often draw from his philosophies in my work But, I've always been turned off to Clojure by the lack of static typing (I know spec exists, but it's not really the same thing). I did a little project once to try it out, and even there I found myself spending time debugging basic issues like passing the w…
Re: (next Rich)
#108Rich has to be my favorite thinker in this space, absolutely love his talks and the way he articulates things, and I often draw from his philosophies in my work But, I've always been turned off to Clojure by the lack of static typing (I know spec exists, but it's not really the same thing). I did a little project once to try it out, and even there I found myself spending time debugging basic issues like passing the w…
It's a matter of habit. Once you get used to it, you quickly know how or why it happens and where (especially when you follow the correct workflow, see below). Modern editors/IDEs help a lot with the typos and wrong number of args. Some advice I would give myself when I started learning Clojure: Think not in types, but in data. It's a different model that requires an 'aha' moment, but it's revelatory when you do get…
It’s like having a conversation with your program while you are developing it.
Re: (next Rich)
#109Rich Hickey's talks inspired me to explore Clojure and functional programming in college. That led to a part of my career where I got to help advance an FP language (F#). Can't say it was a raging success, but it wasn't a raging failure either. Really happy things worked out the way they did, though. I still look back at my senior project, written in Clojure, from time to time and find it elegant in a unique way.