T
TGOS
One way to think of
what you are trying to do is to design a object engine, where the objects and
the engine between them define the runtime semantics of *any* language that is
implemented on top of those objects. I.e. the syntax of the language is
largely unimportant, but the behaviour of the objects is key.
If that's the route that you are going then you are at some risk of
re-inventing* Smalltalk.
No, just a language with a concept similar to Smalltalk, not quite the
same. After all, I already said "Smalltalk is a better paragon than
Java".
Bullshit like this -- I'm sorry, I can think of no more accurate term -- is a
poor way to repay the people (myself included) over on comp.lang.Smalltalk who
are trying to help you understand the language.
Are you married with Smalltalk? I mean, there is no reason to feel
insulted because I dislike one language of your choice. I write programs
in many languages and if I'd feel offended each time someone doesn't
like one of them... I had to feel offended all the time as there's
always someone who doesn't like one of them ;-)
What I wrote is how I see the language. Smalltalk is rather on a level
with PHP and PERL, than with Java and C, rather BASIC than Pascal,
rather JavaScript than Assembler. It's very high level, too high level.
Disagree as much as you like, but I claim it's impossible to implement
an operating system kernel in Smalltalk (like a Linux kernel) that can
still run at usable speed.
And the syntax is ugly. It uses space as separator... very bad idea. No
other reasonable language does that. I mean, sure you can use spaces
like
int a = 10 + 20;
but you don't have to:
int a=10+20;
There is a reason why other OO languages have a separtor between object
and method name that is not space. And it's very hard to distinguish
object, method and parameters in the first place in Smalltalk. It's a
foolish attemp to build a syntax like a real spoken language (kinda like
AppleScript, that tries to imitate the English language, but have you
ever programmed with AppleScript? Horrible!).
In no other language distinguishing code from comments was so difficult
as in Smalltalk. I know how Smalltalk comments look like, but using
quotations for them is just harder to read than comment chars used by
all the other languages (except BASIC, in most BASIC dialects comments
are hard to read as well, e.g. REM lines).
Just look at code like that:
"Generated from the UML suite
Project: Smalltalk
System: sys"
Object subclass: #Account
instanceVariableNames: 'amount'
classVariableNames: ''
poolDictionaries: ''
category: 'sys'!
!Account class methodsFor: 'instance creation'!
new
"Generated"
^super new initialize! !
!Account methodsFor: 'initialize-release'!
release
super release.
"Start user added code"!
initialize
"Start user added code"! !
!Account methodsFor: 'accessing'!
amount
"Generated"
^amount! !
!Account methodsFor: 'misc'!
printAmount
"Not yet implemented"! !
!Account methodsFor: 'modifying'!
amount: anAmount
"Generated"
amount := anAmount! !
Where do methods start, where do they end? Start and end aren't even
marked. Same for classes. This makes it hard to recognize scoping.
It's not that I'm in love with the C syntax. I programmed most of my
life in Pascal and before that in BASIC only. And if it makes you happy,
I hate most of the PERL syntax, too (while I think PHP is quite
acceptable, as it's "clean" than PERL).