HN2new | past | comments | ask | show | jobs | submitlogin
Wolfram Compute Services (stephenwolfram.com)
230 points by nsoonhui 58 days ago | hide | past | favorite | 136 comments


Man, I miss Wolfram Language. Once you've twisted your brain a little to grok its usage, it's such an incredibly high-value tool, especially for exploration and prototyping. I saw it more as a do-anything software tool for researchers rather than as a language aimed at programmers, so I put on a researcher hat and tried to forget everything I knew as a professional programmer, and had a few memorable seasons with it around 2016-2020. I remember calculating precisely which days of the year would cause the sunlight to pass through a window and some glass blocks in an internal wall, creating a beautiful light show indoors. It only took a couple of minutes to get a nice animated visualisation and a calendar.

Nowadays I'd probably just ask Claude to figure it out for me, but pre LLMs, WL was the highest value tool for thought in my toolbox.

(Edit: and they actually offer perpetual licenses!)


The power of the language came from the concise syntax (I liked it more then classical LISPs) with the huge library of Mathematica. When Python is "batteries included", Mathematica is "spaceship included".

If this was open sourced, it had the potential to severely change the software/IT industry. As an expensive proprietary software however, it is deemed to stay a niche product mainly for academia.


> If this was open sourced, it had the potential to severely change the software/IT industry.

As an engineering undergrad I had a similar feeling about Matlab & Mathematica.

Matlab especially had 'tool boxes' that you bought as add-ons to do specific engineering calcs and simulations and it was great, but I almost always found myself recreating things in python just because it felt slightly more sane to handle data and glue code.

Pandas and Matplotlib and SciPy all used via an ipython notebook were almost a replacement.


As discussed on another thread, the outcome is poorly tools glued together, due to lack of roadmap and polish that commercial software usually supports, instead of volunteers coming and going, only caring for their little ich.


I’m not sure about that. I used to use LabView and its various libraries often. The whole thing felt scattered and ossified. I’d take a python standard library any day.


Yet most EE engineers rather use a graphical tool like LabView or Simulink.

Not everyone is keen doing scripting from command line with vi.


I once interned at a lab that used a piece of surely overpriced hardware that integrated with Simulink. You would make a Simulink model, and you’d click something and the computer would (IIRC) compile it to C and upload it to the hardware. On the bright side, you didn’t waste time bikeshedding about how to structure things. On the other hand, actually implementing any sort of nontrivial logic was incredibly unpleasant.


Hahaha yep, so much clicking after One day my finger was actually sore.


Maybe it’s different for those actually working in the profession and n=1 but in my (many) years of studying EE I never used these tools even once.


No not really, depending on the application Cpp or python has been the language of choice in the lab. Labview was used because it was seen as easy to make UIs for operators in production facilities, but even that was a regrettable decision. We ended up rewriting LV business logic in c# and importing it as a lib into a LV front end.