Hacker News new | past | comments | ask | show | jobs | submit login

With debugging, we'll get there. I have some prototypes, but it's a long way from a research prototype to production, and we're still quite busy on getting actual products out the door.

And even at the moment, the fact that so much of a typical program in the Wolfram Language is referentially transparent means its easy to pick something up out of your codebase and mess around with it, then put it back. That's a huge win over procedural languages.

But in terms of the language, many of the ideas Chris is talking about are already possible (and common) in the Wolfram Language:

It's functional and symbolic, so programs are all about applying transformations to data. In fact, the entire language is 'data', with the interesting side effect that some 'data' evaluates and rewrites itself (e.g. If).

The mathematical sum notation is unsurprisingly straightforward in WL.

And StandardForm downvalues allow for arbitrary visual display of objects in the frontend.

For example, the card would have a symbolic representation like PlayingCard["Spade", 1], but you could write

  StandardForm[PlayCard[suit_, n_]] := ImageCompose[$cardImages[suit], $cardNumbers[n]];
to actually render the card whenever it shows up in the FrontEnd.

Graphics display as graphics, Datasets display as browseable hierarchical representations of their contents along with schema, etc...




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: