BenFerrari On Other Peoples Sites

Das ist genau wie bei den Banken

2006-10-19T14:32:00.000-07:00

This is a copy from a comment of mine the orginial discussion can be found here.

Das Problem ist aehnlich wie bei den Banken: Jeder gibt seiner Bank alle moeglichen privaten daten. Weil die Services, die er dafuer bekommt, nuetzlich und manchmal sogar unumgaenglich sind.

Das aendert sich auch nicht, wenn die Banken diese Informationen weitergeben. Das aergert mich zwar, aber deshalb werd ich trotzdem nicht alle meine Konten aufgeben und nur noch bar bezahlen.

Aber zumindest macht google kein Geheimnis aus ihrem Vorhaben. Das das Unternehmen aus diesen Informationen kontextbezogene Werbung verkauft ist ja keine Neuigkeit.

Der grossteil des imperiums wird ueber solche werbung finanziert. Und ich als benutzer weiss gar nicht, ob und wie ich mich da beschweren soll. Schliesslich seh ich ja viel lieber Werbung die tatsaechlich fuer mich interressant ist, als irgendein blinkendes pornopopup.

Das problem wurde ja schon damals bei der Gmail debatte breitgetreten (email texte werden von einem bot analysiert und entsprechende werbung angezeigt)

Andererseits gibt es bei Google zumindest die Moeglichkeit, seine erstellten Accounts auch wieder zu loeschen.

Andere Firmen wie z.B. amazon sammeln aehnlich frech, behalten aber alle gewonnenen daten. Selbst wenn man seinen account loescht.

Fazit: Genau wie bei den Banken, muss eine Loesung auf politisch und auf zwar auf Verfassungsebene gefunden werden.

Services, die private daten sammeln, gaenzlich zu vermeiden ist schon heute fast untragbar geworden.

Michael Kight antwortete: Google benutzt seine Marktmacht und verbindet Services, die eigentlich überhaupt nichts miteinander zu tun haben.

Ich erwiederte:

Genau das ist meiner Meinung nach nicht der Fall: Google benoetigt ja die Informationen aus deinen Emails, um in deinen Suchergebnissen bessere Werbung einblenden zu koennen.

Googles Office Applikationen werden (fast) vollstaendig durch diese Werbung finanziert. Das sammeln der Daten ist also die finanzielle Grundlage fuer diese Programme.

Und sieh dir mal tools wie die Google Desktop search an, bei der man einen index seiner festplatte auf einen von googles rechnern laden soll. Bedenklich? Auf jeden fall! Aber im Gegenzug kann man immerhin von ueberall in meinem netzwerk von rechnern nach daten suchen. Das ist schon ein Nutzen.

Oder da ist dieses plugin fuer googles desktop, das dir nachrichten anzeigt. Welche Nachrichten das sind, berechnet ein Algorithmus aus deinen suchanfragen, deinen emails, den dateien auf Deinem Computer.

Und....

Ganz zu schweigen natuerlich von dem Moment, in dem die Werbung ueber den Suchergebnissen wirklich HILFREICH fuer den Benutzer werden. Also dieser Punkt in der Zukunft, in der ich mich ueber gute Werbung freuen kann.

Es ist also doch genau wie bei den Banken. Ohne Deine Daten kann hier nicht gearbeitet werden.

Das Google durch seine (kommende) Quasi-Monopolstellung wieder besonders gefaehrlich ist stimmt natuerlich. Was aber nicht heisst, das deine Kontodaten bei der BAWAG nicht in die USA exportiert werden.

Ich bleib dabei: "Dann benutz ich das einfach nicht" wird nie und nimmer funktioneren. Man muss Politiker, die derzeit einfach nicht nur zu gierig sondern vor allem auch zu alt sind, um sich in solchen Themengebieten zurechtzufinden, zu einem grundelegenden Schutz vor solchen Datensammlern zwingen.

2006-08-31T09:07:00.000-07:00

This is a copy from a comment of mine the orginial discussion can be found here.

cmerch19602006 wrote:

I've already expressed my opinion on the Yahoo! Answers(YA) mission and guidlines (as to the conflict I percieve to be there).

Now let me say what I think should be done about it.

First, I think the YA mission should remain unchanged.

I think the guidlines need some serious tweaking.

Here's the bombshell. I don't think free speech is what YA was created for. This is a privately run site not owned by the public so YAT can restrict our speech here in any way they see fit. THATS a fact!

xpress their opinions. I think the expression of opinion in YA is counter-productive to the YA mission and should be removed from the guidelines.

Trivia questions about FACT should be allowed, like "Where is the Gulf of Bothnia?". Trivial questions about opinons should not.

Start with these changes and then clarify the remainder of the guidelines, with regard to repeat answers, repeat questions. (we have button that pops up in this forum when we type in the subject field. It doesn't work that great but it can help. Why don't they put that in the Question form on YA?)

Okay. There's my opinion (so far). What's yours?

My Answer:

The mission statement is what I expected when I first heared about yahoo answers, and maybe that is why I took so long until I convinced myself to try that service.

The problem I have with "answering facts" is that this is a solution to a problem that is already solved very well. There are planty of services around the web that collect and index facts, like wikipedia. And these services are very easy to use, thanks to modern search engines like that from google, yahoo or microsoft.

For example, if I want to know where the Gulf of Bothnia is, I enter "wikipedia Gulf of Bothnia" in a search box and I get all the facts. Indeed, I found that I can answer many of the questions at yahoo! answers by copy, paste and reference from wikipedia and then get elected for best answer.

So what the guy who asked that question about the Gulf of Bothnia really needs to know is "What is the simplest way to find out where some place is located in the world?" and now we are back to opinions.

I really think that answers should be about opinions instead of facts, because this is something that is not covered well by other tools. Discussion forums are really more about discussing than about direkt answers/opinions to a statement/question.

Answers with its strict restrictions to how people can participate (only direct answers, no responses to other answers etc.) make the service ideal for controversial topics.

So as a summary, I think opinions are the way to go and not facts. Not because I enjoy all these "what is the best ...?" questions so much, but because yahoo has a chance to create something here instead of being just another encyclopedia.

Re: "Whats the difference between c, c++, visual basic and java."?

2006-08-26T04:33:00.000-07:00

This is a copy from a answer of mine to yahoo! answers. The original post can be found here.

The Question was: "Whats the diffrerence between c, c++, visual basic and java. And what applications can each of these be uesd for?"

My Answer:

OK, this is going to a very general answer. The differences between
these languages are much to complex to explain them to someone new to
programing.

First, you CAN use each of these languages for pretty much
anything. The difference in programming languages is not what you CAN
do with them, but which language is most comfortable to do what you
want.

So the main difference between all these languages is the level of
abstraction. The computer does only understand ones and zeros, so the
main focus in programming languages is to make the code understandable
to programmers.

If the level of abstraction is very high, you can write the solution
to a problem in much less code than with a "low level" language. But
since a lot of stuff relevant to the computer is hidden from you, the
program might not be that optimized for the machine as it could be.

C is a "low level language" , which means you have to do stuff like
memory management all by yourself. But because the level you program
is so close the machine here, C has become the de facto standard for
performance critical programming: Operating system kernels, 3D engines
etc. are mostly written in C.

Java is a lot more abstract. Memory management is "hidden" to the
developer, so he can focus on the problem rather than things like
performance, which doesn't matter that much most applications.

Java is also a language that has support for object oriented
programming. This is a way to structure code in a modular way, by
partitioning your problem domain in objects and sending messages to
them. Object oriented programming can also be done in C, but Java has
a lot of special syntax and rules that makes it a lot easier to
program this way.

Java is also a dynamic language, where the type of an object is
evaluated at runtime. This allows for some very advanced programming
techniques like meta programming. 

Java is very popular in server side programming (ebay.com is a good
example for a server side java application), customized business
software that needs to run on differenct platforms and mobile
applications.

C++ can be seen as a mix of these two levels of abstraction: The
developer has syntax and libraries for object oriented programming,
but still deals with low level stuff like memory management. C++ is
not a dynamic language. C++ is the language most desktop applications
for end users are written in: games, Microsoft office etc. But the
trend is to use more abstract languages here too.

The theories behind C++ is that you can write very performant code in
an object oriented style in C++.  But in praxis, it is often more wise to
first write a program in the most abstract way you know , find the
parts of the program that need to be optimized and then use a very low
level language (like C) to replace this code (in average, this makes
only about 5% of the code you wrote) in a very low level
language. This process is called OptimzeLater (
http://c2.com/cgi/wiki?OptimizeLater ).


Visual Basic is a language that was made by Microsoft to make it
easier to develop client software for the windows operating system,
since C++ is too low level for that. VB was very successful here and
it is used in many mall to medium sized companies to write customized
software that work closely with Microsoft office.

Visual Basic is used very rarely outside the windows world, and
Microsoft cancelled the further development on the language in version
6 in favor to Visual Basic.NET, which is different language (much
closer to Java than to Visual Basic 6! ) and optimized for the
Microsoft .NET framework.



I say it again, this was a very general overview of the topic, and I
missed out a lot of things other people might find important.  But in
my opinion, the level of abstraction in the languages you mentioned is
the most significant difference to consider.

And by the way, these languages are all very similar in many ways
to. Try a language like Prolog or Haskell to see how problems can be
solved in ways that are very different to C or Java and often a lot
more efficient.

Re: what is the pseudocode of getting the square root of a number??

2006-08-17T08:21:00.000-07:00

This is a copy from a comment of mine at yahoo answers. The orginial discussion can be found here.

Question: ela_pam08: what is the pseudocode of getting the square root of a number??

Answer: Here is a simple solution after newtons method: Probably not the best, but it is the most simple solution:

Re: How to put a search button in my website?

2006-08-17T02:36:00.000-07:00

This is a copy from a comment I wrote to yahoo answers. The orginial document is here.

How to put a search button in my website?

I have many movie reviews, and I was wondering how I can put a search box where they type in the name and it shows them the page. I use xhtml / dreamweaver.

My Answer:

One way to do this is by simply using a third party search provider to do the search for you. Google and Yahoo! do already index your content, so all you have to do is to create a form with an input field that links to a search limited to your domain. For example, this form searches inside answers.yahoo.com :

and here is the same form if you want to search your page with yahoo search:

If you want to index the content yourself, you should take a look at lucene , an open source platform that allows you to create and search indices for arbitrary contents.

Re: Der offizielle Python-vs-Ruby Thread.

2006-08-11T04:26:00.000-07:00


This is a copy from a comment of mine. The whole diskussion can be found here:
Re: Der offizielle Python-vs-Ruby Thread.

ok ich bin dabei,  aber nur der spasses halber. Ich programmiere
eigentlich sehr gerne in python.

> 
> - Python ist besser weil man's viel besser lesen kann
> - Sorry, aber #@$& und vor allem $1, $/, $_ & Co sind einfach häßlich

reine Ansichtssache. Ich hab beide Sprachen sehr lange verwendet und
finde die syntax in beiden faellen recht ertraeglich. __method__ und
das verfluchte self find ich auch nicht besonders schoen.

Und der Lesbarkeit schadet @ ganz sicher nicht, es sei denn du kennst
die syntax der Sprache nicht. Das ist in python aber auch nicht
anders, zumindest wenn man mehr als nur ein kurzes code snippets
verstehen moechte.

> - Python ist schneller weil's einen Bytecode-Interpreter und optional
> einen JIT-Compiler gibt
> - Ruby: Warum brauche ich alle 3 Konstruktionen:
>  if A then B else C end
> 
>  case
>    when A: B
>    else C
>  end
> 
>  A ? B : C
> 
> Wo doch alle das gleiche tun?

Wenn es nur darauf ankaehme, was ein code tut, koenntest du auch in
assembler programmieren. Es kommt darauf an wie er ausschaut, und die
eleganteste loesung ist hier manchmal eine case anweisung, manchmal
ein if then else construct.

das python motto "there should be only one (obvious) way to do it"
ist zwar eine gute Idee. Aber wenn man sich dann code aus grossen
python projekten ansieht, dann sieht man das es nicht sinnvoll ist
creative menschen durch syntax einzugrenzen. Z.B verwenden viele
Hacker dictionaries,  um case statements zu imitieren.

Ruby ist ausserdem eine Sprache, die fuer das Erstellen von domain
specific languages optimiert ist, und darum muss es viele
verschiedene Wege geben, etwas auszudruecken. DSLs wie rake oder die
von rails lassen sich in python nicht so elegant umsetzen.

> - Dafür kenne ich keine anständigen Replacements für numpy, scipy und
> PIL

python ist weiter verbreitet und hat mehr bibliotheken, ja. Das selbe
trifft auf Java im Vergleich zu Python zu.

> - Und überhaupt: Python war vorher da, und Ruby hat's alles nur
> geklaut (ich weiß, das zieht besser wenn's um MS geht...)

Wie jede andere Technologie sind auch python und ruby das ergebnisse
von einer technischen evolution. Ruby hat ganz sicher sehr viel von
seinen surzeln uebernommen (smalltalk, lisp) und python ebenfalls
(haskell, C).

auch von python hat ruby viel uebernommen. Von geklaut kann hier aber
nicht die Rede sein, sonst haette Python diese Features ja jetzt
nicht mehr.

Im uebrigen kann ich noch die ueblichen pro-ruby argumente anfuehren:
von grund auf objektorientiert (bei python wurde das nachtraeglich
implementiert), native closures, message driven usw.





This is a copy from a comment of mine, located here: 

http://www.heise.de/newsticker/foren/go.shtml

> Nein, ich hab längere Zeit mit Ruby gearbeitet und es hat mich
> dauerhaft genervt irgendwelche kryptischen Sonderzeichen eintippen zu
> müßen. Ich will nicht dass mein Code aussieht wie Fluchen in einem
> Snoopy-Comic.

wie schon gesagt, das ist Ansichtssache. Ich weiss nicht wie die
Tatsache, das es dich genervt hat, mich davon ueberzeugen soll das es
fuer die meisten anderen Programmierer nicht so ist. Fuer mich zum
Beispiel sind Sonderzeichen gar kein Problem, sofern sie nicht, wie
z.b. in Perl in unterschiedlichen Kontrukten unterschieldiche
Semantik haben.

Ruby ist aber in sich voellig konsistent und einheitlich, und @ ist
nichts weiter als eine alternative zu self (das es in ruby auch
gibt).

> > Wenn es nur darauf ankaehme, was ein code tut, koenntest du auch in
> > assembler programmieren. Es kommt darauf an wie er ausschaut, und die
> > eleganteste loesung ist hier manchmal eine case anweisung, manchmal
> > ein if then else construct.
> 
> Moment, gegen eine case-Anweisung (wie es sie auch in C gibt) hab ich
> nichts - aber die Form:
>  case when A=5: ... when B=7:
> Ist nur ein verkapptes if..else if...end.

Eine case anweisung ist immer ein "verkapptes if..else if...end.".
Die case anwesiung oben unterscheidet sich vom aufbau nicht
wesentlich von denen in C.

> Die
> "wir-stopfen-jede-Syntax-die-uns-einfälltin-die-Sprache"-Mentalität
> führt halt auf dauer zu unwartbaren Sprachen und Programmen.
> 

wie gesagt, das hab ich auch gedacht und wurde eines besseren
belehrt: wenn man DSL - basiert programmieren moechte, ist das ein
grosser Vorteil. Unwartbar wird der code in Wahrheit naemlich nicht,
wenn man viele moeglichkeiten der darstellung erlaubt, sondern wenn
man im selben code in den gleichen/aehnlichen situationen
unterschiedliche kontrukte verwendet.

Aber ich halte nun gar nichts davon, eine Sprache zu entwickeln, die
schlechte Programmierer davon abhalten soll, Bloedsinn zu machen.
Schlechte programmierer werden den Code naemlich auf JEDEN FALL
ruinieren, ganz egal welche Sprache sie zur Verfuegung haben. 

Sprachen muessen fuer gute Programmierer entwickelt werden und die
brauchen viel Freiheit und wenig Grenzen.  Die Sprache soll schon
alles fernhalten, was mich davon abhaelt, mich auf das Problem zu
konzentrieren.  Aber mir so wenig syntax wie moeglich zu geben,
damit ich auch ja nicht jede condition in einer anderen Weise
aufschreibe, ist eine Bevormundung. Und die brauche nur
Programmierer, die sowieso nicht an ernsten Projekten teilnehmen
sollten.

> > ...
> > Im uebrigen kann ich noch die ueblichen pro-ruby argumente anfuehren:
> > von grund auf objektorientiert (bei python wurde das nachtraeglich
> > implementiert), native closures, message driven usw.
> 
> Also wenn du schon mal Python programmiert hättest müsstest du aber
> wissen dass Python von anfang an durchgehend Objektorientiert war...

Nein. Das heisst: Es kommt natuerlich darauf an, was man unter
"OOP-Sprache" versteht. Java ist ja z.b. auch in gewisser Weise
objektorientiert, aber halt nicht in dem Sinn in dem wir
ruby/python/smalltalk programmierer das verstehen.

von http://docs.python.org/lib/types.html:

"...Historically, Python's built-in types have differed from
user-defined types because it was not possible to use the built-in
types as the basis for object-oriented inheritance. ..."

Diese unterscheidung gab es in ruby nie. Darum schreibt man heute z.b
in python funktionen z.b. ( abs(5) ), anstatt, wie es in in
Objektorienten sprachen ueblich ist, Nachrichten an Objekte (5.abs)





> > Ruby ist ausserdem eine Sprache, die fuer das Erstellen von domain
> > specific languages optimiert ist, und darum muss es viele
> > verschiedene Wege geben, etwas auszudruecken. DSLs wie rake oder die
> > von rails lassen sich in python nicht so elegant umsetzen.
> 
> ich kenne rails nur von screencasts, aber was ist an rails so viel
> eleganter als beispielsweise django (www.djangoproject.com)?

Ich kenne wiederum django nicht gut genug, um dir darauf eine Antwort
geben zu koennen :(. Ich werde aber sicher demnaechst einen tieferen
Blick in Django werfen und kann Dir nur raten das selbe bei Rails zu
tun. Zumindest bei Rails sind die meisten Screencasts nur kurze
Showeinlagen, in denen man features zu gesicht bekommt, die dann in
der praxis nicht wirklich so relevant sind. Was mir an Rails gut
gefallt ist ein Gesamtpacket, das man so leicht nicht vermitteln
kann.

Ich hatte mich ja aber nicht auf das Framework als ganzes benogen,
sondern darauf, das in Rails die Configuration in einer DSL
beschrieben sind, die in python so nicht dargestellt werden koennte.

Wenn dich das Thema DSL in Ruby interressiert, siehe hier:

ueber DSLs allgemein:

http://martinfowler.com/articles/languageWorkbench.html

Ein Beispiel von einer DSL in Ruby (Rake):

http://www.martinfowler.com/articles/rake.html



mick3 schrieb am 11. August 2006 17:29

> bejo schrieb am 11. August 2006 14:48
> 
> > > > von grund auf objektorientiert (bei python wurde das nachtraeglich
> > > > implementiert),
> 
> > von http://docs.python.org/lib/types.html:
> >
> > "...Historically, Python's built-in types have differed from
> > user-defined types because it was not possible to use the built-in
> > types as the basis for object-oriented inheritance. ..."
> 
> Genau, dies war eine Einschränkung bedingt durch die Implementation.
> Verbung  für eigene Klassen war in Python von Anfang an dabei. Die
> UserDict-Klasse  z.B. diente zur Ableitung von eigenen
> Dictionary-Klassen. Insofern wurde bei Python keine OOP nachträglich
> implementiert, sondern die Mängel der Implemtierung und
> Unterscheidung beseitigt.

Wie schon gesagt, auch Java und C++ sind eigentlich Objectorientierte
Sprachen.
Python war da nicht anders. Aber unter einer reinen OO Sprache
versteht man, das moeglichst alles ein objekt ist, auf das man ueber
methoden nachrichten schickt.

Und das ist, wie du oben beschrieben hast, in python erst
nachtraeglich eingebaut worden. UserDict mag ein first class Object
gewesen sein, aber {} war es nicht. Man musste das immer besonders
behandeln, da man z.b. nicht davon ableiten konnte. In den Anfaengen
von Python gab es nichteinmal diese UserDict Altertnative! 

In Ruby, wo man sich sehr an die Ideen hinter Smalltalk gehalten hat,
wurde das von vornhinein so integriert. Hier ist alles ein objekt,
oder eine nachricht an ein objekt.

> Naja, abs() war eben eine einbaute Funktion für die leider kein
> Operator mehr frei war. Ist auch schöner, als x.__a__() zu schreiben
> ;)

Genau das. python hat sowas wie funktionen, denen man objekte als
argumente uebergibt. In Ruby gibt es sowas wie eine funktion nicht,
nur eben methoden, mit denen man den zustand von objekten abfragt und
manipuliert.

Und wenn ich wissen will, wie der absolutwert einer zahl ist, na dann
frag ich die zahl halt.

> 
> Nach Deiner Logik und der "reinen Lehre" müßte man also auch
> sämtliche (aritmetische/logische/vergleichende) Operatoren aus einer
> OOP-Sprache verbannen und an dessen Stelle z.B. 5.plus(5) oder
> 5.gt(5) schreiben?

Ja eigentlich schon. Tatsaechlich sind ja sowohl in python als auch
in ruby operatoren methoden auf objekte (5 + 5 ist doch in python das
selbe wie 5.__plus__(5), oder so aehnlich.)

Ich persoenlich finde das auch sinnvoll, da man sich bei
mathematischer notation nunmal daran gewoehnt hat. Da das aber in
python und ruby gleich funktioniert, muessen wir ja auch nicht
drueber diskutieren, welche sprache es besser macht.

Bei abs(5) ist das nicht mehr der fall, weil das nur einen operator
hat und nicht in infix noitation dargestellt werden kann. 5.abs ist
hier die objektorientierte, abs(5) die imperative schreibweise.

In Python kann ich den Spieß auch rumdrehen und
> den Operator als mein wichtigstes Objekt betrachten.

Natuerlich kannst du das, in Python wie in Ruby. Es waehre aber nicht
sehr objektorientiert, denn ein operator definiert ja eine aktion und
somit eine methode, kein objekt mit einem zustand.

Wie wäre es denn
> mit operator.abs(5)? Warum benutzen Ruby-Programmier puts/gets oder
> print als Anweisungen und nicht 5.puts als Methode? Irgendwie auch
> nicht ganz konsequent. :)

gutes beispiel: um ein object auf die stdout auszugeben kannst du
schreiben:

5.display

Also genau was du oben angegeben hat. Und auch die Alternative "puts
5" ist ein objektorientierter Aufruf, bei dem an ein objekt (das, in
dem du dich gerade befindest) die methode puts aufgerufen wird, also
die nachricht das uebergebene Argument auszugeben. Was dir besser
gefallt ist Dir ueberlassen, OOP ist aber beides. Anders als in
Python gibt es in Ruby keinen Code, der Ausserhalb eines Objektes
steht.

+++++++++++++++++++++++++++++++++++++++++++++++
Ich will an dieser Stelle nochmal wiederholen, was ich oben schon
gesagt habe: Das ich nichts gegen python hab.

Das hier ist eine Diskussion rund um Spitzwindigkeiten. Das man in
Ruby so viel produktiver ist als in python, weil es viel mehr
objektorienntiert ist, hab ich nicht gesagt und glaub ich auch nicht.

Ich sag das nur damit ich nicht falsch verstanden werde.

Ich beschreibe hier nur warum die dinge in ruby so sind wie sie sind,
nicht das das der einzige Weg ist an eine Programmiersprache
heranzutreten.
+++++++++++++++++++++++++++++++++++++++++++++++

Hier noch ein Beispiel fuer Rubys reinen OOP Ansatz:

Ein Beispiel, das auch einem Grundkurs fuer Programmierung stammen
koennte:

Pseudocode:

class Person
 attr :name
end

class Employee < Person
end

class Customer < Person
end

Sagen wir ich will jetzt ein Attribut "age" hinzufuegen. Wo mach ich
das?
Natuerlich in Person, nicht wahr?

So, in Ruby kein Problem. Aber in Python geht das nur dann, wenn ich
auf die Klasse Person zugriff habe, also wenn sie z.b. KEIN Teil der
standard library ist!

Der Grund dafuer ist, das man verhindern will, das jemand in Methoden
in der stdlib rumfuscht und bestehdene Methoden veraendert, so dass
sich ihr zustand aendert. Das koennte natuerlich zu einer Katastrophe
im Ganzen system fuehren .

Das bedeutet jetzt aber, das dieses grundlegende Beispiel in Python
nicht so gemacht werden kann, wie es fuer einen programmierer logisch
waehre. Eine Umweg sieht dann z.B. so aus

class Person
 attr :name
end

class MyPerson < Person
 attr :age
end

class Employee < MyPerson
end

class Customer < MyPerson
end

Was dann, wie man sieht, einiges an refactoring erfordert. 

In Ruby jedoch erlaubt man das nachtraegliche oeffnen und ueberladen
von _jedem_ Objekt. Ganz egal wo es herkommt. Dadurch kann ich eine
methode dahin packen, wo sie hingehoert.

Ein praktisches Beispiel ist z.b. eine methode auf ein array, die die
Elemente im Array shuffelt. In python ist das random.shuffle(Objekt).
Was zur hoelle ist ein random? Ich will natuerlich der Liste eine
Nachricht schicken, also schreib ich sowas wie:

class Array
  def shuffle!
    self.sort_by{rand}
  end
end

und kann dann anschliessend damit arbeiten:

[1,2,3,4,5].shuffle!

Warum erlaubt Ruby sowas gefaehrliches? Ganz einfach: Weil es nur
dann gefaehrlich ist, wenn einen richtig schlechten, unerfahrenen
Programmier an den Code laesst. So jemand macht aber auf JEDEN FALL
den Code kaputt, ganz egal welche Sprache er benutzt. Dafuer spricht,
das solche Fehler in der Praxis so gut wie niemals auftauchen. Fuer
einen guten Programmierer aber ist der Python Weg eine
Einschraenkung.

Aber natuerlich ist auch die Einschraenkung von Python nicht dumm,
sondern folgt halt einer anderen Philosophy. Allerdings, und das ist
mein Argument, ist dieser Ansatz dann nicht mehr so streng
objektorientiert wie z.b. in Ruby oder Smalltalk.

> Apropos Mängel, wie sieht es eigentlich
> mittlerweile mit Unicode unter Ruby aus?

Ruby hat, im Gegensatz zu python, keine nativen unicode object. Das
wird sich bis zum naechsten Versionssprung auch nicht aendern. Wenn
das gar keine Frage war, sondern ein versteckter Hinweis darauf das
Python besseren support fuer unicode hat: Ja, das stimmt, da geb ich
Dir recht.



Moersfan schrieb am 12. August 2006 13:28

> bejo schrieb am 11. August 2006 14:48
> 
> > Diese unterscheidung gab es in ruby nie. Darum schreibt man heute z.b
> > in python funktionen z.b. ( abs(5) ), anstatt, wie es in in
> > Objektorienten sprachen ueblich ist, Nachrichten an Objekte (5.abs)
> 
> das ist doch nur syntaktischer zucker. abs(5) ist nunmal 5 .__abs__()
> und len(5) ist 5 .__len__()
> 

Es muss (5).__abs__() heissen. 5.__abs__() funktioniert nicht, aus
historischen gruenden. Und auch der syntactische zucker abs(5) wird
in python aus historischen gruenden vorgezogen.

Fuer den Fall dass du nicht den ganzen Thread gelesen hast: Ich
argumentiere, das python in seinen Anfaengen nicht als rein
objektorientierte Sprache konzipiert war, und das man das heute an
vielen stellen sehen kann. abs(5) ist da schon ein gutes beispiel.

> mfg
> moersfan
> 
> PS: wenn ruby native closures hat, was hat dann python für closures?
> ich hab bisher häufiger closures in python verwendet. wie nennt man
> diese dann? non-native? und wo liegt der unterschied?

Der unterschied liegt darin, das man die Closures in ruby viel besser
benutzen kann, um DSLs zu schreiben. sieh dir dazu z.B. mal rake an,
das ich irgendwo in diesem Thread schonmal verlinkt habe.

Klar versteht Python closures, aber wenn Du typische ruby, smalltalk
und python APIs miteinander vergleichst, dann siehst du wie closures
in ruby und smalltalk praktisch ueberall sinnvoll verwendet werden,
wo es in python nicht so praktisch waehre.

100.times do
  print "foo"
end

oder

File.open("foo.txt") do |f|
 f.write
end

kriegt man in python nicht so gut hin, weil die closures nunmal nicht
direkt in die syntax eingebaut sind.




> grob vereinfacht:
> ruby: "in python gibts ja kein 5.abs() also nicht OO"
> python: "aber abs(5) ruft doch eh nur 5 .__abs__() auf, sieht
> syntaktisch nur anders aus, ist aber OO"

ja, und genau das "meine ich ja. 
In Python duerfen diese methoden aus gutem grund so huebsche namen
wie __xxx__() namen haben. Man ruft sie in der Regel nicht direkt
auf, sondern verwendet eine imparative Schreibweise.

Fuer einen Ruby programmierer ist das senden von "abs" an das objekt
"5" der natuerliche weg. Koennen wir auch anders machen, wuerde aber
nicht zu unserem Verstaendnis von OOP passen.

Es geht nicht darum das beides im hintergrund OOP ist. Das ist ja
gottseidank in beiden Sprachen so. Es geht darum wie man es am Ende
verwendet. Und abs(5) bedeutet nunmal: berechne den absolutwert von
5, waherend wir Rubyianer uns eher fragen wuerden: 5, sag mir deinen
absolutwert.

Dazu sag ich dann weiter unten noch etwas.

> > 100.times do
> >   print "foo"
> > end
> ...
> closures sind für mich sowas (mal mein beispiel aus der wikipedia):
> 
> def closure():
>    _counter=[0]
>    def inc():
>       _counter[0]+=1
>    def get():
>       return _counter[0]
>    return inc, get
> 
> hier als beispiel mal ein anonymer counter

Ich denke wir verstehen schon das selbe unter closures.
Siehe hier z.b. ein post das ich 2004 geschrieeben habe. Hier
uebersetze ich die closures beispiele aus einem Artikel von Martin
Fowler in Python:

http://twoday.tuwien.ac.at/ferrari/stories/643/

Ich kann auch Closures in Ruby aehnlich definieren wie Du das oben
getan hast:

def closure
  counter = 0
  inc = Proc.new{counter += 1}
  get = Proc.new{counter}
  return inc, get
end

Aber auch die "ruby-bloecke" sind in Wirklichkeit nur syntactischer
Zucker fuer eben solche closures. Hier ein Beispiel:

File.open(filename) do |file|
 # mach etwas mit dem file object
 # nach dem block wird das filehandle automatisch geschlossen.
 # file.open(), file.close() und errorhandlich passieren im Kontext
 # von File.open und sind fuer die Closure anonym.
end

Das sind ebenfalls nichts weiter als codebloecke in einem anonymen
Kontext.
Nur das man diese syntax eben sehr gut verwenden kann, um scheinbar
neue Sprachkonstrukte zu verwenden. Und das ist bei DSLs dann halt
sehr praktisch.

z.B:

#implementierung:
def sometimes
  yield if rand < 0.5
end

#usage
sometimes do
  puts "I get executed only with a 50 percent chance"
end

Dem Counter koennte ich dann z.b. auch so in eine closure einbetten:

definition:

def with_counter
  counter = 0
  yield proc{counter}, proc{counter += 1}
end

example:

with_counter do |get_counter, inc_counter|
  inc_counter.call
  print get_counter.call
end

Warueber wir uebrigens noch gar nicht gesprochen haben, was aber
meiner Meinung nach einer der groessten Unterschiede zwischen Ruby
und Python ist:

Wie die beiden Sprachen den "." benutzen. 

In Python wird die Anweisung

object.foo

in etwa so betrachtet:

"Greife in den namespace 'object' auf das attribut foo zu."

Diese Sichtweise ist wahrscheinlich aus Art uebernommen worden, wie
man in C auf Structs zugegriffen hat.

in Ruby wuerde die selbe Anweisung bedeuten:

"Sende die nachricht 'foo' and das object "object."

Tatsaechlich ist object.foo nur syntactic sugar fuer

object.send("foo")

Das kommt ganz klar von Smalltalk, wo man OOP in etwa definiert hat
als "Objekte mit einem Zustand, an die man Nachrichten schickt".

Ich glaube nicht, das eine der beiden Sichtweisen besser ist als die
andere.
Aber ich persoenlich mag halt den smalltalk weg lieber.

Und wenn man als pythianer verstehen will, warum Ruby manche dinge so
macht (z.B warum musste ich oben inc.call sagen statt einfach inc()
), dann muss man sich diesen Unterschied meiner Meinung nach genauer
anschauen.

In Ruby z.B, kann ich nicht wie in python auf ein attribut direkt
zugreifen.
Dadurch wird kapselung etwas simpler:

Es stellt sich gar nicht die Frage, ob ein Attribut private, public
oder was auch immer sein soll. In Ruby darf ich sowieso nicht auf ein
attribut zugreifen, sondern nur ueber eine nachricht danach fragen.
Features wie properties, die nachtraeglich in python eingebaut wurden
(PEPs 252 and 253), werden dadurch in Ruby ueberfluessig.

Andererseits muss ich, wie man oben in meinem Beispiel "with_counter"
sehen kann, die methoden proc und inc explicit mit der methode call
ausfuehren.

Denn da methoden in ruby nur nachrichten sind, bekomm ich da keine
methoden zurueck, sondern extra methoden-objekte.

Wie gesagt, kann man sicher drueber streiten, was besser ist. Aber es
hat meiner Erfahrung nach einen riesen Einfluss auf die gesamte
Sprache und seine Bibliotheken. Fast alle Bilbiotheken sind in Ruby
sehr einheitlich nach dieser Logik aufgebaut.

Als ich z.B zum ersten mal in Python die Elemente eines Arrays
schuffeln wollte, musste ich in Python erst einmal nachschauen, wo
die entsprechende Funktion dafuer ist.

In Ruby wahre so etwas wie random.shuffle([1,2,3]) eine sehr
unnatuerliche Art, eine API zu definieren.  Denn wenn ich nach der
den Zustand von dem Array veraendern will, dann frag ich
selbstverstaendlich das Array danach und nichts anderes.

Und genau deshalb verwenden wir Rubyianer auch so gerne closures
anstatt while, for usw:  Weil es aus unserer Sicht viel logischer
ist, die Objekte, von dene wir etwas wissen wollen, selbst zu
beauftragen.




Ich hab schon lange nicht mehr so eine anstaendige diskussion zu so
einem potentiellen streitthem gefuehrt. Und das auch noch auf heise
online :)

mick3 schrieb am 12. August 2006 16:06

> Nein, im Ernst, der erste Gedanke von Python-Programmierern bei einer
> Erweiterung von Klassen ist die durch Komposition. Der zweite ist
> dann Vererbung und Überschreiben (also UserDict) und erst der dritte
> ist die (dynamische) Modifikation/Erweiterung von Basisklassen (also
> builtins als  first-class Objekte)
> Bei Ruby (Smalltalk?)-Programmierern  ist dies es anscheinend genau
> anders herum :)

ja, so kann man es eigentlich sagen. Wir ueberlegen uns welches
objekt fuer etwas die 'Verantwortung' traegt, und kommt dann der code
hin.

Anmerkung: Ich verwende vererbung auch nur sehr selten. Zum Teil weil
delegation  in ruby sehr schoen zu implementieren ist.

> 

> 
> > Genau das. python hat sowas wie funktionen, denen man objekte als
> > argumente uebergibt. In Ruby gibt es sowas wie eine funktion nicht,
> > nur eben methoden, mit denen man den zustand von objekten abfragt und
> > manipuliert.
> Wie hier schon jemand bemerkt hat, sind in Python (seit 2.2?) alle
> Funktionen, auch die eingebauten, wie abs(), Objekte:
> ...

ja, dass wuste ich eh. Ich glaube mittlerweile in einer anderen
antwort auch  darauf eingegangen:


http://www.heise.de/newsticker/foren/go.shtml?read=1&msg_id=11004413&forum_id=102435


> 
> Python ist stark von der funktionalen Programmierung  beeinflusst, so
> daß es ziemlich normal
> ist, daß auch "Standalone"-Funktionsobjekte (len(), map() etc.)
> verwendet werden.
> 
> Ich finde es einfach gut, wie dieser Ansatz in Pythons OOP integriert
> ist.
> 

In Ruby sind diese funktionalen Elemente auch alle enthalten, nur
eben wieder integriert in das Ruby typische OOP system.

Hierzu wieder ein Link:

Ich hab mal fuer einen Kollegen einen Beitrag geschrieben, in dem ich
map, filter, lamda usw. in python erklaehrt habe. Ein Hacker namens
Ian Blenke hat dann einen Follow-up geschrieben, in dem er das ganze
mit ruby vergleicht:

http://ian.blenke.com/thoughts/rubymapreduce/rubymapreduce.html

> >
> > Und wenn ich wissen will, wie der absolutwert einer zahl ist, na dann
> > frag ich die zahl halt.
> Bei der Diskussion geht ja darum, ob Python vom Ansatz her genauso
> OOP ist wie Ruby. Dies ist meiner Meinung nach der Fall. Die Frage,
> ob jedes Objekt alle Methoden selbst "mitbringen" muss, ist ein
> anderes Thema.

Naja, so wie ich OOP gelernt haben sind Objekte selbst dafuer
verantwortlich, ihren Zustand zu manipulieren. Natuerlich gibt es
auch Ausnahmesitationen, in denen das nicht sinnvoll ist. Aber die
seh ich in den vorangegangen Beispielen nicht.

Kleine Frage am dazu Rande - steht dann etwa
> "Printer.print(sheet)" für Python  und"Sheet.printme(printer) für
> Ruby? Was würdest Du als Ruby-Programmierer bevorzugen?
> 

Beides ist in diesem Fall gut, weil die Verantwortung in beiden
Objekten logisch weahre.

vielleicht wurd ich sogar etwas in der Art machen:

class Sheet

 def print(io)
  #...
 end

end

class Printer
 def print printable
  printable.print self
 end
end

> Unäre Operatoren in imperativer Schreibweise gibt  es aber auch in
> Ruby, oder?

ja. Wie gesagt, es gibt immer ausnahmen, wo man sich der
bequemlichkeit halber von der eigentlichen Idee wegbewegt. Ich
versteh das halt bei -5, bei abs(5) ist es mir schon zu viel, und bei
random.shuffle(arr) find ich das schon unschoen.

> >
> > In Python kann ich den Spieß auch rumdrehen und den Operator als mein wichtigstes Objekt betrachten.
> > Natuerlich kannst du das, in Python wie in Ruby. Es waehre aber nicht
> > sehr objektorientiert, denn ein operator definiert ja eine aktion und
> > somit eine methode, kein objekt mit einem zustand.
> Das hängt natürlich wieder von der Betrachtungsweise ab. Beides ist
> OOP. Stichwort Beispiel Printer <--> Sheet :)

Meiner Meinung nach sind die Beispiele sehr unterschiedlich. Printer
und Sheet sind zwei Objekte (im sprachlichen sinn), ein plus, minus
und abs ist eine action bzw. ein wert. Eine methode ist fuer mich
eben kein objekt, sondern eine nachricht an ein solches. Das diese
nachricht dann technisch gesehen wieder ein objekt ist find ich ok,
aber von design her ist sie es nicht.

> Die "Funktion" abs(5) ist ein objektorientierter Aufruf, bei dem  im
> Toplevel-Scope __ main__ (das, indem du dich gerade befindest) das
> Funktionsobjekt __builtins__.abs mit "__call__(5)" aufgerufen wird,
> welches wiederum die in "5" als numerisches Objekt eingebaute Methode
> __abs__() aufruft. Die Funktion abs() ist in dem Sinne ein unärer
> Operator wie  (-, +,  ~). Du kannst natürlich "x.__abs__()" als
> Alternative aufrufen, was Dir besser gefallt, ist Dir überlassenen,
> OOP ist aber beides.  Da ich kein Sprachentwickler bin und auch noch
> nie in comp.lang.python war, hoffe ich, mir ist keiner böse, falls
> hier etwas nicht ganz exakt erklärt ist.

Das stimmt so in etwa denk ich (war frueher gern in
comp.lamng.python. ist halt schon eine weile her :) ). Allerdings ins
__main__ ein modul und nicht von Object abgeleitet. Methoden, Module
und Objekte sind ich Python zwar alles objekte, allerdings sehr
unterschiedliche. Du kannst z.B von einem modul nicht erben.

> Korrekturen sind gern willkommen.
> > Anders als in
> > Python gibt es in Ruby keinen Code, der Ausserhalb eines Objektes
> > steht.
> Wie funktioniert dann eigentlich der Toplevel-Scope in Ruby? Warum
> muß ich nicht (wie in Java) eine Main-Klasse definieren?  Ist das
> kein Kompromiss in Sachen OOP? ;)

der top level code befindet sich in einer privaten instanzmethode
eines objekts, das beim aufruf des interpreters instanziert wird:

irb(main):002:0> self.class
=> Object

> > Das hier ist eine Diskussion rund um Spitzwindigkeiten. Das man in
> > Ruby so viel produktiver ist als in python, weil es viel mehr
> > objektorienntiert ist, hab ich nicht gesagt und glaub ich auch nicht.
> Ich habe keine Probleme, wenn jemand sagt, das Ruby mehr
> objektorientiert im Sinne von Smalltalk ist. Womit ich nicht
> einverstanden bin, ist das häufig geäußerte Missverständnis, das
> Python ursprünglich (wie Perl und im Gegensatz zu Ruby) kein OOP
> hatte und dies erst nachträglich (auch als Wertung gemeint) zur
> Sprache hinzugefügt wurde. Hier wurde eine "urbane Legende" in die
> Welt gesetzt. Bei Sprachen wieC++/Java / C# bestreitet ja auch
> niemand das Vorhandensein von OOP von Anfang an.

Oha: Ich hab das vielleicht nicht deutlich gemacht, aber schon ein
paar mal angesprochen:

Je nach dem wie man "Unterstuetzung fuer OOP" definiert, sind Java,
C++ oder C# natuerlich objektorieniert. Und Python ebenfalls.

Aber unter der Auffassung: "alles ist ein objekt", ist smalltalk und
ruby am naechsten dran, weil hier eben alles aus objekten und
nachrichtenb besteht.

Python gehoert, bis auf ein paar wenige ausnahmen (mittlerweile) auch
dazu, aber ist eben erst historisch da hineingewachsen.

Im vergleich mit C++ war python natuerlich schon immer OOP :).

> > In Ruby jedoch erlaubt man das nachtraegliche oeffnen und ueberladen
> > von _jedem_ Objekt. Ganz egal wo es herkommt. Dadurch kann ich eine
> > methode dahin packen, wo sie hingehoert.
> > Aber natuerlich ist auch die Einschraenkung von Python nicht dumm,
> > sondern folgt halt einer anderen Philosophy. Allerdings, und das ist
> > mein Argument, ist dieser Ansatz dann nicht mehr so streng
> > objektorientiert wie z.b. in Ruby oder Smalltalk.
> >
> Damit hat man unter Ruby also zwei  gleich einfache Wege,
> Klassen/Objekte zu erweitern und überladen:
> (Ich würde sogar sagen der zweite Weg ist verlockender :)
> 
> 1. Den herkömmlichen Weg wie in (C++/Java), die (Basis) Klasse im
> Quellcode an Ort und Stelle zu erweitern.
> Vorteil - aller Änderungen sind zusammenhängend sichtbar an einer
> Stelle.
> Nachteil - keine Änderungen/Erweiterungen von (Basis)-Klassen möglich
> , wenn z.B. Quellcode nicht vorhanden.
> 
> 2. Den "Ruby/Smalltalk-Way", Klassen bzw. Objekte "offen" zu lassen.
> Vorteil - Änderungen an einzelnen Objekten und kompletten
> Klassenhierarchien jederzeit und überall möglich.
> Nachteil - Änderungen/Erweiterungen können dann über den kompletten
> Programmcode verstreut und nicht mehr nachzuvollziehen sein, mögliche
> Sicherheitsprobleme beim Überschreiben von "builtins" usw...
> 

Ich glaub darauf bin ich schon eingegangen: Der zweite Weg ist auf
jeden Fall gefaehrlich, allerdings nur wenn du es nicht besser
weisst.

Ruby programmierer oeffnen Klassen in der Regel nur dann, wenn eine
methode, an deren source man nicht rankommt, offentsichtlich da
hineingehoert. Sie veraendern aber auch dann niemals ddie bestehedne
Funktionalitaet des objektes, sondern fuegen nur zusaetliche
Funktionalitaet hinzu. Mit Ausnahmen vielleicht bei kleineren
Scripten.

Das ist wieder der unterschied zwischen kindersicherung und freiheit.
Ich glaube das man keine Kindersicherung benoetigt, weil man Kinder
sowieso nicht an Produktivcode lassen sollte.

ACHTUNG, Weil man das jetzt auch falsch verstehen koennte:
Ich MAG dinge wie z.B. automatische Garbageverwaltung, obwohl das ja
auch eine art Einschraenkung ist. Der Unterschied zu dem Fall oben
ist hier, das auch ein erfahrener programmierer zeit in manuelle
speicherverwaltung stekcne muss, daher ist es sehr gut wenn man das
wegabstrahiert. Aber bei den "geschlossenen" built in Klassen hat ein
guter Programmierer keine Vorteile, sondern nur nachteile.

Re: Java ist im Netz mehr als ausreichend dokumentiert

2006-08-09T09:19:00.000-07:00

This is a copy from a comment I posted here: heise.de: O'Reillys Liste der beliebtesten Programmiersprachen. Dem kann ich nicht zustimmen. Ich gebe Dir recht, das Java im Netz sehr gut dokumentiert ist. Das selbe gilt jedoch auch fuer die meisten anderen Sprachen die in der Statistik aufscheinen. Fuer Ruby/Python/Lisp/Smalltalk usw. gibt es tonnenweise Dokumentation. Das betrifft Lehrbuecher zur Sprache genauso wie API Dokumentation. Wer sich technische Buecher kauft, tut das meistens nicht, weil er sich nicht umsonst informieren kann, sondern weil das Lesen von Printmedien, besonders bei laengeren Texten, fuer viele angenehmer ist. Deswegen verkaufen sich Klassiker wie Thinking in Java, Dive into Python oder das Ruby Pickaxe Buch ja auch so gut, obwohl sie auch online zur freien Verfuegung stehen. Natuerlich reflektiert der Buchmarkt nicht 1:1 die Popularitaet der behandelten Themen. Aber ein Indikator ist es auf jeden Fall.

Re: [JAVA] - Problem mit Tabellen

2006-08-02T09:47:00.000-07:00

This is a copy from a comment of mine, located here: http://www.informatik-forum.at/showthread.php?p=348730#post348730 Du must zunaechst einen Listener erzeugen, der die Methode 'tableChanged' ueberschreibt, und ihn an das TableModel anhaengen. die Indices fuer die Zeile und Spalte befinden sich dann im uebergebenen Event. Hier eine vollstaendige Demo:

import java.util.ArrayList;
import java.util.List;

import javax.swing.JFrame;
import javax.swing.JPanel;
import javax.swing.JTable;
import javax.swing.event.TableModelEvent;
import javax.swing.event.TableModelListener;
import javax.swing.table.AbstractTableModel;


public class JTableExample extends JPanel {

  private static final long serialVersionUID = 1L;

  private String[] columnNames = new String[] { "A", "B", "C" };

  private List<List<Object>> rowData = makeData(columnNames.length);

  
  public JTableExample() {
    JTable table = createTable();

    table.getModel().addTableModelListener(new TableModelListener() {

      public void tableChanged(TableModelEvent event) {
        System.out.println("DEBUG: "
            + rowData.get(event.getFirstRow()).get(event.getColumn()));
      }

    });

    this.add(table);

  }
  
  private List<List<Object>> makeData(int numCols) {
    List<List<Object>> rows = new ArrayList<List<Object>>();
    for (int i = 0; i < 25; i++) {
      List<Object> cols = new ArrayList<Object>();
      for (int j = 0; j < numCols; j++) {
        cols.add(j);
      }
      rows.add(cols);
    }
    return rows;
  }

  private JTable createTable() {
    return new JTable(new AbstractTableModel() {

      private static final long serialVersionUID = 1L;

      public String getColumnName(int col) {
        return columnNames[col].toString();
      }

      public int getRowCount() {
        return rowData.size();
      }

      public int getColumnCount() {
        return columnNames.length;
      }

      public Object getValueAt(int row, int col) {
        return rowData.get(row).get(col);
      }

      public boolean isCellEditable(int row, int col) {
        return true;
      }

      public void setValueAt(Object value, int row, int col) {
        rowData.get(row).set(col, value);
        fireTableCellUpdated(row, col);
      }
    });
  }

  public static void main(String[] args) {
    JFrame frame = new JFrame();
    frame.add(new JTableExample());
    frame.pack();
    frame.setVisible(true);
  }

}