Live data from Hacker News

Free Wolfram Engine for Developers

blog.stephenwolfram.com

351–358 of 358 posts

Re: Free Wolfram Engine for Developers

#351

Earlier quoted context omitted.

> Personally, I've found numeric computation more useful in 99% of the cases; do others have a different experience? Yes, of course they do. For example, if they want to obtain a general, symbolic, solution to a problem, rather than estimates of particular numerical values. I'm sorry to sound a bit dismissive, but on HN it is common to hear people say stuff like "Oh, I find code much more helpful than math" and it's…

A dumbfounded example . All you need for this is a cas system or some gruelling head computation that can solve This step or formula nothing more and not wolfram specifically .

Mathematica is a CAS system. The comment I was replying to was asking whether people saw any use for CAS (symbolic) over numerical computing.

Aside: You're commenting in a style that fits YouTube, or maybe Reddit, but this site has a different commenting culture/style.

Re: Free Wolfram Engine for Developers

#352
post #279

Earlier quoted context omitted.

There are open hardware design tools, some examples: http://iverilog.icarus.com/ https://www.veripool.org/wiki/verilator http://www.clifford.at/yosys/ https://symbiflow.github.io/ https://github.com/Qucs/ADMS http://www.myhdl.org/ https://chisel.eecs.berkeley.edu/ https://wiki.debian.org/FPGA

If you know of any chips taped-out, and shipping in volume, that used any of these as their primary tool, I’d be very interested to know more about that. I’m aware of chisel used to verify some RISC-V cores that were fabricated, but that’s a research POC, not a volume/production ASIC.

All of SiFive's chips use Chisel, it's our primary design language. We use commercial tools post-Verilog (ie, synthesis and place+route). We use Verilator for some simulation, but also use commercial Verilog simulators.

We have chips shipping in volume.

Re: Free Wolfram Engine for Developers

#353
post #55

> Why Aren’t You Using Our Technology? It’s not open source. Even if the engine is “free”, I don’t want to build an open source product with it and hope to be granted a “free production license.” If I build something on my own time I don’t want to ask my employer to purchase a “production license” as soon as it becomes useful. Wolfram believes that mathematics software (or “computational knowledge” or whatever he cal…

>But that’s completely at odds with how most software engineers work these days. Most software is grounded in an open source development and deployment tool chain. Imagine saying this with a straight face. Maybe in web development, but the vast majority of programmers are using closed source tools to produce closed source software. You're either thinking of a tiny picture vs the whole picture (web devs vs programming…

That is true, to some extent, but the cost of commercial software makes my company think really hard before we go that route. It has to have a clear and obvious value, or we are reluctant to seriously consider it.

I'm not talking about the dollars, that's relatively minor. It's all the things around it, especially with licenses becoming more complex, including core counts, including all these weird provisions related to when and how and what features can be used in dev and staging and production, what versions of other software they can work with, etc...

The software that we can buy and just use without thinking about it is great, but it's really few and far between these days.

We can spend weeks or months analyzing the things surrounding the commercial licensing for a product, and that is spending one of our most valuable resources: attention.

Re: Free Wolfram Engine for Developers

#354
post #346

Earlier quoted context omitted.

If no one ever criticized restrictions, we wouldn't have the freedom we have today. Most people here are complaining about the license, not the software. They think the software is good but the license is holding it down. To me this looks like valuable feedback.

I see what youre saying but > They think the software is good but the license is holding it down The issue I'm really trying to point out is They think the software is cost free but the license is holding it down Wolfram Engine has always been good, but it seems people are more in a huff because it's priced free but not open source. I.e expecting that if something is given to you at no cost, it also must be open sour…

Hmm, I see what you mean. I'm under the impression that this isn't the main issue people are having here but what do I know.

One other reason why people might be so upset here is the naming of this product. "Free" is commonly used to describe libre software. This is at best an oversight by the marketing team and at worst deliberately set up to deceive developers.

Re: Free Wolfram Engine for Developers

#355

Earlier quoted context omitted.

Kdb is a very niche product that has open source alternatives that are made use of by the rest of the software industry outside of FinTech. It's not bad, it's just not what the market wants to use because it's a closed box. Wikipedia has an article on Time series databases and they contain a short list of popular TSDBs [0]. On that list 11 are libre-software to some degree and 4 are commercial. Relational TSDBs are n…

Unfortunately, there are no open source alternatives to kdb+. Effortlessly handling hundreds of terabytes of data on a single machine, while consisting of only a 300 kB (yes, kilobytes)... Nobody even came close. Market adoption could be better, but the license costs around $100,000/year (probably the most expensive software per kilobyte). Fintech can afford it, other industries can’t.

> Effortlessly handling hundreds of terabytes of data on a single machine

Single machine, because it can't handle parallel queries, at all, and there are no options to scale it.

Every financial institution I've worked at is busily unwinding their investment in q/kdb. It's legacy tech.

Re: Free Wolfram Engine for Developers

#356

Earlier quoted context omitted.

Unfortunately, there are no open source alternatives to kdb+. Effortlessly handling hundreds of terabytes of data on a single machine, while consisting of only a 300 kB (yes, kilobytes)... Nobody even came close. Market adoption could be better, but the license costs around $100,000/year (probably the most expensive software per kilobyte). Fintech can afford it, other industries can’t.

> Effortlessly handling hundreds of terabytes of data on a single machine Single machine, because it can't handle parallel queries, at all, and there are no options to scale it. Every financial institution I've worked at is busily unwinding their investment in q/kdb. It's legacy tech.

What are they moving to?

Re: Free Wolfram Engine for Developers

#357
post #356

Earlier quoted context omitted.

> Effortlessly handling hundreds of terabytes of data on a single machine Single machine, because it can't handle parallel queries, at all, and there are no options to scale it. Every financial institution I've worked at is busily unwinding their investment in q/kdb. It's legacy tech.

What are they moving to?

Other TS products like OneTick, RDBMSs for TAQ (esp. if you need non-TS indexes), streambase for UI backends

I even met a programmer who hacked something together in Java using the same columnar kdb layout but, you know, multithreaded, so different basket optimization jobs could run simultaneously on the same store.

Re: Free Wolfram Engine for Developers

#358
post #342
post #340

Earlier quoted context omitted.

> First, in Scheme, vectors are not made of cons cells. Lisp, too, has vectors not made of cons cells. > make lists, trees etc. from cons cells It's just that they aren't. Clojure uses persistent lazy sequences not made of cons cells as its basic data structure. And it has strange behavior: user=> (conj '(1 2) 0) (0 1 2) user=> (cons 0 '(1 2)) (0 1 2) Thus we have the same external representation. user=> (class (conj…

> When we call cons with two args we get a Java error with a line number? Clojure requires that the second element in the pair be an ISeq. > since it is mostly incompatible and lacks a lot of the usual Lisp features. I and many others disagree, including Clojure's designers, who designed it as a Lisp. Homoiconicity, macros, S-expressions and FP make a language a Lisp. OCaml and SML are about as different as Scheme an…

> Clojure requires that the second element in the pair be an ISeq.

Lisp doesn't have such a requirement and does not have 'ISeqs'.

> I and many others disagree,

That does not make a convincing argument, since you have never used an actual Lisp - as you recently said.

> including Clojure's designers, who designed it as a Lisp.

Derived from Lisp mostly as a blend of FP, Java hosting/integration and Lisp ideas.

> Homoiconicity, macros, S-expressions and FP make a language a Lisp.

Lists are deprecated in Clojure (for maps, sets, vectors, ...), No interpreter, no Lisp down to the metal, no Lisp in Lisp, no images, core Lisp data structures look different, different API, different syntax, impoverished REPL, strange numerics, Java leaking in many places, lots of compromises because of implementing it on top of a not-Lisp-friendly VM, ...

Lisp derived, but Lisp looks & feels a bit different.

Post reply on HN