Rust and the Blub Paradox • Hacker News Board

Re: Rust and the Blub Paradox

#41

Post by pka » Sat, Jan 23, 2016, 7:41 PM UTC

lobster_johnson wrote: post #32

I think articles like these beg the question. It introduces a claim ("many/most people think some languages are too weird") and tries to refute it without first showing that the claim is true. Sure, I see lots of evidence of junior developers living in a happy bubble where they apply language X to everything, when they could expand their horizons a bit by looking into Y and Z. But this also ignores important factors…

I want to respond to one point specifically: `Private ecosystem — if all your code is in X, you have potentially tons of reusable modules as part of your own stack.`

Never ever in my OOP days have I been able to reuse a non-trivial function from a different codebase "just like that". This is because all my functions were impure - something encouraged by most mainstream languages. So I had to first rip out the context the function was living in and make it work again before being able to use it somewhere else. I wouldn't fix it in the original place though, so next time I'd want to reuse I'd have to repeat every step again.

Since I started using a pure language, reusing code actually became possible. I can rip out a function and place it in a new codebase without changing it a bit and it's gonna work just like that, no problem.

Getting back to the topic at hand, I would define the Blub paradox as "being unable to logically explain the benefits of something solving a problem you haven't realized is actually a problem yet". This may sound like trying to create problems out of nothing just so that they can be solved by "cool feature X", but I'd guess in most situations this isn't the case.

I truly believed that I was creating reusable OOP components until I realized that actually I wasn't. I truly believed a normal editor is more than sufficient for my needs until I learned vim. I truly believed svn was the best thing ever until I learned git. Etc...

Re: Rust and the Blub Paradox

#42

Post by steveklabnik » Sat, Jan 23, 2016, 7:42 PM UTC

pcwalton wrote: post #40

steveklabnik wrote: post #36

Earlier quoted context omitted.

I guess I'm just not sure why this is a problem, exactly. Even if you couldn't use those statements inside of a `do` block, that shouldn't be an issue? Just like using `break` outside of a loop is invalid, it would be the same here. The Option monad already is a sort of early return. Inside of monadic combinators, you use the monad for control flow instead of those statements. Seems fine to me, though admittedly my T…

do is only really good if you use it for the whole function, or at least have some way to get the error out of the do block to the code that's supposed to handle it. But if break isn't allowed inside a do block, then if you need to break you have to split up your do blocks into blocks before the break and after the break. Now if there's an error thrown by one of the statements in one of those do blocks, then you have…

The usual implementation of the Either/Option monads already does this though:

    instance Monad Maybe where  
        return x = Just x  
        Nothing >>= f = Nothing  
        Just x >>= f  = f x  
        fail _ = Nothing

and

  instance (Error e) => Monad (Either e) where  
      return x = Right x   
      Right x >>= f = f x  
      Left err >>= f = Left err  
      fail msg = Left (strMsg msg)

The end result is still a value of that type. You get the short-circuting behavior as soon as you hit Nothing/Left.

Re: Rust and the Blub Paradox

#43

Post by pklausler » Sat, Jan 23, 2016, 7:43 PM UTC

Some programmers can write BASIC in any language. But on the up side, some programmers can write Haskell in any language.

Re: Rust and the Blub Paradox

#44

Post by lobster_johnson » Sat, Jan 23, 2016, 7:48 PM UTC

microtonal wrote: post #35

lobster_johnson wrote: post #32

I think articles like these beg the question. It introduces a claim ("many/most people think some languages are too weird") and tries to refute it without first showing that the claim is true. Sure, I see lots of evidence of junior developers living in a happy bubble where they apply language X to everything, when they could expand their horizons a bit by looking into Y and Z. But this also ignores important factors…

The Blub idea also ignores the fact people can accomplish great things with poor tools. Choosing a minimal tool does not necessarily say anything about you as a developer. In fact, I think the original essay makes quite some unwarranted assumptions: But if you work for a startup that doesn't have pointy-haired bosses yet, you can, like we did, turn the Blub paradox to your advantage: you can use technology that your…

Absolutely.

Someone once claimed — I forget who and where — that Go was designed at Google precisely so that even average developers could contribute meaningfully and safely within Google's stack.

Of Google's top languages (as far as I know), Java and C++ are complex, and Python has its own idiosynchracies, notable the lack of static typing which leads to a class of potential errors (especially as relates to backwards compatibility between modules) that must be mitigated with super-extensive unit test coverage.

Go, on the other hand, is a very small and simple (easy to ramp up), very strict (hard to screw up) language with an extensive library (max productivity).

Re: Rust and the Blub Paradox

#45

Post by GFK_of_xmaspast » Sat, Jan 23, 2016, 7:50 PM UTC

bluejekyll wrote: post #17

chao- wrote: post #12

I haven't written C++ with any significance in a few years, and done little with Rust at all. So while I don't feel qualified to speak to the comparison at the core of the blog post, I did find the first example to be disingenuous. It rests entirely on assuming the C++ programmer will rely on inheritance to achieve polymorphism, simply because they can? Additionally, the C++ example doesn't produce the same output ("…

Don't forget about how awesome C++'s multiple inheritance is! edit: It's worth the down votes on this. Multiple inheritance is pure evil and confusion. In fact, even in Java I now rely on aggregation over inheritance. http://stackoverflow.com/questions/269496/inheritance-vs-agg...

c++ is a great language but a lot of the inheritance system is regrettable at best.

Re: Rust and the Blub Paradox

#46

Post by lobster_johnson » Sat, Jan 23, 2016, 7:51 PM UTC

pka wrote: post #41

lobster_johnson wrote: post #32

I think articles like these beg the question. It introduces a claim ("many/most people think some languages are too weird") and tries to refute it without first showing that the claim is true. Sure, I see lots of evidence of junior developers living in a happy bubble where they apply language X to everything, when they could expand their horizons a bit by looking into Y and Z. But this also ignores important factors…

I want to respond to one point specifically: `Private ecosystem — if all your code is in X, you have potentially tons of reusable modules as part of your own stack.` Never ever in my OOP days have I been able to reuse a non-trivial function from a different codebase "just like that". This is because all my functions were impure - something encouraged by most mainstream languages. So I had to first rip out the context…

I didn't mean copy-paste reusability, I meant packaging code into reusable modules (e.g., NPM packages, Ruby gems).

This has nothing to do with OO, really. But I don't disagree with your point about immutability.

Re: Rust and the Blub Paradox

#47

Post by pka » Sat, Jan 23, 2016, 7:51 PM UTC

pcwalton wrote: post #40

steveklabnik wrote: post #36

Earlier quoted context omitted.

I guess I'm just not sure why this is a problem, exactly. Even if you couldn't use those statements inside of a `do` block, that shouldn't be an issue? Just like using `break` outside of a loop is invalid, it would be the same here. The Option monad already is a sort of early return. Inside of monadic combinators, you use the monad for control flow instead of those statements. Seems fine to me, though admittedly my T…

do is only really good if you use it for the whole function, or at least have some way to get the error out of the do block to the code that's supposed to handle it. But if break isn't allowed inside a do block, then if you need to break you have to split up your do blocks into blocks before the break and after the break. Now if there's an error thrown by one of the statements in one of those do blocks, then you have…

Can't break be simulated by something like MaybeT? And forWithBreakM :: [a] -> (a -> m (Maybe b)) -> m [b] that stops when f yields Nothing? (isn't this actually sequence . forM?)

Re: Rust and the Blub Paradox

#48

Post by GFK_of_xmaspast » Sat, Jan 23, 2016, 7:52 PM UTC

jbandela1 wrote: post #3

Wow, this is the first post I have ever read that even kind of implied that Andrei Alexandrescu was a Blub programmer. Part of being a Blub programmer is that you don't even think about the issues. In regards to the weird features brought up, the underlying issues behind these features have been in the C++ consciousness for some time. Below are some talks and resources covering at least some of these issues. Sean Par…

It's always easier to see the blub in someone else's language and not in our own.

Re: Rust and the Blub Paradox

#49

Post by pcwalton » Sat, Jan 23, 2016, 7:53 PM UTC

steveklabnik wrote: post #42

pcwalton wrote: post #40

Earlier quoted context omitted.

do is only really good if you use it for the whole function, or at least have some way to get the error out of the do block to the code that's supposed to handle it. But if break isn't allowed inside a do block, then if you need to break you have to split up your do blocks into blocks before the break and after the break. Now if there's an error thrown by one of the statements in one of those do blocks, then you have…

The usual implementation of the Either/Option monads already does this though: instance Monad Maybe where return x = Just x Nothing >>= f = Nothing Just x >>= f = f x fail _ = Nothing and instance (Error e) => Monad (Either e) where return x = Right x Right x >>= f = f x Left err >>= f = Left err fail msg = Left (strMsg msg) The end result is still a value of that type. You get the short-circuting behavior as soon as…

It only short-circuits to the end of the do block. But once you leave the do block the error isn't propagated anymore.

Re: Rust and the Blub Paradox

#50

Post by kitd » Sat, Jan 23, 2016, 7:59 PM UTC

shams93 wrote: post #33

I'm slowly learning rust. Ive worked with c and jni in android for sound apps but now Im ignoring my reactions over the weird parts of rust so i can use it to builda killer music application for raspberry pi

If it helps, I've called Rust over JNI. Fairly easy in fact though I recommend judicious examination of examples on the web first.

Cargo is also very helpful in this regard.