281–290 of 463 posts
Earlier quoted context omitted.
I agree the GIL is a problem but it's only an issue for CPU-bound problems. Is there really an important amount of CPU-bound work that is written in a scripting language? If it's CPU-bound, wouldn't you want to use something lower level?
It's not just CPU bound problems, handling multiple overlapping i/o operations is more trouble than it ought to be.
Earlier quoted context omitted.
I agree the GIL is a problem but it's only an issue for CPU-bound problems. Is there really an important amount of CPU-bound work that is written in a scripting language? If it's CPU-bound, wouldn't you want to use something lower level?
If it's entirely CPU bound, you can use multiprocessing to negate most of the GIL issues, and transparently send inputs/outputs between the parent and child processes. If it's I/O bound, then AsyncIO is a great way to express asynchronous workflows. If it's a combination of both I/O and CPU bound workloads, there are ways to mix multiprocessing and AsyncIO to better saturate your cores without losing the simplicity o…
Earlier quoted context omitted.
Is that like the relationship between C# and PowerShell?
I think so, at least in some ways. I've shipped a project using PowerShell to script Windows Server/Hyper-V, and it was a pretty pleasant experience. Having a scripting language that not only does typical scripting stuff (wrangling text, etc.) and understands your application's objects is excellent. Some differences: * You can actually write your whole application in Elixir, whereas I could not see doing that with Po…
Earlier quoted context omitted.
I think so, at least in some ways. I've shipped a project using PowerShell to script Windows Server/Hyper-V, and it was a pretty pleasant experience. Having a scripting language that not only does typical scripting stuff (wrangling text, etc.) and understands your application's objects is excellent. Some differences: * You can actually write your whole application in Elixir, whereas I could not see doing that with Po…
I heard so much about the actor model, I should really try it in its intended glory one day.
Earlier quoted context omitted.
I didn't know that Elixir had such a low-threshold for one-off programs. Have you tried Crystal? Both are on my list of programming languages to look into next, together with Elm, Reason and Zig.
Oh man I just love and adore Crystal. I am a long time rubyist and I have to say they just nailed it with Crystal. I just wish I had more opportunity to use it professionally!
Can someone explain to me, for what kinda of new projects would they use Perl/Raku in 2019 at all?
raku is a great language to work with for us. it is feature rich, has good abstractions, and developer friendly. if you like the syntax then give it a try.
This is great news both for Perl and for Raku. I will probably bother to take a serious look at Raku now, sometime, if anything just for curiosity. Why not before? I have no good answer for that. But my main worry about it is that I suspect it has brought along with it the community's dysfunctional fascination with over-the-top cleverness and arcane constructs. I'll probably stick with Python and Perl 5 on an as-need…
I was a Perl dev a long time ago, and I think it made me a stronger coder. I still miss it, and I've not coded Perl for real in a decade. You're correct about "over-the-top cleverness and arcane constructs" being a problem, but it's also about using code as communication. We code in _languages_, and on one extreme is coding newpaper style - lowest common linguistic denominator. On a good day this is a common, underst…
If Raku's "bad day" is basically like "one of the most influential and important authors of the 20th century" (according to Wikipedia)… well, then, maybe I should check Raku out!
I'm amazed that Perl is still around. I personally find it the least readable language that I've ever used, and that includes a lot of languages. But some people really seem to love it, for reasons a bit beyond me.
Earlier quoted context omitted.
The bolted on OO is really just one new function...bless(). The rest is package namespaces, which are also used for non OO purposes. I'm never sure what people don't like about OO Perl. There's a tiny bit of boilerplate in a constructor, other than that, it doesn't seem different from other OO script languages.
It's not terrible to get working, but for many people a major point of OO is encapsulation and it doesn't work out of the box like that. You have to install another package or use the inside-out object model to prevent direct access to package variables and 'private' functions are usually by naming convention only. It's just another example of Perl's biggest strength and weakness. Total freedom to build something ama…
There's no private data or private methods in Python objects. All the properties are right there for anyone to read, protected only by convention.
JavaScript and Perl have almost exactly the same OO model, yet many people quite like JavaScript's OO, so that can't be it, surely...
There's no private data or private methods in JavaScript objects. All the properties are right there for anyone to read, protected only by convention.
(It's closer than it looks. Perl's "bless" function means almost the same as JavaScript's ".__proto__ =", and inside-out data hiding is possible in JavaScript much the same as Perl, although hardly anyone uses it in either language.)