Herzlich Willkommen, lieber Gast!
  Sie befinden sich hier:

  Forum » Allgemeines (OffTopic) » Programmierkonventionen

Forum | Hilfe | Team | Links | Impressum | > Suche < | Mitglieder | Registrieren | Einloggen
  Quicklinks: MSDN-Online || STL || clib Reference Grundlagen || Literatur || E-Books || Zubehör || > F.A.Q. < || Downloads   

Autor Thread - Seiten: [ 1 ] > 2 <
010
03.11.2008, 14:53 Uhr
stephanw
localhorst


Zu den Aussagen von beefy:

Genau das gefällt mir an Python auch nicht - die Vermischung von Syntax und Semantik.

Und die dynamische Typisierung (bzw. Duck-Typing) führt bei größeren Projekten tatsächlich zu Problemen, wenn nach der Hälfte des Programmes ein "MethodNotFoundError" o.ä. auftritt. "Das hätte mir auch der Compiler sagen können." ;-)

Den einzigen Ausweg in diesem Falle sehe ich in einer großen UnitTest-Abdeckung. Und genau hier kann Duck-Typing wieder von großem Vorteil sein, weil der Begriff "Schnittstelle" sich nicht an ein Java-Interface klammert oder reine rein abstrakte C++-Klasse, sondern an einer Syntax. Daher ist es besonders einfach, in Ruby einen UnitTest zu schreiben:


Code:
class MockDataBase
  def connect(post, host)
    # Aufruf protokollieren
  end
  ...
end

def testConnectWasCalled
  mdb = MockDataBase.new
  ws = WebService.new(mdb)
  ws.run # ruft connect() auf am "DataBase"-Objekt
  assert(mdb.connectWasCalled)
  ...
end



Einen ähnlichen Nutzen kann man auch aus C++-Templates ziehen.

Für jeden Zweck gibt es die optimale Sprache
--
Reden ist Schweigen und Silber ist Gold.

Dieser Post wurde am 03.11.2008 um 14:56 Uhr von stephanw editiert.
 
Profil || Private Message || Suche Download || Zitatantwort || Editieren || Löschen || IP
011
03.11.2008, 17:51 Uhr
0xdeadbeef
Gott
(Operator)


Was C# angeht, einen großen Unterschied zwischen Java und C# habe ich bisher nicht wahrgenommen; was da aus mir spricht, ist vielleicht (naja, ziemlich sicher) meine Befangenheit gegenüber Microsoft.

Was Duck-Typing angeht, die Probleme damit sind mannigfaltig, größere Projekte sind damit nahezu unmöglich umzusetzen - das habe ich ja schon erwähnt. Zusätzlich dazu (das muss ich, finde ich, noch erwähnen) ist es pädagogisch gesehen ungefähr das Bösartigste, was man einem Programmieranfänger antun kann. Es lehrt schlimmere Angewohnheiten als C und Intercal zusammen - es untergräbt das komplette objektorientierte Paradigma. Und das ist jetzt nicht übertrieben.

In der Objektorientierung geht es ganz grundsätzlich um die Kapselung von Funktionseinheiten, um hohe Kohäsion bei möglichst loser Kopplung. In der Praxis bedeutet das, wenn ich eine Klasse Schwein habe, die eine Methode fressen hat, die ein Futter-Objekt erwartet, dann hat fressen sich nicht dafür zu interessieren, ob hinter dem Futter-Objekt jetzt Kraft- oder Trockenfutter steckt. Mit anderen Worten, in dem Moment, in dem du eine Duck-Typing-Schnittstelle verwendest (wie z.B. hasattr) befindest du dich schon tief im Land dreckig(st)er Hacks.
--
Einfachheit ist Voraussetzung für Zuverlässigkeit.
-- Edsger Wybe Dijkstra
 
Profil || Private Message || Suche Download || Zitatantwort || Editieren || Löschen || IP
012
04.11.2008, 02:17 Uhr
Pler
Einer von Vielen
(Operator)



Zitat von 0xdeadbeef:

in dem Moment, in dem du eine Duck-Typing-Schnittstelle verwendest (wie z.B. hasattr) befindest du dich schon tief im Land dreckig(st)er Hacks.

Ja und wozu braucht man das in der Praxis? Vielleicht um vorherige Designfehler auszubügeln? :-)
Dann wäre das aber doch gerade ein riesiger Pluspunkt für Python. Da man ja immer Designfehler macht. Und so läßt sich letztendlich immer doch noch alles hinmorksen und mehr oder weniger zum Laufen bekommen was vorher verbockt wurde.
 
Profil || Private Message || Suche Download || Zitatantwort || Editieren || Löschen || IP
013
04.11.2008, 09:06 Uhr
stephanw
localhorst


Was hat "hasattr" mit Ducktyping zu tun ? Das sieht für mich eher wie Reflection aus und das sollte in jeder Sprache nur an sehr ausgewählten Stellen (wenn überhaupt) vom Pogrammierer verwendet werden. Ein Interpreter muss das natürlich verwenden, um Ducktyping zu realisieren.

Um Missverständnissen vorzubeugen - ich bin durchaus ein Verfechter statischer Typsysteme und auch der C++-Programmierstprache.

Das mit der Kohäsion sehe ich anders. Eine fachliche (bzw. semantische) Kohäsion kann auch ein Compiler nicht erzwingen. Ob also eine Klasse "Schwein" tatsächlich nur die Methoden "fressen()", "schlafen()" hat und nicht noch "bestimmePreis()" und "repariereAnhänger(Anhänger*)", das kann sowohl mit Ducktyping als auch mit C++ nur der Programmierer festlegen. Und das erfordert von ihm ein Wissen über den Kontext und gewisse Kenntnisse über Designprinzipien.

Man kann sowohl mit Ducktyping als auch mit statischem Typsystem ein gutes und ein schlechtes System entwerfen. Wahrscheinlich überwiegt für größere Projekte der Vorteil der statischen Typprüfung durch einen strengen Compiler.
--
Reden ist Schweigen und Silber ist Gold.
 
Profil || Private Message || Suche Download || Zitatantwort || Editieren || Löschen || IP
014
04.11.2008, 10:28 Uhr
Guybrush Threepwood
Gefürchteter Pirat
(Operator)



Zitat von 0xdeadbeef:
Was C# angeht, einen großen Unterschied zwischen Java und C# habe ich bisher nicht wahrgenommen; was da aus mir spricht, ist vielleicht (naja, ziemlich sicher) meine Befangenheit gegenüber Microsoft.

Also bei mir ist es so das ich vor ich glaube etwas über 2 Jahren mit C# und ASP.Net angefangen habe beruflich zu entwickeln, was mir obwohl es sich um Webapplikationen handelt Spaß gemacht hat und die Technologie hat mir sehr gut gefallen.

Vor etwas über einem halben Jahr musste ich dann auf Java umsteigen. Nach einer Reihe Schulungen und so was haben wir dann halt Webanwendungen mit Java entwickelt bzw versucht.
Also ich muss sagen auch wenn sich die Sprachen an sich doch sehr ähnlich sind ist alles drum herum was so dazu gehört wie die Entwicklungsumgebung und verschiedene Tools und Technologieen (Maven, Seam, Svn, Eclipse, Richfaces usw) leider bei weitem nicht so ausgereift wie auf der .Net Seite und bei vielen Dingen hat man das Gefühl das die einzelnen Dinge untereinander nicht besonders gut abgestimmt sind was wohl daran liegt das es von verschiedenen Firmen/Gruppen entwickelt wurde. Also alles in allem war das ein ziemlicher Krampf und ich bin froh das ich zumindest im Moment wieder an ein paar "alten" .Net Projekten arbeiten darf.

Wie das aber jetzt außerhalb der Web Welt auf der Java Seite kann ich nicht beurteilen.



Das mal als mein Beitrag zum "Flamewar"
 
Profil || Private Message || Suche Download || Zitatantwort || Editieren || Löschen || IP
015
04.11.2008, 13:40 Uhr
0xdeadbeef
Gott
(Operator)


Duck-Typing verlangt Reflection, das macht es in einer Sprache mit Duck-Typing zu einer Duck-Typing-Schnittstelle. Ob du jetzt explizit hasattr verwendest oder das Programm NoSuchMethodErrors in der Gegend rumwerfen lässt, ist für die Dreckigkeit der Hackerei ziemlich unerheblich.

Was das Erzwingen von Kohäsion angeht, natürlich kann ein Compiler dem Programmierer nicht dazu zwingen (nichtsdestoweniger ist es gute Praxis, die man lehren sollte), allerdings ging es mir hier auch mehr um die lose Kopplung.
--
Einfachheit ist Voraussetzung für Zuverlässigkeit.
-- Edsger Wybe Dijkstra
 
Profil || Private Message || Suche Download || Zitatantwort || Editieren || Löschen || IP
Seiten: [ 1 ] > 2 <     [ Allgemeines (OffTopic) ]  


ThWBoard 2.73 FloSoft-Edition
© by Paul Baecher & Felix Gonschorek (www.thwboard.de)

Anpassungen des Forums
© by Flo-Soft (www.flo-soft.de)

Sie sind Besucher: