Qbasicnews.com
June 26, 2019, 07:38:33 AM *
Welcome, Guest. Please login or register.

Login with username, password and session length
News: Back to Qbasicnews.com | QB Online Help | FAQ | Chat | All Basic Code | QB Knowledge Base
 
   Home   Help Search Login Register  
Pages: 1 2 [3] 4
  Print  
Author Topic: C/C++, which one first  (Read 17314 times)
Anonymous
Guest
« Reply #30 on: June 04, 2006, 06:18:57 AM »

Yes, I just read lillo's thesis (not all of it, yet) about declarative languages. (prolog is declarative, i believe) Kind of interesting.
Logged
na_th_an
*/-\*
*****
Posts: 8244



WWW
« Reply #31 on: June 04, 2006, 05:29:15 PM »

Declarative languages rock Cheesy LISP (yeah, I know, this is a "functional language", but if fits in what I'm gonna say), PROLOG and CLIPS are simply awesome for some tasks.

I mean, you can create a simple AI which learns stuff from what you say and what it asks in no more than 30 PROLOG lines. Programs that modify themselves, programs that take programs as data and process and modify them... Nice stuff for high-level nerds Cheesy
Logged

SCUMM (the band) on Myspace!
ComputerEmuzone Games Studio
underBASIC, homegrown musicians
[img]http://www.ojodepez-fanzine.net/almacen/yoghourtslover.png[/i
stylin
Ancient QBer
****
Posts: 445


« Reply #32 on: June 04, 2006, 06:19:32 PM »

Quote from: "LooseCaboose"
Like na_th_an said, you can over or under-engineer things in any language. If a large project is becoming difficult to work with because it is structured poorly then switching to OO is not going to magically fix the problem for example. I have seen lots of OO code that has been written by people that don't understand OO concepts.

I think we're getting a bit off-track. My initial point was that when those or any other concepts are used in a language that wasn't designed for them (speaking from the programmers' point of view) the burden of replicating the idiom begins to overshadow the code that matters. Your Lisp story parallels that idea a little.

Quote
I don't believe that OO is the magic bullet that alot of the programming world would have us believe that it is. Different projects suit different languages.

I fully agree, which is exactly why I'd recommend C++ over C for beginning programmers; I think C++ is a better overall learning tool, because it supports concepts in native syntax that make it easier for you to concentrate on design, rather than implementation (of not only OO details. For instance, std::vector let's the beginning programmer think more about what she wants to do with an array, while C forces her into dealing with the often complicated and - at that point - unimportant details about how to make it safe to use, further burdening her with debugging hell when she mis-uses it. I'll throw std::map and std::set in there for some over-the-top examples of something better done in C++, again, from the programmers' point of view).

na_th_an: C++ isn't that "far from assembly" itself, but talking about speed in a thread like this is, I think, a little off-topic. Tongue
Logged

stylin:
NecrosIhsan
Been there, done that
*****
Posts: 1191



« Reply #33 on: June 04, 2006, 07:00:42 PM »

Quote from: "stylin"
C++ isn't that "far from assembly" itself

It isn't? :Huh:
Logged

\__/)
(='.'=) Copy bunny into your signature to
(")_(") help him gain world domination.
stylin
Ancient QBer
****
Posts: 445


« Reply #34 on: June 05, 2006, 03:08:39 AM »

Quote from: "NecrosIhsan"
Quote from: "stylin"
C++ isn't that "far from assembly" itself

It isn't? :Huh:

It isn't as far as a novice programmer should think about it.
Logged

stylin:
na_th_an
*/-\*
*****
Posts: 8244



WWW
« Reply #35 on: June 05, 2006, 03:44:11 AM »

I just see how people around here are learning C++ and... they are not learning OOP C++. They are learning "C plus classes" which, IMHO, is a bad thing. I can tell this from the code snippets that are posted around here all the time. You get procedural code with C++ syntax and shortcuts.
Logged

SCUMM (the band) on Myspace!
ComputerEmuzone Games Studio
underBASIC, homegrown musicians
[img]http://www.ojodepez-fanzine.net/almacen/yoghourtslover.png[/i
NecrosIhsan
Been there, done that
*****
Posts: 1191



« Reply #36 on: June 05, 2006, 09:47:25 AM »

Quote from: "na_th_an"
I just see how people around here are learning C++ and... they are not learning OOP C++. They are learning "C plus classes" which, IMHO, is a bad thing. I can tell this from the code snippets that are posted around here all the time. You get procedural code with C++ syntax and shortcuts.

That's not necessarily a bad thing though. Most coders here are probably more used to procedural coding, so procedural C++ makes more sense to them. They may not be "taking full advantage" of C++, but realistically, who does? It's the end product that matters anyways...the end justifies the means.
Logged

\__/)
(='.'=) Copy bunny into your signature to
(")_(") help him gain world domination.
Radical Raccoon
I hold this place together
*****
Posts: 914



WWW
« Reply #37 on: June 05, 2006, 12:59:51 PM »

OOP is just an overrated term anyways. Basically it's still procedural (one thing happens after another).

Learning OOP and C++ are 2 different things. When I first started learning C++, I had to learn the syntax, classes, and then about pointers. Once you get that down, then understanding the concept of OOP becomes more easy and you begin to take advantage of it. That's probably why all you see is people learning "C plus classes." Because taking on the whole new language is big enough, learning OOP is further down the road. Anyway, procedural code with classes is still a nice thing IMO.
Logged

na_th_an
*/-\*
*****
Posts: 8244



WWW
« Reply #38 on: June 05, 2006, 03:10:26 PM »

That's the #1 reason why there's so much shitty code to maintain everywhere.

I work developing new software, but of course sometimes I have to maintain, expand old software already in use. Well, people code like crap. That's the thing. If people learned OOP properly, my life would be ten times easier.

The problem in all these discussions is that people here always think about the latest bedroom game they are coding. I'm talking about big projects, with 20 people involved. Now tell me how good designed OO isn't a must. 'Cause it is.

My claim is that, if you want to master the procedural paradigm, go for a procedural language such as C, Pascal or BASIC. If you want to master the OO paradigm, then try Java or proper C++. Don't mix things.

Radical Racoon: you're wrong. OOP aint' procedural. You are mixing therms, I think you mean "imperative". Procedural comes from "procedures". In OOP you don't have procedures. You have things that look like procedures but are NOT procedures. See? That's the problem! People have the concepts completely messed up and that's why there's so much crappy C++ coding around.

I'm not telling you that you code bad, I'm just talking big words for big scale projects. I think that you, at home, can code as shitty as you want (heck, I DO!), but, at least, you must know how to do things properly.
Logged

SCUMM (the band) on Myspace!
ComputerEmuzone Games Studio
underBASIC, homegrown musicians
[img]http://www.ojodepez-fanzine.net/almacen/yoghourtslover.png[/i
Radical Raccoon
I hold this place together
*****
Posts: 914



WWW
« Reply #39 on: June 05, 2006, 03:17:49 PM »

Procedures are subs, functions, methods, aren't they?  :Huh:

The only difference (from my current knowledge) is that in C++ classes 1 procedure is created per instance (unless it's static) whereas only 1 procedure exist in procedural code the whole time and does not belong to any specific structure. But please let me know if there's more.

Still, I wouldn't blame that issue for the main cause of bad code. Bad code has many more other influences than just that (bad team coordination, source control, just plain sucking, etc.). Not that learning the proper concepts wouldn't help or anything, just saying.
Logged

Anonymous
Guest
« Reply #40 on: June 05, 2006, 04:22:14 PM »

I think what na_th_an is saying is that good c++ ISNT procedure/method based. methods are just one aspect of OBJECT-based programming, which is what you really should focus on with c++.


Seriously, "bad code" doesn't happen from bad management, that's the point of OOP. You could design an object completely autonomous from other objects, and it will interface exactly the same with anything that calls it, or that conatins it through composition.

Sure you can write macro hacks and whatever to simulate it but, the point is the capability is BUILT IN through OOP, and that's the point, to save you time from doing the same pointless crap over and over and over and over.
Logged
na_th_an
*/-\*
*****
Posts: 8244



WWW
« Reply #41 on: June 06, 2006, 04:09:39 AM »

The difference is that a program coded in a procedural languages is made of procedures which call other procedures plain and simple. A program in an OO language is based on objects which produce other objects. Of course, at the end of the day, it's all about code you call to be executed - but it's the way you think what should be different. If you consider a OO program as a sequence of instructions and procedure calls (well, object method calls) you are missing the OOP paradigm completely, you are getting that "C + classes" I was talking about, not OOP.

There's a whole layer of abstraction you must adhere to and respect. The whole purpose of OOP is abstraction. "Work with black boxes you know what they take and what they produce, but not "how" - 'cause it doesn't matter". You usually work just using design patterns and combining them. The focus of OOP is getting a project composed by many parts in which you can replace any of those parts without affecting the rest of the system. Getting your things done in a way you can expand functionality without having to change a line. You know, just like when you install a plugin - you don't have to recompile the main program (well, at least if you are not using Linux :lol:) - in the same way you should be able to add functionality without having to "make room for it" in your existing code.

In OOP you have to think about interfaces. In a procedural language, when you call a procedure, you know which bit of code you are calling. In an OO language, you get an object and call to a method of its interface - but you don't know which bit of code it's running. Maybe you are processing a list of objects that are "geometrical" and you are just calling a "rotate(45)" to rotate each one 45 degrees right. But each object could be in fact a rectangle or a triangle, or a circle or a hexagon - each one with its own "rotate" method. You want your program the ability to process squares as well? Just add a new class "square" which implements the interface "geometrical" (this is - it gives an implementation to each method described in the interface) and you are done. Now there's support for squares. Nothing to be done in the other side.

If people understood OO correctly and coded it in the proper way, I would have no problems expading existing applications - but right now I'm stuck in the middle of a huge pile of shit Cheesy everytime I touch something, another one gets broken!! AAAAARGGGHHH!!! (sorry, needed this rant - I'm overwhelmingly fed up with my current task at work).
Logged

SCUMM (the band) on Myspace!
ComputerEmuzone Games Studio
underBASIC, homegrown musicians
[img]http://www.ojodepez-fanzine.net/almacen/yoghourtslover.png[/i
Jofers
Been there, done that
*****
Posts: 1040



WWW
« Reply #42 on: June 07, 2006, 08:54:33 AM »

C.  There's something to be said for a language that's used to program every major operating system.  It's fundamentally important to learn because it's as close as you can get to the hardware in a high-level language.  I had to work in the spring with a guy who had learned C++ and not C on a C project.  It was a disaster, he couldnt figure out printf, couldn't handle strings, had trouble with pointers.  You have to learn core programming concepts in C before you tackle the abstract stuff, it's for your benefit.

That doesn't mean don't learn C++, as it is very featureful and useful, but if you're serious, then learn C first.
Logged
na_th_an
*/-\*
*****
Posts: 8244



WWW
« Reply #43 on: June 07, 2006, 09:35:36 AM »

Listen to the yellow peanut, he's wise!

I agree 101% with Jofers.
Logged

SCUMM (the band) on Myspace!
ComputerEmuzone Games Studio
underBASIC, homegrown musicians
[img]http://www.ojodepez-fanzine.net/almacen/yoghourtslover.png[/i
Radical Raccoon
I hold this place together
*****
Posts: 914



WWW
« Reply #44 on: June 07, 2006, 11:24:04 AM »

Quote from: "na_th_an"
The difference is that a program coded in a procedural languages is made of procedures which call other procedures plain and simple. A program in an OO language is based on objects which produce other objects. Of course, at the end of the day, it's all about code you call to be executed - but it's the way you think what should be different. If you consider a OO program as a sequence of instructions and procedure calls (well, object method calls) you are missing the OOP paradigm completely, you are getting that "C + classes" I was talking about, not OOP.

There's a whole layer of abstraction you must adhere to and respect. The whole purpose of OOP is abstraction. "Work with black boxes you know what they take and what they produce, but not "how" - 'cause it doesn't matter". You usually work just using design patterns and combining them. The focus of OOP is getting a project composed by many parts in which you can replace any of those parts without affecting the rest of the system. Getting your things done in a way you can expand functionality without having to change a line. You know, just like when you install a plugin - you don't have to recompile the main program (well, at least if you are not using Linux :lol:) - in the same way you should be able to add functionality without having to "make room for it" in your existing code.

In OOP you have to think about interfaces. In a procedural language, when you call a procedure, you know which bit of code you are calling. In an OO language, you get an object and call to a method of its interface - but you don't know which bit of code it's running. Maybe you are processing a list of objects that are "geometrical" and you are just calling a "rotate(45)" to rotate each one 45 degrees right. But each object could be in fact a rectangle or a triangle, or a circle or a hexagon - each one with its own "rotate" method. You want your program the ability to process squares as well? Just add a new class "square" which implements the interface "geometrical" (this is - it gives an implementation to each method described in the interface) and you are done. Now there's support for squares. Nothing to be done in the other side.

If people understood OO correctly and coded it in the proper way, I would have no problems expading existing applications - but right now I'm stuck in the middle of a huge pile of #*&$ Cheesy everytime I touch something, another one gets broken!! AAAAARGGGHHH!!! (sorry, needed this rant - I'm overwhelmingly fed up with my current task at work).

C++ is still a sequence of instructions and method calls. That's how you build the classes. You have a sequence of instructions inside you methods that execute the method. No, you don't have to know which bit of code you are calling to use it, but to make you're own yes. You don't have to really know what's inside a procedure call either to use it, just as long as you know what it's for and what it's suppose to take in. It's never 100% abstract, because at some level you have to instantiate the first class, then call it's method, etc. But aren't you trying to reach the same objective with C? When you code a C procedure don't you want to have it to where the person who is calling it doesn't have to worry about "how" the procedure works, just what it's supppose to takes and what it's suppose to do? That's why I liked moving from QB to C++, because I could implement that concept better with an OOP language. Still, it didn't save me (if you suck, you suck). I haven't been able to finish a game in it because I did infact mix the concepts, creating messy and unmanageable code, but I did eventually learn (maybe not perfect yet, but getting there Wink). So if learning C can save you from that hassle, then I guess it's the way to go. But the conclusion we've all come to is that learning the proper programming concepts is more important than the language itself.

Since we are speaking of C, where can I find some good compilers for it?  :wtnod:
I have Visual Studio 2003, but that only allows for C++ and C# programs as far as I know.
Logged

Pages: 1 2 [3] 4
  Print  
 
Jump to:  

Powered by MySQL Powered by PHP Powered by SMF 1.1.21 | SMF © 2015, Simple Machines Valid XHTML 1.0! Valid CSS!