Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[Jookia]

I don't really have an argument anymore. You've convinced me that C/C++ is totally useless for everything in existance.

[G-Flex]

Then he managed to convince you of something he never said, which is a pretty cool feat.

[Shades]

Can someone lock this thread as it's gotten all ranty.
I hope the op got the information he needed well in hand before it did so.

[ThreeToe]

Don't call people names.  That's not cool.  I'm not going to delete all the off topic ranting, but i hope this thread can steer back on course so we don't have to lock it.  Thanks.

[Kai_Kratz]

After the disappearing of original rant ill try to repost it in more civil manner.

Id like to point out to the OP that if you engage in programming he will have to witness such battles of wits way to often to endure it without fits of rage.

Therefore id advise him not to learn how to program and instead do something worthwhile with his time.

-Kai

[Blacken]

After the disappearing of original rant ill try to repost it in more civil manner.

Id like to point out to the OP that if you engage in programming he will have to witness such battles of wits way to often to endure it without fits of rage.

Therefore id advise him not to learn how to program and instead do something worthwhile with his time.

-Kai

I don't think you actually read the conversation. In my experience, this does not happen among competent programmers--either because they can admit when they are wrong, or they don't jump in feet-first with inane statements to begin with. The nice thing is that people generally notice when programmers are incompetent (when they talk, anyway--workplace, notsomuch) and stop listening to them, which has a damping effect on this sort of thing.

That's absolutely bogus "advice," and constitutes very little more than trolling. Pike off.

[Kebooo]

I read through the topic, and I'm unsure about a few of the listed reasons to avoid learning C++ early on in a programmer's career (I understand that it's not ideal to start with for most people, or even ideal to start with at all).

Suppose you are someone that wants to ultimately understand assembly and every intricacy of allocating memory, would C++ not be a good language to learn simultaneously with another simpler language?  I started with Python several years back, and moved to C++, and while I agree it has a lot of obvious flaws, I tend to be the type that wants to understand every little detail before I abstract it - ie, I'd rather understand physics, then chemistry, then biology, rather than reverse, or at least chemistry before biology.  So I find it extremely hard to start with more abstraction rather than the reverse.  I received my degree in molecular biology but I'm trying to learn programming on the side, and I approach the subject from the opposite angle of abstraction - I feel more comfortable with code if I have the capability to fully understand what's going on, down to the freeing and allocating memory.  I would rather spend more time writing more complex code, and then learn the "here's a simpler way to do it" later on.  While I may simply assume a certain cell works a certain way for brevity's sake, it's nice to be able to understand underlying mechanisms because some of us need that logic and order or else we sit there going "why, why, how?" and so on.

I'm sincere in asking if there's another language I should be focusing on over C++ when it comes to being able to write fleshed our programs while simultaneously not becoming too abstract.  Or if there is a combination of multiple languages to learn side by side that will complement one another.  What the topic has shown is that it's hard to get by only knowing one or two languages, and it seems like it makes sense to me, for the way I best learn, (maybe not to others) to learn different languages simultaneously (like physics, chemistry, biology) rather than sequentially (only learning physics after you've truly mastered biology). 

[Blacken]

In today's environment, assembly is something of an antiquated joke outside of hardcore systems programming--it's needed until somebody bootstraps a C compiler onto a platform, and after that? ROL. It's not like C or C++ actually function like the actual underlying hardware unless you're tossing around some very advanced C concepts--C could be described as "the world's thinnest virtual machine" precisely because it's abstracting away the metal. C presents the same effective interface on ARM and x86 and all that, and it doesn't at all look like the chip below it. If you're (stupidly--that's not intended as an insult, it's simply a mindfuckingly bad way to start) insistent on "not abstracting," then you want to be even lower than C. Messing with toy crap is below my interest level, but if that's where you want to go, go do it. Don't waste time with C++; go on, break out NASM and go write some assembler! Actually, no, strike that--if you don't want abstractions, go write machine code in a hex editor, hand-build them bit-by-bit (it's doable, I think I remember how the Intel ISA works) and run 'em!

You seem to be laboring under the illusion that abstraction is "bad." That's what programming is. The problem with starting C++ is not that it's complex, it's that it's needlessly complex and was more "grown" than "designed". The deficiencies are well-known--like, in the real world, even hot-shit C++ programmers go use a memory manager that's been bulletproofed by somebody else (unless they are A+ top-tier guys, who know who they are). More importantly, the paradigms necessary to make C++ code not suck are so wildly divergent from the rest of the world that you'll be putting your foot in a bucket when you want to do something useful. I can very often tell when somebody started with C and C++: because every other code they write afterwards is C++, even if it's actually written in Java.

New programmers just don't benefit from starting there. You can understand what is going on to a functional level without dicking about with it.



If you intend to never release anything to anybody else in an environment where you can't be watching your code all day long, then C++ is surely fine, but I contend that it is goddam irresponsible to release probably 95% of everybody's C++ code to unsuspecting sapsusers.

If you're writing code for molecular biology, Perl seems to be the way people go. Or ancient FORTRAN code, but suicide may be a preferable option if anyone ever asks you to hack on that mess.

[Kebooo]

I didn't mean to say I don't want to learn abstraction, or that it's bad, I'm not sure how you came to that inaccurate conclusion.  I'm saying the more I understand what's going on in say, a function or memory allocation, the easier it is for me to conceptualize and use it, or quickly understand something different but similar in nature.  So I'm trying to strike a balance between pure abstraction and pure methodology, let's not force a false dichotomy on what I was asking.  If a programming language got to a point you could simply type in "print a green screen at 1600x1200 resolution with a blue box 300x300 pixels in the middle" without anything else, that would obviously be extremely abstract, but a lot of us would still want to understand how they came to that abstraction (in case we want to be the ones writing the abstractions).  Biological sciences are an abstraction of physics, but for some people it becomes easier to see the big picture when you understand the detailed physics of the interactions, and yes, you can be a phD in genetics without ever fully grasping the physics.  It's just for some of us it's easier to work with abstraction when we understand how it was abstracted and what all of its uses and limitations are.  I just approach abstraction differently - I prefer to build up to it, or learn methodology side by side.

So what I'm asking is what is the best course to learn useful abstraction in programming while simultaneously understanding exactly how it is interfacing with the operating system, CPU and memory.  I'm willing to learn several languages at once, but I don't want to take the rout of "oh, you don't need to understand what's happening behind the abstraction to use it" because that's simply not how my mind is organized.  Even if that statement is true, the comfort understanding something gives is priceless.  You may not identify with that sentiment, but for a lot of people in science, it's true.

[Shades]

If you want a complete grounding I'd recommend both erlang and pascal along side python, php and c++, you won't get much use out of the first two, well possibly you could with erlang if your into concurrency, but they differ considerably in how they work and so make it much easier to think about a problem rather than being trapped in a language you know.

I wouldn't recommend to learn them all at once though. You need to play with a language to learn it and you'll probably find it hard to switch how you think early on.

[Blacken]

I didn't mean to say I don't want to learn abstraction, or that it's bad, I'm not sure how you came to that inaccurate conclusion.  I'm saying the more I understand what's going on in say, a function or memory allocation, the easier it is for me to conceptualize and use it, or quickly understand something different but similar in nature.

You don't need to conceptualize it. The point of a programming language is to present you with a system that is sane and self-consistent that has very little to do with how the hardware underneath actually works, because hardware is almost always an inconsistent shitty mess. You will not have a better grasp of how the system handles memory by shitting up your code with malloc() and free() statements, because that's application-level logic and you won't be reserving memory by yourself. You will not be a better programmer or have a better grasp of how internal memory management works by learning how an operating system manages virtual memory and how the TLB works, and you won't even learn that when writing C or C++. You would be a better operating systems programmer, but as near as I can tell that's not your goal.

If you want to go read about how it works, you can read something like Tanenbaum's book or the Hennessy book, but I'm telling you: that's not relevant to actually learning to program, because you're already building on so many abstractions (even just in C: stack frames, flat memory, scoped variables, data types...) that you don't have the mental framework to understand directly that adding a few more isn't going to kill you.

So what I'm asking is what is the best course to learn useful abstraction in programming while simultaneously understanding exactly how it is interfacing with the operating system, CPU and memory.

You will not "interface with the operating system" in any language except through interrupt-raising--C, if you're really really bored, or assembly. You will work with libraries that do it for you regardless of language. Abstraction is everywhere. You will never "interface with the CPU" except in an extremely limited way when writing assembly. If you want to go write an operating system from scratch, you will certainly learn and understand this stuff. You won't in any way from writing code in user-space languages.

You're asking the wrong questions. I'm trying to point you toward the right ones. Start with the ThinkPython book and it should give you the framework you need to work downward--but it does not sound like you have the framework to start bottom-up.




(And Shades, while I love PHP, recommending anyone seriously learn it is scary. Unless you're already well-trained, PHP inflicts brain damage.)

[Kebooo]

Maybe I'm not really getting my question across clearly enough.  I'm not sure whether I will ever actually pursue a job in programming or not and I don't want to only learn what can be used in practical application.  I'm someone that reads string theory for fun, for nothing other than to have the knowledge of it.  Maybe you're not into that kind of thing, but you shouldn't assume other people aren't.  Since programming languages take a lot of reading and practice to even become decent, I'd like to become good with the least abstracted, commonly used abstract language, if that sentence makes sense.  C++ was what people (at the time) had told me I should learn, and you're saying otherwise, so I'm asking, for my particular instance, what you would recommend.  I understand C++ is abstract, but I'm looking for an abstract language less abstract than others while still being useful to create programs in Windows.  That way I can move from the least abstract (yet, I understand, already abstract) language to the more abstract languages.  I find that easier (C++ to Python) than the opposite (Python to C++).  Or rather, learning some C++ has made Python easier for me, but learning some Python didn't make C++ feel much easier.  Are you going to take the position all human beings learn the same way?

To explain, and correct me if I'm wrong, you were calling C++ less abstracted than other languages and that you need to write more complex code to cover the same thing in another language because you have to manually cover more bases.  You see that as a negative, I see it as something important, scholastically.  I'm not sure you're understanding that not every little piece of knowledge some of us want is for applied use.  I don't need to conceptualize string theory.  I want to.  Don't answer the question from the angle "will you use this?", but rather "will this help you understand other languages and how/why they abstracted this more than this other language did?".  You seem to understand C++ pitfalls; learning from mistakes and flaws is often easier than vice versa, regardless of subject.  I'm looking for one (or two, or three) languages to learn that will let me understand what's beneath the abstraction and use it.  You might see it as a waste of time, people that are interested in mechanisms of life, whether it's a cell or a programming language, don't.

To put it simply, I've heard some people recommend learning Lisp because it will help me with computer science and programming in general.  I don't know if this piece of information is accurate or not, or whether there is something else that's better.  Everywhere I go I see conflicting opinions on what's best to learn or start with or expand with.  So rather than look for answers tailored for the general masses, I'm saying what I specifically want.  Why I haven't started at assembly is because (as far as I know), I can't write a fully fleshed out program in Windows with it.  I still intend, eventually, to learn some of it, yes, for no other reason than to understand something I'm interested in, as hard as it is for you to accept. 

All I want to know is what is the least abstract, commonly used language that is above that threshold (being able to create complex programs in a Windows environment).

[Shades]

(And Shades, while I love PHP, recommending anyone seriously learn it is scary. Unless you're already well-trained, PHP inflicts brain damage.)

Your probably right, but it gives some of the grounding you'd get in C that learning C++ won't as well as showing of things like traits and reflection in a way the other languages I listed didn't. I wouldn't recommend someone solely learns it

[Blacken]

Lisp is an exceptional language. It teaches you how to think like a programmer. I recommend it without exception. Python too: because it teaches how to think outside of the framework of the computer. Programmers don't work with computers. Programmers achieve objectives. If you want to dick around with low-level code, C is reasonable--but it's not a good starting point if you have designs on doing more intricate things. In my experience with teaching people, which is pretty considerable, top-down makes more conceptual sense and leads to better productivity faster. (And your snark is funny; I've taught 30-40 people how to program and how to program effectively, and lots of them sounded like you, sneering at the top-down approach--until they saw that it worked. Maybe, just maybe, I know what the fuck I'm talking about.)

If you want to understand that stuff, then the place to start is the Tanenbaum book that I referred to, but it's good primarily as a conceptual resource, not as a how-to on writing code.

Look. I've said it multiple times: top-down results in a conceptually cleaner and more straight-forward way to learn to program. My highest recommendation is to go read the ThinkPython book. If you want to dig deeper after that, go for it! But all I have been fucking saying, although clearly you as a newbie have to know more than me, is that it is a bad place to start. Once you know how to do it right, you can very easily learn how to do it in C++'s flavor of wrong.

(And Shades, while I love PHP, recommending anyone seriously learn it is scary. Unless you're already well-trained, PHP inflicts brain damage.)

Your probably right, but it gives some of the grounding you'd get in C that learning C++ won't as well as showing of things like traits and reflection in a way the other languages I listed didn't. I wouldn't recommend someone solely learns it

C#, sir. C#. (For reflection and the like, anyway. Beautiful system for it.)

[eerr]

@Keyboo

In math, I find Knowing the twiddly bits underneath, like what the fuck happens when you take a derivative to bring me joy because of accuracy, knowledge, and useful interpretations.

While learning C, I find no joy moving closer to the machine level.
(I haven't done anything close assembly or anything, yet I know that could only be more painful.)