Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Why Wolfram tech isn’t open source (2019)

blog.wolfram.com

Post reply on HN
Print view View original

41–50 of 316 posts

Re: Why Wolfram tech isn’t open source (2019)

#41

Post by jasode »

paxys wrote: post #7

Most of their points are valid for community driven open source projects but the existence of large corporate ones like Chrome, Android, .net, VS Code, Tensorflow and lots more prove that exerting tight central control while being fully open source is very much possible.

>but the existence of large corporate ones like Chrome, Android, .net, VS Code, Tensorflow and lots more prove that exerting tight central control while being fully open source is very much possible.

All of your examples are subsidized by a parent corporate sponsor that makes billions from something else. Chrome can be "free as in beer" and Chromium source can be "free as in libre" because Google/Alphabet make billions in ads from a search engine. It's easy for MS to release VSCode and .NET for free if billions are earned from MS Office, Windows, SQL Server, etc.

Wolfram doesn't have another product that rakes in billions such that any licensing income loss from hypothetically open sourcing Mathematica would be an insignificant rounding error.

Re: Why Wolfram tech isn’t open source (2019)

#42

Post by adgjlsfhk1 »

dralley wrote: post #26
sidpatil wrote: post #16

Earlier quoted context omitted.

FORTRAN, the OG of scientific languages, is not slow. In fact, that's why it's still used to this day.

In fact it may well be the fastest language - although it's hard to compete with the sheer number of man hours spent on C/C++ compilers.

while it isn't inherently slow, all the open source compilers are missing a lot of modern improvements. The default libm in particular is often a few times slower than those provided by Julia.

Re: Why Wolfram tech isn’t open source (2019)

#45

Post by jrm4 »

As a huge FOSS guy, I have to say -- this list is excellent.

I think where this debate/discussion goes off the rails is a lack of appreciation for every aspect of things in their place.

The GPL + Stallman + FOSS et al are absolutely necessary as a sort of extreme visible working model; an endpoint to an Overton Window of this sort of thing and as such I completely support it.

But also, I also do not believe that supporting it requires full and complete buy-in, the way some people do religion. I'm glad it's THERE, and ALSO not everyone has to do it. This is not hypocritical or even conflicting.

Re: Why Wolfram tech isn’t open source (2019)

#46

Post by zenonu »

Multiple comments here talking about releasing the source code, as if it's just throwing it over the wall. Open-sourcing software successfully is a commitment to engage with the community on design and implementation over time. Otherwise at best it will be forked and then then lead by another group.

Re: Why Wolfram tech isn’t open source (2019)

#47

Post by rob_c »

seriously on point 9? "Open source doesn’t bring major tech innovation to market"

I don't know where to begin with this alone let alone the rest of the diatripe.

Closed works for them, their product and their vision, but keep it in scope of what works for you or doesn't, not attack an alternative model because you feel superior...

Re: Why Wolfram tech isn’t open source (2019)

#48

Post by munro »

I have a friend that uses Mathematica, and I had some symbolic math I wanted to run a solver on last week, so I thought I'd give it a try. It wasn't any better than sympy from what I could tell. I ended up taking a monte carlo approach anyway. Generating the simulations was soooo slow in Mathematica compared to numpy. After that demo, I'll have to say the Python ecosystem is far superior for all it's flaws. Sure the documentation is all over the place, there's no unified design so it all feels different, and lot of choices to do the same thing. But when you need something to work right now, at least I have options to switch things out or even fix the code. Wolfram has a lot of lofty ideas that hasn't been delivered on.

13) Try to do everything, but poorly

But seriously how can you build a unified model of computation, when we're still figuring things out? I just tried jax yesterday, their approach to jit & automatic vectorization is really interesting. Wolfram, do you even have a jit? This article gives me less respect for the Wolfram Tech, they're building off the shoulders of giants trying to package it up in some nice soft serve product--it's not a good look to criticize something your building your empire off of.

Re: Why Wolfram tech isn’t open source (2019)

#49

Post by zitterbewegung »

Quoting from the blog post.

But Wolfram’s vision for computation is much more profound—to unify and automate computation across computational fields, application areas, user types, interfaces and deployments.

The problem with Wolfram Tech is the above objective can be done by doing one thing and is improving developer ergonomics.

I would say that the Wolfram Language would need a complete overhaul. When I was using it was basically combining Lisp (but using the original M-expression syntax), Symbolic computation and an approach to including every possible mathematical field.

These problems are just since Mathematica is so old it didn't need to or even the concepts of what it achieved it is one of the biggest issues. So, if the Wolfram language just made a bunch of non breaking changes and copy Javascript like syntax then it might actually be useful but right now I don't see it achieving anything like that at all.

Re: Why Wolfram tech isn’t open source (2019)

#50

Post by mwcampbell »

> Paid software offers an open quid pro quo

This section points out a valid problem with business models based on open source, but closing the source and requiring payment doesn't inherently solve the problem. In fact, closing the source, which is the usual means of enforcing the paid license, introduces another problem: the developer could be doing something nefarious in addition to requiring payment, and it would be very difficult to find that out because the source is closed. True, reviewing a large open-source codebase is also difficult, but not, I assume, as difficult as reverse-engineering a large blob or set of blobs. Perhaps processor architectures and/or operating systems could impose restrictions to make reverse engineering easier, but that would fundamentally be at odds with license enforcement. If only we could fix our species to guarantee trustworthiness.

Post reply on HN