Anything you, as an employee of Wolfram, create or prototype or whatever with it can have a future. You would have no questions asked. And as an employee I presume you also get the possibility to inspect the source, and perhaps even email the dev teams directly to fix or modify things as you see fit. In such an environment, even simple things like prototyping are great.

Actually, the cases you described, making an investor demo or the like can be argued to be prohibited by the license! Does an investor demo or MVP count as commercial use? I’d say so. Would an MVP potentially produce data that I might use in the production of a “real” system? Likely so. Both of these are expressly prohibited by the license, straight up in the first section.

“Yeah but you’ll get away with it fine.” Will I? I also must respond to Wolfram with a record of my use within 10 days of being asked.

How is this an attractive state of affairs to build anything, even for paltry testing of an idea?

You make some very good points, and you might be right. My educated guess is that this strategy is to get as many people as possible to try this. That would mean letting people do prototypes for commercial purposes too, but not to ship in production. Now, whether that will be enough to keep people hooked so that they use us in production as well depends on a lot of factors, both technical and political.

I think your worries about what is kosher and what isn't under this license are warranted and I'll try to point this to people internally so that the licensing terms can be clarified.

I think that what Wolfram is missing is that devs are not interested in getting hooked and then paying subscription fees. The payment model is the problem and devs won't be easily suckered by a free version.

I wouldn’t mind paying a license fee... that wasn’t hundreds or thousands of dollars per user, per core. Wolfram makes Microsoft licensing look cheap.

If Wolfram adopted the Unity model I’d be much more willing to try it out. (free to cheap for hobbyists and small businesses, steep rise in price based on revenue per year)

Isn't that the idea of this announcement? Free to start, pay when you deploy.

No, Unity allows commercial uses either for free in some circumstances, or very, very cheap, so long as your annual revenue is less than $2M.

That makes it a no-brainer to use--you pay little or no licensing fees until your game takes off. Unity makes their money off the unpredictable winners, while gifting a nearly free product to the hobbyist and startup ecosystem.

Wolfram Engine is more like the Epic Games (Unreal Engine) model: free to download and play around with, but steep licensing costs before you ship anything. No way to quickly iterate and try things, only paying up when an experiment works out.

UE4's pricing model is a lot like Unity's pricing model nowadays as far as I can tell.

Yes, they changed after Unity are their lunch.

Well, apart from the incredible standard library, there is an interesting programming language.

What I think is missing is a stripped down open source implementation / interpreter. What Gnu Octave is to Matlab. That stripped down variant could or could not share some code with the proprietary implementation (realistically, Wolfram would need to open some parts of their code).

I think octave is invaluable for helping Mathworks: Professional users will almost surely buy a license, but a lot of matlab/octave code can be run and hacked on without a mathworks license (albeit slower, and missing a lot of cool features).

The way it is now, all code written by scientists in the Wolfram language is essentially hostage to Wolfram. An octave equivalent would permit people to trust that they continue to meaningfully own their own code.

It is super unlikely that a stripped down slow but open implementation would ever improve to the point of being a meaningful competitor: The thing Wolfram has built is impossible to replicate in the open source world.

Sure, there are other computer algebra systems and other frameworks / languages, but these have very different strengths and weaknesses that make them appropriate for different niches. E.g. sage permits seamless interfacing with the entire python ecosystem (never write a parser or networking code in mathematica! Everybody and his dog publishes python bindings to their C++ libraries nowadays). Or julia with its multiple dispatch and late-AOT/JIT approach that permits permits to write super fast dynamic code that is Fortran / C / C++ level fast.

Personally, I've found thing since learning Julia I've become pretty distrustful of the whole notion of prototyping in one language and then doing a full implementation in another.

It just seems so unnecessary when you have a language where you can start out in a highly interactive state that seems a lot like Python or Matlab but then you can seamlessly start optimizing or generalizing functions and end up with something that runs basically as fast as C but retains all the dynamic advantages from the prototyping phase.

Yes, Julia's namespace isn't as polluted as Mathematica's is and I think that's a good thing. It's got an amazingly vibrant package ecosystem and packages are treated on such a first class level that as soon as you load a (well made) package, it composes so well with everything else, including other packages that it feels built in. I've never really felt like I was 'writing some shim' to utilize code from a julia package.

I feel the same, except with Common Lisp, whose interactivity is maybe only rivaled by Smalltalk, and whose performance can be made close to that of C for real-world applications.

Yes, in fact Common Lisp was what I almost started investing my energy in before Julia. I almost referenced Common Lisp in the parent post alongside Julia but didn't because I never learned it very well and didn't want to speak from ignorance.

My understanding though is that most of the statements I made also apply in CL though my impression at least from the point of view of scientific computation is that Julia's community is more energetic than CL's. Certainly Julia still has lessons to learn from CL though.

I get the impression that the communities are different. Not that Julia's is "more energetic" (there's actually quite a bit of activity around CL too), but that it's simply a different crowd. The Julia people seem to me to be coming more from the application side of things - computational scientists who want to do a certain job - while the CL people are more interested in CL as a language, without a specific application field in mind. So although neither of the communities are especially large, the Julia bunch have been more focused on good libraries for scientific computation, which is why their ecosystem is better in that respect. (Also, the "Lisp curse": scientists are more likely to choose Julia as a new language, because it looks more like the languages they already know.)

Source: I do computational biology with Julia, hobby projects in Common Lisp.

True, if I was more careful I’d say Julia’s scientific / numerical community is more energetic. I definitely don’t want to sound like I’m dissing CL as I have great respect for it and want to be better acquainted one day.

Julia is influenced by the Common Lisp Object System. But it made it fast for numerical computing. So there is a Julia lesson for CLOS...

http://p-cos.blogspot.com/2014/07/a-lispers-first-impression...

Indeed, and that actually played into my path to using Julia. I had fallen down the lisp rabbit hole and was super interested in the ideas it advocates and was trying to decide on a dialect to try to commit to for my physics numerical work. After spending some time in decision paralysis (even though in hindsight, CL was probably the clear dialect to choose), I discovered that Julia actually inherited a lot of good ideas from the lisp family and that it had its fair share of cool ideas of its own. Eventually, I made up my mind and settled on Julia as my main language, though I screw around with elisp every now and then for my emacs config.

I’d like to come back to CL at some point though and gain some proficiency as I think there’s a lot in CL left for Julia to learn from.

I don't think interactivity and performance are enough to make a good production language. For example, I find Java painful to write without a good IDE, because of all the boilerplate, however it's that boilerplate that makes it very easy to read and refactor.

Agreed. They have to have a good way to write it (an IDE), a good debugger, a good profiler, a good library ecosystem, a good community, a good deployment story, reproducibility, portability across platforms, etc. I find commercial support helpful as well. Common Lisp has all of that.

Do you now find that doing both the prototype and full implementation in Julia the better option?

Sorry, couldn't figure this out from your comment whether you prefer Julia or some other language for doing the prototype and full implementation. If you can clarify this explicity, it would be helpful.

Apologies for the lack of clarity. Yes, I find I really like using Julia from start to finish and really admire that I can do so without compromise.

I find this approach to be straight up superior to the usual pattern where one starts out in a slow dynamic language to build the prototype and then either replaces certain functions with interop calls to a fast language (losing all the features that brought you to your dynamic language in the first place!) or straight up replacing your entire prototype with a production version written in your fast language and providing bindings to your slow language.

I fail to see how you build a business around this technology when you expect people to use it for predominantly investor demos and hackathons.

MVP for investor is commercial use.

They allow commercial use for free--just not production use.

"You can use it to develop a product for yourself or your company."