3 ms·

As a typescript developer who is now starting his PhD in finance, I asked myself recently which of these languages should I pick, taking into account how easy i

As a typescript developer who is now starting his PhD in finance, I asked myself recently which of these languages should I pick, taking into account how easy is to code in each language. To this end I tried to code a quick probability calculator based on the poisson-binomial distribution. I found that R has the best libraries. It's the easiest language to use but it's also easy to write spaghetti code. Static analysis is a joke. Writing code in Julia is slower/more tiresome. I have to annotate all structs and function input types. In languages like typescript, I would see this as an investment because tsserver will later use that information for linting and autocompletion, so the net return is clearly positive. In Julia however static analysis is very primitive and limited, you feel like having to write code twice: once for annotations and then again for the implementation, with very limited cross-checking between the two. When writing functions, output types are so hard to annotate that I just skip them completely and only annotate input types. Type errors are usually caught at runtime. The runtime messages are helpful though. Unfortunately I couldn't even find a reputable Poisson-binomial package for Python so I stopped here. From my limited experience with python in other projects, I think that static analysis using pyright is mature and worth using (nets a positive return, although inferior to tsserver). This experience varies greatly between frameworks and packages, it's only worth to annotate the code if the underlying libraries also provide type hints.

Sukera 4y ago
> I have to annotate all structs and function input types. Can you elaborate on that? Argument types in function definitions do not help the compiler infer types - you can leave them completely untyped. It's really only required in struct fields, so that the compiler can know the size of your struct and doesn't have to box everything.
- jakobnissen 4y ago
  It's not even needed in struct fields. If Python, Matlab and R are viable alternatives, then surely OP does not care about performance and can choose a completely dynamic style of Julia. (I don't recommend it though, having some idea of type safety is in general a good idea)
- javitury 4y ago
  My bad, I didn't express myself properly. The Julia language requires structs to be annotated and only those, you are right. Then if you want to reach a primitive level of type safety, function input types have to be annotated.
  - freemint 4y ago
    This doesn't match with my experience. Julia is really excellent at infering complicated types. What you might be running into is type ambiguity though where Julia has to resort to unions because that's what the loops needs to work. Have a look at @code_warntype of some function call to see if that is the problem.
  - Sukera 4y ago
    Ah, I see, you're referring to linting capabilities. Yes, that's unfortunately a current limitation of LanguageServer.jl right now. I don't think it interfaces extensively with the compiler for type inference in a way that it crossreferences callers in the current code base, though it certainly could. That capability just hasn't been implemented yet I think. Regardless, that's orthogonal to being type safe.
  - ninjin 4y ago
    No, it does not: julia> struct Foo a end julia> Foo(17) Foo(17) julia> Foo("bar") Foo("bar") People should absolutely criticise Julia for its faults, but I would expect them to at least learn and understand the very basics of the language before doing so. Structs and functions do not need to have type annotations. They are completely optional and learning when to annotate is one of the first learning challenges for newcomers to the language. There are code generation advantages to type annotations for structs, but they are not required. As for functions, this will only ever be the case if type inference fails, which should be so rare that you hardly even need to consider it.
el_oni 4y ago
Wrt the python package. Scipy has binomial and poisson classes [1,2]. I don't know if these fit the bill? [1]https://docs.scipy.org/doc/scipy/reference/generated/scipy.stats.binom.html https://docs.scipy.org/doc/scipy/reference/generated/scipy.s... [2]https://docs.scipy.org/doc/scipy/reference/generated/scipy.stats.poisson.html https://docs.scipy.org/doc/scipy/reference/generated/scipy.s...
- lancebeet 4y ago
  I think what he/she is looking for is the Poisson-Binomial distribution[1]. There is mention of one python package in the wikipedia article[2], but it doesn't seem to be widely used. There's an open issue from 2016 to implement it in scipy.stats[3]. [1] https://en.wikipedia.org/wiki/Poisson_binomial_distribution https://en.wikipedia.org/wiki/Poisson_binomial_distribution [2] https://github.com/tsakim/poibin https://github.com/tsakim/poibin [3] https://github.com/scipy/scipy/issues/6000 https://github.com/scipy/scipy/issues/6000
  - defrost 4y ago
    Heh. The attempt to shoehorn in the Python version of the R Fourier variation was closed 18 days ago with a "doesn't quite fit, try again later" [4] https://github.com/scipy/scipy/pull/12000 https://github.com/scipy/scipy/pull/12000
- javitury 4y ago
  Thanks for the suggestions but unfortunately the poisson-binomial distribution [1] is not a simple combination of those two distributions. It requires of specialized packages like PoissonBinomial[2] in R. [1]https://en.wikipedia.org/wiki/Poisson_binomial_distribution https://en.wikipedia.org/wiki/Poisson_binomial_distribution [2]https://cran.r-project.org/web/packages/PoissonBinomial/index.html https://cran.r-project.org/web/packages/PoissonBinomial/inde...
  - el_oni 4y ago
    Ahh my apologies. Shows my lack of domain knowledge. Looking at some child comments it looks like there have been attempts to get it added to scipy since 2016.
deleted 4y ago
[deleted]
jakobnissen 4y ago
That's not my experience with Julia. I find it easy to add type annotations where you want - but it's not needed that often. Usually I add it for clarity, not for performance reasons, like I would in Python. And I definitely don't get what you mean by having to write the code twice: To me the beauty of Julia is exactly that you write it once, then optimise it for speed (or robustness, with gradual typing and all) instead of rewriting it in another language. Unfortunately, I also don't agree that the runtime error messages are good in Julia. I find them pretty bad :( even if stack traces are good. And also, the lack of automatic type checking in the editor is also a problem for productivity.
- username223 4y ago
  > I find it easy to add type annotations where you want - but it's not needed that often. That has been my experience as well: among optionally-typed languages, Julia is pretty good at inference, and at telling you why it gave up. This is critical when dealing with a language with a Sufficiently Smart Compiler that takes some convincing to do what you want.
davidktr 4y ago
I mean you can use R packages in Python, but ...
- BrandonS113 4y ago
  that is hard, but its quite easy to call R inside Julia.

Sukera 4y ago

> I have to annotate all structs and function input types. Can you elaborate on that? Argument types in function definitions do not help the compiler infer types - you can leave them completely untyped. It's really only required in struct fields, so that the compiler can know the size of your struct and doesn't have to box everything.

jakobnissen 4y ago
It's not even needed in struct fields. If Python, Matlab and R are viable alternatives, then surely OP does not care about performance and can choose a completely dynamic style of Julia. (I don't recommend it though, having some idea of type safety is in general a good idea)
javitury 4y ago
My bad, I didn't express myself properly. The Julia language requires structs to be annotated and only those, you are right. Then if you want to reach a primitive level of type safety, function input types have to be annotated.
- freemint 4y ago
  This doesn't match with my experience. Julia is really excellent at infering complicated types. What you might be running into is type ambiguity though where Julia has to resort to unions because that's what the loops needs to work. Have a look at @code_warntype of some function call to see if that is the problem.
- Sukera 4y ago
  Ah, I see, you're referring to linting capabilities. Yes, that's unfortunately a current limitation of LanguageServer.jl right now. I don't think it interfaces extensively with the compiler for type inference in a way that it crossreferences callers in the current code base, though it certainly could. That capability just hasn't been implemented yet I think. Regardless, that's orthogonal to being type safe.
- ninjin 4y ago
  No, it does not: julia> struct Foo a end julia> Foo(17) Foo(17) julia> Foo("bar") Foo("bar") People should absolutely criticise Julia for its faults, but I would expect them to at least learn and understand the very basics of the language before doing so. Structs and functions do not need to have type annotations. They are completely optional and learning when to annotate is one of the first learning challenges for newcomers to the language. There are code generation advantages to type annotations for structs, but they are not required. As for functions, this will only ever be the case if type inference fails, which should be so rare that you hardly even need to consider it.

el_oni 4y ago

Wrt the python package. Scipy has binomial and poisson classes [1,2]. I don't know if these fit the bill? [1]https://docs.scipy.org/doc/scipy/reference/generated/scipy.stats.binom.html https://docs.scipy.org/doc/scipy/reference/generated/scipy.s... [2]https://docs.scipy.org/doc/scipy/reference/generated/scipy.stats.poisson.html https://docs.scipy.org/doc/scipy/reference/generated/scipy.s...

lancebeet 4y ago
I think what he/she is looking for is the Poisson-Binomial distribution[1]. There is mention of one python package in the wikipedia article[2], but it doesn't seem to be widely used. There's an open issue from 2016 to implement it in scipy.stats[3]. [1] https://en.wikipedia.org/wiki/Poisson_binomial_distribution https://en.wikipedia.org/wiki/Poisson_binomial_distribution [2] https://github.com/tsakim/poibin https://github.com/tsakim/poibin [3] https://github.com/scipy/scipy/issues/6000 https://github.com/scipy/scipy/issues/6000
- defrost 4y ago
  Heh. The attempt to shoehorn in the Python version of the R Fourier variation was closed 18 days ago with a "doesn't quite fit, try again later" [4] https://github.com/scipy/scipy/pull/12000 https://github.com/scipy/scipy/pull/12000
javitury 4y ago
Thanks for the suggestions but unfortunately the poisson-binomial distribution [1] is not a simple combination of those two distributions. It requires of specialized packages like PoissonBinomial[2] in R. [1]https://en.wikipedia.org/wiki/Poisson_binomial_distribution https://en.wikipedia.org/wiki/Poisson_binomial_distribution [2]https://cran.r-project.org/web/packages/PoissonBinomial/index.html https://cran.r-project.org/web/packages/PoissonBinomial/inde...
- el_oni 4y ago
  Ahh my apologies. Shows my lack of domain knowledge. Looking at some child comments it looks like there have been attempts to get it added to scipy since 2016.

deleted 4y ago

[deleted]

jakobnissen 4y ago

That's not my experience with Julia. I find it easy to add type annotations where you want - but it's not needed that often. Usually I add it for clarity, not for performance reasons, like I would in Python. And I definitely don't get what you mean by having to write the code twice: To me the beauty of Julia is exactly that you write it once, then optimise it for speed (or robustness, with gradual typing and all) instead of rewriting it in another language. Unfortunately, I also don't agree that the runtime error messages are good in Julia. I find them pretty bad :( even if stack traces are good. And also, the lack of automatic type checking in the editor is also a problem for productivity.

username223 4y ago
> I find it easy to add type annotations where you want - but it's not needed that often. That has been my experience as well: among optionally-typed languages, Julia is pretty good at inference, and at telling you why it gave up. This is critical when dealing with a language with a Sufficiently Smart Compiler that takes some convincing to do what you want.

davidktr 4y ago

I mean you can use R packages in Python, but ...

BrandonS113 4y ago
that is hard, but its quite easy to call R inside Julia.