PTC was made using C. BASIC has even more limitations. It's impossible to program something more powerful than the original language.
Untrue. Assembly language is pretty limited, capabilities/feature wise. However, it does grant access to everything the machine has. Everything language goes down to machine language, eventually. Assuming BASIC has PEEK,POKE then anything is possible.
At one time, I was doing BASIC interpreter in BASIC. I didn't finish because I ran into memory trouble, and didn't solve the problem until years down the road where the BASIC I'm using became obsolete. But it is very much possible to program things with a rudimentary set of tools.
I have designs where PTC does recursion and OO methodology. A preprocessor compiler would have been perfectly doable had PTC has a way to write source code.
You don't understand. It would be like having a third of me being stronger than me as a whole. C made in PTC would be very limited compared to real C.
I don't understand what you mean by "power". Once you define that, then maybe I understand. I can understand feature set, speed of execution, memory manager, and all that. What do you mean by "power"?
I think I understand well enough, having done it. I think it is you who do not investigate the matter fully.
Besides, Tiny C was implemented in 4K of code at one point in time.
You don't understand. It would be like having a third of me being stronger than me as a whole. C made in PTC would be very limited compared to real C.
I don't understand what you mean by "power". Once you define that, then maybe I understand. I can understand feature set, speed of execution, memory manager, and all that. What do you mean by "power"?
I think I understand well enough, having done it. I think it is you who do not investigate the matter fully.
Besides, Tiny C was implemented in 4K of code at one point in time.
EDIT:
You've never heard "bootstrap" code?
Powerful as in having more abilities, faster, etc...Better as a whole. C programmed in BASIC programmed in C can't be the same as original C because original C had to interpret BASIC, and then interpret a limited version of itself using the BASIC it's interpreting. It's decoding twice, so that forces it to slow down, because it must take the time to decode.
Powerful as in having more abilities, faster, etc...Better as a whole. C programmed in BASIC programmed in C can't be the same as original C because original C had to interpret BASIC, and then interpret a limited version of itself using the BASIC it's interpreting. It's decoding twice, so that forces it to slow down, because it must take the time to decode.
You're describing compilation speed. That's not the same as having more abilities. You're painting a generic whole view based upon a single factor.
I can tell you that people, myself included, has built systems having more feature than the underlying language. Java, Ruby, Python, Perl, even early C++ was built upon plain old C compiler. Processing is built upon Java, which fits your definition of being decoded twice, and yet, even though execution speed is sacrificed, there are many more libraries built upon it than the original C language it's implemented it. Thus the higher level languages, such as Processing, have more "power" than lower language such as C.
That's why people built higher level languages. To have more features. More convenience. "Power"? "Better as a whole?" That's just too generic.
Powerful as in having more abilities, faster, etc...Better as a whole. C programmed in BASIC programmed in C can't be the same as original C because original C had to interpret BASIC, and then interpret a limited version of itself using the BASIC it's interpreting. It's decoding twice, so that forces it to slow down, because it must take the time to decode.
You're describing compilation speed. That's not the same as having more abilities. You're painting a generic whole view based upon a single factor.
I can tell you that people, myself included, has built systems having more feature than the underlying language. Java, Ruby, Python, Perl, even early C++ was built upon plain old C compiler. Processing is built upon Java, which fits your definition of being decoded twice, and yet, even though execution speed is sacrificed, there are many more libraries built upon it than the original C language it's implemented it. Thus the higher level languages, such as Processing, have more "power" than lower language such as C.
That's why people built higher level languages. To have more features. More convenience. "Power"? "Better as a whole?" That's just too generic.
Oh, Java, a language that is known to be slow. C is better as a whole because it can do anything Java can do, plus more! Need proof? Okay! It made Java. Therefore, anything made in Java is actually made in C, thus making C better. Better as a whole isn't too generic.
Unless someone is actually thinking of making a C compiler in petit computer for whatever reason, could we please stop with the debate?
I'm actually thinking of implementing Object-Oriented design with PTC.
It won't be C++, but it will have object allocation/deallocation, inheritance, and all that.
Assuming BASIC has PEEK,POKE then anything is possible.
PTCom does not have PEEK or POKE. What do those commands do? There might be an equilavant (like "WriteLine" in VB is "PRINT" in PTCom) to that command.
If Facebook, Myspace, Twitter, Instagram, and Snapchat were all destroyed, 90% of teens would go insane. If you're one of the 10% that would be laughing at them, copy & paste this into your signature and hope it happens.
Unless someone is actually thinking of making a C compiler in petit computer for whatever reason, could we please stop with the debate?
I'm attempting at a C interpreter.
If Facebook, Myspace, Twitter, Instagram, and Snapchat were all destroyed, 90% of teens would go insane. If you're one of the 10% that would be laughing at them, copy & paste this into your signature and hope it happens.
Therefore, anything made in Java is actually made in C, thus making C better. Better as a whole isn't too generic.
By your argument, then, C is actually made in machine language, thus making machine language "better". TI84 BASIC has PEEK/POKE, thus machine language. Therefore TI84 BASIC is just "better" as a whole, than C language. QED.
I'll stop the discussion here, because if that doesn't convince swordx using the word "better" isn't too generic, there's no hope.
Therefore, anything made in Java is actually made in C, thus making C better. Better as a whole isn't too generic.
By your argument, then, C is actually made in machine language, thus making machine language "better". TI84 BASIC has PEEK/POKE, thus machine language. Therefore TI84 BASIC is just "better" as a whole, than C language. QED.
I'll stop the discussion here, because if that doesn't convince swordx using the word "better" isn't too generic, there's no hope.
Until you remember that PTC only gives you 9999 lines of coding per program...All languages we use were mode using binomial coding, therefore it has the ability to do more than all the languages we use. We use the languages because it's easier, NOT because it can do more.
Until you remember that PTC only gives you 9999 lines of coding per program...All languages we use were mode using binomial coding, therefore it has the ability to do more than all the languages we use. We use the languages because it's easier, NOT because it can do more.
That's actually irrelevant. Let's just stop the discussion here.
So sorry to butt in to... whatever this is, but I wanted to let you know that Village 1.2.3 has a very severe save file corruption bug. I'm extremely sorry if anyone has encountered this bug! You'll know you have it if you can't walk into a particular cell or two without the game crashing. I've made a save file fixer and updated Village to 1.2.4 to fix this bug; if your village has this bug in it, please use the Village 1.2.3 Save Fixer and update Village to 1.2.4. Please backup your save file when the fixer gives you the option; I'm not entirely sure that the save file fixer is bug free (I only had a few corrupted worlds to test it on). Let me know if you have any issues with either the new update or the save file fixer! Thanks.
So sorry to butt in to... whatever this is, but I wanted to let you know that Village 1.2.3 has a very severe save file corruption bug. I'm extremely sorry if anyone has encountered this bug! You'll know you have it if you can't walk into a particular cell or two without the game crashing. I've made a save file fixer and updated Village to 1.2.4 to fix this bug; if your village has this bug in it, please use the Village 1.2.3 Save Fixer and update Village to 1.2.4. Please backup your save file when the fixer gives you the option; I'm not entirely sure that the save file fixer is bug free (I only had a few corrupted worlds to test it on). Let me know if you have any issues with either the new update or the save file fixer! Thanks.
Wouldn't you be able to tell which version you have by the version number you put in the source code? Or help menu?
Let me know when it's REALLY bug free, and I'll scan them then. ITMT, I'll wait for others to beta test your code.
@ramstrong The version number is both in the code and shows up while playing. I meant the "You'll know you have it" part to be about the bug, not a particular version lol. The bug is pretty rare for most people, and really only shows up if you're cheating or decided to fill up your town quite a lot.
Lol you know a program is never bug free, so I'll just assume you'll never play it. Unless you want to lower your expectations lol.
Lol you know a program is never bug free, so I'll just assume you'll never play it. Unless you want to lower your expectations lol.
I tend to have murderous thought to programmers who release buggy program. Since I like you, I want to keep the sentiment.
Having a program crashed after you spend so much time stocking up items seems like a bad way to go. I don't expect perfection, but crashing or hanging up isn't acceptable. If the game takes money once in long while, OK. Causing the save game to be corrupted after you spend days playing the game? Not OK.
Lol you know a program is never bug free, so I'll just assume you'll never play it. Unless you want to lower your expectations lol.
I tend to have murderous thought to programmers who release buggy program. Since I like you, I want to keep the sentiment.
Having a program crashed after you spend so much time stocking up items seems like a bad way to go. I don't expect perfection, but crashing or hanging up isn't acceptable. If the game takes money once in long while, OK. Causing the save game to be corrupted after you spend days playing the game? Not OK.
Then I hope you didn't play Dungeon Adventure... gulp
EDIT: Here's a video of the most simple (and important) sidequest in Dungeon Adventure 2!
Luckily the whole save file wasn't corrupted... it was just the cell where the corruption occurred. It's also lucky that the corruption was something that could be fixed, so people could "decorrupt" their saves with the program I provided. I know it's terrible that people (hopefully just the one who mentioned it) had to go through that, but it was such a ridiculous corner case that it never even came to mind. It's quite a large game at 150KB (code only), so testing every case would be impractical. I'm sorry if I gave you murderous thoughts!
Forums
Topic: Petit Computer
Posts 4,701 to 4,720 of 9,620
Please login or sign up to reply to this topic