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

Why I’m Learning Perl 6

evanmiller.org

Post reply on HN
Print view View original

291–300 of 380 posts

Re: Why I’m Learning Perl 6

#291

Post by Diederich »

dmytrish wrote: post #197
kbp wrote: post #196

Earlier quoted context omitted.

You aren't really showing off different ways to get arguments in any of those examples. In all of them, you get the arguments in a list called @_; you're just showing off three different ways to get values out of a list, which Python has plenty of ways to do as well. Translating your examples into Python: def add1(*_): _ = list(_) arg1, arg2 = _ return arg1 + arg2 def add2(*_): _ = list(_) arg1 = _.pop(0) arg2 = _.po…

That does not change the fact that in Python everybody writes def add(x, y): return x + y whereas the Perl codebase that I work with has every possible combination of these methods.

I don't mean to detract from your point, but I have a related question:

How much actual cognitive overhead is there associated with three of four different ways of unpacking args?

Speaking for myself (as a long-time Perl/Python/GoLang/etc programmer), when I jump into a language I don't know, it doesn't take me long to get 'muscle memory' for how such things work.

Re: Why I’m Learning Perl 6

#292

Post by dmix »

anonacct37 wrote: post #256
RX14 wrote: post #92

Earlier quoted context omitted.

Unfortunately, unless the IO in the stdlib uses or is modified to schedule these fibers around evented IO, they're essentially useless as soon as you use an external library. Go and Erlang do this, Crystal does this but with only N:1 multiplexing (but that will change before 1.0), but I don't know about other languages.

Very true. Node does this too, in the sense that all node libraries are async/callback aware or have async/callback versions of those. I much prefer the go/erlang version of this. Playing the "what color is your function" game or "will it block" is no fun.

> Playing the "what color is your function" game or "will it block" is no fun.

This was quite painful with.js Node 1-2yrs back when Promises and coroutines started picking up steam [such as https://github.com/tj/co]. It was always a shot in the dark.

Has this situation changed now? (basically is the stdlib all async friendly now?)

Re: Why I’m Learning Perl 6

#294

Post by xutopia »

sherr wrote: post #49
rlpb wrote: post #39

Earlier quoted context omitted.

...and then deployment basically becomes scp. And security updates for your deployment become...what?

Rebuild and scp the whole lot again? Not necessarily a big deal.

Or doing patches. Copy the file locally... apply the patch... restart process.

Re: Why I’m Learning Perl 6

#295

Post by dullgiulio »

Rafert wrote: post #222
StevePerkins wrote: post #22

> Concurrency is hard and if you want M:N thread multiplexing (i.e. WEB SCALE CODE, where application threads aren’t pinned to pthreads) your options today are precisely Erlang, Go, .NET, and Perl 6. Putting aside the "web scale" jokes ( http://www.mongodb-is-web-scale.com/ ), this statement is still absurd. Every major language, or at least the ones that matter for backend development, has support for thread multipl…

> Ruby has [...] likewise community gems with more robust functionality like Quasar. https://github.com/ruby-concurrency/concurrent-ruby for those wondering. Rails uses it as of version 5.

Concurency doesn't mean multithreading. The "yield" keyword in Python enables a for of concurrency and Python is infamous for not being multi-threaded (when interpreting Python.)

Re: Why I’m Learning Perl 6

#296

Post by darkr »

ashayh wrote: post #231
StevePerkins wrote: post #22

> Concurrency is hard and if you want M:N thread multiplexing (i.e. WEB SCALE CODE, where application threads aren’t pinned to pthreads) your options today are precisely Erlang, Go, .NET, and Perl 6. Putting aside the "web scale" jokes ( http://www.mongodb-is-web-scale.com/ ), this statement is still absurd. Every major language, or at least the ones that matter for backend development, has support for thread multipl…

Ruby also has JRuby, which has true parallelism & concurrency and does not suffer from the global interpreter lock like vanilla ruby/python.

Unfortunately most ruby gems are written with no concept of thread safety. I say this from the perspective of a long time ruby fan, terrified when I hear of critical systems that are running on jruby

Re: Why I’m Learning Perl 6

#297

Post by [deleted] »

ashayh wrote: post #231
StevePerkins wrote: post #22

> Concurrency is hard and if you want M:N thread multiplexing (i.e. WEB SCALE CODE, where application threads aren’t pinned to pthreads) your options today are precisely Erlang, Go, .NET, and Perl 6. Putting aside the "web scale" jokes ( http://www.mongodb-is-web-scale.com/ ), this statement is still absurd. Every major language, or at least the ones that matter for backend development, has support for thread multipl…

Ruby also has JRuby, which has true parallelism & concurrency and does not suffer from the global interpreter lock like vanilla ruby/python.

[deleted]

Re: Why I’m Learning Perl 6

#298

Post by Tarean »

krylon wrote: post #202
hardwaresofton wrote: post #195

Earlier quoted context omitted.

What do you mean by the "side-effect-laden" part? Did you find yourself writing lots of side effecting code because of Haskell (which seems weird)? Or Haskell just wasn't a good fit for a project that was full of side-effecting code? If it's the latter, I can definitely tell you that part of the zen of Haskell is firming up the boundaries between side-effecting code and pure code -- for example, IMHO the better you g…

Writing a purely functional function like, say, factorial, or the Ackermann function, was no problem at all. Writing a "purely" side effect-based one, say, read a string from stdin, parse an age, and say, "What, you are %d years old?!?! Wow, you're old!" completely eluded me. Maybe it was just that all the tutorials I encountered sucked. Maybe I am just too dumb for Haskell. Given that I currently really love Go, I k…

I felt the same for a long time. At first glance something like

    import Text.Printf

    main :: IO ()
    main = do
        age  String
    formatAge age = printf "What, you are %d years old?!?!?! Wow, you are old" age
might look nice and imperative. But then you realize it is just syntactic sugar for `main = readLn >>= printf ...`, which is incredibly confusing when coming from another language. And then you learn that libraries can just invent their own meanings for `>>=` as long as the type signatures match and all bets are off. The upshot of this is that the code like the one above is easy to test and could be async or parallelized without issue. The downside is that people usually fail several times before finally getting it.

The haskell book[1] is apparently really helpful with this but it also costs 60$ and is over a thousand pages so it's a pretty large investment in both time and money.

[1]: http://haskellbook.com/

Re: Why I’m Learning Perl 6

#299

Post by oblio »

daotoad wrote: post #241
Verdex_2 wrote: post #91

For some reason, when I started my software engineering career I got it into my head that I needed to learn as much as I could about programming languages. I learned ruby, perl5, python, lisp, forth, ml, ocaml, scheme, haskell, r, c#, java, lua, c++, factor, idris, asm, erlang, prolog, rust, d. But that wasn't quite enough because haskell and idris kept on talking about complicated type theory stuff. So I also learne…

Perl 6 is designed to be a large, feature rich language that can be learned and used incrementally. The intent is that, like users of natural languages, Perl 6 practitioners gain fluency and nuance in their expression over time. So, if you want to learn Perl6, don't worry about writing "baby talk" Perl 6. Write something that works and solves your problem. Later on you may learn that there are multiple other ways to…

While I encourage OP to dive in and don't want to dismiss your points, in my experience life is more about perpetual intermediates: https://blog.codinghorror.com/defending-perpetual-intermedia...

As a result, a language like Perl is very nice and maybe even artistic but in many situations downright "dangerous".

Re: Why I’m Learning Perl 6

#300

Post by ensiferum »

anonacct37 wrote: post #259
supremesaboteur wrote: post #47

Earlier quoted context omitted.

For Python there is no native support for threads because of GIL. You can get around this through multiprocessing etc but these are hacks

You might have chosen bad words, but people reading this should know this statement it false. Python has threads. You can create them and (if you're using linux) see them in the /proc filesystem. A more accurate statement is: "python bytecode can't execute concurrently w/o something like multiprocessing". The key difference? You can do multithreaded I/O all day long, which is a pretty important use case of threading.…

In fact it is quite common. If you look into the c modules you see a pattern where they release the gil before performing some operation and then reacquire it
Post reply on HN