Are Objects really hard?

Hi Marcus!

Tnx for calling me a troll. Reminder:

http://forum.world.st/Hanging-connects-exhausted-resources-memory-leaks-bocked-everything-Unusable-td3669616.html

several month later:

http://lists.gforge.inria.fr/pipermail/pharo-project/2012-February/059581.html

You've got serious problems *seeing reality*

With that attitude you and the Pharo team are even threatening Chris Muller's efforts on programming a HA OODB replacement for Gemstone with Magma.

So *please*, develop the development process!

Ok?

Tnx for understanding, Guido Stepken

Thanks guys for the daily amusement :D

rofl

On 2012-02-15, at 12:15, Guido Stepken wrote:

On Feb 15, 2012, at 12:35 PM, Camillo Bruni wrote:

> Thanks guys for the daily amusement :D
>

I am now deleting his emails direcly in gmail... I would suggest everyone else to do the same.

        Marcus


--
Marcus Denker -- http://marcusdenker.de

On Wed, Feb 15, 2012 at 9:50 AM, Marcus Denker <[hidden email]> wrote:

> Yes, 4-5 manyears? So, why reinventing the wheel, like with COGVM?
> LLVM ist much better supported by big, big, commercial companies.
>
Yes, LLVM has a great track-record of easing the development of dynamic
languages.
http://qinsb.blogspot.com/2011/03/unladen-swallow-retrospective.html

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

Interestingly on the cited page

http://dosync.posterous.com/illiterate-programming

we read

"There's nothing more powerful in aiding readability than a small core
set of concepts. In this sense I think Smalltalk continues to be one
of the few languages to get anywhere near LISP. "

--Hannes

Reminds me of http://www.infoq.com/interviews/foote-oop-code

On 02/11/2012 01:21 PM, Janko Mivšek wrote:

Hi guys,

Just to conclude this topic: there is a nice talk between Dave Thomas
(of OTI fame where IBM VisualAge Smalltalk and nowadays VA Smalltalk
came out), James Robertson and David Buck in recent Independent
Misinterpretations:

   IM 67: Have Objects Failed Us?
   http://www.jarober.com/blog/blogView?entry=3507708198

What I like is a discussion about OO vs. relational world and ORM in the
second half, which is also by my opinion the reason why OO didn't
succeed more as it did, and why is considered hard for most of
developers until our days.

Best regards
Janko


S, Janko Mivšek piše:
--
Janko Mivšek
Aida/Web
Smalltalk Web Application Server
http://www.aidaweb.si

This note kind of ties down to this discussion.

Why does Rails , .Net : VB/ C# or Java , PHP et als succeed : Objects
vs code pattern.. ( not design pattern ).

 Pattern matched copying of code to get an app constructed/
maintained/ extended.

 What I mean is people learn/ work mostly by pattern they pick up and
accumulate as much is necessary for them to go exploring. They really
do not go debugging deep and wide.

 Example: Let us say in VB/ C# or Rails ; you have read how doing
steps 1, 2 , 3 and using a pattern of macro's helps get this function
done.. they get it going fast by copying , modifying bits/ ids/ etc
here n there.. Barely few I have met in C# / .Net / PHP world who
really know its deep internals as one imagines Smalltalkers need to
know of Smalltalk base.

  So when they want something else like how to have a Dataset
connected with a DB table and do CRUD.. they pick an example , modify
by patterns... and get it going. They do not spend time debugging and
knowing whats inside the various classes, its "Object" / "Class"
etc..

  But in Smalltalk, I believe as it exists, it is certainly not that
"friendly" or dumbed down for people to simply pattern match.. You
need to be innured in browse hierarchy, senders, implementors,
references, understand the methods/ messages .. the whole wiring of
"Objects"...

  Java claims and is certainly better than this lot.. but with its
XML, struts, templates, even the HTML programming is actually lot
easier than Seaside with the need to do Object oriented server side
code even for the HTML .. easy for many of us.. but I realize really
hard to grok from most of the milling crowd.

  Easier there of to deploy less experienced/ junior programmers in
more divided modules of work...  not that we cannot have it in
Smalltalk, just that much harder..

  I  believe to hit it viral, you do need the Rails kind of appeal,
even the PHP .. macro's ; pattern matched code / ability to quickly
scale from copy-paste pattern matched code, wizards that get you up
and running for small / medium apps.

 Leave the higher order/ comprehension / framework construction to
those who do.. but if we can make the entry barrier really low to work
with Smalltalk without OOPs baggage.. it might surprise all of us how
many could flock in..

  This will easily graft people in and then push their need to really
dig in, and go up the value chain. Of course the primary motive that
hits is making money in what they do.. !

  That really begs the point here.. most of such programmers really do
not try understand "Objects" as in OOPs with the construct of
metaclass/ behavior/MessageSend/ ClassDescription/.. etc .. they just
do with what is a pattern of code either as stmts or methods that they
see/ copy / run.. rather than worry about correct composition -
hierarchy - indirection even simple stuff like double dispatch.. et
als.

  Of course its a grey band .. so many are in the 70% range of the
gray band.. but few really do try and understand the OOPs internals
deep down.. Debugging / inspection is not wired in.. either

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

Janko Mivšek <[hidden email]> writes:
I thin OO has clearly won hands down. Look in every languages these
days. There are classes and objects. Even in the "main-stream" languages
like C#, and  Java it's  not a question whether OO  but only how. There
are still things lacking. That are blocks (I know they wer introduced
recently in both Java and C#) but probably not  used that much. The same
is true for ORM, it's not if but how it's done. I for  my part see the
biggest mistakte  in  doing that. Yes one can it make work, but it's
always a break and/or one is not using OO as it was meant to be used.

Since ages we get promised that OODBS or the like are the future but
what do you really have key/value pairs (that's since the good ole
Berkeley DB times) now the DBs got the name NoSQL, but in the end the
complete IT infrastructure relies and is build on RDBs (maybe with some
O extension in it. I guess therefor we'll be stuck with new approaches
to persistence through RDBs. Some will work under certain limits and
others's won't. And I don't think it's considered hard to do OO with
Smalltalk, Ruby etc. It is hard for C++ because this is a language full
of rites and that's makes it look that hard. Just remember the big hype
around Talingent? Now what's left of it.

Regards
Friedrich

--
Q-Software Solutions GmbH; Sitz: Bruchsal; Registergericht: Mannheim
Registriernummer: HRB232138; Geschaeftsfuehrer: Friedrich Dominicus

Am 27.02.2012 um 15:05 schrieb Friedrich Dominicus:
Typically there are just Java and C# courses nowadays...

There are two big problems in my eyes:
First, the majority of developers don't know the "real" OO and are stuck in their imperative way of thinking
(a fate that OO shares with other paradigms like functional programming).
When somebody wants to learn OO, he or she will most probably end in one of the mainstream languages,
like C#, Java and C++. The problem here is that there is only a vague description and no real definition of the term OO.

Second, what (real) OO delivers is mostly not valued in commercial environments.
Sure, everybody wants reusable, maintainable and scalable code, but only very few are willing to pay
the price for it.
In my experience you typically win a contract for the cheapest offer - quality is hard to measure and is most of the time
of lower interest and measured in funny units like lines of code or cyclomatic complexity.
As software projects are (almost always) complex, it's hard to get the requirements right. When the requirements
will be substantiated you can always add time and money to the contract :)
Customers typically cannot change the company that is working for them easily - too much time and money already spent
(and no guarantee that the next will do better).
So for an economical point of view for a software company it's better to be cheap than to be good and accurate.
Often it's even better to deliver bad solutions - they will bring more money.
To put it in other words: To my experience software development is driven by estimated costs and deadlines.
There is a saying: "Time, costs and quality - choose any two of them." But is anybody really willing to drop time or costs?

Regards
Andreas