Lambda the Ultimate

Thanks for your kind comment David.

Does SPREAD appear as the work of a (computer science) crank? Or may be that SPREAD is untyped, explains the few comments thus far.

Anyway, when you represent booleans as 0's and 1's, the max (|) and min (&) operators follow naturally. The operators are copied from the Enchilada programming language, which - in turn - was inspired by Eric Hehner's work on Unified Algebra, and Daniel Cook's SequenceL.

To answer your question: here are examples of stream multiplication (you can try it yourself by using the online Enchilada interpreter):

[1;2] [3;4;5] * => [1 3;1 4;1 5;2 3;2 4;2 5]
[1;2] - [3;4;5] * => _[2;1] [3;4;5] * => _[2 3;2 4;2 5;1 3;1 4;1 5]
[1;2] - [3;4;5] - * => _[2;1] _[3;4;5] => [1 3;1 4;1 5;2 3;2 4;2 5]

It does not offer me an impression of a crank language. Actually, you'll find there is much in similar with what you are offering and existing logic and query languages, esp. those with a focus on streaming computations (including K/KDB, Bloom, LINQ+C#'s Reactive).

However, your language does feel limited in expressiveness.

when you represent booleans as 0's and 1's, the max (|) and min (&) operators follow naturally

Indeed! That's part of why I liked them.

I've updated my blog to further explain the SPREAD language, using a higher-order spreadsheet analogy. I believe these concepts are highly expressive and not found in any other language to date:

1) Instead of one single value, a cell can have more alternative values: a Set of values
2) Next to Numbers, Strings, Dates, etc, we have an additional cell type: the 'Spreadsheet'
3) A cell can be named or 'Labeled' with anything

Edit: fixed the link to higher-order spreadsheets

I like this honest question quite a bit, so here's my honest answer.

Robbert van Dalen: Does SPREAD appear as the work of a (computer science) crank?

I can't tell because that page is very short: less than two hundred words of prose, with the first hundred in the first numbered list. (Your first post above reprises nearly all the plain english prose.) While nothing seems obviously out of place, and it seems a crisp and clean start, this is very sparse.

I like walls of text when sufficiently tight and focused, so I'd be happy to read several hundred word concise summaries of each main feature. Less than a hundred words per feature seems like word golf undermining clear communication. Since you seem to have an interesting idea, I wish there was more to skim.

Long descriptions of elementary things can be irritating, true, but you haven't come close to risking this yet at all. :-)

Edit: for example, definitions of stream and program would be nice.

Thank you for your reply and excellent advice. I guess writing prose isn't my cup of tea.
I'm an idea person, not a writer, but I absolutely understand the impact of a good story.

I hope that my latest post on 'higher-order spreadsheets' give you more insights? It introduces three main concepts with some additional explanations.

... (now that i'm rereading my blog, every entry more or less suffers from the problems that you mention) ....

Robbert van Dalen: I hope that my latest post on 'higher-order spreadsheets' give you more insights?

More prose is appreciated, and you write clearly, and I'm getting an intuition from that page and others. But I might be cheating now, since I see similarity to a graphical programming language I helped develop around 1994. So I'm fitting to a model I remember instead of getting it just from what you say. Note I'm not pitching the old language, just saying I have a point of reference.

(It was like a spreadsheet in the sense it was immutable dataflow, and was competing with spreadsheets we wanted folks to stop using instead. You could alter cells and watch recalculation of anything dependent downstream. Your page on visualization actually has strong similarities to a UI that ran on NeXT workstations. But I think your visualization is explanation only, not languge UI.)

I'm an idea person, not a writer, but I absolutely understand the impact of a good story.

I hated writing as late as my 20's, because I was predominantly visual. I use words mainly in "scratch processing" space as extra short term memory. As a result it's easy for me to edit without affecting thoughts, which are not especially verbal. I can ask, "Is there a shorter way to say this?" and it pops into mind without affecting how I think.

One gets better at writing with practice. If you're an idea guy, people will keep asking you to explain. :-) It's far easier to explain in person, because it's clear what someone wants to understand next. In writing you must imagine a reader according to some model -- an impatient reader with a short attention span is a good safe model. Every 30 seconds they're going to change the channel, unless you say something useful or fun.

You can assume a reader's attention span lasts until end of paragraph, for at most several sentences. Inside that paragraph, you needn't explain how related ideas connect; it will just be obvious if you avoid useless decorations (like "I, for one," which drives me nuts). The following example story illustrates why explanations can often be skipped.

"Bob almost reached the beehive when the bear returned too soon. After two miles of running, he was completely out of breath, but unscathed."

Why was Bob running? It's implicit in context, and boring to hear explained. As a writer, it's tempting to connect every single thing explicitly. But that's agonizing to read. To make writing crisp, just get points close together and readers will go, "Oh yeah, a bear, I get it." If you can join several short sentences into one longer one, that's often better.

It's tricky to say a lot and leave out enough. But if you're explaining, folks often won't get something you forgot to say. So more is good as long as it's fast and goes by with a whoosh blowing back their hair like a roller coaster.

Your comments demonstrate that you apply your own writing rules with no exception.
Thank you for taking your time to mentor me: I very much appreciate it.

But you did make me curious. To what extend was your 'immutable dataflow' spreadsheet succesful?

Edit: s/taken/taking/

I hope it's not rude if I change spelling of two words. Take this as asking whether you seek editing suggestions about grammar or spelling; you seem like someone who wants feedback, not that I can usually provide it.

To what extent was your 'immutable dataflow' spreadsheet successful?

(I'll answer in a way letting me eventually answer, "Why did it fail?")

Not successful at all, judging from never hearing about it again after leaving to work at Apple in 1995 (on something I found far more compelling). The only thing I did was add object orientation to the runtime, so generics were possible via explicit mapping of api conformance. It was effectively oo via interfaces rather than inheritance, because a 'subclass' would declare, "I conform to api Foo other there in this manner." So it worked even with completely different names.

They called it a "graphical programming language" and it wasn't terribly different from others in existence at that time, except it favored imitation of the NeXT interface builder used to develop it.

Calling it a "language" is debateable, since it didn't have a formal text representation corresponding to the parse tree coming directly from the graph-oriented UI. But it's probably correct to say there was graphical syntax.

It was designed and developed by guys who had worked on (large scale) computer aided design systems for hardware. So their attitude was: graphs work great for circuits, so it should work great for financial instruments in software too. That's actually a reaonable idea. A focus on immutable dataflow comes from knowing you handle signals in circuits as messages instead of editing them. In essence, it was a circuit simulator for nodes composed of programmable operations including the builtin native ones.

The director of engineering had a plan in mind that sounded like this: "Large scale banking has trouble balancing books in a timely manner, given vast data size in daily signal traffic in financial transactions and evolving contract values." Another part of the company was selling software to write derivatives contracts, so they were directly contributing to difficulty in balancing books and correctly hedging positions. So the idea of supplanting spreadsheets is clearly present here, but there was never analysis of spreadsheets as competition.

Here's one of the assumptions they got wrong: "Programming is hard, and Wall Street won't hire the best coders to use normal text languages." (Yes, they will.)

Another bad plan was: "We'll keep this a secret for proprietary advantage, instead of seeking broader adoption." (Are secret languages successful?)

Also, it only worked on a NeXT workstation which was a suicidal market segmentation plan, if you read NeXT histories. (I elided a mini story about Steve Jobs here that sounded like name dropping.)

Spreadsheets typically have a native table model involving rows and columns, making them available to manipulation: you can operate on a column, for example. That sort of thing was absent from the graphical programming language, so it was strictly weaker than a spreadsheet in array processing semantics.

That's close to an exhaustive post mortem, so we should get back to your ideas. Part of what I want you to get from the story above is motivations people bring to design choices. You want folks to understand what problem makes you think of a new idea, because designs are hard to grasp without such context.

I think programming language ideas can be enhanced, in presentation, by including one or more stories about a person with a problem addressed by each PL feature considered. (But beware mockery can subvert almost anything. For example, Crash might say, "Bob wants to balance his bank books, and suddenly realizes only a graphical language on a NeXT workstation could possibly work." Funny, but not very useful.)

I don't mind a bit if someone has unusual ideas that seem crankish.

In fact, that's kind of preferred. What differentiates someone who has a crucial insight from a crank isn't how outlandish the ideas seem; it's how well they hold up under scrutiny and whether the person with the ideas can discuss them rationally and follow other people's logic about them.

So keep in mind what Carl Sagan said: "They laughed at Columbus, they laughed at Fulton, and they laughed at the Wright brothers. But they also laughed at Bozo The Clown."

Most really profound ideas look somewhat crankish when they appear. What Fulton, Columbus, and the Wright brothers have in common is that they took their crankish ideas, worked out all the details, and produced something that wasn't fake and could be verified.

Ray

Ideas can't be cranky, only people can be cranky.

A crank isn't someone who comes up with unorthodox and outlandish ideas, but someone who doesn't think critically or receive criticism very well, whether their ideas are good or not. They wind up in a community of one or that consists mostly of not very critical yes men (people).

That one is willing to present their idea for criticism means that one is not a crank. If you become oblivious to arguments against your work, you are probably on your way to crankiness, and you avoid that by either changing your views to fit reality (if necessary) or to refute the arguments with reasonable counter arguments (if you still think the ideas are right).

We should be very careful here. I mean, people are often labelled as cranks for having unorthodox ideas and arguing about them, but this does not mean they are a crank. We need people at the fringe in a healthy community.