Streem – a new programming language from Matz • Hacker News Board

Re: Streem – a new programming language from Matz

#171

Post by breuleux » Fri, Dec 12, 2014, 2:32 AM UTC

ssmoot wrote: post #161

breuleux wrote: post #150

Earlier quoted context omitted.

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)…

> In my example, Scala interprets "ary.map(f(_ * 2))" as "ary.map(f(x => x * 2))" I think this is where I'm not communicating what I'm trying to say very well. What I'm trying to say is that that statement is false. The underscore isn't a placeholder saying "inject a Function here". You probably didn't mean that exactly of course, but it's a programming language; it pays to be a bit pedantic I think. It's easier to u…

> The underscore isn't a placeholder saying "inject a Function here".

It is. Look at the error message:

    error: missing parameter type for expanded function ((x$1) => x$1.$times(2))

It did inject a function, it's right there, in plain text. Then it did type inference. I mean, what else is "lifting" the asterisk to a Function supposed to mean, if not injecting a function around a placeholder? And what about "1 + _ * 2"? What is it lifting? The asterisk? No. It is lifting more than that.

> You had a Function[Int,Int] before, but now that you've passed that function value to Array.apply instead of getting an Array[Function[Int,Int]] as you would in every single other case, you get a Function[Int,Array[Int]]?

That's besides the point. The question is, when the parser sees "_", how much of the context does it grab along with it? In other words, I know it's lifting stuff, what I want to know is how much it lifts. Here's another example:

    f(_, 2)(3)

    ==> x => (f(x, 2)(3)) ?
    ==> (x => f(x, 2))(3) ?

Scala does the former. That's a legitimate choice given common use cases, but the latter is simpler, preserves the invariant that "a(b) (a)(b)" and has use cases as well, e.g. to make an expression like "f(super_long_expression, 2)" more readable.

> But not so much as you think. It's just the "lift". Type-inferencing lets you get away with what looks like a little more sometimes.

I still don't see what type inference has to do with this. The error message makes it clear that the lift is done before type inference kicks in. In a dynamic language, you would stop at the lift, but it would otherwise work just the same.

Re: Streem – a new programming language from Matz

#172

Post by programminggeek » Fri, Dec 12, 2014, 2:45 AM UTC

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.

Re: Streem – a new programming language from Matz

#173

Post by emmanueloga_ » Fri, Dec 12, 2014, 3:34 AM UTC

lgleason wrote: post #158

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 real…

> "Matz is nice and therefore we are nice"

This non sequitur annoys me. Deconstructing it:

* A: "Matz is nice": Let's say we all agree this is true.

* B: "we are nice": i.e., the ruby community is nice.

* P(A -> B): (A therefore B) is a slogan, so I assume the proposition P is believed to be true. Is it?

In order for P to be true, the only option is for B to be true as long as Matz keeps being nice. Assuming Matz is still good-natured, is not hard to find counterexamples for B (every big community have some less-than-nice people). So the facts tell us that P is false.

Alternatively, if you assume that Matz is not nice, then, without mattering if "we" are nice or not, the slogan holds true (modus ponens [1]).

Anyway, my point is that the slogan is as silly as this rant :p.

1: http://en.wikipedia.org/wiki/Modus_ponens#Justification_via_...

Re: Streem – a new programming language from Matz

#174

Post by ghuntley » Fri, Dec 12, 2014, 3:40 AM UTC

qubitcoder wrote: post #135

icedog wrote: post #84

Earlier quoted context omitted.

I disagree that it maps most directly to the problem statement. You're performing a common factor computation in your mind, which may be more difficult given numbers other than 3 and 5. In my opinion, pattern matching offers the most direct solution and comes with an abundance of compiler optimizations. Here's an example in Rust... for i in range(1i, 101) { match (i % 3, i % 5) { (0, 0) => println!("Fizzbuzz"), (0, _…

The solution in Haskell is quite clean, I believe. fizzBuzz n | n `mod` 15 == 0 = "FizzBuzz" | n `mod` 3 == 0 = "Fizz" | n `mod` 5 == 0 = "Buzz" | otherwise = show n main = mapM_ (print . fizzBuzz) [1..100] I agree with you about generalizing pattern matching for less simple cases. Your example brought to mind view patterns, about which Oliver O'Charles had a nice writeup recently [1]. Nifty little extension. [1] htt…

Using F# pattern matching:

    let buzzer number =
       match number with
       | i when i % 3 = 0 && i % 5 = 0 -> "FizzBuzz"
       | i when i % 3 = 0 -> "Fizz"
       | i when i % 5 = 0 -> "Buzz"
       | i -> (sprintf "%i" i)

    for i = 1 to 100 do
        printfn "%s" (buzzer i)

Re: Streem – a new programming language from Matz

#175

Post by esMazer » Fri, Dec 12, 2014, 4:14 AM UTC

kaeluka wrote: post #91

chc wrote: post #71

Earlier quoted context omitted.

If they don't know who Matz is, are they likely to know who Yukihiro Matsumoto is? EDIT: Interesting fact: I believe this is now my most downvoted comment in five years on HN, at effectively -7. Never would have guessed. I'm not exactly sure what it says, but I thought it was an interesting data point.

I, for one, remember the full name but not "Matz"

same here

Re: Streem – a new programming language from Matz

#176

Post by msie » Fri, Dec 12, 2014, 4:29 AM UTC

rudolf0 wrote: post #93

spoiler wrote: post #88

Earlier quoted context omitted.

I prefer {|el| el + 5} more than { _ + 5 } the latter is too implicit for my taste, also I imagine it could become more confusing in a more complex context.

Personally I like it and find it clear. Compare: ary.map(_ * 2) ary.map(x => x * 2) "_" is perhaps an ugly choice of character (frankly I'm not sure why Scala is so obsessed with it, since it's used for so many featurse), but I think the semantics are sensible. Of course, in a more functional language you could perhaps just write ary.map(* 2)

For only several characters more the second form is much clearer to many more programmers. I think it's worth it.

Re: Streem – a new programming language from Matz

#177

Post by balakk » Fri, Dec 12, 2014, 5:10 AM UTC

mackwic wrote: post #146

marvy wrote: post #128

Earlier quoted context omitted.

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.

> arcanic

Arcane. Some would call it archaic too :)

Re: Streem – a new programming language from Matz

#178

Post by desdiv » Fri, Dec 12, 2014, 5:11 AM UTC

rudolf0 wrote: post #93

spoiler wrote: post #88

Earlier quoted context omitted.

I prefer {|el| el + 5} more than { _ + 5 } the latter is too implicit for my taste, also I imagine it could become more confusing in a more complex context.

Personally I like it and find it clear. Compare: ary.map(_ * 2) ary.map(x => x * 2) "_" is perhaps an ugly choice of character (frankly I'm not sure why Scala is so obsessed with it, since it's used for so many featurse), but I think the semantics are sensible. Of course, in a more functional language you could perhaps just write ary.map(* 2)