I am a Perl user and I do like it very much (warts and all). This article reminded me of another self-deprecatory Perl article:
http://ebb.org/bkuhn/blog/2012/12/18/perl-cobol.html
And yes, as the article says, Here's to 26 more! :-)
And yes, as the article says, Here's to 26 more! :-)
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.
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 ;-)
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.
follow me @ https://github.com/hernan604
I think Perlbrew [1] is closest to virtualenv.
[0] But there is Mojolicious, Dancer, Catalyst, etc [1] http://perlbrew.pl/
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.
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.
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.
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.
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).
(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?)
I'd argue single process multiple threads, vs multiple process single thread, vs not blocking, are different solutions to the same problem:
how do I take advantage of multiple cores?
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?
> 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.
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.
> 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.
When? Please quote.
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
"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.
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.
OK.
I wouldn't say that's necessarily an accurate description, or at least not a foregone conclusion.
> I was hoping to get you to be creative and come up with your own problem/solution pairs. :)
Also:
http://www.youtube.com/watch?feature=player_detailpage&v=R5F...
https://dl.dropboxusercontent.com/u/10190786/your_perl_on_dr...
Both done in realtime in Perl.
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. ;)
>> 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."
Christ.
That is actually what Perl is doing. With its loose original design it can evolve amazingly, and in ways that couldn't be foreseen.
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.
Best of all: So much more fun.