A lack of productivity is killing Smalltalk.

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
8 messages Options
Reply | Threaded
Open this post in threaded view
|

A lack of productivity is killing Smalltalk.

Janko Mivšek
Another one from blogosfere. For our rethinking ...

http://pinderkent.blogsavy.com/archives/99

A lack of productivity is killing Smalltalk.

I heard today that the development of Dolphin Smalltalk has been
discontinued. Although it isn’t a product I used or was familiar with, I
have been involved with a number of Smalltalk-based development efforts
in the past. While it was somewhat popular in the late 1980s and early
1990s, the commercial usage of Smalltalk has declined significantly
since then.

Slava Pestov suggests how poor implementations are leading to the
downfall of Smalltalk. I would tend to agree, to some extent. Most
Smalltalk implementations really don’t compare to a development platform
like Java, or even what Microsoft has put together with C# and .NET.

However, I would tend to think that the main reason why Smalltalk has
started to really fall out of favor is that it doesn’t bring the level
of productivity that it used to, relative to other technologies. Back in
the early 1990s, a lot of enterprise-grade software was written using C
or C++. For developing complex business applications, Smalltalk often
did offer a very significant productivity boost to developers, even if
the runtime performance of the applications suffered somewhat. Being at
a higher-level, it allowed business rules and concepts to be more easily
and effectively represented in the software itself.

But that started to change by the mid-1990s. Java arose, and offered
many of the benefits that Smalltalk had been offering. That’s not to say
that Java, as a language, is comparable to Smalltalk. In many ways it’s
quite inferior, even over a decade after its initial release. But it was
more familiar to those developers who’d come from the world of C and
C++, while also offering OO functionality and garbage collection similar
enough to that of Smalltalk.

I’ve worked with several excellent Smalltalk developers in the past. A
talented, experienced professional can do wonders with Smalltalk.
Unfortunately for them, Java and its vast array of classes, class
libraries and frameworks have brought a similar level of productivity to
only average developers. So if these average developers can churn out an
adequate software product at a lower cost than the Smalltalk expert, as
has often become the case, then the business will flow towards the Java
developers.

Unless the Smalltalk developers bring something to the party that
drastically increases their productivity (or their software’s
productivity) over that put out by Java developers, they won’t have a
real chance at survival.




--
Janko Mivšek
AIDA/Web
Smalltalk Web Application Server
http://www.aidaweb.si

Reply | Threaded
Open this post in threaded view
|

Actually, An excess of productivity is killing Smalltalk.

tblanchard
Shows a total ignorance of how management thinks.

Java is about 1/10 to 1/5 as productive as Smalltalk.

 From the manger's perspective, he wants to climb the corporate  
ladder.  To do this, he must become more important than he is.  He  
could hire Steve the wizard Smalltalker to write his system and get  
it done in a few months.  Steve can do it.  He's pricey but from a  
productivity perspective, he's worth it.

But when promotion time comes - manager guy can only say "I have one  
employee - Steve" and he gets very little respect as a manager.  How  
hard can it be to manage one guy?

For the timeframe - he could hire 5 Java guys - make more code (that  
does the same thing) and he gets to say to his peers that he manages  
a team of 5 developers.  Each developer costs less than Steve - so it  
looks like he is getting a bargain in two ways.  Which sounds better  
to his boss who is judging him on his management skills?  He manages  
Steve.  Or he manages a team of 5?  Which one will get him promoted?

Extra bonus reason - Steve can get hit by a bus.  Big risk!  A Java  
developer can also get hit by a bus - but if that happens it is much  
less likely to impact the project critically.  So manager guy feels  
better about that too.  Steve is hard to replace - Java people are a  
dime a dozen and only have to be 1/5 as good.

Smalltalk loses because it is TOO productive.  It frightens the  
manager and doesn't make him look powerful and important.  It  
marginalizes him instead.

FWIW, I also worked as a dev manager at some large companies and  
believe me - this is the thought process.


On Aug 12, 2007, at 1:36 PM, Janko Mivšek wrote:

> Another one from blogosfere. For our rethinking ...
>
> http://pinderkent.blogsavy.com/archives/99
>
> A lack of productivity is killing Smalltalk.
>
> I heard today that the development of Dolphin Smalltalk has been  
> discontinued. Although it isn’t a product I used or was familiar  
> with, I have been involved with a number of Smalltalk-based  
> development efforts in the past. While it was somewhat popular in  
> the late 1980s and early 1990s, the commercial usage of Smalltalk  
> has declined significantly since then.
>
> Slava Pestov suggests how poor implementations are leading to the  
> downfall of Smalltalk. I would tend to agree, to some extent. Most  
> Smalltalk implementations really don’t compare to a development  
> platform like Java, or even what Microsoft has put together with C#  
> and .NET.
>
> However, I would tend to think that the main reason why Smalltalk  
> has started to really fall out of favor is that it doesn’t bring  
> the level of productivity that it used to, relative to other  
> technologies. Back in the early 1990s, a lot of enterprise-grade  
> software was written using C or C++. For developing complex  
> business applications, Smalltalk often did offer a very significant  
> productivity boost to developers, even if the runtime performance  
> of the applications suffered somewhat. Being at a higher-level, it  
> allowed business rules and concepts to be more easily and  
> effectively represented in the software itself.
>
> But that started to change by the mid-1990s. Java arose, and  
> offered many of the benefits that Smalltalk had been offering.  
> That’s not to say that Java, as a language, is comparable to  
> Smalltalk. In many ways it’s quite inferior, even over a decade  
> after its initial release. But it was more familiar to those  
> developers who’d come from the world of C and C++, while also  
> offering OO functionality and garbage collection similar enough to  
> that of Smalltalk.
>
> I’ve worked with several excellent Smalltalk developers in the  
> past. A talented, experienced professional can do wonders with  
> Smalltalk. Unfortunately for them, Java and its vast array of  
> classes, class libraries and frameworks have brought a similar  
> level of productivity to only average developers. So if these  
> average developers can churn out an adequate software product at a  
> lower cost than the Smalltalk expert, as has often become the case,  
> then the business will flow towards the Java developers.
>
> Unless the Smalltalk developers bring something to the party that  
> drastically increases their productivity (or their software’s  
> productivity) over that put out by Java developers, they won’t have  
> a real chance at survival.
>
>
>
>
> --
> Janko Mivšek
> AIDA/Web
> Smalltalk Web Application Server
> http://www.aidaweb.si
>


Reply | Threaded
Open this post in threaded view
|

Re: Actually, An excess of productivity is killing Smalltalk.

David Mitchell-10
Something like this happened to my project teams twice. (Though it was
first C++ and later Microsoft VB ASP as the competing project teams.)
The *much* larger development organizations delivered less
functionality (according to the companies own metrics), but their
managers were far more powerful because they had a larger span of
control.

On 8/12/07, Todd Blanchard <[hidden email]> wrote:

> Shows a total ignorance of how management thinks.
>
> Java is about 1/10 to 1/5 as productive as Smalltalk.
>
>  From the manger's perspective, he wants to climb the corporate
> ladder.  To do this, he must become more important than he is.  He
> could hire Steve the wizard Smalltalker to write his system and get
> it done in a few months.  Steve can do it.  He's pricey but from a
> productivity perspective, he's worth it.
>
> But when promotion time comes - manager guy can only say "I have one
> employee - Steve" and he gets very little respect as a manager.  How
> hard can it be to manage one guy?
>
> For the timeframe - he could hire 5 Java guys - make more code (that
> does the same thing) and he gets to say to his peers that he manages
> a team of 5 developers.  Each developer costs less than Steve - so it
> looks like he is getting a bargain in two ways.  Which sounds better
> to his boss who is judging him on his management skills?  He manages
> Steve.  Or he manages a team of 5?  Which one will get him promoted?
>
> Extra bonus reason - Steve can get hit by a bus.  Big risk!  A Java
> developer can also get hit by a bus - but if that happens it is much
> less likely to impact the project critically.  So manager guy feels
> better about that too.  Steve is hard to replace - Java people are a
> dime a dozen and only have to be 1/5 as good.
>
> Smalltalk loses because it is TOO productive.  It frightens the
> manager and doesn't make him look powerful and important.  It
> marginalizes him instead.
>
> FWIW, I also worked as a dev manager at some large companies and
> believe me - this is the thought process.
>
>
> On Aug 12, 2007, at 1:36 PM, Janko Mivšek wrote:
>
> > Another one from blogosfere. For our rethinking ...
> >
> > http://pinderkent.blogsavy.com/archives/99
> >
> > A lack of productivity is killing Smalltalk.
> >
> > I heard today that the development of Dolphin Smalltalk has been
> > discontinued. Although it isn't a product I used or was familiar
> > with, I have been involved with a number of Smalltalk-based
> > development efforts in the past. While it was somewhat popular in
> > the late 1980s and early 1990s, the commercial usage of Smalltalk
> > has declined significantly since then.
> >
> > Slava Pestov suggests how poor implementations are leading to the
> > downfall of Smalltalk. I would tend to agree, to some extent. Most
> > Smalltalk implementations really don't compare to a development
> > platform like Java, or even what Microsoft has put together with C#
> > and .NET.
> >
> > However, I would tend to think that the main reason why Smalltalk
> > has started to really fall out of favor is that it doesn't bring
> > the level of productivity that it used to, relative to other
> > technologies. Back in the early 1990s, a lot of enterprise-grade
> > software was written using C or C++. For developing complex
> > business applications, Smalltalk often did offer a very significant
> > productivity boost to developers, even if the runtime performance
> > of the applications suffered somewhat. Being at a higher-level, it
> > allowed business rules and concepts to be more easily and
> > effectively represented in the software itself.
> >
> > But that started to change by the mid-1990s. Java arose, and
> > offered many of the benefits that Smalltalk had been offering.
> > That's not to say that Java, as a language, is comparable to
> > Smalltalk. In many ways it's quite inferior, even over a decade
> > after its initial release. But it was more familiar to those
> > developers who'd come from the world of C and C++, while also
> > offering OO functionality and garbage collection similar enough to
> > that of Smalltalk.
> >
> > I've worked with several excellent Smalltalk developers in the
> > past. A talented, experienced professional can do wonders with
> > Smalltalk. Unfortunately for them, Java and its vast array of
> > classes, class libraries and frameworks have brought a similar
> > level of productivity to only average developers. So if these
> > average developers can churn out an adequate software product at a
> > lower cost than the Smalltalk expert, as has often become the case,
> > then the business will flow towards the Java developers.
> >
> > Unless the Smalltalk developers bring something to the party that
> > drastically increases their productivity (or their software's
> > productivity) over that put out by Java developers, they won't have
> > a real chance at survival.
> >
> >
> >
> >
> > --
> > Janko Mivšek
> > AIDA/Web
> > Smalltalk Web Application Server
> > http://www.aidaweb.si
> >
>
>
>

Reply | Threaded
Open this post in threaded view
|

Re: Actually, An excess of productivity is killing Smalltalk.

Jason Johnson-5
These are "big org" problems.  Smalltalk, Lisp, etc. are the reason
little companies still have a chance.

On 8/13/07, David Mitchell <[hidden email]> wrote:

> Something like this happened to my project teams twice. (Though it was
> first C++ and later Microsoft VB ASP as the competing project teams.)
> The *much* larger development organizations delivered less
> functionality (according to the companies own metrics), but their
> managers were far more powerful because they had a larger span of
> control.
>
> On 8/12/07, Todd Blanchard <[hidden email]> wrote:
> > Shows a total ignorance of how management thinks.
> >
> > Java is about 1/10 to 1/5 as productive as Smalltalk.
> >
> >  From the manger's perspective, he wants to climb the corporate
> > ladder.  To do this, he must become more important than he is.  He
> > could hire Steve the wizard Smalltalker to write his system and get
> > it done in a few months.  Steve can do it.  He's pricey but from a
> > productivity perspective, he's worth it.
> >
> > But when promotion time comes - manager guy can only say "I have one
> > employee - Steve" and he gets very little respect as a manager.  How
> > hard can it be to manage one guy?
> >
> > For the timeframe - he could hire 5 Java guys - make more code (that
> > does the same thing) and he gets to say to his peers that he manages
> > a team of 5 developers.  Each developer costs less than Steve - so it
> > looks like he is getting a bargain in two ways.  Which sounds better
> > to his boss who is judging him on his management skills?  He manages
> > Steve.  Or he manages a team of 5?  Which one will get him promoted?
> >
> > Extra bonus reason - Steve can get hit by a bus.  Big risk!  A Java
> > developer can also get hit by a bus - but if that happens it is much
> > less likely to impact the project critically.  So manager guy feels
> > better about that too.  Steve is hard to replace - Java people are a
> > dime a dozen and only have to be 1/5 as good.
> >
> > Smalltalk loses because it is TOO productive.  It frightens the
> > manager and doesn't make him look powerful and important.  It
> > marginalizes him instead.
> >
> > FWIW, I also worked as a dev manager at some large companies and
> > believe me - this is the thought process.
> >
> >
> > On Aug 12, 2007, at 1:36 PM, Janko Mivšek wrote:
> >
> > > Another one from blogosfere. For our rethinking ...
> > >
> > > http://pinderkent.blogsavy.com/archives/99
> > >
> > > A lack of productivity is killing Smalltalk.
> > >
> > > I heard today that the development of Dolphin Smalltalk has been
> > > discontinued. Although it isn't a product I used or was familiar
> > > with, I have been involved with a number of Smalltalk-based
> > > development efforts in the past. While it was somewhat popular in
> > > the late 1980s and early 1990s, the commercial usage of Smalltalk
> > > has declined significantly since then.
> > >
> > > Slava Pestov suggests how poor implementations are leading to the
> > > downfall of Smalltalk. I would tend to agree, to some extent. Most
> > > Smalltalk implementations really don't compare to a development
> > > platform like Java, or even what Microsoft has put together with C#
> > > and .NET.
> > >
> > > However, I would tend to think that the main reason why Smalltalk
> > > has started to really fall out of favor is that it doesn't bring
> > > the level of productivity that it used to, relative to other
> > > technologies. Back in the early 1990s, a lot of enterprise-grade
> > > software was written using C or C++. For developing complex
> > > business applications, Smalltalk often did offer a very significant
> > > productivity boost to developers, even if the runtime performance
> > > of the applications suffered somewhat. Being at a higher-level, it
> > > allowed business rules and concepts to be more easily and
> > > effectively represented in the software itself.
> > >
> > > But that started to change by the mid-1990s. Java arose, and
> > > offered many of the benefits that Smalltalk had been offering.
> > > That's not to say that Java, as a language, is comparable to
> > > Smalltalk. In many ways it's quite inferior, even over a decade
> > > after its initial release. But it was more familiar to those
> > > developers who'd come from the world of C and C++, while also
> > > offering OO functionality and garbage collection similar enough to
> > > that of Smalltalk.
> > >
> > > I've worked with several excellent Smalltalk developers in the
> > > past. A talented, experienced professional can do wonders with
> > > Smalltalk. Unfortunately for them, Java and its vast array of
> > > classes, class libraries and frameworks have brought a similar
> > > level of productivity to only average developers. So if these
> > > average developers can churn out an adequate software product at a
> > > lower cost than the Smalltalk expert, as has often become the case,
> > > then the business will flow towards the Java developers.
> > >
> > > Unless the Smalltalk developers bring something to the party that
> > > drastically increases their productivity (or their software's
> > > productivity) over that put out by Java developers, they won't have
> > > a real chance at survival.
> > >
> > >
> > >
> > >
> > > --
> > > Janko Mivšek
> > > AIDA/Web
> > > Smalltalk Web Application Server
> > > http://www.aidaweb.si
> > >
> >
> >
> >
>
>


Reply | Threaded
Open this post in threaded view
|

Re: A lack of productivity is killing Smalltalk.

Jason Johnson-5
In reply to this post by Janko Mivšek
This article only looks at the initial implementation, which is the
smallest part of the software life-cycle.

It is probably true these days that one can use InteliJ or Eclipse to
generate all the verbose code and bring a Java developer on par or
even past a Smalltalk programmer for that initial writing (though even
this doesn't seem to be the case in practice).

Then starts the QA/debugging phase.  Here the advanced IDE's help out
again but Java et al begin to slip behind.  Not as far as they used to
but still losing ground.

And now your software goes into production.  So the support teams need
a way to see what your software is doing so they can support it.  This
means you have to reach into the system and expose parts of it, but
what do we expose?  You will get this question wrong pretty much every
time.  So you have to make the next version just to put in monitoring
code.  And it works beautifully... to demonstrate that they actually
needed to see some other part of the system.  At some point you just
give up and log the entry and exit to every function in the system
with Log4* and let them choose how much information they want.

In Smalltalk you can completely skip this step if you want, the entire
system is *already* exposed [1].

Most of the cost of software comes from the maintenance which is tied
directly to lines of code.  Smalltalk is still way ahead on that score
(against Java and C/C++ at least), and giving people the ability to
generate the 3/5/10/whatever times more code faster doesn't fix that.
It is the equivalent of optimizing a section of code that almost never
gets called.  When you pan out and look at the bigger picture you
don't see any gains at all.

[1] Also talked about at:
http://sixtyk.blogspot.com/2007/02/watching-watchmen.html

On 8/12/07, Janko Mivšek <[hidden email]> wrote:

> Another one from blogosfere. For our rethinking ...
>
> http://pinderkent.blogsavy.com/archives/99
>
> A lack of productivity is killing Smalltalk.
>
> I heard today that the development of Dolphin Smalltalk has been
> discontinued. Although it isn't a product I used or was familiar with, I
> have been involved with a number of Smalltalk-based development efforts
> in the past. While it was somewhat popular in the late 1980s and early
> 1990s, the commercial usage of Smalltalk has declined significantly
> since then.
>
> Slava Pestov suggests how poor implementations are leading to the
> downfall of Smalltalk. I would tend to agree, to some extent. Most
> Smalltalk implementations really don't compare to a development platform
> like Java, or even what Microsoft has put together with C# and .NET.
>
> However, I would tend to think that the main reason why Smalltalk has
> started to really fall out of favor is that it doesn't bring the level
> of productivity that it used to, relative to other technologies. Back in
> the early 1990s, a lot of enterprise-grade software was written using C
> or C++. For developing complex business applications, Smalltalk often
> did offer a very significant productivity boost to developers, even if
> the runtime performance of the applications suffered somewhat. Being at
> a higher-level, it allowed business rules and concepts to be more easily
> and effectively represented in the software itself.
>
> But that started to change by the mid-1990s. Java arose, and offered
> many of the benefits that Smalltalk had been offering. That's not to say
> that Java, as a language, is comparable to Smalltalk. In many ways it's
> quite inferior, even over a decade after its initial release. But it was
> more familiar to those developers who'd come from the world of C and
> C++, while also offering OO functionality and garbage collection similar
> enough to that of Smalltalk.
>
> I've worked with several excellent Smalltalk developers in the past. A
> talented, experienced professional can do wonders with Smalltalk.
> Unfortunately for them, Java and its vast array of classes, class
> libraries and frameworks have brought a similar level of productivity to
> only average developers. So if these average developers can churn out an
> adequate software product at a lower cost than the Smalltalk expert, as
> has often become the case, then the business will flow towards the Java
> developers.
>
> Unless the Smalltalk developers bring something to the party that
> drastically increases their productivity (or their software's
> productivity) over that put out by Java developers, they won't have a
> real chance at survival.
>
>
>
>
> --
> Janko Mivšek
> AIDA/Web
> Smalltalk Web Application Server
> http://www.aidaweb.si
>
>


Reply | Threaded
Open this post in threaded view
|

Re: A lack of productivity is killing Smalltalk.

Andres Valloud-3
In reply to this post by Janko Mivšek
Janko Mivšek wrote:

> Another one from blogosfere. For our rethinking ...
>
> http://pinderkent.blogsavy.com/archives/99
>
> A lack of productivity is killing Smalltalk.
>
> I heard today that the development of Dolphin Smalltalk has been
> discontinued. Although it isn’t a product I used or was familiar with,
> I have been involved with a number of Smalltalk-based development
> efforts in the past. While it was somewhat popular in the late 1980s
> and early 1990s, the commercial usage of Smalltalk has declined
> significantly since then.
>
> Slava Pestov suggests how poor implementations are leading to the
> downfall of Smalltalk. I would tend to agree, to some extent. Most
> Smalltalk implementations really don’t compare to a development
> platform like Java, or even what Microsoft has put together with C#
> and .NET.
>
> However, I would tend to think that the main reason why Smalltalk has
> started to really fall out of favor is that it doesn’t bring the level
> of productivity that it used to, relative to other technologies. Back
> in the early 1990s, a lot of enterprise-grade software was written
> using C or C++. For developing complex business applications,
> Smalltalk often did offer a very significant productivity boost to
> developers, even if the runtime performance of the applications
> suffered somewhat. Being at a higher-level, it allowed business rules
> and concepts to be more easily and effectively represented in the
> software itself.
>
> But that started to change by the mid-1990s. Java arose, and offered
> many of the benefits that Smalltalk had been offering. That’s not to
> say that Java, as a language, is comparable to Smalltalk. In many ways
> it’s quite inferior, even over a decade after its initial release. But
> it was more familiar to those developers who’d come from the world of
> C and C++, while also offering OO functionality and garbage collection
> similar enough to that of Smalltalk.
>
> I’ve worked with several excellent Smalltalk developers in the past. A
> talented, experienced professional can do wonders with Smalltalk.
> Unfortunately for them, Java and its vast array of classes, class
> libraries and frameworks have brought a similar level of productivity
> to only average developers. So if these average developers can churn
> out an adequate software product at a lower cost than the Smalltalk
> expert, as has often become the case, then the business will flow
> towards the Java developers.
>
> Unless the Smalltalk developers bring something to the party that
> drastically increases their productivity (or their software’s
> productivity) over that put out by Java developers, they won’t have a
> real chance at survival.
>

That does not work as soon as changes must be made to the software.  
Which, oh by the way, happens all the time.

Other than that, I find fascinating how easily we put the responsibility
with the tool instead of ourselves.  To a point, I'd say there's
something to be said about the overall productivity of diverse languages
over time.  At the same time, I find it quite frustrating when I go to a
bookstore to research computer programming books and it turns out that
the amount of information they have on hash, which we shall call K, is
inversely proportional to the cube of books that cover the same topic.  
So, for instance, many books on the latest programming trends have no
index entry for hash.

Since hashing is such a fundamental issue of computer programming, I
can't just help worrying that the underlying assumption is that the
average programmer does not even need to know about these things.  Some
books even explicitly state so, thus there's some justification for that
assertion.  Thus, if that is the case, then the real issue is that our
skill set is tiny --- and then how are we going to even begin to have a
proper discussion on the merits of programming language X vs Y?

Just my 2 cents,
Andres.

Reply | Threaded
Open this post in threaded view
|

Re: Actually, An excess of productivity is killing Smalltalk.

Göran Krampe
In reply to this post by Jason Johnson-5
Hi Jason!

Please turn off base64 mime encoding or whatever it is in gmail? Other
people here using gmail can perhaps tell you what to do.
I am using Celeste and it can't render your posts in a easily readable
way.

regards, Göran

Reply | Threaded
Open this post in threaded view
|

Re: A lack of productivity is killing Smalltalk.

Cees De Groot
In reply to this post by Andres Valloud-3
On 8/13/07, Andres Valloud <[hidden email]> wrote:
> Since hashing is such a fundamental issue of computer programming, I
> can't just help worrying that the underlying assumption is that the
> average programmer does not even need to know about these things.

Just for thinking and because I like the role of Devil's advocate: it
used to be that machine language was a fundamental issue of computer
programming...

About the original topic: I did a Java project last year. The biggest
hurdle was that we were working with legacy code, but I must admit
that Eclipse has come a long way, that class reloading helps quite a
bit when developing web apps, and that the refactoring browser in
Eclipse beats its Smalltalk parent because it can make use of the
static type information. Ok, I've been cussin' and swearin' at the
language at times, but overall I must say that my Java productivity
was incredibly high compared to my previous large Java project (with
JDK 1.1 and Emacs/JDE and horrible GNU Make files). And its nice to
see to what extent Eclipse seems to have been "inspired" by Smalltalk
- maybe that will turn out to be Smalltalk's final contribution to the
computer programming community, to hold a candle in the dark and guide
the way :)

"Worse is better" - Java vs. Smalltalk might prove another example of
this. Actually typing in and modifying code is an increasingly small
part of a whole software product lifecycle, and it could just be that
Java closed the gap enough (productivity lower by maybe 50-100%
instead of the order of magnitude that used to hold) that switching to
Smalltalk with all its associated (real and perceived risks) is just
not worth it.

Note: I'm making these comments about "sane" Java environments. Not
the whole J2EE christmas tree :)

--
"Human beings make life so interesting. Do you know, that in a
universe so full of wonders, they have managed to invent boredom. " -
Death, in "The Hogfather"