by Doug Coulter » Tue Jun 20, 2017 5:12 pm
We do have some books and data reccies, but they are mostly physics stuff.
For programming, of course it's all language-specific, or maybe I should say "for coding" as programming and architecting are different skills hopefully often contained in the same person, but maybe not.
I like O'Reilly books for almost anything programming, personally, but then I like this weird language perl that's kinda out of favor just now.
Python is perl without all the good stuff and with stupid variable indentation whitespace for statement and block/scope delimiters so it can't work right easily in a stream (hint, one line edit boxes you can't paste a newline into). Ruby is perl without all the good stuff...and so on. There's not as much difference out there as you might think at first.
Most languages that start with J are abhorrent to adults but you wind up having to learn some anyway. You can take fads way too far.
Java is C++ with all the bad stuff only. (I'm sure that'll get some flames) Hello world needs objects, really? Oh, no pointers, it's all references, which are, under the hood, pointers...you just can't do good (or bad) things with them now. And a memory manage that runs when it damn well pleases and screws up any hard realtime stuff because they thought coders (and this is largely true, there are a lot of people who just shouldn't be coders) couldn't manage to control memory allocation and recovery on their own. But there's no argument that it's better to really understand lifetimes
of things and mange them properly yourself, and can do slow allocations and de allocations at times you don't have more important things to do.
Perl also has a builtin memory manager, but you can control when it runs...just by the scope of things.
Skip for now all the languages that have only tiny followings - if you're in the field they're overspecialized for, they might be fine, but...really
you could call gnuplot's command line stuff a language in that context (and it's damn complex). Plenty of weird to go around, go for the meat and potatoes stuff first if you can do that.
Eg skip R, forth, schema, lisp and a bunch of others at first. If you have a use they really fit, well then.
Most of the differences boil down to what do you do voluntarily and what's forced on you - and what the libraries do for you almost free. Rust true believers seem to think they can force good programming via strict rules. I await the proper time to laugh my ass off there, not that I don't like Rust. Or any other strict language. Thing is, once you develop taste (Ask Linus) and discipline, you can apply it yourself and don't have to follow some rules that may not make sense right now.
Some people can handle self-discipline, some not so much. As usual in anything else, those who can't try to force their rules on everyone rather than admit their own deficiency.
Bjarne Stroustrup wrote some really good stuff on C++.
Knuth will scare most problems just by threatening to take it off the shelf, but is largely not that relevant anymore.
Design patterns made us laugh as we'd been using some for years, and others were just dumb.
Ditto extreme programming. We did it, not write about it. Works for some, drives others crazy.
Fads are fads. Takes a little time to recognize them for what they are. There's usually one or two special cool things in a fad, but not really enough meat to be the whole game.
For me the best languages are the ones that let you define another language, more or less, and then write one slick sentence or paragraph in this new derived language that does what the program is about - far better than Vogon poetry, honest. And one hell of a lot easier to maintain a year
later when you forget what you were thinking. (if your language makes comments hard, it stinks as a language - use comments)
So, subroutines and in OO methods, are your new vocabulary for your special language and can have whatever depth of meaning you wish (you get better at deciding stuff like that as you go along). You can easily write object-oriented code in any language, we did the first DSP audio stuff in a plain C compiler for an oddball fast cheap floating point CPU. It's just discipline to keep your data defs and routines that do things with that data together, it's not magic.
And that's a thing. Perl has a fairly nasty rep as cowboys who like to do weird or obscure stuff to show their chops use it for that - it's so flexible you can write code that doesn't look like code - but it works even though almost no human can read it (see perl golf or any language's obfuscation competitions). So, don't do that. Any language actually gives you enough rope to shoot yourself in the foot, after all - and so, as the doctor replied to "It hurts when I move my arm like this" - don't do that.
On the other hand, see CPAN. Almost every interesting problem is already solved for you there in "steal this code" form. Try that in almost any other language and it's around 10,000 times less. But that's my religion, it need not be yours. I just want to make all my other stuff work, and it's no longer much of a case of I have to do this in assembly so it'll fit in the time and space of a computer I can afford. So what if it's huge by comparison with what we did in a z80? If it works and I can move on to doing science, we're golden - but that's my use-case.
Once you tell me what language(s) trip your trigger I might be able to get more specific about reccies. I know our business spent many many thousands a year (tax deduction!) on books, and a few percent were actually good ones - even many from the cutout bins in the bookshops that used to exist. But it was by far the minority that were really good keepers. Can't completely blame the authors - it's a moving target.
Posting as just me, not as the forum owner. Everything I say is "in my opinion" and YMMV -- which should go for everyone without saying.