That's an interesting article but seems to be missing the actual why of it. He still likes perl because... culture? Some people are still writing software in perl or cobol, sure - and some of that is good software that solves real problems. But the reason we think of the average programmer in one of these obsolete languages as "some sort of second-class technology citizen" is that, well, they are. Compared to the rest of us they spend more time working around language deficiencies, inadequate tooling and all the rest of it, and less time making interesting things.
Right now I'm a huge Scala fan. I've had that experience of feeling that I never want to program in any other language again (and every other language I've gone to, even those I used to like, feels clumsy and tedious by comparison). But I hope that in 25 years' time I'll have moved on to something even better. Language design isn't done, and languages are getting better all the time.
Interesting. What does Python make harder? In Perl I find myself missing list comprehensions, shared-by-default threading, a well-integrated object system, and a comprehensive, integrated, popular web framework. (Also a standard way of doing event-driven programming, but that's a fair criticism of Python too). And while I'm sure the tooling functionality is there, everything just seems less obvious and standard (e.g. where's the virtualenv equivalent?)
In Python I miss a switch statement, anonymous functions longer than a single line, and an object system with the power of Moose. I don't think shared-by-default threading is a good idea, and Python's GIL makes it close to pointless.
I also miss a web framework like Django or Rails in Perl. I never liked Catalyst, but have not spent much time with it.
I cannot judge if the tooling is less obvious, but think the tools are better, especially in regard to testing. There is a virtualenv equivalent called local::lib, but I recommend the bundler equivalent called carton ;-)
If you like Django/Rails I'd suggest you check out Perl's Mojolicious - very modern Perl web framework. There's also Dancer - both seem much easier to use & set up than Catalyst
Indeed. Perl does have Jifty and Gantry which do have out of the box support for the M part of MVC, but for whatever reasons they never became as popular as Django/Rails.
With perl I always include the M inside my application class/module.
And I use only VC from the web framework.
That way, i get thin controllers only for url mapping which in that case will access my application class/module instance.
Thats where the real code will be, in my application and not-in-the-web-framework.
With this environment its easy to switch and test other web frameworks avaliable because i will only need to create the thin controllers and re-use my templates. Plus, when i need a cronjob, i use my application without the VC.
In the end the real deal is: dont tie your application with webframeworks. Always use the M inside the application and from the web framework use VC only with thin controllers.
Put the real code inside the aplication. Make the framework use the application. Dont make the framework your application.
You haven't found any of the major Perl web frameworks? You haven't seen Moose for OO? perlbrew? (Don't get me started on list comprehension, extra stuff to learn because Python lack real maps with real lambdas.) And so on...
Do you always have opinions on stuff you have no clue about?!
Start with getting the Modern Perl book and read it (free pdf). Ask (/search) on Perlmonks.
> You really prefer Python threading to anything?!
Sure. When I just want "run this task in the background, I don't particularly care about throughput but don't block entirely". There's a niche where a proper task queue is too heavy and shared variables are a perfectly adequate communication mechanism.
> Don't get me started on list comprehension, extra stuff to learn because Python lack real maps with real lambdas.
They're a nicer abstraction for many purposes. Look at their Haskell origin, or Scala for/yield.
For stuff so trivial that even the GIL is no problem, most any utility should work... (You don't seem to know that Perls are usually not compiled with threading support?) It just isn't interesting to talk about.
I argued that list comprehension's use cases are generally solved better with "real" lambdas + map (==> less to learn). To note that most every feature have some use case they are extra good for is not relevant.
But again -- why do you discuss subjects you obviously don't know? Ask instead.
You don't seem to know that Perls are usually not compiled with threading support?
I've heard this a few times now, and find it interesting. I guess people that compile their own do it without threading support, but I would guess the majority of Perl interpreters out there were bundled from some third party (usually the distro), and those almost always have threading enabled.
Also, that's a good thing. I've made quite heavy use of threads over the years and find Perl's abstraction of OS threads is actually quite nice to use, as long as you play to their strengths. I.e. pre-create your threads, and thread them like pthreads with easier IPC. If you want "green" threads, use any of the numerous packages that provide it.
> You really prefer Python threading to anything?!
The Python 'process' and 'queue' modules rock (yes, multiple single threaded processes still counts as multithreading). I've had apps on the front page of HN / Smashing Mag using them, happily taking advantage of a multicore server.
I swear half the people who bitch about the GIL have never used either of these modules (not you, people in general).
Using multiple single-threaded processes still counts as parallelism, sure, but please don't set a precedent for using the term "multithreading" to mean something other than "using multiple threads". Nobody who works professionally on these sorts of problems would understand "multithreading" in the way that you're using it. (The term is overloaded enough as it is, given that it glosses over the distinction between user-space and OS threads...)
I understand your point, but there are people who'd argue non-OS 'threads' aren't actually threads either - if ps -eLF doesn't show more than 1 LWPs for your PID you're not considered multithreaded.
I answered a comment re threading, not different multi process implementations.
(All the popular scripting languages have bad threading support and try to do everything with multiple processes, afaik. It should be possible to add good support, but I guess it isn't really worth it?)
As long as multi-processes can't share variables, nevermind complex data structures made of variables, they don't apply to the problem multi-threading solves.
shrug The queue module takes complex data structures, provides them to processes, which when finished doing whatever they do, send them back to other queues and in turn more processes.
It works, complex data structures are being shared. There's no nightmarish locking issues. Not sure what else you want.
Are you entirely sure you're not discounting the solution because It's Not What Java Does?
I'm sorry if that wasn't clear, sharing doesn't only mean "making the data available" but also means high performance and direct access. Quite simply though: If you can't imagine different use profiles that make certain multi-processing paradigms better suited than others, then you shouldn't be having this discussion and should be getting more experience outside of what you're doing right now.
I'm just pointing what's solved the problem for me, and how it can be useful for others. I'm aware there's a performance overhead.
> If you can't imagine different use profiles that make certain multi-processing paradigms better suited than others, then you shouldn't be having this discussion and should be getting more experience
Conversely, there's also a huge gain in architectural simplicity which I hope you are aware of. Though you have neither acknowledged nor disproven that yet - based on your last comment, I think this is because you are an asshole. That's not an ad hominem attack, but rather an assessment of your personality after conversing with you here.
I have tried discussing with you technically, and not acknowledging other's points, then responding with "if you can't imagine my points, I can't tell you" is not how a rational, polite adult with a technical viewpoint converses with others.
I'm not saying i can't tell you, i'm saying i don't have the patience. I could throw the book at you and the library besides, but you showed quite clearly that you lack the experience to know which problems multi-threading solves. This means that both of our time is better used if you went and got the experience. I don't want you to shut up, i want you to go and learn something.
On the other hand, yes, i am an asshole. That's why i'll suggest you try and build a minecraft clone with a multi-process/single-thread solution
PS:
> Conversely, there's also a huge gain in architectural simplicity which I hope you are aware of. Though you have neither acknowledged nor disproven that yet
I absolutely said so. I expressed quite clearly that different multi-processing solutions apply to different categories of problems, which of course means that there are problems which simple, plain multi-process solutions excel at, for example webservers.
By no means would I try and build a high bandwidth graphics pipeline that runs between processes. That's a very specific problem requiring a very specific solution. However it wouldn't be correct to abandon multiple process single thread for the (much more common, particularly on HN) situation of a web app that's running on a server with multiple logical cores in non-evented programming language.
> I expressed quite clearly that different multi-processing solutions apply to different categories of problems, which of course means that there are problems which simple, plain multi-process solutions excel at, for example webservers.
> it wouldn't be correct to abandon multiple process single thread
I never said that should be done and in fact mentioned that as a solution/problem pair, see the bit about webservers in the PS of my previous comment. :)
(A web app is just a specialized webserver.)
> When? Please quote.
I did so in a much more concise form here:
> different use profiles that make certain multi-processing paradigms better suited than others
I guess the issue is the full version of the quote:
"If you can't imagine different use profiles that make certain multi-processing paradigms better suited than others, then you shouldn't be having this discussion"
That was the first time you've proposed the topic! I didn't imagine it because you hadn't actually brought up the subject. I asked you specifically what you needed. And already you've told me not to speak to you about it.
How about: "well in games which need single copies of large in-memory assets a multi-process setup wouldn't work due to copy latency"?
Seriously. You're not very good at discussing things with people.
Perhaps you were a Perl person - who, in general, doesn't create high performance games - avoiding Python for typical Perl task because of lack of multiprocessing?
I'm just showing that you (and others) can solve the multicore issue quite easily with a couple of well known modules.
And you tell me not to talk to you because I didn't anticipate you wanted to talk about /video gaming/?
There's a stereotype of early 2000's Perl people: misanthopes who discuss LARTing, hitting users with 'cluesticks' etc. You're reenforcing it.
I was hoping to get you to be creative and come up with your own problem/solution pairs. :)
Anyhow, rather than having you both take my word for it, and at the same time try to prove how bad i am at argumenting (i really am terrible!), i'd prefer to see you actually try a minecraft clone in multiple processes, just in case i'm wrong.
Also, oh god, all that stuff you edited into the reply before that one about LARTing and whatever, you're misinterpreting so much and putting so many words into my mouth, it's not funny anymore. You should try to reread my posts with a conscious effort to not make them sound like a german drill seargant yelling at you. ;)
>>> I was hoping to get you to be creative and come up with your own problem/solution pairs.
>> You wanted me to come up with a scenario like gaming graphics pipelines in a discussion of Perl, a language primarily used for Unix scripting tasks?
> I just told you that i exactly did not want you do to that: "I was hoping to get you to be creative and come up with your own problem/solution pairs."
I run into many Scala fans amongst Java developers. It's the current shiny thing in that technology area. Good old Java (of a similar age to Perl) is usually what they're making their living doing...
Actually Perl 5 is older then Java by about a year (yes, Perl had OO support before Java even left the lab). But Perl itself is much older then Java, by several years.
Sucks to be them; I'm fortunate enough to do Scala professionally. I think "shiny" is unnecessarily dismissive; the productivity and safety advantages are real enough.
The Perl culture is very much "Wild West" meets the race to space.
It's a language for people who are comfortable enough around theory that they don't need syntax to force them to use it.
At the same time, it's highly evolutionary -- it supports the fastest, dirtiest, hackinest method of getting to the goal -- and thus has prototyping built in to production.
I often write Perl scripts twice. The first is a tape-up job to "git 'er done" and the second is a more elegant and architected approached.
This method matches the configuration of most jobs. The client doesn't (fully) know what they want. Last-minute, world-bending exceptions arise. Well-intentioned schemes gang aft agley.
With this prototyping-production, I'm able to get something up and working, and can fix it later if the client has foresight.
Theory is great. I am the first to defend theory. But if it doesn't correspond to application, there's another word for it: arbitrary.
(You may note the difference between two predominant value systems illustrated in that sentence.)
I was used to take a problem of a certain size, sit down and think for a while. Then code C for maybe 3 to 10 days.
When I did a similar problem in Perl, the time to think for a problem of that size was longer than the time to throw a solution at the wall! You could design using code, then refactor/rewrite if it got too bad.
And yes, as the article says, Here's to 26 more! :-)