khinsen

I doubt there is a single good answer to that question. I'd call it a workbench for software and knowledge management, but I am well aware that this doesn't mean much for people who have never used a workbench for software and knowledge management.

A more pragmatic answer: - If a Smalltalk IDE is what you are looking for, give it a try. Right now. You won't regret it. - If static analysis of large code bases is what you are looking for, explore the current level of support for your language (best done by asking a question on Discord), and if it's good enough, give it a try. Otherwise, check again later. - If you are interested in new approaches to software and knowledge management, give it a try, right now, but be prepared to invest some time before you "get it".

I sympathize with your criticism, which reflects my first impressions of Smalltalk when I played with Smalltalk 80 on my Atari ST 25 years ago. An impressive system, but isolated from the rest of the universe.

However, today's Pharo has made significant progress with interfacing to "foreign" stuff. The file system has become a first-class citizen of the environment. There is an FFI to work with C libraries. And of course support for network protocols. Source code management is based on Git. It's the GUI that remains in a world (window) of its own, but otherwise Pharo's system integration level is just a notch below languages such as Python or Ruby.

From my experience as a recent Pharo user (started in October 2018 with the Pharo MOOC), the two main issues with existing documentation are

1) Much of it is outdated. 2) Much of it supposes significant prior knowledge of Pharo.

Once you start to become familiar with Pharo, neither is much of a problem. You see that the screenshot of Pharo 5 resembles what you see on Pharo 7 in spite of superficial differences. And you picked up enough of the jargon to be able to judge if some documentation is close to your level or not.

For someone who downloads Pharo 7, starts it up, and wonders "what now", most of the existing documentation is confusing. The MOOC was a much better starting point back in October, but with the new system browser in Pharo 7, it's seriously outdated as well.

There is a nice overview/demo, though unfortunately the quality of the video isn't great: https://www.youtube.com/watch?v=qeYEais1eT4&feature=youtu.be

My recent presentation on Leibniz may answer some questions that have remained open in this discussion: http://www.slideshare.net/khinsen/leibniz-a-digital-scientif...

Leibniz and Modelica indeed share the objective of writing digital scientific models rather than software. But the kind of information that can be expressed is quite different. Perhaps the most important difference (for me at least) is that Leibniz permits analyzing and reasoning about models, not just simulating them. I don't think Modelica can do this, but I can't claim to know it well enough.

You can indeed consider a context plus a term to be reduced as a program, which is executed by term reduction. But the unit of code in Leibniz is the context, not the context + term-to-be-reduced. If you want to compare to programming languages, a context is more like a library.

The difference is in the focus rather than in the principles. Leibniz is a Turing-complete language, so you can use it for programming. But that's not what Leibniz is designed for. Term reduction is more a way of exploring the definitions in a context than a way to run code.

In Leibniz, you wouldn't write only "nabla v = 0", but also what v is (by associating it with a sort), what properties v has (e.g. being positive), and how you actually obtained "nabla v = 0" from some first principles, using a sequence of transformations.

The point of Leibniz is to communicate information to other scientists, but in a notation that can be analyzed and verified by computer programs. An immediate advantage is coherence checking by the Leibniz system - you cannot use undefined quantities in an equation, for example.

You don't "run" Leibniz code. Leibniz is not a programming language. A Leibniz context is more like a database of equations than like a program.

You can use the database of equations (and rules) to "reduce" a term, which is also what computer algebra systems do. The difference is that in Leibniz, the database of equations of rules is always known and can be inspected, whereas in a computer algebra system it is carefully hidden from the user. Since it's this database where scientific knowledge is stored, this difference is quite important.

The analysis of the problem is good, but I am not convinced about the solution.

There has never been a central hub for scientific papers, but that has never been a problem. Why should it be a problem for software? We have technologies for making software citable with a DOI, so we could aim for the same network-of-references approach to discoverability that has worked reasonably well for journal articles.

As for impact metrics, they have done more harm than good for papers, so I don't see why should run to make the same mistake for software. Moreover, we could do much better. Given that we are slowly moving towards provenance tracking and workflow management for replicability, we could use that same provenance information for measuring software use in a way that is verifiable and hard to game. I have outlined such an approach in a recent paper (http://dx.doi.org/10.12688/f1000research.5773.3, see the Conclusions), which should be combined with transitive credit (http://openresearchsoftware.metajnl.com/articles/10.5334/jor...). Such a metric would measure how much a piece of software has contributed to published computational results.

Your comment is a nice example of the frequent misunderstandings concerning bitwise reproducibility.

My article argues that infrastructure tools (compilers, runtimes, ...) should ensure bitwise reproducibility, making it possible for a programmer to define a computational result exactly through a program's source code.

This does not mean that we can't have different algorithms. It doesn't even mean that no compiler could ever re-arrange operations for optimization. The latter could well be enabled through a compiler option.

All I am asking for is that infrastructure tools leave all these choices to the programmer.

I don't think I am among the "main" ones, but to answer your question: Python is what I use for doing research, Clojure is what I look at because there are lots of good ideas in it. BTW, I also follow some Haskell developments, in particular DPH.