6502 illegal opcodes questions
in [Commodore]
|
Prev: what happened CBM=VGA
Next: 1581 Drive Kits on eBay
From: mdj on 3 Jun 2006 20:45 Paul Schlyter wrote: > > Still, this didn't solve the whole problem, as many standard 1.1 > > Applets wouldn't run on Microsofts VM, which unfortunately shipped > > standard with Windows, making Java look a lot worse than it actually > > was. > > Which explains why Sun later prohibited Microsoft to implement its own JVM. > That's when Microsoft switched to C#. Yes. Things have been a lot better since then. > That's nice! But it's also a hole in the fairly strict type checking > in Java. How so? > ...well then the choice is easy: do it the most efficient way... :-) > > Of course there's some work in ensureing that they way you chose really > was the most efficient. There's yet to be any evidence that it's less efficient, and perhaps some to indicate it's more so. Anyway when faced with choice these days I go with the most maintainable way. CPU power is cheap and plentiful. > > It's still frowned upon, in favour of using a constant plus > > if/else/switch constructs to do conditional compilation. > > That causes a problem: a source line which shouldn't be used in some > particular environment can also be a syntax error in such an environment. Exactly. The point is to avoid these situations by design. There's no good reason to have machine dependencies within the same class in a OO language. That's poor design. > I dondt think one can talk about namespaces at all regarding macros in > preprocessors. The preprocessor does not know what a namespace is. It > hardly knows anything about the underlying source language. Heck, you > can even replace reserved words with macros -- try to do THAT using > the global namespace in a normal way..... Why? Namespaces are a natural extension present in most modern languages to avoid collisions that occur frequently in larger programs. Macro's being redefined by included headers from an unrelated piece of code is a real problem in C/C++ programs. Of course, most good programmers utilise some form of poor-mans namespacing by prefixing their preprocessor names with something that's likely to be unique. This illustrates the point that the feature would be useful. > Is there a .setName() method too? If there is, one might be able to > do quite interesting things with it.... :-) Heh. Some OO languages implement a 'Pose' facility to allow you to do this. It's possible to get the same effect in Java, but constructors make it difficult. Don't get me started on constructors ;-) > > But then, many people want to treat Java as if it's C++ minus features, > > rather than the very different language that it is. > > These peope are wrong of course. Java resembles C++ only > superficially, mostly by having similar syntax. But the semantics > under that syntax is quite different, and more resembles > "strait-jacket languages" like Pascal --- of course with a lot of > features not available in Pascal. I usually think of Java as "the > UCSD Pascal of our times": it has portable object code which must be > run on a virtual machine. However, it is object oriented, it is net > aware, and it is 32-bit rather than 16-bit. And Java is also a > subsystem, not a whole OS like UCSD Pascal was. Straightjacket is a little harsh :-) If we're comparing Java to C++, it's really C++ that's the straightjacket language, by forcing you to make all binding decisions at compile time. Semantically speaking Java is a lot more like Smalltalk than C++. It's a nice bridge between the dynamic world and the static world. To me it's more like this: C++ is C, but with stricter type checking, and object oriented like extensions, staying within the realm of a static language with no runtime system or typing. Java is C++ like in syntax, but is underneath a 'real' OO language, allowing dynamic binding, loading, etc, within a C++ like typing system. It's actually far more flexible than it first appears, but you have to think like an OO programmer. The only time the typing system annoys me is when I want to do something REALLY OO, with some fairly heavy reflection. The lack of syntactic sugar in the reflection API is at times most tedious, and results in code being very hard to read where it should be simple and concise. To this day, I don't miss the implicit conversion between integer and boolean type that C/C++ programs use. This is the only area where Java's type checking is stricter. Other differences are feature removals as mentioned previously Matt
From: mdj on 3 Jun 2006 20:54 > Just like certain Java-programmers who consider Interface and Class > synonymous... (That's what the I in API means - Interface). :-) I've not met anyone who misses that distinction yet. Although one must be careful when using the word Interface within Java as it can be easily misconstrued - a libraries interface need not use interfaces.
From: mdj on 3 Jun 2006 21:04 Paul Schlyter wrote: > I fully agree with that! The API is the specification, not the > implementation. There might be some parts of the library which > can be called by outside code but wasn't intended to be called in > that way - they're not part of the API, even though they're part of > the library! Of course, if you use features of a library that aren't part of it's documented interface you'll eventually be cursed by almost everybody. Hey, we're almost back on topic, considering this was supposed to be about 'undocumented opcodes' :-) Of course, my feelings on using undocumented library calls is much the same as my feelings on undocumented opcodes. They are very similar problems. Matt
From: mdj on 3 Jun 2006 21:13 Michael J. Mahon wrote: > Many years later, I think that the "offside rule" for delimiting > blocks simply by indentation is a very nice approach. Why on > earth should white space, the most significant characteristic of > text to the human eye, be ignored by most programming languages? Once you bed down the definition of white space, you've committed the language to a certain aesthetic form quite unnecessarily. People have been arguing for *years* over such aestheic issues in most programming languages without any clear consensus. Perhaps one day we'll reach one, but beauty being in the eye of the beholder I somewhat doubt it :-) An interesting language in this regard is Ruby, who's syntax is such that BOTH whitespace or statement delimiters may be used, depending on what is felt most appropriate to the developer. Actually the first language I've used seriously where carriage returns are considered statement terminators and I've not immediately disliked the language. In fact, Ruby allows some beautifully concise code. The language is so flexible in fact, that you can override almost any facet of it, in effect making it very simple to construct domain-specific languages, or sublanguages, to better suit the problem domain. Lots of fun. Matt
From: Michael J. Mahon on 4 Jun 2006 04:31
Kent Friis wrote: > Den Fri, 02 Jun 2006 21:53:25 -0700 skrev Michael J. Mahon: > >>Many years later, I think that the "offside rule" for delimiting >>blocks simply by indentation is a very nice approach. Why on >>earth should white space, the most significant characteristic of >>text to the human eye, be ignored by most programming languages? > > > For the same reason that comments, the most human readable text found > in a program, are ignored by the programming language. Whitespace is > an important part of making the program more readable. > > A programming language that prevents me to use white space to make > code readable (because that would change what the code does) is just > as bad as one that prevents me from writing a comment where needed > (Actually, Visual Basic .NET does that in certain places. Yuck). If you think about it, the same things that make it more readable to a human can make it more "parsable" by a computer--and you'll be much less likely to have a piece of code look different from what it means. Comments are still fine, and can also be delimited by the off-side rule in many cases (though that isn't necessary). A comment should never repeat the meaning of a statement at the level of the language, but should, generally, give the meaning of a statement or group of statements at a higher level of abstraction. -michael Parallel computing for 8-bit Apple II's! Home page: http://members.aol.com/MJMahon/ "The wastebasket is our most important design tool--and it is seriously underused." |