Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Streem – a new programming language from Matz

github.com

Post reply on HN
Print view View original

141–150 of 199 posts

Re: Streem – a new programming language from Matz

#141

Post by bglazer »

c3RlcGhlbnI_ wrote: post #42

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…

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/

Re: Streem – a new programming language from Matz

#143

Post by vram22 »

bglazer wrote: post #141
c3RlcGhlbnI_ wrote: post #42

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…

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/

Yes, pyp is interesting. So are some other roughly similar Python tools for doing pipe-like stuff. I had blogged about some of them here, a while ago, including pyp, osh, and pipe (not the Unix pipe system call, but a Python module):

Some ways of doing UNIX-style pipes in Python:

http://jugad2.blogspot.in/2011/09/some-ways-of-doing-unix-st...

And that later inspired me to create an experimental tool called pipe_controller:

Swapping pipe components at runtime with pipe_controller:

http://jugad2.blogspot.in/2012/10/swapping-pipe-components-a...

The above post links (recursively) to a few others, also by me, describing a couple of other ways of using pipe_controller, including this one:

Using PipeController to run a pipe incrementally:

http://jugad2.blogspot.in/2012/09/using-pipecontroller-to-ru...

and also includes the link for it on my Bitbucket account.

There's also plumbum, another such Python module.

Re: Streem – a new programming language from Matz

#145

Post by wycats »

Argorak wrote: post #86
danso wrote: post #78

Earlier quoted context omitted.

Does he really get a "lot of flak" for Ruby? While I know not everyone loves Ruby, it seems crazy to me that people would denigrate Matz on a personal level...to me (admittedly, a novice in designing languages), Ruby always seemed well-thought out...that is, the trade-offs do not seem out of line given the philosophical benefits, and not everyone can make claim to turning a personal project into a worldwide language.…

See the amount of people complaining about the missing spec for Ruby in this thread, which is his doing. At some point ~50% of the comments here were downvoted. I should clarify that I meant Ruby the implementation, not Ruby the language. Edit: I changed the word to "some", maybe that was a bit of a hyperbole. I see quite some unreflected bashing though.

Matz worked on a spec for the Ruby language, which is now an ISO standard: http://www.iso.org/iso/iso_catalogue/catalogue_tc/catalogue_...

Re: Streem – a new programming language from Matz

#146

Post by mackwic »

marvy wrote: post #128
mackwic wrote: post #112

Earlier quoted context omitted.

I think that stream-oriented languages are doomed to have an arcanic syntax. Streams are a non-trivial construction, after all.

I think I don't believe you. Look at the car and house example above. Is that arcane?

Well, sorry but sed _is_ cryptic. Let me quote an exemple for you (squeezing blank lines):

>leaves a blank line at the beginning and end if there are some already.

     #!/usr/bin/sed -f

     # on empty lines, join with next 
     # Note there is a star in the regexp 
     :x 
     /^\n*$/ { 
       N
       bx
     }
     
     # now, squeeze all '\n', this can be also done by:
     # s/^\(\n\)*/\1/
     s/\n*/\
     /
As soon as you begin to use sed registers, the code becomes arcanic.

Re: Streem – a new programming language from Matz

#147

Post by a3n »

PhearTheCeal wrote: post #37
[deleted] wrote: post #24

Earlier quoted context omitted.

[deleted]

noice, here's my version print("\n".join([("FIZZ"*(i%3==0)+"BUZZ"*(i%5==0)) or str(i) for i in range(1,101)]))

Similar:

  print '\n'.join(['FizzBuzz' if x % 15 == 0
      else 'Fizz' if x % 3 == 0
      else 'Buzz' if x % 5 == 0
      else str(x) for x in range(1, 101)])

Re: Streem – a new programming language from Matz

#148

Post by FnuGk »

vessenes wrote: post #3

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.

Another thing i dont understand is why people hardcode 15. I would rather write (3 * 5) and let the compiler figure out that 3 * 5=15. This way i think it more clearly states where the number 15 comes from. Any reason to write 15 over (3 * 5)?

Re: Streem – a new programming language from Matz

#150

Post by breuleux »

ssmoot wrote: post #126
breuleux wrote: post #122

Earlier quoted context omitted.

This is not a confusing context, though. This would be a confusing context: ary.map(f(_ * 2)) ==> ary.map(x => f(x * 2)) ? ==> ary.map(f(x => x * 2)) ? How does Scala interpret that one? I have no idea.

It doesn't. It's invalid code in most (all?) cases. scala> val f: Int => Int = _ - 1 f: Int => Int = scala> val ary = Array(1,2,3) ary: Array[Int] = Array(1, 2, 3) scala> ary.map(f(_ * 2)) :10: error: missing parameter type for expanded function ((x$1) => x$1.$times(2)) ary.map(f(_ * 2)) ^ You can't think of "_" like a placeholder. It's not. It's to lift an argument of a function. So simplify it: map in this context…

That's interesting, but you did not answer my question. I wanted to know how Scala determines where to insert =>. In my example, Scala interprets "ary.map(f(_ * 2))" as "ary.map(f(x => x * 2))" (both of these expressions yield the same error). If it interpreted it the other way, then the expression would work (using your definition of f). Perhaps a better example to use would have been:

    Array((_:Int) * 2)

    ==> (x:Int) => Array(x * 2) ? (correctly typed)
    ==> Array((x:Int) => x * 2) ? (also correctly typed)
As it turns out, Scala goes for the latter. After playing with the feature a bit I'd say the rules are engineered to fit particular use cases, but they can be a bit finicky if you venture outside of them. For instance, "1 + _ * 2" will work, but "(1 + _) * 2" won't. "f(_)(x)" does not mean the same thing as "(f(_))(x)".

I mean, I wouldn't say the feature is bad, but it definitely has a DWIM vibe to it that would make me classify it as a hack.

Post reply on HN