Hard Light Productions Forums
Modding, Mission Design, and Coding => The Modding Workshop => Topic started by: Kazan on June 06, 2007, 01:02:47 pm
-
java makes the baby jesus cry
-
You know baby Jesus? What's he like? I am honored to know someone who knew him.
-
he's like any other baby - eats, sleeps, ****s, pisses, cries... and was born from a woman who got screwed
(PS: if you didn't know most of "jesus's" ideas come from the Rabbi Hillel who was intentionally blending judaism with buddhism)
-
Fascinating fairy tale :D
-
yes, jesus is a fascinating fairy tail
-
Jesus is for General Discussion ;) But Kaz still has that monkey thing :(
Don't really know what to suggest here.... Well, I do, but it's an Admin decision.
Either way, let's please not let this thread drift off topic :)
-
but but... they started it! :lol:
remove the monkey already :P
-
Well the monkey helps me find your post. It's either you or... That... other guy. :shaking:
-
if they want to give me a special avatar it can be a PCS2 avatar... i don't eed a ****ing insulting monkey under my name due to their inability to see how stiff necked and unreasonable they were being in their moderation
-
LOL Well, love it or loathe it, chances are that in the future, Java will be a useful language to be moderately fluent in. Personally, I'd rather learn C++ but it doesn't look like I get a choice next year at Uni :(
-
just keep in mind many of the things java does are VERRRRRY bad coding practices in C++
like.... java leaks objects because it has a garbage collector... never mind that when the garbage collector does trigger to clean up these leaked objects your program freezes waiting for it to complete.... i've known enterprise apps that they wanted to write in java have to be written in C++ because of this - the freezup would make the propgram take longer to process a request than the maximum allowed time.. (not to mention that the C++ version of the app was much faster on average as well - meaning more requests could be served within te service time requirements on the same hardware)
-
And I've known C++ programs THAT HAVE MEMORY LEAKS!!!11111
Garbage collection is not responsible for the problem you describe. ****ty programming is possible in any language.
Oh and the fact that you derail topics to go off on rants about Java isn't really helping your demonkeying cause.
-
if they want to give me a special avatar it can be a PCS2 avatar... i don't eed a ****ing insulting monkey under my name due to their inability to see how stiff necked and unreasonable they were being in their moderation
ERm..if you want a avatar or a stupid nickname removed generally pissnig off the admins is not the way you go..you know..sucking up and all that jazz..
-
Sucking up won't have much effect either I suspect. To get it removed he has to prove that he won't simply earn it again 5 minutes after it's removed.
-
Or donate...
-
A topic called "Kazan vs. Java" would inevitably be funnier if the first post was not by Kazan.
-
Garbage collection is not responsible for the problem you describe. ****ty programming is possible in any language.
yes it is. You have no mechanism in java to explicitly deallocate a resource (in java those are all objects) at the time at which you need to discard it - your reference to that object just goes out of scope so an orphaned object hangs out there. When you attempt to perform an allocation the garbage collector ticks and says "do I need to cleanup?" if no... you continue, if yes it has to go through and make an educated guess at which objects are orphaned (obviously always being cautious so it doesn't remove a resource in memory.. so there will be orphaned objects not removed). this process of determining orphaned allocations is costly causing execution of the main program to pause.
another program had a smiliar problem -
garbage collection is exactly responsible for the problem because the way the coders involved in that program overcame the problem was by creating a ringbuffer of reusable objects, allocated at start, so they never have to deallocate or reallocate objects - so the garbage collector was never hit. the application performed within specified time parameters once the ringbuffer was created
-
So in other words the problem was solved by good programming. Which is exactly my point. The problem is not a fault in the language so much as the inability of the coders to recognise and code for the languages strengths and weaknesses.
Bear in mind that the same ****ty code would have caused a hell of a slowdown in C++ too. The only difference there is that without garbage collection the entire program would run slowly all the time and the cause would not be apparent without profiling.
-
Sucking up won't have much effect either I suspect. To get it removed he has to prove that he won't simply earn it again 5 minutes after it's removed.
You sure sucking up won't work? Damn... I can't cancel the order of 3 tons of danish muffins now...
hm...will threats concerning shortening their life expectency (or that of their family) have any effect?
-
Depends one whether you consider taking the leash off Carl and pointing him in your direction an effect. :p
-
Bah...Carl has goten fat and is out of shape. Besides, wasn't he stuck in the vent?
He can onyl scare n00bs now...especially since I got my plasma rifle of Destruction (+5 vs. Shivans).
Now, where wuz I? Oh yes!
*points at the giant friggin lazer at his moon base*
I want one million dollarz! Or a better nick anyway....
-
There's a gc() function in Java as well, which is supposed to run the garbage collector. There's nothing stopping someone from parking a call to it at opportune times (eg after a file load or save has finished) and/or grouping all their 'deallocation' changes right before gc().
Why I'm using Java is because it's a hell of a lot less pain in the ass than wxWidgets was. I can point people to one package they'll have to install, and it's widely enough used that most people will already have it installed. Mac OS X actually comes with a JVM by default. It has fully built-in crossplatform interface and file loading/saving code. The capabilities are also pretty consistent across platforms. It doesn't require that I throw in a bunch of empty macros everywhere. For the most part, debugging is much easier because I can just check the command line for exceptions. Speed is not an issue.
Load time for all retail VPs: 8 seconds
Load time for all BtRL demo VPs: 2 seconds
And it takes around a minute and 30 seconds to write a merged VP of all the retail VPs, compared to 50 seconds if you were just copying all the VPs to the same location. How often do you need to write 1.17 GB worth of VPs, anyway?
I also don't have to worry about providing platform-specific binaries, and I can compile for all platforms on one platform, radically reducing the time it takes for me to go from making some code change to having a new version ready to release. I don't need to worry about #defines to provide substitutions for functions or features which aren't supported on one platform. I don't need to worry about having special compiler flags in the project files for each platform. Hell, getting a project file to work with wxWidgets can be a chore in and of itself. Last time I used wxWidgets I couldn't find decent instructions to get a project to compile with MSVC. And last time I used wxWidgets, I couldn't even get the right-click trigger for a tree object working for Polonius, despite hours of poking through newsgroups and forums and even posting the code in question and trying to get help based on that.
Overall, it's far easier to use Java for something like this, rather than struggle with wxWidgets for who-knows-how-many-hours to get it to work, and then have to deal with getting everybody who actually wants to use the program to install wxWidgets, and keeping three sets of binary releases in-sync and up-to-date.
And in some cases I've found that the automatic garbage collection of Java is a plus, because I don't have to worry about writing extra code to basically do the same thing as the garbage collector.
-
There's a gc() function in Java as well, which is supposed to run the garbage collector. There's nothing stopping someone from parking a call to it at opportune times (eg after a file load or save has finished) and/or grouping all their 'deallocation' changes right before gc().
I'm not sure if you're aware of this actually but the gc() method does not call the garbage collector. It tells the system that this might be a good time to call the garbage collector. Whether or not the system responds to that request immediately is a function of that particular implementation of the VM.
That said in most cases it probably will so you're not really wrong in what you said. You should just never assume that the garbage collector will be called.
-
I've found that Java tends to be good with small and/or fairly straight-forward programs. One of the best features of Java is the large supply of built-in libraries that do most of your work. Why bother writing your own collection class when you've got ArrayList and friends?
On the other hand, if you find that you're going to have to re-write a lot of the Java Library, or that you're simply not using much of it, then the argument to move to another language becomes much more convincing.
As for the speed issue, it's really not that big of a problem anymore. The more recent VMs seem to be plenty fast. If you're seeing a speed problem, it's likely your code, and not Java. The problem with Java's VMs is that they seem to artificially limit the memory footprint, which causes problems. I wrote a Liar's Dice game in Java recently, and the speed of it WAS a problem: The AI I wrote played so fast that you had to scroll back up and read what happened! (Project requirements specifically stated that we had to use the command line...) I managed to get several hundred million AI players in one game, and had no slowdown. Adding -Xmx1024m to your Java execution line will occasionally do wonders for speed on high-powered machines.
Why I'm using Java is because it's a hell of a lot less pain in the ass than wxWidgets was. I can point people to one package they'll have to install, and it's widely enough used that most people will already have it installed. Mac OS X actually comes with a JVM by default. It has fully built-in crossplatform interface and file loading/saving code. The capabilities are also pretty consistent across platforms.
Java isn't actually as cross-platform as I'd like, but that's not Java's fault. If you're using anything above Java 1.4.2, then you'll get a bunch of "OMG IT DOESNT WURK AND I ALREADY GOTS JAVA!" because Apple doesn't bother to update the version of VM they distribute with OSX. If the major OSes were distributed with the latest Java VM as of the release date, it wouldn't be a problem. I'm sure that Apple's issued a minor version change in the time since 1.5 came out.
-
So in other words the problem was solved by good programming. Which is exactly my point. The problem is not a fault in the language so much as the inability of the coders to recognise and code for the languages strengths and weaknesses.
Bear in mind that the same ****ty code would have caused a hell of a slowdown in C++ too. The only difference there is that without garbage collection the entire program would run slowly all the time and the cause would not be apparent without profiling.
the "same ****ty code" would have been fine in C++ because the problem WASN'T IN THE CODE, the problem was in the memory management scheme - what they did was not good programming, what they did was BAAAD programming... creative but still bad - only reason it's justified is they were working around a WORSE behavior of the language.
-
turey.. do me a favor
don't talk to me like i'm a ****ing moron - i have the latest JRE on all my systems, if I had a problem running said code (Whih i haven't bothered to try to run) I would have checked that first.
and it's not "my code" i avoid writing java code because java is the plague... a java VM fast? that's LAUGHABLE.. the java VM is slow, absolutely inexecusably slow. Startup times on hat should only take a fraction of a second to load for what it does, and this isn't "it's the code's fault!" this is good code from good programmers are annoyingly long in java.
and i'm not interested in times it takes to READ a VPs FAT - i want to know load times, how long it takes to WRITE a vp, etc
-
turey.. do me a favor
don't talk to me like i'm a ****ing moron - i have the latest JRE on all my systems, if I had a problem running said code (Whih i haven't bothered to try to run) I would have checked that first.
You're throwing a fit and accusing Turey of implying you're a ****ing moron over code you haven't even tried to run yet?
and it's not "my code" i avoid writing java code because java is the plague... a java VM fast? that's LAUGHABLE.. the java VM is slow, absolutely inexecusably slow. Startup times on hat should only take a fraction of a second to load for what it does, and this isn't "it's the code's fault!" this is good code from good programmers are annoyingly long in java.
Good programmers test their code before accusing someone of being a ****ing moron for suggesting that they could optimize said code.
and i'm not interested in times it takes to READ a VPs FAT - i want to know load times, how long it takes to WRITE a vp, etc
I never posted how long it took to "READ a VPs FAT". I posted how long it took to load the FAT of the 9 retail VPs, convert those FAT to over 6,000 internal class instances representing each of the files/folders, along with various other supporting classes, then use each of those classes to create the 18,000 class instances needed to add those to all three of the entry trees, and finally display the 6,000 entries in the one visible file view tree.
It takes about two seconds to load Maja under OS X, and around a second to load Maja under Windows.
I already posted how long it takes to write a VP.
EDIT: My bad, you weren't accusing Turey of being a ****ing moron, just accusing him of implying(?) you were a ****ing moron. Even more amusing.
-
Kazan, garbage collection hasn't been a serious issue since Java 1.2. Unless you're writing a real-time or embedded application (in which case you shouldn't be using Java anyhow), Java will run at perfectly acceptable speeds. Allegedly it can be faster than C++ in some areas, but I haven't seen statistics on this.
Another thing is that you can't write C++ code in Java. You have to follow the assumptions of the programming language that you write in. This means that you don't implement function pointers using reflection and callback; you use an interface. Etc.
What have you written in Java, anyway?
-
IIRC Kaz was forced to use Java against his will, because one of his professors helped write it.
I'm not sure if you're aware of this actually but the gc() method does not call the garbage collector. It tells the system that this might be a good time to call the garbage collector. Whether or not the system responds to that request immediately is a function of that particular implementation of the VM.
oh isn't that lovely, your code performs totally different on different systems and there is nothing you can do about it. this is one of the principal reasons I hate Java on a very intimate personal level, none of your code is executed it's 'interpreted'.
-
I'd actually like karajorma to source that comment, the java documentation says (for 1.6.0):
Runs the garbage collector.
Calling the gc method suggests that the Java Virtual Machine expend effort toward recycling unused objects in order to make the memory they currently occupy available for quick reuse. When control returns from the method call, the Java Virtual Machine has made a best effort to reclaim space from all discarded objects.
The call System.gc() is effectively equivalent to the call:
Runtime.getRuntime().gc()
Runtime.gc():
Runs the garbage collector. Calling this method suggests that the Java virtual machine expend effort toward recycling unused objects in order to make the memory they currently occupy available for quick reuse. When control returns from the method call, the virtual machine has made its best effort to recycle all discarded objects.
The name gc stands for "garbage collector". The virtual machine performs this recycling process automatically as needed, in a separate thread, even if the gc method is not invoked explicitly.
The method System.gc() is the conventional and convenient means of invoking this method.
I haven't used gc() enough (I haven't had to use it at all) to know how accurate the documents are. However, I found this test program (http://www.devdaily.com/java/edu/pj/pj010008/index.shtml) which I used under Windows and found that the garbage collector was, in fact, invoked with the gc() call.
Still, that's a relatively minor point (IMHO). It's no different from using something like OpenGL or OpenAL and having to deal with different functionality on different systems. Mostly I just want to know what the differences are on what platforms, I haven't found a site listing them yet.
-
openGL and openAL only have differences between different hardware capabilities - the programming interface is still the same and the basic behavior is the same, it's just a "realism" difference.
and bob has it right - i've had to write a lot of java because one of the professors who (is now moving to a school in florida) at my uni helped write part of java
-
So would it be safe to assume that if you are creating small applications and 'non-speed-critical' software, that Java is an acceptable, if not very popular, solution? But the moment speed or memory are going to need to be kept at a premium, it's probably better to look for a language with more 'direct' control over the management?
-
I'd actually like karajorma to source that comment, the java documentation says (for 1.6.0):
Runs the garbage collector.
Calling the gc method suggests that the Java Virtual Machine expend effort toward recycling unused objects in order to make the memory they currently occupy available for quick reuse. When control returns from the method call, the Java Virtual Machine has made a best effort to reclaim space from all discarded objects.
Let me clarify. I don't remember if it runs the garbage collector itself and that simply returns without doing any collection or if the system decides not to call the garbage collector.
Either way the result is the same. Calls to gc() do NOT guarantee that garbage collection will be performed. Simply that this is a good time for garbage collection to be performed. Pay close attention to the use of the word suggest.
This fact is actually a favourite of the examiners on the certification exams. Which is why I remember it despite not actually having touched Java for quite a while. :)
-
I'd actually like karajorma to source that comment, the java documentation says (for 1.6.0):
Runs the garbage collector.
Calling the gc method suggests that the Java Virtual Machine expend effort toward recycling unused objects in order to make the memory they currently occupy available for quick reuse. When control returns from the method call, the Java Virtual Machine has made a best effort to reclaim space from all discarded objects.
Let me clarify. I don't remember if it runs the garbage collector itself and that simply returns without doing any collection or if the system decides not to call the garbage collector.
That's an important difference. If it runs the garbage collector and the memory can't be freed, that's a whole 'nother ball game from the JVM simply not deciding to try at all. After all, it's not like the garbage collector can add extra RAM sticks to your machine if it reads everything as being in-use; though it might be able to do some defrag work.
Now I feel like Kazan, accusing someone of being condescending. Rather than implying that I'm not paying enough attention to the definition or not reading it right, read the sentences before and after the "suggest" one. Both state with certainty that the garbage collector will have been run, and made a 'best effort' to reclaim memory. Hence I feel like arguing over the interpretation of the definition in the Java API is retarded because it basically contradicts itself with regards to the certainty, which is why I asked what you were basing your comment on.
-
So would it be safe to assume that if you are creating small applications and 'non-speed-critical' software, that Java is an acceptable, if not very popular, solution? But the moment speed or memory are going to need to be kept at a premium, it's probably better to look for a language with more 'direct' control over the management?
I think you shouldn't make any concrete judgments based on this thread. The SCP is C-based, which is what attracts most programmers. It's also a game, and most 3D games are written in C/++ because that's been the best solution so far. If you were to go to a forum that attracted mostly Java fellows, you'd probably get people *****ing about the templates library or preaching how Java is so much better because it's so much easier to use and doesn't require libraries.
Bobb has basically admitted to being biased towards the way that Java runs, and AFAIK hasn't done any real coding at all with it. Kazan was forced into doing Java. I haven't done anything much to test Java's speed or memory usage compared to C/C++, nor do I know much about optimizing it. Turey seems to be in about the same boat as me. Karajorma has probably had the most experience with the language, as IIRC he works as a java programmer as his day job.
Sun has gone to some effort to get Java to run on embedded platforms, where CPU usage and memory usage will be at a premium. I haven't researched that at all; I don't know how the performance stacks up against C-based apps.
I would say that unless you're doing something that needs a lot of speed or lowlevel hardware/software access, or you need something that can be portable to other platforms or the web in a flash, you should prefer the language you like the most. If you're in a position where you need speed but want portability or vice versa, figure out a way to run some benchmarks with what you're actually doing. Open a bunch of windows or spit out a bunch of polygons (There are OpenGL and OpenAL wrappers for Java now). Do a bunch of physics calculations.
That is just MHO.
-
Thanks for the opinion, the reason I'm asking is because, like all trainee programmers, we'd all love to write a game, even though I'm honest enough to myself to know the chances are my career probably won't go in that direction. I'm learning Java for my second year at Uni, but was basically under the impression that Java was more a 'business language', as in it was designed for writing easily and quickly at the cost of low-level access, but, most everyone tends to polarise themselves to a particular language so it is kind of hard to get a good picture.
I've got the next few months free, which is a rare moment in my life, and I am considering sitting down and learning some C++, from what I've been told, moving from C++ to Java is not that much of a chore at the sort of level we'll be using it at Uni.
I suppose the real decider here for me is the accessiblity of help on the web, GameDev.net etc were very C++ based for a while in the 3D graphics side of things, with Java considered to be a language for writing phone games on.
If I am going to take on a project as massive as a game as a hobby, I suspect I'll need all the help and hints I can find on the net, I've got a pretty good founding in basic coding and design practice, being an ex 8-Bit machine coder, the rules haven't changed, even if the languages have. I already have a pile of DFD's Data Dictionaries, Flowcharts etc I've done over the years, though the chances are none of them will even be relevant by the time I actually sit down and start writing.
Still, it'll be a while before that happens, first job is just to write out some simple software based algorhythms for Matrices and Quarternians and removing cobwebs from 15-year old 3D programming practices ;)
Edit: Though I will admit, I only did Pascal and VBasic this year, nice to see they haven't changed, Pascal is still the worlds most complicated calculator, and Basic is still 'Lego for Programmers' ;)
-
I can find lots of comments on the gc() method but pretty much everything I'm finding is from 1.4.2 or earlier. Basically the explanation I was given while studying for Certification was that the gc() method sets a flag telling the garbage collector that it has been asked to run and nothing else. The implementation is completely at liberty to decide what it wants to do with this flag.
IIRC Hotspot and IBM's JVMs did respect the flag. Others might not or might do something different.
For instance.
http://edocs.bea.com/wljrockit/docs142/devapp/codeprac.html
Avoid Calling System.gc()
Don't call java.lang.System.gc(). This method behaves differently with BEA JRockit JVM than with other JVMs. Instead of doing a complete garbage collection, as with the Sun JVM and others, when called by an application running with BEA JRockit JVM, System.gc() behaves depending upon the garbage collector already in use:
* If you're using a generational copy collector, System.gc() does a collection in their nursery.
* For all other collectors, it does a collection only if one is needed. In other words, it does nothing special on the call.
Sun are quite strict on the matter in their exams. You'll automatically fail any question in which you say that the gc() method calls the garbage collector.
-
if you are planning on going into games programming, Java is not for you. Java is best for application software, like a tax calculator or a spreadsheet or a word processor, and it's best if you have a lot of platforms you want to support, while C\++ can be very portable it's up to the API writers to make sure it is, this is why I like my C, because ultimately the programmer is in charge. however, there is a trade off in terms of easy vs lot-of-control (and thus an ability to take advantage of hardware). now when I say a lot of platforms, I don't mean PC, Linux, and Mac, a Java program "will" run on any platform that has an interpreter written for it, from a PC to a playstation to a car sterio to a cellphone, and supposedly it will run the same on all them, but that's up to the person who writes the Java interpreter, not you.
now back to my first point, games need a lot of speed and in Java it is designed around you not being able to get to any hardware, it's a "good" thing in the Java mindset that you can't use memory tricks to copy whole arrays of data directly in one call (because Java is object orientation to the max, memory doesn't exsist anymore, just objects and objects need to know how to copy, so you have to go one at a time) for example. I understand were they are coming from, but I think they just took it WAY THE **** too far. you absolutely cannot take advantage of hardware _ever_, this is both due to Java's OO philosophy and the fact that it's platform independent (if hardware is undefined you can't take advantage of it), for things ware cross platform homogony is more important than speed, this can be a good thing (even if I'm uncomfortable with the fact that you are forced not to go low level for a particular platform). for a game of any complexity this is unacceptable.
-
(because Java is object orientation to the max, memory doesn't exsist anymore, just objects and objects need to know how to copy, so you have to go one at a time)
Actually isn't primitives (int..etc) actually primitives in Java unlike C#, Eiffel and Ruby, which int's are objects?
-
Well, I have to be realistic and admit that game programming would likely be a hobby, chances are, like 90% of other programmers, I'll end up being into Database development, which I don't really mind, and, in many ways, it's a lot less demanding than working in the gaming market.
I suppose I'd write a game more because it was a game I'd like to play, which sounds terribly conceited, but I suppose it's better than sitting round complaining that there aren't enough what I consider to be 'engaging' Empire Building type programs out there.
I see what you mean about Java, it gives up low level control for compatability, I guess I will have to learn it anyway for Uni next year, but yeah, I think I'll start studying C++ over the next few months, and getting used to using it :)
Thanks for the advice and opinions :)
-
The lessons you learn about OO studying Java are pretty much directly applicable to C++ (but not C ).
It's probably easier to go from C++ to Java than the other way round but it's not a huge problem in either direction.
-
It's probably easier to go from C++ to Java than the other way round but it's not a huge problem in either direction.
for an astute person who knows what they're getting into
i've seen too many snot-nosed plebes with less-than-sufficient-cluecount learn java and then when they start writting C++ their programs leak memory like whores because they cannot get the delete call into their heads no matter how many times you explain it.
-
*scared of Kazan
:shaking:
I not quite sure I want to try to taking programming courses anymore.
*hopes that programing 1&2 are c++
-
*scared of Kazan
:shaking:
I not quite sure I want to try to taking programming courses anymore.
*hopes that programing 1&2 are c++
Haha they should be in Pascal, thats what mine were :lol:
-
Hey, wait: I have a question:
Umm... If one were to hypotheticly... uhh... aspire to code for FSO, what language would have to, uhh... be fluent in? Is it C or C++ (or neither)?
:nervous:
-
it would be best if you knew how to write c++ as c
-
it would be best if you knew how to write c++ as c
Without classes? I could see how classes would make FSO a bit more easier to mod.
-
well FS was originally coded as C, then later they upgraded to C++, so it's mostly C but it uses a few of the nifty tricks C++ added in a few places.
-
Hey, wait: I have a question:
Umm... If one were to hypotheticly... uhh... aspire to code for FSO, what language would have to, uhh... be fluent in? Is it C or C++ (or neither)?
:nervous:
My bad, I misread it as write FSO from the ground up. At which point I would definetely write it in C++, if starting fresh.
-
well, in a game speed is the key, and you wouldn't want to over do the OO stuff, it might be more organized and easier to write but it can also be slower if you are not VERY careful, C style coding has fewer pitfalls in this regard.
-
I don't see any reason to learn C++ as opposed to learning C and then upgrading to C++.
There's so little difference between the two in the FS2 code that I find it bizarre how big of a deal people make out of the difference between the two in discussions here. FS2 barely uses any of STL, and I'd guess at least 90% of the functions are only object-oriented in that they're prefixed with "ship_" in the name and are meant to be used with a ship pointer (or weapon_, object_, etc). The other 10% is either new stuff or the audiostream code.
-
99.9% of the STL it does use is new stuff. I don't think V used any STL except the odd function or two.
-
Yeah, programming is fun, but whilst I was doing the first year course, which is was just Pascal and VB, the most painful part was looking at some of the other guys programs... Here is an example...
We were given a condition to write a game that involved 'pairs', as in you select a card, select another, and if they match, you up the score and keep them turned, else turn them back after 1 second.
One of the first thoughts that entered my head was 'Collection', simply throw all your pictureboxes into one collection, and then you can use Sender and a quickl check loop to find out which button was pressed. Not diifficult, once you get your head around the idea of a collection.
The usual solution from trainees was to write 36 If-Then statements, one for each card clicked..... It's the sort of thing to make someone who was used to coding with 32K of memory cry :(
-
We set students a problem of writing a battleships game. Ships placed on a 10x10 game grid. The player enterred X Y co-ords and the game reported if the shot was a hit or a miss. The solution we were looking for was a two dimensional array storing the contents of the game squares which is interrogated by an if statement. What we got instead was.
If x=1 and y=1 then print "hit"
If x=2 and y=1 then print "miss"
If x=3 and y=1 then print "hit"
(repeat 97 more times and pardon my use of BASIC)
-
:lol: It's kind of funny thinking that I started off learning Basic from an Oric-1 Manual, and then got an Amstrad and started learning Z80 machine code without any help from school at all.
In fact the only language that almost made me give up coding was 6502 machine code. Have you ever tried writing in a language that has no registers larger than one byte? Simply working out a relative address was a nightmare :(
-
All I can program is a graphing calculator. :(
I made this one program that counts :drevil:. It's like, 5 lines. I shall teach myself C or C++ this summer in my spare time, though. :nod:
-
that's how I got started, making programs to do my math homework for me on a TI83.
-
LOL I programmed my TI85 and managed to pass stats class with it :lol:
-
Real programers write in assembly code!!! :pimp:
-
Real programmers write in machine code! :eek2:
-
Real programmers write in machine code! :eek2:
Now you got me confused... isn't that mostly the same? :confused:
-
asm:
push eax r12
machine code:
001101010101000110110001101010101000111100
but real programmers just tap wires together until the executable just appears on the disk.
-
They use magnets to manually write the code to the disk :lol:
-
or laser pointers...
-
Well the monkey helps me find your post. It's either you or... That... other guy. :shaking:
hey, wait a sec, what other guy?
-
:lol: It's kind of funny thinking that I started off learning Basic from an Oric-1 Manual, and then got an Amstrad and started learning Z80 machine code without any help from school at all.
In fact the only language that almost made me give up coding was 6502 machine code. Have you ever tried writing in a language that has no registers larger than one byte? Simply working out a relative address was a nightmare :(
you mean code like 10111011111100... :wtf:
-
hey, wait a sec, what other guy?
Blackdove.
But I think he made too much of an ass of himself and got banned anyway.
-
:lol: It's kind of funny thinking that I started off learning Basic from an Oric-1 Manual, and then got an Amstrad and started learning Z80 machine code without any help from school at all.
In fact the only language that almost made me give up coding was 6502 machine code. Have you ever tried writing in a language that has no registers larger than one byte? Simply working out a relative address was a nightmare :(
you mean code like 10111011111100... :wtf:
Noy quite, but knowledge of Binary was pretty much a must, Boolean Flags really took up 1 bit of memory then and you could only access them as whole bytes, so you learned how you rotate your bits in public ;)
Basically, it was assembly code, but the assemblers that were available back then were utter nightmares to use compared to modern ones, you had to do 'Grey Box' Testing, which, is sort of halfway between Black Box and White Box testing, it basically means 'I have a vague idea what should happen when this routine runs, but I'll find out how close it is when I run it, and fix it accordingly'.
It sort of looked like:-
LDA &FE
STA &BB00
LDA &00
STA &BB01
JSR (&BB00)
END.
That was, quite literally, the only way to call a referenced subroutine, now, a cookie for who knows what address a 6502 machine could would try to jump to?
-
That was, quite literally, the only way to call a referenced subroutine, now, a cookie for who knows what address a 6502 machine could would try to jump to?
Line 254?
My assembly's a bit rusty...
-
I'd say 127