5 ms·

> Mathematica is a desktop product, specifically an IDE for the Wolfram Language Presenting Mathematica (or, rather, FrontEnd?) as IDE is harmful for its reput

by akater 12y ago

> Mathematica is a desktop product, specifically an IDE for the Wolfram Language Presenting Mathematica (or, rather, FrontEnd?) as IDE is harmful for its reputation among hackers: 1) Workflow differs from one in traditional IDEs, and lots of build tools are simply not there 2) It has different goals, being a bottom-up environment: users start with tiny one-cell programs; IDEs like Eclipse suggest to “create a new project” by default It's a tool for discovery and improvisation, not for building large programs, with multi-modular source code provided by different independent authors, that is sometimes (often?) written in different languages. “Improvisations and Experiment Environment” or something like that would be a more adequate description. It's not that FrontEnd can't be an IDE too. I believe it can be a better IDE than anything else out there but experienced programmers disagree unanimously. Part of it is personal tastes, part is mind being closed by means of classical IDE heritage, part is not-so-rational disgust towards proprietary software, paid software, S.W., etc. FrontEnd and the language itself encourage users to add features themselves. Those who persist probably end up with the highly personalised product the majority of them could never buy. (+) Still, some features would be universally needed, so one might want to install a package from a public hub, but FrontEnd lacks this feature. (–) I think hackers would appreciate it more if Mathematica (FrontEnd?) were marketed as emacs-like tool. Still, without a proper package manager (and an open package server, or at least an open standard for package server) it would be a hopeless take. — Though I heard something like package manager is coming. :-)

taliesinb 12y ago
You're right, it is more of an emacs-like tool. Probably in the next year or so we will consolidate some ideas of what an IDE should (or could) be for WL. Some Brett Victor like things should be in there, no doubt... And yes, we need to get PacletManager into a state where it is easy to use as a package manager. The only thing (and a big, crucial thing) it is missing right now is explicit dependencies, and a solver. If you have ideas about this please offer them (are you on the Mathematica stack exchange?)
- szhorvat 12y ago
  The Front End isn't very good at taking the job of an IDE ... But it is a very good notebook interface (doesn't the notebook concept come from Mathematica originally?). Notebook interfaces are excellent for interactive work (a large part of scientific computing) and improvisational programming. It's a pity that they're only becoming popular recently (IPython). Many people still don't get it what notebooks are really good for. For example, the R community seems to think that a "notebook" is for report generation, and none of the "notebooks" for R allow any interactive work (knitr). What's good about the notebook interface is the workflows it allows. Even MATLAB adopted "cell mode" a few years ago which enables the same basic workflow (except it does't have the equivalent of output cells, so it's not quite as good).
  - akater 12y ago
    > doesn't the notebook concept come from Mathematica originally? Yes. It stems naturally from Lispy core of Wolfram language, IMO. Hypothesis: whenever you try to develop a user-friendly environment with a Lisp-like language, given enough effort and being consistent, you end up with notebook interface. :-) > The Front End isn't very good at taking the job of an IDE ... > But it is a very good notebook interface Actually, notebook interface is the key here, I believe. How do people start writing large programs, anyway? They invariably start with small things (~ “evaluating Plot[…] in one cell”). Then they join communities, accept certain practices and fashions, and pick the tools that dominate the community. Workbench (Eclipse + Mathematica Kernel caller + some build tools) is a universally recommended solution for large programs written in Mathematica. Having no experience with programming, I honestly tried it, used for several months only to come to believe people only recommend it because of fashions and traditions currently dominating the area. There was absolutely no benefit in using it for a [relatively] large project instead of a bunch of notebooks with their cells properly and consistently (and automatically, of course) tagged. I deploy, call unit tests and show project directory tree, with one-word command for each task, it all happens inside FontEnd, and I have no idea why people repeatedly try to float away from notebook interface. I don't have years of experience, and may be stupid, but I strongly suspect it's only due to old habits, community influence or plain unwillingness to innovate when you have traditional environments at hand. Multi-language projects could present a challenge, though (given that we have to represent text with boxes and not pure strings), but it can be overcome as well, if only people invested their time and effort.

by akater 12y ago

taliesinb 12y ago

You're right, it is more of an emacs-like tool. Probably in the next year or so we will consolidate some ideas of what an IDE should (or could) be for WL. Some Brett Victor like things should be in there, no doubt... And yes, we need to get PacletManager into a state where it is easy to use as a package manager. The only thing (and a big, crucial thing) it is missing right now is explicit dependencies, and a solver. If you have ideas about this please offer them (are you on the Mathematica stack exchange?)

szhorvat 12y ago
The Front End isn't very good at taking the job of an IDE ... But it is a very good notebook interface (doesn't the notebook concept come from Mathematica originally?). Notebook interfaces are excellent for interactive work (a large part of scientific computing) and improvisational programming. It's a pity that they're only becoming popular recently (IPython). Many people still don't get it what notebooks are really good for. For example, the R community seems to think that a "notebook" is for report generation, and none of the "notebooks" for R allow any interactive work (knitr). What's good about the notebook interface is the workflows it allows. Even MATLAB adopted "cell mode" a few years ago which enables the same basic workflow (except it does't have the equivalent of output cells, so it's not quite as good).
- akater 12y ago
  > doesn't the notebook concept come from Mathematica originally? Yes. It stems naturally from Lispy core of Wolfram language, IMO. Hypothesis: whenever you try to develop a user-friendly environment with a Lisp-like language, given enough effort and being consistent, you end up with notebook interface. :-) > The Front End isn't very good at taking the job of an IDE ... > But it is a very good notebook interface Actually, notebook interface is the key here, I believe. How do people start writing large programs, anyway? They invariably start with small things (~ “evaluating Plot[…] in one cell”). Then they join communities, accept certain practices and fashions, and pick the tools that dominate the community. Workbench (Eclipse + Mathematica Kernel caller + some build tools) is a universally recommended solution for large programs written in Mathematica. Having no experience with programming, I honestly tried it, used for several months only to come to believe people only recommend it because of fashions and traditions currently dominating the area. There was absolutely no benefit in using it for a [relatively] large project instead of a bunch of notebooks with their cells properly and consistently (and automatically, of course) tagged. I deploy, call unit tests and show project directory tree, with one-word command for each task, it all happens inside FontEnd, and I have no idea why people repeatedly try to float away from notebook interface. I don't have years of experience, and may be stupid, but I strongly suspect it's only due to old habits, community influence or plain unwillingness to innovate when you have traditional environments at hand. Multi-language projects could present a challenge, though (given that we have to represent text with boxes and not pure strings), but it can be overcome as well, if only people invested their time and effort.