6 ms·

> Our policy for evolving the API over time is that new functionality can be added, while removing or changing existing functionality can only be done if the be

> Our policy for evolving the API over time is that new functionality can be added, while removing or changing existing functionality can only be done if the benefits exceed the (often significant) costs to users and only after giving clear deprecation warnings to those users for at least one year. In general, we encourage changes that improve clarity in the API of the library but strongly discourage breaking backward compatibility, given our position near the base of the scientific Python computing stack. This is one of the nuggets out of it. I have been using Python with scipy and more extensively with it's sci-kit library since 2014. Started with it by solving discrete traveling sales man problem for solution of sitting arrangements and was astonished with its ease of use of matrix algebra with these libraries and got hooked to it. It helped me to do scientific computing and create a user friendly user interface on web to help end-user to just focus on siting arrangement and conference Organization. Can solve it with Matlab or GNU octave, but couldn’t have developed easily the whole system with user interface in them. If Swift wanted to be used in scientific computing it needs to follow the similar policy of managing its scientific stack. Julia is good for scientific computing, but it’s UI and web development libraries are isn’t that powerful. So will see how it develops. I constantly see on HN criticism of Python and something rewritten in Rust as something revolutionary or ground breaking that it will change the whole world. Earlier this fad was with go language. Probably in time to come Rust will be used for some core library development which brings substantial benefits like scipy, not something rewritten as wrapper around C library with unsafe code which can be done with Python much better.

pmarin 7y ago
Hacker News always has been driven by fashion and novelty. It's a news site after all. The main innovation of recent programming languages is the use of social media for marketing and PR by their companies to promote them.
- jolux 7y ago
  > The main innovation of recent programming languages is the use of social media for marketing and PR by their companies to promote them. For some languages I think yes, others no. Rust in particular has a memory management philosophy which was basically novel when it came out; it existed in research papers and such but not very many people were using those languages to do mainstream software engineering. It’s a big deal.
  - pmarin 7y ago
    It is not a big deal, It is good marketing.
    - leksak 7y ago
      I follow a lot of Rust programmers on Twitter. Here's my understanding, they are busy writing Rust code. Their tweets are about the code. Their bio points out that they are fortunate to write Rust for a living. They focus on how it was _done_. Meanwhile, the other programmers I follow share what they've built as in what their code _does_ and why that makes them giddy. (C#, Python, JS,...)
      - pjmlp 7y ago
        Just like C++ conferences vs other languages. :) In C++ conferences, the talks are about how to do data structure X in C++, on to do certain algorithms in C++, build systems, meta-programming tricks, and so forth. In other languages, the talks are about how product X was built in language Y.
    - staticassertion 7y ago
      I worry that I may regret asking, but what qualifies as a big deal?
      - pmarin 7y ago
        It's a subjective matter of course but for example a feature that Go and Rust have is type checking across module boundaries which is a big deal for me but it's not something very interesting to make marketing with.
    - jolux 7y ago
      Why isn’t it a big deal?
  - dragonsh 7y ago
    > It’s a big deal. Only time will tell, right now don’t see any real benefits. I do agree though rust is a good attempt to try. Right now majority of the rust libraries depend on underlying C/C++ with unsafe code. Will watch how it will slowly replace Firefox use of C++. Will wait and watch when rust will replace LLVM written in C++ with something completely written in rust. Although they replaced OCaml part with rust already so need to see when they can replace C++ dependency which is LLVM. (My opinion might be biased as rust code reminds me of 1990’s and doesn’t look any different than C++, I like Swift syntax more)
deleted 7y ago
[deleted]
gigatexal 7y ago
That discrete traveling salesman problem of seating arrangements ... how did you model that? I have a similar problem with organizing committees where committees have members that are in other committees and so committees with overlapping members can’t meet together etc etc.
- bhl 7y ago
  Not exactly TSP, but something similar on solving seating arrangements: it’s with simulated annealing; it might help with formulating your optimization problem. https://news.ycombinator.com/item?id=16548012 https://news.ycombinator.com/item?id=16548012
  - gigatexal 7y ago
    Danke!!!
- ylk 7y ago
  I think you could also see this as a graph coloring problem https://en.m.wikipedia.org/wiki/Graph_coloring#Scheduling https://en.m.wikipedia.org/wiki/Graph_coloring#Scheduling Edit: to elaborate, each committee would be a vertex and a committee-vertex is connected to another vertex if one or more of their members overlap. Once you’ve got such a graph you simply have to a assign a color (or number/letter/anything) to every vertex in the graph, with the requirement that no neighboring (as defined by being connected by an edge) vertexes are allowed to have the same color. You also try to use the minimum amount of colors needed. Then you can safely schedule the committees with the same colors for the same timeslots, and be sure that everybody will be able to attend.
  - gigatexal 7y ago
    Thank you! I can run with this.
DataDaoDe 7y ago
> Probably in time to come Rust will be used for some core library development which brings substantial benefits like scipy, not something rewritten as wrapper around C library with unsafe code which can be done with Python much better. I think a nice situation would be to have all the core scientific libraries and tools written in rust with clean APIs, independent of any particular scripting language but with the clear goal of providing a clean API to wrapper languages. Then any scripting language can wrap these libs and go - essentially something like a universal numpy/scipy/scikit, etc. This would mean Ruby/Python/JavaScript/Julia, etc. would all be able to get to state of the art immediately while minimizing the duplication of effort across languages and creating a standard "ML" or "Scientific" API.
- woodson 7y ago
  You mean like currently BLAS/LAPACK? Written in FORTRAN, wrapped by any scripting language, e.g. Python's NumPy/SciPy, Julia's LinearAlgebra (part of stdlib, https://docs.julialang.org/en/v1/stdlib/LinearAlgebra/ https://docs.julialang.org/en/v1/stdlib/LinearAlgebra/), R, Octave, Javascript (BLASjs etc.). That's the standard API for now.
  - xiaodai 7y ago
    I recall a couple of efforts to write a BLAS in pure Julia. https://discourse.julialang.org/t/we-can-write-an-optimized-blas-library-in-pure-julia-please-skip-op-and-jump-to-post-4/11634 https://discourse.julialang.org/t/we-can-write-an-optimized-...
mxcrossb 7y ago
> Can solve it with Matlab or GNU octave, but couldn’t have developed easily the whole system with user interface in them. This is a very key point. I still find that Matlab often has a larger set of features and better efficiency for linear algebra. But thanks to Scipy, you really can expand your mind about what kinds of systems to interface with.
- enriquto 7y ago
  GNU Octave is indeed faster than numpy. This may be because GNU Octave uses highly optimized solvers (like the famous modified Cholesky method). Due to scipy's license fundamentalism, they refuse to use many of these solvers because they are GPL-licensed. It is a bit sad to see how these ridiculous ideological constraints taint an otherwise excellent software package.
  - beojan 7y ago
    Much as I'm personally very pro-GPL, I think there are good reasons to avoid licensing fundamental parts of the SciPy stack under a copyleft license, since anything built on top would also need to be GPLed. A scipy-copyleft for such GPLed components would be nice though.
Dowwie 7y ago
Rust isn't going to replace Python because it isn't an interactive language that can be used for adhoc analysis, but it will be used to write the libraries that python imports when the existing ones are no longer sufficient for people's needs. Python isn't criticized as much as it is recognized as the lesser tool for certain categories of development. That's fine because it is a general purpose language with many great uses.
- YawningAngel 7y ago
  What do you mean? There's an RFC for a proper REPL in Rust and a bunch of good-enough hacks in the meanwhile, there just isn't that much demand for one. You can absolutely write ad-hoc scripts in Rust if you want to
  - Dowwie 7y ago
    Hobby project at best-- doing it because one can rather than because one should. That in itself is worthwhile to those involved, yet it doesn't mean it will disrupt Python. You ask me as if I don't know what I'm talking about-- as if I am not well acquainted with the rust-analyzer grinding away compilation in the background, slowing down the machine and interrupting workflow? Rust's Achilles heel is compilation. It is a hard enough problem to solve that it won't ever reach a level that it can successfully run in the background of a REPL workflow and offer a user experience comparable to that of Python. The user experience is the reason that Rust will not ever present a viable alternative. Just as with Python, this is also fine. Rust isn't the right tool for every job.
    - mark_l_watson 7y ago
      I have a question for you or anyone else who might know the answer: both Haskell and Rust have long compilation times for large systems, so why is the Haskell repl so fast and agile for interactive development? Is it just because Haskell has been around for so long that partial compilation is more refined?
      - deleted 7y ago
pjmlp 7y ago
For Swift to be taken seriously, it needs to be actually usable across macOS, GNU/Linux and Windows, and not be something that still resembles the heyday of GNUStep experience.
warmvanilla 7y ago
Very cool. So what are your go-to tools for putting a front end on top of your models?
- dragonsh 7y ago
  For the seating arrangement problem in conference everything is in Python and used flask with simple bootstrap and jinja templates.
- Feuilles_Mortes 7y ago
  Qt is cross-platform, very stable, and has sane Python bindings. No other reasonable choice (imo).
gumby 7y ago
I agree this is a great philosophy. I have to point out as well, though, that one of the major objections to C++ is that it is "too big" and has too many "dangerous" constructs, both of which are a consequence of this approach. As a developer using the language this is great: I can write using clean modern approaches* and still use older packages. (Making this all continue to work is a burden on the implementation developers of course.) * not to argue which modern features are clean or not -- this is about SciPy.

pmarin 7y ago

Hacker News always has been driven by fashion and novelty. It's a news site after all. The main innovation of recent programming languages is the use of social media for marketing and PR by their companies to promote them.

jolux 7y ago
> The main innovation of recent programming languages is the use of social media for marketing and PR by their companies to promote them. For some languages I think yes, others no. Rust in particular has a memory management philosophy which was basically novel when it came out; it existed in research papers and such but not very many people were using those languages to do mainstream software engineering. It’s a big deal.
- pmarin 7y ago
  It is not a big deal, It is good marketing.
  - leksak 7y ago
    I follow a lot of Rust programmers on Twitter. Here's my understanding, they are busy writing Rust code. Their tweets are about the code. Their bio points out that they are fortunate to write Rust for a living. They focus on how it was _done_. Meanwhile, the other programmers I follow share what they've built as in what their code _does_ and why that makes them giddy. (C#, Python, JS,...)
    - pjmlp 7y ago
      Just like C++ conferences vs other languages. :) In C++ conferences, the talks are about how to do data structure X in C++, on to do certain algorithms in C++, build systems, meta-programming tricks, and so forth. In other languages, the talks are about how product X was built in language Y.
  - staticassertion 7y ago
    I worry that I may regret asking, but what qualifies as a big deal?
    - pmarin 7y ago
      It's a subjective matter of course but for example a feature that Go and Rust have is type checking across module boundaries which is a big deal for me but it's not something very interesting to make marketing with.
  - jolux 7y ago
    Why isn’t it a big deal?
- dragonsh 7y ago
  > It’s a big deal. Only time will tell, right now don’t see any real benefits. I do agree though rust is a good attempt to try. Right now majority of the rust libraries depend on underlying C/C++ with unsafe code. Will watch how it will slowly replace Firefox use of C++. Will wait and watch when rust will replace LLVM written in C++ with something completely written in rust. Although they replaced OCaml part with rust already so need to see when they can replace C++ dependency which is LLVM. (My opinion might be biased as rust code reminds me of 1990’s and doesn’t look any different than C++, I like Swift syntax more)

deleted 7y ago

[deleted]

gigatexal 7y ago

That discrete traveling salesman problem of seating arrangements ... how did you model that? I have a similar problem with organizing committees where committees have members that are in other committees and so committees with overlapping members can’t meet together etc etc.

bhl 7y ago
Not exactly TSP, but something similar on solving seating arrangements: it’s with simulated annealing; it might help with formulating your optimization problem. https://news.ycombinator.com/item?id=16548012 https://news.ycombinator.com/item?id=16548012
- gigatexal 7y ago
  Danke!!!
ylk 7y ago
I think you could also see this as a graph coloring problem https://en.m.wikipedia.org/wiki/Graph_coloring#Scheduling https://en.m.wikipedia.org/wiki/Graph_coloring#Scheduling Edit: to elaborate, each committee would be a vertex and a committee-vertex is connected to another vertex if one or more of their members overlap. Once you’ve got such a graph you simply have to a assign a color (or number/letter/anything) to every vertex in the graph, with the requirement that no neighboring (as defined by being connected by an edge) vertexes are allowed to have the same color. You also try to use the minimum amount of colors needed. Then you can safely schedule the committees with the same colors for the same timeslots, and be sure that everybody will be able to attend.
- gigatexal 7y ago
  Thank you! I can run with this.

DataDaoDe 7y ago

> Probably in time to come Rust will be used for some core library development which brings substantial benefits like scipy, not something rewritten as wrapper around C library with unsafe code which can be done with Python much better. I think a nice situation would be to have all the core scientific libraries and tools written in rust with clean APIs, independent of any particular scripting language but with the clear goal of providing a clean API to wrapper languages. Then any scripting language can wrap these libs and go - essentially something like a universal numpy/scipy/scikit, etc. This would mean Ruby/Python/JavaScript/Julia, etc. would all be able to get to state of the art immediately while minimizing the duplication of effort across languages and creating a standard "ML" or "Scientific" API.

woodson 7y ago
You mean like currently BLAS/LAPACK? Written in FORTRAN, wrapped by any scripting language, e.g. Python's NumPy/SciPy, Julia's LinearAlgebra (part of stdlib, https://docs.julialang.org/en/v1/stdlib/LinearAlgebra/ https://docs.julialang.org/en/v1/stdlib/LinearAlgebra/), R, Octave, Javascript (BLASjs etc.). That's the standard API for now.
- xiaodai 7y ago
  I recall a couple of efforts to write a BLAS in pure Julia. https://discourse.julialang.org/t/we-can-write-an-optimized-blas-library-in-pure-julia-please-skip-op-and-jump-to-post-4/11634 https://discourse.julialang.org/t/we-can-write-an-optimized-...

mxcrossb 7y ago

> Can solve it with Matlab or GNU octave, but couldn’t have developed easily the whole system with user interface in them. This is a very key point. I still find that Matlab often has a larger set of features and better efficiency for linear algebra. But thanks to Scipy, you really can expand your mind about what kinds of systems to interface with.

enriquto 7y ago
GNU Octave is indeed faster than numpy. This may be because GNU Octave uses highly optimized solvers (like the famous modified Cholesky method). Due to scipy's license fundamentalism, they refuse to use many of these solvers because they are GPL-licensed. It is a bit sad to see how these ridiculous ideological constraints taint an otherwise excellent software package.
- beojan 7y ago
  Much as I'm personally very pro-GPL, I think there are good reasons to avoid licensing fundamental parts of the SciPy stack under a copyleft license, since anything built on top would also need to be GPLed. A scipy-copyleft for such GPLed components would be nice though.

Dowwie 7y ago

Rust isn't going to replace Python because it isn't an interactive language that can be used for adhoc analysis, but it will be used to write the libraries that python imports when the existing ones are no longer sufficient for people's needs. Python isn't criticized as much as it is recognized as the lesser tool for certain categories of development. That's fine because it is a general purpose language with many great uses.

YawningAngel 7y ago
What do you mean? There's an RFC for a proper REPL in Rust and a bunch of good-enough hacks in the meanwhile, there just isn't that much demand for one. You can absolutely write ad-hoc scripts in Rust if you want to
- Dowwie 7y ago
  Hobby project at best-- doing it because one can rather than because one should. That in itself is worthwhile to those involved, yet it doesn't mean it will disrupt Python. You ask me as if I don't know what I'm talking about-- as if I am not well acquainted with the rust-analyzer grinding away compilation in the background, slowing down the machine and interrupting workflow? Rust's Achilles heel is compilation. It is a hard enough problem to solve that it won't ever reach a level that it can successfully run in the background of a REPL workflow and offer a user experience comparable to that of Python. The user experience is the reason that Rust will not ever present a viable alternative. Just as with Python, this is also fine. Rust isn't the right tool for every job.
  - mark_l_watson 7y ago
    I have a question for you or anyone else who might know the answer: both Haskell and Rust have long compilation times for large systems, so why is the Haskell repl so fast and agile for interactive development? Is it just because Haskell has been around for so long that partial compilation is more refined?
    - deleted 7y ago

pjmlp 7y ago

For Swift to be taken seriously, it needs to be actually usable across macOS, GNU/Linux and Windows, and not be something that still resembles the heyday of GNUStep experience.

warmvanilla 7y ago

Very cool. So what are your go-to tools for putting a front end on top of your models?

dragonsh 7y ago
For the seating arrangement problem in conference everything is in Python and used flask with simple bootstrap and jinja templates.
Feuilles_Mortes 7y ago
Qt is cross-platform, very stable, and has sane Python bindings. No other reasonable choice (imo).

gumby 7y ago

I agree this is a great philosophy. I have to point out as well, though, that one of the major objections to C++ is that it is "too big" and has too many "dangerous" constructs, both of which are a consequence of this approach. As a developer using the language this is great: I can write using clean modern approaches* and still use older packages. (Making this all continue to work is a burden on the implementation developers of course.) * not to argue which modern features are clean or not -- this is about SciPy.