We haven't learned "map" or "grep" yet.

Is that a royal we? ;-)

Yes, learning in groups is ok, also the classic school "class and teacher" approach. But that's not all. Don't think that's the only way to learn. There are so many other ways, and some of them make learning so easy that you don't even feel like you are learning.

Feel free to learn new things outside the group. The group won't always be there when you need to learn something new, so you better learn how to learn on your own.

To learn a computer language, read other people's code and try to understand what their code does. Especially in the early learning process, you will find new things in almost every line of code, and what you read looks more like line noise or a cat trampling over the keyboard than anything else. But things will soon start to make sense. You will recognize some constructs you've seen before. And very soon after that, you will know the most common constructs. Programs look like buildings made from Lego, and you know the Lego bricks quite well. Then, one day, you will see a car made from those building blocks. A program that uses the same building blocks that you already know, plus a single new building block that you have never seen before. That will happen several times, and you will get used to people building cars, trucks, railway systems, space ships, boats from the Lego bricks. Way before that, you have build your own little buildings, perhaps a little bit wonky, but they did the job. Your first "car" may have five wheels and a spaceship canon, but hey, it moved! And the next one will roll on an even number of wheels.

One day, you will find an artistic, huge bouquet of flowers, large and tiny, all made from the same Lego blocks you use to build ugly cars. And you will enjoy not only the look, but also the way it was built. That's why Perl has an "artistic" license.

The great thing about computer languages is that you can do experiments with them without really breaking anything. Take any program you find, make it run on your computer. Then try to change it a little bit. If if did additions of two numbers, make it subtract instead. Extend it to three numbers. You will make errors, Things will break. Your code will look like a mess. That's expected. And if you have messed up the code to the point were nothing works, you can easily revert to the original program simply by renaming your source file to something different and copying in the original file.

There are tools for exactly that, taking, breaking, and reverting code. But they also need some time to learn. Subversion and Git are two famous ones, and once you have learned how to make your computer manage your files, you won't want to go back. But that's a diffferent story, and for your first steps, renaming and copying files is ok. Once you can write software on a level above hello world and the classic calculator example, take some time to learn Subversion. It comes with a really good book, from which you really need only one or two chapters to get up and running.

When I look things up, it feels like I'm diving into the deep end and I can't see the shore.

I know that feeling. But believe me, you've just got your toes wet, and the beach is right behind you. I have that feeling at work with every new product that we develop (embedded systems for medical applications, aerospace, and other industries). Every time, I feel like knowing nothing about the product environment. It takes a few weeks, then I think I've understood what the product will do. Then, our client explains what the product really does, with some of the edge cases, and I see that I'm still near the beach, and the water just reaches the belly button. I'm nowhere near the deep see that I thought I was swimming in. Get used to it. You can't know everything.

We have covered hashes only in the most basic sense so far.

Hashes are easy. There is some math involved in the background, and that's the difficult part of hashes, but you don't have to know that to work with hashes. First, hashes are like arrays, with some little differences:

• Hashes aren't ordered like arrays, they will enumerate their keys and values in a random order that changes with every run of your program.
• Hashes don't use positive integers to find the location of an entry, but instead, they use any strings you like.
• Hashes use % instead of @, and {} instead of [].

Then, there are some functions to help you with hashes: To get a list of keys, use keys. To get a list of values, use values. To get a stream of key-value-pairs, use each in a while loop. To find out if a key exists in a hash, use exists.

For instance in a previous assignment, I really wanted to take a user input and force it to be a floating point number not a string (for math equations), but I could only find a way to take user input and make it an integer "int(<STDIN>)", but what if they enter a number with a decimal? Why is it basically impossible to easily force user input to be a number if it's not a whole number?

Good questions. It's all in the documentation, but perl has a lot of documentation, and in some cases, it's a little bit messy. Reading documentation is another thing you have to learn.

But your feeling is right. Making a number from a string of user input should be easy, and in fact it is easy. Perl's scalars can store strings or numbers, and perl automatically converts them when needed. You don't have to do anything!

Now, input from STDIN usually has a trailing newline that needs to be removed, see chomp. After that, if the user input looks like a number in a format understood by perl (i.e. not roman or klingon numbers), perl can use it like a number.

There are a few ways to trigger automatic conversion, like adding 0 to force numeric context or appending an empty string to force string context. You will see that in other peoples code, and with a little bit of luck, you will also find it in the documentation.

Now, I know that you guys who know this stuff well probably have the answer to this readily at hand, but for me, trying to find an Easy answer for something that I think is a simple question, was not easy to understand at all. Obviously I don't expect that to be answered now, but just explaining how I'm still learning, and I don't always understand what I see online when I look things up.

It looks like Perl is your first or second computer language, That makes things a little bit hard. To stay with the Lego bricks picture: you start with lego bricks, you have never had wood blocks to play with. That makes it a little bit harder to understand stacking of blocks to build simple houses. But do not fear, everyone but Larry Wall had to learn Perl.

Learning new computer languages will become easier, because they share many of the same concepts. Their syntaxes may differ wildly, but things like strings, arrays, references/pointers, loops, if/then/else are quite universal. Your building blocks look a little bit different, but building things works using the same prinicples.

Alexander