Hacker News Reader

Comment by hyperbovine | Hacker News Reader

What a ridiculous post. The quote in question is a reference the Trojan horse, so unless you are suggesting that loading Mathematica onto the Pi will, in fact, destroy it, I don't see any merit to this analogy. And while it's true that Steve Wolfram is incredibly arrogant, so too is the act of publicly shaming him for refusing to share his code, no? The man has spent the last 25 years perfecting his product and along comes you, acting like you have some God-given right to inspect its inner workings. Gimme a break.

View on HN

> along comes you, acting like you have some God-given right to inspect its internals

Well,it's mathematics software, so it's actually really not unreasonable. Fortunately, the rest of mathematics has moved past the seventeenth-century style of "Here's my result, the proof is secret". If Mathematica is intended to be suitable for mathematical research, then its source must be open so that the results are auditable.

Other mathematics software like Sage doesn't have this problem, and is already available for the Raspberry Pi for free, obviating the need to use Mathematica.

> If Mathematica is intended to be suitable for mathematical research, then its source must be open so that the results are auditable

You don't need source to audit the results. It's a tool, just like a calculator or a table of logarithms or a table of integrals. If I use an HP calculator for a calculation, for instance, you don't audit my results by examining the source for the calculator's firmware and convincing yourself it is right and then accepting my results. No, you audit my results by doing the calculation on your Casio calculator and seeing if it comes out the same.

> You don't need source to audit the results.

In fact, you do. Modern computer mathematical results require full exposure, nothing can be left to the imagination. This is true and understandable.

Going back to the first important computer mathematical result (the solution to the four-color map conjecture¹ in 1976), to be taken seriously, computer math results have been required to be fully transparent.

Imagine auditing a cancer cure without knowing anything about the methods or tools. Same idea.

1. http://en.wikipedia.org/wiki/Four_color_theorem

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.

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

Yes, there are mathematical results that can be validated independently. But the problem is not so much pure mathematics as numerical results. In that arena, the method by which the results were acquired must be accessible in detail. And much of modern applied mathematics relies on numerical results. Imagine producing a result of some value and being unable to explain in detail how it was arrived at, because it emanated from a closed-source program.

The four-color map problem I mentioned earlier was the first important case where this problem had to be dealt with, and it was resolved to everyone's satisfaction only because the full source was made available.

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.

> You're jumping around a bit.

In that case, anyone who uses more than one example to make his point is jumping around. If allowed to prevail, this non-argument would cripple debate.

> Did the four-color map problem use numerical results?

Yes, emphatically so. There were a certain finite number of possible maps (1936 to be precise), and each of them had to be tested explicitly. The reason for the requirement for full disclosure was that the tested set needed to be examined to assure that nothing germane was excluded, nothing included on specious grounds, and the manner of testing had to be closely examined. None of this could be reduced to a simple equation, and none of it yielded to a formal, concise mathematical proof.

> I imagine it was just a pure combinatorial enumeration problem (I have not read the original paper, I may be wrong about that).

If that were true, there would have been no role for a computer program -- it would have been published as a pure and formal result, like Fermat's last theorem. No one would have cared about the role played by computers, because a formal and pure proof could be examined by anyone sufficiently versed in mathematics.

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

Any field that would benefit from use of a computer. By recent count, that's nearly all mathematical fields for one reason or another, including areas we once might have thought would have no use for a computer. Computer mathematics has gotten to the point where computers, laboring independently, come up with new theorems that humans have overlooked.

> 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 struggle with that, and part of the struggle is being able to see the detail of the algorithms used to arrive at a result. No detail, no trust, no science.

> "Most" maths is totally abstract these days ...

Not relevant. Relevant would be whether that abstract mathematics is or is not fully revealed in its details. For science, it must be.

This article --

http://www.newscientist.com/article/dn7286-computer-generate...

-- discusses the role of theorem-proving software like Coq, but includes a misleading statement by someone at Microsoft: "Microsoft hopes to develop a similar system for checking the logic used in computer programs, which could pre-empt some unforeseen bugs that cause programs to crash."

I hope this is an error on the part of the journalist who wrote the article, because it implies that Turing's halting problem, and Gödel's incompleteness theorems, which lie behind it, are potentially soluble. They aren't. All the more reason for full disclosure.

The statement regarding checking logic in computer programs is not misleading (though of course, your characterization of it is); there are many systems which are not subject to the halting problem in fact (at least in any way that affects practice ---> You can simply limit constructible terms to those which provably terminate, if you please). Statements like yours about Turing & Gödel are a common mistake.

You don't have to _decide_ whether a program halts in order to prove it. In many cases, termination is not so much even a proof obligation as it is a _fact_ by construction; in the harder case where termination is not obvious structurally, you can simply rewrite your general recursion as a call-graph, and then termination is a proof obligation which you must satisfy if you wish to execute it.

Decidability is much a much stronger thing than "provability in most relevant cases", and it turns out that the latter suffices. By Gödel, there are indeed "true" sentences which you cannot prove in a particular system, but I am willing to give you a hundred thousand dollars if you can actually find one and print it out. That is, Gödel's result was indeed sort of constructive, in that it did provide a scheme to construct such a sentence, but nobody does so because the term is so unfeasibly large.

There are many things which we should like very much to be decidable, some of which _can_ in fact be decidable (by Turing, termination is not one of those). For instance, in some systems (such as Intensional Type Theory), type checking is decidable, which is really nice. In others, type checking is undecidable (such as in Extensional Type Theory); does this mean that type checking cannot be done? Of course not. It simply means that type checking becomes a proof obligation, since the typing derivations may not be entirely synthesized by the type checker. (A simple demonstration of this is equality in a NuPRL-like system: propositional equality is reflected into definitional equality; there is not decidable equality for functions; therefore, there are equations which might hold definitionally by equality reflection, but for which further proof would be required; therefore, definitional equality is undecidable; therefore type checking is undecidable; but we can still prove that a term is well-typed, even if type checking is undecidable.)

"Open source" and "commercial" are not antonyms, but people working on proprietary software think they are.

Only if you use an overly literal interpretation of "commercial" yet don't use the literal interpretation of "open source" (since it's also possible to make source code visible to the public without using a license that would be considered "open source").

You have just rediscovered the reason that some people talk about "free software", and some people talk about "open source".

The sort of access to source code that is being expected here is really no more than the sort of access that you can get to Windows code. It really is not an unreasonable expectation.

No - when most people use the term "open source", they mean something along the lines of the Open Source Definition (http://opensource.org/definition), rather than the literal meaning; this is independent from the distinctions between open source and free software, which are mostly about philosophy rather than the set of applicable licenses (http://www.gnu.org/philosophy/free-software-for-freedom.html)

I suppose that you, however, do not, which makes what I was trying to say irrelevant.

Some people may think that, but I doubt that that applies here. Wolfram certainly knows that "proprietary" and "free" aren't antonyms.

I do think there is a commercial side to this, too, however. This is a kind of a hook to catch future customers of the commercial package.

And a lot of people using open source products think so too :-)

If what one is publishing is an algorithm or formula or what-have-you, it's only required that the algorithm itself be fully exposed. It particular implementation, much less so the implementation of the particular software that implementation is written in, is only incidental. When you're giving a driving test, you don't need to know how a fuel-injection system works.

> It particular implementation, much less so the implementation of the particular software that implementation is written in, is only incidental.

Not at all. In computer programming, examples abound in which the gap between the formal algorithm and its practical embodiment led to catastrophe. One can scarcely count the number of times in which the specific manner by which a simply stated algorithm was implemented needed to be examined more closely:

http://en.wikipedia.org/wiki/Ariane_5

"Ariane 5's first test flight (Ariane 5 Flight 501) on 4 June 1996 failed, with the rocket self-destructing 37 seconds after launch because of a malfunction in the control software.[20] A data conversion from 64-bit floating point value to 16-bit signed integer value to be stored in a variable representing horizontal bias caused a processor trap (operand error) ..."

> When you're giving a driving test, you don't need to know how a fuel-injection system works.

No, but someone does. If the software is inaccessible, then no one can check it except its owners, who have an incentive not to check it thoroughly, or to conceal what they have discovered.

Out of curiosity: how deep does that need go? Low level hardware analysis? Chip manufacturing facility audits?

How would you even approach this?

> Out of curiosity: how deep does that need go?

Deep enough that the meaning of the result cannot reasonably be called into question, just like in science.

> How would you even approach this?

As scientists. Someone once described science as ... not so much knowing as knowing that we know. Same idea.

Many results that seemed certain when published, evaporated once the mathematics were examined closely. This happens even when the entire process -- data, equations, conclusions -- are all included in the publication. Given that history, imagine how much more cautious people want to be when part of the process of arriving at a critical conclusion is concealed perpetually.

"Deep enough that the meaning of the result cannot reasonably be called into question, just like in science."

I think what is really being asked is: "What level of confidence is required?".

I would assume you trust the hardware and only scrutinise the software? In contrast: are results tested on a plurality of machines with intentionally, measurably different hardware and the absence of discrepancies implies that the hardware is not a factor with regard to the problem being solved? Presumedly you'd need some sort of standardised test suite to pass on your hardware to really confidently declare the hardware to not be a factor.

I doubt this is the case, but like the previous poster, I'm quite curious as to the specific level of scrutiny applied here.

> I think what is really being asked is: "What level of confidence is required?".

That's something that varies from field to field. In physics, a new discovery requires a five-sigma result, meaning a result that has a one in 3.5 million probability of arising by chance rather than the legitimate detection of a new particle or phenomenon.

http://www.select-statistics.co.uk/blog/webmaster/one-sigma-...

In psychology, by contrast, a p-value of 0.05 (i.e. 2 sigma) is accepted as statistically significant, which by itself may explain the sad state of the field.

http://en.wikipedia.org/wiki/P-value

> I would assume you trust the hardware and only scrutinise the software?

No, a scientist doesn't trust either hardware or software, but hardware can be checked and validated. In the case of Mathematica, the software cannot be checked and validated, it must be trusted. And for a scientist, trust cannot be distinguished from faith.

Thanks for your reply.

"No, a scientist doesn't trust either hardware or software, but hardware can be checked and validated." Do you know if or how this is done?

Recalling the The Pentium FDIV bug, I'd say yes. Chip level.

Your table of logarithms and integrals is exactly the perfect example of why you need the source to audit the results, those things were notoriously error prone.

IMO, the existence of Sage obviates the need to use Mathematica in the same way as the existence of the Gimp obviates the need to use Photoshop.

In both cases, the commercial package has many, many features that the free version barely implements or even completely lacks, and implements many of the shared features better. On top of that, the commercial software has the advantage of being market leader. That brings with it that it, in general, is easier to find a Mathematica package to do X that to find a Sage one.

If Sage really is to Mathematica what Gimp is to Photoshop then IMO it definitely does not obviate using Mathematica. The Gimp/PS argument is well worn.

>so unless you are suggesting that loading Mathematica onto the Pi will, in fact, destroy it, I don't see any merit to this analogy

That's not really how you refute an analogy. In any analogy, you can find differences, but not all differences are relevant. You could say "Mathematica isn't made of wood", or "Mathematica isn't full of soldiers", but these differences don't weaken the analogy.

You have to look at the claimed similarity (in this case, ulterior motives) and show a difference that conflicts with that claim.

You have failed to do this, and so your refutation falls flat.

The Greeks could not 'apt-get uninstall --purge' the Trojan Horse. QED.

QED... as in, "I've demonstrated what I wanted to say, regardless of what the original claim was."

OP was talking about fearing the 'gift' because it might be a ploy to get you data-locked into Wolfram's cloud suite, or some other kind of bait-and-switch. As in, there might be unforeseen consequences of embracing this offering. I don't think there was any implication that we might not be able to uninstall Mathematica. I think it's an apt analogy.

My fellow bovine friend, you're now misinterpreting the analogy (and Greek mythology, but I assume you mistyped and meant "the Trojans" and not "the Greeks"). In the analogy, Troy is not a single person's computer. Troy is the software ecosystem.

Consider Microsoft's old "embrace, extend, and extinguish" strategy, which devastated the PC software ecosystem in the 90s. Was that problem solved by individual users uninstalling Microsoft's products? Of course not. Recovering from that destruction was a far more difficult and grueling process which isn't quite finished even today.

The Trojans could--just set the wood horse aflame.

No, this is actually valid criticism. People are generally adverse to learning new software programs, when the one they've been using for years has served them so well. With this in mind, we'll be exposing thousands of students to closed source software when the open source alternatives are more than adequate for teaching. By the time students need features in Mathematica that are not present in the open source alternatives, they will have the skills to contribute those features back as pull requests.

This is a Trojan horse. It undermines the open source alternatives. The Pi foundation here is betraying its open source roots.

> The Pi foundation is betraying it's open source roots.

No, it's not betraying it's open source roots. It has none. The Raspberry Pi has been a proprietary environment dressed up in open source clothing from the beginning.

The Raspberry Pi has most of its processor silicon devoted to a chip that you are not allowed to touch -- the ARM6 core is really more of a coprocessor to the GPU, which comes with a big binary blob. OK, you say, forget the GPU, I'll just use the little ARM core. Nope! You can't boot the system at all without the blob.

Then we've got their laughable attempt to pass off a shim that delegates function calls as an open-source driver. Or their support for software patents, with patent-restricted chip features that require separately purchased licences.

The Pi foundation's roots are with Broadcom, a company known very well for its hostility to open source.

I believe most of your complaints can be explained by their desire to create the cheapest device possible, but still powerful enough to be useful in an education setting. Corners had to be cut somewhere, and pure open hardware is expensive and hard to come by. If you want to drive the cost down, that typically means using popular silicon, which in turn typically means dealing with companies like Broadcom.

Just because it's not 100% open source doesn't mean it has no roots there. I know this is hotly debated in many circles, but in my book it doesn't have to be all or nothing.

Personally, I feel they made the right decision for their project. I'd rather introduce kids to linux, computing, and hacking on a device that is relatively open rather than on a purely open device that schools may not even be able to afford.

Don't get me wrong, the Pi is a positive development, and I'm glad it exists. But I don't think that we should think of it as something with open source roots. Sure, you're never going to get a 100% open device at these costs. But something like the BeagleBone Black is in the same price range as the Pi but doesn't have all of these issues (i.e., the lack of openness is not just due to pragmatic cost reasons, but also "because Broadcom".)

The chip in the Pi was used because the guy that started the project works for Broadcom.

As a comparison, the Beaglebone Black (http://beagleboard.org/products/beaglebone%20black) uses a TI chip, which is at least fully and properly documented. It is also better than the BCM chip at pretty much everything except high-resolution video decoding.

The Raspberry Pi is a cool machine, but the "open source" hype about it is rather exaggerated.

PowerVR isn't fully documented, is it?

You're right, but for the wrong reasons. As far as I understand it, the Pi foundation doesn't have much in the way of open-source roots. Their aim wasn't to produce an ideologically pure device, but to create a dirt cheap but fully functional computer as an educational aid to teach kids to code. Open source software just happened to be a cost-effective way of achieving that goal.

I think they were were so focused on the educational side that they didn't realise how interesting the device would be to hackers and hobbyists. Remember the problems launch where the demand hugely outstripped the initial manufacturing runs.

> The quote in question is a reference the Trojan horse, so unless you are suggesting that loading Mathematica onto the Pi will, in fact, destroy it, I don't see any merit to this analogy.

It is, as you say, an analogy and not to be taken literally.

Someone offering a suspiciously good gift can be expected to expect something in return that may not be to your benefit - particularly if the gift giver is not known for being a philanthropist.

Maybe a good counterpoint would be to suggest that OP "not look a gift horse in the mouth". That being said it isn't too difficult to imagine Wolfram having ulterior motives. Overall I think it's a good thing and a good act done for bad reasons is still a good act (though agreed, source code would be nice)

Well, what is the possible catch? I can't see it. My immediate guess is that they think the money isn't in selling the software itself but to have some sort of cloud-based subscription model, and having it on a Raspbian without charge would be a good lure. What ulterior motives do you foresee?

I define myself as a pragmatic computer user. I use Linux because it is the best tool for the job, but I use closed source programs when they are the best tool.

In program why would someone want a closed source solution that cost $2,000 for profession use and $200 for a one year personal license when we have so many great Open Source languages? Why program in something closed source any more? I can't see that working especially in statistics and math.

How would any closed source (secrets) Mathmatica be a better option than an open source language (Sage)? Really want to understand the thought process.

Also Trojan hHrse analogy is always used when referring to closed source programs coming into an environment. Take your issue up with RMS (Richard Stallman)

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've always wondered, who are these sycophants who are always cheering Wolfram in his long self-aggrandising blog posts? Are they his employees or something?

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.

> I doubt very much that Sage has any mechanism for flashing LEDs through the GPIO pins of the Pi

You use the RPi.GPIO module, as follows:

    import RPi.GPIO as GPIO

There's some more information here:

https://code.google.com/p/raspberry-gpio-python/wiki/BasicUs...

Good to know, thanks for the link.

> How would any closed source (secrets) Mathmatica > be a better option than an open source language (Sage)? > Really want to understand the thought process.

Probably because it does something Sage can't do. I can think of several reasons why I'm attached to Mma.

1) It has a great help system. Having 3 to 100 examples per help entry, and a See Also section in every single one f them is invaluable, at least for me. I almost can't use any other language's help system after using this one, because it's so good. Good yet simple; nothing prevents others from maintaining at least Examples-driven documentation but almost nobody does that, and I'm not aware of a single other documentation model that would include [consistently] both Examples and See Also sections. With its interactivity and tutorials on top, MMA's DocCenter is completely unbeatable.

2) Sage is for mathematics, Mma is for everything. That's what Wolfram says, and that's what programmers usually giggle at. Ask non-programmers, like me, about it. I use Mma for everything, and I can't imagine using Python instead. I actually feel rather weird explaining this on HN. Have you read about Blub Paradox in “Beating the Averages”? Mathematica vs Sage is Lisp vs Python. Of course I'd never use Sage. Wolfram language is really good: I use it as a basic markup for every piece of structured data that I need to write down in everyday life. I can't think of any single alternative here: other markup languages I know of are way too clumsy for this.

3) Mma has a unique interface, a mix of GUI and CLI. Nobody else has that. IPython Notebooks is a (surprisingly late) attempt to mock it, but for me it looks a bit like an exercise in sympathetic magic: for example, they've copied In and Out labels that are actually Mma expressions, that is, a part of its language. Not that it's an essential part but still, it looks like IPython authors were rather clueless about what they tried to imitate. Mma notebooks themsevles are written in Wolfram language while IPython Notebooks are written in that miserable excuse of a markup called JSON.

Mathematica is Enterprise-class emacs. It's general, powerful, AND also user-friendly and good looking, unlike emacs. I can be sure that lots of people will use it who would never dive into a black hole of a terminal [until absolutely neccesary], yet all the power of CLI will be with them when they use Mma. Well, this sounds like the kind of people I want to write software for.

As for closed source, Mma is just too good for that being a crucial drawback. Besides, a truly mathematical result never depends on anything external so it doesn't matter whether you use black boxes while producing it, or not. If only mathematical result is correct and valuable, then it /must/ be self-contained.

IPython has to my knowledge always used those kind of labels for inputs and outputs. It just follows from the CLI convention.

I looked up how it was in version 0.0.1 from 12 years ago and it turns out the original CLI format was made to look like Mathematica [1]: "Interactive execution with automatic history, tries to mimic Mathematica's prompt system".

[1] https://gist.github.com/fperez/1579699

Ah, it's a 12 years old story, then. I wasn't aware of that; thanks.

> Well, what is the possible catch? I can't see it.

It's obvious. The first exposure to something expensive is often free. Heroin. Women. Alcohol. All those things that end up costing much more than one can imagine at the outset.

It's a classic marketing strategy, and it works.

> My immediate guess is that they think the money isn't in selling the software itself but to have some sort of cloud-based subscription model ...

No, it will be more like Wolfram Alpha, a way to show what a product can do without providing the full experience.

I believe the idea here is to prevent exposure to similar free software such as Sage by exposing students to Mathematica first. Once they learn it, they may be reluctant to learn something else.

It's actually a simple concept. Apple used that in schools for ages, first with the Apple II, then with low-end Macs. The software you use in high-school or college stands a good chance of becoming your choice later in life.

> acting like you have some God-given right to inspect its inner workings.

As it happens, closed-source mathematical software is next to useless for anything serious, and for scientific work, it's fatal. This is the single biggest obstacle to programs like Mathematica -- it may be useful for experimentation, but once one intends to publish, it has to be completely excluded from the process.

Imagine someone claiming to have cured cancer, but using a method that other laboratories cannot imitate or inspect, essentially black magic. That's what faces people who try to use Mathematica in scientific work. It violates the most basic principle of science -- transparency.

Also, funny thing, the quote is not a reference to the Trojan horse but wisdom that derived from that trick the greeks pulled. It doesn't mean "don't allow wooden horses in your castle", it means "maybe there is something behind the obvious".

Not godgiven, but RMS philosophy...

Reply on news.ycombinator.com