Programmiersprachen im Kommen und Gehen [Archiv]

Shink

2012-02-06, 17:32:16

Meine 0,02€:
- C++ wird vorerst bleiben; womöglich immer mehr C ersetzen bei Betriebssystemen, Embedded-Zeug etc. Für Client-Applikationen ist es am absteigenden Ast.
- Java, C# und Objective C mutieren immer mehr zu Multiparadigmensprachen und werden früher teilweise eher belächelte und als akademisch abgestempelte Konzepte wie logische und funktionale Programmierung reinfrickeln. Irgendwann werden wohl die wenigsten Java-Entwickler alle Features kennen. Wer da vorgreifen will kann sich mal Scala oder die Backward-Chaining-Features von Drools ansehen.
- JS - ich bin nicht gerade glücklich darüber aber ich denke über den Umweg Web bekommen wir immer mehr JS auf den Client: Es läuft auf ALLEN mobilen Plattformen, auf allen Desktop-Plattformen, hat kaum nennenswerte Konkurrenz und nicht einmal Apple oder Microsoft trauen sich da irgendwelche Einschränkungen zu erfinden. node.js - also serverseitiges JS - kann ich nicht beurteilen. Wer weiß, wer weiß... ich hätte mir nie gedacht dass das schrottige JS mal zur Lingua Franca wird in die sogar manche Java-Compiler übersetzen (GWT).
- PHP, Python, Ruby - keine Ahnung. Ich glaub fast nicht dass die in 20 Jahren mehr Verbreitung haben als heute (wobei ich auch nicht weiß warum).
- VB, Delphi, ABAP, Actionscript - wichtig für Bestandsapplikationen aber zunehmend uninteressant und unsexy.

pest

2012-02-06, 18:02:39

Man sollte ja wissen wo man sich selber am besten einarbeitet

ist Grundlegend nicht wirklich wichtig wenn du "programmieren lernen" willst.
Funktionale Programmierung ist bis auf Syntax und Typkonventionen meist recht ähnlich. Objektorientierung genauso, wobei es da eben reichlich Unterschiede bzgl. der von der Spache gesetzten Grenzen gibt.

Wichtig ist das Konzept zu verstehen (und wofür es gut ist) und nicht die Programmiersprache in der das Konzept formuliert ist. Ob du nun Polymorphie in Pascal oder C++ verfasst ist nebensächlich.

Ich habe z.B. mit x86-Assembler angefangen, dann mit Pascal weitergemacht irgendwann C/C++ angefangen. An dem Punkt konnte ich mir Perl und Python grob in 2 Wochen beibringen.

AwesomeSauce

2012-02-06, 18:22:30

ist Grundlegend nicht wirklich wichtig wenn du "programmieren lernen" willst.
Funktionale Programmierung ist bis auf Syntax und Typkonventionen meist recht ähnlich. Objektorientierung genauso, wobei es da eben reichlich Unterschiede bzgl. der von der Spache gesetzten Grenzen gibt.

Wichtig ist das Konzept zu verstehen (und wofür es gut ist) und nicht die Programmiersprache in der das Konzept formuliert ist. Ob du nun Polymorphie in Pascal oder C++ verfasst ist nebensächlich.

Ich habe, z.B. mit x86-Assembler angefangen, dann mit Pascal weitergemacht irgendwann C/C++ angefangen. An dem Punkt konnte ich mir Perl und Python grob in 2 Wochen beibringen.
Ich finde aus didaktischen Gründen ist dieser Weg eine schlechte Wahl. Ich habe selbst mit C/C++ angefangen und die Lernkurve ist doch sehr steil, gerade wenn man sich mit Pointern herumschlagen muss. Bis man das Konzept wirklich begriffen hat, vergeht schon einige Zeit (die ist es aber wert).

Retrospektiv würde ich wohl mit Java oder C# die ersten Schritte machen. Die Konzepte lernt man dort sehr gut, ohne die ganzen Komplikationen mit Compiler/Linker. Gerade debuggen ist sehr mühsam im Vergleich zu den Sprachen mit einer VM.

Ganon

2012-02-06, 18:22:40

Java war mal die VM/Sprache "für alles". Aber seitdem Apple mit dem iPhone/iPad sehr erfolgreich ist und die Spielekonsolen zu Multimediastationen werden und dort kein Java erlauben und Oracle mit Java-Lizenzen rumferkelt ist, ist das auch schon wieder eher falsch...

Also das "Eine Sprache für alles-Konzept" ist somit schon mal wieder völlig am abdriften.

Somit bist du mit C/C++ immer noch "am portabelsten", hast jedoch sämtlichen Portierungsaufwand bei dir. Musst halt für jedes Device den entsprechenden Code schreiben.

C/C++ wird noch sehr sehr sehr sehr sehr sehr sehr sehr sehr sehr sehr sehr sehr lange leben. Ich kenne bisher keine Bibliothek "für den allgemeinen Gebrauch" (aka, nix sprachspezifisches), die nicht in C oder C++ geschrieben wäre. Alles andere sind Wrapper auf die C/C++ Bibliotheken.

Python wird imo aus dem "Sprache für kleinere Tools"-Tal nicht so schnell rauskommen. Die Referenzimplementierung die überall mit installiert wird ist imo einfach hoffnungslos langsam, da sie interpretiert wird und das auch nicht sonderlich schnell. Weiterhin ist es mit dieser Implementierung unmöglich mehrere CPUs zu nutzen. Es gibt schnellere Implementierungen, aber die hängen immer der Referenz hinterher.

Aber prinzipiell kann man sagen: Willst du eine Plattform verlassen mit "einem Code", wird es eklig und/oder teuer. Das fängt beim Build-Tool an, geht über den Compiler und hört irgendwo bei Bugs in den verwendeten Bibliotheken auf. Überall gibt's da Konflikte oder Inkompatibilitäten.

tomvos

2012-02-06, 18:43:06

Letzten Endes ist es egal, mit welcher Sprache du anfängst. Es geht darum, für dich selbst herauszufinden, ob das Programmieren dir Spaß macht. Also Aufgaben zu erkennen, zu strukturieren und zu lösen. Die Wahl der Programmiersprache selbst ist beinahe Nebensache.

Nach meine Erfahrung ist es sehr lehrreich, sich mit mindestens je einer Programmiersprache der drei großen Paradigmen auseinanderzusetzen:

http://de.wikipedia.org/wiki/Programmiersprache#Programmierparadigmen

So bin ich z.B. von C über Objective-C letzten Endes bei Erlang gelandet. Ich finde das Denkmodel von funktionalen Sprachen inzwischen erfrischend einfach im Vergleich zu den Objekt orientierten Sprachen.

Meine Prognose ist jedoch, dass letzten Endes Scala als Hybrid aus Objekt orientiert und funktional eine (die?) wichtige Sprache werden wird. Ob nun aber eine Hybridsprache für den Einstieg leichter ist, als eine Sprachen die sich recht streng an ein Paradigma hält, wage ich zu bezweifeln.

Tiamat

2012-02-06, 18:57:18

google go soll angeblich ganz cool sein.

PatkIllA

2012-02-06, 19:19:11

Python wird imo aus dem "Sprache für kleinere Tools"-Tal nicht so schnell rauskommen.Ich finde ja generell dynamisch getypte Sprachen für größere Dinge ungeeignet.

Ansonsten würde ich auch sagen, dass die Sprache eigentlich nur sekundär ist und man erstmal vor allem versuchen sollte Konzepte zu verstehen.
Wenn man das was man am Anfang gemacht hat ein Jahr später nochmal anguckt gruselt es einem sowieso. Programmieren ist auch viel Erfahrung.

Monger

2012-02-06, 20:04:04

Ich glaube, es gibt gewisse Trends die sich durch alle Programmiersprachen durchziehen.
Eine Zeitlang war z.B. Vererbung DAS zentrale Merkmal einer modernen Sprache - mittlerweile ist man da wieder ein Stück weit weg. Ich weiß noch, dass die frühen Java Frameworks irrwitzig lange Vererbungshierarchien hatten, die man dann später so allmählich wieder aufgebrochen hat.

Ich hab das am Anfang nicht so richtig ernst genommen, aber die funktionalen Sprachen haben Stärken die einfach nicht zu leugnen sind. "Asynchron" scheint momentan das Buzzword des Jahres zu sein.

Wenn ich mal so orakeln darf:
- Ich glaube, dass das Konzept von Sandboxes/Runtimes grundsätzlich mal zukunftsweisend ist. Java und .NET sind keine Eintagsfliegen, sondern werden eine stärkere Rolle bei Server- und Desktopapplikationen spielen als heute.
- C++ entwickelt sich ja stetig weiter, und die Grenze insbesondere zu .NET wird immer dünner. Solange es die Win32 API noch gibt, wird es definitiv auch noch C++ Entwickler für Windows geben. Zu den anderen Betriebssystemen kann ich ehrlich gesagt nicht viel sagen, aber Unix ohne C++ ist wohl auch kaum denkbar.
- Javascript ist wohl auch etwas, was unverzichtbar geworden ist. Gemessen daran welche Bedeutung mittlerweile Webapplikationen erreicht haben, sehe ich da auch kein Ende.

Zu vielen anderen Sprachen kann ich mir gar kein Urteil erlauben. Die ganze Pascal/Delphi Schiene stirbt einen unheimlich siechenden Tod. So manche Exoten wie z.B. Fortran werden wahrscheinlich noch ewig ihre Nischenanwendungen haben. So lange es Microcontroller gibt die nicht mehr als ein paar Eingänge verschalten müssen, wird es auch immer ein Anwendungsgebiet für C geben.

Wer sich gerne kleine Tools mit ein paar Buttons und Textfeldern unter Windows zusammenschrauben will, dem kann ich die .NET Welt herzlich empfehlen. Macht wirklich Spaß, was man da mit relativ geringem Aufwand mittlerweile zusammenschustern kann.

hell_bird

2012-02-06, 20:25:31

Lern C++... und wenn du dann den Speicher selber aufräumen kannst, selber aufpasst, dass du die arraybounds nicht sprengst, dich mit ein paar inkompatiblen Compilern herumgeärgert hast und durch den ganzen Faschismus von Templates und überladenen Operatoren durchblickst... dann ist der Rest, wie java, .net und Konsorten nur noch Kindergarten.

Trap

2012-02-06, 21:00:04

es gibt ja viele Sprachen, aber sie kommen und gehen z.B. C++ ist schon lange auf dem Markt, aber wird das bleiben?
Die existierenden Programme in den großen Sprachen C/C++/Java/C# sind so viel wert, dass allein die Pflege der existierenden Programme garantiert, dass es auch in 20 Jahren die Sprachen noch gibt. So wie bei Cobol auch.
gibt es eine neue Sprache die viele Systeme verstehen, zb, auch Andriod? aber auch Linux, Windoof:D oder ähnliches ?
Nicht ganz neu, aber ziemlich genau passend: Javascript

PHuV

2012-02-06, 21:12:37

Alle Sprachen kommen und gehen, doch C bleibt. ;)

C++ ist doch heute gar nicht mehr so in, dachte ich, eher Java und C#. Im praktischen Leben habe ich bisher kaum C++-Projekte, außer in Linux, angetroffen. Ich tät bei C und bei Java bleiben, das hat eine gute Grundlage, und man kann damit in den meisten Dingen im täglichen Leben arbeiten, und es ist portabel. Und wer viel mit Windows arbeitet, sollte sich mit C# beschäftigen. C++ halte ich bis heute für überbewertet, zu überladen und nach wie vor zu komplex, und wenn man auf der Plattform keinen gcc hat, ist man fast aufgeschmissen, da es leider lange nicht so portabel ist wie C.

Gast

2012-02-06, 21:14:28

Die große Frage ist, wohin sich die EDV Welt hin entwickeln wird. Entweder ist die App Entwicklung mit Smartphones, Tablets etc. und der aktuelle Web & Cloud Wahn nur eine Mode, die sich wieder geben wird, oder das wird der Schwerpunkt werden.
Falls ersteres der Fall ist, so werden wir in Zukunft mit rückständigen Sprachen wie JavaScript (nicht zu verwechseln mit Java), php, html etc. zu tun haben bzw. diverse Java Varianten für mobile Geräte.
Wenn sich das Ganze wieder gibt und die Welt eher auf einer Windows und PC Welt bleibt, so werden wir sehr stark mit C# und VB.NET zu tun haben.
C/C++ ist jetzt schon tot abgesehen von Bestandsprojekten und ein paar Nischenmärken wie Betriebssysteme, Spiele, Treiber etc.
Derzeit ist einer großer Teil der Entwickler mit Individualsoftware für den PC beschäftigt (klassiche C#/VB.NET Programmierung mit den üblichen Steuerelementen), Webentwicklung (derzeit gerade im Boom), eine Menge Admin arbeiten mit Access, Batch Skripts etc., die ich eigentlich nicht als Softwareentwicklung einstufen würde.

PHuV

2012-02-06, 21:18:54

C/C++ ist jetzt schon tot abgesehen von Bestandsprojekten und ein paar Nischenmärken wie Betriebssysteme, Spiele, Treiber etc.

Bitte? :| Da hatte einer aber wirklich Ahnung. :rolleyes: Schau mal, worin die meisten (großen) Anwendungen/Datenbanken bis heute geschrieben sind. C und nichts als C. Und wenn die Programme etwas moderner sind, in C++.

Exxtreme

2012-02-06, 23:14:16

Also meiner Meinung nach: C/C++ und Java.

Beide Sprachen/Technologien verhalten sich quasi gegensätzlich. Da wo die eine schwächelt, hat die andere meistens ihre Stärke und vice versa. Kann man beide Sprachen dann deckt man fast alles ab was man so braucht, irgendwelche Spezialwünsche mal ausgenommen aber sowas hat man immer.

Was beide Sprachen so erfolgreich macht ist ihre weitgehende Unabhängigkeit von irgendwelchen Herstellern und ihre riesigen Biotope an Tools, Frameworks, IDEs, Dokumentationen etcpp. Zudem sind keine echten Einstiegshürden vorhanden da man mit beiden Sprachen/Technologien sofort loslegen kann ohne erstmal fett Kohle für irgendwelche Tools, IDEs, Server etc. auf den Tisch legen zu müssen. Man braucht nur einen Rechner und am besten eine Internetflatrate. Also wenn man Programmieren lernen will dann würde ich eine oder gar beide dieser Sprachen nehmen.

Und ja, ich weiss, Oracle könnte Java abwürgen wenn sie wollten da sie die Namensrechte und wichtige Patente halten. Im Gegensatz zu sehr vielen anderen Leuten glaube ich aber nicht, dass Oracle das tut. Wer mit Oracle-Middleware gearbeitet hat, der weiss wie sehr sie selbst von Java abhängig sind. Ein abgewürgtes Java wäre sehr schädlich für Oracle. Deshalb befürchte ich in der Richtung nichts trotz irgendwelcher Klagen gegen Google. Wobei die Doppelmoral hier schon witzig ist. Sun hat auch mal wegen Java geklagt und zwar gegen Microsoft und zwar wegen sehr ähnlichen Gründen. Da war Sun aber nicht der Buhmann da MS damals als das Böse schlechthin galt.

Was andere Technologien/Sprachen angeht da bin ich wesentlich unschlüssiger ob die eine erfolgreiche Zukunft haben werden.

C#/VB/.NET & Co. hat den Nachteil, dass es zwei nicht unbedingt kompatible Implementierungen gibt. Und zweitens, mit Windows 8 macht Microsoft zumindest zum Teil eine Kehrtwende weg von .NET indem sie ihr altes COM wieder auspacken. Und ohne Scheiss, mir ist kein .NET-Programm bekannt welches nicht irgendwie komisch/wackelig läuft. X-D

Unschlüssig bin ich mir auch bei Scala. Das Ding scheint so derbe komplex zu sein, dass sich wohl kaum einer damit beschäftigt da die Lernkurven sehr steil sind. Mit einer großen Komplexität hat man den Nachteil, dass man kaum Leute findet, die damit umgehen können und damit gibt es kaum Projekte in dieser Richtung. Sowas ist oft ein K.O.-Kriterium für eine Sprache. Zudem sind komplexe Sprachen meistens nicht gut zum Lernen geeignet.

Was den Rest an Programmiersprachen angeht, ich glaube nicht, dass da noch was eine grössere Rolle spielen wird. Sicherlich wird es hier und da Nischen ala alte Cobol-Programme pflegen zum Füllen geben. Andererseits soll LISP ganz witzig sein.

Aquaschaf

2012-02-06, 23:45:10

Man sollte ja wissen wo man sich selber am besten einarbeitet

Jede der derzeit populären Sprachen wird mit hoher Wahrscheinlichkeit nicht von Heute auf Morgen verschwinden. Dazu ist die darin geschriebene Code-Basis, wie gesagt, bereits zu gewaltig. Um gut zu programmieren ist es auf der anderen Seite aber nicht so wichtig alle Details einer Sprache zu kennen - Aspekte die nichts direkt mit der verwendeten Programmiersprache zu tun haben spielen bei der Entwicklung von Software eine viel größere Rolle.

Such dir die Sprache aus die dir am besten gefällt, bzw. in der du glaubst dein Programm am einfachsten implementieren zu können.

Mein persönlicher Favorit für fast alles ist mittlerweile Python.

GloomY

2012-02-06, 23:59:42

Wie schon erwähnt wurde sind Konzepte, Algorithmen und Datenstrukturen natürlich essentiell für das Programmieren. Die verwendete Sprache ist eher nebensächlich und ich denke, diese Dinge sollte man auch unabhängig von einer Programmiersprache erlernen. Wenn man z.B. weiß, wie ein AVL-Baum aufgebaut ist, was für Eigenschaften bei diesem gelten und wie diese Eigenschaften beim z.B. Einfügen eines neuen Knotens wieder hergestellt werden, dann ist das viel mehr wert als irgend ein Sprachfeature genau zu kennen.

Jetzt zur konkreten Fragestellung: Als jemand, der hauptberuflich in C (reines C, kein C++ oder C#) programmiert, habe ich natürlich eine eigene Sichtweise auf diese Fragestellung. :naughty:

C läuft auf so ziemlich allem. Wer das nicht glaubt, soll mir mal bitte eine HW nennen, für die es keinen C-Compiler gibt. Das liegt natürlich auch daran, dass der Sprachumfang überschaubar und die Übersetzung relativ einfach ist.
"C ist ein portabler Assembler" sagt z.B. Greg Kroah-Hartman (http://en.wikipedia.org/wiki/Greg_Kroah-Hartman) in diesem Video (http://www.youtube.com/watch?v=LLBrBBImJt4&t=2m21s), aber dennoch "very very powerful".

Ich denke allein deswegen lohnt es sich meiner Meinung nach einen Blick auf diese Sprache zu werfen. Sicherlich hat es auch seine Beschränkungen und Nachteile - so wie jede Programmiersprache.
Alle Sprachen kommen und gehen, doch C bleibt. ;)Jein. Das C, das Kerninghan&Ritchy in den 70ern geschrieben haben, ist doch etwas anders als der 2011er C-Standard. Klar, jede Sprache entwickelt sich weiter, deswegen auch meine verhaltene Zustimmung.

FlashBFE

2012-02-07, 00:00:33

C#/VB/.NET & Co. hat den Nachteil, dass es zwei nicht unbedingt kompatible Implementierungen gibt. Und zweitens, mit Windows 8 macht Microsoft zumindest zum Teil eine Kehrtwende weg von .NET indem sie ihr altes COM wieder auspacken. Und ohne Scheiss, mir ist kein .NET-Programm bekannt welches nicht irgendwie komisch/wackelig läuft. X-D

Windows 8 und COM? Wo hast du denn das gelesen? COM war zwar nie richtig weg, aber dass es zu neuer Blüte geführt werden soll, bezweifle ich.
Zweitens wurde Win8 nur als Kehrtwende weg von Silverlight eingestuft, aber nicht von .NET insgesamt.

Ich selbst habe angefangen, Delphi zu lernen, dann VBA in Excel (was für wissenschaftliche Programme spitze ist), dann zwangsweise C++ (was ich gehasst habe), Assembler und C, und dann habe ich mir VB.NET beigebracht und bin dabei geblieben.

Also ich würde sagen: Tu dir als Anfänger nicht auf Anhieb C++ an, wenn du nicht masochistisch veranlagt bist. Die .NET Sprachen sind ein guter Anfang, als Einstieg in die .NET Welt gibts auch Small Basic (http://msdn.microsoft.com/en-us/beginner/ff384126.aspx), wobei man auch mit Microsofts neuestem Schrei F# direkt in funktionale Programmierung einsteigen kann. Mit JavaScript macht man auch nichts falsch. Die Sprache gewinnt eher noch mehr Bedeutung, als sie sowieso schon hat.

Lyka

2012-02-07, 00:19:42

die letzte Programmiersprache, die ich gut fand, war C, die hab ich wirklich geliebt :D (vorher Basic, Pascal, Java...) Java kann ich nicht wirklich leiden, vermutilch liegt das aber eher an meinem damaligen PC, der "fast zu langsam war für JBuilder"^^

DraconiX

2012-02-07, 06:35:21

Also ich bin ganz klar für C, C++ und meinetwegen sogar C#...

Ich habe... puhh... vor viiiielen Jahren (so um 1991 rum?!) mit Pascal und Turbo Basic angefangen und bin dann ziemlich schnell zum C und ASM gekommen und im Grunde auch da geblieben. Aber man hat halt dann auch die Evolution mitgemacht... hin zum OO.

Aber eigentlich nutze ich selbst heute noch sehr viel C und ASM, gerade im Microcontroller Bereich ist das noch immer das non-plus-ultra.

Ähm... und nein... es gibt imo kein Java-Compiler für 8-biter ;) Aber dennoch sehr überraschend wie sich das doch damals belächelte Java, was ja im Grunde noch recht "jung" ist, verbreitet hat. :freak:

ScottManDeath

2012-02-07, 07:39:44

WinRT von Windows 8 ist ein gepimptes COM mit Sprachsupport.

lemming71

2012-02-07, 08:46:06

DraconiX

2012-02-07, 09:03:11

Für mich war damals der umstieg von C auf C++ ne große Hürde, nicht vom programmieren an sich - sondern vielmehr von den Gedankengängen die da ein wenig anderst laufen können und müssen :freak:

Aber wie schon gesagt, unterscheiden tun sich eigentlich alle (mal abgesehen von struktur- und Objektorientierten) Programmiersprachen eigentlich nur im Syntax - finde ich jedenfalls so.

Also ich hab letzten mit Boo programmieren müssen und nach ner halben Stunde Syntax anschauen gings flutschig von der Hand.

Trap

2012-02-07, 09:07:00

Aber wie schon gesagt, unterscheiden tun sich eigentlich alle (mal abgesehen von struktur- und Objektorientierten) Programmiersprachen eigentlich nur im Syntax - finde ich jedenfalls so.
Probier mal Haskell :biggrin:

Shink

2012-02-07, 09:23:20

Probier mal Haskell :biggrin:
Oder Prolog.

Und wie schon gesagt werden diese Konzepte auch Einzug in C# und Java finden.

Ganon

2012-02-07, 09:54:21

Probier mal Haskell :biggrin:

Haskell ist ja quasi auch das Lambda-Kalkül in Reinform :D

Aber ich denke in Zukunft wird der funktionale Ansatz immer mehr Beliebtheit finden.

Es muss zwar hier und da immens umgedacht werden, aber eine strikte Variablenlosigkeit macht das Verteilen auf mehrere CPUs schon leichter.

Aber momentan hat ja alles noch Ecken und Kanten...

Zergra

2012-02-07, 18:36:03

okey :D danke für eure Einschätzungen, bleiben wohl C++ und Java übrig,
da gehts mal ans eingemachte :D

Gast

2012-02-08, 01:25:42

Bitte? :| Da hatte einer aber wirklich Ahnung. :rolleyes: Schau mal, worin die meisten (großen) Anwendungen/Datenbanken bis heute geschrieben sind. C und nichts als C. Und wenn die Programme etwas moderner sind, in C++.

Du meinst wahrscheinlich die meisten DatenbankSYSTEME. Ja da magst du recht haben, aber wenn du vergleichst, wieviele Leute an der Entwicklung von Datenbanksystemen beteiligt sind und wieviele für die Entwicklung von Software zum Zugriff auf Datenbanken, dann erübrigt sich das schon wieder.
Wenn du Anwendungen meinst, dann musst du hier unterscheiden. Viele klassischen Programme zum Zugriff auf Datenbanksysteme sind ERP Systeme mit tiefen Wurzeln und somit als bestehendes Projekt zu werten. Für die klassische Individualsoftware im Business Bereich für einen Kunden oder überhaupt für den Eigenbedarf kommt hier .NET sehr oft zum Einsatz in Kombination mit SQL Server, wobei hier Access mit VBA zumindest als Frontend immer noch einen sehr großen Anteil hat.

C#/VB/.NET & Co. hat den Nachteil, dass es zwei nicht unbedingt kompatible Implementierungen gibt.

Du kannst bis auf wenige Ausnahmen C# und VB.NET ohne Probleme mischen d.h. eine .dll in C# und eine .dll in VB.NET, wobei du selbst aus dem VB.NET Projekt noch die C# .dll debuggen kannst und umgekehrt.

Und zweitens, mit Windows 8 macht Microsoft zumindest zum Teil eine Kehrtwende weg von .NET indem sie ihr altes COM wieder auspacken. Und ohne Scheiss, mir ist kein .NET-Programm bekannt welches nicht irgendwie komisch/wackelig läuft. X-D

Ich glaube das muss man differenzierter sehen. Microsoft macht im Desktop/Business Bereich keine Kehrtwende. Microsoft bewirbt nur in jeder Edition von Windows/Visual Studio lediglich die Features, die ihnen strategisch besonders wichtig sind. Das sind momentan die Metro Apps und die ganze Webentwicklung, da sie ihre Vormachtstellung auch auf den neuen Markt der Tablets ausdehnen wollen, weil sie sonst die Angst haben, dass ihnen über dieses Tor Apple und Google schön langsam einfallen (zuerst ein Handy, dann ein Smartphone, dann ein Tablet, dann ein Netbook, dann ein Notebook und schon sind wir im Desktop Kerngeschäft.

Zweitens wurde Win8 nur als Kehrtwende weg von Silverlight eingestuft, aber nicht von .NET insgesamt.

Das mag sein. Von Silverlight habe ich bisher außer von Microsofts eigenen Implementierungen noch nie viel gesehen.

Meiner Meinung nach ist C eine gute Sprache zum Erlernen der Grundlagen, wenn man eine 5-jährige Ausbildung macht. Wenn man schnell auch etwas produktives sehen will, dann würde ich einmal mit C# anfangen. Da hat man eine umfassene Bibliothek und man kommt ohne viel Aufwand schnell einmal zu etwas, sitzt aber gleichzeitig auf einer Technologie, wo man mit etwas mehr Erfahrung auch professionelle Anwendungen schreiben kann, was mit VBA eher nicht der Fall ist.
C/C++ hat zwei große Probleme, die die Entwicklungszeit stark verlangsamen:
a) Wenn man per Pointer bzw. per Feldüberschreitung auf eine falsche Adresse zugreift, gibt es nur eine Segmentation Violation, aber keinen Weg das ganze per Fehlermeldung so auszugeben bzw. zu loggen, dass es für den Entwickler darauf hinweist, was schief gegangen ist d.h. der Code muss 100% sauber sein
b) Wenn man Speicher anfordert und danach nicht wieder frei gibt, bläht sich die Anwendung immer mehr und mehr auf und muss von Zeit zu Zeit neu gestartet werden. Mit C lässt sich das noch einigermaßen handlen, aber wenn man C++ dann kompliziertere Konstrukte mit Nutzung sämtlicher Features der objektorientierten Programmierung dazu kommen, dann kann es schnell einmal passieren, dass man sich ein Speicherleck aufreißt.

ScottManDeath

2012-02-08, 05:37:13

Eher das Gegenteil, in C++ mittels RAII ist es nahezu trivial Resourcenlecks (neben Speicher auch Filehandles, Datenbankenverbindungen usw.) zu vermeiden, insbesondere wenn man std::shared_ptr bzw boost::shared_ptr nutzt. Ich habe seit Jahren kein delete mehr geschrieben, trotzdem leake ich nichts ;)

DraconiX

2012-02-08, 06:16:31

*snip*

Du kannst bis auf wenige Ausnahmen C# und VB.NET ohne Probleme mischen d.h. eine .dll in C# und eine .dll in VB.NET, wobei du selbst aus dem VB.NET Projekt noch die C# .dll debuggen kannst und umgekehrt.

*snip*

Oh oh... stimmt das? Ich weiß noch, das ich in C# keine VB.NET DLL importieren konnte. Oder hat sich das mittlerweile geändert?!

btw... willste in Reinkultur programmieren.. bleibt sowieso nur ASM übrig :freak:

Exxtreme

2012-02-08, 08:46:36

Du kannst bis auf wenige Ausnahmen C# und VB.NET ohne Probleme mischen d.h. eine .dll in C# und eine .dll in VB.NET, wobei du selbst aus dem VB.NET Projekt noch die C# .dll debuggen kannst und umgekehrt.

Das meine ich nicht. Es gibt .NET von MS und es gibt Mono. Das sind zwei verschiedene Implementierungen, die nicht zu einander kompatibel sind da sie ein eigenes Süppchen kochen. Es gibt zwar Überschneidungen und man kann sicherlich Programm schreiben, die auf beiden VMs ohne Änderungen laufen. Nur sind die Schnittpunkte nicht sehr groß und man muss aufpassen. ;)

Matrix316

2012-02-08, 11:02:14

Zum lernen wie man programmiert, fand ich C am besten. Die ganzen "Basics" kann man IMO in der Pfeife rauchen. ;) Und wenn man weiß wie ein struct funktioniert, ist man schon fast in der sbjektorientierten Welt.

Am einfachsten und schönsten finde ich C# zu programmieren. C++ ist mir einfach zu unkomfortabel und teil umständlich. C# ist zwar ähnlich wie JAVA finde ich, aber Visual Studio gefällt mir besser als jede Entwicklungsumgebung für Java.

Am schlimmsten zu programmieren finde ich Javascript und VB Script. Die Quellcodes sind einfach total unübersichtlich und bekloppt. Bei manchen Javascript Bauten denkt man sich nur noch: WTF?!
GEvent.addListener(map, "click", function(overlay, latlng) {

if (latlng) {
var TextBoxLAT = '<%= hfMLAT.ClientID %>';
var TextBoxLON = '<%= hfMLON.ClientID %>';
document.getElementById(TextBoxLAT).value = latlng.y;
document.getElementById(TextBoxLON).value = latlng.x;

}
});
und das sind noch einfache Sachen.

:ugly: Visual Basic gefällt mir auch nicht so, weil mir da irgendwie die Klammern fehlen.

Monger

2012-02-08, 11:20:49

Oh oh... stimmt das? Ich weiß noch, das ich in C# keine VB.NET DLL importieren konnte. Oder hat sich das mittlerweile geändert?!

Kann mir nicht vorstellen, dass das jemals ein Problem war. Der Clou an .NET ist ja gerade, dass C#, J#, VB.NET, ASP.NET, F# etc. alle in die selbe Zwischensprache kompilieren, und alle .NET Assemblies grundsätzlich mal sich gegenseitig referenzieren können.

Es gibt ein paar Ausnahmen. Microsoft nennt das gemeinsame Featureset aller Sprachen "CLS compliant", und es gibt einige Abweichungen davon. In C# sind z.B. öffentliche Signaturen erlaubt die sich nur in der Groß/Kleinschreibung unterscheiden, damit kann aber VB.NET nicht umgehen. oder VB.NET kennt parametrierte Properties, also sowas wie MyObject.MyProperty("Name"), das löst C# dann als MyObject.get_MyProperty("Name") als Methodenaufruf auf.

Die Abweichungen sind insgesamt aber sehr gering. Wir mischen hier auf Arbeit ständig VB.NET mit C# Assemblies, und haben damit überhaupt keine Probleme.

Gast

2012-02-08, 11:49:30

Oh oh... stimmt das? Ich weiß noch, das ich in C# keine VB.NET DLL importieren konnte. Oder hat sich das mittlerweile geändert?!

Ich kann nicht sagen, ob es in den ersten Versionen ein Problem war. Ich nutze VS 2008 mit .NET Framework 2.0 als Target und habe schon etliche Projekte gehabt, wo ich in ein bestehendes C# Projekt meine VB.NET .dll eingebunden habe. Beim Debuggen des C# Projektes öffnet sich auch gleich der VB.NET Code, wenn du einen Schritt hinein machst und kannst das Source File auch gleich bearbeiten. Nur zum Kompilieren musst du das andere Projekt öffnen (ist bei zwei VB.NET Projekten genauso).
Die einzige Einschränkung, die für mich bisher relevant war waren die optionalen Parameter in VB.NET. Wenn man so eine Funktion aus C# nutzt, muss man die Defaultwerte wissen und mit angeben, was etwas umständlich ist, aber sonst gibt es kein Problem.

Das meine ich nicht. Es gibt .NET von MS und es gibt Mono. Das sind zwei verschiedene Implementierungen, die nicht zu einander kompatibel sind da sie ein eigenes Süppchen kochen. Es gibt zwar Überschneidungen und man kann sicherlich Programm schreiben, die auf beiden VMs ohne Änderungen laufen. Nur sind die Schnittpunkte nicht sehr groß und man muss aufpassen. ;)

Einer der Vorteile von VB.NET/C# ist, dass man eine sehr umfangreiche Funktion zum Zugriff auf Systemschnittstellen von Windows hat und diese nicht von irgendwelchen Drittanbietern besorgen muss bzw. die ganzen Windows Konventionen quer durchgezogen sind und man sich nicht auf den kleinsten gemeinsamen Nenner beschränken muss. Dass das Ganze dann nicht vernünftig auf anderen Betriebssystemen laufen kann, ist irgendwie klar.
Das Mono Projekt ist für mich eine nette Spielerei wie Wine und in manchen Fällen vielleicht wirklich hilfreich, wenn man eine schnelle Lösung braucht, mehr aber schon nicht.

Gast

2012-02-08, 11:54:24

][immy

2012-02-08, 21:45:44

JavaScript ist meiner Ansicht nach keine ernsthafte Programmiersprache, sondern nur ein Weg für Webentwickler ohne Programmierkenntnisse ein paar Features mehr einzubauen. Nur Anfänger glauben, dass ein toleranter Compiler ohne Syntaxregeln und der ganze Late Binding Mist etwas Gutes ist.
Da werden Syntaxfehler toleriert, die dann irgendwann zur Laufzeit sporadisch zum Absturz führen, die man normalerweise schon alleine durch Syntax Highlighting finden würde.
du weist schon das besonders im Web Javascript immer wichtiger wird und Javascript so ziemlich die einzige sprache ist, die auf allen möglichen geräten läuft?
Aber ja, ich hasse es auch irgendwas in dieser scriptsprache zu machen. grade wenn es etwas komplexer wird fehlt mir sowas wie typsicherheit und intellisense. An dieser stelle wollte ich mich mal mit script# beschäftigen, aber irgendwie fehlt mir immer die zeit dafür.

C & C++ sind nicht tot zu bekommen. die sprachen werden wir auch in x jahren noch haben. ihre bedeutung wird aber vielleicht ein wenig leiden. denn java & .net sind recht mächtige frameworks mit denen sich sehr schnell komplexe Programme abbilden lassen.
Klar ginge es auch mit c/c++ aber der Aufwand ist einfach geringer, da einem bereits vorhandene funktionen jede menge arbeit abnehmen und man sich dadurch eher auf die kern des projekts konzentrieren kann und sich weniger um das drumherum kümmern muss.

Es gibt noch alle möglichen sprachen die ihre berechtigung haben, die es auch in 20-30 jahren noch geben wird, obwohl kaum einer sie kennt. es gibt halt viele sprachen die zielen auf ein bestimmtes markt-segment und in diesem sind sie (fast)unschlagbar.

Ist "Beta" inzwischen eigentlich tot?

Exxtreme

2012-02-08, 22:27:55

Ich würde Javascript nicht überschätzen. Denn es läuft nicht auf allen möglichen Geräten. Man braucht dazu nämlich einen Browser als VM. Zweitens, die Ergebnisse von JS-Programmen können varrieren je nach Browser und OS. Man ist dann quasi doch wieder plattformabhängig. Nur dass die Plattform eben Browser heisst. ;) Und ein drittes Problem ist, dass man immer den Sourcecode mitliefert. :D

PatkIllA

2012-02-08, 22:29:07

Nur dass die Plattform eben Browser heisst. ;) Und ein drittes Problem ist, dass man immer den Sourcecode mitliefert. :DDas ist bei Java und .NET praktisch auch so.

Yavion

2012-02-08, 22:57:36

Hey,
ich Programmiere gerade viel in der Schule und auch zu Hause, womit ist erstmal egal :P

nun zu meiner Frage,
es gibt ja viele Sprachen, aber sie kommen und gehen
z.B. C++ ist schon lange auf dem Markt,
aber wird das bleiben ? gibt es eine neue Sprache die viele Systeme verstehen, zb, auch Andriod? aber auch Linux, Windoof:D oder ähnliches ? Es gibt ja auch Phython usw. ich wollte mal wissen welche wird sich in der Zukunft durchzusetzen ? Man sollte ja wissen wo man sich selber am besten einarbeitet

Viele Grüße

Das hängt ja erstmal davon ab, in welche Richtung man gehen möchte:

Unternehmens- und Desktopanwendungen: Java, C#.
Embedded Bereich und MCP: C
Betriebsysteme, Basissoftware: C, Go oder Erlang.
Numerische Anwendung, Highperformance Computing und Visualisierung: C++
Webanwendungen und Tools: Python, Groovy, Ruby, JavaScript.
Entwicklung von Algorithmen, theoretische Informatik und Hochsicherheitsanwendung: Mathematica, Haskell, Lisp, Prolog.

Und das sind natürlich nur Beispiele ohne Anspruch auf Eindeutigkeit oder Vollständigkeit.
Wenn man gerade mit Programmieren anfängt, ist es vielleicht eine gute Idee, eine statisch typisierte Sprache zu verwenden. Der Umstieg auf dynamisch typisierte Sprachen fällt i.d.R. leichter als umgekehrt.
Andererseits haben Millionen Programmierer ihre ersten Programmiererfahrungen in LISP/Scheme gemacht.
Das wichtigste ist Erfahrungen sammeln und vor allem offen sein für neues (und altes!).
Denn es passiert regelmäßig, dass längst abgeschriebene Sprachen, Paradigmen und Konzepte auf einmal wieder auftauchen.

Gast

2012-02-08, 23:17:16

Das ist bei Java und .NET praktisch auch so.

Zu Java kann ich nicht viel sagen, aber bei .NET gibt es einige Obfuscating Tools. Klar einen unknackbaren Kopierschutz, der Razor1911 und Co. stand hält, bekommt man damit nicht hin, aber es reicht zumindest dazu, das Know How zu schützen, da sämtliche Funktions/Variablen/Klassennamen verschlüsselt sind und versuche hier einmal noch den Sinn zu finden. Bis du das geschafft hast, kannst du es gleich neu schreiben.

Bei JavaScript sehe ich das auch nicht als so großes Problem an. Anwendungen, die wirklich in einer so großen Zahl vertrieben werden, dass sich ein Kopierschutz lohnt (das meinste ist ja nur Anpassung der Firmeneigenen Homepage), der setzt sowieso auf eine andere Technologie, wobei hier php auch nicht viel besser aussieht, da hier auch die Source Files unkompiliert am Server liegen müssen.

RLZ

2012-02-08, 23:33:50

Da wird 3 Seiten über Programmiersprachen diskutiert und ABAP nicht genannt. :freak:
[immy;9157909']du weist schon das besonders im Web Javascript immer wichtiger wird und Javascript so ziemlich die einzige sprache ist, die auf allen möglichen geräten läuft?
WAT? (https://www.destroyallsoftware.com/talks/wat)

Definier mal alle mögliche Geräte.
Wenn ich mir anschaue auf welche Plattformen es C# dank Mono geschafft hat, bin ich immer noch erstaunt. Sogar Sony setzt bei der Playstation Suite darauf.

Es gibt noch alle möglichen sprachen die ihre berechtigung haben, die es auch in 20-30 jahren noch geben wird, obwohl kaum einer sie kennt. es gibt halt viele sprachen die zielen auf ein bestimmtes markt-segment und in diesem sind sie (fast)unschlagbar.
Domänenspezifische Sprachen sind imo eh die Zukunft, da den Compilern ansonsten zuviel Semantik fehlt.

Das ist bei Java und .NET praktisch auch so.
Ich will mal sehen, wie du bei einer HASP geschützten .NET Anwendungen noch etwas mit dem CLI Code anfangen kannst. :freak:

Monger

2012-02-08, 23:35:15

Man ist dann quasi doch wieder plattformabhängig. Nur dass die Plattform eben Browser heisst. ;)

Nach der Definition: ich glaube, es gibt nirgendwo einen so klar definierten Standard wie eine Sandbox auszusehen hat wie bei heutigen Browsern. So ähnlich sind sich sonst keine zwei Plattformen.

Läuft natürlich immer noch nicht so rund wie es sollte, aber was außer Web Anwendungen läuft schon auf Smartphones, Tablets, Spiele Konsolen, PC und Mac?

Und ein drittes Problem ist, dass man immer den Sourcecode mitliefert. :D
Das Problem ist in der Praxis irgendwie erstaunlich irrelevant. Das war als bei uns auf der Firma .NET aufkam auch ein riesiges Thema, aber mittlerweile haben sich die Sorgen zerstreut. Wir haben ja schon Probleme unseren eigenen Quellcode in Klartext zu verstehen, wie soll das dann erst die Konkurrenz? ;)

PatkIllA

2012-02-08, 23:46:14

Ich will mal sehen, wie du bei einer HASP geschützten .NET Anwendungen noch etwas mit dem CLI Code anfangen kannst. :freak:Für Scriptsprachen gibt es auch Techniken die unleserlich zu machen.
Im CLI Code schaut man eh in der Regel nicht. Die Decompiler liefern ziemlich gut nachvollziehbaren Code.
Außerdem macht Obfuscation Problemanalyse auf Kundenseite schwieriger.

Wirkliche Bedenken habe ich ähnlich wie Monger eh nicht,

Shink

2012-02-09, 08:15:53

Da wird 3 Seiten über Programmiersprachen diskutiert und ABAP nicht genannt. :freak:
Post #4.:freak:

Tiamat

2012-02-09, 11:29:50

Moment, der Thread lautet doch welche Sprachen im Kommen sind oder welche langsam verschwinden.
Was hier 3 Seiten aufgelistet wird, sind doch schon längst etablierte Sprachen ^^

Da kann man doch momentan nur Scala und GO nennen, die (langsam) im Kommen sind.
Mit Scala hab ich persönlich noch nichts programmiert, aber mal einen Vortrag an der FH gehört (Sprachen für die JVM) und das hat mir von allen anderen vorgestellten wie Clojure e.t.c den besten Eindruck gemacht.

Go sieht sehr interessant aus.
Toll ist Unicodeunterstützung für Bezeichner!, also sowas wie ∆t, oder tief und hochgestellte Indicees für Bezeichner ist kein Problem.
Funktionen können mehr als einen Wert zurückgeben, das sticht aus der Masse hervor.
Ansonsten wird glaub ich alles als Call by Value übergeben, weswegen die Performance bisher nicht übermäßig aufgefallen ist, allerdings gibt es auch Pointer(aber ohne Arithmetik). Benutzung von Funktionszeigern durch Schlüsselwort func macht die Angelegenheit übersichtlich.
Soll auch ziemlich einfach sein, Sockets zu benutzen. Ich schau ich mir das demnächst mal an.
Ich bin mal gespannt wann so langsam die 5. Generation Programmiersprachen auftaucht.

rattentod

2012-02-09, 12:09:34

Numerische Anwendung, Highperformance Computing und Visualisierung: C++

Im HPC Bereicht wird noch immer sehr, sehr viel Fortran eingesetzt. Ich war neulich bei einer Besichtigung des ZIB in Berlin, was zum HLRN Verbund gehoert und die meisten Sachen werden dort noch immer in Fortran gemacht.

Entwicklung von Algorithmen, theoretische Informatik und Hochsicherheitsanwendung: Mathematica, Haskell, Lisp, Prolog.

Was ist den aus deiner Sicht eine Hochsicherheitsanwendungen? Was fuer ein schoener Thread zum ranten ...

Shink

2012-02-09, 13:01:24

Im HPC Bereicht wird noch immer sehr, sehr viel Fortran eingesetzt. Ich war neulich bei einer Besichtigung des ZIB in Berlin, was zum HLRN Verbund gehoert und die meisten Sachen werden dort noch immer in Fortran gemacht.
AFAIK ist mehr als 50% der Backend-Banksoftware in Prolog Fortran geschrieben.
Man muss auch zugeben dass moderne Fortran-Versionen einiges drauf haben:
http://de.wikipedia.org/wiki/Co-array_Fortran

Da kann man doch momentan nur Scala und GO nennen, die (langsam) im Kommen sind.
Ich bin mir nicht ganz sicher ob Scala noch "in" ist wenn es einmal Closures in Java gibt.
Go find ich auch ganz nett - aber davon abgesehen, dass Google offensichtlich alle paar Jahre mal eine neue Programmiersprache raushaut (z.B. Dart):freak: wüsste ich nicht aus welchem Grund Go irgendetwas anderes ablösen soll. Naja, ausser Oracle macht noch mehr Unsinn mit Java.

Exxtreme

2012-02-09, 13:22:26

Naja, ausser Oracle macht noch mehr Unsinn mit Java.
Also ich wüsste nicht wo Oracle mit Java Unsinn macht.

Tiamat

2012-02-09, 14:15:32

AFAIK ist mehr als 50% der Backend-Banksoftware in Prolog geschrieben.
Man muss auch zugeben dass moderne Fortran-Versionen einiges drauf haben:
http://de.wikipedia.org/wiki/Co-array_Fortran

Ich bin mir nicht ganz sicher ob Scala noch "in" ist wenn es einmal Closures in Java gibt.
Go find ich auch ganz nett - aber davon abgesehen, dass Google offensichtlich alle paar Jahre mal eine neue Programmiersprache raushaut (z.B. Dart):freak: wüsste ich nicht aus welchem Grund Go irgendetwas anderes ablösen soll. Naja, ausser Oracle macht noch mehr Unsinn mit Java.

Das kann ich mir nicht vorstellen mit Prolog.
Was hat Prolog im Bankwesen zu tun.

Selbst wenn Closures für Java in Java8 rauskommen, seh ich da immer noch Vorteile. Scala ist weniger schwergewichtig, wenige Zeilen Code ersetzen schon mal ne DinA4 Seite Code in Java und man kann glaub ich sämtliche JavaLibs benutzen. Das ganze bei weitgehend gleicher Performance.

Shink

2012-02-09, 14:42:08

Das kann ich mir nicht vorstellen mit Prolog.
Was hat Prolog im Bankwesen zu tun.
Scheisse, ich hab natürlich Fortran gemeint.:freak:

Prolog wird allerdings öfters verwendet als man glaubt. Z.B. unterstützt JBoss Drools das Prolog-like Backward Chaining.

rattentod

2012-02-09, 18:06:15

Prolog wird allerdings öfters verwendet als man glaubt. Z.B. unterstützt JBoss Drools das Prolog-like Backward Chaining.

Naja, aber Backward Chaining ist als Verfahren doch völlig unabhängig von Prolog?

rattentod

2012-02-09, 18:08:41

Also ich wüsste nicht wo Oracle mit Java Unsinn macht.

Ich denke er bezieht sich auf die Lizenzpolitik. Beispielsweise gibt es keine Lizenz mehr für Linux Distributionen. Die Idee einer 'Premium' VM stehe ich auch eher skeptisch gegenüber. In der Vergangenheit hat man zumindest gesehen wohin das mit API verschiedenen JDKs hinführen kann.

Yavion

2012-02-09, 18:45:46

Der Nachteil an (Gnu) Prolog ist m.E. einfach der, dass es sch..... zu debuggen ist.
Scala leidet m.E. etwas dadurch, dass man die meisten (alle?) Vorteile auch in C-ähnlichen Sprachen wie Groovy oder C# haben kann.

Im HPC Bereicht wird noch immer sehr, sehr viel Fortran eingesetzt. Ich war neulich bei einer Besichtigung des ZIB in Berlin, was zum HLRN Verbund gehoert und die meisten Sachen werden dort noch immer in Fortran gemacht.

Was ist den aus deiner Sicht eine Hochsicherheitsanwendungen? Was fuer ein schoener Thread zum ranten ...
Ja. Das erklärt auch, warum es CUDA z.B. auch für Fortran gibt.

Mit Hochsicherheitsanwendungen meine ich Anwendungen, die den Aufwand einer mathematischen Verifizierung rechtfertigen.

Exxtreme

2012-02-09, 20:44:56

Ich denke er bezieht sich auf die Lizenzpolitik. Beispielsweise gibt es keine Lizenz mehr für Linux Distributionen. Die Idee einer 'Premium' VM stehe ich auch eher skeptisch gegenüber. In der Vergangenheit hat man zumindest gesehen wohin das mit API verschiedenen JDKs hinführen kann.
Wie bitte? Das OpenJDK 7 ist die Referenzimplementierung und unter der GPL 2. Von daher braucht's hier keine spezielle Lizenz für Linux. Die spezielle Lizenz bezog sich auf das Oracle JDK. Nur ist dieses schon seit Ewigkeiten mehr oder weniger völlig obsolet.

Shink

2012-02-09, 20:50:42

Der Nachteil an (Gnu) Prolog ist m.E. einfach der, dass es sch..... zu debuggen ist.
Da widersprech ich nicht.

Naja, aber Backward Chaining ist als Verfahren doch völlig unabhängig von Prolog?
Nun ja... wirklich viel kann Prolog nicht ausser Backward Chaining.:freak:
Mir fällt auch keine Backward-Chaining-Implementierung ein, die keinen Prolog-Bezug hat. Selbst Drools nennt es "Prolog-style Backward Chaining".

Ich denke er bezieht sich auf die Lizenzpolitik. Beispielsweise gibt es keine Lizenz mehr für Linux Distributionen. Die Idee einer 'Premium' VM stehe ich auch eher skeptisch gegenüber. In der Vergangenheit hat man zumindest gesehen wohin das mit API verschiedenen JDKs hinführen kann.
Nun ja; wir alle kennen die Anfänge der Oracle-Herrschaft: Den Java Evangelisten Google verklagt (zu Recht natürlich), die JDK-Alternativimplementierung "Harmony" hat resigniert, Apache hat sich als JCP-Mitglied zurückgezogen... da konnte man schon ins Grübeln kommen. Ohne Open Source-Rückhalt wäre Java halt nicht wo es jetzt ist.

Coda

2012-02-09, 21:48:03

Im HPC Bereicht wird noch immer sehr, sehr viel Fortran eingesetzt. Ich war neulich bei einer Besichtigung des ZIB in Berlin, was zum HLRN Verbund gehoert und die meisten Sachen werden dort noch immer in Fortran gemacht.
Fortran kann wegen dem strikteren Speichermodell tatsächlich auch schneller sein als C/C++. Es ist halt... kotzhässlich X-D

][immy

2012-02-09, 22:44:42

Für Scriptsprachen gibt es auch Techniken die unleserlich zu machen.
Im CLI Code schaut man eh in der Regel nicht. Die Decompiler liefern ziemlich gut nachvollziehbaren Code.
Außerdem macht Obfuscation Problemanalyse auf Kundenseite schwieriger.

Wirkliche Bedenken habe ich ähnlich wie Monger eh nicht,

nunja, wirkliche bedenken bezüglich obfuskierung habe ich auch nicht. zur not schreibt man halt ein wenig unleserlichen code. Nur lizenzierungssachen und sowas kritisches sollte man nicht unbedingt offenlegen.

wir haben bei uns in der firma eigentlich nur angefangen obfuskierung einzusetzen, weil wir ab und an mal kunden hatten die sich die dlls mittels reflector angeschaut haben und sowas gefragt haben wie "warum macht ihr das denn so?". es hatte zwar alles seine richtigkeit und gründe, warum es so war wie es nunmal war, aber die obfuskierung hat auch hier einen riegel vorgeschoben.
Was die Konkurenz angeht, hier mache ich mir weit weniger sorgen. ab einem gewissen punkt sind produkte so komplex, das man sich höchstens einige winzige sachen "rausklauen" könnte, alles andere wäre aufgrund der komplexität und abhängigkeiten ein viel zu hoher aufwand.

und was javascript angeht, es läuft in allen möglichen browsern relativ gleich (zumindest in aktuellen browsern). Das einzige was hier und da mal nicht stimmt sind irgendwelche positionierungen bzw. hat eher mit dem DOM zu tun als mit dem Javascript selbst. Und inzwischen gibt es auch recht gute bibliotheken wie dojo oder jquery die einem einiges an arbeit abnehmen. Trotzdem fehlen da noch wirklich gute entwicklungstools und z.B. so eine art von compiler der auch mal ein paar probleme (z.B. allein die typsicherheit erspart einem in .net schon einiges ... z.B. gibt es dadurch intellisense ^^) anzeigt bevor man sie im browser suchen muss.
worauf man allerdings bei exessiven javascript einsatz achten muss ist immer wieder die performance die von browser zu browser unterschiedlich ist und auch hier haben besonders die mobilen geräte extreme schwachstellen.
ich würde allerdings niemals auf die idee kommen komplexe systeme in javascript abzubilden. so krank (http://www.jslint.com/lint.html) bin ich dann doch nicht :)

creave

2012-02-09, 23:35:33

.... Und ohne Scheiss, mir ist kein .NET-Programm bekannt welches nicht irgendwie komisch/wackelig läuft. X-D

Darf ich fragen, was du so für .NET Programme verwendet hast? Ernst gemeinte Frage, mir fiele für das von dir beschriebene Verhalten kein .NET spezifischer Grund ein :)

Windows 8 und COM? Wo hast du denn das gelesen? COM war zwar nie richtig weg, aber dass es zu neuer Blüte geführt werden soll, bezweifle ich.

WinRT für Metro basiert wohl durchaus auf überarbeiteten COM.

Coda

2012-02-09, 23:46:41

Es ist nichtmal überarbeitet. Es ist stinknormales COM abstrahiert über C++/CX. Ich wüsste auch nicht was daran verwerflich sein sollte.

Und ohne Scheiss, mir ist kein .NET-Programm bekannt welches nicht irgendwie komisch/wackelig läuft. X-D
.NET wird viel öfters verwendet als du denkst. Man sieht es nur nicht.

Exxtreme

2012-02-10, 08:40:55

Darf ich fragen, was du so für .NET Programme verwendet hast? Ernst gemeinte Frage, mir fiele für das von dir beschriebene Verhalten kein .NET spezifischer Grund ein :)

Auf die Schnelle fallen mir SQL Server Management Studio, Paint.net, SQL Server Replikationsmonitor, Lookout Search und Curse Client ein. Wobei Lookout Search tatsächlich am Brauchbarsten lief.

.NET wird viel öfters verwendet als du denkst. Man sieht es nur nicht.
Der einzige Fall wo ich .NET-Programme nicht merke, ist wenn diese komplett eigene GUIs verwenden, z.B. Spiele oder so. Sobald es aber in Richtung Anwendungen geht merke ich es.

Kenny1702

2012-02-10, 09:42:31

Bzgl. des Titels, von einem "Kommen und Gehen" habe ich noch nicht viel bemerkt.

In der Uni habe ich (vor mittlerweile 12 Jahren) mit Java angefangen. Inzwischen bin ich beruflich seit ein paar Jahren auf .NET (C# und VB). Derzeit sieht es auch nicht danach aus, als würde sich das in den nächsten Jahren ändern. Das, was sich merklich geändert hat seit meinen Anfängen, sind die Frameworks.

Shink

2012-02-10, 09:46:04

Naja; Delphi war vor 10-20 Jahren in manchen Bereichen (Clients) sehr beliebt. Heute ist das ein totes Pferd.

xxxgamerxxx

2012-02-10, 10:11:07

Der einzige Fall wo ich .NET-Programme nicht merke, ist wenn diese komplett eigene GUIs verwenden, z.B. Spiele oder so. Sobald es aber in Richtung Anwendungen geht merke ich es.

Und wie genau merkst du das? Ich arbeite mit dem Management Studio (2008 täglich. Ohne jetzt genau zu prüfen (Bsp. Prozess Explorer), wüsste ich nicht, ob die Anwendung .NET verwendet oder nicht.

Coda

2012-02-10, 11:21:09

Das wollte ich ihn auch fragen, hab's dann aber einfach gelassen. Ist doch ermüdend.

Exxtreme

2012-02-10, 12:21:42

Und wie genau merkst du das? Ich arbeite mit dem Management Studio (2008 täglich. Ohne jetzt genau zu prüfen (Bsp. Prozess Explorer), wüsste ich nicht, ob die Anwendung .NET verwendet oder nicht.
Auch wenn es OT ist, es ist eine spürbare Langsamkeit/Trägheit und oft auch gehen die Programme in einem Zustand wo sie irgendwie undefiniert reagieren. Sprich, sie reagieren nicht mehr auf Mausklicks, Tastatureingaben gehen aber noch etc. Und dann muss man sie beenden und neu starten. Und das MS SQL Server Management Studio ist hier das Negativbeispiel schlechthin. Und ja, ich kann direkt vergleichen da ich auch noch den alten Enterprise Manager für SQL Server 2000 parallel nutze. Und der basiert nicht auf .NET und hat alle diese Probleme nicht.

creave

2012-02-10, 12:53:07

Coda

2012-02-10, 15:38:26

Ich vermute das Problem ist eher, dass billig und schnellgeschriebene Software vermehrt in "einfacheren" Sprachen wie C# geschrieben wird und daher dieser Eindruck entsteht.

Das liegt aber nicht inhärent an .NET.

Exxtreme

2012-02-10, 16:26:59

Zu der Sache mit der Performance will ich dir weder widersprechen, noch zustimmen, das hängt dann auch sehr davon ab, was das Programm leisten muss, wie es programmiert wurde, wie das persönliche empfinden ist etc. Dass .NET nicht gerade Rekorde aufstellt ist natürlich klar.

Zu der Sache mit der fehlenden Reaktion auf Mausklicks und dem "undefinierten Verhalten", das hat wohl kaum mit .NET zu tun und ich kann dir auch schwer glauben, dass das bei dir gleich bei mehreren Programm auftritt (und falls doch, dann liegt an deiner Systemkonfiguration o.ä. wohl was im Argen. Bei welchen Programmen soll das noch so gewesen sein und kannst du es rekonstruieren?). Programmiere seit Jahren .NET und mir kam noch nie derartiges zu Ohren, zumal .NET mittlerweile stark verbreitet ist und quasi niemand von solchen Dingen berichtet.

Anhand vom Programmverhalten kann man wohl kaum sagen, dass es sich um .NET handelt, von "undefiniertem Verhalten" kann man nicht darauf schließen und was die Trägheit angeht, da gibt es außer nativen Sprachen wohl nicht viel besseres für Windows.
Das mit dem undefinierten Verhalten ist mir beim SQL Server Management Studio, beim AMD Catalyst Control Center und beim Curse Updater aufgefallen. Und lahm sind sie irgendwie alle.

Ich will auch nicht sagen, .NET sei dran schuld und es sei unmöglich damit Programme zu schreiben, die diese Mängel nicht aufweisen. Nur finde ich es echt komisch, dass das bisher nur in .NET-Programmen aufgetreten ist. Und zweitens, grad Microsoft patzt hier mit dem SQL Server Management Studio am Heftigsten. Obwohl Microsoft es eigentlich am besten können müsste. Und nein, das SQL Server Management Studio bietet nicht so viel mehr Funktionalität im Vergleich zum alten Enterprise Manager, als dass es diese Performanceeinbußen dadurch gerechtfertigt wären. Beim CCC von AMD merkt man das auch. Wer noch das alte Controlpanel von ATi kennt, der wird mit Sicherheit auch zustimmen, dass dieses beträchtlich flotter unterwegs war als das CCC. Obwohl Letzteres jetzt auch kein Funktionalitätsmonster ist.

Und ja, vielleicht hat Coda recht und das .NET-Framework bzw. C# "verführt" die Programmierer zu Dingen, die in anderen Frameworks/Sprachen zu sofortigen Fehlern führen oder als nicht "best practise" gelten. Keine Ahnung.

Monger

2012-02-10, 17:57:26

Und ja, vielleicht hat Coda recht und das .NET-Framework bzw. C# "verführt" die Programmierer zu Dingen, die in anderen Frameworks/Sprachen zu sofortigen Fehlern führen oder als nicht "best practise" gelten. Keine Ahnung.
Ich kenn das Phänomen von Arbeit auch: wenn man bestimmte Algorithmen durch den Profiler jagt, sind diese meistens irrsinnig schnell in .NET, aber wenn die fertige, große Applikation da steht ist sie plötzlich träge.

Meiner Meinung nach hat das auch damit zu tun, dass C# eben kein C++ Nachfolger ist, wie von Microsoft immer wieder gerne beworben. Ein erfahrener C++ Entwickler kann eben nicht 1:1 seinen Code auf C# transferieren. Die ähnliche Syntax ist da eher irreführend.

Zum Beispiel (gefährliches Halbwissen, meine C++ Zeit ist lange her): Structs galten in C++ als sehr leichtgewichtig, das Instanziieren von Objekten dagegen als teuer.
In .NET dagegen können Structs sich auf dem Lokaldatenstack ziemlich aufblähen, Microsoft empfiehlt selbst, nur Structs für kleine, nicht veränderbare Value Types zu benutzen.

Gibt noch mehr so Beispiele. Kann mich da an Diskussionen erinnern wo die Collection Typen aus dem .NET Framework unseren Entwicklern zu speicherintensiv waren, und sie deshalb angefangen haben ihre eigenen Typen zu implementieren. Ich will jetzt darauf nicht näher eingehen, aber man kann sich denken dass in der Praxis die Performance dadurch nicht gerade besser geworden ist.

Ich habe also den starken Verdacht, dass durch den Versuch zwanghaft alte Muster in die Neuwelt zu transportieren da vieles erstmal schlechter wird.

Gast

2012-02-10, 20:44:24

Und ohne Scheiss, mir ist kein .NET-Programm bekannt welches nicht irgendwie komisch/wackelig läuft.

Das liegt eher daran, dass Anfänger bzw. Gelegenheitsprogrammierer oft Programme in .NET schreiben. Wenn die C/C++ verwenden würden, wäre es noch schlimmer siehe Pointerei.

Auf die Schnelle fallen mir SQL Server Management Studio, Paint.net, SQL Server Replikationsmonitor, Lookout Search und Curse Client ein. Wobei Lookout Search tatsächlich am Brauchbarsten lief.

Der einzige Fall wo ich .NET-Programme nicht merke, ist wenn diese komplett eigene GUIs verwenden, z.B. Spiele oder so. Sobald es aber in Richtung Anwendungen geht merke ich es.

Ich kann das bestätigen. Standardsoftware, wo erstens Kopierschutz ist großes Thema ist bzw. die meistens tiefe Wurzeln habe, sind meistens in C/C++ geschrieben, aber hier sind die wenigsten Programmierer beschäftigt.
Die meisten Programmierer schreiben Individualsoftware für einen Kunden. Hier ist die Entwicklungszeit ein großes Thema. Gerade für kleinere Projekte bis zu 10.000 Zeilen Code ist .NET ein sehr großer Vorteil, da man eine sehr große Bibliothek an Funktionen hat und sehr schnell zu einem funktionsfähigen Programm kommt. Klar bei einem Projekt mit 100 Mio. Zeilen Code kann man es sich schon leisten großen Teile der Bibliothek selbst zu entwickeln. Wenn selbst schreiben zu teuer ist, und die Funktionen nicht in der Bibliothek integriert sind, hilft nur Codeteile von Drittanbietern zu verwenden und hier habe ich schon sehr schlechte Erfahrungen gemacht, was die Fehlersuche bzw. den Support angeht.
Die graphischen Effekte sind meistens nebensächlich. Wichtig ist die Funktionalität und die bekommt man mit Standardcontrols in .NET schon sehr gut hin.

xxxgamerxxx

2012-02-10, 20:53:44

Und zweitens, grad Microsoft patzt hier mit dem SQL Server Management Studio am Heftigsten. Obwohl Microsoft es eigentlich am besten können müsste. Und nein, das SQL Server Management Studio bietet nicht so viel mehr Funktionalität im Vergleich zum alten Enterprise Manager, als dass es diese Performanceeinbußen dadurch gerechtfertigt wären.

Bei mir läuft das Management Studio schnell und problemlos. Wo konkret hängt's denn? Den alten Enterprise Manager 2000 kann man doch eh nicht verwenden für Sql Server > 2000. Das Management Studio wird auch deutlich mehr mit dem Server kommunizieren als noch der Enterprise Manager, zum Beispiel bei Intellisense.

Eigentlich kann es ja nur irgend ein Konfigurationsproblem, Netzproblem oder sowas sein.

][immy

2012-02-13, 23:06:34

Das mit dem undefinierten Verhalten ist mir beim SQL Server Management Studio, beim AMD Catalyst Control Center und beim Curse Updater aufgefallen. Und lahm sind sie irgendwie alle.

Ich will auch nicht sagen, .NET sei dran schuld und es sei unmöglich damit Programme zu schreiben, die diese Mängel nicht aufweisen. Nur finde ich es echt komisch, dass das bisher nur in .NET-Programmen aufgetreten ist. Und zweitens, grad Microsoft patzt hier mit dem SQL Server Management Studio am Heftigsten. Obwohl Microsoft es eigentlich am besten können müsste. Und nein, das SQL Server Management Studio bietet nicht so viel mehr Funktionalität im Vergleich zum alten Enterprise Manager, als dass es diese Performanceeinbußen dadurch gerechtfertigt wären. Beim CCC von AMD merkt man das auch. Wer noch das alte Controlpanel von ATi kennt, der wird mit Sicherheit auch zustimmen, dass dieses beträchtlich flotter unterwegs war als das CCC. Obwohl Letzteres jetzt auch kein Funktionalitätsmonster ist.

Und ja, vielleicht hat Coda recht und das .NET-Framework bzw. C# "verführt" die Programmierer zu Dingen, die in anderen Frameworks/Sprachen zu sofortigen Fehlern führen oder als nicht "best practise" gelten. Keine Ahnung.

.net (bzw. in diesem fall c#) verleitet schnell dazu bestehendes zu verwenden. Dieses ist dann häufig aber nicht zu 100% auf den anwendungsfall optimiert wodurch es vielleicht auch mal ein wenig langsamer wird. Dafür spart man aber jede menge arbeit die man in andere teile reinstecken kann.

meine erfahrung mit .net ist, es lässt sich ziemlich schnell die gewollte logik abbilden, ohne sich großartig mit dem drum herum zu beschäftigen. Das geht auch gut solange alles im kleinen rahmen bleibt, wenn man dann aber auf grenzfälle stößt muss man halt mal optimieren, was aber nur recht wenige machen.

kleines beispiel:
Fülle eine Datagrid mit tausenden zeilen und schalte die autooptimierung der zeilenhöhe/breite ein.

Mit ~100 Zeilen ist es noch schnell. mit 1000den nicht mehr erträglich (z.B. bei scrollen). Legt man nun hand an und optimiert das rendering (z.B. nur noch das sichtbare korrekt ausrichten) ist es wieder schnell. sowas kostet zwar zeit, aber ist immernoch schneller als in c++ (im normalfall).

Diese Optimierungen werden aber nur sehr selten vorgenommen (zumindest von dem was man so im internet findet) denn die software erfüllt ja ihren zweck bereits, warum sollte man also zeit in optimierung stecken wenn es dann am ende 10s schneller ist den catalyst treiber zu installieren?
Was natürlich in beiden Welten geht, man nimmt sich einfache eine Fremdkomponente die schon in alle möglichen Richtungen optimiert wurde (z.B. Telerik, DevExpress,...) und spart jede Menge Zeit.

Ich weiß nicht mehr von wem ich das mal gelesen habe, aber da hat ein recht bekannter entwickler mal geschrieben, das er mehrere Wochen in ein Tool gesteckt hat, welches im dann am Tag 2 Klicks abnimmt. Aus seiner Sicht hatte sich das gelohnt, weil er nun diese nervigen Klicks los war, aber rein wirtschaftlich war es eine Katastrophe. Und so ist es auch bei den meisten kleine Tools denen man über den weg läuft, es lohnt einfach nicht eine Entwickler mit sowas zu beschäftigen, wenn man ihn stattdessen schon aufs nächste Projekt schicken kann.

Und was das SQL Mangement Studio angeht, also lahm finde ich das nicht. Das ist irgendwie nur ziemlich lahm, wenn man irgendwelche Einstellungen ein einer Datenbank ändern will, aber Editor, Verbindungsaufbau & co sind doch flott.

übrigens, den Eindruck den du von .net hast, habe ich häufig auch von Java, aber das sind dann einfach die weiter oben genannten probleme.

Exxtreme

2012-02-14, 22:52:03

[immy;9164840'].net (bzw. in diesem fall c#) verleitet schnell dazu bestehendes zu verwenden. Dieses ist dann häufig aber nicht zu 100% auf den anwendungsfall optimiert wodurch es vielleicht auch mal ein wenig langsamer wird. Dafür spart man aber jede menge arbeit die man in andere teile reinstecken kann.

meine erfahrung mit .net ist, es lässt sich ziemlich schnell die gewollte logik abbilden, ohne sich großartig mit dem drum herum zu beschäftigen. Das geht auch gut solange alles im kleinen rahmen bleibt, wenn man dann aber auf grenzfälle stößt muss man halt mal optimieren, was aber nur recht wenige machen.

kleines beispiel:
Fülle eine Datagrid mit tausenden zeilen und schalte die autooptimierung der zeilenhöhe/breite ein.

Mit ~100 Zeilen ist es noch schnell. mit 1000den nicht mehr erträglich (z.B. bei scrollen). Legt man nun hand an und optimiert das rendering (z.B. nur noch das sichtbare korrekt ausrichten) ist es wieder schnell. sowas kostet zwar zeit, aber ist immernoch schneller als in c++ (im normalfall).

Diese Optimierungen werden aber nur sehr selten vorgenommen (zumindest von dem was man so im internet findet) denn die software erfüllt ja ihren zweck bereits, warum sollte man also zeit in optimierung stecken wenn es dann am ende 10s schneller ist den catalyst treiber zu installieren?
Was natürlich in beiden Welten geht, man nimmt sich einfache eine Fremdkomponente die schon in alle möglichen Richtungen optimiert wurde (z.B. Telerik, DevExpress,...) und spart jede Menge Zeit.

Ja, aber das Vorhandene verwenden ist das was produktiv macht weil es Arbeit spart. Genau deshalb ist Java so verdammt mächtig geworden. Es ersparte dem Programmierer viel Kleinkram, welcher auch noch fehleranfällig war. Und die Java-Klassenbibliothek ist auch immer noch sehr fein. Das spart Kosten und senkt den Preis. Klar braucht man mehr RAM wegen der VM und so. Aber RAM ist im Vergleich zur Arbeitszeit viel billiger. Lieber 4 GB mehr reintun als Programmierer zum Suchen und Stopfen von Memoryleaks zu verdonnern.

Übrigens, ich glaube die Ereignisanzeige von Windows 7 ist auch in .NET implementiert. Einfach mal da rumklicken. Es passiert oft, dass das Fenster so halb gezeichnet für 5 - 10 Sekunden hängenbleibt. Daran erkenne ich .NET-Anwendungen recht präzise. Das SQL Management Studio zeigt exakt das gleiche Verhalten, wo der Enterprise Manager sofort das Gewünschte anzeigte.

[immy;9164840']übrigens, den Eindruck den du von .net hast, habe ich häufig auch von Java, aber das sind dann einfach die weiter oben genannten probleme.

Hier entscheidet sich viel mehr ... Build on Eclipse oder nicht? X-D

Eclipse ist allgemein ein Fall für sich. Da ist das GUI nicht einmal Java da es aus JNI-Aufrufen nativer Steuerelemente des Betriebssystems besteht.

Trap

2012-02-14, 23:49:28

Lieber 4 GB mehr reintun als Programmierer zum Suchen und Stopfen von Memoryleaks zu verdonnern.
Mit viel mehr als 32 GB Heapgröße kann der mitgelieferte JVM-GC soweit ich weiß aber nicht so wirklich gut umgehen, der nimmt sich dann ab und zu längere Denkpausen.

Tiamat

2012-02-14, 23:52:34

Dieses ganze abstrahierte Zeug(Java, C#, e.t.c) geht auch mächtig auf die Akkulaufzeit bei mobilen Geräten. Das ist allein der Grund, wieso C/C++ so schnell auch nicht abgelöst werden.

RattuS

2012-02-15, 00:20:57

Frameworks sind nur dort problematisch, wo wenig Speicher zur Verfügung steht. Ansonsten ist der JIT-Kompilierung herzlich wenig nachzusagen. C/C++ wird in Zukunft nur noch dort verwendet werden, wo Hardwarenähe erforderlich bleibt. Der Markt entwickelt sich sonst aber doch schon seit Jahren in Richtung RAD und da hat C/C++ keinen Platz. Selbst im Game-Development bietet Microsoft mit dem XNA-Framework mittlerweile ein umfangreiches Spielzeug, das so einige Entwickler-Studios motiviert endlich von C++ wegzukommen.

Gast@work

2012-02-15, 14:14:11

Ich habe also den starken Verdacht, dass durch den Versuch zwanghaft alte Muster in die Neuwelt zu transportieren da vieles erstmal schlechter wird.Das mag ein Punkt sein. Ebenso wichtig ist aber der Punkt, dass gewisse Feinheiten nicht bekannt sind, die große Auswirkungen haben können. Bei der Applikation an der ich mitarbeite hat sich schon öfters gezeigt, dass Events ein Hauptquell von Performanceverlusten sind. Beispielsweise indem unbeabsichtigt Eventkaskade entstehen, Events unötigerweise unzählige Male pro Sekunde feuern oder aber dass diese nicht korrekt wieder deregistriert werden und somit für Objektleichen sorgen. Letzteres sorgt dann nicht nur für ein Memoryleak sondern es werden auch noch nach wie vor Events abarbeitet was die Applikation mit der Zeit immer langsamer werden lässt.
Aber RAM ist im Vergleich zur Arbeitszeit viel billiger. Lieber 4 GB mehr reintun als Programmierer zum Suchen und Stopfen von Memoryleaks zu verdonnern.Ist aber immer ein schmaler Grat. Wir verwenden auf der Arbeit http://teambuildscreen.codeplex.com/ und das kleine Tool gehemigt sich auch mal an die 200 MB Hauptspeicher plus einen kompletten Core Rechenleistung für ein paar Zeilen Text, die es alle 30 Sekunden mal updaten muss. Da komme zumindest ich dann schon mal ins Grübeln ob das wirklich sein muss.
Übrigens, ich glaube die Ereignisanzeige von Windows 7 ist auch in .NET implementiert. Einfach mal da rumklicken. Es passiert oft, dass das Fenster so halb gezeichnet für 5 - 10 Sekunden hängenbleibt. Daran erkenne ich .NET-Anwendungen recht präzise. Das SQL Management Studio zeigt exakt das gleiche Verhalten, wo der Enterprise Manager sofort das Gewünschte anzeigte.Das könnte am Threading liegen. Bei .Net muss man aufpassen, dass nicht zu viel im UI Thread gemacht wird, ansonsten hängt alles. Zumal gewisse Controls von WPF eine schlechte Performance haben. Vor allem bei Grids ist mir das schon sehr negativ aufgefallen. Mit Grids kann man sich die Performance und Reaktivität einer .Net-Anwendung total zerstören. Da kann es dann vorkommen, dass das UI sekundenlang steht. AFAIR hat mal einer bei uns das untersucht und raus gefunden, dass das Problem ist, dass das .Net-Grid bei irgendwelchen Änderungen stets (fast) alles neu berechnet. Vor allem bei Grids die in Grids eingebettet sind, müssen dann unzählige Operationen ausgeführt werden um die korrekte Anzeigegröße der Zellen zu bestimmen. Da könnte man mit Optimierung viel heraus holen, was allerdings nicht geht, da der Ansatz von MS sehr generisch ist.

Yavion

2012-02-15, 17:49:35

(...)
Das könnte am Threading liegen. Bei .Net muss man aufpassen, dass nicht zu viel im UI Thread gemacht wird, ansonsten hängt alles. Zumal gewisse Controls von WPF eine schlechte Performance haben. Vor allem bei Grids ist mir das schon sehr negativ aufgefallen. Mit Grids kann man sich die Performance und Reaktivität einer .Net-Anwendung total zerstören. Da kann es dann vorkommen, dass das UI sekundenlang steht. AFAIR hat mal einer bei uns das untersucht und raus gefunden, dass das Problem ist, dass das .Net-Grid bei irgendwelchen Änderungen stets (fast) alles neu berechnet. Vor allem bei Grids die in Grids eingebettet sind, müssen dann unzählige Operationen ausgeführt werden um die korrekte Anzeigegröße der Zellen zu bestimmen. Da könnte man mit Optimierung viel heraus holen, was allerdings nicht geht, da der Ansatz von MS sehr generisch ist.

Die Sache mit dem UI-Thread und synchronen Methodenaufrufen ist allerdings eher Forms-Problem. WPF macht mit seinem eigenen Rendering-Thread da schon von Haus aus einiges richtig. Den Rest muss man selbst lösen, wobei das heute mit Dispatcher-Aufrufen auch recht komfortabel geworden ist.

Das mit den grids macht mich jetzt aber neugierig: Welche Grids sind hier gemeint: DataGrids oder das allgemeine Wpf-Grid zum tabellarischen Anordnen beliebiger Elemente?
Gerade letzteres würde mich sehr wundern, weil Grids häufig auch in abgeleiteten Controls/Control Templates vorkommen, z.B. Slider.
Das DataGridView hat (zumindest in Forms) so seine eigenen Caveats...

Monger

2012-02-15, 20:02:18

...AFAIR hat mal einer bei uns das untersucht und raus gefunden, dass das Problem ist, dass das .Net-Grid bei irgendwelchen Änderungen stets (fast) alles neu berechnet. Vor allem bei Grids die in Grids eingebettet sind, müssen dann unzählige Operationen ausgeführt werden um die korrekte Anzeigegröße der Zellen zu bestimmen. Da könnte man mit Optimierung viel heraus holen, was allerdings nicht geht, da der Ansatz von MS sehr generisch ist.
Meinst du DataGrid?

WPF ist kein einfaches Thema. Wenn du weißt was du tust, kannst du nahezu jeden Aspekt durch eigene Implementierungen ersetzen. Du kannst z.B. das Datenprovider des DataGrid durch eine eigene Implementierung austauschen, und kannst dann ganz genau kontrollieren welche Render Events zu welchem Zeitpunkt geworfen werden sollen.

Manche Lösungen die auf den ersten Blick furchtbar kompliziert aussehen, sind dann mit wenigen Handgriffen gelöst - und andere wiederum die total selbstverständlich wirken, sind alles andere als trivial.
Ein Zeilenindex ist z.B. in einem DataGrid echt nicht einfach performant zu realisieren, vorallem wenn Zeilen eingefügt oder verschoben werden können. Ein Index setzt halt die Kenntnis über die Indizes aller Daten voraus, und das ist bei weitem keine selbstverständliche Information.

Auf der anderen Seite funktioniert die Virtualisierung der Grid Zellen quasi out of the Box. Wir haben kleine Tools auf Arbeit mit hunderttausenden von Zeilen in einem Grid, und wenn man ein bißchen an den gehosteten Controls rumschleift, läuft das auch richtig schön flott.