3 ms·

There's no way a proprietary environment can be the future of programming, but Wolfram does have the right ideas. Ctrl-F for "symbolic" in that page returns 14

by pshc 13y ago

There's no way a proprietary environment can be the future of programming, but Wolfram does have the right ideas. Ctrl-F for "symbolic" in that page returns 14 results. The way I interpret it, they're aiming (rightly) to dismount programming from its local maxima in expressivity that is plaintext--a feat that Lisp and Smalltalk and a horde of gimmicky visual languages* couldn't do. Wolfram Language won't succeed here, but they'll get closer than anyone else has. * Not saying that visual languages are inherently gimmicky; just that when you do write one, it's extremely tempting to fall into toyland.

solipsism 13y ago
The way I interpret it, they're aiming (rightly) to dismount programming from its local maxima in expressivity that is plaintext Where do you get this idea, out of curiosity? Every demonstration of Wolfram Language I've seen has been plain text. And what makes you think they'll get farther than everyone else?
- pshc 13y ago
  When I say plaintext, I mean like a .c file--a bag of bytes that may or may not parse into the AST you intend. Modern editors dress plaintext up with syntax highlighting, auto-complete, folding, and such--the code has a veneer of structure--but the basic representation remains plaintext. (And for good reason... plaintext is easy to edit with existing editors, tractable, easy to parse, somewhat easy to tool, moderately easy to version control, and hard but possible to transform automatically. But I believe plaintext is only a local maxima in code representation. We just don't have a good enough editor for code ASTs (yet)). Now in the Wolfram Language REPL they have some rich input capabilities like http://reference.wolfram.com/language/example/BooleanOperationsAndGraphs.html http://reference.wolfram.com/language/example/BooleanOperati... . I suspect these are still underpinned by plaintext dumps internally, though, judging by http://reference.wolfram.com/language/tutorial/VariablesInPureFunctionsAndRules.html http://reference.wolfram.com/language/tutorial/VariablesInPu... . I should have said that they've gotten farther than anyone else so far, perhaps, but I haven't tried WL yet, so who knows?
  - solipsism 13y ago
    Yeah, with respect, I think you're being duped. What you're seeing is plain text being drawn as images, making you think the images are input. You only have to click the code to see the plain text (and its not pretty). Not only have they not gone farther than others, I cant find a single instance of anything in WL that's not plainly plain text. They have interesting output, not particularly interesting input.
    - pshc 13y ago
      Damn, that's too bad. Oh well. It's a closed source dead end anyway. Time to dust off the old side project.
    - tluyben2 13y ago
      I think the great thing here is the output; better than anything we have in open source so far. I takes a very large amount of effort to make something like that for your language of choice. For the input I agree; it's text and not very nice.
  - taliesinb 13y ago
    > I suspect these are still underpinned by plaintext dumps internally, though, judging by http://reference.wolfram.com/language/tutorial/VariablesInPu.. http://reference.wolfram.com/language/tutorial/VariablesInPu.... . You suspect wrong.
seanmcdirmid 13y ago
> The way I interpret it, they're aiming (rightly) to dismount programming from its local maxima in expressivity that is plaintext--a feat that Lisp and Smalltalk and a horde of gimmicky visual languages* couldn't do. I'm sure they are referring to how the code is evaluated [1] vs. how it is stored and manipulated by the programmer. Lisp and Prolog are the canonical examples of symbolic languages, and they are both based on plain text. [1] http://en.wikipedia.org/wiki/Symbolic_programming http://en.wikipedia.org/wiki/Symbolic_programming
- taliesinb 13y ago
  That's right. We can serialize any Wolfram Language expression as ASCII, if necessary (and functions like Save do exactly that -- traversing the symbol graph to find all definitions that a piece of code depends on) and dumping it out. But you wouldn't want to do that in the case of packed arrays, timeseries, or images -- the result would be incomprehensible (and incomprehensibly large). Ultimately, Wolfram Language code consists of expression trees, these trees are "conceptually" the equivalent of their FullForm (http://reference.wolfram.com/language/ref/FullForm.html http://reference.wolfram.com/language/ref/FullForm.html). What makes a WL expression "code" instead of "data" is that evaluating it will change the state of the kernel so that it has new rules attached to various symbols (functions + variables). Plaintext files are just one vehicle for WL expressions. And in many cases there are cool things you can do that require the code to live in an IDE that can render WL expressions natively, such as Blur[<<picture of dog>>] or GeoLocation[<<NLP interpretation of "berlin">>] For machines, the thing now known as the Wolfram Symbolic Protocol is used to talk WL expressions over the wire. And there are two efficient binary serialization formats: "MX" and "WDX".

by pshc 13y ago

solipsism 13y ago

The way I interpret it, they're aiming (rightly) to dismount programming from its local maxima in expressivity that is plaintext Where do you get this idea, out of curiosity? Every demonstration of Wolfram Language I've seen has been plain text. And what makes you think they'll get farther than everyone else?

pshc 13y ago
When I say plaintext, I mean like a .c file--a bag of bytes that may or may not parse into the AST you intend. Modern editors dress plaintext up with syntax highlighting, auto-complete, folding, and such--the code has a veneer of structure--but the basic representation remains plaintext. (And for good reason... plaintext is easy to edit with existing editors, tractable, easy to parse, somewhat easy to tool, moderately easy to version control, and hard but possible to transform automatically. But I believe plaintext is only a local maxima in code representation. We just don't have a good enough editor for code ASTs (yet)). Now in the Wolfram Language REPL they have some rich input capabilities like http://reference.wolfram.com/language/example/BooleanOperationsAndGraphs.html http://reference.wolfram.com/language/example/BooleanOperati... . I suspect these are still underpinned by plaintext dumps internally, though, judging by http://reference.wolfram.com/language/tutorial/VariablesInPureFunctionsAndRules.html http://reference.wolfram.com/language/tutorial/VariablesInPu... . I should have said that they've gotten farther than anyone else so far, perhaps, but I haven't tried WL yet, so who knows?
- solipsism 13y ago
  Yeah, with respect, I think you're being duped. What you're seeing is plain text being drawn as images, making you think the images are input. You only have to click the code to see the plain text (and its not pretty). Not only have they not gone farther than others, I cant find a single instance of anything in WL that's not plainly plain text. They have interesting output, not particularly interesting input.
  - pshc 13y ago
    Damn, that's too bad. Oh well. It's a closed source dead end anyway. Time to dust off the old side project.
  - tluyben2 13y ago
    I think the great thing here is the output; better than anything we have in open source so far. I takes a very large amount of effort to make something like that for your language of choice. For the input I agree; it's text and not very nice.
- taliesinb 13y ago
  > I suspect these are still underpinned by plaintext dumps internally, though, judging by http://reference.wolfram.com/language/tutorial/VariablesInPu.. http://reference.wolfram.com/language/tutorial/VariablesInPu.... . You suspect wrong.

seanmcdirmid 13y ago

> The way I interpret it, they're aiming (rightly) to dismount programming from its local maxima in expressivity that is plaintext--a feat that Lisp and Smalltalk and a horde of gimmicky visual languages* couldn't do. I'm sure they are referring to how the code is evaluated [1] vs. how it is stored and manipulated by the programmer. Lisp and Prolog are the canonical examples of symbolic languages, and they are both based on plain text. [1] http://en.wikipedia.org/wiki/Symbolic_programming http://en.wikipedia.org/wiki/Symbolic_programming

taliesinb 13y ago
That's right. We can serialize any Wolfram Language expression as ASCII, if necessary (and functions like Save do exactly that -- traversing the symbol graph to find all definitions that a piece of code depends on) and dumping it out. But you wouldn't want to do that in the case of packed arrays, timeseries, or images -- the result would be incomprehensible (and incomprehensibly large). Ultimately, Wolfram Language code consists of expression trees, these trees are "conceptually" the equivalent of their FullForm (http://reference.wolfram.com/language/ref/FullForm.html http://reference.wolfram.com/language/ref/FullForm.html). What makes a WL expression "code" instead of "data" is that evaluating it will change the state of the kernel so that it has new rules attached to various symbols (functions + variables). Plaintext files are just one vehicle for WL expressions. And in many cases there are cool things you can do that require the code to live in an IDE that can render WL expressions natively, such as Blur[<<picture of dog>>] or GeoLocation[<<NLP interpretation of "berlin">>] For machines, the thing now known as the Wolfram Symbolic Protocol is used to talk WL expressions over the wire. And there are two efficient binary serialization formats: "MX" and "WDX".