Pre-Newbie Programming Question

[boran]

Originally posted by: CTho9305
[...]
The same is not true of C++ - it would be much more difficult to hand-compile C++ programs. Java removes you even farther from the real system by adding stuff like GC, which results in you knowing *nothing* at all about the memory system.
[...]

which is a good thing imho. you'll notice that programming language tend to simplyfy matters more and more for the programmer, the reason therefore is because someone has done it already before you. I'm not exactly C-knowlegable, but I do know a stuct is akin to an object with just properties and no functions. now if you write your memory implementation yourself, why do that, someone has it done before, it might be able to get done better in teh future, in which case they just change that in the back-end where you dont even see or notice it. etc.

but that's just my opinion offcourse. I do think Structured programming is important to know (they teach us cobol for that -uuurgh-) because as you mentioned it's easier to understand what the machine is doing. but I think the role of the top level programmer (the one that makes apps, not operating systems) is to move away from that and see less of the inner workings. and work with an abstraction of a machine.

 

[Armitage]

Originally posted by: Red and black

Originally posted by: Armitage

That's a very limited view of object oriented programming (OOP). Actually, I have no idea what your statementis trying to say?? "Treating things that are different in a uniform manner" I personally find OOP to be a very powerful paradigm.

The question is, what do you mean by OOP then?

Here is a recent post ( by a very skilled person ) to the ocaml beginners' list on the topic:

http://article.gmane.org/gmane.comp.lang.ocaml.beginners/3144

I'll be honest - alot of my code is just "C with Classes" paradigm. But even that is tremendously useful. I'm not of the school where *everything* has to be an object. Inheritance is great when you need it, but in my work it hasn't come up to much.

One example I'm working with now is an astrodynamics simulation. There are lots of ways to represent & propagate orbital data, and this project may have to eventually incorporate quite a few of them. So I wrote an abstract base class to represent the satellites, and I inherit from it for each specific type I need to handle. They all know how to read themselves from the database, pass themselves via PVM, the API is identical, all the different object types can reside on the same vector so you don't ever touch the computational guts of the model, etc.

It makes adding a new data type a snap - a few days tops. Derive a class to wrap up the specifics of that type - ussually some 3rd party code, add a bit of glue to the front end to turn it on, and you're done. Compared to similar C/Fortran procedural code I helped maintain, where adding a new data type was a huge undertaking that got into nearly every part of the code.

The STL is great - but yea, they need to do something to clean up the error messages and provide a cleaner way to work with STL containers in a debugger. The latter is probably more of a debugger issue then a language issue.

 

[itachi]

Originally posted by: CTho9305
I think calling C a low-level language is not unfair, because pretty much nothing goes on that you don't "explicitly spell out" (as Red and Black said). You learn that stuff doesn't just appear when you do "MyFoo bar = new Foo" - you have to understand that you're allocating the memory, and setting up all the members of a struct before you use it. For most C I've written, it would not be hard to translate it line by line into assembly language (this is a key reason why I don't think calling it low-level is bad). If you are comfortable with C, you can pick up assembly language without too much difficult... when I had to do things in assembly on exams, I usually just wrote C and translated it.

assuming 'typedef Foo* MyFoo;' was stated earlier..
MyFoo bar = new Foo; // c++
MyFoo bar = (MyFoo) malloc (sizeof (Foo)); // c
both cases, heap space is allocated by the operating system.. in C, sizeof (Foo) gets pushed onto the stack and malloc is called.. in C++, sizeof (Foo) gets pushed onto the stack and operator new[] is called. you wouldn't know by looking at the statements that the os looks for a block in the free pool, marks the space as being used, removes it from the heap space, and assigns the base address for the block to the page offset, in the page table, that the pointer is pointing to.
when i took a class on assembly.. we were never allowed to use any c function. all input and output was done using kernel calls.. so starting off in c wasn't something that could be done easily, especially when the most i learned about c is how to use malloc, printf, scanf, and such.. not how to write my own.
i'll agree that c puts you closer to hardware than c++ does, but the difference in abstraction between them is nothing compared to the level of abstraction performed by the os, which is what most of the c and c++ standard library functions end up calling ultimately.

 

[Bacardi151]

go with java, it's less complicated than c++, but i would definitely say that whichever one of you choose, you should go with a higher level language , and preferably an object oriented programming language. although it wouldn't hurt if you learned some basics of scheme or lisp, they do. i took a lisp class which limits your everyday coding style, and it forced me to use tail recursion, and now i understand it much better.

but yeah, java should be easier to pick up because it literally takes care of your memory usage with its garbage collector unlike c++ where you have to declare and dispose any memory you've tried to use. it's been a year since i programmed in C++ and i think i already forgot the syntax for the pointers in c/c++

 

[jboschen]

personally i can't stand coding in Java, but it's a preference thing.

now... there's nothing wrong with learning C/C++ first or even assembly. you could argue that assembly is a great starting point because it gives you a truly uncluttered view of the architecture paradigm, and also argue that it's a terrible starting point because it complicates fundamental programming concepts that will make you a better programmer. C offers a level of indirection above that but the same applies, C++ takes it further, 4GL languages even further still.

what i think makes it difficult for people who are getting started is that there is no great way to separate the "programming language" from the "platform services" during the initial learning process. i see the majority of initial confusion starting there. after that it's service issues and rarely language semantics.

in the end, it really depends on how "you" best learn something. if knowing the details of how that "Hello World" text is actually appearing on your screen better helps you grasp the concepts of programming then go for a lower level language. if it adds to the confusion, use one that hides it from you. from experience, i think C is a really great trade off because the language and associated runtime libraries are mature enough to hide a lot of the underlying platform specifics, yet low-level enough that when you need to get into the platform details you can with relative ease. ask a C programmer how cout is implemented for their library and platform, then ask a Java programmer how System.out.println is implemented on the same platform. neither is a "better" answer, but if you want to know that stuff, you'll get a much simpler answer from the C programmer. ask a C programmer how you iterate over a vector of static integers and you'll get nearly the same answer as you would for practically every other language. those are language features, and like spoken language it ends up being syntax. once you know the translation you get the same thing, communication. data and algorithms.

 

[ArmchairAthlete]

Python and VB.NET are both pretty easy to start with. You don't have to jump right into OO, simple syntax, etc. Python even has this nice shell interpreter thing that lets you try one (or a few) lines at a time and see what happens.

But don't spend too long picking one... I don't think you're going to get burned choosing the "wrong" one and you can always try another one later. I've used about a half dozen so far (some much more than others).

 

[Barnaby W. Füi]

Originally posted by: itachi you wouldn't know by looking at the statements that the os looks for a block in the free pool, marks the space as being used, removes it from the heap space, and assigns the base address for the block to the page offset, in the page table, that the pointer is pointing to.

Sure you would. The documentation for malloc() should make it quite clear what it is doing. But in C++, 'new' is a language feature and is a little more magical. Even then, any C++ programmer should understand what it does (to expect a newbie to understand ANY programming language well is just asinine) -- but it's more magical because it does quite a few things. malloc() basically just does one thing.

malloc: "gimme x bytes of memory or NULL if you can't"

new: "gimme enough bytes of memory to hold a Foo, or hey maybe don't allocate it, if I tell you where I have some free memory using this completely retarded syntax. Oh and if you can't get any memory, then throw an exception, or hey maybe if I passed you std::nothrow with yet more retarded syntax, then just return NULL. And if I tell you it's an array, then remember that too. Oh and then construct this object by traversing the class hierarchy, calling the appropriate constructors, oh and don't forget about maybe setting up vtables with pointers to methods, oh and, and and and ..."

 

[Barnaby W. Füi]

Originally posted by: Armitage
The STL is great - but yea, they need to do something to clean up the error messages and provide a cleaner way to work with STL containers in a debugger. The latter is probably more of a debugger issue then a language issue.

I dunno, I think the problem is pretty inherent to how templating works. Whenever I see a compiler/interpreter error message in another language, I can usually say "oh, I can understand why the compiler says that, and it makes sense for the most part." It's not like they did anything magical to come up with the error message. But with templates, that same approach yields these insane error messages. With nested nested nested templates, I can't see how the compiler could hope to turn them into anything that makes sense to a human. I mean, sometimes they're not that bad obviously, but I can't imagine what the compiler could do to make more sense of the bad ones. Maybe I have a bad imagination.