Live data from Hacker News

Why I’m Learning Perl 6

evanmiller.org

301–310 of 380 posts

Re: Why I’m Learning Perl 6

#301
post #135

Earlier quoted context omitted.

> Every major language, or at least the ones that matter for backend development, has support for thread multiplexing / coroutines / fibers, whatever. M:N threading is not, from a developer perspective, the same thing as coroutines/fibers. Coroutines are lower-level; it's possible to build something like M:N threading on top of coroutines, but it means doing a lot of work that's already done for you in a language tha…

That's kind of the problem when the author uses meaningless words like "WEB SCALE", we don't really know what it means exactly. If it's about serving a great number of concurrent connections, I'm not sure why M:N is the only way to go.

Most languages give you one of two easy options. The first is to use green threads, which makes 100,000 new threads cheap, but now a single slow function call anywhere can block other threads. The second is to use OS threads, which keeps a slow function call in one thread from interrupting your responsiveness, but now makes 100,000 new threads expensive.

What M:N threading does, at least in theory, is allows you to create 100,000 threads cheaply AND keep a slow function call in one thread from blocking others. In a language with those features you can build it out of continuations (NOT coroutines) and real threads. But that requires building your own scheduler that can move a user thread to a different process at need. Which is non-trivial, and is unlikely to cooperate well with any third party libraries.

That said, whether M:N threading is a real optimization depends on a ton of things. A big one is the underlying performance of the scheduler and the language. Which is improving for Perl 6..but has a long way to go.

Whether optimizing at this level matters is another good question. Most companies shouldn't care. Those that should, should be cautious about deploying Perl 6 into a mature infrastructure.

So that's why people can think that M:N is important, and why you might legitimately disagree.

Re: Why I’m Learning Perl 6

#302

Earlier quoted context omitted.

Blame Aho, Weinberger, and Kernighan. Oh and Larry :)

Why are the awk guys to blame for Perl syntax?

> (It's sorta like sed, but not. It's sorta like awk, but not. etc.)

Guilty as charged. Perl is happily ugly, and happily derivative.

    Usenet article  (1992) -- Larry Wall

Re: Why I’m Learning Perl 6

#303

Earlier quoted context omitted.

There is native support for threads, it's just that they don't run concurrently.

At this point the word is so far removed from the meaning in this thread you might as well say a haberdasher supports threads.

There are valid reasons for programming with threads with only a single CPU (indeed when I learnedb thread programming in the 90s pretty much only single core cpus were available). For instance, IO blocking.

Re: Why I’m Learning Perl 6

#304

Earlier quoted context omitted.

HN doesn't support full Markdown. :(

I think you're thinking of CommonMark. That link format isn't valid in canonical Markdown either (just to some of the common variants that also went by "Markdown"). I was always partial to the variants that could do citations well. They would automatically link-ify items postfixed by [1] etc with the link included at the citation at the bottom. I implemented a customer facig newsletter system at one job using that, w…

I thought CommonMark was the attempt to standardize Markdown. Besides that, every markdown implementation I've touched since before CommonMark supported [text](url) format.

Re: Why I’m Learning Perl 6

#305
post #99

Earlier quoted context omitted.

This is incorrect. Coroutines and fibers are not m:n threads. There are important implementation and usability distinctions. Besides, there are a lot of additional usability issues with bolted-on concurrency vs language-level concurrency.

Ah yes, let's use Perl 6 to avoid usability issues.

I wasn't advocating for Perl; I've never used it.

Re: Why I’m Learning Perl 6

#306

Thing that really gets me about perl is the syntax, it's horrendous. No other reason, that's all. Just the syntax.

Blame Aho, Weinberger, and Kernighan. Oh and Larry :)

The good thing about awk is that it's limited. So you know when to stop using it and move to use a different language when your requirements exceed the comfort zone of awk.

Larry Wall came and made a language inspired by awk that doesn't give feedback on when you're out of the comfort zone. This lets you make a mess before you know what you've done (aka technical debt). The same problem 'that killed Smalltalk and could have killed ruby' too (thanks, Bob Martin).

Re: Why I’m Learning Perl 6

#307
post #35
post #15

why is everybody saying they are put off by Go? Did we pass the "trend" phase and now it's cool to say go sucks?

Go was no-go for me from the get-go (hmm I should probably get better phrases but F it). Its design goals just don't align with my preferences at all.

The design go-als, you mean.

Re: Why I’m Learning Perl 6

#308
post #290

Earlier quoted context omitted.

perl6 grammars have to be seen in context of perl5 regexp. Basically, regular expressions have grown to impossible to understand, write and modify. Mostly due to perl. Yet, they are used daily by millions of developers, because they are a ton better than manual character checks. Perl6 grammars are basically an attempt to bring developers another step forward.

Are you saying that Perl6 grammars are a replacement (maybe eventually) for Perl5 regexps?

partly, you still build Grammars out of "token", "regex" and "rule" definitions, but some things are more natural with one or the other.

So, if you are doing "test if string has whitespace" you'd use a regex, while for "parse an apache log line" you'd probably use a grammar instead of a very nasty regex.

IANA perl6 dev though, just a casual observer.

Re: Why I’m Learning Perl 6

#309
post #299

Earlier quoted context omitted.

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".

Perpetual intermediates exist in every field, many of them with far more nuance than any mere programming language has to offer. The way to extract productivity from these people is the same in software development as it is in any endeavor: leadership.

Good leaders identify and propagate conventions that can keep their teams functioning in a complex millieu.

You can't get rid of the irreducible complexity of any system. You can only move it around.

In my experience, if you use an expressive language well, you can fit the code to the problem domain in a way that better communicates the underlying approach you have taken to solving the problem.

Relying on strict, small languages, like Java, means that you gain a consistency of syntax by sacrificing flexibility.

I've seen monstrous turds written in many languages, the problem in all these cases was poor or absent leadership.

Re: Why I’m Learning Perl 6

#310

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…

Also, errors are mostly pretty good and getting better. I think a big and overlooked part of learning a new language is the quality of the errors the language provides. Some do this better than others, and some get it right in the core language but by the time you've stacked up enough libraries and extensions to get things done nicely, the errors aren't so good anymore because they talk about things at a lower level than you're thinking of them (Perl 5 can fall prey to this latter problem, even though the core language has pretty good errors these days).
Post reply on HN