I am glad that someone is working on a new stream processing language, it is a very interesting paradigm. However I hope that they provide some very robust tools for controlling input splitting. As I have spent too much time fighting with awk and wishing it was more flexible(it is frustrating always having exactly two levels of splitting with only matchers on the first and only inverse splitting on the second).

As is you would have to put in filters to resplit input into lines and that is very messy for something that you will need/want to do very often.

For example if you wanted to parse by character it would be wonderful to be able to do the following:

  STDIN | /./{|c|
    # stuff
  }

  STDIN | /\w+/{|word|
    /house/ {
      # when word is house
    }
    /car/ {
      # when word is car
    }
    {
      # default case
    }
  }

If you ever meet Matz, talk to him about programming languages. While he gets some flak for all the problems of his original hobby project (Ruby), he obviously loves programming languages and gives things more thought then people give him credit for. I had the chance to talk to him while I was still a student and full of ideas how the language could be made "better" and he shot them all down. For good reasons, as I know nowadays. So I always love seeing him building languages.

I shared a small story about him and languages quite a while ago, I guess it fits here as well: https://news.ycombinator.com/item?id=6562979

*Yukihiro Matsumoto, creator of Ruby

I'm not sure everyone is familiar enough with Ruby to know who Matz is.

Why do most implementations of FizzBuzz special case % 15? I haven't ever really understood this. Maybe it's just my math-y background, but it always seemed to me you should just check mod 3 and mod 5 without an else between them, concatenating Fizz and Buzz.

Can anyone else comment on this? Most canonical FizzBuzz programs special case 15, and I don't get it.

I'm not really a programming language expert, but it seems to me that having an implementation being the spec wouldn't be a good idea. If the Streem implementation has a bug, then the bug becomes the authoritative behavior. Any platform specific quirks would also make it difficult to have defined behavior.

At the very least, it's going to be amazing to watch a master language designer build a new language from the ground up.

That said, I'm incredibly optimistic about a new Matz language. If I was going to guess, the syntax will be much lighter and the semantics will make VM optimization much easier than in Ruby.

Would be cool if it would incorporate some thinking and concepts from Flow-based programming [1], as that is AFAIK the most comprehensive architecture covering all the aspects of asyncronous concurrent processing that one might run into (multiple in/out-ports, channels with bounded buffers, sub-stream support, etc etc).

[1] http://www.jpaulmorrison.com/fbp/

[2] http://en.wikipedia.org/wiki/Flow-based_programming

Reminds me a lot of Elixir's |> operator, which does the exact same thing. Nice! Curious how it'll turn out to compare with Elixir on other areas.

I love Ruby and I love Matz. With that being said there are some things that Ruby struggles with. I know that there have been some conversations among the core on bringing in more functional concepts to Ruby....at least since April. To me this says that Matz is coming to the conclusion that we may need a new language to get functional right.

While I am sad to see that Ruby may be superseded by a new language I'm really happy to see Matz leading the way with one of the solutions. In the Ruby community we have a expression "Matz is nice and therefore we are nice". That has set the tone for the community in ways that have never been the same in some of the others.

As someone who has had the opportunity to talk with Matz on multiple occasions and work with the Ruby community it would be great to see this as a natural evolution of Ruby and the people who love it... As I have started to move on to working with more functional languages etc. I have started to move away from doing Ruby, but if the community can continue on and evolve with a new language that would be awesome!

"Copyright (c) 2015 Yukihiro Matsumoto" - bit early, ey? ;)

And... here’s an implementation: https://github.com/mattn/streeem

Well, that was quick.

We did a similar thing to the awk source. Made awk scripts first class, you could pipe them to each other.

Can someone help explain what's going on here: \"([^\\\"]|\\.)\" [seen here in context](https://github.com/matz/streem/blob/master/src/lex.l#L49).

Now it seems to be finding literal strings (so "strings" e.t.c.). That would explain the literal double quotes on either side. so without that we get: ([^\\\"]|\\.) so zero or more repeating versions of [^\\\"]|\\.

What I don't understand is why there is the explicit or \\. construct there, as this seems unnecessary. Am I missing something? also, why does it seem that strings cannot have either literal \ or literal " in them?

I like the idea of dataflow or stream processing ideas. I would love if you could make the connector pieces smarter so that you were enforcing a contract between the piping mechanisms. I believe you could build some very interesting systems with that approach.

Awesome I hacked something like this together a couple years ago using ruby and gnu parallel

https://github.com/charlesmartin14/gnu_parallel

it is badly needed

This is an excellent example of using a parser as a language. Whether it has any legs depends on whether it beats existing tools on some front (sed, perl, ruby, etc). The concurrent angle is interesting, but I have found a multi-process approach to stream data to be more efficient than most concurrent single-process implementations. For example, with DAP (https://github.com/rapid7/dap), we found that GNU Parallel + Ruby MRI was more effective than a concurrent language such as Go.

Tab (https://bitbucket.org/tkatchev/tab) is another interesting recent text processing language.

Take a look at dss from AT&T AST tools:

http://www2.research.att.com/~astopen/dss/dss.html

http://www2.research.att.com/~astopen/publications/dss-2004....

It's definitely a good idea. Pipes are both very powerful and very simple to use and debug, yet they are not very common in general purpose programming languages (examples?). I'm not surprised that someone is trying to build a language around them. I'll follow that, but for now it's a bit too early to judge.

Great idea, but I'm a bit disappointed in the syntax. Composed chains in Ruby are much nicer to look at.

For people interested, you can do something like this in Ruby right now that has nearly the same syntax:

http://pragdave.me/blog/2007/12/30/pipelines-using-fibers-in...

I hope it will support really big integers as in Haskell and better floating point number calculation, although I cannot foresee the power right now. Because it is concurrent, it may be very useful in scientific computing, whether in small or large scale.

    true{TRAIL}	return keyword_false;

-> in clojure or hy deals with that nicely:

(-> (read) (eval) (print) (loop))

using python-sh in hy this is possible:

(-> (cat "/usr/share/dict/words") (grep "-E" "^hy") (wc "-l"))

Matz, now get started on implementing transducers! https://www.youtube.com/watch?v=6mTbuzafcII

Stream processing languages typically derive from SQL (streamSQL) or prolog (Rapide) ... This one doesn't seem anywhere near as powerful but who knows.

Interesting that he chose a C-like syntax after going the complete opposite direction with Ruby.

Now it might be time to have a look into YACC, LEX and maybe BISON and follow Matz' repo :)

Looking to hire a Streem professional, must have at least 5 years experience with Streem.

I see this as a very good alternative to traditional shell scripting languages.

What kind of areas could Streem be used in?

Why is Stream spelled incorrectly?

Sorry, but if you know nothing about Ruby this is pure hype.

Not a fan of the closing braces.

undefined

undefined

"Then said Jesus unto him, Put up again thy sword into his place: for all they that take the sword shall perish with the sword" (Matthew 26:52, King James Version)

Sony played hard many times, e.g. closing Linux on Playstation 3 devices. I do not condone the attack, although I have no sympathy at all for such kind of companies.

Whatever, https://github.com/ekmett/machines https://github.com/scalaz/scalaz-stream