taliesinb

Come work on a modern functional language!

Because those are really poor substitutes for Associations, though one can make do.

That might work, but it's not clear how all the graphics, image processing, user interface, and dynamic interactivity stuff would work.

Still, would be interesting to try. I have great enthusiasm for what Chris Granger is doing.

I should have said DTrace for functional programs

Sort didn't supervise autocorrect properly

To be fair, our brand of monotonicity is somewhat different from LISP's, as I've discussed before at length on HN.

I think that's part of it. It's also aimed at non-hackers who took a look at Clojure once and said 'yuck'. And managers who are being 'groomed' not to totally freak out when someone on their team says "can we use the Wolfram Language on such and such a project?".

Yes! At least triple-abort should kill the kernel! P.s. hi again!

Yeah that's pretty bad.

Not really. Stephen knows how poor our debugging facilities are (and I regularly tell him how bad the situation is) -- we've just had limited bandwidth to actually fix it properly to our satisfaction.

Luckily I have a totally revamped debugging and logging system that will put us ahead of the curve here (imagine DTrace at a program level). Probably a point release of V10.

Same goes with multiple undo and retina support -- we know how embarrassing their absence is, and we've luckily been able to fix these for v10. I've been in design meetings where the multiple undo has bumped several other desirable features off our roadmap.

You're jumping around a bit..

Did the four-color map problem use numerical results? I imagine it was just a pure combinatorial enumeration problem (I have not read the original paper, I may be wrong about that).

If you're doing a finite element method to validate a bridge design, you're hardly publishing a paper based on the result (though of course you will do plenty of validation and then times everything by 2 for good measure!).

What kinds of actual fields of mathematics are you thinking about, here?

I know that error analysis is a deep and arcane subject, and personally I have no idea how well or badly we do in that department, but I'm struggling to think of where the details of how we get it wrong or right is crucial for the development of published academic mathematics.

"Most" maths is totally abstract these days, categories and sheaves and topi and what not.

I advance the possibility that your thinking about programming languages has become, to paraphrase The Dude, way too uptight.

Is a telescope a proprietary source? Is a commercially manufactured CCD a proprietary source? Maybe they got the response curve wrong! Okay, test it before you announce your galactic dust measurement paper! I take that attitude towards "experimental mathematics" that involve computers in some deep way.

And no need to patronize with Wikipedia links, I know the story about the Mars Climate Orbiter. And I don't think it even demonstrates your point. As I understand it, vxWorks, which many of the NASA missions use, is closed source. You have to pay to see the source. And I'm sure that Wolfram Research would or could do the same thing for e.g. intelligence agencies (and hopefully will do for everyone in the future, fingers crossed).

Let me do some patronizing of my own: are you sure your understanding of what the language does is up to date? You seem to talk of it as if it were a predominantly a CAS: http://reference.wolfram.com/language/index.html

Ooops -- just saw this! My mistake!

Well, because for the moment the Wolfram Language has such a small fraction of developer mind-share.

Which means that open-sourcing our projects during their actual development isn't worth the significant development cost (an entire toolchain would need to be open-sourced, and documented). And it also is somewhat antithetical to our design process, which is kinda centralized around Stephen himself, who for the most part really does have a good sense of design.

I think that could change, though, and then I think there is a really good opportunity to open source more of our stuff and start building stuff collaboratively with a wider community. Especially when our Cloud stuff comes online.

Also, I regularly bug Wolfram about open-sourcing some core part of the kernel. He's not in principal against it, but points out that it would cost a lot, buy us nothing in the short term, and fork the language. But I think it'll happen eventually, hopefully sooner rather than later.

Good to know, thanks for the link.

I suppose it is your prerogative to classify employees as sycophants if you want.

From talking to other people at the company I know of only two Wolfram employees who are active on HN, being myself and carlob.

I don't think I cheer Wolfram, particularly. He's arrogant, sure, his posts are self-aggrandizing (or rather product-aggrandizing), sure -- although I don't think that these are remarkable properties for a CEO to have.

But we have some really nice technology that not many people seem to know very much about, so I comment a lot about it when the opportunity arises. Also, I think NKS has some cool stuff in it -- that's how I got associated with the company in the first place, through an amazing summer school experienc in Pisa, Italy.

> In fact, it can be argued that when the salaries of mid-level employees are low compared to industry norms

Read my post again: revenue / employee, not salary / revenue.

> One can read all sorts of user-level script code, but no source code at all.

What? Probably half of the Wolfram Language is written in the Wolfram Language. How is top-level code not source code?

> it explains why Mathematica cannot be used in serious mathematical work, work meant for technical and scientific publication and peer review.

You keep saying that... I think the truth is more subtle. A tool like Mathematica might play a crucial role in some result, but the proof or result itself doesn't a priori need to rest on any black box software at all to be reproducible.

A nice family of examples would be the class of NP problems, for which the discovery might have been difficult, and achieved via proprietary tools, but the verification is possible via open-source tools or with direct human insight.

And that's not even considering physics, biochemistry, engineering, and astronomy, where many of the tools you use will always be expensive and built by industry, and have no impact on peer review. Especially if they are a means to visualizing data to generate hypotheses, or processing or wrangling data into a tractable form.

I actually somewhat sympathize with your view. But I think you overstate the problem: if someone discovers something with Mathematica, they can then formalize it with an open proof assistant like Coq before they publish, and modern journals in fact encourage this sort of thing.

Really, it's not a zero-sum-game between open-source and commercial tools.

An entire country (Estonia) recently bought a Mathematica site license.. I don't see that as evidence of monopoly erosion.

Look, Sage is great, I hope Sage does really well and eventually duplicates the entirety of our functionality. But at the current rate it'll take probably hundreds of years. Sometimes, profit-subsidized research is just much, much more productive at driving innovation.

I think you're missing the point about why the Wolfram Language is going to be useful on a PI. I don't think the majority case will be mathematics. See here for some ideas:

http://blog.wolfram.com/2013/11/21/putting-the-wolfram-langu...

And re free tools: I doubt very much that Sage has any mechanism for flashing LEDs through the GPIO pins of the Pi, or doing image processing on a RaspiCam, or balancing an inverted pendulum using control theory, or modelling and controlling a sous vide cooker.

For the tinkerer, getting an embedded device to do something cool isn't going to lead to bankruptcy in older age.

I believe it required getting rid of some legacy libraries, which couldn't be achieved in a point release.

> I don't get it... Wolfram is a money-hungry egomaniac.

That's kinda funny. Our revenue per employee is lower than the industry average. If the company was interested in money uber alles, there are many more profitable and less interesting ways of doing it than what we do now.

> not a single source line of Mathematica code is exposed

Well, not sure what you mean by 'exposed'. But you can read large swathes of our code by looking in the right place in the installation. We also have some official open source projects, like our HadoopLink: https://github.com/shadanan/HadoopLink

V10 is retina aware, and it's coming out soon.

Lattice Boltzmann have these same weaknesses (whether one cares as you say depends on the Reynolds regime). Point is, starting from the "simplest possible gas program" has yielded a useful branch of CFD, and one would have thought it extremely unlikely to work if you used intuition from traditional mathematics... It's as discrete and analytically intractable as you get.

Anyway, to me, the continued application of these methods is one data point that NKS-like methods are proving useful across a variety of domains.

> the way in which real fluids deviate from N-S is completely unlike the way in which lattice gas fluids deviate from N-S

Can you describe more how the deviations deviate? Specifically, how do these differences affect numerical solutions?

> If anything the trend in that field since the late 90s has been away from NKS and towards seeing the lattice Boltzmann method as a solver for continuum treatments at the Boltzmann (rather than N-S) level.

Also, which continuum are you referring to here? Number of particles? Lattice spacing?

Sooooort of. There are major differences, differences that make a difference, so to speak.

Lisp: everything is lists.

Wolfram Language (prior to V10): everything is an expression. An expression has a head, and parts. The head is the primary place you attach rules. The head can be List, but can also be, say, If, or Disk, or Entity, or Timeseries, or Image, or Graph, or Graphics, or Button, or Frame, (and on and on and on).

Wolfram language (v10): expressions can be numerically indexed (i.e. Part[{"A","B","C"}, 2] == "B"), or symbolically indexed (Part[<|"A" -> 1, "B" -> 2, "C" -> 3|>, "B"] == 2). This new datastructure is called an Association (analogous to a hash map / associative array / dictionary, of course), but eventually it could have heads other than Association.

Anyway, its all quite uniform. No pointers, no references, nothing you "can't see". And the new Association data structure interacts beautifully with lists when you allow it to interact with Part -- you end up with something like XPath, but capable of expressing, for example, almost all of SQL, or LINQ, but in a very functional way.

It's a little beyond that, in some ways. In the LISPs, you can view programs as data, but macros are different from, say, 'if'. The Read and Evaluate parts of the REPL are distinct phases.

Whereas in Wolfram Language, If is just an ordinary symbol that has attribute HoldRest to ensure that it can prevent evaluation of its two clauses until it knows which one to evaluate.

In other words, code is just data (expression) that happens to have specific rules that will cause it to evaluate in some way, yielding a new expression (which could be more code, or partially evaluated code, or data, or whatever).

But you can also have rules attached to several symbols together. So for example, when you see a Foo containing a Bar, replace it with a Baz:

   Foo[___, Bar, ___] := Baz;

It's a little like multiple dispatch, but it is slightly more general than even that. And totally pattern based (the pattern language is ridiculously rich).

There's one more twist, which is that everything is not just serializable, but in some sense it is its serialization (called FullForm). It's hard to explain what this means without playing around with stuff.

Also, the language has actual m-expressions, thank god, unlike most LISPs.

Objectively, it avoids jargon and florid prose (apart from some rather repetitive language). It means a child could read it, and perhaps that makes it boring to read.

Perhaps you found the actual experiments he did boring, or tedious. I think they're pretty cool, and I've now done my fair share of them, and taught other people how to do them. The axiom systems, graph automata, constraint satisfaction, causal graph stuff, and entropy stuff is all cool. And the notes are a goldmine reference.

Also, this is probably the least important of the 8 specific claims of Shalizi's that I rebut. But hey.

edit: because we seem to be using edits to converse. For 25 years, Wolfram has been the company brand, and people roughly know what it is -- how can we NOT prefix our products with the word Wolfram? Also, did you just call a marketing-type pre-announcement hyperbolic? http://www.youtube.com/watch?v=BETSuT2RNLs

Aha! Physical fluids aren't Naiver Stokes, which is just a continuum approximation that was invented before atoms were even a scientifically established idea. Which of course you know already, but it means it is begging the question a little to say "you might be simulating something but it sure ain't a Navier-Stokes fluid".

For Galilean invariance, I've previously waxed philosophic about why I think that's a feature, not a bug (at least, pedagogically): http://news.ycombinator.com/item?id=5931434

For 2, I think it was overly ambitious to think that within a program family so small it has only 88 members there would be one ideal hash function. And If you compare the simplicity of Damgard's design to the contortions that modern hash designs employ to stymy cryptanalysis, it's hard to think that more designs constructions wouldn't perform better, even on that particular automaton.

For 3, I think having a full 7 slides of Bertoni et al's slide deck devoted to the influence of CA-based cryptography on SHA-3 makes it fair to call the approach influential.

Thanks for the references!