Matz, now get started on implementing transducers! https://www.youtube.com/watch?v=6mTbuzafcII
Streem – a new programming language from Matz
151–160 of 199 posts
Re: Streem – a new programming language from Matz
#152I 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.
Re: Streem – a new programming language from Matz
#153I 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…
I'd like to recommend a python command line utility called pyp. It allows you to do python string manipulation on text streams using the standard pipe operator. https://code.google.com/p/pyp/
This inspired me to build a similar tool which runs javascript instead.
Re: Streem – a new programming language from Matz
#154I 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…
Take a look at TXR: http://www.nongnu.org/txr/
The link was posted on HN some time ago and was generally well received. I didn't have the time to use it much yet, but it looks very nice. Well, unless you hate lisp.
Re: Streem – a new programming language from Matz
#155Earlier quoted context omitted.
That manual is possibly the single most useful technical document that I have ever read. It has enabled me to write extremely powerful programs that no one I know can understand. It would however be nice to have a tool with similar power but simpler, more comprehensible syntax. One of the other commenters linked to an interesting document on sam, which has a better control flow but equally arcane syntax.
I think I could argue that Perl is that tool. I'm not looking forward to people chiming in about the syntax that have little to no experience with it though.
I fell in love with Perl 3 over twenty years ago and loved how it took the best parts of both awk and sed and added extra features while making the overall syntax more consistent. Ironically, the consistency of Perl's syntax in those days (vs having to remember awk, sed, and other somewhat overlapping tools, each with its own awkward syntax) made it an amazingly convenient super-tool for stream processing. Perl 4 came along almost immediately, and I couldn't believe how powerful those little "Perl one-liners" could be.
With Perl 5, Perl essentially repositioned itself as a full-blown, general-purpose programming language, with all the power that entailed, but still stuck with a syntax based on essentially trying to be a more powerful and consistent superset of sed and awk.
These days, I think we could do a lot better with a stream processor with the stream-processing focus and one-liner power of Perl 4 but without the needless (these days) constraint of retaining the syntactic hash of ancient unix utilities.
Re: Streem – a new programming language from Matz
#156This 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.
Re: Streem – a new programming language from Matz
#157For 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...
Re: Streem – a new programming language from Matz
#158I 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!
Re: Streem – a new programming language from Matz
#159I 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 real…
> I know that there have been some conversations among the core on bringing in more functional concepts to Ruby....at least since April.
Only since April? Has there been a non-bugfix release of Ruby that didn't bring in more functional concepts to Ruby since, well, ever? AFAICT, bringing more support for ideas that come from the FP world has been one of the perennial drivers of progress in Ruby, not a new issue that emerged this spring.
> To me this says that Matz is coming to the conclusion that we may need a new language to get functional right.
I think that's reading a lot into it. Matz experimenting with something doesn't mean that the intent is to replace Ruby with it.