Hard Light Productions Forums
Off-Topic Discussion => General Discussion => Topic started by: MicroPsycho on September 07, 2005, 08:21:59 pm
-
Alright, I finished my second day of school today and Grade 12 Programming was one of my courses. I learned that we will be able to choose a programming language that we would like to learn individually. So my question is this, what is a good/useful/practical language to learn? I want something I can use to code PC games, so nothing like java, html or whatever, as I'll probably learn those in grade 11 anyway.
-
no Java, eh?
why not?
-
Bobbau better answer this one.
-
C/++.
PHP, Java, and Javascript all have similar syntax, as well as (obviously) C#. It's crossplatform and most of the fundamentals you learn will carry over into other languages, even if they have significantly different syntax.
I also wrote a C quickreference/primer/condensed crash course on this page, so you can get a feel for the major elements and a little of the syntax.
http://dynamic.gamespy.com/~freespace/fsdoc/index.php?pagename=CodingInC
Hopefully it's not so condensed that it scares you away :nervous:
Whatever you do, don't pick Scheme.
-
go C/C++ so you can help with the SCP. But if you start on COBOL, i'll find out where you live and murder you ;)
-
c/c++ is what you want, if you do have a choice, it is a bit tough for a first language though.
Basic as slow as it is, would be more practical (than horid relics like COBOL and FORTRAN) as visual basic is used comercaly to this day, but it's crapy _CRAPY_ for games.
if there is a c++ class take it, you'll need to learn c as a prerequsite for c++ anyway so you won't miss anything, and you won't pick up any bad habits from the older style.
-
Lisp. Or Nautilus.
-
Start with C. Then maybe C++. Make sure to learn assembly somewhere along the line, if only to understand the C better. If you're into making games for handhelds or the web, Java would actually be useful.
-
Schools these days tend to like the OO approach, so I'd say your best bet is probably C++. Plus, actually finding a course on C programming will be difficult at best, and the differences really aren't all that great with how far you'll get in a year of coursework. C is a better foundation to have, but it just may not be possible.
-
C++ and Java to begin with, then take a look at C#. It's similar to Java in many ways but it's not as 'clean' a language. However, it's very good for getting stuff working quickly.
For games, C++ is still the language of choice and probably will be until computers run Java/.NET bytecode natively. Any language that requires a virtual machine is by definition slower than a language compiled to native machine code, and games need speed.
Knowing Assembly code is very valuable in games programming. Despite the popular view of Assembly as being unnecessarily low-level and complicated, it is still used in games to squeeze more speed out of complex loops. Also, a solid understanding of the hardware and OS helps you write better, faster, more robust code even if you don't actually write any of it in Assembly.
For the record, HTML is not a programming language. It's a markup language. Essentially, making an HTML document is no different from using MS Word. The only real difference is that you have to enclose text in <i></i> instead of Ctrl-I to get italics...
-
Originally posted by MicroPsycho
Alright, I finished my second day of school today and Grade 12 Programming was one of my courses. I learned that we will be able to choose a programming language that we would like to learn individually. So my question is this, what is a good/useful/practical language to learn? I want something I can use to code PC games, so nothing like java, html or whatever, as I'll probably learn those in grade 11 anyway.
C/C++ for games. C in particular is also well suited for learning low level embedded coding (along with something like MIPS assembler; I think the motorola 8-bit chips making up the majority of EmbSys use that-?).
Java is better for mobile applications (distributed systems, mobile code, portable apps, middleware systems) IMO; it's more portable, probably easier to learn, but less optimiseable (I think it's also more of a true OO language than C++, which was an extension of C minus some of the old UNIX specific operators, IIRC). You can write games in Java (i.e. using the OpenGL or OpenAL bindings), but it's simply not as suited for fast code as C/C++.
HTML isn't a programming language (and you'd be better off learning XML and the associated standards like XSLT than it anyways, as HTML 4.01 or so is now an XML substandard).
-
I knew html wasn't a true language, but I forgot that it was known as a mark-up language.
I'm starting to learn Java in Grade 11 programming, as I suspected I would.(I'm taking grade 11 and 12 programming at the same time)
It sounds like I should go with C/C++ but what are some other codes used in games so i can check them out?
btw, anyone know what Doom 3 is written in?
-
C++.
Functional languages like Haskell and Prologue aren't used for games because... well... they're just not suitable for it.
Among the remaining languages, modularity, flexibility, simplicity, efficiency, and sheer speed are the primary criteria. C/C++ fulfill these very well and are old enough to be widely known.
Delphi/Pascal is sometimes used for smaller projects, as is BASIC. But larger projects are almost exclusively C/C++.
-
C and its successors (C++/Java/C#, depending on what you want to do with the code) are really the only widely-used programming languages in existance today. Some people still cling to Visual Basic and other, older languages for the simplicity, but no one considers them decent choices for writing fast programs.
-
Doom 3 would be C++ and IIRC OpenGL. I think the sound & physics code is proprietary (rather than, say, OpenAL and Havok).
AFAIK there's no other language widely used in mainstream (i.e. major or even medium scale titles) coding. However, some other languages are used for scripting purposes.
-
C/C++
Java is a good learning platform, but its not nearly as powerful or useful.
-
>>Java is a good learning platform, but its not nearly as powerful or useful.
:wakka:, that definitly was a good one.
Why does everyone think Java is slow? On low-level and numeric, ist even much faster than C/C++.
-
Originally posted by LtNarol
C/C++
Java is a good learning platform, but its not nearly as powerful or useful.
I think that's a little unfair. It's powerful in different ways; whereas C++ allows access to the underlying hardware, Java has advantages in terms of dynamic code (i.e. moving programs between different physical machines whilst running). I certainly wouldn't class Java as a 'learning platform' language; to me that'd be fundamentally misunderstanding the application areas it's most used in.
In fact, I think it'salso idiotic to characterise the 'usefulness' of any language in that way; it assumes both complete universal knowledge of applications, and of future development channels.
It's also worth noting Java is a far younger language than, say C++; it's still very much in a maturation stage. Given that it's by nature a higher (abstraction) level language, it's unfair to assume there is no prospect of the languages problems (especially performance wise) being solved. I think the use of dynamic recompilers and straight up compilation alongside the JIT compiler has already had an impact. It's also IMO dangerous to assume the more useful abstractions of Java - such as automatic garbage collection and memory re/allocation - make it 'weaker' simply because they remove a programming burden present for C/C++.
It's simple horses for courses.
EDIT; it's also worth noting there is no requirement for an application to be written solely in one language.
-
Because we're inately talking about graphical applications here. Java's dependancy on a virtual machine, no matter how optimized its bytecode is, fails pretty miserably in comparison when making system-dependent calls to graphics packages. Java is never faster than properly optimized C/C++ either, if just because its garbage collection eats cycles that you could easily avoid with proper memory allocation.
EDIT: One normally doesn't care much about the speed of memory management in a strictly computational, low-level environment, and so it is rarely optimized to that end. That's where Java's apparent strength lies; it allows you to write more complex non-graphical programs, especially from a beginner perspective, without actually needing to worry about closing up all of your memory leaks.
-
Originally posted by StratComm
Because we're inately talking about graphical applications here. Java's dependancy on a virtual machine, no matter how optimized its bytecode is, fails pretty miserably in comparison when making system-dependent calls to graphics packages. Java is never faster than properly optimized C/C++ either, if just because of its garbage collection.
But graphical applications are a very small subset of all applications, which is my entire point. In fact, graphical engines are a subset of the requirements for games, too.
IMO it's probably most valuable in any situation to have an understanding of the design principles rather than a specific language fluency.
Albeit I believe Java graphics performance is signficiantly improving thanks to DirectX / OpenGL bindings (through several methods IIRC; including direct interface bindings and the Java3d APIs); whether or not it can attain an acceptable performance vis-a-vis C/C++ is a different matter, of course. (The JOGL binding API is unfortunately pretty poorly documented at present, natch, so I'm not sure if direct comparative work has been done)
I would agree that Java is slower, but IMO that would be beside the point - my personal attraction to Java is the portability. Not so much in terms of moving between different platforms, but in terms of mobile running code. I think that will be of major use in future, and I'm not sure C++ is as suited - AFAIK all the major mobile agent programs/frameworks use Java (albeit in some cases also a modified VM in order to allow persistant state between transfers).
EDIT; actually, this is interesting. I'd still venture that C/C++ is more innately optimizable (despite my limited experience in both of those), but I never realised the apparent closeness.
http://www.idiom.com/~zilla/Computer/javaCbenchmark.html
http://www.javaworld.com/javaworld/jw-02-1998/jw-02-jperf_p.html
http://www.tommti-systems.de/go.html?[url]http://www.tommti-systems.de/main-Dateien/reviews/languages/benchmarks.html[/url]
Originally posted by StratComm
EDIT: One normally doesn't care much about the speed of memory management in a strictly computational, low-level environment, and so it is rarely optimized to that end. That's where Java's apparent strength lies; it allows you to write more complex non-graphical programs, especially from a beginner perspective, without actually needing to worry about closing up all of your memory leaks.
I'm not sure what you mean. Obviously the speed of memory management and the efficacy of memory use is critical in low-level situations, particularly with embedded C coding; if you mean that Java isn't suitable for that because it doesn't have an optimizable garbage collection system (i.e. slower), then I agree; I'd always prefer a low level control of memory allocation on sparse or efficiency crucial environments.
My point is that the lack of garbage collection / pointer tracking responsibilities for the programmer should not be regarded as a 'deficiency' in the usefulness of Java, but a difference. Same for much of the differences between languages; Java is slow due to an abstraction layer, but it's more - natively - portable in both a static and dynamic sense. (Obviously you can port C++, but AFAIK you'd have to either make hardware level optimization changes, or ignore that very benefit to make the code portable. and even if you use libraries to abstract that, there's still the issue of how many platforms all those libraries cover - especially with small mobile systems)
-
Originally posted by aldo_14
IMO it's probably most valuable in any situation to have an understanding of the design principles rather than a specific language fluency.
Exactly. This really is the underlying principle behind learning any programming language anyway. Especially since the modern languages (C++/Java) have remarkably similar syntax and moving between them is not difficult at all.
Originally posted by aldo_14
Albeit I believe Java graphics performance is signficiantly improving thanks to DirectX / OpenGL bindings (through several methods IIRC; including direct interface bindings and the Java3d APIs); whether or not it can attain an acceptable performance vis-a-vis C/C++ is a different matter, of course. (The JOGL binding API is unfortunately pretty poorly documented at present, natch, so I'm not sure if direct comparative work has been done)
I would agree that Java is slower, but IMO that would be beside the point - my personal attraction to Java is the portability. Not so much in terms of moving between different platforms, but in terms of mobile running code. I think that will be of major use in future, and I'm not sure C++ is as suited - AFAIK all the major mobile agent programs/frameworks use Java (albeit in some cases also a modified VM in order to allow persistant state between transfers).
That's just it, Java as a language was developed specifically with portability in mind, which is why that's the area in which, as a language, it excels hands down. But that's also a tradeoff as you're compiling to bytecode and you have to run through a translator as opposed to directly on hardware. It's different, and it's the applications, not the language, that makes one more ideal than the other.
-
Originally posted by StratComm
Exactly. This really is the underlying principle behind learning any programming language anyway. Especially since the modern languages (C++/Java) have remarkably similar syntax and moving between them is not difficult at all.
That's just it, Java as a language was developed specifically with portability in mind, which is why that's the area in which, as a language, it excels hands down. But that's also a tradeoff as you're compiling to bytecode and you have to run through a translator as opposed to directly on hardware. It's different, and it's the applications, not the language, that makes one more ideal than the other.
:nod:
Exactly my point :)
I just don't like the sweeping generalization of the language as 'less useful', any more than a C++ programmer would like it being done of their specialism.
-
I wish they still had C++ classes at my university. They removed the C++ classes altogether last semester and use Java exclusively now, so I'm doing a Java class. I think the college board (the people who run the AP program) switched to Java a few years ago and most of the universities are just following them.
I know some C/C++ but only enough to make small math computation programs (for which Fortran and assembly are overall a bit better), not games or anything like that. Maybe I'll try picking it up on my own later on.
-
It's also worth pointing out the inherant security aspect of Java. Buffer under/overruns are a very large and often easily exploitable hole in many poorly written C programs (And they're even found in good ones where they just happened to slip through).
The problem is virtually non-existant in Java due to the fact that a Java array knows exactly how big it is and refuses to let you write beyond it's end.
As Aldo says it's a case of choosing the best language for what you're doing. To say Java isn't as useful as C++ is like saying a boat isn't as useful as a car. If you're trying to sail on an ocean you're not going to get far in the car.
-
Originally posted by aldo_14
Doom 3 would be C++ and IIRC OpenGL. I think the sound & physics code is proprietary (rather than, say, OpenAL and Havok).
AFAIK there's no other language widely used in mainstream (i.e. major or even medium scale titles) coding. However, some other languages are used for scripting purposes.
So OpenGL is another language, or is it code to be used within C++/Java? Would this be similar with DirectX aswell?
If I choose C++, which is very likely, I'll probably try to work on the SCP in class...
-
OpenGL (like D3D) is a set of graphics libraries that reference your drivers (or a software implimentation in the OS itself), not a language.
-
Choose Python (http://www.python.org). You can never go wrong with Python. It is simple, logical and beautiful. Its readable. Its interactive and thus discoverable. It's portable and free. It'll teach you basic logical constructs and more advanced concepts (like objects). It is extensible and embeddable. Once you understand it you can apply that knowledge to other languages.
Follow that with C++ (if you grok C++, you will grok C).
-
Allow me to rephrase:
Java is a good learning platform because of its consistency and documentation, its also far easier to learn than C++ or C.
C++ and C are more 'useful' in that they are more geared (at present) to most applications an entry level student creates. Suppose you get a large project for a semester and decide you want to take it to the next level afterwards. Java is particularly good for entry level graphics aps, but not so if you're trying to develop your own permutation of whichever data structure.
I'm not saying Java sucks, because I still use it, but there are annoying limits once you get into optimization.
-
To add to mik's point, languages like python (ruby (http://en.wikipedia.org/wiki/Ruby_programming_language) too) are nice because they can be easily mixed and matched with modules written in C. So if a component needs more performance or lower-level functions, you can write that part in C.
-
Originally posted by aldo_14
The JOGL binding API is unfortunately pretty poorly documented at present, natch, so I'm not sure if direct comparative work has been done
:wtf: Undocumented? The API is almost call-for-call identical to the C OpenGL API, for which there is adequate documentation! OK, so there are a few gotchas (like buffers having to be in native byte order) but anyone who knows the first thing about calling native code will have no trouble.
Originally posted by mikhael
if you grok C++, you will grok C
Not true. It is possible to write C in C++, but it isn't usually done. C++ uses a more abstract view of the machine, makes heavy use of objects, and avoids pointers.
C is a linear, procedural language at heart. C functions are file-global.
C++ is an object-oriented language. C++ functions are usually object-global.
C is a different paradigm. The language grammar is the same, but programming methods changed a lot between C and C++.
-
I'd recommend that you take the opportunity to take classes on C, C++, or Java if you are at all interested in game programming. Python - since it's technically a scripting language - isn't as widely used. Plus, the other languages are more well-established. So there'll probably be better/more extensive classes on them.
Also, Python is a piece of cake if you know C/++.
From your first post it looks like you're still in High School :eek2: so I would guess that your choices will be fairly limited.
Overall, if you're faced with a choice between learning C and C++, I would vote C++. It's much more difficult to fully understand, but it is what's used for most games these days, and all of the fundamentals to it are common to C.
-
Originally posted by Descenterace
:wtf: Undocumented? The API is almost call-for-call identical to the C OpenGL API, for which there is adequate documentation! OK, so there are a few gotchas (like buffers having to be in native byte order) but anyone who knows the first thing about calling native code will have no trouble.
That's the problem; there is no documentation of the differences. I've been trying to write a little program for a while now, but there is (for example) absolutely **** all information available on how to actually form a ByteBuffer of rasterized pixel data (i.e. the precise ordering pattern for pixels).
As it stands, it'd probably be easier for me to learn C++ and OpenGL (which is what I was doing before, till I started work) than to learn JOGL; which is exactly what I mean. There is sod all javadoc documentation (virtually all of the commentary for GL methods is 'Interface to C language function:'), and there is little by way of tutorials. That's an access barrier.
-
The data structures are identical to those used in a C program. The solution to your problem is documented. I wrote a 3D engine on JOGL a few months ago; everything required to do that is documented, albeit in C.
The problems I had regarding threading and GLCanvas objects were mainly due to my own lack of experience in dealing with multithreaded apps.
I assume 'rasterised pixel data' means textures in this case. So basically you need to turn an image into an array of pixel colour values, right? Yeah, that is a bit of a sod in Java; no one ever thought it would be necessary to handle an image as anything other than an object... Shortsightedness of the worst kind.
*digs out the HyperDrive OGL abstraction layer*
Pixels are stored in row-major order, and each one is a quadruple of either bytes or floats depending on the texture format you've selected. Remember to set the byte order of any buffer handling non-'byte' values to ByteOrder.nativeOrder() before writing the pixels to it, or you'll end up with some really weird, frustrating bugs.
You can use a PixelGrabber to get pixel data out of a BufferedImage object in TYPE_INT_RGB format, then do some byte-twiddling to fill a byte array. The PixelGrabber will fill an array of ints, one per pixel. Each int consists of the four colour elements in ARGB order (alpha being the most significant byte). If you like, I'll PM you some code to do the conversion.
OpenGL normally takes pixel colour values in RGBA order. Plus, if you're using buffers that store 'float' colour values, you're probably in for a world of pain.
Most of JOGL's problems are less to do with a lack of Java-specific documentation and more to do with a lack of tools for converting objects to raw data.
-
Alright, next question, what's a good program to use for writing and compiling C++?
-
GCC, the GNU C Compiler (http://gcc.gnu.org/)
Eclipse, a modular multi-language IDE. Supports C++ with a plugin. Written in Java. (http://www.eclipse.org/)
DevC++, a free IDE (http://www.bloodshed.net/devcpp.html)
Vim, an editor that lets you edit madly fast (http://www.vim.org/)
You can also look at this Wikipedia article (http://en.wikipedia.org/wiki/List_of_integrated_development_environments) for more choices.
-
most people use some form of MSVC, but it costs money, and is windows only, and doesn't follow everything perfictly in some usualy minor details.
-
And it doesn't come with the standard libraries; it comes with the Microsoft standard libraries. That means that you start to rely on functions which the ordinary POSIX-compatible libraries don't provide.
Yes, it happened to me.
I'd recommend getting used to command line development, then moving onto an IDE once you're familar with the construction of Makefiles.
Yay, Vim! My favourite *n[iu]x editor! But I use SciTE for coding, since I know Vim's commands just about well enough to insert/change text and save the file.
-
Originally posted by Descenterace
The data structures are identical to those used in a C program. The solution to your problem is documented. I wrote a 3D engine on JOGL a few months ago; everything required to do that is documented, albeit in C.
The problems I had regarding threading and GLCanvas objects were mainly due to my own lack of experience in dealing with multithreaded apps.
I assume 'rasterised pixel data' means textures in this case. So basically you need to turn an image into an array of pixel colour values, right? Yeah, that is a bit of a sod in Java; no one ever thought it would be necessary to handle an image as anything other than an object... Shortsightedness of the worst kind.
*digs out the HyperDrive OGL abstraction layer*
Pixels are stored in row-major order, and each one is a quadruple of either bytes or floats depending on the texture format you've selected. Remember to set the byte order of any buffer handling non-'byte' values to ByteOrder.nativeOrder() before writing the pixels to it, or you'll end up with some really weird, frustrating bugs.
You can use a PixelGrabber to get pixel data out of a BufferedImage object in TYPE_INT_RGB format, then do some byte-twiddling to fill a byte array. The PixelGrabber will fill an array of ints, one per pixel. Each int consists of the four colour elements in ARGB order (alpha being the most significant byte). If you like, I'll PM you some code to do the conversion.
OpenGL normally takes pixel colour values in RGBA order. Plus, if you're using buffers that store 'float' colour values, you're probably in for a world of pain.
Most of JOGL's problems are less to do with a lack of Java-specific documentation and more to do with a lack of tools for converting objects to raw data.
I think that's what I need. The problem I had was that, when I finally got the image ready, it was displaying as wholly translucent; .e. it was 'merged' with a the draw colour (I was drawing 2d; but using a textured polygon rather than drawSquare or whetever the method name is). IIRC it was a PNG image.
Originally posted by Kamikaze
GCC, the GNU C Compiler (http://gcc.gnu.org/)
Eclipse, a modular multi-language IDE. Supports C++ with a plugin. Written in Java. (http://www.eclipse.org/)
DevC++, a free IDE (http://www.bloodshed.net/devcpp.html)
Vim, an editor that lets you edit madly fast (http://www.vim.org/)
You can also look at this Wikipedia article (http://en.wikipedia.org/wiki/List_of_integrated_development_environments) for more choices.
I've not tried the C++ plugin, but as a native Java IDE Eclipse is absolutely superb.
-
Originally posted by Descenterace
Not true. It is possible to write C in C++, but it isn't usually done. C++ uses a more abstract view of the machine, makes heavy use of objects, and avoids pointers.
C is a linear, procedural language at heart. C functions are file-global.
C++ is an object-oriented language. C++ functions are usually object-global.
C is a different paradigm. The language grammar is the same, but programming methods changed a lot between C and C++.
C++ avoids pointers? Don't tell... well anyone.
When you say "C functions are file-global" and "C++ functions are usually object global", you hurt my brain. Non-class functions (IE functions written outside of classes) are file-global in C++, exactly as in C. C++ is C with slightly tighter typing, language level support (rather than stylistic support) for object orientation.
Better to say, Stroustroup says himself, that C++ is a superset of C.
-
Yeah, C++ can do what C does, so it is a superset, but the point is that it introduces a whole load more things which make the messier C coding constructs unnecessary. I haven't seen much C++ code that uses file-global functions.
C++ introduces references. Unless you're calling old library code, pointers become unnecessary for the everyday. It is nice to have the option of using them when they are required, though.
Aldo, I think there's a rendering setting which ignores alpha entirely and simply draws the texture as a decal. It sounds like you've already got the image loading OK (a task that took me well over a week to make work correctly; btw, if you want a PCX loader, I've got one that works with 24-bit PCX files).
glDisable( GL_BLEND ) should do it, or you can use glBlendFunc to set source factor to GL_ONE and destination to GL_ZERO.
Have a look at glTexEnv too. It can control blend settings, but I think it's only important if you're trying to blend colours.
-
References are cute, but they lead to rather difficult-to-debug problems sometimes. Most of the professional programmers I know stick to pointers. Besides, you can't do half the nifty, speedy tricks on references that you can with pointers.
That is beside the point however. The point is that if you grok C++ you can grok C.
-
To be honest, I prefer pointers to references.
There's one type of C++ code I've seen which is written very much like C (besides using classes to encapsulate some functions): Mine.
Doesn't half piss off the lecturers when I put most of my functions outside classes. Not as much as writing C++ in C does, though.
I love emulating polymorphism and virtual functions in C.
-
As Stroustroup said in the gray book: anyone writing very good C code is already writing C++.
-
But although using function pointers in structs to emulate polymorphism is basically how a C++ compiler does it, the expectation is that you actually use an OO language for it...
Uni lecturers don't like seeing the implementation.
-
I don't know. My uni instructor loved it. I was basically using OO methodology through the use of structs and carefully written functions, kept tightly bundled with the structs. It works out to the same thing in the end. As they man said (well, he didn't but its close enough), "Any sufficiently well written C is indistinguishable from C++."
Now, when I started using unions, I got in hella trouble.
-
Yeah, that's another thing mine hate.
My current project (not a Uni project, thankfully) makes use of unions to enhance readability.
I'm serious. Enhance readability.
It's either unions or excessive numbers of buffer access functions. I'm emulating the registers of an x86, which means having _AL, _AX and _EAX overlapping.
-
I gave my final exam today. I don't wanna hear any more OO non sense... :devil: (btw, i got a 30 in my Software Engineering exam even if i presented a project who didn't use it one bit... but that's another story)
There's only one advice i can really give you: DON'T stick to a particular language. You never know what will come trough your way.
As those who love OO (or EXtreme Programming, call it whatever you want) would say, be "flexible". That's the only important thing. And don't forget, whatever decisions you make, to motivate them. That's the difference between an Engineer and a CodeMonkey.
Just my 2 cents.
*goes out and celebrates his degree*
-
OO and XP are different things. Object Oriented programming is a methodology related to (at its most basic) data hiding. Extreme Programming (XP) is about having two sets of eyes on the code at all times, working through it with four eyes, four hands and two brains.
One is scary and the other is frightening. I'll let you choose which is which.
Originally posted by Descenterace
Yeah, that's another thing mine hate.
My current project (not a Uni project, thankfully) makes use of unions to enhance readability.
I'm serious. Enhance readability.
It's either unions or excessive numbers of buffer access functions. I'm emulating the registers of an x86, which means having _AL, _AX and _EAX overlapping.
That gives me a geeky giggle. :D
-
Originally posted by mikhael
OO and XP are different things. Object Oriented programming is a methodology related to (at its most basic) data hiding. Extreme Programming (XP) is about having two sets of eyes on the code at all times, working through it with four eyes, four hands and two brains.
Actually, Extreme Programming (look here: http://en.wikipedia.org/wiki/Extreme_Programming) is a particular approach to Software Engineering, and it's the next step after OO. It does not describe by any means some sort of "Superman Programmer", but just all the opposite. Read the Wikipedia entry, it's pretty reassuming.
p.s.: if you were trying to be sarcastic, well, i'm pretty tired and drunk. Be nice
:)
-
And that's a step beyond OO in what manner? OO is a way of handling data and code affecting that data. XP is about ways to write better code, independent of linguistic or semantic considerations.
You must be drunk.
-
mik's correct. XP and OO are independent.
Extreme Programming actually works quite well. We use it at work sometimes. It certainly makes the other person's code more comprehensible.
The productivity loss caused by having one keyboard between two people (effectively meaning that only one can be actually working on the code at a time) is made up for by the productivity gain caused by more people understanding more of the application.
But most of the time I still prefer being told what needs to be done and being left in peace to do it.
-
XP and OO being of the same paradigm? What a strange idea to have....
Incidentally, somehow asked about Java developed games. Purely by coincidence, I discovered that Chrome and it's sequel - http://www.specforcethegame.com/ - was written in Java (according to java.com). Which is interesting; I didn't know that scale of game was feasible with java.
-
Bah. Java has come a long way since it was "too slow" for gaming. Quake III has been shown to run quite speedily under Java, just as an example. "Its Slow" isn't a valid black mark against Java anymore, and hasn't been since 2002ish.
Now, if you want a genuine blackmark, I'd look at its dumbass object model and the way it handles interfaces and its painful introspection support. One of the things I like about Python is the raw self-awareness of python code and its core mutability. Of course, like semantically signifigant whitespace, some might consider this a blackmark against python. ;)
-
The one thing Java really needs to add is support for delegates. Function pointers were a very powerful component of C/C++ (in the same manner as a big gun: it's still possible to shoot yourself in the foot, and when you do it'll make a bigger hole). Delegates were one of the nicer parts of C#. So where's Java's version?
-
http://www.onjava.com/pub/a/onjava/2003/05/21/delegates.html / http://java.sun.com/docs/white/sidebar.html?
EDIT; suns 'why not' argument; http://java.sun.com/docs/white/delegates.html (I think)
-
Function pointers are so groovy when building interfaces.
That said, function pointers are like the tactical nuke in the C++ arsenal. Its been said that C lets you shoot your self in the foot, C++ makes it hard to shoot yourself in the foot but when you do you take your whole leg off... well function pointers make it possible to shoot yourself in the foot and take out your neighbors. *heh*
-
Originally posted by mikhael
Function pointers are so groovy when building interfaces.
;7
-
I read Sun's argument a while ago, aldo, but I needed the reminder.
Inner classes are very messy. They add a lot more levels of indentation, they take up a lot of vertical space on the screen (unless you compact the braces, in which case it's harder to follow the indentation), and they're not conducive to following the flow of the code if the inner class definition is placed in the middle of the method that uses it.
Not only that, all classes in a program compile to seperate files. Even one-off internal classes. So if your application uses a lot of them you end up with vast numbers of tiny, used-once files in the project /bin directory.
Delegates are so much neater. I know what I want to do; I want syntax and semantics that reflect what I'm trying to do. Object-oriented languages are fine, but Java is obsessively object-oriented.