I always said my job as a programmer was one of indentured servitude…
Perl For Dummies never came, but I received the llama book today.
For what it’s worth, I second Stranger’s suggestion to use pico for text editing on a Mac.
Johnny, you’re going a lot of unnecessary gymnastics with the programs you’re using to edit text. I’m guessing that you are familiar with TextEdit and so used that. That would be a reasonable way to go about things, but as you’re learning, you want a “real” text editor, not a pseudo-word-processor.
Pico is very easy to use. Just open another terminal window, navigate to the directory your Perl script is in, and type this:
pico Hello_World.pl
Pico gives you hints about how to do things at the bottom of the screen. For example, it has this:
^X Exit
(The carat symbol, ^, is a way to refer to the control key. So ^X means control-X).
By holding down the control key and hitting the X key, you’ll exit Pico. The hints at the bottom of the screen include ways to save, to cut, to paste, etc. It’s really handy to have two terminal windows open: one to run pico and edit your script, and the other to run your script. You make changes in the first window and test them in the second.
Good luck!
Well, start with pico. It will get you used to using a text editor. Then take of the training wheels and graduate to vim, which can have a steep learning curve but once you understand the functions that you use frequently can be very functional and also very configurable. Or Emacs; there is a graphical version that runs natively in MacOS if you don’t want to use the command line interface. But learning to work from the command line means that you can work in any system, Windows, MacOS, *nix, without regard to native applications.
Stranger
Sure; I’m a vim guy myself. But given the tenor of the OP’s questions and his inexperience with the Unix shell, I’m not sure that exceeding the limits of the pico editor is something he has to worry about just yet.
Yeah, definitely stick with pico while learning the basics of Perl. But be aware there are more functional tools out there.
Stranger
Ugh. I sent five minutes looking at Easytrieve. Goodness, a step back to the 60’s.
I don’t know why you picked Perl as the right language to try to work in. Sure, Perl is a powerful text wrangling script, but it is by no means something you would want to start with learning, and the semantic gap between Perl and Easytrieve is cavernous. You will spend a lot of time convincing Perl (in its arcane and infuriating ways) to do things that sort of do what your Easytrieve experience wants.
What you might find really useful is to code in a proper modern Integrated Development Environment, and not spend your life worrying about the arcane nature of editors such as vim and emacs (lifelong emacs user here - but I would no longer develop code in it if there is a sensible IDE to hand.) That said, an editor designed for purpose with language specific add ons (and this include BBEdit, vim and Emacs) make life a lot nicer, as they have syntax directed features. But an IDE will give you serious support well beyond this.
I would have a think about Python. It isn’t as user unfriendly as Perl, has a massive support environment, and perhaps best of all, you can download the community edition of JetBrain’s PyCharm and use it for free. They produce some the best development tools you will see.
You won’t be able to avoid learning a bit about the Unix environment. And as mentioned above, you need to invest a few hours into getting the basics under your belt. Just understanding the basics of the way the filesystem namespace works, the basics of the shell, and how programs run is all you need. This plus the basics of the main useful programs available to you. Things like dos2unix, and for MacOS - using brew to install extra stuff.
At this level all unix based systems are the same, Linux, MacOS X - your efforts should be trivially transportable.
Atom is an excellent free MacOS text editor for programming. I highly recommend trying it out if editing code via terminal applications is overwhelming for you.
I disagree with this. I think IDEs are a terrible way to learn programming concepts. They’re fine for working on actual software projects, but that’s a very different set of skills.
Learning programming conceits is an orthogonal question to writing code. Being saddled with learning a text editor with arcane commands, wrestling with understanding the OS and the tools, all the time trying to work out the basics of the language is silly. An IDE insulates you from the cruft and lets you concentrate on the semantics of the language and the concepts. I find it hard to understand what it is about an IDE that makes learning concepts harder. We were certainly happy enough to have students use them when I was teaching.
Getting away form the edit, compiler run, cycle is a very good start to learning concepts and not just wrestling with tools. Given the OP konws how to code useful stuff in Easytrieve he isn’t starting form zero anyway. Although a modern language might involve a bit of culture shock.
Not at all. I use Notepad at work, but other than that I’ve had no need to use any kind of text editor.
Yep, it’s old-school. Easytrieve is called a ‘report-writing program’. I learned it at Experian in a JCL environment (not that I remember JCL 15 years later), and they still use it. It’s useful for reformatting and calculations. I posted an example in another thread of one that I use, and was told Perl is ‘tailor-made’ for what I want to do. Stranger and others said Python is the better program, but Perl is easier to learn and was pretty much made to do what I want/need.
Python is by far the better general purpose programming language (and actually my favorite language to use for most tasks) but the o.p. is ‘t looking to become a programmer; he just wants to solve a particular task that requires text filtering, sorting, and modification, which is what Perl is designed for and has features in the core language for regex and string manipulations rather than having to call modules.
Python programming also has the mindset of doing things in a specific, optimized style, requiring that you first learn the “pythonic” way, i.e. PEP 8, which is a lot of material to absorb, especially in an informal, non-classroom self-teaching environment, whereas Larry Wall achitected Perl with the idea that ”There is more than one way to do it,” e.g. there is no rigorous style or organization you have to follow to write workable Perl code. Wall came from a linguistics background, and was cognizant that different people will have different ways of expressing algorithims, and felt that the ease of being able to express that trumped confirmity and absolute efficiency. Guido van Rossum is a computer scientist (though he disdains that terms and refers to himself as a “programmer”) and architected Python with the idea in mind that there is one best way to write code for both optimal performance and consistent readability among trained programmers. The consistency is great in large projects that have to be shared across many developers, but for just hacking simple scripts Perl is more in the vein of “get it done” without worrying about adhering to any particular style. I would personally use Python to attack this problem, but that is because I know Python very well, and am rusty in Perl. However, give that the o.p. is really looking for a largely declarative, functional programming approach to a pretty straightforward, non-state-dependent problem, Python brings in a bunch of overhead that he will never need to use or care about, while Perl has core features that just solve his particualr problem, e.g. regex, sorts, and simple import and write out functions.
The common complaints that Perl is too old or obscure to bother with learning is just kind of bizarre to me; it is certainly not the the happening ‘new’ language like Python or Java (which are now pushing or over 25 years old) nor old standards like C/C++ or BASIC, but Perl is extensively used in systems programming as glue code and in computer gateway interface programming that holds the Internet together. As a superset of sed and awk it basically provides a more formalized structure to shell programming that is better able to work across platforms, and it has features that allow it to be used in multiple programming paradigms (although if you are going to do object oriented programming you are better off just learning a more structured language) but it is hardly going awayjist because it isn’t used in web frameworks and hardcore data munging.
Stranger
I’m just a hobbyist, and I started on vim because I like being thrown in the deep end of the pool, I guess, but this (pico) is what I would suggest, as well. vim can be somewhat arcane and overwhelming to a newcomer, and pico is pretty much figure-out-able from the first time I tried it. Otherwise, I use BBEdit for Mac when I don’t want to do it in Terminal. I never paid for it. I just have what I guess is the version that it reverts to after the 30-day trial, but I don’t even know what advanced features I’m missing, as I never need anything beyond the basics.
If we’re taking votes, I’ll say that I think perl is a fine language for the OP’s purpose. He’s mainly looking for a way to process a spreadsheet and generate reports, and perl has some nice report generation features (its most common backronym is “Practical Extraction and Report Language”).
As for the editor, please note that per #28 he is no longer using TextEdit; he switched to BBEdit, which is a perfectly fine WYSIWYG editor for his purpose. Learning a keystroke-command editor like vim or pico involves an unnecessarily steep learning curve for someone used to WYSIWYG editors. My editor of choice is vim; I’ve been using vi/vim since 1978, but I wouldn’t recommend it to a novice unless there’s a good reason.
Oh, cool. Missed that post. BBEdit is comfortable and familiar and my most-often used non-Terminal editor.
I must point out that one can run Vim (and Emacs, or Spacemacs…) in a separate window, or even multiple windows, on Mac as well as Windows. You can run them inside a Terminal, but you don’t have to if you don’t feel like it. (You could also have multiple Terminal windows open at the same time!) So they are by no means inferior to BBEdit and its ilk in that respect; the choice comes down to which interface fits your typing style and personal preferences. In my book, they get extra points for being customizable free software with all features always available.
If that’s the criteria then OP should use RPG (Report Program Generator). 
It’s not actually required to be pythonic. It’s more…aspirational. Lords know I ignore around half of PyCharm’s little PEP8 annoyance underlines on a daily basis.
In case it hasn’t been said yet, I highly recommend putting
use strict;
at the beginning of every single Perl program you write (just after the #!/usr/bin/perl. Just get in the habit of putting it there every single time. You won’t regret it, as it adds compile-time checks for many common errors.
With that line, you may find that some code samples no longer work. This is because it requires declaring all of your variables with the my keyword:
my $x;
$x = 3.14;
This will save your ass from typos. Whereas this happily executed before (silently giving the wrong answer):
$tax = 0.05;
$subtotal = 100;
$total = $subtotal * (1.0 + $tex);
This now gives the correct error:
my $tax = 0.05;
my $subtotal = 100;
my $total = $subtotal * (1.0 + $tex);
Global symbol “$tex” requires explicit package name (did you forget to declare “my $tex”?) at test.pl line 5.
The lack of any real equivalent to “use strict” is the biggest deficiency of Python in my mind (Python will give an error, but only at runtime).
Python’s “Pythonicness” ia specifically a reaction to Perl’s free-formed-ness. Having a whole bunch of equivalent ways to do the same thing made for some incredibly hard-to-read perl code, since different programmers would express the same intent in radically different ways. Python’s strictness meant that intent was easy to infer from syntax.
This is, I think, overstated. Perl had its heyday with CGI scripts in the 90s/early 2000s, and while there are probably plenty of hoary old CGI scripts holding together important things, they are almost extinct for any new work.