Why Wolfram tech isn’t open source (2019)
51–60 of 316 posts
Re: Why Wolfram tech isn’t open source (2019)
#52Re: Why Wolfram tech isn’t open source (2019)
#53Earlier quoted context omitted.
At first I thought, "how could anything be slower than python?" And then I figured that you probably would've ported it to leverage things like numpy which makes a lot of operations into native code and takes advantage of highly optimized blas libs, etc.
Even native python is not as slow as people expect. And scientific languages are terribly slow, see for example loops in Matlab, which are terribly slow.
I'll agree that mathematica was really slow (but very expressive) when I played with it last. I think this comes down to it's lispy heritage.
julia is an example of a lang that is fast, but even it can be slow because of GC depending on the workload.
Re: Why Wolfram tech isn’t open source (2019)
#54Almost none of the reasons have anything to do with releasing the source. You can release the source but still maintain central control. They shouldn’t even have posted this. Obviously they want to make money from their products, and that’s fine.
Yea, it's embarrassingly bad. It sounds like their idea of open source is something along the lines of "slap a MIT license on it, throw it over fence, and hope random nerds on the internet finish it while we wait idly."
Re: Why Wolfram tech isn’t open source (2019)
#55all of these points can be just countered by pointing to sqlite.they have a drastically different community philosophy that shows that there is no such thing as THE oss development model. A language without an open source core is hard to take seriously unless maybe it is just part of a proprietary software suite (max/msp,labview etc.) that makes little sense to use without, but i guess this is exactly where wolfram s…
Re: Why Wolfram tech isn’t open source (2019)
#56Earlier quoted context omitted.
At first I thought, "how could anything be slower than python?" And then I figured that you probably would've ported it to leverage things like numpy which makes a lot of operations into native code and takes advantage of highly optimized blas libs, etc.
Even native python is not as slow as people expect. And scientific languages are terribly slow, see for example loops in Matlab, which are terribly slow.
Re: Why Wolfram tech isn’t open source (2019)
#57It would be more interesting to address why they chose a pricing model that guaranteed their products would never be a more mainstream consumer product and pretty much irrelevant for almost all enterprise contexts where a computational or analytical capability is needed. Because I don't think they are so stupid this wasn't a conscious decision on their part.
Re: Why Wolfram tech isn’t open source (2019)
#58Earlier quoted context omitted.
I don't really understand the definition of open source. I used to hear people say stuff along the lines of "If you just release the source and don't accept patches then that's not real open source" But the opinion on that has changed I guess?
> If you just release the source and don't accept patches then that's not real open source this is commonly referred to as "source available".
I completely agree that Mathematica needs a steady stream of income to continue, it is a great language and for many use cases the best available. But every time I see a paper that relied on Mathematica for critical conclusions I'm forced to dismiss it as incomplete speculation.
Re: Why Wolfram tech isn’t open source (2019)
#59Earlier quoted context omitted.
Yea, it's embarrassingly bad. It sounds like their idea of open source is something along the lines of "slap a MIT license on it, throw it over fence, and hope random nerds on the internet finish it while we wait idly."
Well the guy seems like a VP in corporate, probably would struggle with more than hello world himself...
Re: Why Wolfram tech isn’t open source (2019)
#60Earlier quoted context omitted.
At first I thought, "how could anything be slower than python?" And then I figured that you probably would've ported it to leverage things like numpy which makes a lot of operations into native code and takes advantage of highly optimized blas libs, etc.
Even native python is not as slow as people expect. And scientific languages are terribly slow, see for example loops in Matlab, which are terribly slow.
If a Matlab user don't need Simulink or one of it's numerous costly toolboxes, this user should give Julia a try.