S
Stephen Kellett
James Britt said:
I'm an anon coward because I can't be bothered logging in.
I'm an anon coward because I can't be bothered logging in.
S
Stephen Kellett
Just curious, how long have you been on the net?
Since July 1990. Why?
Stephen
Since July 1990. Why?
Stephen
M
Martin DeMello
Stephen Kellett said:
That picture is a sort of bizarre rite of passage
It even has its ownWikipedia entry: http://en.wikipedia.org/wiki/Goatse.cx
It's very popular with the slashdot troll crowd, which is why so many
people were asking about your slashdot reading habits.
martin
S
Stephen Kellett
Martin DeMello said:That picture is a sort of bizarre rite of passage
Wikipedia entry: http://en.wikipedia.org/wiki/Goatse.cx
You learn something new every day...
I've got to admit I'm surprised that the sys admin at my previous place
of work didn't show me this image - as far as weird images go, this one
fits his sick sense of humour. I was always amazed at the things he'd be
viewing even though his screen was clearly visible from the CEO's
office.
Stephen
S
Stephen Kellett
Christian Neukirchen said:
Thats an amazing image. I'm quite impressed by the height of the plume.
Also totally bizarre that her beaver has been digitally obscured when
you consider what the photo is of.
Stephen
K
Kaspar Schiess
(In response to by Ilias Lazaridis)
[entiry post snipped]
Hello Ilias,
I would like to tell you that we have uncovered your real identity. You are
generated by a bunch of sociologists that are into male dominant behaviour
research.
Or you are just a Turing Test gone very very wrong.
Please do me the favor of answering: My post was trying to cut right trough
the sterility. Please, show some emotion here.
Whatever it is, happy trolling !
kaspar
code manufacture - ruby lab
www.tua.ch/ruby
[entiry post snipped]
Hello Ilias,
I would like to tell you that we have uncovered your real identity. You are
generated by a bunch of sociologists that are into male dominant behaviour
research.
Or you are just a Turing Test gone very very wrong.
Please do me the favor of answering: My post was trying to cut right trough
the sterility. Please, show some emotion here.
Whatever it is, happy trolling !
kaspar
code manufacture - ruby lab
www.tua.ch/ruby
M
Mark Hubbart
Strangely, I had already been reminded of a story where a distributed
AI spread over the net as a worm; It then started impersonating people
on the net.
So it really made me look twice when he mentioned his "limited processing time".
cheers,
Mark
M
Markus Pilzecker
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Austin Ziegler wrote:
| On Thu, 17 Feb 2005 02:04:51 +0900, Markus Pilzecker
|
|>Austin Ziegler wrote:
|>| Actually, Ilias, it is 100% accurate. There is no system in
....
|
| A "generic" model transformer and generator, yes. A framework,
| maybe. It depends on the capabilities. However, properly stated,
| code generation is a toolbox, not a tool.
|
Agreed. It only makes sense, if the transformer|generator framework
is to such an extreme degree customisable, that you can call this
programming.
....
|
| Yes, but a generator isn't necessarily the same as what was being
| talked about. All of the generators that I've ever used have been
| domain and application specific.
At least those modern ones like AndroMDA or ArcStyler are quite
independent of the practical domain. They are of course to some
extent specific to the target technology -- but only in one aspect:
you get delivered object technology for the transformer|generator
framework plus some ``library'' transformers, you can start with.
These latter are partially quite generic like an EJB generator, you
can derive your own specific, lets say Jonas-, generator from.
Partially, you get e.g. a concrete product-specific WLS8 generator.
And for this, of course, it's quite right to speak of specificity
wrt. the target technology.
| Additionally, proper generation
| techniques indicate that you should know how to implement at least
| one of the items you're generating (e.g., if you're developing a
| generated GUI, you should develop at least one screen by hand; the
| same applies to web interfaces, etc.)
|
Well, frankly, I'm not such an expert in EJB-technology, but I'm able
to set up my own hello-world application with a handful of classes
with a running Weblogic Server in a day or so. I do not even have
to have seen the interior of a deployment descriptor[, as long as
things work about as expected ;-) ]. Of course, if it comes to
debugging, while trying to understand, what's going wrong, I
certainly don't get around digging deeper into EJB-technology.
....
|
| Not at all. Code generation is a technique -- a toolbox -- and not a
| silver bullet. It's a very valuable technique, and various tools can
| help with the technique, but there's still *no such (singular) tool*
| to generate an application and make it run everywhere in every way
| that makes it feel right for those platforms. It's a non-soluble
| problem, especially when you get to user interaction and platform
| look-and-feel.
|
Of course, at least one person [or company or whatever] has to perform
this technology [+user interaction, ...] -projection at least once.
It's as at least one person has to write the gcc-backend for the
(n+1)st CPU-type.
| To take a simple example, there's a development tool for mobile
| development called "AppForge". This plugs into a Visual Basic
| development environment and allows you to generate mobile apps for
| the PocketPC, PalmOS, Symbian, Windows Mobile, Windows SmartPhone,
| and a few other targets, I think. The application thus generated
| requires a massive runtime (300Kb on PalmOS systems)
Then, the generator does not [completely] map to the target platform.
The problem probably is, that it is more expensive to implement a
reasonably complete technology projection into a generator than to
implement an emulation layer.
| and doesn't
| look like native applications. Similarly, Java's Swing doesn't look
| or act like any other application on a platform.
|
This is a phenomenon inherent to a portability scenario. Would you
want to overcome this, had you to invest much into flavor-mapping.
Most of the time, it is decided, that it's not worth it.
And you cannot even say, that it is bad, if it does not look as
PalmOS. Me, not knowing PalmOS, may make it feel at home, when I
find something looking like Swing.
| If a developer for the platforms in question can't do it, what makes
| you think that a transformer/generator will be able to do it?
|
I don't think that. A generator will not produce better code than
a good informatician. But since it has the ability to gather some
structural knowledge, it can produce much more code of about the same
quality as that of a good informatician. In the long run, a generator
may gather optimisation knowledge, like peep-hole optimisation, loop
unroling, design patterns, ..., which a programmer can not apply
alltogether in a short enough time.
|
|>| Because such a tool would SUCK. As every single CASE tool in
|>| existence has ever done. CASE tools generally require that you
|>| run a very large runtime, program *their* way, often in *their*
|>| language (which isn't related to anyone else's), and then tend to
|>| fall behind both operating system releases and the technology
|>| curve.
|>Transformer|generator frameworks concentrate the knowledge of the
|>target technology in the transformation engine. At least for
|>simpler scenarios, this does not at all imply generation or use of
|>a runtime system: e.g., if you have modelled your system in
|>ArcStyler and use its Java2-cartridge to generate code of it,
|>there is nothing near to a runtime system, which comes into the
|>game. And the result is [at least beyond javac] as slim as what
|>you could code by hand.
|
|
| Maybe. I'm very skeptical of claims in this direction. Indeed, what
| the OP wanted was something that could be run on an embedded device,
| a workstation, or a cluster of servers. I'm sorry, but I stand by my
| original statement: there's no such tool -- not even ArcStyler --
| which can do that.
Of course, not out of the box. Because this required, that the
transformer|generator knew all _your_ requirements, constraints and
trade-offs in advance. But a good transformer framework can make it
acceptably easy to articulate these specifities.
| (And I'm unsurprised that UML is being pushed
| this way. UML is good for very few things, and the most important
| part of making an n-tier database applications is one of the things
| that UML is worst at: data modeling.
I'm not sure, if it is that bad: define the datatypes of your database
and store that in a profile. Every table is a class with attributes
/*the columns*/ of one the available types. May be, I oversimplified
a bit -- but did I too much?
The other question is, if it _should_ be good at that. At least the
a-priori assumption was[ according to some human judgement of a certain
community], that OO is superior to ER. And if you have legacy RDBMSs,
you have specify some OR-mapping -- most probably somewhere in your
transformer model. If you don't have that legacy, you could have that
mapping undercover -- or you use an object database anyway. In these
latter cases, you won't have to model any ER part.
| It's too based on OO
| technologies to even remotely come close to properly modeling data
| relationships other than hierarchical.)
|
Where is the restriction to hierarchies? I think, I'm able to draw
general graphs...
| [major snippage]
|
|
| Again, maybe. ArcStyler and other OMG-driven insanities won't help.
If you criticised, that abstraction requirements on those, who have
to program the transformers, misses market availability, you may have
got me to agree. And of course, commitee compromises tend to be far
from satisfying. But using transformers to convert graphs, be it
on MOF-level-1 or on MOF-level-0[, which is the usual case in ``normal
programming'',] or between level 1 and level 0 [or between 2 an 1]
is a paradigm, I won't easily give up.
| Being able to state requirements clearly will.
|
Ack.
A+, Markus
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.6 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org
iD8DBQFCFKX90sM4x4ItYcQRAmH7AJ9o/yZQ4hST16qJvwRwqfkEup0uXACfUWle
nEZ3yXqJ6GWyVIBmi9W95eU=
=VTmZ
-----END PGP SIGNATURE-----
Hash: SHA1
Austin Ziegler wrote:
| On Thu, 17 Feb 2005 02:04:51 +0900, Markus Pilzecker
|
|>Austin Ziegler wrote:
|>| Actually, Ilias, it is 100% accurate. There is no system in
....
|
| A "generic" model transformer and generator, yes. A framework,
| maybe. It depends on the capabilities. However, properly stated,
| code generation is a toolbox, not a tool.
|
Agreed. It only makes sense, if the transformer|generator framework
is to such an extreme degree customisable, that you can call this
programming.
....
|
| Yes, but a generator isn't necessarily the same as what was being
| talked about. All of the generators that I've ever used have been
| domain and application specific.
At least those modern ones like AndroMDA or ArcStyler are quite
independent of the practical domain. They are of course to some
extent specific to the target technology -- but only in one aspect:
you get delivered object technology for the transformer|generator
framework plus some ``library'' transformers, you can start with.
These latter are partially quite generic like an EJB generator, you
can derive your own specific, lets say Jonas-, generator from.
Partially, you get e.g. a concrete product-specific WLS8 generator.
And for this, of course, it's quite right to speak of specificity
wrt. the target technology.
| Additionally, proper generation
| techniques indicate that you should know how to implement at least
| one of the items you're generating (e.g., if you're developing a
| generated GUI, you should develop at least one screen by hand; the
| same applies to web interfaces, etc.)
|
Well, frankly, I'm not such an expert in EJB-technology, but I'm able
to set up my own hello-world application with a handful of classes
with a running Weblogic Server in a day or so. I do not even have
to have seen the interior of a deployment descriptor[, as long as
things work about as expected ;-) ]. Of course, if it comes to
debugging, while trying to understand, what's going wrong, I
certainly don't get around digging deeper into EJB-technology.
....
|
| Not at all. Code generation is a technique -- a toolbox -- and not a
| silver bullet. It's a very valuable technique, and various tools can
| help with the technique, but there's still *no such (singular) tool*
| to generate an application and make it run everywhere in every way
| that makes it feel right for those platforms. It's a non-soluble
| problem, especially when you get to user interaction and platform
| look-and-feel.
|
Of course, at least one person [or company or whatever] has to perform
this technology [+user interaction, ...] -projection at least once.
It's as at least one person has to write the gcc-backend for the
(n+1)st CPU-type.
| To take a simple example, there's a development tool for mobile
| development called "AppForge". This plugs into a Visual Basic
| development environment and allows you to generate mobile apps for
| the PocketPC, PalmOS, Symbian, Windows Mobile, Windows SmartPhone,
| and a few other targets, I think. The application thus generated
| requires a massive runtime (300Kb on PalmOS systems)
Then, the generator does not [completely] map to the target platform.
The problem probably is, that it is more expensive to implement a
reasonably complete technology projection into a generator than to
implement an emulation layer.
| and doesn't
| look like native applications. Similarly, Java's Swing doesn't look
| or act like any other application on a platform.
|
This is a phenomenon inherent to a portability scenario. Would you
want to overcome this, had you to invest much into flavor-mapping.
Most of the time, it is decided, that it's not worth it.
And you cannot even say, that it is bad, if it does not look as
PalmOS. Me, not knowing PalmOS, may make it feel at home, when I
find something looking like Swing.
| If a developer for the platforms in question can't do it, what makes
| you think that a transformer/generator will be able to do it?
|
I don't think that. A generator will not produce better code than
a good informatician. But since it has the ability to gather some
structural knowledge, it can produce much more code of about the same
quality as that of a good informatician. In the long run, a generator
may gather optimisation knowledge, like peep-hole optimisation, loop
unroling, design patterns, ..., which a programmer can not apply
alltogether in a short enough time.
|
|>| Because such a tool would SUCK. As every single CASE tool in
|>| existence has ever done. CASE tools generally require that you
|>| run a very large runtime, program *their* way, often in *their*
|>| language (which isn't related to anyone else's), and then tend to
|>| fall behind both operating system releases and the technology
|>| curve.
|>Transformer|generator frameworks concentrate the knowledge of the
|>target technology in the transformation engine. At least for
|>simpler scenarios, this does not at all imply generation or use of
|>a runtime system: e.g., if you have modelled your system in
|>ArcStyler and use its Java2-cartridge to generate code of it,
|>there is nothing near to a runtime system, which comes into the
|>game. And the result is [at least beyond javac] as slim as what
|>you could code by hand.
|
|
| Maybe. I'm very skeptical of claims in this direction. Indeed, what
| the OP wanted was something that could be run on an embedded device,
| a workstation, or a cluster of servers. I'm sorry, but I stand by my
| original statement: there's no such tool -- not even ArcStyler --
| which can do that.
Of course, not out of the box. Because this required, that the
transformer|generator knew all _your_ requirements, constraints and
trade-offs in advance. But a good transformer framework can make it
acceptably easy to articulate these specifities.
| (And I'm unsurprised that UML is being pushed
| this way. UML is good for very few things, and the most important
| part of making an n-tier database applications is one of the things
| that UML is worst at: data modeling.
I'm not sure, if it is that bad: define the datatypes of your database
and store that in a profile. Every table is a class with attributes
/*the columns*/ of one the available types. May be, I oversimplified
a bit -- but did I too much?
The other question is, if it _should_ be good at that. At least the
a-priori assumption was[ according to some human judgement of a certain
community], that OO is superior to ER. And if you have legacy RDBMSs,
you have specify some OR-mapping -- most probably somewhere in your
transformer model. If you don't have that legacy, you could have that
mapping undercover -- or you use an object database anyway. In these
latter cases, you won't have to model any ER part.
| It's too based on OO
| technologies to even remotely come close to properly modeling data
| relationships other than hierarchical.)
|
Where is the restriction to hierarchies? I think, I'm able to draw
general graphs...
| [major snippage]
|
|
| Again, maybe. ArcStyler and other OMG-driven insanities won't help.
If you criticised, that abstraction requirements on those, who have
to program the transformers, misses market availability, you may have
got me to agree. And of course, commitee compromises tend to be far
from satisfying. But using transformers to convert graphs, be it
on MOF-level-1 or on MOF-level-0[, which is the usual case in ``normal
programming'',] or between level 1 and level 0 [or between 2 an 1]
is a paradigm, I won't easily give up.
| Being able to state requirements clearly will.
|
Ack.
A+, Markus
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.6 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org
iD8DBQFCFKX90sM4x4ItYcQRAmH7AJ9o/yZQ4hST16qJvwRwqfkEup0uXACfUWle
nEZ3yXqJ6GWyVIBmi9W95eU=
=VTmZ
-----END PGP SIGNATURE-----
C
Curt
Have you considered upgrading?
S
Stephen Kellett
Curt said:
Careful, his 16Kb RAM pack might wobble!
[I wonder how many of you know what that is a reference to?]
Stephen
S
Steve Longdo
Would that be a Sinclair ZX-81 reference?
A
Austin Ziegler
On Thu, 17 Feb 2005 23:14:51 +0900, Markus Pilzecker
I'm still highly skeptical. I don't doubt the value and efficiency
benefit from code generation: I was one of the many technical
reviewers on Jack Herrington's _Code Generation in Action_ and it's
an amazingly useful book. But I've seen entirely too many situations
where UML has been abused and misused.
That said, I also think that most modern frameworks are far larger
than they need to be, and I think that Rails, Nitro, Wee, and IOWA
are excellent examples of what can be done if you have a highly
expressive language and don't have to write ten thousand helper
classes. I also don't think that UML simplifies matters in the
least.
ArcStyler looks impressive -- and it will be a tool that I
investigate should I ever need to work in one of these crazy
environments again. But I'll probably lean more toward the CGiA
approach rather than another expensive tool that makes it difficult
to migrate from.
[big snip]
Yes, actually. The language behind UML lends itself well to class
definition, but not so well to relation definition. In my logical
model, I might have:
+-+0..* 0..*+-+
|L|----------|R|
+-+ +-+
Where L and R represent tables that have many-to-many relations with
each other. In practice, this is almost always implemented
relationally as:
+-+0..* 0..*+-+0..* 0..*+-+
|L|----------|M|----------|R|
+-+ +-+ +-+
Where M is that many-to-many relation table. There's no way that
would ever be represented that way in UML. In all likelihood, the
class L would contain a set of Rs. This sets up a one-way-browse
situation. To bring it a bit more concrete, if L is a customer and R
is a rate package, then many customers may have a single rate
package and some customers may have multiple rate packages. The
proper relationship in an OO hierarchy in this case is that an L
owns zero or more Rs. Without setting up a cyclical hierarchy or
scanning the set of Ls for all their Rs, you have no way of knowing
which Rs are used by what Ls. In a relational database, this is
easy -- and the modeling as such is very different.
Well, the problem is that object databases are simply a repeat of
hierarchical databases. The object graphs are typically one way, not
two way. Relational databases describe relationships and are and
always will be superior to object databases, despite the impedance
mismatch that most people have when converting from the open-ended
relationship description in relational databases and the closed-
ended relationship description in most OO languages.
So yes, the a priori assumption was that OO is superior to ER, but
that assumption is unequivocally wrong. OO makes the mistake of
putting the data on equal footing as the application. Considering
that a lot of people developed applications without concern for the
data, this was an important step forward in theoretical circles. In
practice, businesses *always* consider their data more valuable than
their programs. OO turns this on its head by tying the data so
tightly to the program that the data becomes difficult to use in any
other way.
Yes, I'm biased. I saw a company that I worked for spend many
millions of dollars on implementing a system that was designed by
hotshot college graduates who had been filled with the worst sort of
OO design garbage and had absolutely no data modeling skills to
understand their data separately from their object model. The system
took thirty seconds to simply authenticate users -- and they
couldn't get it under seven seconds. The version of the system that
I worked on was much more realistically developed and had a good,
strong data model that drove the object design. Ultimately, the
expensive project that was heavy on UML and related technologies was
killed and many of the developers were integrated into the team that
I worked on.
The OMG isn't a disinterested observer here. Neither, ultimately,
are you, as you work for the makers of ArcStyler. But UML holds very
hollow promises for anything smaller than an enterprise billing
system -- and its promises there aren't much better, because it adds
a lot of overhead. Data modeling is the single most important skill
that any developer can learn; if you can learn to model your data,
you can learn to make good objects than have better reuse
characteristics.
You can, sort of. But for a variety of reasons, you're not going to,
and UML actively discourages it. See my discussion above on the one-
way-browsing problem.
-austin
I'm still highly skeptical. I don't doubt the value and efficiency
benefit from code generation: I was one of the many technical
reviewers on Jack Herrington's _Code Generation in Action_ and it's
an amazingly useful book. But I've seen entirely too many situations
where UML has been abused and misused.
That said, I also think that most modern frameworks are far larger
than they need to be, and I think that Rails, Nitro, Wee, and IOWA
are excellent examples of what can be done if you have a highly
expressive language and don't have to write ten thousand helper
classes. I also don't think that UML simplifies matters in the
least.
ArcStyler looks impressive -- and it will be a tool that I
investigate should I ever need to work in one of these crazy
environments again. But I'll probably lean more toward the CGiA
approach rather than another expensive tool that makes it difficult
to migrate from.
[big snip]
Yes, actually. The language behind UML lends itself well to class
definition, but not so well to relation definition. In my logical
model, I might have:
+-+0..* 0..*+-+
|L|----------|R|
+-+ +-+
Where L and R represent tables that have many-to-many relations with
each other. In practice, this is almost always implemented
relationally as:
+-+0..* 0..*+-+0..* 0..*+-+
|L|----------|M|----------|R|
+-+ +-+ +-+
Where M is that many-to-many relation table. There's no way that
would ever be represented that way in UML. In all likelihood, the
class L would contain a set of Rs. This sets up a one-way-browse
situation. To bring it a bit more concrete, if L is a customer and R
is a rate package, then many customers may have a single rate
package and some customers may have multiple rate packages. The
proper relationship in an OO hierarchy in this case is that an L
owns zero or more Rs. Without setting up a cyclical hierarchy or
scanning the set of Ls for all their Rs, you have no way of knowing
which Rs are used by what Ls. In a relational database, this is
easy -- and the modeling as such is very different.
Well, the problem is that object databases are simply a repeat of
hierarchical databases. The object graphs are typically one way, not
two way. Relational databases describe relationships and are and
always will be superior to object databases, despite the impedance
mismatch that most people have when converting from the open-ended
relationship description in relational databases and the closed-
ended relationship description in most OO languages.
So yes, the a priori assumption was that OO is superior to ER, but
that assumption is unequivocally wrong. OO makes the mistake of
putting the data on equal footing as the application. Considering
that a lot of people developed applications without concern for the
data, this was an important step forward in theoretical circles. In
practice, businesses *always* consider their data more valuable than
their programs. OO turns this on its head by tying the data so
tightly to the program that the data becomes difficult to use in any
other way.
Yes, I'm biased. I saw a company that I worked for spend many
millions of dollars on implementing a system that was designed by
hotshot college graduates who had been filled with the worst sort of
OO design garbage and had absolutely no data modeling skills to
understand their data separately from their object model. The system
took thirty seconds to simply authenticate users -- and they
couldn't get it under seven seconds. The version of the system that
I worked on was much more realistically developed and had a good,
strong data model that drove the object design. Ultimately, the
expensive project that was heavy on UML and related technologies was
killed and many of the developers were integrated into the team that
I worked on.
The OMG isn't a disinterested observer here. Neither, ultimately,
are you, as you work for the makers of ArcStyler. But UML holds very
hollow promises for anything smaller than an enterprise billing
system -- and its promises there aren't much better, because it adds
a lot of overhead. Data modeling is the single most important skill
that any developer can learn; if you can learn to model your data,
you can learn to make good objects than have better reuse
characteristics.
You can, sort of. But for a variety of reasons, you're not going to,
and UML actively discourages it. See my discussion above on the one-
way-browsing problem.
-austin
B
Bill Guindon
That's the first thing I thought of too, so even if it's not...
/who greenlighted this thread?
//It's not Ruby, it's Fark!
///yes, slashing can be addictive.
/who greenlighted this thread?
//It's not Ruby, it's Fark!
///yes, slashing can be addictive.
I
Ilias Lazaridis
I'm closing this thread.
It's always fascinating to see how a few people can completely ruin the
image of a community.
Really diaspointing.
..
It's always fascinating to see how a few people can completely ruin the
image of a community.
Really diaspointing.
..
I
Ilias Lazaridis
Martin said:
This is too much.
It should not take more than 1 hour.
ok, I understand.
I've not used Nitro or Wee, but I've heard good things about
both of those too.
ok
Non-web GUIs - http://www.rubygarden.org/ruby?ComparingGuiToolkits
ok
As for objects, it's nigh impossible to use Ruby *without* creating
them
ok
Surfing the Rubygarden wiki and the newsgroup archives should garner you
a lot more.
ok
martin
Thank you for your gentle answers.
..
B
Ben Giddings
Ilias said:
No, you're not. It will live on forever.
Actually, I think this will go on to prove how incredibly friendly and
helpful the Ruby community is. Despite the fact you're an obvious
troll, and have been banned from a number of other groups, despite your
insulting posts, despite your valiant attempts to start flame wars...
there were a lot of people who were friendly, and helpful, and nice to you.
I, for one, am amazed and proud that in a discussion of this size,
virtually nobody lost their cool, and only one goatse.cs picture was
posted -- and even the follow-ups to that were friendly and fun.
Congrats ruby-talk, I'd say you won this one.
Ben
S
Stephen Kellett
Steve Longdo said:
Well done. Take a bow. I didn't think there were that many of us
slightly older folks around.
Or for US/Canadian folks, a Timex something or other.
Stephen
I
Ilias Lazaridis
Ben said:
You're right.
I've just reopened it, to answer you.
until all usenet archives go down.
"incredibly friendly"
"helpful"
"insulting posts"
"valiant attempts to start flame wars"
"virtually nobody lost their cool"
And this is the most sad part of all this.
That you (and possibly most others) believe that all this is true [and
even if true, an achievement].
-
I'm wondering If anyone fo the posters has the courage to see what
essentially happened here.
And if anyone has the gentleness to apologize.
Possibly after reviewing this thread again after a few days.
..
S
Stephen Kellett
Ilias Lazaridis said:
The only person that should apologize to any of the newsgroups you've
been in is yourself. That amount of times you were given on-topic
answers that you just shrug off with "I have not read it, it is off
topic". Arrogance and selfishness beyond belief.
Stephen
S
Stephan Kämper
Stephen said:
I can remember pretty well sitting (closely) in front of a TV set with a
friend of mine - one browsing Rodney Zaks' 'Programming the Z-80' the
other typing hex code into REM lines. Was that pair programming already? ;-)
Ahhh, those were the days...
....which I don't really miss that much now that I have Ruby.
Happy rubying
Stephan