OO Challenge

[Henry Gilbert]

Dear Ruby Community,

One day I hope to learn your trade :)

But before that ...
A reasonably arrogant guy came out blasting in a web-forum about how OO is
crap and all that.

He offered a challenge which I tried to defeat but in VB.NET
Now VB.NET sucks simply because the Visual Studio IDE that comes with it
is all very boring, slow, bureacratic, clunky and when you get a spark of
inspiration it hangs saying "Please wait while we update your Help File"
(for 20 minutes)

Pure Joy-Killer

His challenge is as follows:

* I wont give the URL yet because I want you guys to come with the best
solution, don't worry I wont take credit for it - will post the website
and say this is the RUBY's solution loggin in as Anonymous *

[QUOTE]

Whole OO is step back in programming. Encapsulation is trivial
and unnecessary, inheritance wrong and polymorphism weak ..

OK, here is my favorite 'Tax Payer' challenge for OO languages. There are lot of different groups of people with different rules for tax calculation. One man can be in the same time member of many groups. His membership can change during program execution time. If he is member of many groups in the time tax is calculated, his tax is the greatest one on the base of all groups he is member (they are clever!). Natural situation, isn't it? Now, (1) define separate functions that calculate tax for each groups, and (2) write polymorphic function that calculate tax for tax payer, no matter of his membership to one or many groups in the same time. Here is code in procedural language: record tax_payer(salary,member_of)

[Version 1]

procedure tax_soldier(X)
return X.salary/10.0
end

procedure tax_professor(X)
return X.salary/15.0+100
end

#many of them ...

procedure tax(X) #procedural polymorphism
result:=0
every class:=!X.member_of do
if result then result:=t
return result
end

procedure main()
A:=tax_payer(3000,["soldier"])
B:=tax_payer(5000,["professor"])
C:=tax_payer(6000,["professor","soldier"])
#...
write(tax(A),tax(B),tax(C)) #this line is goal
end

[Added to Version 1]

Oh, board ignored part of the procedure tax(), here it is again ...

procedure tax(X)
result:=0
every class:=!X.member_of do
if result less_than t:=proc("tax_"||class)(X) then result:=t
return result
end

[Version 2]

Here is the procedural version of your second program:

record tax_payer(salary,member_of)
record tax_rule_data(multiplier, additional)
global tax_rule

procedure tax(payer)
* * res:=0
* * every r:=tax_rule[! payer.member_of ] do
* * * * * * * if res less_than t:=payer.salary/r[1]+r[2]
* * * * * * * * * * * * * * * * * * * * then res:=t
* * return res
end

procedure main()
* * tax_rule:=table()
* * tax_rule["soldier"]:=tax_rule_data(10,0)
* * tax_rule["professor"]:=tax_rule_data(15,100)
* * A:=tax_payer(1000,["soldier","professor"])
* * write(tax(A))
end

That is actual code in Icon, not pseudocode, just like my previous program.
I believe I have my point about elegance.
I do not think that Tax Payer problem deserves to be called 'functional problem' - it is simple problem every general programming language should be able to solve easily and with elegance. Such problems are everywhere. It is not exotic automated theorem proving problem ... neither is proc() non-procedural.. actually, I remember Sinclair ZX 81 had similar GO SUB (expression) statement. Sure, it is slower, but worked well even then, on 1000 times slower comp and 20 000 times smaller memory.
Tax Payer problem is all about object (tax_payer) - class (soldier ...) membership and polimorphic functions, just it is not that simple as designers of OO languages believe (object is member of only one class (and superclasses) and does not change its membership, function version can be decided solely on class membership) - hence one is forced to handle membership relation on his own, and OO support integrated in the language is shown to be restrictive and cluttering. Proof is in the puding - compare Icon and Java code.
It is not the only problem with OO. Inheritance rules are even worse; almost everything in that concept is wild guess, and code is always much worse.
If anyone disagree and he think he has problem where OO is better, i accept the challenge.

[/UNQUOTE]


So sorry for the abuse in pasting.
Now I started solving this in VB.NET
But just to be vindictive lol .. wanted to most beautiful solution ever.
Which I believe RUBY can deliver.
This guy is talking crap.

My version in VB would be pure syntatic sugar.
But its fundamental we had an eval function
ie eval "3 + 4 / 7" returns 1
I tried to import that from JScript Library
And "bureacratic" Visual Studio started asking me to reflect on which
Engine, for which I tried to look into the help files: and it began
pissing me off with insert CD this, wait until we update your files .. and
a second time wait until we update your file, now insert CD number 2 ..
[note when I first installed I explicitily asked VS to loads ALL Library
and also saved the Library Locally but VS is just thick]

My version should have a Main more or less like:

Sub Main()

Dim ListOfTaxRules As New TaxRules
Dim ListOfTaxPayers As New TaxPayers
Dim Member As Object

With ListOfTaxTules
.Add("soldier","/10")
.Add("teacher","/15+2000")
.Add("professor","/12+1000")
End WIth

With ListOfTaxPayers
.Add("John","soldier",30000)
.Add("Mary","teacher",15000)
.Add("Gary",{"professor","soldier"},50000)
End With

For Each Member As Object In ListOfTaxPayers.List
Console.WriteLine(Member.Name,Member.CalculatedTax )
Next

End Sub

Of course I am abusing the VB.NET as Much as possible.
For the sake of readability and winning the challenge :P

I haven't supplied code for the Classes because I got stuck on importing
the Eval function from Microsoft.Jscript Library.
Which would also tarnish the "elegant" solution

There are many ways round to this problem - and the most concise and yet beautiful
easy to read .. should be considered.
So please venture completely different routes - so we can breed the best
one.

Of course his challenge is stupid, because OO languages excel on a large
scale, not on such simple things. But still I am confident there is a
solution to his silly challenge.

Thanks for your attention.
Would love to learn from you all RUBY sometime.
For another abandoned .NET project - an English Online Website
I was going to build for free - and being GPL
(Any takers? :)

All the best

Henry Gilbert

[Robert Feldt]

Henry Gilbert <nospam@alliancetec.com> skrev den Fri, 12 Sep 2003 21:37:04 +0900:

> record tax_payer(salary,member_of)
> record tax_rule_data(multiplier, additional)
> global tax_rule
>
> procedure tax(payer)
> * * res:=0
> * * every r:=tax_rule[! payer.member_of ] do
> * * * * * * * if res less_than t:=payer.salary/r[1]+r[2]
> * * * * * * * * * * * * * * * * * * * * then res:=t
> * * return res
> end
>
> procedure main()
> * * tax_rule:=table()
> * * tax_rule["soldier"]:=tax_rule_data(10,0)
> * * tax_rule["professor"]:=tax_rule_data(15,100)
> * * A:=tax_payer(1000,["soldier","professor"])
> * * write(tax(A))
> end
>

Without any refactoring or rethinking of his "problem" here
is a Ruby version:

Rule = Struct.new("Rule", :multiplier, :additional)
class Rule
def calc_tax(salary)
salary/(multiplier || 1) + (additional || 0)
end
end

Rules = {"soldier" => Rule.new(10.0, 0), "professor" => Rule.new(15.0, 100)}

TaxPayer = Struct.new("TaxPayer", :salary, :member_of)
class TaxPayer
def tax
Rules.select {|n,r| member_of.include?(n)}.map do |profession, rule|
rule.calc_tax(salary)
end.max end
end

a = TaxPayer.new(1000, ["soldier", "professor"])
p a.tax # => 166.666666667

Not the way I would structure this but its close to his code.
Which one is more "elegant" is subjective IMHO but I don't think
he has got a strong case... ;)

It also seems like a lousy example for comparisons between languages
and paradigms. Then again most such comparisons are a lousy idea... ;)

Regards,

Robert

[Robert Klemme]

"Robert Feldt" <feldt@ce.chalmers.se> schrieb im Newsbeitrag
news:oprvd068apoglyup@mail1.telia.com...
[snip]

I prefer this approach since it is more OO in the sense that rules and
their names are better bound together.

robert


require 'set'

# abstract base, not really needed
class TaxGroup
class << self
attr_reader :all_groups

def inherited(gr)
$stderr.puts "Group #{gr}"
( @all_groups ||= Set.new ) << gr
end
end
end

# tax groups
class TaxGroupSoldier < TaxGroup
def calc_tax(emp)
emp.salary/10.0
end
end

class TaxGroupProf < TaxGroup
def calc_tax(emp)
emp.salary/15.0+100
end
end

# tax payers
class TaxPayer
attr_reader :tax_groups
attr_accessor :salary

def initialize(sal, groups = [])
@salary = sal
@tax_groups = Set.new
@tax_groups.merge groups
end

def tax()
self.tax_groups.map do |gr|
gr.new.calc_tax(self)
end.max
end
end

# example
taxPayers = [
TaxPayer.new(3000,[TaxGroupSoldier]),
TaxPayer.new(5000,[TaxGroupProf]),
TaxPayer.new(6000,[TaxGroupProf, TaxGroupSoldier]),
]

taxPayers.each do |p|
puts "#{p.inspect}: #{p.tax}"
end

[Weirich, James]

I'll throw in my version. Logically it is structured very much like Robert
Klemme's except that I made lighter weight choices for some of the
abstractions. For example, I use simple procs for the tax groups and my
TaxPayer is Struct based. What is really interesting is that despite the
differences in representation, the last bits of our programs are identical
except for minor spelling differences.

Here's the code.

-----------------------------------------------------
Soldier = proc { |p| p.salary / 10.0 }
Professor = proc { |p| p.salary / 15.0 + 100 }

TaxPayer = Struct.new(:salary, :tax_classes)
class TaxPayer
def tax
tax_classes.collect { |tc| tc.call(self) }.max
end
end

taxpayers = [
TaxPayer.new(3000, [Soldier])
TaxPayer.new(5000, [Professor])
TaxPayer.new(6000, [Professor, Soldier])
]

Taxpayers.each { |tp| printf "%0.2f\n", tp.tax }
----------------------------------------------------

Disclaimer: I don't believe this example says anything deep or significant
about OO verse non-OO.

--
-- Jim Weirich / Compuware
-- FWP Capture Services
-- Phone: 859-386-8855

[Robert Klemme]

"Weirich, James" <James.Weirich@FMR.COM> schrieb im Newsbeitrag
news:1C8557C418C561429998C1F8FBB283A728BA48@MSGDAL CLB2WIN.DMN1.FMR.COM...

> I'll throw in my version. Logically it is structured very much like

Robert

> Klemme's except that I made lighter weight choices for some of the
> abstractions. For example, I use simple procs for the tax groups and my
> TaxPayer is Struct based. What is really interesting is that despite

the

> differences in representation, the last bits of our programs are

identical

> except for minor spelling differences.

Probably there's not too much room for variations with this small example.
Or we think along the same lines. Could be interesting to see with what
others come up.

Rereading the original posting I think the author of these lines has not
yet fully understand OO:

"Tax Payer problem is all about object (tax_payer) - class (soldier ...)
membership and polimorphic functions, just it is not that simple as
designers of OO languages believe (object is member of only one class (and
superclasses) and does not change its membership, function version can be
decided solely on class membership) - hence one is forced to handle
membership relation on his own, and OO support integrated in the language
is shown to be restrictive and cluttering."

In fact there are only few languages in which an instance can change its
class at runtime. I'm not sure about belonging to several classes at the
same time. Even if there were, I'd be curios how that should be modelled
(after all you have to invoce *all* calculation methods before deciding on
the return value.)

But that doesn't necessarily mean that OO languages are not well suited
for this problem. In fact, any of the ruby solutions looks cleaner to me
than the VB examples. My 2 cent...

> Here's the code.

[snip]

Great short implementation! I always like to see how small programs can
get in Ruby. Unfortunately that reminds me that I sometimes do seem to
make things unnecessary complicated... *sigh*

OTOH we don't know what these groups are supposed to do other than
calculating the tax value. They sure have some weird code that uniquely
identifies... :-)

> Disclaimer: I don't believe this example says anything deep or
> significant about OO verse non-OO.

Very much indeed so. I still wonder why the OP did not put the original
link here - if there is any at all...

Regards

robert

[Richard Dale]

Weirich, James wrote:

> I'll throw in my version. Logically it is structured very much like
> Robert Klemme's except that I made lighter weight choices for some of the
> abstractions. For example, I use simple procs for the tax groups and my
> TaxPayer is Struct based. What is really interesting is that despite the
> differences in representation, the last bits of our programs are identical
> except for minor spelling differences.
>
> Here's the code.
> def tax
> tax_classes.collect { |tc| tc.call(self) }.max
> end

I like James' solution best because he has tax_classes 'collect'ing - which
seems to model the real world well :).

-- Richard

[Weirich, James]

From: Robert Klemme [mailto:bob.news@gmx.net]

> "Weirich, James" <James.Weirich@FMR.COM> schrieb im Newsbeitrag

> > [...] last bits of our programs are identical
> > except for minor spelling differences.

>
> Probably there's not too much room for variations with this
> small example.

Add the abstractions were fairly well identified by the OP as well. What's
significant (IMHO) is that once the abstractions are set, the code using
those abstractions is pretty straight-forward.

> Rereading the original posting I think the author of these lines has not
> yet fully understand OO:

I think you are talking about the Icon programmer here. What I find
interesting is that he denigrates OO, but provides a solution that depends
on a polymorphic function (although he implements the polymorphism by hand).

> In fact, any of the ruby solutions looks cleaner to me
> than the VB examples. My 2 cent...

Actually, I think the first example is Icon, not VB. But I agree, the Ruby
stuff does look cleaner to me.

> Great short implementation! I always like to see how small
> programs can get in Ruby. Unfortunately that reminds me that
> I sometimes do seem to make things unnecessary complicated...
> *sigh*

Actually, I think my example is a little over simplified for real life work.
Using a proc for the tax group is cute, but doesn't reflect the abstraction
well (you have to use "call" instead of something more descriptive). A
slightly longer version would be ...

class SimpleTaxClass
def initialize(&block)
@calculations = block
end
def calculate_tax(tp)
@calculations.call(tp)
end
end

Soldier = SimpleTaxClass.new { |tp| tp.salary / 10.0 }
Professor = SimpleTaxClass.new { |tp| tp.salary / 15.0 + 100 }
etc...

The problem gets interesting when you start throwing changes at it. For
example, what if there was another class of taxpayer that selected the
minimum tax charge. We could code this up as ...

class Politician < TaxPayer
def tax
@tax_classes.collect { |tc| tc.calculate_tax(self) }.min
end
end

Then we can have ...

taxpayers = [
TaxPayer.new(3000, [Soldier]),
Politician.new(4000, [Soldier, Professor])
]

Now think about what it would take to have the politician behavior
determined at runtime. Fun stuff.

--
-- Jim Weirich / Compuware
-- FWP Capture Services
-- Phone: 859-386-8855

[Eric Hodel]

--/GPgYEyhnw15BExa
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

Henry Gilbert (nospam@alliancetec.com) wrote:

> OK, here is my favorite 'Tax Payer' challenge for OO languages.

> There are lot of different groups of people with different rules
> for tax calculation.

Ok... Different groups of people

> One man can be in the same time member of many groups.

Ok... A person is in one or more groups

> If he is member of many groups in the time tax is calculated, his
> tax is the greatest one on the base of all groups he is member.

Ok... A person calculates his tax based on which groups he is in.

> Now, (1) define separate functions that calculate tax for each
> groups, and (2) write polymorphic function that calculate tax for
> tax payer, no matter of his membership to one or many groups in the
> same time. Here is code in procedural language: record
> tax_payer(salary,member_of)
> =20
> Tax Payer problem is all about object (tax_payer) - class (soldier
> ...) membership and polimorphic functions,

In most of the Ruby solutions, the person is the one calculating
the tax, the tax groups don't calculate how much tax a person owes.

> just it is not that simple as designers of OO languages believe
> (object is member of only one class (and superclasses) and does not
> change its membership, function version can be decided solely on
> class membership) - hence one is forced to handle membership relation
> on his own, and OO support integrated in the language is shown to
> be restrictive and cluttering.

A person is in one or more tax groups, which suggests that the
person should hold which professions they are in, not the other way
around. (With a trivial bit of work, you could have the profession
hold all the people who are in that profession as well, but that is not
useful for the example proposed.)

> It is not the only problem with OO. Inheritance rules are even
> worse; almost everything in that concept is wild guess, and code
> is always much worse.

If you have to fight your language, you're doing something wrong. The
easy way is probably the right way. The real problem here seems to be
that the poster doesn't understand how to model problems in OO.

--=20
Eric Hodel - [email]drbrain@segment7.net[/email] - [url]http://segment7.net[/url]
All messages signed with fingerprint:
FEC2 57F1 D465 EB15 5D6E 7C11 332A 551C 796C 9F04


--/GPgYEyhnw15BExa
Content-Type: application/pgp-signature
Content-Disposition: inline

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.2 (FreeBSD)

iD8DBQE/YgQMMypVHHlsnwQRAlOnAKCq78so5q4US/Y7Xm6a8Dzjk+nWxQCZAX3H
wJvXFR9PdnmcbHwW4DUUdGE=
=nMz9
-----END PGP SIGNATURE-----

--/GPgYEyhnw15BExa--

[Sean O'Dell]

Henry Gilbert wrote:[quote]
> Dear Ruby Community,
>
> One day I hope to learn your trade :)
>
> But before that ...
> A reasonably arrogant guy came out blasting in a web-forum about how OO is
> crap and all that.
>
> He offered a challenge which I tried to defeat but in VB.NET
> Now VB.NET sucks simply because the Visual Studio IDE that comes with it
> is all very boring, slow, bureacratic, clunky and when you get a spark of
> inspiration it hangs saying "Please wait while we update your Help File"
> (for 20 minutes)
>
> Pure Joy-Killer
>
> His challenge is as follows:
>
> * I wont give the URL yet because I want you guys to come with the best
> solution, don't worry I wont take credit for it - will post the website
> and say this is the RUBY's solution loggin in as Anonymous *
>
>

>
> Whole OO is step back in programming. Encapsulation is trivial
> and unnecessary, inheritance wrong and polymorphism weak ..
>
> OK, here is my favorite 'Tax Payer' challenge for OO languages. There are lot of different groups of people with different rules for tax calculation. One man can be in the same time member of many groups. His membership can change during program execution time. If he is member of many groups in the time tax is calculated, his tax is the greatest one on the base of all groups he is member (they are clever!). Natural situation, isn't it? Now, (1) define separate functions that calculate tax for each groups, and (2) write polymorphic function that calculate tax for tax payer, no matter of his membership to one or many groups in the same time. Here is code in procedural language: record tax_payer(salary,member_of)

For such a small variation, OO has little to offer. Morphing is usually
for when a class can be extended, especially when a series of extensions
can reduce code. Simply switching the tax rate between different
professions is so simple, an OO solution is likely to ADD code, not
reduce it.

However, that said, I think Ruby has a lot to offer to make this
succinct. My code is below. It's not meant to be short, it's meant to
be understandable and easily extensible.


rates = {
"soldier" => Proc.new{|salary| salary/10},
"professor" => Proc.new{|salary| (salary/15)+100}
}

taxpayers = [
{"salary" => 3000, "jobs" => ["soldier"]},
{"salary" => 5000, "jobs" => ["professor"]},
{"salary" => 6000, "jobs" => ["professor", "soldier"]}
]


taxpayers.each do | taxpayer |
tax = 0

taxpayer["jobs"].each do | job |
rate = rates[job]
raise "no such job in rate schedule: '#{job}'" if (not rate)

rate_tax = rate.call(taxpayer["salary"])

tax = rate_tax if (rate_tax > tax)
end

print(tax)
end


Sean O'Dell

[Henry Gilbert]

On Fri, 12 Sep 2003 13:31:00 +0100, Henry Gilbert wrote:
[quote]
> Dear Ruby Community,
>
> One day I hope to learn your trade :)
>
> But before that ...
> A reasonably arrogant guy came out blasting in a web-forum about how OO is
> crap and all that.
>
> He offered a challenge which I tried to defeat but in VB.NET
> Now VB.NET sucks simply because the Visual Studio IDE that comes with it
> is all very boring, slow, bureacratic, clunky and when you get a spark of
> inspiration it hangs saying "Please wait while we update your Help File"
> (for 20 minutes)
>
> Pure Joy-Killer
>
> His challenge is as follows:
>
> * I wont give the URL yet because I want you guys to come with the best
> solution, don't worry I wont take credit for it - will post the website
> and say this is the RUBY's solution loggin in as Anonymous *
>
>

>
> Whole OO is step back in programming. Encapsulation is trivial
> and unnecessary, inheritance wrong and polymorphism weak ..
>
> OK, here is my favorite 'Tax Payer' challenge for OO languages. There are lot of different groups of people with different rules for tax calculation. One man can be in the same time member of many groups. His membership can change during program execution time. If he is member of many groups in the time tax is calculated, his tax is the greatest one on the base of all groups he is member (they are clever!). Natural situation, isn't it? Now, (1) define separate functions that calculate tax for each groups, and (2) write polymorphic function that calculate tax for tax payer, no matter of his membership to one or many groups in the same time. Here is code in procedural language: record tax_payer(salary,member_of)
>
> [Version 1]
>
> procedure tax_soldier(X)
> return X.salary/10.0
> end
>
> procedure tax_professor(X)
> return X.salary/15.0+100
> end
>
> #many of them ...
>
> procedure tax(X) #procedural polymorphism
> result:=0
> every class:=!X.member_of do
> if result then result:=t
> return result
> end
>
> procedure main()
> A:=tax_payer(3000,["soldier"])
> B:=tax_payer(5000,["professor"])
> C:=tax_payer(6000,["professor","soldier"])
> #...
> write(tax(A),tax(B),tax(C)) #this line is goal
> end
>
> [Added to Version 1]
>
> Oh, board ignored part of the procedure tax(), here it is again ...
>
> procedure tax(X)
> result:=0
> every class:=!X.member_of do
> if result less_than t:=proc("tax_"||class)(X) then result:=t
> return result
> end
>
> [Version 2]
>
> Here is the procedural version of your second program:
>
> record tax_payer(salary,member_of)
> record tax_rule_data(multiplier, additional)
> global tax_rule
>
> procedure tax(payer)
> * * res:=0
> * * every r:=tax_rule[! payer.member_of ] do
> * * * * * * * if res less_than t:=payer.salary/r[1]+r[2]
> * * * * * * * * * * * * * * * * * * * * then res:=t
> * * return res
> end
>
> procedure main()
> * * tax_rule:=table()
> * * tax_rule["soldier"]:=tax_rule_data(10,0)
> * * tax_rule["professor"]:=tax_rule_data(15,100)
> * * A:=tax_payer(1000,["soldier","professor"])
> * * write(tax(A))
> end
>
> That is actual code in Icon, not pseudocode, just like my previous program.
> I believe I have my point about elegance.
> I do not think that Tax Payer problem deserves to be called 'functional problem' - it is simple problem every general programming language should be able to solve easily and with elegance. Such problems are everywhere. It is not exotic automated theorem proving problem ... neither is proc() non-procedural.. actually, I remember Sinclair ZX 81 had similar GO SUB (expression) statement. Sure, it is slower, but worked well even then, on 1000 times slower comp and 20 000 times smaller memory.
> Tax Payer problem is all about object (tax_payer) - class (soldier ...) membership and polimorphic functions, just it is not that simple as designers of OO languages believe (object is member of only one class (and superclasses) and does not change its membership, function version can be decided solely on class membership) - hence one is forced to handle membership relation on his own, and OO support integrated in the language is shown to be restrictive and cluttering. Proof is in the puding - compare Icon and Java code.
> It is not the only problem with OO. Inheritance rules are even worse; almost everything in that concept is wild guess, and code is always much worse.
> If anyone disagree and he think he has problem where OO is better, i accept the challenge.
>
> [/UNQUOTE]
>
>
> So sorry for the abuse in pasting.
> Now I started solving this in VB.NET
> But just to be vindictive lol .. wanted to most beautiful solution ever.
> Which I believe RUBY can deliver.
> This guy is talking crap.
>
> My version in VB would be pure syntatic sugar.
> But its fundamental we had an eval function
> ie eval "3 + 4 / 7" returns 1
> I tried to import that from JScript Library
> And "bureacratic" Visual Studio started asking me to reflect on which
> Engine, for which I tried to look into the help files: and it began
> pissing me off with insert CD this, wait until we update your files .. and
> a second time wait until we update your file, now insert CD number 2 ..
> [note when I first installed I explicitily asked VS to loads ALL Library
> and also saved the Library Locally but VS is just thick]
>
> My version should have a Main more or less like:
>
> Sub Main()
>
> Dim ListOfTaxRules As New TaxRules
> Dim ListOfTaxPayers As New TaxPayers
> Dim Member As Object
>
> With ListOfTaxTules
> .Add("soldier","/10")
> .Add("teacher","/15+2000")
> .Add("professor","/12+1000")
> End WIth
>
> With ListOfTaxPayers
> .Add("John","soldier",30000)
> .Add("Mary","teacher",15000)
> .Add("Gary",{"professor","soldier"},50000)
> End With
>
> For Each Member As Object In ListOfTaxPayers.List
> Console.WriteLine(Member.Name,Member.CalculatedTax )
> Next
>
> End Sub

[url]http://tools.devchannel.org/comments.pl?sid=3343&op=&threshold=0&commentsort=0 &mode=thread&tid=39&pid=179#185[/url]

And now am going to read and learn from your posts! hehe

Thanks loads for your prompt answer and enthusiam.

Henry G.



Of course I am abusing the VB.NET as Much as possible.

> For the sake of readability and winning the challenge :P
>
> I haven't supplied code for the Classes because I got stuck on importing
> the Eval function from Microsoft.Jscript Library.
> Which would also tarnish the "elegant" solution
>
> There are many ways round to this problem - and the most concise and yet beautiful
> easy to read .. should be considered.
> So please venture completely different routes - so we can breed the best
> one.
>
> Of course his challenge is stupid, because OO languages excel on a large
> scale, not on such simple things. But still I am confident there is a
> solution to his silly challenge.
>
> Thanks for your attention.
> Would love to learn from you all RUBY sometime.
> For another abandoned .NET project - an English Online Website
> I was going to build for free - and being GPL
> (Any takers? :)
>
> All the best
>
> Henry Gilbert

[Henry Gilbert]

[url]http://tools.devchannel.org/comments.pl?sid=3343&op=&threshold=0&commentsort=0 &mode=thread&tid=39&pid=179#185[/url]

[Henry Gilbert]

Link is above there somewhere.
[url]http://tools.devchannel.org/comments.pl?sid=3343&op=&threshold=0&commentsort=0 &mode=thread&tid=39&pid=179#185[/url]

(great it was still in my clipboard!)

The article was about Eiffel.
But the guy blasted OO ..
I know from experience that the least you know - the more you think you
know :P
So obviously that guy was whizzing on an ego trip.

He fails to realize that OO is to encapsulate and reduce complexity for
larger programs - not trivial examples.

His example is silly.
As OO is *usually* built on procedural-like code.
Now .. if he were to have an example involving a more complex application
Then he would lose ground - he is cheating, setting the rules - with an example of
20 lines or so.

As I stated I tried VB.NET because you can do *illegal* things
that makes code more sugary-like.

With C# you can make classes morph into others - while introducing some
ugly parameters. (Perhaps) the solution could have been more concise.

But I was aiming for the solution to be readable when declaring.
That is IMO .. what OO is for. Work hard to make it easier.

I was close to finding a solution - but no EVAL in VB, and didn't want to
thread at MSDN for hours, .. I got sick of Visual Studio .NET slow,
crawling once more -hanging on "Wait 20 minutes ..." (P-OFF MS! grrrr).

Refreshing to be here under Linux again :)

Thanks again.

I will look into RUBY more
I am looking for a nice language.
I tried Smalltalk but couldnt get round it. I feel even embarrased about
it :(
Ruby seems to be more my style!

I deffy want to re-write a site which I began with C#.
So any advice on RUBY (ie links) for rendering pages and dealing with Response Fields
is much appreciated.

Of course I will always be searching through posts here trying to learn as much as
poss.

All the best

Henry Gilbert

[Jim Weirich]

On Fri, 2003-09-12 at 10:57, Weirich, James wrote:

Not to beat a dead horse or anything, but I love playing with variations
on a theme...

I reviewed the thread that Henry posted. Not much interesting except
that one fellow posted a Haskell version of the tax program. Here it is
...

tax_soldier earning = earning/10
tax_professor earning = earning/15 + 100

tax (TaxPayer earning taxgroups) =
maximum (map (\f -> f earning) taxgroups)

-? tax (TaxPayer 3000 [tax_soldier, tax_professor])

Wow, short and to the point. So, could a Ruby version be that concise?
Here's my attempt ...

TaxSoldier = proc { |earning| earning / 10.0 }
TaxProfessor = proc { |earning| earning / 15.0 + 100 }

def tax(earning, tax_groups)
tax_groups.collect { |g| g.call(earning) }.max
end

puts tax(3000, [TaxSoldier, TaxProfessor])

Pretty much a line for line translation. Why so much shorter than
previous versions? Because we threw out the tax payer abstraction and
just pass around earning (e.g. salary).

--
-- Jim Weirich [email]jweirich@one.net[/email] [url]http://onestepback.org[/url]
-----------------------------------------------------------------
"Beware of bugs in the above code; I have only proved it correct,
not tried it." -- Donald Knuth (in a memo to Peter van Emde Boas)

[Robert Klemme]

"Henry Gilbert" <nospam@alliancetec.com> schrieb im Newsbeitrag
news:pan.2003.09.12.22.03.43.604791@alliancetec.co m...

> He fails to realize that OO is to encapsulate and reduce complexity for
> larger programs - not trivial examples.

I think the posted examples show that even simple programs can benefit
from OO (and especially Ruby) - at least by increased readability but also
by reduced code (you get polymorphism and a lot of other stuff for free).

> I deffy want to re-write a site which I began with C#.
> So any advice on RUBY (ie links) for rendering pages and dealing with

Response Fields

> is much appreciated.

Look out for eruby, amrita, apache mod-ruby and the like.

> Of course I will always be searching through posts here trying to learn

as much as

> poss.

Go ahead, you'll find plenty. :-)

Regards

robert