Schoolwork is keeping me from doing anything with this particular project, but some years ago I decided that I'm going to learn how to program.
I've decided to learn Perl first. Please tell me why this is a horrible idea! The more interesting reasoning, the better!
> Python was designed by professors to make it difficult for their students to introduce bugs into their code.
Guido van Rossum was never a professor, and he didn't make the language for students. I also question the part regarding the introduction of bugs.
> Professional programmers say they just enjoy Python.
I must not be professional enough then.
> It has led to a very bloated language over the years.
While Python is nowhere near the same league of syntactic evil as Perl, I must point out that it's also suffering from featuritis. It's not a simple or consistent language, all the kowtowing to the contrary.
Please don't, >>28.
I love Python and all, but Python vs. Perl gets tiring pretty quick.
yeah, my first google hit says Python's predecessor, ABC, was the one made by the teachers. And Guido worked with them.
http://www.artima.com/intv/pythonP.html
>>>SOME professional programmers enjoy using Python. There will ALWAYS be flamers no matter what opinion you express. And they usually don't bother to mention the parts of your statement that they agree with.
Fixed.
Lua should be mentioned in a discussion of bloat. Its owners resist letting the basic package get over 100KB. You run into nastiness (binds) when you need to call Windows API though.
Euphoria is not as high level as TCL/Python/Perl, but it has the Windows API interface built in, and it has a to-C translator.
>Python vs. Perl gets tiring pretty quick
The original poster was a newb asking why he shouldn't use Perl. I was writing to him, not to old fahrts that tire quickly.
>Lua should be mentioned in a discussion of bloat.
But this isn't.
>I've decided to learn Perl first. Please tell me why this is a
horrible idea!
Because it's bloated.
>But this isn't.
Yes it is.
> Because it's bloated.
This is an argument against it, because...?
See, strict minimalist languages are not easier for beginners to learn. There's no requirement to learn all of a language when starting out programming in it, and as a matter of fact, there's no need to learn all of it to use it normally either. This is why C++ is so popular despite having a ridiculously huge feature-set: Nobody bothers learning all of it, and the language works just fine even if you ignore most of it.
Have a large and varied feature set does, however, let you pick the parts you are comfortable with using, and focus on those.
> This is why C++ is so popular despite having a ridiculously huge feature-set: Nobody bothers learning all of it, and the language works just fine even if you ignore most of it.
Except when you want to work with other programmers, and they program in a different island of the language.
That is only a problem if you are going to work with other programmers, which you probably won't as a hobbyist.
How many hobbyist programmers do not eventually start working with others? It's not just working with others either, but also simply reading the code written by others.
I concur with >>35. Languages with too many doodads are just as unpleasant as those with too few.
I neglected to mention: how often have I used a feature of an overly-complicated language, then come back to the code a month or more later and had no idea what I was looking at?
Far too often for comfort.
>>38
clearly comments are a feature you're not familiar with
A hobbyist will download sample programs from the internet. I did this with Java. I kept buying books so I could follow the programs. The book stack is almost 3 feet high now. Java Core, Java GUI, Java Swing, Java Beans, Java AWT, Java Kiss My Ass, Java Never Again.
Some language "guardians" learned from that and try to keep their languages small. Lua and FORTH are the best examples I can think of. FORTH founder Moore is an extremist at removing redundancy. He has a complete system: OS, GUI API, apps, etc in less that 1 MB. FORTH is still tricky to learn though. (http://ficl.sourceforge.net/)
A hobbyist can make things easier on himself by choosing one of the languages that are deliberately kept small. Lua is my choice. And I remember something about Pascal and TCL language definitions fitting on 1 or 2 pages. (freepascal.org) Turbo Pascal was fun back in the 80s because it compiled instantly.
But Perl is the opposite of this keep-it-small idea. It can be a real struggle to follow a sample Perl program that I find on Google.
>>39
My, my, what a perceptive comment.
I'd appreciate keeping the jackassery to more appropriate boards.
>>40
The problem with Lua is that if you want to call C libraries, you have to write tricky C code for the bindings. And personally, I find programming a lot more interesting when I can do graphics and stuff, rather than just little command-line things, which is all you can do with bare Lua.
Perl and Python, while they are big languages, don't have this drawback because their popularity has led to a lot of bindings and things already being written, but with Lua, if any binding exists, it's probably a barely usable version 0.2 that doesn't even support the latest version of the language.
> FORTH is still tricky to learn though.
So, uh, your point was...?
When you fail to learn Perl you can blame the syntax. When you fail to learn FORTH you can't, because there is no syntax.
Learning to use a language involves more than just the syntax though. If it was just syntax, we'd all be using infinite tapes and states (or functional Lisp), since that's as simple as we can get.
Perl crams a lot of ability into the syntax, so you can do certain things very simply. Forth goes the other direction, so while the syntax is dirt simple, doing anything is harder. Imagine implementing regular expressions in Forth. Yech.
Which language do you all most ENJOY using [and why]?
Maybe that's the best approach since the original poster
seems to be a hobbyist.
For me it's Python since 1) it's a pretty complete package with all the documents and libs I need, and 2) I follow it easily. I don't think I've ever gotten stuck on anything for more than 2 minutes. I can't say that about anything else I've tried.
But I can see where some people might prefer to invest in Perl's learning curve to receive the POWER of the syntax.
And FORTH reminds me of LOGO: just enough commands to do something interesting. I can see the appeal of a language+library so small that you can keep it all in your head and never re-read the manual. Yes it's more coding work, but you don't get diverted for 2 or 3 days tracking down a man page for some odd function. At least not often. That ain't fun.
So, which one is your fav? And, which one is next on your list to try?
For me, C. Yes, the thing is low-level and easy to screw up, but I like how WYSIWYG it all is. If your program is doing something wrong, you know it's not because of some bizarre automagical language feature, it's because you screwed up. And it's the language I have the most experience with.
"Scripting" oriented languages like Perl and Python mystify me with their implicit references, shallow vs. deep copying, automagic conversion of integers to strings and so on. There's just too much hidden stuff going on that I have no idea what my program is really doing. It may seem to work, but I don't know if it always will.
>For me, C.
A tip for the C beginner: pointers will kill you with bugs you can't trace. Avoid them if you can.
∧ ∧＿__ what
／(*ﾟーﾟ) ／＼
／|￣∪∪￣|＼／
| |／
￣￣￣￣
i prefer perl (and scripting high level languages in general) because :
after all of that i'm learning C and Java because :
as for objects... Java owns C++
I prefer C... and there's one reason C is more usable than Perl...
Perl is a scripting language. If you are going to sell any software or try to get other compuuters to implement any of your scripts, you have to set up the Java environment on them. In addition, while Perl is awesome for making one's own code, it doesn't help when making code for anyone else in the world, because you can never hide the source code.
C is also better for it's ability to affect the OS. If you're a skilled programmer, you will find that you need such code.
TCL when I already have C programs that do most of the stuff I need. TCL has a simple argv string interface to C routines. I can add that to old C programs quickly, then write TCL code to tie the C programs together, passing data between them and displaying it on a GUI with Tk. And with Expect, I often don't even have to recompile the old C programs; just use their existing stdin and stdout. Prototyping is easier this way instead of adding new C code since TCL is high-level script and interpreted instead of compiled.
Java owns nobody. Java is an mediocre language for mediocre programmers to write mediocre code in. Java is not horrible, but neither is Java actually good at anything. It is merely average.
maybe that's the reason why it is used by every company to do they business solutions and planning programs as well as web interfaces
>>57
Actually, the reason for that is "marketing."
Companies pick Java because it has a lot of support from Sun and other companies. The others (perl, python, etc.) come from individuals. There's no hotline to call for answers like you can get with Java. And the product's reliability is in doubt when there's no big corporate backer. Companies just like to deal with other companies.
Anyhow, we had a few good posts where people named their favorites and good reasons for them. I'd like to see more of those; I might learn something. I already moved Ruby higher on my list of things to do. If that poster can recommend a download package with eveything (docs, libs, interpreter, debugger, etc), I'd like to see it.
Right, "business solutions" is the very definition of mediocre code written by mediocre programmers.
> If that poster can recommend a download package with eveything (docs, libs, interpreter, debugger, etc),
For windows, I'd recommend this: http://rubyinstaller.rubyforge.org/wiki/wiki.pl. Stick to the SciTE editor.
If you're using some form of *nix, you'll have to install it all in individual pieces.
is ruby really fucking slow compared to perl or are portupgrade and pkgdb just really poorly written? those are the only things written in ruby that i use often and both seem incredibly slow for what they do...
>>62
it is
ruby doesn't have a bytecode compiler yet
Just started with ruby myself, and while the documentation is haphazard at best, with one of the wierdest introductions you may ever see (http://poignantguide.net/ruby/), but on the other hand it's by far my favourite new language.
Also check out the ruby plug-ins for eclipse if you like the IDE vibe
Of the available guides out there (Pickaxe, Poignant, and Matz's), I like Matz's the most. Just the facts, ma'am: http://www.ruby-doc.org/docs/UsersGuide/rg/
doijwqndciw
>>66
is that perl code?
i think you left out a few @'s
>>63
It's been this way for what, four years now? When are they going to actually do a bytecode interpreter?
Or is it simpler to just, you know, fuck about with the parse trees and stick with reference-counted memory management, like the assholes with perl and python?
Ruby 2.0 probably isn't coming any time soon.
> You need Ruby command to build YARV :)
sounds like it'll probably take a few years just to build it...
Most of YARV is in C. The only bit Ruby seems involved in is generating the Makefile.
I like PHP, because I enjoy making little web doodads. And it seems to be pretty damn easy to do just about anything in PHP.
Including shooting yourself in the foot.
Silly >>72! Don't you know that any mention of PHP on this board is met with replies of ill-conceived panic and h8orade?
>>75
See the "PHP users are dumb" thread. I guess PHP is okay for "little web doodads", though.
My, that was enlightening. Thanks for bringing that to my attention. I was unaware of the securitiy risks and such.
I've never written anything big in PHP, though. I do bigger things in Python.
I am sorry that we don't give you the common courtesy of blinding ourselves to your favourite language's glaring flaws.