Interesting, though I think I still prefer the Eiffel syntax, which sees no use for repeating "KeyType" later when the constraint is placed on its type.
Eiffel is purely object-oriented(in the same vein as SmallTalk or Ruby, but statically typed). Everything is an object. Strings, integers, floating point numbers. Yet they can be used with no less flexibility than primitive types in other languages, and have little negative impact on executables. Quite a feat.
Eiffel is no more verbose than it needs to be to express the concepts at work. Additionally, it does several things to cut down on syntax.
1. Semi-colons aren't required. 2. Parentheses don't have to follow routine calls which don't require arguments. 3. Groups of arguments to routines with the same type don't have to be individually typed. 4. Access qualifiers don't have to be individually applied(vs. Java/C#)
Eiffel's genericity is far more powerful than that which C++ provides. In Eiffel it is possible to restrict the type that may be used. This becomes useful in cases like the DICTIONARY class, where the class provided for the key must inherit HASHABLE.
Yes, this could be done in lots of other languages by not using generics and simply ensuring that the key must be of type HASHABLE. Yet, how then do you ensure that every object bound to that key variable is of the same type? You can't.
So you must have constrained genericity. Eiffel provides this while C++ does not.
Well, one PPC970 might not compete against an Itanium2, but how many 970s will you be able to buy(I'm assuming the pricing will be comparable to what Motorola currently gets for its high-end) for the price of a single Itanium2?
Could the second example be achieved more easily(if not more effectively in all cases) by translating on an instruction-by-instruction basis, then optimizing using whatever normally optimizes the native instruction set?
I'm going to have to shill for Eiffel again. Eiffel allows for generics in a much cleaner way than C++, and it also allows for constrained genericity, whereby one can explicitly state that the class T(just because everyone uses T) must inherit (or "implement")some other class or interface.
For instance, in the DICTIONARY class, the KEY class must inherit from the deferred class HASHABLE. If it doesn't, then the class might not have the proper routine to generate a hashcode, which is essential to the DICTIONARY class, and trouble could result.
There is a language which allows for this kind of "access qualifier". It's called Eiffel. In the classic example, only the TELLER and BANK classes have access to the balance feature of the ACCOUNT class.
class ACCOUNT feature { TELLER } balance: INTEGER end
-- this causes problems:
class ROBBER feature stash: INTEGER do_something(acc: ACCOUNT) is do stash:= stash + acc.balance end end
I was thinking that functions can only modify their own local variables, and must return a value. Procedures may modify the object's instance variables(or class variables), as well as their ownn local variables, but may not return a value.
Sort of...
class A { private int foo; public void setFoo(int foo) { this.foo = foo; } public int getFoo() { return this.foo; } }
Rather than...
public int setFoo(int foo) { this.foo = foo; return this.foo; }
I'll add one to this and see which category the folks here think it belongs in.
Functions/methods should be separated into "functions", which return a value without modifying external values, and "procedures", which do exactly the opposite.
They're targetting education. From what I've seen, Math and CS departments are really keen on languages being standardized before they'll add it to the curriculum.
At least at my school, we were late in getting on the Java bandwagon, and still have only grudgingly accepted it as a "slightly cleaner C++", which I strongly object to(since Javva is most definitely not C++).
If C# has the standards going for it, plus the blessing of Microsoft, and looks more like C++ than Java, it'll supplant Java quickly in academic settings, which buys Microsoft greater control over the cycle*.
* Schools teach what's in demand, and businesses look to colleges to see what knowledgeable people are using.
I haven't yet found anybody who'll pay me to use it, but I do to keep my design skills reasonably close to my coding skills. I've found the statement that "it's only as verbose as it need to be to describe the concepts going on" quite accurate.
It also does a great job of handling multiple inheritance and operator overloading, with keywords to explicitly distinguish infix, prefix, and postfix operators. Constrained genercicity can be a nice tool too.
MPC 74xx wuld be an even more accurate way of describing the processor.
And Motorola isn't out of the running, if they can deliver with the 7447/7457, 75xx and maybe even some 85xx series processors, they could be a good source of consumer-level chips for Apple.
There are, if memory serves, 32 integer registers, 32 "number" registers, 32 string registers, and 32 "Parrot Magic Cookie" or PMC registers which deal with more complex data.
Actually, AltiVec/VMX(IBM) is basically just a whole mess of extra instructions that result in performance gains for some(but a large "some") applications.
Python modules can be compiled. Write a simple little script that imports your module(which in Python means just about any source file). You'll notice a *.pyc file now hanging out in your directory. Cngratulations, it's Python bytecode.
Umm.... you could just buy a Mac and VirtualPC, then install Xfree86 in rootless mode. Seems like a simpler means to the stated end, considering that a Mac running Mac OS X is a "unix box".
Well, it doesn't seem to be able to find GMP with the standard Dev Tools installed. Downloading GMP from the GNU site, and building and installing it seems to have eliminated the problem, though it occasionally gets a few warnings.
Slashdot Mirror
Say I want to find documentation on the DICTIONARY class.
localhost% short dictionary
Or maybe I'd rather look up the array class.
localhost% short array
Interesting, though I think I still prefer the Eiffel syntax, which sees no use for repeating "KeyType" later when the constraint is placed on its type.
I agree, but I would clarify that the PowerPC architecture didn't "scale to" 64-bit, but rather started out as 64-bit, with a 32-bit subset.
Yes, we like stylish, happy computers. But stylish, happy, and blazingly fast computers are even better.
I think I still prefer "class DICTIONARY[V, K->HASHABLE]". ;-)
Eiffel is purely object-oriented(in the same vein as SmallTalk or Ruby, but statically typed). Everything is an object. Strings, integers, floating point numbers. Yet they can be used with no less flexibility than primitive types in other languages, and have little negative impact on executables. Quite a feat.
Eiffel is no more verbose than it needs to be to express the concepts at work. Additionally, it does several things to cut down on syntax.
1. Semi-colons aren't required.
2. Parentheses don't have to follow routine calls which don't require arguments.
3. Groups of arguments to routines with the same type don't have to be individually typed.
4. Access qualifiers don't have to be individually applied(vs. Java/C#)
Eiffel's genericity is far more powerful than that which C++ provides. In Eiffel it is possible to restrict the type that may be used. This becomes useful in cases like the DICTIONARY class, where the class provided for the key must inherit HASHABLE.
Yes, this could be done in lots of other languages by not using generics and simply ensuring that the key must be of type HASHABLE. Yet, how then do you ensure that every object bound to that key variable is of the same type? You can't.
So you must have constrained genericity. Eiffel provides this while C++ does not.
Well, one PPC970 might not compete against an Itanium2, but how many 970s will you be able to buy(I'm assuming the pricing will be comparable to what Motorola currently gets for its high-end) for the price of a single Itanium2?
Could the second example be achieved more easily(if not more effectively in all cases) by translating on an instruction-by-instruction basis, then optimizing using whatever normally optimizes the native instruction set?
I'm going to have to shill for Eiffel again. Eiffel allows for generics in a much cleaner way than C++, and it also allows for constrained genericity, whereby one can explicitly state that the class T(just because everyone uses T) must inherit (or "implement")some other class or interface.
For instance, in the DICTIONARY class, the KEY class must inherit from the deferred class HASHABLE. If it doesn't, then the class might not have the proper routine to generate a hashcode, which is essential to the DICTIONARY class, and trouble could result.
class DICTIONARY[V, K -> HASHABLE]There is a language which allows for this kind of "access qualifier". It's called Eiffel. In the classic example, only the TELLER and BANK classes have access to the balance feature of the ACCOUNT class.
:= stash + acc.balance
class ACCOUNT
feature { TELLER }
balance: INTEGER
end
-- this causes problems:
class ROBBER
feature
stash: INTEGER
do_something(acc: ACCOUNT) is
do
stash
end
end
I was thinking that functions can only modify their own local variables, and must return a value. Procedures may modify the object's instance variables(or class variables), as well as their ownn local variables, but may not return a value.
Sort of...
class A {
private int foo;
public void setFoo(int foo) {
this.foo = foo;
}
public int getFoo() {
return this.foo;
}
}
Rather than...
public int setFoo(int foo) {
this.foo = foo;
return this.foo;
}
I'll add one to this and see which category the folks here think it belongs in.
Functions/methods should be separated into "functions", which return a value without modifying external values, and "procedures", which do exactly the opposite.
They're targetting education. From what I've seen, Math and CS departments are really keen on languages being standardized before they'll add it to the curriculum.
At least at my school, we were late in getting on the Java bandwagon, and still have only grudgingly accepted it as a "slightly cleaner C++", which I strongly object to(since Javva is most definitely not C++).
If C# has the standards going for it, plus the blessing of Microsoft, and looks more like C++ than Java, it'll supplant Java quickly in academic settings, which buys Microsoft greater control over the cycle*.
* Schools teach what's in demand, and businesses look to colleges to see what knowledgeable people are using.
You can't remember any others? What the hezmana is wrong with you? ;-)
I haven't yet found anybody who'll pay me to use it, but I do to keep my design skills reasonably close to my coding skills. I've found the statement that "it's only as verbose as it need to be to describe the concepts going on" quite accurate.
It also does a great job of handling multiple inheritance and operator overloading, with keywords to explicitly distinguish infix, prefix, and postfix operators. Constrained genercicity can be a nice tool too.
Since you mentioned "excessive syntax", I figure I'll just quickly ask...
What are your thoughts on Eiffel?
MPC 74xx wuld be an even more accurate way of describing the processor. And Motorola isn't out of the running, if they can deliver with the 7447/7457, 75xx and maybe even some 85xx series processors, they could be a good source of consumer-level chips for Apple.
There are, if memory serves, 32 integer registers, 32 "number" registers, 32 string registers, and 32 "Parrot Magic Cookie" or PMC registers which deal with more complex data.
Actually, AltiVec/VMX(IBM) is basically just a whole mess of extra instructions that result in performance gains for some(but a large "some") applications.
Python modules can be compiled. Write a simple little script that imports your module(which in Python means just about any source file). You'll notice a *.pyc file now hanging out in your directory. Cngratulations, it's Python bytecode.
How about the following?
for @i -> $c { print "$c\n" }
Umm.... you could just buy a Mac and VirtualPC, then install Xfree86 in rootless mode. Seems like a simpler means to the stated end, considering that a Mac running Mac OS X is a "unix box".
Well, it doesn't seem to be able to find GMP with the standard Dev Tools installed. Downloading GMP from the GNU site, and building and installing it seems to have eliminated the problem, though it occasionally gets a few warnings.
Has anyone had luck getting Pike installed on Mac OS X(10.1.x)/Darwin(1.4)?