hey guys just searched the forums to see if there is anything and i didn't see anything. So i'm just wondeirng what Code is LFS programmed on? Is it programmed on C++? I'm thinks its programed on C++ but i just want to make sure cause i want to learn how to program a bit just for fun.
Don't do this. C#, Java, Python are all Object Oriented. While there is less to worry about when you're actually coding, it's a lot more complex for a absolute beginner that has no understanding of the Object Oriented design.
Start with Pascal, it's a procedural language and it was designed to be a learning language. Once you gain some proficiency in Pascal go ahead and move onto C++.
Also you could argue it's easier to learn OOP (which you will have to do at some point) if you get a handle on it early, rather than have to make the change from procedural programming at a later date.
There is no correct language to choose as a first language, it's a choice that the person who is learning has to make themselves. As a general rule I'd say to learn something modern, that's actively being developed, has a large community, and is well suited to making the sorts of programs you are interested in.
but I stand by what I said about OOP, trying to teach someone OOP before procedural is like teaching someone the logarithm function before they know how to multiply. (perhaps a bit of an exaggeration , but you get the point).
I also completely disagree with your last statement. There is a right and wrong language when it comes to your first. I would pick something ancient, popular, procedural and not undergoing any development .. . start from the basics and move on up to the modern stuff.
You make a lot of claims, but I see few arguments to actually back them up. Kinda difficult to argue against. Why is learning procedural programming easier than OO when starting out? You've just asserted that it is, with no explanation as to why.
My claim (and DarkTimes'?) is that OO makes it easier to model concepts from the real world, and as such is easier to pick up for someone unfamiliar with computer programming. It's easier to relate to what they already know. You obviously cover functions (procedures) before you teach classes and objects, but I don't agree at all that OO should be omitted completely.
well for one the only semi sensible example any textbook seems to be able to produce is a used car lot... which isnt doing oo any favours
my personal take on oo is that it usually doesnt make a whole lot of sense if youre working on a project alone and the whole point of oo only starts to appear when you try to glue the work of several coders together which with oo should be doable in a block diagram fashion as opposed to procedural which is bound to end up in a mess
maybe its just my lack of coding experience but i get the feeling that the only real advantage of oo is the self containedness of objects which is fairly pointless if you know exactly whats in them
That's a big if though. I have no idea how a lot of the code I wrote years ago actually works nor how it handles its state/data. As time goes by you forget the details, even if you work alone, and it's important that you can once the project reaches a certain size. OO is just a means of abstraction. It's not the One True Way, but it's certainly handy in a lot of cases.
Now obviously you can group state together in structures and make functions that work on these in procedural programming as well, but it's my view that then you're doing OO anyway. Just with less desirable syntax.
OO to me is simply data aggregation; grouping related data together in self-contained objects. I can't even imagine how you'd program anything of reasonable size without it. I realise my definition is a lot wider than most though. I cannot stand the popular notion that "everything's an object", because it's plainly false. Pure OO languages like Java often invent silly classes for abstract concepts like "Math" which are solely used to house standalone functions like sin and cos. How do you create an instance of Math? "I'll have 2 pounds of Math please." It doesn't make any sense.
That's why it's an abstract class containing static methods
Tbh, I don't see what's bad about this. Sure you can't instantiate "Math", but it serves as a nice way to group common methods together. Would you rather import a certain package/namespace and suddenly have all those functions directly available?
But maybe my perspective is just different on this. I'm working on a web based business application with several 100k lines of code, uncountably many business rules and on average five other programmers who work on the same code. I'd rather have everything nicely grouped together than the intellisense exploding with tons of entries because someone needed a math function in one line of code of a business object that is a few thousand lines big. Having all the BO's functions in there is bad enough (though partial classes do help).
Edit to your edit: I don't see how intellisense will react any worse with your_project::math::<list> than Yourproject.Math.<list> (assuming C#)? If it's a public library function intellisense will show it either way. Private functions can still go inside classes where it makes sense of course (or anonymous namespaces in C++), so you won't get clutter from implementation details if that's what you're afraid of. I'm just in favour of calling a spade a spade and sin and cos are standalone functions. They just are. They should not be methods of a class, static or otherwise.
Not having standalone functions in Java is not such a big problem. It is probably because Java classes (in compiled form) are also basic deployable and executable units. At least since version 1.5 you can "import static java.lang.Math.*" and then just use sin(x), cos(x) etc. in your code.