I've tried to use: require("socket"), but I red on forums about WoW that I can't use the require command. Is there any other way to accomplish this? I'd like to pass data from the Lua thread to a Java thread.
You cannot use sockets, and there are no other way to communicate with other programs either. This is a restriction applied by Blizzard to prevent some forms of cheating, and to avoid malware propagation and other account security breaches.
In general you won't be able to communicate with third-party apps. There are workarounds, but they are hacks, they are likely to break in future updates of WoW, and they probably violate some terms of service.
I'm not quite sure that this is on-topic (if it isn't, I'll delete it ASAP =)).
I've decided to start teaching myself Perl and how to use it for web development.
I've done the same about a year ago with Python, and although I'm not an expert (I code in Java during work hours, and spend some personal time trying out other stuff), I've been able to create some websites using Django, and I've used ProjectEuler problems to get to know the basics of the language.
From my first approaches, Perl seems to have a steeper learning curve then Python.
I've been looking at some Web dev. frameworks for Perl and stumbled upon Catalyst, which seems very interesting.
My question here is: Is it even worth it to try it out while still struggling a bit with the language, or will I be wasting my time? Should I master Perl first, and then perhaps CGI before jumping into a framework that probably abstracts many concepts from the developer?
Thanks for any insight!
Catalyst is a great framework, and Perl is a great language. I don't know about the steeper learning curve part - I don't know any of the other languages.
As to learning Perl whilst learning Catalyst, this is almost exactly what I did. Work required that I produce something with a web interface. I ran into Catalyst and thought, 'Great, that sounds easy'. Well… it is and it isn't. There are learning curves with everything and Catalyst, like the rest of Perl, gives you plenty of rope — more than enough to hang yourself with.
The way to keep that from happening is to read the Catalyst book, and read some generic Perl books. I'm from a background of UNIX/Linux, so I also read Minimal Perl by Tim Maher, and find it extremely helpful — I go back to it constantly.
CPAN is really helpful with Catalyst — so many people have come up with ways to do "it", and Catalyst can work with pretty much all of it.
Also, make sure you head over to irc.perl.org and listen in on the conversations in the #catalyst and #dbix-class channels. Use #perl on freenode as well.
I think you can fumble through Perl while you use Catalyst. Here's a great book on Catalyst.
My opinion is that learning CGI would teach you the theory behind the framework. You may or may not want that. I think people learn a lot of the theory over time as they become a more advanced user of the framework.
I would recommend Catalyst while learning Perl.
Perl + Catalyst + Catalyst Tutorials + Modern Perl book = awesome (use in the same time)
You might start with a "microframework" like Dancer if you want to more-quickly reach a point where you're productive in your learning phase. Catalyst is very good but has its own learning curve, especially if you're also new to Perl.
Maybe you should first start to explore the differences to other languages, which make perl such a good alternative to the classic programming languages. After this I would recommend to start with Catalyst for deepening your skills ;)
Are there links, materials, or books about network programming with Perl that are relevant to 2010? I saw some books on programming the network with Perl are very old (about a decade) and the tutorials on the internet are also old and using old modules.
Could someone provide a good reference about programming sockets and network layer/application layer protocols with Perl that are updated to 2010?
This task really demands an asynchronous framework: pretty much everyone uses POE these days. I hate it because for me it doesn't look like Perl. It looks like its own special silly premature-optimized language. Anyway, you can find more info on cpan's docs about poe.
The internals of POE are weird, and POE does rather silly stuff like statically index the contents of #_ for "speed". A POE-component looks like a little brick of voodoo-dung right in the middle of your code. You might like it, give it a shot. If you have to debug it or expand POE::Kernel you might want to look for employment elsewhere.
There is a growing alternative too: AnyEvent. I'd look at it first. It does things massively different and is a much thinner layer that doesn't want to infest your whole application.
Links:
AnyEvent::Socket
POE SocketFactory
Although Lincoln Stein's Network Programming with Perl is a bit old, the content is still mostly good. Network programming at that level hasn't changed that much in the last couple of decades. If you want to learn to play with sockets, that's the book to get to get you started.
However, Perl at the socket level does that same thing the C libraries do. There might be some nice interfaces around it, but look under the interface and you'll see the same things.
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 10 years ago.
I got into Perl years ago and always found it a fun and expressive language to work with.
I found that programming in Perl makes me quite productive thanks to its low overhead and the outstanding amount of ready-made solutions to common problems on CPAN.
If you're new to Perl, what got you into it?
I was coding PHP for a living, and then heard of their change from :: to \ as a name-space separator. I'm really not joking or being spiteful, but that is really what got the ball rolling.
Not to be elitist, but I suddenly realised that the people I had to collaborate with whom knew PHP understood very little in programming concepts in ways that frustrated me how they could be so blind, the people in the IRC rooms for it were no longer a source of help for my questions, and I usually spent more time answering questions and waiting for somebody to turn up whom could answer mine. Usually I ended up solving it myself.
Most the time I realised was people re-solving the same problems over and over again in increasingly bad ways.
I discovered problematic behaviours in PHP which defied logic and reasoning (like the array_merge_recursive family), and discovered functions that were undocumented in how to use them, and when I reported a bug in the functions, my bug was marked as "Bogus" and I was expected to be psychic.
I had a friend whom was constantly proclaiming the goodness of Perl, so I basically gave it a shot and now am hooked like an addict.
Additionally, my experience in other higher-order dynamically typed languages (JavaScript and Ruby, yes, JavaScript is a more powerful language than PHP in terms of language features) left me a knowledge with many ways to solve types of problems easily, but being restricted in such a way I had no way to use these powerful features. Perl satisfied this need.
Why Perl and not Ruby? I've played with Ruby a bit, but my experience taught me the support and documentation is sparse, the language is slow and immature. Nice it may be, but its still in diminished in capacity against Perl from what I've seen. And it shared PHPs major flaw that it has a huge user base comprised of total novices all doing things the wrong way, and I really wanted to not have to deal with that so much.
It's not nice to be elitist, but once you have tried to explain the same thing to 30 people (and taken an hour to get a simple concept into their heads every time) it reaches a point of frustration. (I can't cope with the 'There is somebody on the internet who is wrong' situation, If I can't SEE it, it doesn't happen)
I started doing Perl during my third year in computer science as a part of 'Scripting languages' course. I have a friend studying biotechnology and I helped her with some data mining scripts for dealing with protein databases (parsing text files, regexps, simple integrity checks). It was all very natural to do in Perl.
Then I got my first part-time job and had to use it professionally. I was responsible for developing set of batch scripts that handled some part of business logic in the company. And it was the task where Perl revealed all its potential. Need to get data from DB? - no problem, just go to CPAN. Need to automate wiki - no problem, go to CPAN. The amount of already created modules is overwhelming and you can be sure you will always find what you need in CPAN.
To sum up. For me, Perl is a swiss army knife of scripting languages. Everything can be done in it and it has huge number of additional modules even for very exotic tasks. And by the way, did I mention REGEXPS?
With Perl (and the expressive power behind TMTOWTDI), programming becomes a creative task. I can write if($expr) { $statement; } if I plan on having many else statements, or I can write $statement if $expr; if that makes more sense (for example, I'm fond of writing:
sub doSomething {
my($toObject, $argument) = #_;
die "No object specified" unless defined($toObject);
die "Object invalid: $toObject" unless $toObject->ISA('Example');
# Do stuff
}
but of course that's not always the easiest, and most expressive way of doing it; so I come up with a better way for the task at hand!). People complain because Perl lets you write horrible looking code; I love Perl because it lets me write code which looks pretty to me (and yes, I can see the downside of having a dozen different programmers writing in their own styles; I'll hold to the idea that good writers can be pretty expressive and understandable no matter how different the subject matter).
With other programming languages, I end up having to think my way through abstraction layers (how will this Map give me Collections whose Iterators I can use to ... and so on). With Perl, I'm usually only one abstraction level above basic Perl. For instance, DBI will give me database results as ordinary, everyday Perl scalars, lists and hashes, so everything I know about these simple, core data structures carries over to every task I put DBI to (Complicated data structures? That's what PostgreSQL is for!).
I've only been using Perl full-time for about a year, but these are the big wins for me, and the reason I first went full-time onto Perl after a year suffering at the hands of Java 1.4's Collections model (don't ask). Other programming languages make me feel like I'm putting together a jigsaw puzzle, as you line up all the modules and packages just right; Perl feels like a box full of Legos, with some "special" bricks (like DBI, CGI.pm and Test::*) thrown in for good measure. There are tons of different ways to solve any problem, and Perl lets you try any of them you like, in any way you like.
I'm still not that long time in the Perl community and what me first brought in was Larry Wall's humor and wisdom. True, Perl has it quirks but the language comes from an understanding of things that is very close to mine so I'm much less comfortable with Python and to a lesser degree Ruby.
I don't do web app's more GUI with WxPerl and it works just fine. I'm very interested in languages also in lesser known like factor, boo, rebol and so on but all in all is Perl my choice. and it's because a mixture of powerful syntax (can be very functional if you like it), the community, CPAN of course, and, like I said before, due to the cosy feeling being in the right place.
Perl is its community, which is the reason to use it both on a social and practical level. (See CPAN and Perlmonks, which likely inspired SO.)
There's a lot of freedom when coding in Perl; you can write some wicked-crazy unreadable hacks, but it doesn't take long once you've gotten a feel for the language (and learned how to use perltidy :-) ) before you realize that well-written perl code can look downright pretty.
It's interesting; I ended up as a full-time Perl programmer after learning it for my sysadmin-type job in college; and now it's my strongest skill. I'm going to stick with Perl for a while because so far the language has been versatile to grow with me. I write a lot of systems software in Perl, and decided to pick up web programming for fun, and Catalyst was there waiting for me. Do I want to try out a new language paradigm? Perl will probably support it. In contrast, when I was coding in PHP for a time, I immediately felt like I was pressing against a glass ceiling.
I work as a technological troubleshooter for a big organization in southern OH. I had to learn Perl to keep some automated network text manipulation systems up and running and eventually got a little excited about it. I eventually thought of myself as a developer and wrote some programs that parsed some database data and made some people’s lives a little easier. But after reading some of the posts on this website and listening to the stackoverflow podcast and even starting to read the book Code Complete from someone’s suggested reading list I no longer have any delusions that I was a developer of Perl or any other language for that matter. However, maybe someday I could be.
I had used awk a few time for shell scripts way, way back in the days. In one ancient project we needed to implement the a TELNET protocol connection, so I wrote a quick version in Perl 4. It worked really well, and I started to really like the language.
Later, I wrote a big full commercial web application in Perl 5, complete with it's own framework and database. I was careful not to use to many of Perl's more esoteric features, so the code looked more like C than Perl. It worked really well, performance was good and the code was easily extended.
Recently I've been working in Java, but I often find myself missing the Perl's loose typing, and its ability to encapsulate things way better than Java. My favorite features were being able to put Perl datastructures (arrays and hashes) and code directly in config files and execute them, and the ability to tie code to syntax like arrays. Both lead to some really slick code.
Paul.
simple syntax, powerful scripting capabilities for win32 and unix systems, and totally powerful regex!
I pickup Perl on my first job where I had to write plenty of automation script for electrical engineers to mine datalogs and format them to Excel and sometimes deal with sql server too. With Perl I could usually get something working rather quickly, so all is good in the manufacturing land. :P
I started using Perl as an enhancement to our build process for embedded development. We needed to develop diverse outputs based on our cross compiled payload and Perl was a great fit.
Our enhancements included floating-point to hexadecimal conversion, S-record post-processing, and checksum modifications.
Not that this kind of work can't be done with many other tools, but I would definitely recommend Perl for build-related work.
What brought me to Perl was when I saw the DBI and realized that I could write the ESQL/C programs I was writing at the time in one fifth the time.
What has kept me using Perl is that the two other languages likely to unseat it are both strongly typed. That is
print "10" + 5;
is a type error rather than 15.
I'm not taking it up. I had to work on a project in Perl a few years ago, and I came to really dislike the language. It has a sometimes-awkward syntax and a lot of crazy gotchas that I found hard to work with. Honestly, I think Ruby has superseded Perl in many respects: it's good at roughly the same things, but has much nicer features and is easier to use.
Perl still has CPAN, though, which even Ruby can't match (although Ruby has a lot of useful libraries, too).
I considered learning Perl last year.
It was the only technologies that I actively decided not to learn. This is nothing directly against the language itself, it just seemed that I would be coming to the party 10 years too late. It is very useful for the shell scripting tasks that it was designed for but for me personally I prefer languages with a stronger coherence.
Perl 6 seems like it's on indefinite hiatus and even when it arrives I don't believe that it will make the language profoundly more compelling.
Also, Larry Wall scares me.
For my situation Perl wasn't the right choice and thats why.
Perl is not as bad as I thought. I used to use it in a couple customer scripts about one year ago, and even grew to like it a bit. Then again, I've never ever missed it since.
The reason? It's mostly a write-only language. Going above a 100 line solution made me be wary of my own code, which is definately not a good outcome. With other languages that bar is considerably higher (maybe 1000 or 10000 lines).
I see no reason to go for Perl in new projects, for new users, in -soon- 2009.