.Net Treiber auch von nvidia! [Archiv]

r@h

2004-09-27, 01:13:32

PS: nLite mag auch nicht ohne .NET, die Anzahl an Anwendungen, die das benötigen wird rapide zunehmen...Wen interesiert "nLite"?
Und auch sonst gibt aber auch rein gar nichts, was mich dazu bewegen würde, .NET nutzen zu wollen...

Wenn es bis 2006 'rapide' (unverzichtbare?) Anwedungen geben soll, dann sollten sie wirklich langsam mal anfangen. Und by the Way, im 3DCenter & 3DCenter Forum (http://www.forum-3dcenter.org/vbulletin/showthread.php?t=167129) gibt's zu diesen Thema schon einen Thread, indem IMO auch schon alles zu diesem Thema gesagt wurde.

Also, Stefan, troll Dich dahin!
Hoffe inständig, dass diese ganze Sinnlos-Diskussion nicht wieder von vorne los geht.

Und was mir noch einfällt: The Inquerer?
:Kotz:
:D

Razor

P.S.: ich will die alten Smilies wieder!
*schmoll*

Leonidas

2004-09-27, 01:42:16

1. ist das das richtige forum?
2. da stehts (http://www.computerbase.de/news/treiber/grafikkarten/nvidia/2004/september/auch_nvidia_net-treiber/)

meine meinung dazu: egal!

Spekulation von Inquirer. Wichtig ist hier das Wort "könnte". Wie mir dagegen nVidia bestätigte, wird deren Deto70 noch nicht auf .NET basieren.

Leonidas

2004-09-27, 01:44:16

fragt sich nur wie lang noch :devil:

PS: nLite mag auch nicht ohne .NET, die Anzahl an Anwendungen, die das benötigen wird rapide zunehmen...

Und? Jeglich ernsthafte Software wird niemals auf .NET setzen, weil die Performance immer niedriger ist als bei einer echten Programmierung. Nur für Tools, Panels und ähnliches Blabla ist .NET interessant. Und selbst da hat ATi einen RAM-Bedarf wie ein älteres Spiel hingezaubert.

Xmas

2004-09-27, 02:22:21

Leonidas

2004-09-27, 02:35:56

Wer meint, .NET wäre nur für "Blabla" interessant meint wohl auch dass man mit einem Schweizer Taschenmesser nur Flaschen öffnen kann.

Sicherlich nicht. Aber Du wirfst mit einem Schweizer Taschenmesser auch sicherlich nicht in einen Atomkrieg ziehen.

Insofern irritiert mich im ungekehrtem Maße Deine erstaunliche Abwiegelei gegenüber NET. Das ganze ist eine Vereinfachung für die Programmierer (für den Endanwender ist der Nutzen erst einmal 0), welches aber gleichzeitig mit einem höheren Ressourcenverbrauch einhergeht, was damit automatisch die Anwendungsfelder von NET einschränkt. Oder kann sich hier wer ein PHP oder ein Doom 3 auf Basis von NET vorstellen?

Ikon

2004-09-27, 02:40:24

Mir ist völlig egal ob ATI oder NVidia ihre CPs mit .NET, Java, Python oder sonstwas schreiben, solange es am Ende gut funktioniert.

Und wo bleibt die Effizienz dabei? Es ist schlichtweg Irrsinn soetwas "simples" wie ein ControlPanel mit .NET oder Java zu schreiben. Der Entwickler freut sich über den geringeren Aufwand und der Endnutzer starrt ungläubig auf den Task-Manager, der für das neue Panel mal eben 5 neue Dienste mit locker-flockigen 100MB Speicherbedarf anzeigt - von der CPU-Last ganz zu schweigen.

-> Das hat für mich nichts mit "gut funktionieren" zu tun.
Ich möchte .NET gar nicht grundsätzlich verurteilen - es hat seine sinnvollen Einsatzgebiete - aber hier ist es IMO völlig deplaziert.

Kennung Eins

2004-09-27, 03:30:06

Und wo bleibt die Effizienz dabei? Es ist schlichtweg Irrsinn soetwas "simples" wie ein ControlPanel mit .NET oder Java zu schreiben. Der Entwickler freut sich über den geringeren Aufwand und der Endnutzer starrt ungläubig auf den Task-Manager, der für das neue Panel mal eben 5 neue Dienste mit locker-flockigen 100MB Speicherbedarf anzeigt - von der CPU-Last ganz zu schweigen.

-> Das hat für mich nichts mit "gut funktionieren" zu tun.
Ich möchte .NET gar nicht grundsätzlich verurteilen - es hat seine sinnvollen Einsatzgebiete - aber hier ist es IMO völlig deplaziert.
Wenn Loghorn aber nunmal .NET verlangt ...

Falls es mal ein System gibt, in das .NET ordentlich integriert ist, (und auf dem es nicht nur aufsitzt wie momentan) bzw was ganz einfach darauf basiert, da macht es dann auch keinen Unterschied mehr, ob ein Control Panel mittels C++ oder C# geschrieben ist.

Nagilum

2004-09-27, 03:46:53

Oder kann sich hier wer ein PHP oder ein Doom 3 auf Basis von NET vorstellen?
Ja, die Realität kann sowas.

Nennt sich ASP.NET und performed - dank düsteren Voodoozaubers wie z.B. Kompilierung - besser als dein PHP. Managed DirectX liegt in vielen Bereichen bei ungefähr 90% einer Nicht-CLR Anwendung.

Hach, sind Verschwörungstheorien schön. :rolleyes:

Xmas

2004-09-27, 03:52:19

Sicherlich nicht. Aber Du wirfst mit einem Schweizer Taschenmesser auch sicherlich nicht in einen Atomkrieg ziehen.
Mit dem rostigen Dolch aber auch nicht.

Insofern irritiert mich im ungekehrtem Maße Deine erstaunliche Abwiegelei gegenüber NET. Das ganze ist eine Vereinfachung für die Programmierer (für den Endanwender ist der Nutzen erst einmal 0), welches aber gleichzeitig mit einem höheren Ressourcenverbrauch einhergeht, was damit automatisch die Anwendungsfelder von NET einschränkt.
Ich würde das nicht als Abwiegelei bezeichnen. Ich habe bisher Erfahrungen mit rund einem Dutzend Programmiersprachen auf vielen verschiedenen Ebenen gemacht, und dabei unzählige Fälle von unbegründeter "High-Level-Phobie" kennengelernt. Früher galt auch die Ansicht, mit C würde man gegenüber C++ effizientere Programme schreiben. Das stimmt nur noch in Teilbereichen. Dieselbe Entwicklung hat es bisher auf jeder Stufe gegeben.

"The Right Tool for the Right Job." Das impliziert aber nicht nur, das richtige Werkzeug zu verwenden, sondern auch die richtige Aufgabe zu definieren. ATIs CCC ist viel mehr als nur ein Control Panel. Dass es so viele Ressourcen verbraucht, liegt nicht daran dass es .NET nutzt, sondern dass es so programmiert ist. Das heißt noch lange nicht dass es mit .NET nicht möglich wäre ein sparsames Control Panel zu schreiben.

Oder kann sich hier wer ein PHP oder ein Doom 3 auf Basis von NET vorstellen?
Ein PHP auf Basis von .NET? Ist das ernst gemeint? Aber sicher doch, wieso denn nicht? Und auch bei einer kommerziellen high-end 3D-Engine ist meine Antwort ein klares Ja.

Xmas

2004-09-27, 04:00:29

Und wo bleibt die Effizienz dabei? Es ist schlichtweg Irrsinn soetwas "simples" wie ein ControlPanel mit .NET oder Java zu schreiben. Der Entwickler freut sich über den geringeren Aufwand und der Endnutzer starrt ungläubig auf den Task-Manager, der für das neue Panel mal eben 5 neue Dienste mit locker-flockigen 100MB Speicherbedarf anzeigt - von der CPU-Last ganz zu schweigen.

-> Das hat für mich nichts mit "gut funktionieren" zu tun.
Ich möchte .NET gar nicht grundsätzlich verurteilen - es hat seine sinnvollen Einsatzgebiete - aber hier ist es IMO völlig deplaziert.
Die Effizienz steckt in "gut funktionieren" mit drin. Ich sage ja auch nicht dass das CCC effizient ist. Nur dass es mir egal ist ob .NET, Java oder sonstwas wenn es gut funktioniert, und dass absolut nichts dagegenspricht dass es mit diesen Plattformen gut funktionieren kann.

Du kannst wohl kaum Anhand eines einzigen Programms die .NET Plattform verurteilen.

StefanV

2004-09-27, 09:28:26

Wen interesiert "nLite"?
Eigentlich jedem, der Windows nutzt und gerne einige Komponenten loswerden möchte oder aber der 'mal eben' ein paar Treiber integrieren möchte.

Und auch sonst gibt aber auch rein gar nichts, was mich dazu bewegen würde, .NET nutzen zu wollen...
Tjo, in diesem Fall denke ich eher, daß du keinen Schimmer hast, wohl aber Xmas oder Demirug, die ja nicht gerade schlecht über .NET reden, von daher dürfte dein 'anti .NET geplapper' nur haltloses geblubber sein.

Wenn es bis 2006 'rapide' (unverzichtbare?) Anwedungen geben soll, dann sollten sie wirklich langsam mal anfangen.
Womit??

BTW: Longhorn bietet ja gerade an, daß man SW mit .NET proggt.

Und by the Way, im 3DCenter & 3DCenter Forum (http://www.forum-3dcenter.org/vbulletin/showthread.php?t=167129) gibt's zu diesen Thema schon einen Thread, indem IMO auch schon alles zu diesem Thema gesagt wurde.
Tja, leider scheinst du nicht das zur Kenntnis genommen zu haben, was die ganzen Programmierer da gepostet haben.
Nur falls du es nicht weißt: Xmas gehört zu der Kategorie, die .NET am anderen Ende anwenden (könnten).

Also, Stefan, troll Dich dahin!
Hoffe inständig, dass diese ganze Sinnlos-Diskussion nicht wieder von vorne los geht.

Tja, Razor, zu 'nem flamewar gehören mindestens 2, wenn du nicht willst, das die ganze Diskussion hier weitergeführt wird, dann halt einfach die Klappe zu dem Thema, dann wird dieser Thread auch nicht zerfleddert.

Und was mir noch einfällt: The Inquerer?
:Kotz:
:D
Deine Meinung, die nicht unbedingt der Wahrheit entsprechen muss...

Tigerchen

2004-09-27, 09:31:48

Die Effizienz steckt in "gut funktionieren" mit drin. Ich sage ja auch nicht dass das CCC effizient ist. Nur dass es mir egal ist ob .NET, Java oder sonstwas wenn es gut funktioniert, und dass absolut nichts dagegenspricht dass es mit diesen Plattformen gut funktionieren kann.

Du kannst wohl kaum Anhand eines einzigen Programms die .NET Plattform verurteilen.

Kannst du mir mal verraten warum du den unglaublichen Resourcenverbrauch des CCC so beschönigst? Der BVB könnte auch Tabellenführer sein. Daß weder der BVB als auch das .net-basierte CCC trotz enormen Resourcenverbrauchs erfolgreich sind sollte einem schon zu denken geben.
Ich sehe es irgendwie nicht ein daß demnächst teure 4GByte RAM Pflicht sind nur damit die Firmen in Zukunft Treiber/Tools ganz billig von irgendeinem indischen Programmierlehrling zusammenklicken lassen können.

Exxtreme

2004-09-27, 09:48:09

Und wo bleibt die Effizienz dabei? Es ist schlichtweg Irrsinn soetwas "simples" wie ein ControlPanel mit .NET oder Java zu schreiben. Der Entwickler freut sich über den geringeren Aufwand und der Endnutzer starrt ungläubig auf den Task-Manager, der für das neue Panel mal eben 5 neue Dienste mit locker-flockigen 100MB Speicherbedarf anzeigt - von der CPU-Last ganz zu schweigen.

-> Das hat für mich nichts mit "gut funktionieren" zu tun.
Ich möchte .NET gar nicht grundsätzlich verurteilen - es hat seine sinnvollen Einsatzgebiete - aber hier ist es IMO völlig deplaziert.
Daß ATis CCC grad bissle langsam ist, liegt nicht an .NET selbst sondern an ATi. Vor allem ist das CCC viel mächtiger als sich die viele Leute hier nur annähernd vorstellen können. Und die meiste Performance und Speicher frisst die Preview-Funktion weg, die in der aktuellen Version nicht deaktiviert werden kann. TM hat aber versprochen, daß man diese deaktivieren können wird in einer späteren Version des CCC.

aths

2004-09-27, 09:51:11

Nur dass es mir egal ist ob .NET, Java oder sonstwas wenn es gut funktioniert, und dass absolut nichts dagegenspricht dass es mit diesen Plattformen gut funktionieren kann.Bei Java wäre ich skeptisch :)

[COLOR="#000088"]
Kannst du mir mal verraten warum du den unglaublichen Resourcenverbrauch des CCC so beschönigst? Das mach er in keinem Satz.

Ohne Borland VCL (z. B. in Delphi integriert) wäre kein aTuner möglich gewesen. Gibt es eine Art VCL, nur nicht von Borland sondern als absehbaren Standard, wäre es möglich mit dem kommenden Standard .Net kleinere EXE-Dateien zu schreiben.

Exxtreme

2004-09-27, 10:06:47

Bei Java wäre ich skeptisch :)

Java kann auch sehr flott sein. Nur die Java-eigene GUI-Bibliothek von SUN ist lahm ohne Ende. Ich habe bei mir unter Linux einen Bittorrent-Client, der in Java geschrieben wurde. Das Teil ist recht flott wenn es mal gestartet wurde.

Demirug

2004-09-27, 10:41:33

Ohne Borland VCL (z. B. in Delphi integriert) wäre kein aTuner möglich gewesen. Gibt es eine Art VCL, nur nicht von Borland sondern als absehbaren Standard, wäre es möglich mit dem kommenden Standard .Net kleinere EXE-Dateien zu schreiben.

Windows.Forms?

Eine .Net Exe ist im Regelfall eigentlich immer kleiner als eine vergleichbare Exe welche mit C++ erstellt wurde.

StefanV

2004-09-27, 10:49:18

Öhm, mächtiger, in wie Fern??

PS: meine Meinung ist, daß das CCC noch, öhm, 'etwas' beta ist und noch allerhand zur Finalen Version fehlt...

Demirug

2004-09-27, 10:51:09

Managed DirectX liegt in vielen Bereichen bei ungefähr 90% einer Nicht-CLR Anwendung.

Liegt sogar meist höher. Spätestens wenn man aus dem CPU Limit raus ist spielt es dann sowieso keine Rolle mehr.

Betrachtet man das ganze dann noch etwas übergeordnet wird die Bilanz für .net sogar noch besser. Spiele nutzen heute zu einem nicht unehrheblichen Teil Scripts. Bei einer .Net Anwendung kann man für diese Scripts eine der vielen .Net Sprachen benutzten. Da diese ebenfalls compiliert werden und kein zusätzlicher Layer zwischen Engine und Scriptsystem notwendig ist holt man hier sogar wieder Leistung rein.

Exxtreme

2004-09-27, 11:04:50

Öhm, möchtiger, in wie Fern??

Die Engine vom CCC ist sehr flexibel und gut erweiterbar.

Xmas

2004-09-27, 11:23:24

Kannst du mir mal verraten warum du den unglaublichen Resourcenverbrauch des CCC so beschönigst? Der BVB könnte auch Tabellenführer sein. Daß weder der BVB als auch das .net-basierte CCC trotz enormen Resourcenverbrauchs erfolgreich sind sollte einem schon zu denken geben.
Ich sehe es irgendwie nicht ein daß demnächst teure 4GByte RAM Pflicht sind nur damit die Firmen in Zukunft Treiber/Tools ganz billig von irgendeinem indischen Programmierlehrling zusammenklicken lassen können.
Kannst du mir bitte sagen wo du herausliest dass ich den Resourcenverbrauch des CCC beschönige?

Sumpfmolch

2004-09-27, 11:31:10

und wieviel arbeit ist das dann .net programme auf linux lauffähig zu machen ? ;)

Exxtreme

2004-09-27, 11:48:33

und wieviel arbeit ist das dann .net programme auf linux lauffähig zu machen ? ;)
Nicht viel wenn man auf Windows-spezifisches Zeugs verzichtet. =) MONO scheint recht kompatibel zu sein.

Ikon

2004-09-27, 12:28:36

Die Engine vom CCC ist sehr flexibel und gut erweiterbar.

Was das CCC dringend braucht ist nicht die Skalierbarkeit nach oben sondern nach unten :cool:

Coda

2004-09-27, 12:36:39

und wieviel arbeit ist das dann .net programme auf linux lauffähig zu machen ?
http://www.mono-project.com/

Wenn das Spiel dann noch auf OpenGL basiert, ziemlich wenig.

Aber bei Doom³ + x86 und .NET wäre ich auch vorsichtig. Die haben AFAIK gesagt, dass sie jetzt schon Probleme mit der Speicherfragmentierung haben, und das wird mit einem GC sicher nicht besser.

Exxtreme

2004-09-27, 12:38:53

Was das CCC dringend braucht ist nicht die Skalierbarkeit nach oben sondern nach unten :cool:
Wie gesagt, die meisten Resourcen frisst die Preview weg. Sie wird aber komplett deaktivierbar sein.

Demirug

2004-09-27, 12:54:36

http://www.mono-project.com/

Wenn das Spiel dann noch auf OpenGL basiert, ziemlich wenig.

Aber bei Doom³ + x86 und .NET wäre ich auch vorsichtig. Die haben AFAIK gesagt, dass sie jetzt schon Probleme mit der Speicherfragmentierung haben, und das wird mit einem GC sicher nicht besser.

Ich weiss ja nicht sicher wie andere GCs arbeiten aber der von .net ist im Bezug auf Speicherfragmentierung die Ideallösung weil er die Löcher im Objektheap einfach rausschieb. Auf jeden Fall hatten wir bei Serveranwendungen (24/7) mit dem Heapmanager des VC mehr ärger in diesem Bereich als mit einer ähnlichen .net Anwendung.

IIRC wurde bei D3 aber eher von der Speichermenge gesprochen weil man versucht immer zwei Levels gleichzeitig im Speicher zu halten.

LordDeath

2004-09-27, 13:02:08

so, wie es aussieht, wird .net immer wichtiger! würde es sich lohnen, jetzt anzufangen, diese sprache zu erlernen? wieviel müsste ich da für ne gute entwicklungsumgebung hinblättern?

StefanV

2004-09-27, 13:04:14

Öhm, für .NET brauchst du keine Sprache erlernen, das kann mit vielen Sprachen umgehen ;)

LordDeath

2004-09-27, 13:07:17

ok, jetzt check ich nix määhr :D

robbitop

2004-09-27, 13:07:48

Mal eine ganz blöde Frage:

was bringt mir als normalen Endanwender ein .NET Panel?
(Mir ist Klickibunti völlig egal. Mich interessiert nur die Funktionalität)

StefanV

2004-09-27, 13:14:03

ok, jetzt check ich nix määhr :D
Bei .NET kannst weiter z.B. in C schreiben, auch die Kombination von mehreren Sprachen bei unterschiedlichen 'Plug Ins' ist möglich.

Du musst dich nur noch auf die neuen Gegebenheiten von .NET einstellen :)

Exxtreme

2004-09-27, 13:18:14

ok, jetzt check ich nix määhr :D
.NET ist ein Framework. Es ist vergleichbar mit der Java Virtual Machine. Man kann mit sehr vielen Programmiersprachen für .NET programmieren. Man braucht nur einen entspr. Compiler.

LordDeath

2004-09-27, 13:21:23

@robbitop: entwicklern ist es so möglich, softwarelösungen schneller entwickeln zu können! und diesen einfluss wirst auch du als endanwendern irgendwie wahrnehmen können!
@Stefan Payne & Exxtreme: ok, habs gaycheckt :D
wie groß ist eigentlich das .Net Paket für entwickler?

Exxtreme

2004-09-27, 13:22:39

Wer sich die IDEs für's .NET-Framework anschauen will, hier gibt's die Betas von MS:
http://lab.msdn.microsoft.com/express/

Sie sind komplett kostenlos und nicht laufzeitbeschränkt.

StefanV

2004-09-27, 13:22:47

Mal eine ganz blöde Frage:

was bringt mir als normalen Endanwender ein .NET Panel?
(Mir ist Klickibunti völlig egal. Mich interessiert nur die Funktionalität)
Ganz einfach:

Solche Sicherheitslöcher, wie sie der IE besitzt, sind mit .NET nicht mehr möglich :devil:
Und der Speicher wird nicht mehr wirklich fragmentiert, wodurch man nach einigen Tagen mehr nutzbaren Speicher hat...

Exxtreme

2004-09-27, 13:25:07

Mal eine ganz blöde Frage:

was bringt mir als normalen Endanwender ein .NET Panel?
(Mir ist Klickibunti völlig egal. Mich interessiert nur die Funktionalität)
Der Anwender merkt davon eigentlich nichts. =) Ausser, daß die Software nicht mehr anfällig für Bufferoverflows ist.

LordDeath

2004-09-27, 13:25:24

Wer sich die IDEs für's .NET-Framework anschauen will, hier gibt's die Betas von MS:
http://lab.msdn.microsoft.com/express/

Sie sind komplett kostenlos und nicht laufzeitbeschränkt.

geil! ich mach mir schnell ein .net passport und saug mir mal die visual basic exrpess runta :D

Gast

2004-09-27, 13:33:16

Und? Jeglich ernsthafte Software wird niemals auf .NET setzen, weil die Performance immer niedriger ist als bei einer echten Programmierung. Nur für Tools, Panels und ähnliches Blabla ist .NET interessant. Und selbst da hat ATi einen RAM-Bedarf wie ein älteres Spiel hingezaubert.
und das kommt auch noch von dir, einem von der 3dcenter crew *kopfschüttel*. ich weiß daß jeder seine eigenen bereiche bezüglich der kopetenz hat, und genau deshalb sollte man auch keinen mist schreiben wenn man keine ahnung davon hat. das mit "ernsthafte software" ist ja noch lustig, ich stell mir darunter z.b. die steuerungssoftware für ein AKW vor, ich weiß nicht was du darunter verstehst. aber das mit "echter programmierung" ist ja wirklich DAS indiz daß du keinen schimmer hast; was bitte ist denn echte programmierung ? direkt einser und nullen schreiben, ja das ist echte programmierung, oder ? FYI, das was du warscheinlich meinst heißt nativer code (im gegensatz zum managed code in .NET).
"tools, panels und ähnliches blabla" kann man mit jeder entwicklungumgebung welche GUIs unterstützt machen, nicht das GUI der anwendung ist das argument für .NET (es gibt zig mediaplayer und messenger und sonstiges zeug welches ihre eigene "geskinnte" GUI hat und nicht .NET nutzt, ATI selber nutzt Windowblinds für´s skinning). der vorteil ist daß .NET aufgeräumter ist, und verschiedene sprachen zur verfügung stellt, also wird der einstieg und der entwicklungsprozess mit .NET stark vereinfacht.
und daß CCC so lahm und groß ist, ist einzig und allein ATI´s schuld. natürlich steigt der ressourcenverbrauch mit .NET um einige MB, da ja die runtime bibliotheken zusätzlich zu deiner "echt programmierten" software geladen werden müssen, aber der ressourcenhunger des CCC (davon abgesehen daß es auch sonst nur mist ist) liegt einzig und allein an ATI´s programmierkünsten, mit denen sie uns ja seit jahren durch den kaum vorhandenen fortschritt überzeugen. (anstatt jetzt einfach zu antworten, erst mal bedenken daß hier das UI gemeint ist, und nicht der treiber, denn es sind zwei verschiedene dingen, und daß scheinen einige immer noch nicht zu kapieren; ja, beim treiber haben sie in den letzten jahren tatsächlich große fortschritte gemacht)

als schlußfolgerung für die ganz langsamen also nochmal:
GRAFIKTREIBER UND CONTROLPANEL/UI SIND VERSCHIEDENE DINGE. nur das letztere ist und kann mit .NET geschrieben sein. treiber mit .NET sind mit jetzigen Windows versionen nicht möglich, erst ab Longhorn wird es möglich sein treiber im user-mode, also z.b. mit .NET zu schreiben

.NET ist nicht für die ähm...anwenderfreundliche, bunte, geskinnte oberfläche z.b. des CCC verantwortlich, das geht mit was auch immer, siehe andere geskinnte anwendungen die nix mit .NET zu tun haben

daß CCC so lahm und ineffizienz und im allgemeinen mist ist, liegt an ATI alleine, und nicht an .NET.

MuLuNGuS

2004-09-27, 13:41:00

Öhm, für .NET brauchst du keine Sprache erlernen, das kann mit vielen Sprachen umgehen ;)

lolol...

nur weil es mit diversen sprachen umgehen kann braucht er keine zu lernen, das ja mal geil.
überhaupt ist C# das optimum um .NET anwendungen zu schreiben da es quasi die kernsprache von .NET ist.

c++ ist eine geile kiste keine frage, aber c++ managed code ist ja wohl zum abgöbeln und indiskutabel.

übringens, das game "Arena Wars" tadaa.. ist in C# geschrieben.

LordDeath

2004-09-27, 13:41:42

nach ich von ms die mail mit aktivierungslink bekam und auf continue klickte, damit ich es downloaden kann stand da nur noch: The system cannot find the file specified. :(

edit: nachdem ich es nochmal versucht habe ging der normale download link direkt! ich lad jetzt ne 2,4mb große datei mit 4kb/s runter :D
ist wohl wieder mal ein webinstaller...

robbitop

2004-09-27, 13:42:15

hrn also viel Wind und Hype um nichts...

LordDeath

2004-09-27, 13:45:20

hrn also viel Wind und Hype um nichts...

du bezeichnest es als nichts, wenn ein grakatreiber einer großen firma von grund auf neu programmiert wird?

Exxtreme

2004-09-27, 13:49:26

du bezeichnest es als nichts, wenn ein grakatreiber einer großen firma von grund auf neu programmiert wird?
AFAIK betrifft das nur das Panel, nicht aber dne GraKa-Treiber selbst.

StefanV

2004-09-27, 13:50:05

StefanV

2004-09-27, 13:54:06

hrn also viel Wind und Hype um nichts...
Stimmt, nur ein paar Sicherheitslücken von Windows werden geschlossen und ein paar 'Steinzeitliche Elemente' entsorgt, das ist kein großer Schritt :rolleyes:

Sorry, aber das sehen einige andere anders, die es eigentlich wissen sollten...

MuLuNGuS

2004-09-27, 14:05:01

nun,

kleine .NET anwendungen kommen immer schnell schlanker daher aber sobald sie etwas anwachsen und eine menge ressourcen mitbringen verschwindet dieser unterschied. mit 10x kommste auch bei einer kleinen anwendung nicht hin. (das framework darf man auch nicht vergessen)

nlite ist sehr nett, aber nichts was man nicht auch mit der winapi machen könnte.(allerdings mit .NET sehr komfortabel)

aths

2004-09-27, 14:08:30

Insofern irritiert mich im ungekehrtem Maße Deine erstaunliche Abwiegelei gegenüber NET. Das ganze ist eine Vereinfachung für die Programmierer (für den Endanwender ist der Nutzen erst einmal 0), welches aber gleichzeitig mit einem höheren Ressourcenverbrauch einhergeht, was damit automatisch die Anwendungsfelder von NET einschränkt. Oder kann sich hier wer ein PHP oder ein Doom 3 auf Basis von NET vorstellen?Abgesehen von meiner Abneigung gegen .Net wäre aus meiner Sicht hier trotzdem einiges richtigzustellen. Mit vereinfachter Programmierung kann Software schneller und kostengünstiger realisiert werden. Die gesteigerte Produktivität kann dann gleichermaßen zu einem höheren Einkommen des Softwareentwicklers wie auch in niedrigeren Preisen für Softwareentwicklung resultieren.

Der erhöhte Ressourcenverbrauch ist angesichts der technischen Entwicklung zu verschmerzen. .Net enthält Sicherheitsmechanismen, die z. B. zuverlässig Bereichsüberschreitung bei Arrayindizierung verhindern. Durch das Verhindern von Pufferüberläufen sind automatisch die gängigen Softwarelöcher für Angriffe geschlossen.

Was Doom3 angeht könnten bestimmte Teile der Engine durchaus in Managed C++ (oder C#) geschrieben werden, ohne dass das negative Auswirkungen auf die Performance hat.

LordDeath

2004-09-27, 14:10:15

MuLuNGuS

2004-09-27, 14:12:18

Mit vereinfachter Programmierung kann Software schneller und kostengünstiger realisiert werden.

eben eben,

ich finde man sollte die programmierung nicht als "einfacher" sondern als "mehr komfortabel" bezeichnen.

Benedikt

2004-09-27, 14:13:16

btw: der webinstaller hat schon 247kb von 286647kb! gibts da keine möglichkeit, dass schneller hinzukriegen? oder hab ich jetzt ne blöde arschkarte gezogen?
Meinst du jetzt die .net-Runtime, das Programm, das du dir gerade lädst?
Ich würde mir irgend 'n Computerheft mit CD am Kiosk kaufen, ist doch eh schon fast überall drauf, die Runtime.

MFG,
B. W.

StefanV

2004-09-27, 14:14:56

Nein, er meint die Developer Version, die ist etwas größer als das Framework ;)

robbitop

2004-09-27, 14:18:13

Treiber =! Panel

wenn ich als Enduser daraus keinen Vorteil ziehe, kanns mir eigentlich egal sein.
Deshalb verstehe ich den Hype nicht. Aber schön für die Entwickler.

Ach jetzt ist mein Panel eine Sicherheitslücke? *gg*
Wie stehts denn mit ICQ, IE oder Outlook?
Ein vernünftiger Mensch nutzt andere Programme und eine brauchbare Firewall, das Panel sollte das geringste Problem darstellen.

Sorry, aber das sehen einige andere anders, die es eigentlich wissen sollten...
Stefan, entweder du nutzt eigene Argumente oder du lässt besser das Diskutieren. Ist schön wie du anderen Leuten nachplappern kannst...

LordDeath

2004-09-27, 14:18:50

Meinst du jetzt die .net-Runtime, das Programm, das du dir gerade lädst?
Ich würde mir irgend 'n Computerheft mit CD am Kiosk kaufen, ist doch eh schon fast überall drauf, die Runtime.

MFG,
B. W.

also der webinstaller muss teile saugen:
-.net framework 2.0 beta
-visual basic 2005 express edtion beta
-microsoft msdn express libary 2005 beta
-sql server 2005 express edition beta

alle zusammen sind 286mb groß!
derzeit hab ich gradmal 373kb des .net frameworks 2.0 beta und ich denke nicht, dass diese teile irgendwie bei irgendwelchen magazin cds enthalten sein werden...

vielleicht sind ja derzeit zuviele leutz das am saugen? aber in amerika sollte es doch um diese uhrzeit nicht so überlastet sein, oder?

StefanV

2004-09-27, 14:27:00

D-Swat

2004-09-27, 14:28:57

also, dass programme mit .net kleiner werden ist schon klar! nur ab wann es sich lohnt, ist ne andere sache! wäre ein programm ohne .net trotzdem kleiner als die gesammte .net runtime, dann ist schonmal dieser vorteil weg! wenn jedoch ganze anwendungspakete wie office auf .net basieren würden, hätte man schon mehr davon!

btw: der webinstaller hat schon 247kb von 286647kb! gibts da keine möglichkeit, dass schneller hinzukriegen? oder hab ich jetzt ne blöde arschkarte gezogen?

Es gibt auch die Möglichkeit es manuell zu Installieren, dabei must du dir dann .NET 2.0 Beta und Visual Basic 2005 Express beta downloaden und selbst installieren.

Wo du die Links findest, steht auf der Seite, wo man auch den Web Installer downloaden kann.

http://lab.msdn.microsoft.com/express/vbasic/default.aspx
Dort nicht auf 'Download Now' sonder am rechten Rand auf 'Having trouble downloading? Click here for manual installation instructions.'
Dort gibt es dann direktlinks zu den einzelnen Downloads.

Wer sich die IDEs für's .NET-Framework anschauen will, hier gibt's die Betas von MS:
http://lab.msdn.microsoft.com/express/

Sie sind komplett kostenlos und nicht laufzeitbeschränkt.

Soweit ich weis, werden die Express Versionen später nicht kostenlos sein und die Beta Versionen sind afair auf 365 Tage beschränkt.
Hab grad keins dieser Express Produkte zur Hand, aber ich glaub unter 'Help' irgendwo was über die 365 Tage gelesen zu haben. Kann das einer mal nachschauen?

robbitop

2004-09-27, 14:37:55

@Robbi

Dann sag doch, was deiner Meinung nach so schlecht am .NET Framework ist?!
Abgesehen davon, daß mans sich runterladen und installieren muss und natürlich die Größe von etwa 25MB (+10MB Patch).

PS: du solltest auch nicht vergessen, daß du dich auch oft genug auf andere beziehst, womit deine 'Bitte' eigentlich überflüssig ist...
Von daher...

Wo sage ich, dass es schlecht ist?
Ich sage nur, dass ich den weltweiten Hype nicht nachvollziehen kann.

Es ist ein Unterschied ob man das permanent tut oder gelegentlich und auf welche Art man das tut. Ich sehe da schon einen Unterschied. Du diskutierst in diesem Thread nicht oder kaum mit eigenen Argumenten.
P.S. Kritik =! Bitte (aber du musst selbst wissen, ob du Kritik aufnimmst oder sie abblockst)

LordDeath

2004-09-27, 14:41:57

@D-Swat: danke! mit 90kb/s full zu ziehen ist schon sexier :D
ich hätte nicht gedacht, dass die express edition von visual basic nur 34mb groß sein soll! ich glaub das hier ist ein gutes beispiel dafür, wie gut das framework umfangreiche programme schrumpfen lassen kann!

werden in longhorn die windows systemdateien auch auf .net basieren? oder wär das unsinn?

MuLuNGuS

2004-09-27, 14:43:07

von welchem weltweiten hype redest du?

@LordDeath

auf jeden fall soll es dort ein fester bestandteil sein.

LordDeath

2004-09-27, 14:50:31

@LordDeath

auf jeden fall soll es dort ein fester bestandteil sein.

das ist es doch schon in windows server 2003! klar, man kann das framework auch bestimmt nachträglich entfernen wie mit programmen wie nlite, aber das wär nicht sinn der sache! daher finde ich das gemecker einige leutz gegen .net nicht so wirklich sinnvoll!

das einizge, was mich ärgert ist, dass microsoft lieber was eigenes entwicklt um weiter expandieren zu können als etwas vorhandenes wie java zu unterstützten!
das haben die schon damals mit opengl gemacht, indem sie direct3d entwickelt haben! ohne solcher konkurrenzprojekte wären wir heute mit nur einem produkt viel weiter als wir es jetzt sind!

robbitop

2004-09-27, 14:50:55

ich lese täglich viel News in der weltweiten Internetpresse.
Die Authoren können sich kaum vor Begeisterung über das supertolle CCC .NET Panel retten.

-> "Muss ich auch haben" ist der Effekt der beim Lesen eintritt.
Ohne zu hinterfragen "warum" und "was bringt mir das"

Versteht mich nicht falsch, ich will NET nicht schlecht machen. Aber ich sehe das im Moment einfach nur von der Endanwenderseite.

MuLuNGuS

2004-09-27, 15:25:39

tja,

mir wäre es lieber gewesen wenn sie eine neue winapi entwickelt hätten die man schön mit c++ nutzen könnte.

aber nein, sie basteln c#...auch wenn das ding nicht schlecht ist.

zu GC hat der erfinder von c++ auch schon mal ein paar worte losgelassen, auch das ist da möglich.

Benedikt

2004-09-27, 15:28:26

das ist es doch schon in windows server 2003! klar, man kann das framework auch bestimmt nachträglich entfernen wie mit programmen wie nlite, aber das wär nicht sinn der sache! daher finde ich das gemecker einige leutz gegen .net nicht so wirklich sinnvoll!

das einizge, was mich ärgert ist, dass microsoft lieber was eigenes entwicklt um weiter expandieren zu können als etwas vorhandenes wie java zu unterstützten!
das haben die schon damals mit opengl gemacht, indem sie direct3d entwickelt haben! ohne solcher konkurrenzprojekte wären wir heute mit nur einem produkt viel weiter als wir es jetzt sind!
Was mich schon immer interessiert hat: Auch bei WindowsXP ist mir direkt nach der Installation damals gleich ein Ordner namens WinSxS aufgefallen, wo ja Sachen wie GDIplus usw. enthalten sind. Ich weiß, dass bei WinXP keine .net-Runtime standardmäßig installiert ist, aber was ist dann dieser Ordner, war/ist das eine Vorstufe zu .net? AFAIK wurde ja WinXP 2001 released, oder - da gabs doch noch gar kein .net in dem Sinn!?

MFG,
B. W.

Exxtreme

2004-09-27, 15:28:35

Versteht mich nicht falsch, ich will NET nicht schlecht machen. Aber ich sehe das im Moment einfach nur von der Endanwenderseite.
Von der Endanwenderseite her bringt .NET im Großen und Ganzen erstmal nichts. Ausser villeicht, daß die Programme schon von der ersten Version an "fertig" sind. :)

robbitop

2004-09-27, 15:30:47

Von der Endanwenderseite her bringt .NET im Großen und Ganzen erstmal nichts. Ausser villeicht, daß die Programme schon von der ersten Version an "fertig" sind. :)

Ah, siehst du, das ist schonmal was. :up:

seahawk

2004-09-27, 16:35:49

Von der Endanwenderseite her bringt .NET im Großen und Ganzen erstmal nichts. Ausser villeicht, daß die Programme schon von der ersten Version an "fertig" sind. :)

Das wurde schon zu oft versprochen, als ich das jemals glauben werde.

Für den Endanwender sehe ich momentan keinen Vorteil. Auch hinsichtlich möglicher Sicherheitslücken bin ich sehr vorsichtig, es hat zwar nicht die heutigen, aber ob sich aus .net nicht andere ergeben, das wage ich nicht zu beurteilen.

robbitop

2004-09-27, 17:17:34

LordDeath

2004-09-27, 18:02:06

@Benedikt: also ich hab kein plan, was das für files sind! ich hab auch das framework schon drinne und bei mir hat windows die files schon mit der datenträgerbereinung komprimiert, weil über 50 tage auf diese nicht zugegriffen wurde!
@robbitop: auf jeden ist das profilsystem von matrox super! aber ich glaube nicht, dass man auch dafür unbedingt .net braucht! es wäre auch so möglich! aber jetzt, wo nvidia mal das gesamte panel von neu progt, könnte die es ja nebenmal bei so einbauen *träum* :D

Xmas

2004-09-27, 18:11:08

ich weiss zwar nicht ob das mit .NET zusammenhängt, aber Matrox war bisher der einzige IHV, der ein vernünftiges Gameprofilsystem realisieren konnte.
Profil einstellen für das jeweilige Spiel und beim Starten des Spiels wurde es automatisch geladen. Das war praktisch. Alles andere war nur umständlich.
Das wäre auf jeden Fall für mich eine Entwicklung die mich umsteigen lassen würde.
Solche Profile hat NVidia doch AFAIK auch?

Man sollte auch beachten, dass der "Speicherverbrauch" von GC-Anwendungen nicht mit dem "normaler" Anwendungen zu vergleichen ist. Wenn von 1GiB Speicher die Hälfte frei sind, dann besteht kein allzu großer Bedarf dass der Garbage Collector häufig einschreitet. Mehr ungenutzter Speicher macht Anwendungen nicht schneller.

(del)

2004-09-27, 18:27:34

Die allgemeine Abneigung .NET gegenüber ist das größte Mißverständnis der letzten 10 Jahre in der IT-Branche.

Zum Thema: Ich finde es schön, dass nVidia nun wahrscheinlich bald auch ein .NET Control Panel entwickelt. Konkurrenz belebt schliesslich das Geschäft. Davon profitieren ATI-User gleichermassen wie nVidia-User.

zeckensack

2004-09-27, 18:59:25

Solche Profile hat NVidia doch AFAIK auch?Ja.
Und PowerVR.
Und ich.

Das ist auch nicht soo schwierig. Ich verstehe garnicht, warum ATI das nicht gleich vernünftig gelöst hat. Die jetzige Implementierung der Profile ist viel zu umständlich.

zeckensack

2004-09-27, 19:03:35

Meine Meinung:

a) GEIL
b) ENDLICH :)

Ein .NET Panel hat viele Vorteile, u.A. kann mans wesentlich übersichtlicher hinbekommen...a)Inwiefern geil?
b)Du hast also darauf gewartet?

Ein .NET-Panel sollte theoretisch kleiner sein, und früher bugfrei und stabil laufen (weil der Entwicklungsaufwand verringert wird). Dass das praktisch nicht so sein muss, hat ATI ja bereits eindrucksvoll demonstriert.

"Übersichtlich" ist nur eine Frage des GUI-Designs, nicht eine Frage der Programmierumgebung, mit dem dieses Design letztlich umgesetzt wurde.

robbitop

2004-09-27, 19:11:27

alle haben diese Profile und alle stellen sich an wie die letzten Idioten.
Nur MGA hat das AFAIK brauchbar gelöst. Setting einstellen und vergessen.
Sobald das Spiel irgendwann mal gestartet wird, läd der Treiber das Setting.
Bei ATi/NV muss man in das panel und die Application von dort aus starten oder aber das profil dort laden und dann das Game starten. Mit Gameerkennung war da bisher noch gar nichts.

mapel110

2004-09-27, 19:14:44

robbitop

2004-09-27, 19:19:56

mapel110

2004-09-27, 19:46:48

funktioniert das Ganze auch mit 4xS oder 2x2SSAA? [kann man lediglich über aTuner oder in der Registry einstellen]

nur AA-modi, die du auch im panel siehst. ;(
weiss nit, ob man die profile noch irgendwie modifizieren kann, da müsste man mal Razor fragen. :)

StefanV

2004-09-27, 19:50:28

a)Inwiefern geil?
b)Du hast also darauf gewartet?

Ein .NET-Panel sollte theoretisch kleiner sein, und früher bugfrei und stabil laufen (weil der Entwicklungsaufwand verringert wird). Dass das praktisch nicht so sein muss, hat ATI ja bereits eindrucksvoll demonstriert.

"Übersichtlich" ist nur eine Frage des GUI-Designs, nicht eine Frage der Programmierumgebung, mit dem dieses Design letztlich umgesetzt wurde.
a) u.A. weniger 'Chaos' im 'normalen' Panel...
b) jap, seit dem ich meine Parhelia abgegeben hab, warte ich auf .NET Panels von anderen Herstellern...

zum Rest:

Naja, es kommt immer drauf an, wie die Hersteller das 'hinbiegen', wenn mans ordentlich macht (siehe Matrox), dann kann ein .NET Panel richtig gut werden, vorallendingen da sich die Entwickler dabei voll austoben könnten, was das Design betrifft.

Ok, die 'Firmenfarbe' hilft MGA ein wenig ;)

grakaman

2004-09-27, 19:54:58

Sicherlich nicht. Aber Du wirfst mit einem Schweizer Taschenmesser auch sicherlich nicht in einen Atomkrieg ziehen.

Insofern irritiert mich im ungekehrtem Maße Deine erstaunliche Abwiegelei gegenüber NET. Das ganze ist eine Vereinfachung für die Programmierer (für den Endanwender ist der Nutzen erst einmal 0), welches aber gleichzeitig mit einem höheren Ressourcenverbrauch einhergeht, was damit automatisch die Anwendungsfelder von NET einschränkt. Oder kann sich hier wer ein PHP oder ein Doom 3 auf Basis von NET vorstellen?

Was meinst du mit PHP? Den Murks, woraus dein "Profiforum" besteht? :lol:

LordDeath

2004-09-27, 19:57:49

ok, hab jetzt mal mir das neue visual basic angeguckt und hab nen dicken gekriegt :D
ist für mich die einfachste sprache überahaupt, die ich nie vergessen kann :D
auch wenn ich visual basic das letzte mal in version 6 gesehen habe finde ich mich sofort wieder zurecht und alles ist voll easy! und in den ersten schritten kann man sich anzeigen lassen, wie man in 5 minuten einen eigenen internet browser "zusammenklicken" kann. und kompiliert ist das ganze grad mal 24kb groß!
ich hoffe mal, nvidia, ati und viele andere hersteller werden in zukunft ebenfalls auf .net umsteigen! ich find das einfach nur geil, was es aus visual basic gemacht hat!
nur braucht man jetzt .net framework 2.0beta, um diesen browser starten zu können :D

StefanV

2004-09-27, 19:59:10

und das funktioniert? einfach so?
hrn ich habe dem wohl zu sehr misstraut.

Sorry for labering Bullshit ;(

funktioniert das Ganze auch mit 4xS oder 2x2SSAA? [kann man lediglich über aTuner oder in der Registry einstellen]
Öhm, Robbi, warum probierst das nicht selbst aus??

Du hast doch eine nV3x, oder ist sie dir abgeraucht??

LordDeath

2004-09-27, 19:59:59

Was meinst du mit PHP? Den Murks, woraus dein "Profiforum" besteht? :lol:

1. flameing zeigt mangelndes selbstwertgefühl an
2. du hast erst das recht zu meckern, wenn du allen beweisen kannst, dass du es besser kanst :P
3. Leonidas ist cool, also mach ihn bitte nicht grundlos an

robbitop

2004-09-27, 20:01:53

Öhm, Robbi, warum probierst das nicht selbst aus??

Du hast doch eine nV3x, oder ist sie dir abgeraucht??

Nein das Board ist es :-(

grakaman

2004-09-27, 20:14:29

1. flameing zeigt mangelndes selbstwertgefühl an
2. du hast erst das recht zu meckern, wenn du allen beweisen kannst, dass du es besser kanst :P
3. Leonidas ist cool, also mach ihn bitte nicht grundlos an

Ich brauch hier gar nichts zu beweisen. Jeder, der sich ernsthaft damit beschäftigt, weiß das das einfach nur Müll ist, riesen großer architektonischer Softwaremüll. Wer PHP+MySql fährt, sollte hier nicht großschnäuzig von professionell daherfaseln.

LordDeath

2004-09-27, 20:25:50

ok, deine meinung! aber bitte bleiben wir ontopic! php und mysql können wo anders niedergemacht werden ;)

Demirug

2004-09-27, 20:52:13

robbitop, schau mal: http://www.forum-3dcenter.org/vbulletin/showthread.php?t=172564

Quasar

2004-09-27, 21:01:37

ich lese täglich viel News in der weltweiten Internetpresse.
Die Authoren können sich kaum vor Begeisterung über das supertolle CCC .NET Panel retten.
Die Frage ist nun, ob das für/gegen das neue Panel von ATi spricht oder eher für/gegen diese Autoren, denen ein Panel offenbar so wichtig zu sein scheint.

r@h

2004-09-27, 21:44:10

Eigentlich jedem, der Windows nutzt und gerne einige Komponenten loswerden möchte oder aber der 'mal eben' ein paar Treiber integrieren möchte.Ich halt's da lieber mit XPLite(pro), welches all das bietet und eben nicht auf .NET setzt... wie im übrigen alle anderen 'vernünftigen' Proggis auch.

Un ein paar Treiber in 'ne Install-CD zu integrieren ist doch nun wirklich nicht schwer...

Deine Meinung, die nicht unbedingt der Wahrheit entsprechen muss...Dito!
:D

Razor

r@h

2004-09-27, 21:50:25

@robbitop: entwicklern ist es so möglich, softwarelösungen schneller entwickeln zu können! und diesen einfluss wirst auch du als endanwendern irgendwie wahrnehmen können!Wie denn das?

Ist das, was ATI da abgeliefert ein Beispiel davon?
Mega-Resourcen-Fresser mit ordentlich Bugs drin?
Na ja, aber immerhin ist's schnell zusammen geklatscht worden...

Ja, der Anwender hat wirklich viel von so etwas.
*grunz*

Razor

r@h

2004-09-27, 21:54:55

Achja, dieses Programm ist etwa ein 3/4MB groß, ohne .NET wäre es vermutlich um ein vielfaches größer (mein Tip: etwa das 10 Fache).XPLite ist gerade mal 800kB groß...
Und braucht selbstredend keinen völlig überzogenen 'Unterbau'.

Razor

r@h

2004-09-27, 22:01:06

Dann sag doch, was deiner Meinung nach so schlecht am .NET Framework ist?!
Abgesehen davon, daß mans sich runterladen und installieren muss und natürlich die Größe von etwa 25MB (+10MB Patch).Anders herum wird ein Schuh daraus...
Um mir irgend etwas auf den Rechner zu ballern brauche ich einen Grund!
Nicht einen, um es nicht zu tun.

Überflüssige Dinge stören mich halt.
Auch gibt es sehr viel 'schlankere' Lösungen, als .NET...
(und mit 'schlank' meine ich jetzt lange nicht nur den Umfang in Bytes ;-)

Razor

StefanV

2004-09-27, 22:04:21

Nur mal so, razor, warst du es nicht, der weiter vorn das gepostet hat:

Hoffe inständig, dass diese ganze Sinnlos-Diskussion nicht wieder von vorne los geht.

Und machst du nicht das, was du da bemängelt hast?!
Solltest du es nicht lieber selbst erstmal besser machen, bevor andere kritisierst?!

r@h

2004-09-27, 22:07:52

und das funktioniert? einfach so?
hrn ich habe dem wohl zu sehr misstraut.

Sorry for labering Bullshit ;(

funktioniert das Ganze auch mit 4xS oder 2x2SSAA? [kann man lediglich über aTuner oder in der Registry einstellen]Jo, klar!
Demirug hat dazu gerade was im NV-Forum geschrieben.
Mit der NVApps.xml lassen sich im übrigen noch ganz andere lustige Dinge anstellen...
;)

Razor

r@h

2004-09-27, 22:14:33

Nur mal so, razor, warst du es nicht, der weiter vorn das gepostet hat:

Und machst du nicht das, was du da bemängelt hast?!
Solltest du es nicht lieber selbst erstmal besser machen, bevor andere kritisierst?!Wenn Du hier nicht so einen Müll verzapfen würdest, sähe ich mich nicht dazu gezwungen.
Hast Du eigentlich auch nur ein einziges eigenes Argeument gebracht?
Oder ist 'nLite' Dein einziges Argument?

By the way... bist Du tatsächlich der Meinung, dass die Form eines Panels oder dessen Funktionalität etwas mit der Entwicklungsumgebung zu tun hat? Mann oh mann...

Razor

LordDeath

2004-09-27, 22:19:02

Wie denn das?

Ist das, was ATI da abgeliefert ein Beispiel davon?
Mega-Resourcen-Fresser mit ordentlich Bugs drin?
Na ja, aber immerhin ist's schnell zusammen geklatscht worden...

Ja, der Anwender hat wirklich viel von so etwas.
*grunz*

Razor

eine guter grundsatz ist noch lange keine garantie dafür, dass keine scheiße mehr gebaut werden kann! die haben .net nur für optische spielereien benutzt in diesem release, aber vielleicht einige vorbereitungen für neue features gemacht! da müssen wir noch abwarten!

schon damals als winxp rauskam meinte ein bekannter zu mir, dass es so stabil wär, da könnte man nix falsch machen! und ich garantiere ihm, das teil innerhalb von ner halben stunde zu schrotten!
nach 5 minuten konnte man schonmal nicht mehr im normalmodus booten ^^

also .net ist noch lange keine garantie für super programme! der devs haben immer noch die verantwortung, ein gutes programm abzuliefern!

Adam D.

2004-09-27, 22:26:21

Hört doch mal auf, euch zu zoffen :( ;(

r@h

2004-09-27, 22:27:03

eine guter grundsatz ist noch lange keine garantie dafür, dass keine scheiße mehr gebaut werden kann! Das Problem ist nur, dass man solch eine 'Scheiße' sehr viel schneller (i.e. unüberlegter) auf den Markt bringen kann...

schon damals als winxp rauskam meinte ein bekannter zu mir, dass es so stabil wär, da könnte man nix falsch machen! und ich garantiere ihm, das teil innerhalb von ner halben stunde zu schrotten!
nach 5 minuten konnte man schonmal nicht mehr im normalmodus booten ^^WinXP ist das stabilste und gleichermaßen felxibelste OS, welches je das Licht der Welt erblickte (OK, war jetzt ein wenig theatralisch ;-), aber immun gegen Dummheit ist es ganz sicher nicht.

also .net ist noch lange keine garantie für super programme! der devs haben immer noch die verantwortung, ein gutes programm abzuliefern!Und wenn man jetzt noch im Hinterkopf behält, dass .NET dem Endanwender auch noch absolut keinen Vorteil bringt, sondern angedenk der wenigen Ausnahmen eher genau das Gegenteil... wird man daran doch wohl kritik üben dürfen, oder etwa nicht?

Razor

LordDeath

2004-09-27, 22:29:41

ok, razor, da kann ich deinen gedankengang nachvollziehen :D
und kritik darfste ja in deutschland auch ausüben! hast nochmal glück gehabt *waffenwegsteck*

ich gay jetzt tvtotal gucken ^^

Quasar

2004-09-27, 22:36:44

Ich frage mich gerade, ob die Umstellung des CP auf .NET-Technik nicht eher eine Erwähnung in den Investor-Relations der jeweiligen Firmen finden sollte. Das einzige, was es im Endeffekt wirklich bringt (neben der Festigung der Monopolstellung von M$...) ist, daß es preisgünstiger wird, hier Software-Entwicklung zu betreiben.

Ob diese Vorteile an den Kunden weitergereicht werden werden? *eg*

StefanV

2004-09-27, 22:42:58

Raymond

2004-09-28, 03:49:41

Indirekt sicher, denn so bleibt mehr Zeit, um am eigentlichen Treiber zu arbeiten ;)

Irgendwie bezweifle ich das eine kapitalistisch orientierte Firma (egal ob nun ATI oder nvidia) diese gesparten Resourcen in ein anderes Gebiet (in diesem Fall Treiberentwicklung) steckt, statt sie gänzlich abzubauen und somit Geld zu sparen. Würde mich natürlich freuen wenn ich mich irren und positiv überrascht werden würde, nur fehlt mir da so recht der Glaube :cool: .

Greetings Ray

grakaman

2004-09-28, 08:14:18

By the way... bist Du tatsächlich der Meinung, dass die Form eines Panels oder dessen Funktionalität etwas mit der Entwicklungsumgebung zu tun hat? Mann oh mann...

Es ist z.B. extrem einfach einen online Updater einzubauen und z.B. Assemblys per WebService oder Remoting von einem Server zu laden (dauert vielleicht höchstens 5Min.), wenn man das wollte.
Wenn solche Dinge nicht einfach wären zu implementieren, würde man diese auch in Zukunft nicht mit einbauen. Eigentlich ist das auch mit der Grund warum z.B. das Client/Server Paradigma sich zu Smart Clients bzw. Thin Clients in vielen neuen Entwicklungen verschiebt.

StefanV

2004-09-28, 09:51:57

Irgendwie bezweifle ich das eine kapitalistisch orientierte Firma (egal ob nun ATI oder nvidia) diese gesparten Resourcen in ein anderes Gebiet (in diesem Fall Treiberentwicklung) steckt, statt sie gänzlich abzubauen und somit Geld zu sparen. Würde mich natürlich freuen wenn ich mich irren und positiv überrascht werden würde, nur fehlt mir da so recht der Glaube :cool: .

Greetings Ray
(Gute) Ingeneure sind ein sehr kostbares Gut in der Branche, da feuert man nicht mal eben ein paar Leute ;)

Wenn man auf einem Gebiet welche einsparen kann, dann setzt man sie halt auf einem anderen Gebiet ein, feuern wäre schlecht denn wenn man sie wieder brauchen würde, dann hätte man ein Problem (die gibts nämlicz nicht soo recht auf dem Freien Markt)...

aths

2004-09-28, 10:00:32

By the way... bist Du tatsächlich der Meinung, dass die Form eines Panels oder dessen Funktionalität etwas mit der Entwicklungsumgebung zu tun hat? Mann oh mann...Das hat es, das ist sicher.

Grestorn

2004-09-28, 13:16:25

Wer grundsätzlich gegen Frameworks wie .net ist, der sollte konsequenterweise auch etwas gegen die folgenden Dinge haben:

Java (sollte einsichtig sein)
Visual Basic Runtime (ohne die läuft fast nix mehr heutzutage)
MFC/ATL Anwendungen (nahezu alle Windows Anwendungen der letzten Jahre, löscht mal die MFC*.DLL aus windows/system32...)
C/C++ (ja, auch C++ hat eine Laufzeitumgebung, die in einer DLL enthalten ist (MSVCRT.DLL))
Assembler Programme unter Windows (schließlich benutzen auch die meist Routinen aus den Kernel DLLs)
Letztlich ist .net ja nichts anderes als eine weitere Softwareumgebung, wie alle vorgenannten. Natürlich unterscheiden sie sich teilweise massiv in ihrer Komplexität und Größe, aber auch in ihrem Funktionsumfang und in der Einfacheit ihrer Nutzung.

Die Anforderungen an die Software steigen unheimlich schnell, in möglichst wenig Zeit soll Software mit möglichst viel Funktionen entstehen. Und das geht nur mit entsprechenden Laufzeitumgebungen wie der Java Runtime oder eben .net

Sich gegen .net zu stellen halte ich für ziemlich unangebracht und zeugt eigentlich nur von gefährlichem Halbwissen und einer gewissen Anfälligkeit für Medien-Hysterien.

zeckensack

2004-09-29, 00:09:48

a) u.A. weniger 'Chaos' im 'normalen' Panel...Liegt nicht an .NET oder nicht, sondern am Design. Das Design muss sich jemand ausdenken. Mit (oder auch ohne) .NET kann man es nur realisieren (oder auch nicht).

Als Beweisstück A für ein kaum übersichtlich(er)es Panel führe ich mal ATIs CCC ins Feld. Organisation wie im CP, nur mit Seitenmenü (btw von NVIDIA inspiriert) statt TABs. Toll.
b) jap, seit dem ich meine Parhelia abgegeben hab, warte ich auf .NET Panels von anderen Herstellern...Kann ich nicht nachvollziehen. Verstanden hätte ich, wenn du auf effizientere/flexiblere/bessere Pandels von anderen Herstellern warten würdest. Da gibt's keinen zwingenden Zusammenhang zu .NET.

Hatte ich schon erwähnt, dass mir das Forceware-Panel sehr gut gefällt?
Naja, es kommt immer drauf an, wie die Hersteller das 'hinbiegen', wenn mans ordentlich macht (siehe Matrox), dann kann ein .NET Panel richtig gut werden, vorallendingen da sich die Entwickler dabei voll austoben könnten, was das Design betrifft.

Ok, die 'Firmenfarbe' hilft MGA ein wenig ;)Auch ein Java Swing-Panel kann richtig gut werden, oder eine native Win32-API-Kiste, oder "was eigenes" wie zB bei Winamp.

__________________
@Topic

Ich stimme in dieser Sache weitgehend mit Razor überein. "Bringt dich schon nicht um", "Wird in der nächsten Version besser", "Man gewöhnt sich dran" sind keine Gründe um sich eine Software zu installieren. Das sind Entschuldigungen, Ausreden, etc, aber sicher keine Gründe dafür. Bugs, Bloat und Komplikationen sind aber Gründe um sich eine Software nicht zu installieren. Wie schwer diese Gründe wiegen, ist natürlich subjektiv.

Die Frage ob Gründeklasse "Pro" Gründeklasse "Contra" aufwiegt stellt sich aber nicht. Gründeklasse "Pro" ist die leere Menge.

Kennung Eins

2004-09-29, 00:29:31

Visual Basic Runtime (ohne die läuft fast nix mehr heutzutage)
MFC/ATL Anwendungen (nahezu alle Windows Anwendungen der letzten Jahre, löscht mal die MFC*.DLL aus windows/system32...)
C/C++ (ja, auch C++ hat eine Laufzeitumgebung, die in einer DLL enthalten ist (MSVCRT.DLL))
Assembler Programme unter Windows (schließlich benutzen auch die meist Routinen aus den Kernel DLLs)
Das als Framework (http://de.wikipedia.org/wiki/Framework) zu bezeichnen ist falsch.

Ein Framework ruft seine Komponenten auf, waehrend z.B. beim MFC das Programm die MFC-Komponenten aufruft.

ShadowXX

2004-09-29, 08:53:29

Das als Framework (http://de.wikipedia.org/wiki/Framework) zu bezeichnen ist falsch.

Ein Framework ruft seine Komponenten auf, waehrend z.B. beim MFC das Programm die MFC-Komponenten aufruft.

Hmmm....ich würde die MFC auch eher als Wrapper sehen als als Framework, aber darüber kann man sich sicher sehr lange streiten. (Egal was bei Wiki steht)

Grestorn

2004-09-29, 09:44:55

Das als Framework (http://de.wikipedia.org/wiki/Framework) zu bezeichnen ist falsch.

Ein Framework ruft seine Komponenten auf, waehrend z.B. beim MFC das Programm die MFC-Komponenten aufruft.Das ist zwar alles furchtbar OT, aber dennoch möchte ich anmerken, dass die von Dir genannte Definition (Framework = Applikationsrahmen in dem Komponenten eingehängt werden) zwar häufig so gebraucht wird, aber durchaus nicht die einzig übliche Definition ist.

Ich frage mich ausserdem, wieso Du bei der Java-Runtime davon ausgehst, dass die Bezeichnung Framework (in Deiner Definition) anwendbar ist, bei der MFC aber nicht. Meines Erachtens hat die MFC viel mehr Elemente, die in die Richtung eines Frameworks gehen als Java (Docment/View, OLE Container usw.).

Und nur der Vollständigkeit halber:

Die MFC ist nicht nur ein Wrapper, sie implementiert z.B. ein eigene Document/View Architektur (die man eben sehr wohl als einfaches Framework interpretieren kann) und hat teilweise sehr komplexe Klassen. Dass es viele Klassen gibt, die lediglich Windows Controls wrappen heisst nicht, dass die ganze Klassenbibliothek lediglich ein Wrapper ist.

Der Großteil des .net Framework Pakets besteht aus der CL Runtime. Die Bezeichnung "Framework" stammt von Microsoft, und bei welcher Definition diese Bezeichnung bei .net korrekt möchte ich nicht weiter beurteilen.

Bei der Aussage in meinem Beitrag ging es nicht darum, zwischen Frameworks und Laufzeitumgebungen zu unterscheiden, sondern lediglich darum, dass ich es für ziemlich unangebracht halte, eine dogmatische Abneigung gegen das .net Framework zu haben, als ob es sich um etwas völlig neues handeln würde, das es bisher noch nicht gab.

grakaman

2004-09-29, 09:51:12

MuLuNGuS

2004-09-29, 12:56:38

@grestorn

u 've got point!

Xmas

2004-09-29, 13:25:18

Die Frage ob Gründeklasse "Pro" Gründeklasse "Contra" aufwiegt stellt sich aber nicht. Gründeklasse "Pro" ist die leere Menge.
Du redest jetzt nur vom CCC, oder?

Tjell

2004-09-29, 14:13:03

Ich will kein eigenes Thema dafür starten, darum packe ich das mal hier herein (Auszug):

ATI-News: Gibt es Pläne neue Optimierungen, ähnlich ATIs Catalyst AI Feature, in den kommenden ForceWare Treibern zu integrieren?

Jens: Ziel eines jeden neuen Treibers ist immer die Verbesserung der Spiele-Performance. Das gilt für alle in der Grafikbranche tätigen Unternehmen. Die Steigerung der Performance erfolgt durch Treiberanpassungen und Optimierungen. Optimierungen für Spiele sind sowohl von Endkunden als auch von Spiele-Anbietern gewünscht und sogar gefordert, denn sie sorgen dafür, dass das Spiel auf möglichst vielen Grafikkarten flüssig läuft und über eine aufregende Grafik verfügt. Das von NVIDIA ins Leben gerufene „The way it’s meant to be played“ Programm klinkt sich da nahtlos ein, da dadurch schon während der Entwicklung des Spieles die flüssige Darstellung auf möglichst allen Grafikkarten gewährleistet werden soll. Das heißt Spiele (z.Zt. mehr als 160 Titel), die mit einem „The way it’s meant to be played“ Logo versehen sind, laufen garantiert auf allen NVIDIA GPUs ohne Kompatibilitätsprobleme.

Optimierungen sind ein ganz natürlicher Vorgang. Sie müssen aber auch AN- und AB-schaltbar sein, damit jeder Anwender den optimalen Mittelweg zwischen Performance und Bildqualität finden kann. Um den Vergleich mit den Optimierungs-Anstrengungen unseres Hauptmitbewerbers auch weiterhin nachvollziehbar zu halten, wird NVIDIA mit dem Treiber 65.xx und aufwärts auch die Möglichkeit einer AF Optimierung bieten, die natürlich vom Anwender konfigurierbar ist.

ATI-News: Auf die vorherige Frage bezogen, wann wird es endlich eine Lüfterkontrolle und/oder Temperaturüberwachung geben?

Jens: Diese Eigenschaften können von unseren Grafikkartenpartnern implementiert werden. Die Voraussetzungen sind durch die thermische Diode der GPU schon vorhanden.

Quelle: Interview von ATI-News.de (http://www.ati-news.de/HTML/Berichte/Interview/NV/1/Interview-Seite1.shtml) mit Jens Neuschäfer von nVdia vom 27. September 2004

Kennung Eins

2004-09-29, 18:05:35

Das ist zwar alles furchtbar OT, aber dennoch möchte ich anmerken, dass die von Dir genannte Definition (Framework = Applikationsrahmen in dem Komponenten eingehängt werden) zwar häufig so gebraucht wird, aber durchaus nicht die einzig übliche Definition ist.

Ich frage mich ausserdem, wieso Du bei der Java-Runtime davon ausgehst, dass die Bezeichnung Framework (in Deiner Definition) anwendbar ist, bei der MFC aber nicht. Meines Erachtens hat die MFC viel mehr Elemente, die in die Richtung eines Frameworks gehen als Java (Docment/View, OLE Container usw.).

Und nur der Vollständigkeit halber:

Die MFC ist nicht nur ein Wrapper, sie implementiert z.B. ein eigene Document/View Architektur (die man eben sehr wohl als einfaches Framework interpretieren kann) und hat teilweise sehr komplexe Klassen. Dass es viele Klassen gibt, die lediglich Windows Controls wrappen heisst nicht, dass die ganze Klassenbibliothek lediglich ein Wrapper ist.

Der Großteil des .net Framework Pakets besteht aus der CL Runtime. Die Bezeichnung "Framework" stammt von Microsoft, und bei welcher Definition diese Bezeichnung bei .net korrekt möchte ich nicht weiter beurteilen.

Bei der Aussage in meinem Beitrag ging es nicht darum, zwischen Frameworks und Laufzeitumgebungen zu unterscheiden, sondern lediglich darum, dass ich es für ziemlich unangebracht halte, eine dogmatische Abneigung gegen das .net Framework zu haben, als ob es sich um etwas völlig neues handeln würde, das es bisher noch nicht gab.
Ok, um das OT mal zu beenden:

Ich gebe mich geschlagen :)
Ich habe diese Framework definition so gelernt, und dabei wurde immer explizit gesagt, daß MFC kein Framework sei, da das MFC halt einfach nur eine Sammlung von Klassenbibliotheken ist. Bei Java / .NET hängt da ja noch ein "bisschen" mehr dran.

Aber je nach Definition kann man das natürlich anders sehen. So ist dann zumindest der Framework-Ansatz beim MFC ein anderer als bei .NET bzw die Framework-Architektur sieht anders aus.

r@h

2004-09-29, 21:53:54

Es ist z.B. extrem einfach einen online Updater einzubauen und z.B. Assemblys per WebService oder Remoting von einem Server zu laden (dauert vielleicht höchstens 5Min.), wenn man das wollte.Sollte ein Hardware-Panel (oder irgend etwas anderes, welches dort nichts zu suchen hat) auch nur den Versuch unternehmen, mit dem Internet 'kontakt' aufzunehmen, wird dieses von mir sofort und ohne jegliches Zögern unterbunden!

Wenn solche Dinge nicht einfach wären zu implementieren, würde man diese auch in Zukunft nicht mit einbauen. Eigentlich ist das auch mit der Grund warum z.B. das Client/Server Paradigma sich zu Smart Clients bzw. Thin Clients in vielen neuen Entwicklungen verschiebt.Was ich persönlich sehr schade finde, da man sich so kaum noch Gedanken um die Struktur macht... nicht nur um die der Basis, sondern auch nicht mehr, um die des eigenen 'Bockmists'.

Razor

r@h

2004-09-29, 21:55:24

Das hat es, das ist sicher.Ich bin sicher, dass Du weißt, wie das gemeint war.
(andere haben's doch auch vestanden ;-)

Razor

r@h

2004-09-29, 21:59:55

Sich gegen .net zu stellen halte ich für ziemlich unangebracht und zeugt eigentlich nur von gefährlichem Halbwissen und einer gewissen Anfälligkeit für Medien-Hysterien.So so...
Dann erzähle Du mir doch einfach mal, was da bisher Positives aus dieser Richtung gekommen ist.

Und nenne bitte etwas, was nicht durch gigantischen Resourcen-Verbrauch und/oder "Quick&Dirty"-Programmierung gekennzeichnet ist.

Razor

r@h

2004-09-29, 22:06:27

Ich will kein eigenes Thema dafür starten, darum packe ich das mal hier herein (Auszug):

Quelle: Interview von ATI-News.de (http://www.ati-news.de/HTML/Berichte/Interview/NV/1/Interview-Seite1.shtml) mit Jens Neuschäfer von nVdia vom 27. September 2004Was hat denn das jetzt mit dem Thread-Thema zu tun?
:confused:

Razor

grakaman

2004-09-29, 22:56:44

Sollte ein Hardware-Panel (oder irgend etwas anderes, welches dort nichts zu suchen hat) auch nur den Versuch unternehmen, mit dem Internet 'kontakt' aufzunehmen, wird dieses von mir sofort und ohne jegliches Zögern unterbunden!

Du kannst tun und lassen, was du willst. Die Frage ist, ob dir deine Paranoia lieber ist oder aber Features und Support. Außerdem habe ich ja nicht zwangsweise einem automatischen Updater gemeint. Das kannst du ja auch explizit auf Anfrage realisieren, z.B. über einen Button. Es wäre nur ein nettes Feature, was für Aktualität beim Anwender sorgen könnte, um eventuellen Problemen vorzubeugen.

Was ich persönlich sehr schade finde, da man sich so kaum noch Gedanken um die Struktur macht... nicht nur um die der Basis, sondern auch nicht mehr, um die des eigenen 'Bockmists'.

Razor

Du sollst dir ja auch weiterhin Gedanken über deine Anwendung machen. Das eine hat nur nichts mit dem anderen zu tun, denn auf irgend einer Infrastruktur muss ja deine Anwendung basieren. Eines der großen Probleme, die OOP angeht, ist es ja, Code wiederverwendbar zu kapseln und nicht alles neu zu schreiben. Wenn Software komplexer wird, ist das auch anders gar nicht möglich. Und auf etwas bewährtem zurückzugreifen, ist logischerweise weniger fehleranfällig, als alles neu zu implementieren.

r@h

2004-09-29, 23:10:11

Du kannst tun und lassen, was du willst. Die Frage ist, ob dir deine Paranoia lieber ist oder aber Features und Support. Außerdem habe ich ja nicht zwangsweise einem automatischen Updater gemeint. Das kannst du ja auch explizit auf Anfrage realisieren, z.B. über einen Button. Es wäre nur ein nettes Feature, was für Aktualität beim Anwender sorgen könnte, um eventuellen Problemen vorzubeugen. Meine "Paranoia" ist mir eindeutig lieber!
Auch gibt es solche 'Features' längst... und das ganz ohne .NET.

Du sollst dir ja auch weiterhin Gedanken über deine Anwendung machen. Das eine hat nur nichts mit dem anderen zu tun, denn auf irgend einer Infrastruktur muss ja deine Anwendung basieren. Eines der großen Probleme, die OOP angeht, ist es ja, Code wiederverwendbar zu kapseln und nicht alles neu zu schreiben. Wenn Software komplexer wird, ist das auch anders gar nicht möglich. Und auf etwas bewährtem zurückzugreifen, ist logischerweise weniger fehleranfällig, als alles neu zu implementieren.Und was hat das jetzt mit .NET zu tun?
Schließlich ist das, was Du da beschreibst, schon seit Jahrzehnten gängige Praxis.

Wie dem auch sei, ich warte immer noch auf die Beispiele von Dir, wo mit/unter .NET etwas postives (nach meiner Spezifikation!) zustande gebracht wurde.

Razor

r@h

2004-09-29, 23:12:03

Sorry... das mit den Beispielen war von grestorn gefordert...
Aber vielleicht hast Du ja ein Beispiel für eine 'positive' .NET-Anwendung.

Razor

Xmas

2004-09-30, 02:20:10

Dann poste doch mal bitte deine ausführliche und widerspruchsfreie "Spezifikation" einer "positiven Anwendung".

zeckensack

2004-09-30, 09:58:27

Du redest jetzt nur vom CCC, oder?Ja.

r@w

2004-09-30, 13:13:26

Dann poste doch mal bitte deine ausführliche und widerspruchsfreie "Spezifikation" einer "positiven Anwendung".Nö.
Sie soll einfach effizient programmiert und damit resourcen-schonend und schnell sein.

Und bitte keine Mega-Simpel-Teile ala 'nLight'.
(die kann man mit JEDER Umgebung 'mal eben' zusammen friemeln)

Razor

grakaman

2004-09-30, 13:14:46

Und was hat das jetzt mit .NET zu tun?
Schließlich ist das, was Du da beschreibst, schon seit Jahrzehnten gängige Praxis.

Aber nicht in der vereinfachten Form, wie wir es z.B. mit Java/.NET haben.

r@w

2004-09-30, 13:20:31

Aber nicht in der vereinfachten Form, wie wir es z.B. mit Java/.NET haben.Nich für Babys, das ist klar.

Aber unternehmensintere Klassensammlungen mit einer entsprechenden SourceSafe-Umgebung und bindenden Implementierungsrichtlinien gab's schon und hatten einen ähnlichen Effekt, nämlich die eigene Position im Wettbewerb zu stärken. Gestärkt wird mit .NET aber lediglich die Position Microsofts...

Razor

grakaman

2004-09-30, 13:23:20

Nich für Babys, das ist klar.

Aber unternehmensintere Klassensammlungen mit einer entsprechenden SourceSafe-Umgebung und bindenden Implementierungsrichtlinien gab's schon und hatten einen ähnlichen Effekt, nämlich die eigene Position im Wettbewerb zu stärken. Gestärkt wird mit .NET aber lediglich die Position Microsofts...

Razor

Oh, jetzt ist Märchenstunde :D

Crushinator

2004-09-30, 14:10:04

(...) Aber unternehmensintere Klassensammlungen mit einer entsprechenden SourceSafe-Umgebung und bindenden Implementierungsrichtlinien gab's schon und hatten einen ähnlichen Effekt, nämlich die eigene Position im Wettbewerb zu stärken. Gestärkt wird mit .NET aber lediglich die Position Microsofts... Prizipiell stimme ich dem zu. Allerdings finde ich, daß man nicht vergessen darf, daß eben nicht lediglich die Position Microsofts durch solche nahtlosen Verzahnungen von Produkten gestärkt wird, sondern aufgrund der deutlichen Vereinfachung von Softwareentwicklung auch die Position von sogenannten Nichtspezialisten. Letztere bekommen somit Werkzeuge in die Hand, um Dinge zu realisieren, von deren sie keine tiefergehenden Erkenntnisse haben. Man erzielt damit, wenn man es mit bösen Worten ausdrücken würde, daß Spezialisten größten Teils überflüssig würden. Für viele Chefetagen mag das wirtschatliche Vorteile bringen, diese vergessen dabei allerdings oft, daß dadurch sehr viel Entwicklerwissen verloren ginge oder gar nicht angeeignet würde, weil es einem die Werkzeuge schlicht nicht mehr abverlangen. Ob das wiederum nicht sehr oft zu qualitativ minderwertiger Software führt, wird sich noch zeigen müssen. Für mich persönlich zeichnet es sich im industriellen Umfeld leider bereits ab, und die leidtragenden sind in solchen Fällen keine geringeren als die Kunden, welche für die erworbene Software den selben Preis bezahlen, als würde sie von erfahrenen Spezialisten womöglich sogar mit für den jeweiligen Fall technisch angebrachteren Werkzeugen erstellt. Von möglichen Kosten wegen ggf. notwendiger Hardwareaufrüstung wollen wir erst gar nicht sprechen.

HellHorse

2004-09-30, 14:37:14

Aber nicht in der vereinfachten Form, wie wir es z.B. mit Java/.NET haben.
70er Smalltalk?

grakaman

2004-09-30, 14:39:36

Von möglichen Kosten wegen ggf. notwendiger Hardwareaufrüstung wollen wir erst gar nicht sprechen.

Deine Hardwarekosten spielen überhaupt gar keine Rolle im Vergl. zu dem eingesparten Mehraufwand.

Crushinator

2004-09-30, 15:16:21

Kennung Eins

2004-09-30, 15:27:55

Vergleich mal Kosten einer Programmierer-Arbeitsstunde mit den Kosten für die Anschaffung neuer Hardware.

Das läßt sich nicht einfach sagen "a ist teurer als b" ...

Crushinator

2004-09-30, 15:55:49

grakaman

2004-09-30, 16:09:45

Eingesparten Mehraufwand für den Kunden? Welchen denn? :D Ich sprach davon, daß der Kunde ggf. seine Hardware erstmal aufrüsten müßte, um überhaupt in den Genuß der Wohltat zu kommen, unheimlich einfach zu entwickelnde Software nutzen zu dürfen.

Das kommt darauf an, wovon du redest. Wenn wir uns jetzt hier z.B. auf ein Control Panel für Grafikkarten beziehen, dann hat der Kunde letztendlich neben eventueller stabilierer Software und dem einen oder anderen Feature nicht wirklich was. Ich meinte jetzt speziell Auftragsentwicklung von z.B. Geschäftsanwendungen. Denn da sind Mannkosten viel höher als die eventuell zusätzlichen HW Kosten. Trotzdem bin ich der Meinung, dass der Kunde längerfristig einen Vorteil aus solchen Plattformen erzielt. Denn durch die Vereinheitlichung und der Vereinfachung lässt sich darauf aufbauend noch mehr Funktionalität implementieren, die dem Endverbraucher dann zu Gute kommt. Ich glaube mit Longhorn werden wir viele solcher Sachen sehen, z.B. Avalon. Bis dahin ist es in der Tat so, dass für dem Heimanwender wohl weniger bringt als für den Entwickler.

grakaman

2004-09-30, 16:16:22

OK, veranschlagen wir dem Kunden mal für eine in Auftrag gegebene Anwendung seriöse 90,- bis 150,- € für eine Programmierstunde und gehen einfach mal vom höchsten Betrag aus. Bei einem 100 Std. Projekt (ohne .Net) veranschlagen wir mal 20 Std. (Das sind fast 3 Tage) Einsparung durch .Net was bei einem mit Tools gutbestückten Softwarehaus meiner Meinung nach sogar etwas übertrieben klingt, denn die meisten machen so etwas ja nicht erst seit gestern und haben mit Sicherheit auch ohne .Net bereits wiederverwendbaren Code für die meisten Problemfälle. Ergibt 3000,- € Vorteil für .Net-Einsatz, die sofort verbraucht sind, sobald mehr als nur ein Server und 2 Arbeitsstationen auf/umgerüstet oder neuangeschafft, möglicherweise noch extra eingerichtet werden sollen. Schade nur, daß ein 100 Stunden Projekt in der Regel nicht nur für 2 PCs und einen Server angefangen wird, und wenn wir mit 90,- pro Std. rechnen fällt der Vorteil noch geringer aus.

Es würde sich wirklich lohnen, wenn man nur noch 40% des Aufwandes bräuchte. Ich möchte nicht bestreiten, daß es in Einzelfällen so deutliche Einsparungen allein durch Einsatz von .Net theoretisch möglich sind, in der Praxis sind mir diese allerding noch nicht begegnet, und das ist noch sehr diplomatisch ausgedrückt. ;)

Nunja, du kannst ja schlecht verlangen, dass wir jetzt dein, nach deinen Interessen zurechtgeschustertes Bsp. als Allgemeintgültig hinnehmen. :rolleyes:

Nachtrag: Achso, und wie du mit 15k EUR über 3 Monate Entwicklung finanzieren willst, ist mir irgendwie schleierhaft. :rolleyes:

Crushinator

2004-09-30, 16:23:08

Wieso nach meinen Interessen zurechtgeschustertes Beispiel? Es basierte sogar auf tagtägliche Projekte unseres Hauses, welche ich zum Teil selbst so veranschlagt habe.
Nachtrag: Achso, und wie du mit 15k EUR über 3 Monate Entwicklung finanzieren willst, ist mir irgendwie schleierhaft. :rolleyes:Ich verstehe die Fragestellung nicht so richtig. Meinst Du, daß es sich erst lohnen würde, wenn die Projekte 3 oder mehr Mann-Monate an Aufwand verschlingen würden?

grakaman

2004-09-30, 16:42:27

Ich verstehe die Fragestellung nicht so richtig. Meinst Du, daß es sich erst lohnen würde, wenn die Projekte 3 oder mehr Mann-Monate an Aufwand verschlingen würden?

Nein, mit den 15k kannst du bestenfalls die Arbeitnehmerkosten decken. Wie du da überhaupt rentabel arbeiten willst, ist mir schleierhaft. Dein Arbeitgeber hat ja ein bischen mehr zu bezahlen, als das was auf deinem Lohnzettel drauf steht. Und damit mein ich die Lohnnebenkosten, von den anderen gar nicht zu sprechen. Mehr Manntage heißt auch mehr Kosten, die auf dem Kunden umgelegt werden. Dein "Rechenbsp." funktioniert ja nur, weil du von einem ziemlich niedrigen Stundensatz ausgehst, den ich als nicht praxisnah bezeichnen würde ;)

Crushinator

2004-09-30, 17:13:05

grakaman

2004-09-30, 18:20:20

Achso, jetzt habe ich das verstanden. :) Also, wir berechnen dem Kunden je nach Art der Tätigkeit wirklich zwischen 120,- und 250,- Euronen die Programmiererstunde, wobei der Durchschnitt die 120,- bezahlt, und wir haben genügend paralell laufende Projekte neben mehreren modularen Standardanwendungen, die wir oft einfach so von der Stange für ca. 3000,- pro Einzellizenz (kleinste Version) verkaufen. Unsere Firma gibt es seit dem 19. Jahrhundert, und Software schreiben wir erst seit 1989. Soweit ich mich erinnern kann, mußte in den letzten 8 Jahren auch keinem Entwickler gekündigt werden, nur weil wir sparen mußten. ;)

Ja gut, wir wollen jetzt auch nicht über Dinge reden, die wir im Endeffekt eh nicht beweisen können. Trotzdem hast du imo einen bedeutenten Punkt vergessen. Die Zeitersparnis kommt ja nicht nur durch die leichtere Benutzung, sondern hauptsächlich mit durch die damit verbundene geringere Fehlererwartung. Insofern kann die Zeitersparnis sogar in bestimmten Bereichen viel höher als 40% liegen. Gerade was Thin Clients und Serveranwendungen angeht, würde ich doch Java/.NET als äußerst überlegen im Vergl. zu C++ ansehen.

Kennung Eins

2004-09-30, 20:12:08

OK, veranschlagen wir dem Kunden mal für eine in Auftrag gegebene Anwendung seriöse 90,- bis 150,- € für eine Programmierstunde und gehen einfach mal vom höchsten Betrag aus. Bei einem 100 Std. Projekt (ohne .Net) veranschlagen wir mal 20 Std. (Das sind fast 3 Tage) Einsparung durch .Net was bei einem mit Tools gutbestückten Softwarehaus meiner Meinung nach sogar etwas übertrieben klingt, denn die meisten machen so etwas ja nicht erst seit gestern und haben mit Sicherheit auch ohne .Net bereits wiederverwendbaren Code für die meisten Problemfälle. Ergibt 3000,- € Vorteil für .Net-Einsatz, die sofort verbraucht sind, sobald mehr als nur ein Server und 2 Arbeitsstationen auf/umgerüstet oder neuangeschafft, möglicherweise noch extra eingerichtet werden sollen. Schade nur, daß ein 100 Stunden Projekt in der Regel nicht nur für 2 PCs und einen Server angefangen wird, und wenn wir mit 90,- pro Std. rechnen fällt der Vorteil noch geringer aus.

Es würde sich wirklich lohnen, wenn man nur noch 40% des Aufwandes bräuchte. Ich möchte nicht bestreiten, daß es in Einzelfällen so deutliche Einsparungen allein durch Einsatz von .Net theoretisch möglich sind, in der Praxis sind mir diese allerding noch nicht begegnet, und das ist noch sehr diplomatisch ausgedrückt. ;)
Wie schaut es bei größeren Projekten aus? I.e. eine Neuentwicklung einer imaginären Datenbankanwendung für die Nutzerverwaltung, Kostenabrechnung (etc.) von digitalem Fernsehen.

Ich nehm jetzt mal deine Werte (150€/stunde, 20% Einsparung durch .NET)
Wenn da ein Team von 20 Programmierern ein halbes Jahr dran beteiligt ist, kommen da (6 Monate == 22 Arbeitstage*6 == 132 Tage, abzüglich 15 Tage Urlaub == 117 Tage == 936 Arbeitsstunden) 150*936, grob 150*1.000 = 150.000 Euro zusammen.

20% Einsparung entsprechen 30.000 Euro. pro Person
Das macht also 20*30.000 = 600.000€uro Einsparung.

In diesem Fall überlegt man sich vielleicht wirklich, daß .NET was nützt.

[edit]
Ich hab vergessen, daß ich ja noch alles *20 nehmen darf, da wir 20 Programmieren haben.

Crushinator

2004-09-30, 22:59:06

@grakaman
Welche geringere Fehlererwartung meinst Du denn? Unsere eigenen Fehlerfälle ohne .Net-Einsatz bestehen in der Praxis nämlich zu 99,9% aus Logikfehlern, die mit .Net oder Java eben so passiert bzw. zum selben unerwünschten Ergebnis führen würden.

Ich stimme dem zu, daß Java oder .Net für Webanwendungen besser taugen, würde es jedoch nicht verstehen, warum jede Problemstellung mit einer Webanwendung gelöst werden soll.

@Kennung Eins
OK, aber auch Dein Beispiel gilt nur für eine Gruppe von Softwareentwicklern, die bisher noch nie ein komplexes kaufmännisches Projekt mit entsprechender Datenbankanbindung realisiert hat, mit anderen Worten für eine unerfahrene Gruppe. Softwarehäusern mit Referenzen auf bereits erfolgreich abgeschlossene Projekte ähnlicher Art (jedoch ohne .Net) würde .Net allein nicht mal 5% an Aufwand sparen. Abgesehen davon, daß neue Hardware für eine solche Monsteranwendung - immerhin soll ihre Entwicklung ja nicht weniger als 120 Mannmonate andauern - auch ganz schnell weit über 600.000 € kosten kann.

grakaman

2004-10-01, 09:14:00

Ich stimme dem zu, daß Java oder .Net für Webanwendungen besser taugen, würde es jedoch nicht verstehen, warum jede Problemstellung mit einer Webanwendung gelöst werden soll.

Wie kommst du denn zwangsweise auf Webanwendung? Mit Thin Clients meinte ich eher Desktopanwendungen, die sich den Presentationslayer dynamisch vom Server laden (Remoting oder aber auch WebServices), instanzieren und von dort noch mal über Remoting oder WebServices auf die BL zugreifen. Sowas kann man in wenigen Minuten problemlos implementieren. Auch wegen Reflections kann man z.B. die Entwicklung extrem verkürzen, indem man beispielsweise O/R Mapper verwendet (die funktionen i.d.R über Reflections per XML File oder Attributen) verwendet. Es gibt wirklich so viele tausende von nützlichen Klassen, z.B. Objekt XML-Serialisierer oder oder...
Möglich, dass du einige wenige Bibliotheken hast, die bestimmte Dinge ähnlich vereinfachen. Nur was ist, wenn du vielleicht mal woanders arbeitest oder neue Mitarbeiter für ein Projekt kommen. Die müssen sich dann erst einmal ständig in zig verschiedene Bibliotheken einarbeiten.

grakaman

2004-10-01, 09:19:22

@Kennung Eins
OK, aber auch Dein Beispiel gilt nur für eine Gruppe von Softwareentwicklern, die bisher noch nie ein komplexes kaufmännisches Projekt mit entsprechender Datenbankanbindung realisiert hat, mit anderen Worten für eine unerfahrene Gruppe. Softwarehäusern mit Referenzen auf bereits erfolgreich abgeschlossene Projekte ähnlicher Art (jedoch ohne .Net) würde .Net allein nicht mal 5% an Aufwand sparen. Abgesehen davon, daß neue Hardware für eine solche Monsteranwendung - immerhin soll ihre Entwicklung ja nicht weniger als 120 Mannmonate andauern - auch ganz schnell weit über 600.000 € kosten kann.

Das ist ja nun nicht richtig, mit unerfahren hat das überhaupt nichts zu tun. Was ist nun mal, wenn du kein generisches Produkt verwenden kannst, dass du nir anpassen brauchst, sondern es sich um eine komplett spezifische Anwendung handelt? Denn genau das wird ja wohl die Mehrheit der Fälle sein.

Crushinator

2004-10-01, 11:33:54

(...) Möglich, dass du einige wenige Bibliotheken hast, die bestimmte Dinge ähnlich vereinfachen. Nur was ist, wenn du vielleicht mal woanders arbeitest oder neue Mitarbeiter für ein Projekt kommen. Die müssen sich dann erst einmal ständig in zig verschiedene Bibliotheken einarbeiten. Wenn ich wo anders arbeiten würde, bin ich - so schätze ich mich zumind. selbst ein - in der Lage notfalls selbst das Rad neu zu erfinden, falls es notwendig sein sollte, und wenn die Devise dort lauten sollte, daß die Strategie hauptsächlich auf .Net oder sonstigen propritären Techniken ausgerichtet sein sollte, müßte ich mich dem entweder beugen oder eben dort nicht arbeiten. Aus heutiger Sicht würde ich mich für Letzteres entscheiden.

Was neue Mitarbeiter für ein Projekt angeht: Die Frage stellte sich für uns bisher nicht. Wir beschäftigen keine Externen, da das Anforderungsprofil solche nicht so einfach erlaubt. Neue und langfristige Mitarbeiter haben mehr damit zu tun, sich in die eigentlichen Produkte einzuarbeiten. Wenn es sich jedoch so verhalten würde, wie Du es beschreibst, sprich einfach projektweise neue und einfach austauschbare Entwickler, dann wären solche Sachen ala Standardbibliotheken/Frameworks selbstverständlich von Vorteil, was aber auch die Gefahr mit sich brächte, daß die Qualität der Anwendung(en) wegen der Unerfahrenheit von ständig neuen Mitarbeitern leiden würde. Das war, was ich in meinem ersten Beitrag in diesem Thread mit "Spezialisten überflüssig machen" meinte.

Das ist ja nun nicht richtig, mit unerfahren hat das überhaupt nichts zu tun. Was ist nun mal, wenn du kein generisches Produkt verwenden kannst, dass du nir anpassen brauchst, sondern es sich um eine komplett spezifische Anwendung handelt? Denn genau das wird ja wohl die Mehrheit der Fälle sein. Wie jetzt? Man kann doch wohl nicht davon ausgehen, daß ein ähnliches Projekt Deutschlandweit von bisher niemandem realisiert worden ist. Gerade bei dem Beispiel von Kennung Eins handelt es sich um ein Standardprojekt, bei dem es haupstächlich darauf ankommt die Geschäftslogik zu implementieren, und nicht darauf daß erstmal das Rad für die Kommunikation mit den Backends und den Front ends erfunden werden muß. Ich würde jetzt einfach mal schätzen, daß 80% der Arbeit an solchen Projekten auf die Modellierung und Implementierung des eigentlichen Ablaufes fällt.

[edit]
Laßt uns doch bitte darauf einigen, daß es genügend Pro und Kontras für die unsere jeweiligen Ansichten gibt, und man pro Fall entscheiden müßte, wo solche Frameworks oder Verwendung von XYZ-Entwicklungstools angebrachter sind. Denn absolut einig werden wir uns eh' nicht, und die Gefahr besteht, daß wir uns bei unserer Diskussion viel zu weit vom Topic entfernen, was für die anderen etwas unschön wäre. Schließlich geht's hier ja um einen zukünftigen Treiberfrontend für Grafikkarten und nicht um spezielle Datenbankanwendungen und mögliche Aufwandseinsparungen bei Entwicklung solcher. Bei Bedarf diskutiere ich gerne in einem ggf. neuerstellten Thread in angebrachteren Unterforen mit, aber hier höre ich jetzt auf.

Quasar

2004-10-01, 13:07:09

Prizipiell stimme ich dem zu. Allerdings finde ich, daß man nicht vergessen darf, daß eben nicht lediglich die Position Microsofts durch solche nahtlosen Verzahnungen von Produkten gestärkt wird, sondern aufgrund der deutlichen Vereinfachung von Softwareentwicklung auch die Position von sogenannten Nichtspezialisten. Letztere bekommen somit Werkzeuge in die Hand, um Dinge zu realisieren, von deren sie keine tiefergehenden Erkenntnisse haben. Man erzielt damit, wenn man es mit bösen Worten ausdrücken würde, daß Spezialisten größten Teils überflüssig würden.
Ich weiß nicht, ob du dir der Tragweite dieser Worte in Gänze bewußt bist.

IMO ist das nämlich der Hauptzweck, neben der Stärkung der eigenen Position, die M$ mit Win95/ME/XP begann und mit .NET sicherlich nicht zuende verfolgt hat.

Ersetze Spezialisten mehr und mehr durch Halbspezialisten und diese mehr und mehr durch erfahrene User und diese dann irgendwann durch beinahe-DAUs - und keiner wird dir mehr dein Monopol nehmen können, weil schlicht keiner mehr weiß, was und wie du da dein Geschäfte betreibst.

Crushinator

2004-10-01, 13:18:45

grakaman

2004-10-01, 13:56:50

Wenn ich wo anders arbeiten würde, bin ich - so schätze ich mich zumind. selbst ein - in der Lage notfalls selbst das Rad neu zu erfinden, falls es notwendig sein sollte, und wenn die Devise dort lauten sollte, daß die Strategie hauptsächlich auf .Net oder sonstigen propritären Techniken ausgerichtet sein sollte, müßte ich mich dem entweder beugen oder eben dort nicht arbeiten. Aus heutiger Sicht würde ich mich für Letzteres entscheiden.

Das Rad neu zu erfinden, ist aber wohl alles andere als intelligent. Wenn deine Mitarbeiter nicht smart genug sind und keine Ahnung davon haben, so ist das nicht weiter schlimm. Wenn deine Mitarbeiter aber erfahrene Entwickler sind, dann versuch doch mal das deinen Chef klar zu machen, warum du sinnlose Stunden für sinnlose Sachen verbrätst. Solche Leute gehören ganz einfach gefeuert.

Wie jetzt? Man kann doch wohl nicht davon ausgehen, daß ein ähnliches Projekt Deutschlandweit von bisher niemandem realisiert worden ist.

Die Welt besteht aus etwas mehr als nur aus generischen Warenwirtschaftssystemen oder der gleichen. Die Aufgabe könnte genau so gut lauten, integrierer eine neue Clientanwendung zur grafischen Erstellung von Schaltplänen mit dem geringsten Aufwand. Bestehende Daten auf AS/390 + DB2 sollen integriert werden und bestehende BL Komponenten auf MFC Basis sollen so weit wie möglich wiederverwendet werden. Viele IT Projekte bauen auf einer vorhandenen Basis auf, im geringsten Fall bloss eine DB.

Gerade bei dem Beispiel von Kennung Eins handelt es sich um ein Standardprojekt, bei dem es haupstächlich darauf ankommt die Geschäftslogik zu implementieren, und nicht darauf daß erstmal das Rad für die Kommunikation mit den Backends und den Front ends erfunden werden muß. Ich würde jetzt einfach mal schätzen, daß 80% der Arbeit an solchen Projekten auf die Modellierung und Implementierung des eigentlichen Ablaufes fällt.

Bei der Kommunikation zwischen Backend und Geschäftslogik ist auf traditionelle Weise immer das Rad neu erfunden worden, d.h. das Mapping von DAL und BL bzw. Entity. In einem datenzentrierten Projekt wie ein WWS nimmt das mind. 40% der Entwicklung ein. Je normalisierter die DB, was ja auch richtig ist, desto mehr CRUD.

grakaman

2004-10-01, 14:01:30

Doch Quasar, ich bin mir durchaus über die Tragweite bewußt, und es freut mich, daß wenigstens Einer zwischen den Zeilen lesen konnte. Ich wollte damit nur ergänzend zu Razors Ausführungen verdeutlichen, daß es den Halbspezialisten Vorteile bringt, und daß es diese sind, die am Endeffekt dafür sorgen, daß wir. a) ggf. minderwertige Qualität bekämen und b) weiterhin am Tropf vom Monopolisten hängen blieben.

Das ist freilich ein gänzlich hochintellektuelle Gesinnung, die anderen sind dran Schuld. Du, der jedes mal das Rad neu erfindet, kann freilich viel qualitativ hochwertigerere Software entwickeln.

Crushinator

2004-10-01, 14:21:54

Nein, Du hast es glaub' ich einwenig mißverstanden. Man erfindet nicht das Rad jedes mal neu, weil das Rad eben nicht erst durch .Net oder gar von Microsoft erfunden wurde. Außerdem sollte es aus all meinen Beiträgen eindeutig hervorgehen, daß meine Intention keine Verallgemeinerung ala ."XYZ == minderwertige Software" sei, sondern daß Nichtspezialisten erwartungsgemäß öfter qualitativ minderwertiges produzieren als jene die sich viel tiefgründiger mit der Materie auskennen.

grakaman

2004-10-01, 15:26:29

Ich weiß nicht, ob du dir der Tragweite dieser Worte in Gänze bewußt bist.

IMO ist das nämlich der Hauptzweck, neben der Stärkung der eigenen Position, die M$ mit Win95/ME/XP begann und mit .NET sicherlich nicht zuende verfolgt hat.

Ersetze Spezialisten mehr und mehr durch Halbspezialisten und diese mehr und mehr durch erfahrene User und diese dann irgendwann durch beinahe-DAUs - und keiner wird dir mehr dein Monopol nehmen können, weil schlicht keiner mehr weiß, was und wie du da dein Geschäfte betreibst.

Inwieweit soll denn Microsoft.NET das Monopol mehr stärken? Und warum sollten Spezialisten durch Halbspezialisten ersetzt werden?

Kennung Eins

2004-10-01, 15:39:44

Doch Quasar, ich bin mir durchaus über die Tragweite bewußt, und es freut mich, daß wenigstens Einer zwischen den Zeilen lesen konnte. Ich wollte damit nur ergänzend zu Razors Ausführungen verdeutlichen, daß es den Halbspezialisten Vorteile bringt, und daß es diese sind, die am Endeffekt dafür sorgen, daß wir. a) ggf. minderwertige Qualität bekämen und b) weiterhin am Tropf vom Monopolisten hängen blieben.Nur schnell eine Frage:
Halbspezialisten?

Bezeichnest du einen C#-Programmierer als Halbspezialisten?
Ist Demirug ein Halbspezialist?

[edit]
.NET programmieren heißt nicht, daß man "weniger" tun muß, sondern daß der Programmierer sich einfach nur auf das konzentrieren kann, was er machen soll: Programmieren.

Quasar

2004-10-01, 15:40:05

Crushinator

2004-10-01, 16:01:13

(...) Bezeichnest du einen C#-Programmierer als Halbspezialisten? Nunja. Diejenigen, welche nur C# kennen, würde ich nicht unbedingt zur Elite zählen.
Ist Demirug ein Halbspezialist? In vielen Bereichen könnte er - wie ich wiederum in anderen - ein Noob sein, was ja an sich nicht schlimm ist. Da ich von seinen langjährigen Erfahrungen mit anderen Programmiersprachen und seinem unschätzbaren Wissen insbesondere bezüglich D3D weiß, würde ich ihn in vielerlei Hinsicht eher zu den Gurus zählen. ;)

[edit]
.NET programmieren heißt nicht, daß man "weniger" tun muß, sondern daß der Programmierer sich einfach nur auf das konzentrieren kann, was er machen soll: Programmieren. Diese Argumentation impliziert jedoch, daß man mit anderen Entwicklungswerkzeugen und Bibliotheken immer wieder das Rad neuerfinden müßte, was so natürlich nicht stimmt. Native Dektopanwendungen sind, um nur ein topic-nahes Beispiel zu nennen, mindestens genau so schnell mit Delphi oder Borlands C++ Builder zusammengeklickt.

grakaman

2004-10-01, 16:12:25

Nunja. Diejenigen, welche nur C# kennen, würde ich nicht unbedingt zur Elite zählen.

Das ist ja vollkommener Quatsch, weil sich sowas nicht an der Sprache entscheidet, sondern, ob man generell Ahnung von Softwarearchitektur und über die die Möglichkeiten bzw. über das richtige Werkzeug für die richtige Aufgabe bescheid weiß. Und mit Werkzeug meine ich jetzt nicht die Programmiersprache, sondern den Lösungsansatz für entsprechende Probleme. Jemand, der vielleicht, in 10 Sprachen programmieren kann, aber nicht über simple GUIs hinauskommt bzw. die Implementierung grottenschlecht ist, weil er noch nie was von Design Pattern und Softwarearchitektur gehört hat, so einen würde ich erst recht nicht als professionell bezeichnen. Und gerade in der Java/.NET Ecke werden solche Themen viel intensiver angesprochen und durch das Framework auch beim Entwickler forciert.

Crushinator

2004-10-01, 16:23:41

grakaman

2004-10-01, 16:25:57

Es wurde doch hier dargestellt, daß .NET diverse Vereinfachungen für Entwickler mit sich bringt. Dadurch wird erstens eine höhere Entwicklungsdichte erreicht und zweitens wird die Schwelle herabgesetzt, ab der Programme entwickelt werden können.

Die Vereinachung rührt hauptsächlich von der Reduzierung der geschriebenen Zeilen, was primär auf die Plattform zurückzuführen ist. Das hat mehrere Gründe, erstens weil die Sprache absolut objekt orientiert ist und die Frameworks darauf aufbauen (.NET/J2EE). Plattformbedingt hast du hier auch nicht unzählige Handles/Pointer, nur um du die simplesten Aufgaben zu erledigen.
Das zu managen macht dich nämlich nicht professioneller, denn letztendlich weißt du ja sowieso, was du genau implementierst. Jeder, der sich auch nur ein wenig damit auskennt, weiß ganz genau wie z.B. Pointer funktionieren, auch wenn er nie damit in Berührung kommt.
Was deine Monopolisierung betrifft, so ist das ja um so mehr falsch im Vergl. zu MFC, weil ja .NET sehr stark abstrahiert. Du brauchst dir nur um die Implementierung des Frameworks gedanken machen und nicht über die Programme, bestes Bsp. Mono.

grakaman

2004-10-01, 16:39:26

Warum ist es Quatsch? Jemand der nur C# kennt, kann sich besten Falls seit 2,5 Jahren ernsthaft mit Programmierung beschäftigt haben. Wenn jemand seit so einer kurzen Zeit Software entwickelt und bereits zum Spezialisten gezählt wird, wie sollen denn Leute bezeichnet werden, die schon seit mehr als 10 Jahren Software entwickeln und während dieser Zeit mehrere Epochen der IT-Welt inkl. der dazugehörigen Entwicklungswerkzeugen neben Programmiersprachen und Architekturen durchgemacht haben?

Das ist ganz einfach insofern Quatsch, weil das nichts mit der Sprache zu tun hat, sondern speziell auf die Person ankommt. Inwieweit diese nämlich bereit ist über Softwarearchitektur/Design Pattern zu lernen. Jemand, der schon 10 Jahre in der IT ist, kann ein absoluter Profi sein, er kann aber einfach auch nur ein Idiot sein, wenn er z.B. Dinge wie eh und je auf triviale Art und Weise implementiert. Und jemand, der seit 4 Jahren C# programmiert, kann vielleicht äußerst profssionell sein, er kann aber auch genau das Gegenteil sein.

Crushinator

2004-10-01, 16:44:14

Also, ist es kein vollkommener Quatsch, sondern wie Du selbst schreibst eben möglich, wenn auch selten anzutreffen, weshalb ich Gebrauch von "nicht unbedingt" machte. ;)
(...) Plattformbedingt hast du hier auch nicht unzählige Handles/Pointer, nur um du die simplesten Aufgaben zu erledigen. (...) Du stellst es hin, als würde man in anderen Sprachen zwangsläufig unzählige Handles/Pointer benötigen. Ich habe kürzlich einem Member dieses Forums einen TCP-Server mit konfigurierbarem Feedback auf Requests (mit GUI und multithreaded Mehrclientfähig) geschrieben, damit er die SMTP-Funktionalität eines ca. 2 Watt verbrauchenden microcontroler ähnlichen Gerätes ohne einen echten SMTP-Server testen kann. Ich schrieb das Ding mit Delphi, während ich mich mit ihm nebenbei im IRC unterhielt. ca. eine Stunde später hatte er eine lauffähige Version und nach insgesamt weiteren 3 Std. wurden all seine Wünsche, soweit er sie äußerte, berücksichtigt. Dabei kann ich mich nicht einmal daran erinnern, expliziten Gebrauch von Pointern oder Handles gemacht zu haben.

Quasar

2004-10-01, 17:10:03

Die Vereinachung rührt hauptsächlich von der Reduzierung der geschriebenen Zeilen, was primär auf die Plattform zurückzuführen ist. Das hat mehrere Gründe, erstens weil die Sprache absolut objekt orientiert ist und die Frameworks darauf aufbauen (.NET/J2EE). Plattformbedingt hast du hier auch nicht unzählige Handles/Pointer, nur um du die simplesten Aufgaben zu erledigen.
Das zu managen macht dich nämlich nicht professioneller, denn letztendlich weißt du ja sowieso, was du genau implementierst. Jeder, der sich auch nur ein wenig damit auskennt, weiß ganz genau wie z.B. Pointer funktionieren, auch wenn er nie damit in Berührung kommt.
Wie gesagt - Zwischenschritte. Noch weiß vielleicht jeder solche Dinge, aber wenn die Umgebungen das nicht mehr voraussetzen, wird auch ein Programmierbaukasten in ein paar Jahren zu einem Klicki-Bunti Puzzle.
Das UI hat's ja bereits 'erfolgreich' vorgemacht.

Was deine Monopolisierung betrifft, so ist das ja um so mehr falsch im Vergl. zu MFC, weil ja .NET sehr stark abstrahiert. Du brauchst dir nur um die Implementierung des Frameworks gedanken machen und nicht über die Programme, bestes Bsp. Mono.
Wo du grade 'Gedanken machen' ansprichst - genau das wurde dem User bereits erfolgreich abgenommen, 'wizards' aller Orten.
Meinst du nicht, daß man auf demselben Wege ist, zunächst mal nur eine bestimmte Gruppe an Entwicklern in dieselbe Richtung zu führen?

Schau dir mal die Virenbaukästen an, über die so viel geschrieben wird: Programmentwicklung für Jedermann - schnell erlernt, schlampig zusammengeschustert. Aber wirklich wissen, was sie da machen, das tun nur noch die wenigsten.

Darum geht's mir - das Grundsatzwissen wird mehr und mehr zurückgedrängt und man fokussiert sich auf die Aufgabenstellung. Das wäre IMO nicht weiter problematisch, würde damit nicht die Möglichkeit einhergehen, nach dem User auch den Entwickler langsam zum 'Black-Box Bediener' zu degradieren.

edit:
Nur zum besseren Verständnis: Ich bin kein Programmierer - es hat daher wenig Sinn, sich mit mir über Implementationsspezifika unterhalten zu wollen. Ich versuche mehr, das Gesamtbild zu sehen und abzuschätzen, wohin uns das führen kann.
Für mich als Enduser habe ich funktional keine Probleme mit .NET - nur die Philosophie von M$, die ich dahinter sehe, behagt mir nicht.

Jesus

2004-10-01, 17:41:42

Wie gesagt - Zwischenschritte. Noch weiß vielleicht jeder solche Dinge, aber wenn die Umgebungen das nicht mehr voraussetzen, wird auch ein Programmierbaukasten in ein paar Jahren zu einem Klicki-Bunti Puzzle.
Das UI hat's ja bereits 'erfolgreich' vorgemacht.

Wo du grade 'Gedanken machen' ansprichst - genau das wurde dem User bereits erfolgreich abgenommen, 'wizards' aller Orten.
Meinst du nicht, daß man auf demselben Wege ist, zunächst mal nur eine bestimmte Gruppe an Entwicklern in dieselbe Richtung zu führen?

Schau dir mal die Virenbaukästen an, über die so viel geschrieben wird: Programmentwicklung für Jedermann - schnell erlernt, schlampig zusammengeschustert. Aber wirklich wissen, was sie da machen, das tun nur noch die wenigsten.

Darum geht's mir - das Grundsatzwissen wird mehr und mehr zurückgedrängt und man fokussiert sich auf die Aufgabenstellung. Das wäre IMO nicht weiter problematisch, würde damit nicht die Möglichkeit einhergehen, nach dem User auch den Entwickler langsam zum 'Black-Box Bediener' zu degradieren.

edit:
Nur zum besseren Verständnis: Ich bin kein Programmierer - es hat daher wenig Sinn, sich mit mir über Implementationsspezifika unterhalten zu wollen. Ich versuche mehr, das Gesamtbild zu sehen und abzuschätzen, wohin uns das führen kann.
Für mich als Enduser habe ich funktional keine Probleme mit .NET - nur die Philosophie von M$, die ich dahinter sehe, behagt mir nicht.

Es reicht aber leider nicht mehr alles von Hand machen zu wollen ( und damit das Rad zweimal zu erfinden). Das ist langsam und uneffektiv. Würde jeder seine Graphikschnittstellen selber programmieren ( = ohne DX) dann hätten wie eine Entwicklungsdauer von 10 Jahren pro Spiel.

Es ist eben hauptsächlich der Effizienzgewinn der es so intressant macht (vorallem für Unternehmen). Alles kann man aber (zum Glück) damit (noch) nicht machen, vorallem wenn man mal was machen will was nicht einfach durch Klicken gelöst werden kann kommt man schnell an seine Grenzen und dann ist Basiswissen wieder gefragt.

Ich sehs mehr als Erweiterung anstatt Einschränkung in meinen Möglichkeiten.

Crushinator

2004-10-01, 17:56:24

Es reicht aber leider nicht mehr alles von Hand machen zu wollen ( und damit das Rad zweimal zu erfinden). Das ist langsam und uneffektiv. Würde jeder seine Graphikschnittstellen selber programmieren ( = ohne DX) dann hätten wie eine Entwicklungsdauer von 10 Jahren pro Spiel. (...) Diese Argumentation, besonders die Entwicklungsdauer deckt sich jedoch nicht mit der solcher Titeln wie NWN, UT2003 oder Quake, welche auf anderen Plattformen und ohne Klicki-Bunti Entwicklungsumgebungen mehr oder minder gleichzeitig erschienen. Von den alten DOS-Spielen mal ganz zu schweigen, die eben so wenig in 10 Jahren entwickelt wurden. Man muß mit anderen Worten nicht alles neu erfinden. ;)
Ich sehs mehr als Erweiterung anstatt Einschränkung in meinen Möglichkeiten.Klar, ist es ja auch. Nur führt sie auch dazu, daß zukünftige Entwickler vieles an Grundwissen nicht mehr erlernen, weil es zum Opfer der Effizienzsteigerung wurde.

Xmas

2004-10-01, 18:18:16

Du stellst es hin, als würde man in anderen Sprachen zwangsläufig unzählige Handles/Pointer benötigen. Ich habe kürzlich einem Member dieses Forums einen TCP-Server mit konfigurierbarem Feedback auf Requests (mit GUI und multithreaded Mehrclientfähig) geschrieben, damit er die SMTP-Funktionalität eines ca. 2 Watt verbrauchenden microcontroler ähnlichen Gerätes ohne einen echten SMTP-Server testen kann. Ich schrieb das Ding mit Delphi, während ich mich mit ihm nebenbei im IRC unterhielt. ca. eine Stunde später hatte er eine lauffähige Version und nach insgesamt weiteren 3 Std. wurden all seine Wünsche, soweit er sie äußerte, berücksichtigt. Dabei kann ich mich nicht einmal daran erinnern, expliziten Gebrauch von Pointern oder Handles gemacht zu haben.
Was doch wohl daher rührt, dass Delphi ebenso ein gutes Framework zur verfügung stellt. Wogegen wehrst du dich dann genau?

Ich sehe hier keine Ersetzung von Spezialisten durch schlechter Ausgebildete. Es verschieben sich lediglich die Aufgaben. Die höher Spezialisierten arbeiten den weniger Spezializierten zu, und während das Verhältnis Spezialisten pro Nicht-Spezialisten sinkt, steigt die absolute Zahl der Nicht-Spezialisten, die in der Lage sind entsprechende Programme zu nutzen.

Sicher, die Arbeit eines Nicht-Spezialisten ist möglicherweise weniger effizient, nicht so elegant und vielleicht nicht erweiterbar. Nur ist das in vielen simplen Fällen trotzdem ausreichend. Wenn nicht, kann ja immer noch ein Spezialist einspringen. Dafür hat der Nicht-Softwareentwickler eben anderes, Problembezogenes Spezialwissen.

Jesus

2004-10-01, 18:26:47

Diese Argumentation, besonders die Entwicklungsdauer deckt sich jedoch nicht mit der solcher Titeln wie NWN, UT2003 oder Quake, welche auf anderen Plattformen und ohne Klicki-Bunti Entwicklungsumgebungen mehr oder minder gleichzeitig erschienen.

Naja das ist wieder OpenGL und Dx :) Ich meinte eigentlich ein Level drunter, also z.b. Bresenham nochmal selber zu implementieren. Viel spass... :rolleyes:

Crushinator

2004-10-01, 18:45:34

Was doch wohl daher rührt, dass Delphi ebenso ein gutes Framework zur verfügung stellt. Wogegen wehrst du dich dann genau? Ich wehre mich gegen Trivial-Anwendungen, die a) in ihrem Ressourcenverbrauch native deutlich übersteigen, b) ohne extra installierte Runtime nicht lauffähig sind und c) ich als Entwickler den Quellcode der mitgelieferten Komponenten nicht mal bei Bedarf verändern/erweitern kann. Ganz zu schweigen davon daß d) ich keinen Bock darauf habe, mich der Art in eine Anhängigkeit eines nicht gerade für Offenheit bekannten Monopolisten zu begeben. Wie gesagt: Bei ersichtlichem Bedarf an solchen Tools ja, ansonsten nein. Ich muß nicht alles - Die Control Panels der beiden großen IHVs lassen grüßen - mit .Net erledigen.
Ich sehe hier keine Ersetzung von Spezialisten durch schlechter Ausgebildete. Es verschieben sich lediglich die Aufgaben. Die höher Spezialisierten arbeiten den weniger Spezializierten zu, und während das Verhältnis Spezialisten pro Nicht-Spezialisten sinkt, steigt die absolute Zahl der Nicht-Spezialisten, die in der Lage sind entsprechende Programme zu nutzen. Je mehr Nichtspezialisten, desto mehr was von ihnen stammt. Nicht ganz aber dennoch vergleichbar mit "je mehr Fernostprodukte, desto billiger muß hier produziert werden, desto mehr nimmt die Qualität ab, desto mehr minderwertige Qualität, teils Wegwerfware kommt auf den Markt." Hat sicher alles Vor- und Nachteile, ich sehe aus meinem Standpunkt halt mehr die Nachteile.
Sicher, die Arbeit eines Nicht-Spezialisten ist möglicherweise weniger effizient, nicht so elegant und vielleicht nicht erweiterbar. Nur ist das in vielen simplen Fällen trotzdem ausreichend. Wenn nicht, kann ja immer noch ein Spezialist einspringen. Dafür hat der Nicht-Softwareentwickler eben anderes, Problembezogenes Spezialwissen.Die Gefahr besteht - wie Quasar schon schrieb - eben auch darin, daß auch die Spezialisten irgendwann zu "Blackbox-Bedienern" werden, weil es keine Werkzeuge mehr gibt, um diese Boxen zu öffnen. ;)

Kennung Eins

2004-10-01, 19:02:11

Also, ist es kein vollkommener Quatsch, sondern wie Du selbst schreibst eben möglich, wenn auch selten anzutreffen, weshalb ich Gebrauch von "nicht unbedingt" machte. ;)
Du stellst es hin, als würde man in anderen Sprachen zwangsläufig unzählige Handles/Pointer benötigen. Ich habe kürzlich einem Member dieses Forums einen TCP-Server mit konfigurierbarem Feedback auf Requests (mit GUI und multithreaded Mehrclientfähig) geschrieben, damit er die SMTP-Funktionalität eines ca. 2 Watt verbrauchenden microcontroler ähnlichen Gerätes ohne einen echten SMTP-Server testen kann. Ich schrieb das Ding mit Delphi, während ich mich mit ihm nebenbei im IRC unterhielt. ca. eine Stunde später hatte er eine lauffähige Version und nach insgesamt weiteren 3 Std. wurden all seine Wünsche, soweit er sie äußerte, berücksichtigt. Dabei kann ich mich nicht einmal daran erinnern, expliziten Gebrauch von Pointern oder Handles gemacht zu haben.Will man wirklich performante, speicheroptimierte Programme schreiben, so kommt man auch bei OOPascal nicht um Pointer herum.

Schreib mal ein Programm mit Delphi auf API-Basis, dann weißt du, was ich meine.
Wie gesagt - Zwischenschritte. Noch weiß vielleicht jeder solche Dinge, aber wenn die Umgebungen das nicht mehr voraussetzen, wird auch ein Programmierbaukasten in ein paar Jahren zu einem Klicki-Bunti Puzzle.
Das UI hat's ja bereits 'erfolgreich' vorgemacht.

Wo du grade 'Gedanken machen' ansprichst - genau das wurde dem User bereits erfolgreich abgenommen, 'wizards' aller Orten.
Meinst du nicht, daß man auf demselben Wege ist, zunächst mal nur eine bestimmte Gruppe an Entwicklern in dieselbe Richtung zu führen?

Schau dir mal die Virenbaukästen an, über die so viel geschrieben wird: Programmentwicklung für Jedermann - schnell erlernt, schlampig zusammengeschustert. Aber wirklich wissen, was sie da machen, das tun nur noch die wenigsten.

Darum geht's mir - das Grundsatzwissen wird mehr und mehr zurückgedrängt und man fokussiert sich auf die Aufgabenstellung. Das wäre IMO nicht weiter problematisch, würde damit nicht die Möglichkeit einhergehen, nach dem User auch den Entwickler langsam zum 'Black-Box Bediener' zu degradieren.

edit:
Nur zum besseren Verständnis: Ich bin kein Programmierer - es hat daher wenig Sinn, sich mit mir über Implementationsspezifika unterhalten zu wollen. Ich versuche mehr, das Gesamtbild zu sehen und abzuschätzen, wohin uns das führen kann.
Für mich als Enduser habe ich funktional keine Probleme mit .NET - nur die Philosophie von M$, die ich dahinter sehe, behagt mir nicht.
Du hast noch nicht mit VS.NET gearbeitet, oder?
Zeig mir einen Wizard, der kompletten Code ausspuckt. Sowas gibt es nicht.

Es gibt höchstenfalls wizards, die dir gleich ein leeres Codegerüst hinstellen, was ausschließlich Tipp-Arbeit spart, aber nicht Implementierungsarbeit.Diese Argumentation, besonders die Entwicklungsdauer deckt sich jedoch nicht mit der solcher Titeln wie NWN, UT2003 oder Quake, welche auf anderen Plattformen und ohne Klicki-Bunti Entwicklungsumgebungen mehr oder minder gleichzeitig erschienen.Sprichst du in diesem ganzen Gespräch eigentlich über die ENTWICKLUNGSUMGEBUNG?? :confused:
.NET ist ja wohl ein bisschen mehr, als eine "Entwicklungsumgebung".

Jesus

2004-10-01, 19:10:04

Du hast noch nicht mit VS.NET gearbeitet, oder?
Zeig mir einen Wizard, der kompletten Code ausspuckt. Sowas gibt es nicht.

Uber-OT:

Doch Statemate kann das :) Allerdings nur aus Zustandsautomaten generierter C Code ;)

Sowas gibts bestimmt bald auch für Windows, du "zeichnest" dann nur noch deinen Code :P

Kennung Eins

2004-10-01, 19:34:45

Uber-OT cont.:

Hmm ich kann mir vorstellen, daß man gut aus UML-Diagrammen "fast fertigen" Code erstellen kann ...
Doch ich bin nicht firm mit praktischen UML-Anwendungen. (Rational Rose?)

Quasar

2004-10-01, 19:46:56

Du hast noch nicht mit VS.NET gearbeitet, oder?

Nein. Sag' bloß, das merkt man.... :rolleyes:
(hast du meinen letzten Absatz nicht gelesen, den du mitgequotet hast? ;))

Zeig mir einen Wizard, der kompletten Code ausspuckt. Sowas gibt es nicht.

Den Bezug zu wizards stellte ich ausschließlich für User her - User, die Windows 'benutzen' und die man früher als DAUs bezeichnet hätte - nicht Entwickler.

Ich dachte, daß ich das durch den Folgesatz, in dem ich Entwickler separat ansprach, ausreichend unterschieden.
("Wo du grade 'Gedanken machen' ansprichst - genau das wurde dem User bereits erfolgreich abgenommen, 'wizards' aller Orten.
Meinst du nicht, daß man auf demselben Wege ist, zunächst mal nur eine bestimmte Gruppe an Entwicklern in dieselbe Richtung zu führen?")

StefanV

2004-10-01, 19:53:29

Kennung Eins

2004-10-01, 19:58:46

Nein. Sag' bloß, das merkt man.... :rolleyes:
(hast du meinen letzten Absatz nicht gelesen, den du mitgequotet hast? ;))Du könntest VS.NET doch z.B. für Erstellung von Homepages verwenden ...

("Wo du grade 'Gedanken machen' ansprichst - genau das wurde dem User bereits erfolgreich abgenommen, 'wizards' aller Orten.
Meinst du nicht, daß man auf demselben Wege ist, zunächst mal nur eine bestimmte Gruppe an Entwicklern in dieselbe Richtung zu führen?")Es ist schon etwas anderes.

Bei VB würde ich dir sofort zustimmen, denn das ist wirklich was für solche Leute. Und das setzt (was deiner Aussage völlig entgegen kommt) ja inzwischen auf .NET auf. Aber das, was es "so einfach" macht für den Nutzer, ist ja die Sprache an sich, und nicht .NET.

Und es ist eben _nicht einfach_ VB und "mal eben" Anwendungen zusammenklicken.

LordDeath

2004-10-01, 20:00:02

Öhm, man munkelt, daß .NET Proggies auch unter Linux laufen ;)

Zumindest gibts 'nachahmungen' vom .NET Framewor, unter anderem Momo und GPLNET (oder so)...

ja, das wär aber was anders, wenn microsoft eine linux .net framework bereitstellen würde!

grakaman

2004-10-01, 20:14:02

ja, das wär aber was anders, wenn microsoft eine linux .net framework bereitstellen würde!

Wieso wäre das was anderes? Viele Hersteller in der Java Welt implementieren ihr eigenes J2EE Framework her.

grakaman

2004-10-01, 20:33:30

Ich wehre mich gegen Trivial-Anwendungen, die a) in ihrem Ressourcenverbrauch native deutlich übersteigen, b) ohne extra installierte Runtime nicht lauffähig sind und c) ich als Entwickler den Quellcode der mitgelieferten Komponenten nicht mal bei Bedarf verändern/erweitern kann.

Jetzt pendelst du dich langsam wieder auf dein übliches Niveau ein. Was den Quellcode anpassen bestrifft, anscheinend hast du nicht wirklich verstanden, wie man objekt orientiert programmiert. Und dass deine Trivialanwendungen den Ressourcenverbrauch maßlos übersteigen, ist einfach nur eine große Lüge.

Ganz zu schweigen davon daß d) ich keinen Bock darauf habe, mich der Art in eine Anhängigkeit eines nicht gerade für Offenheit bekannten Monopolisten zu begeben.

Oh ja, die große Microsoftverschwörung. Falls du hier ernsthaft diskutieren willst, solltest du deine hirnrissigen Parolen lieber stecken lassen. Vielleicht gehst du ja auch mal auf die vielen Javaentwickler ein, aber dann kannst du ja die Diskussion nicht immer auf dein übliches Anti-Microsoft Geschwafel reduzieren.

Wie gesagt: Bei ersichtlichem Bedarf an solchen Tools ja, ansonsten nein. Ich muß nicht alles - Die Control Panels der beiden großen IHVs lassen grüßen - mit .Net erledigen.

Du sollst hier gar nichts machen, dann lass es bitte bleiben. Aber laber hier nicht von Dingen rum, von denen du ganz offendichtlich keinen Blassen hast. Aber hier Klischees plefgen ist freilich bequemer, als mal Argumente zu bringen.

Je mehr Nichtspezialisten, desto mehr was von ihnen stammt. Nicht ganz aber dennoch vergleichbar mit "je mehr Fernostprodukte, desto billiger muß hier produziert werden, desto mehr nimmt die Qualität ab, desto mehr minderwertige Qualität, teils Wegwerfware kommt auf den Markt." Hat sicher alles Vor- und Nachteile, ich sehe aus meinem Standpunkt halt mehr die Nachteile.

Und wer sagt mir, dass du nicht auch so eine billige Chinaware bist? Sich hier im Forum aufspielen und den großen markieren, kann jeder.

Die Gefahr besteht - wie Quasar schon schrieb - eben auch darin, daß auch die Spezialisten irgendwann zu "Blackbox-Bedienern" werden, weil es keine Werkzeuge mehr gibt, um diese Boxen zu öffnen. ;)

Es gibt Werkzeuge, um diese Blackboxen zu öffnen. Allerdings muss man da schon Ahnung haben, wovon man redet. Das hast du offensichtlich nicht, ganz zu schweigen, von deinem fehlenden Verständnis von objekt orientierer Programmierung.

Kennung Eins

2004-10-01, 21:19:20

Crushinator

2004-10-01, 21:53:44

(...) Sprichst du in diesem ganzen Gespräch eigentlich über die ENTWICKLUNGSUMGEBUNG?? :confused:
.NET ist ja wohl ein bisschen mehr, als eine "Entwicklungsumgebung". Wenn Du einen besseren Vorschlag hast, wie ich es hätte als Antwort auf den Beitrag von Jesus besser ausdrücken sollen, daß man unter Linux - besonders zu dem Zeitpunkt wo die genannten Spiele entwickelt wurden - eben keine, nennen wir sie jetzt mal so, unheimlich benutzerfreundlichen IDEs für den GCC geschweige denn solche von Euch in den Himmel gelobten SDKs und Frameworks zur Verfügung hatte, dann höre ich mir das gerne mal an. ;)

Crushinator

2004-10-01, 22:07:24

Öhm, man munkelt, daß .NET Proggies auch unter Linux laufen ;) (...) Ganz toll, ehrlich. ;) Selbst wenn Mono jemals einen "fertigen" Status bekäme, würde es nichts an die Geschwindigkeit und den Ressourcenverbrauch von solchen Bytecode-Programmen mit einer Riesenruntime im Hintergrund ändern, schon gar nichts daran, daß man nicht eben alles mit .Net erschlagen muß, nur weil manche Dinge damit einfacher zu realisieren scheinen als mit den plattformspezifischen Nativcompilern.

aths

2004-10-01, 22:08:50

Falls du hier ernsthaft diskutieren willst, solltest du deine hirnrissigen Parolen lieber stecken lassen.Und du solltest dir einen vernünftigen Tonfall angewöhnen.

grakaman

2004-10-01, 22:18:01

Und du solltest dir einen vernünftigen Tonfall angewöhnen.

Wer jede Diskussion immer in die selbe substanzlose Richtung Lenkt, vom bösen Buhmann und der Microsoftweltverschwörung und nebenbei auch wahnwitzige Unterstellungen macht, der kann keine adäquatere Antwort erwarten.

Crushinator

2004-10-01, 22:18:38

Jetzt pendelst du dich langsam wieder auf dein übliches Niveau ein. Was den Quellcode anpassen bestrifft, anscheinend hast du nicht wirklich verstanden, wie man objekt orientiert programmiert. Und dass deine Trivialanwendungen den Ressourcenverbrauch maßlos übersteigen, ist einfach nur eine große Lüge.Lieber Grakaman, um Deine gerade an den Tag gelgete Tonlage genau zu treffen müßte ich eigentlich antworten, daß ich OOP durch Visual Age for Smaltalk lernte, da wußtest Du vermutlich nicht mal, was ein Modeller ist, aber lassen wir das und bedienen uns lieber den lebenden Beispielen, was den Ressourcenverbrauch angeht. Da wären einmal das CCC von ATi und ansonsten hätte ich noch das (http://www.forum-3dcenter.org/vbulletin/showthread.php?t=99944) hier.

Ich bin mommentan zu Hause und wollte, wenn's Euch recht ist, mein WoE in Ruhe genießen. Nächste Woche präsentiere ich Euch noch mehr lebende Beispiele, wo .Net Binaries je nach dem zwischen 30 bis 200% langsamer als native Programme laufen und wieviel mehr sie an Ressourcen schlucken.

[edit]
Auf den Rest Deines Beitrages werde ich nicht mehr eingehen, weil ich Dein Diskussionsstil, die Tonlage und die Wortwahl unnötig herablassend und diskussionsunfreundlich finde, EOD.

grakaman

2004-10-01, 22:22:39

Also wie ich das sehe programmiert Crushi mit Delphi - und da stimmt es schon, daß ein default-Klickibunti-Programm viele Ressourcen braucht.

Das tut er freilich nicht, denn Delphi ist ja propritär.

grakaman

2004-10-01, 22:26:09

Ich bin mommentan zu Hause und wollte, wenn's Euch recht ist, mein WoE in Ruhe genießen. Nächste Woche präsentiere ich Euch noch mehr lebende Beispiele, wo .Net Binaries je nach dem zwischen 30 bis 200% langsamer als native Programme laufen und wieviel mehr sie an Ressourcen schlucken.

Was du hier presentieren willst, interessiert keine Sau. Da kannst du dich freilich weiterhin als Mr. Wichtig Mod aufspielen, bei den ganzen .NET Profis hier im 3DC. Warum versuchst du dein Missionierungsversuch mal nicht in entsprechenden .NET Foren oder NG's? Da reicht wohl dein Wissen dann doch nicht aus, Mr. Profi.

grakaman

2004-10-01, 22:28:42

Wenn Du einen besseren Vorschlag hast, wie ich es hätte als Antwort auf den Beitrag von Jesus besser ausdrücken sollen, daß man unter Linux - besonders zu dem Zeitpunkt wo die genannten Spiele entwickelt wurden - eben keine, nennen wir sie jetzt mal so, unheimlich benutzerfreundlichen IDEs für den GCC geschweige denn solche von Euch in den Himmel gelobten SDKs und Frameworks zur Verfügung hatte, dann höre ich mir das gerne mal an. ;)

Total hirnrissiger Vergleich, da Grafikintensive Entwicklungen, vor allem 3D, bis jetzt keinen großen Schwerpunkt in den Frameworks haben. Das wird sich wohl aber in Zukunft sicherlich ändern.

Crushinator

2004-10-01, 22:36:28

Also wie ich das sehe programmiert Crushi mit Delphi - und da stimmt es schon, daß ein default-Klickibunti-Programm viele Ressourcen braucht. Nein, mein leiber Kennung Eins, ich entwickle hauptsächlich in C und C++, soweit unter Windows mal mit VC++ 6 EE mal mit BCB 6 EE. Für triviale Dinge nehme ich oft Delphi, weil man da weniger tippen muß. Außerdem braucht ein einfaches GUI-Progrämmchen mit Delphi erstellt, wesentlich weniger Ressourcen als ein gleichwertiges jedoch mit managed C++ erzeugtes. Vielleicht verwendest Du ja mal das Programm der c't aus dem von mir im letzten Beitrag verlinkten Thread, um den Ressourcenverbrauch zu messen.
Aber wenn man sich damit schonmal beschäftigt hat, schreibt man sich halt seine nötigen Klassen selbst und kann super performante Anwendungen schreiben - wie auch bei .NET :)An Ironie nicht zu übertreffen. :up:

Crushinator

2004-10-01, 22:43:30

Das tut er freilich nicht, denn Delphi ist ja propritär.Soweit mich meine Augen nicht täuschen, sehe ich gerade vor mir den Quallcode der gesamten VCL und CLX. Noch schlimmer, jede Komponente liegt in Sourceform vor. OMG, scheinbar werden sie mit dem Compiler gleich mitgeliefert...

StefanV

2004-10-01, 22:45:03

Öhm, Tschuldigung, will ja eure Diskussion nicht stören, aber wäre es an dieser Stelle nicht besser aus 1 2 zu machen und die andere Hälfte im Progger Forum unterzubringen?! :|

Crushinator

2004-10-01, 22:53:53

Ich bitte ebenfalls Entschuldigung, daß ich mich weiter dazu habe hinreissen lassen. Da jedoch einige von den Beiträgen sehr wohl im direkten Zusammenhang (Triviale Desktopanwendungen) mit dem Topic angesehen werden können, lasse ich sie lieber alle stehen und verabschiede mich aus diesem Thread. :)

Kennung Eins

2004-10-01, 23:22:12

Nein, mein leiber Kennung EinsWas ist denn jetzt los? Das war doch keine Beleidigung von mir, Delphi zu erwähnen.
Es ging einfach aus deiner Aussage hervor, daß du wohl Delphi benutzt (wie ich auch, bei den selben "einfachen" Aufgaben)., ich entwickle hauptsächlich in C und C++, soweit unter Windows mal mit VC++ 6 EE mal mit BCB 6 EE. Für triviale Dinge nehme ich oft Delphi, weil man da weniger tippen muß. Außerdem braucht ein einfaches GUI-Progrämmchen mit Delphi erstellt, wesentlich weniger Ressourcen als ein gleichwertiges jedoch mit managed C++ erzeugtes. Vielleicht verwendest Du ja mal das Programm der c't aus dem von mir im letzten Beitrag verlinkten Thread, um den Ressourcenverbrauch zu messen.Ich weiß nur, daß Delphi viele Ressourcen verbraucht. Einen Vergleich Delphi<->.NET Anwendung habe ich noch nicht gemacht.
An Ironie nicht zu übertreffen. :up:Warum? Ich meinte es nicht so (auch wenn es wirklich so klingt, hast recht), daß "from scratch" alles neu gemacht wird, sondern daß man sich eben z.B. aus der TRegistry nur seine nötigen Funktionen rausnimmt und ein neues Interface verwendet, was eben nur die benötigten Funktionen beschreibt.

Daß hier immer gleich alle so rumhacken müssen ...

aths

2004-10-02, 00:00:16

Wer jede Diskussion immer in die selbe substanzlose Richtung Lenkt, vom bösen Buhmann und der Microsoftweltverschwörung und nebenbei auch wahnwitzige Unterstellungen macht, der kann keine adäquatere Antwort erwarten.Eine Antwort im freundlichen Ton kann man immer erwarten, jedenfalls von jedem der gute Manieren hat.

Grestorn

2004-10-02, 11:48:50

Du stellst es hin, als würde man in anderen Sprachen zwangsläufig unzählige Handles/Pointer benötigen. Ich habe kürzlich einem Member dieses Forums einen TCP-Server mit konfigurierbarem Feedback auf Requests (mit GUI und multithreaded Mehrclientfähig) geschrieben, damit er die SMTP-Funktionalität eines ca. 2 Watt verbrauchenden microcontroler ähnlichen Gerätes ohne einen echten SMTP-Server testen kann. Ich schrieb das Ding mit Delphi, während ich mich mit ihm nebenbei im IRC unterhielt. ca. eine Stunde später hatte er eine lauffähige Version und nach insgesamt weiteren 3 Std. wurden all seine Wünsche, soweit er sie äußerte, berücksichtigt. Dabei kann ich mich nicht einmal daran erinnern, expliziten Gebrauch von Pointern oder Handles gemacht zu haben.Und worin unterscheiden sich nun grundsätzlich die Laufzeitumgebungen von Delphi und .net?

Beide stellen umfangreiche Klassenbibliotheken zur Verfügung, die es dem Entwickler ermöglichen, mit verhältnismäßig wenig Aufwand Software zu schreiben, die einen gewissen Anspruch an die Oberfläche erfüllen.

Den eigentlichen funktionalen Kern der Applikation wird ein Laufzeitsystem nie abdecken können, nur wenn es um Schnittstellen (zum Anwender und zu anderen Komponenten) und Standardfunktionen geht, wie z.B. das Verwalten von Sockets und Verbindungen, vereinfacht es die Arbeit.

Und ob Software gut oder schlecht ist (Architektur & Design, Stabilität, Ausbaubarkeit) wird nicht durch die Sprache oder die Laufzeitumgebung vorgegeben, sondern durch den Programmierer. Natürlich kann auch dabei die Sprache unterstützen, aber die richtige Nutzung der Möglichkeiten obliegt immer noch dem Programmierer.

In so fern halte ich Deine Vorbehalte gegen .net für ein wenig unverständlich, insbesondere, nachdem Du offensichtlich ein Spezialist für Softwareentwicklung in Delphi (und sicher noch mehr) bist. Delphi und .net haben aber deutlich mehr Gemeinsamkeiten als Unterschiede.

StefanV

2004-10-02, 12:21:29

Öhm, ist ein weiterer Vorteil von .NET Apps nicht auch, daß die die Registry nicht vollmüllen müssen bzw ein Schritt 'to good old days' (=ini Dateien)?? ;)

grakaman

2004-10-02, 13:04:18

Soweit mich meine Augen nicht täuschen, sehe ich gerade vor mir den Quallcode der gesamten VCL und CLX. Noch schlimmer, jede Komponente liegt in Sourceform vor. OMG, scheinbar werden sie mit dem Compiler gleich mitgeliefert...

Das etwas im Source Code mitgeliefert wird, macht es nicht weniger propritär. Delphi ist propritär. Oh Gott, du benutzt ja propritäre Software und bindest dich an Borland. Was ist denn nun, wenn Borland die Weltherrschafft anstrebt?

Crushinator

2004-10-02, 15:13:00

(...) Ich weiß nur, daß Delphi viele Ressourcen verbraucht. Einen Vergleich Delphi<->.NET Anwendung habe ich noch nicht gemacht. (...) Kennst Du Total Commander (http://www.ghisler.com/deutsch.htm) oder um ganz topic-nah zu bleiben, den aTuner (http://www.3dcenter.de/atuner/) von aths? Es sind beide mit Delphi realisiert, und ich kann mich nicht daran erinnern, daß diese Anwendungen - ganz im Gegensatz zu ATis CCC - für hohen Ressourcenverbrauch bekannt seien. ;)

Crushinator

2004-10-02, 16:42:06

Und worin unterscheiden sich nun grundsätzlich die Laufzeitumgebungen von Delphi und .net? (...) Die Delphi-Anwendungen (bis V7) brauchen keine Laufzeitumgebung in dem Sinne. Wenn man Wert auf Typensicherheit und andere Dinge legt, welche eine solche Umgebung benötigten, kann man sie statisch (sogar partiell) in die .Exe linken lassen oder eben dynamsich ala MSVCRT linken. Gleiches gilt für Borlands C++ Builder (bis V6) und beide haben gemeinsam, daß die gesamten zugrundeliegenden Klassenbibliotheken (VCL,CLX und fast 100% der Zusatzkomponenten) im Gegensatz zu den des .Net Framework in Sourceform vorliegen.

Die erstellten Anwendungen laufen somit bei statischem Linken der zur Laufzeit benötigten Komponenten auch auf Win95a, ohne daß zusätzlich etwas installiert werden muß. Wenn man unbedingt Wert auf sehr kleine Dateigrößen legt, linkt man eben dynamisch und installiert ggf. die benötigte(e) DLL(s) auf dem Zielrechner.

Delphi gibt es seit Anfang diesen Jahres in der 8ten Version und diese nennt sich Delphi for MS .Net Framework (http://www.borland.de/delphi_net/index.html) und das Ergebnis der Übersetzung bestehender Projekte - soweit überhaupt möglich - sieht leider oft so (http://www.forum-3dcenter.org/vbulletin/showthread.php?t=156154) aus. ;(
In so fern halte ich Deine Vorbehalte gegen .net für ein wenig unverständlich, insbesondere, nachdem Du offensichtlich ein Spezialist für Softwareentwicklung in Delphi (und sicher noch mehr) bist. Delphi und .net haben aber deutlich mehr Gemeinsamkeiten als Unterschiede.Ich erkläre es jetzt zum allerletzten mal: :) Wenn ich in etwa all das, was .Net mir als Entwickler bringen soll, bereits mit anderen Entwicklungswerkzeugen und jahrelang entwickelten Eigenbibliotheken haben sollte, warum zum Himmel muß ich dann (ich meine mich persönlich) einen Freudentanz über .Net aufführen? Warum erwartet Ihr das von mir? Meine persönlichen Kontras gegen .Net schrieb ich sogar Punkt für Punkt in einem Beitrag an Xmas. Aber anstatt speziell diese mit nachvollziehbaren Argumenten zu entkräften, oder über jeden Punkt normal zu diskutieren, wird mit Unterstellungen und Beleidigungen (Du bist hier natürlich nicht gemeint) nur auf mir rumgehackt.

grakaman

2004-10-02, 17:21:30

Ich erkläre es jetzt zum allerletzten mal: :) Wenn ich in etwa all das, was .Net mir als Entwickler bringen soll, bereits mit anderen Entwicklungswerkzeugen und jahrelang entwickelten Eigenbibliotheken haben sollte, warum zum Himmel muß ich dann (ich meine mich persönlich) einen Freudentanz über .Net aufführen? Warum erwartet Ihr das von mir? Meine persönlichen Kontras gegen .Net schrieb ich sogar Punkt für Punkt in einem Beitrag an Xmas. Aber anstatt speziell diese mit nachvollziehbaren Argumenten zu entkräften, oder über jeden Punkt normal zu diskutieren, wird mit Unterstellungen und Beleidigungen (Du bist hier natürlich nicht gemeint) nur auf mir rumgehackt.

Nur mal so zur Klarstellung, hier erwartet man überhaupt nichts von dir. Du bist der jenige, der andere als Daus und Halbprofis deklassiert, von minderwertiger Qualität spricht, von propritären Gefahren wettert und dann selbst Delphi verwendet. Und trotz alle dem bist du uns noch immer den Beweis schuldig, wie effizient du denn
die Dinge auf herkömmliche Art und Weise mit C++ erledigst. Ganz besondern interessiert mich das in Bezug auf Thin Clients und Deployment.

Kennung Eins

2004-10-02, 17:43:21

Kennst Du Total Commander (http://www.ghisler.com/deutsch.htm) oder um ganz topic-nah zu bleiben, den aTuner (http://www.3dcenter.de/atuner/) von aths? Es sind beide mit Delphi realisiert, und ich kann mich nicht daran erinnern, daß diese Anwendungen - ganz im Gegensatz zu ATis CCC - für hohen Ressourcenverbrauch bekannt seien. ;)Ok, you got me there ... denn: was sind "viele" Ressourcen?

Kennst du das GeForce Tweak Utility (http://www.guru3d.com/geforcetweakutility)? Das ist von mir.
Einen großen Mangel z.B. ggü Rivatuner sah ich immer darin, daß die Anwendung viel zu viel Speicher verbraucht (8mb oder so wenn ich mich recht erinnere).
Ich habe angefangen ein GTU 4.0 zu schreiben, was nur auf API-Basis beruht, das verbraucht nur 1.6mb - und das obwohl eine Menge BMPs geladen wurden - mittels Delphi/OOPascal.
(Nur um das der Fairness halber zu erwähnen: Das CCC hat wesentlich mehr "bunte" Komponenten, allein schon dadurch schießt der Speicherverbrauch in die Höhe)

Das ist das, was ich ursprünglich hiermit sagen wollte:
Will man wirklich performante, speicheroptimierte Programme schreiben, so kommt man auch bei OOPascal nicht um Pointer herum.

Schreib mal ein Programm mit Delphi auf API-Basis, dann weißt du, was ich meine.

Kennung Eins

2004-10-02, 17:51:33

Aber anstatt speziell diese mit nachvollziehbaren Argumenten zu entkräften, oder über jeden Punkt normal zu diskutieren, wird mit Unterstellungen und Beleidigungen (Du bist hier natürlich nicht gemeint) nur auf mir rumgehackt.Irgendwie kommen wir hier in dem Gespräch vom Hundertsten ins Tausendste. Das, was ich eigentlich nicht mochte, war nur, daß jemand, der auf .NET arbeitet, gleich als "Halbprofi" bezeichnet wird.

Für mich ist das Thema damit jetzt erstmal beendet, denn eigentlich wurde ja alles schon gesagt.

Quasar

2004-10-02, 17:53:07

Aber anstatt speziell diese mit nachvollziehbaren Argumenten zu entkräften, oder über jeden Punkt normal zu diskutieren, wird mit Unterstellungen und Beleidigungen (Du bist hier natürlich nicht gemeint) nur auf mir rumgehackt.
Das ist hier immer so, wenn man keine Mainstream-Meinung vertritt. Ich persönlich mag diesen Stil auch nicht - scheine aber auch in diesem Punkt keine Mainstream-Meinung zu vertreten. ;)

edit:
Ich schreib das mal hier rein als Antwort auf untenstehendes Posting von Grakaman, weil ich nicht weiter OT hier rumposten mag: Mainstream ist hier z.B. ATi gut zu finden, immer weitergehende Optimierungen an Texturfiltern gutzuheißen, die mehr FPS vortäuschen, als mit der gegebenen Leistung erreichbar sind, AMD toll zu finden, WaKü toll zu finden, immer die neuesten BETA-Treiber installiert zu haben, ähhhh...., Win-KlickBunti toll zu finden usw....

grakaman

2004-10-02, 18:09:23

Das ist hier immer so, wenn man keine Mainstream-Meinung vertritt. Ich persönlich mag diesen Stil auch nicht - scheine aber auch in diesem Punkt keine Mainstream-Meinung zu vertreten. ;)

Wobei man hier erst einmal Mainstream definieren sollte. Das ewige Nörgeln und Diskutieren auf Basis von Ideologien und Gefühlen scheint nämlich ganz schön Mainstream geworden zu sein.

Grestorn

2004-10-02, 19:40:47

Die Delphi-Anwendungen (bis V7) brauchen keine Laufzeitumgebung in dem Sinne. Wenn man Wert auf Typensicherheit und andere Dinge legt, welche eine solche Umgebung benötigten, kann man sie statisch (sogar partiell) in die .Exe linken lassen oder eben dynamsich ala MSVCRT linken. Gleiches gilt für Borlands C++ Builder (bis V6) und beide haben gemeinsam, daß die gesamten zugrundeliegenden Klassenbibliotheken (VCL,CLX und fast 100% der Zusatzkomponenten) im Gegensatz zu den des .Net Framework in Sourceform vorliegen.Zunächst: Ich bin kein Experte für .net, in den letzten Jahren hatte ich nahezu ausschließlich mit Java und C++/MFC zu tun.

Den Vorteil die Laufzeitumgebung statisch zu linken sehe ich nicht, das ist eher ein Nachteil. Dadurch muss sie nicht nur immer zusammen mit der Software ausgeliefert werden (ggf. auch nur teilweise) sondern ist auch mehrfach auf der Platte. Bei immer größer werdenden Laufzeitumgebungen ist das nicht mehr sinnvoll.

Dass nur Teile der Klassenbibliothek von .net im Quellcode verfügbar sind hat einen Vor- und einen Nachteil.

Zunächst der Vorteil: Es ist einfach sehr praktisch in den Quellcode "reinzudebuggen", wenn man mit einem Stück Code Schwierigkeiten hat. Das hat mir gerade in der MFC (die von MS vollständig mit Quellcode ausgeliefert wird) schon oft geholfen.

Jetzt der Nachteil: Gerade bei MFC ist die Dokumentation oft schlecht und das Verhalten der Klassen nicht ganz korrekt oder man muss sich das genaue Verhalten aus dem Source der MFC schließen. Das führt dann oft dazu, dass der Programmierer sehr speziell auf den vorhandenen Code der MFC programmiert, um Probleme zu umgehen oder bestimmte Dinge zu erreichen, die sonst nicht oder nur sehr schwer möglich wären. Bei einem Update der MFC ist die Gefahr, dass man seine Applikation auch anpassen muss, sehr hoch.

Bei einer Klassenbibliothek deren Quellcode nicht vollständig vorhanden ist (z.B. Java) sind ganz andere Anforderungen an die Qualität der Dokumentation zu stellen. Ausserdem muss bei der Konzeption der Klassen in der Bibliothek immer darauf geachtet werden, dass der Programmierer deren Code nicht kennt und Anpassungen (z.B. durch überschreiben der Methoden) nur auf Basis der Dokumentation vornehmen kann. Das zwingt im Allgemeinen zu einem wesentlich saubereren Design der Klassenbibliothek. Jedenfalls sind mir die Quellen in Java noch nie abgegangen (obwohl sie in Teilen durchaus auch zur Verfügung stehen).

Ansonsten gebe ich Dir vollkommen recht, dass die Qualität der Software in den letzten Jahren immer weiter sinkt. Mit immer weniger Aufwand soll immer mächtigere Software entstehen. Einerseits helfen die immer umfangreicheren Tools und Bibliotheken dabei, andererseits bleibt die Qualität und Performance immer öfter auf der Strecke, gerade auch bei den Laufzeitsystemen/Bibliotheken.

Das ist das Übel, nicht .net, Delphi, Visual Basic oder Java.

.net mag noch nicht ausgereift und performant sein, und es sicher möglich sehr schlechte Software damit zu schreiben. Ersteres galt auch mal für Java, inzwischen sind die richtig weit gekommen. Schlechte Software gibts dennoch zu Hauf für Java - genauso wie echte Perlen.

Jeder, der sich dogmatisch gegen etwas verschließt schadet sich am Ende nur selber.

r@h

2004-10-03, 08:59:18

Öhm, ist ein weiterer Vorteil von .NET Apps nicht auch, daß die die Registry nicht vollmüllen müssen bzw ein Schritt 'to good old days' (=ini Dateien)?? ;)Dafür sorgt .NET doch schon selbst.
Hast Du Dir mal angeschaut, was da alles bei der Installation in die Registery geschrieben wird?

OK, gefährlich mag es nicht sein, wie Demirug ja schon ausführte (ich habe mich nie duch diesen ganzen Wust gewühlt), aber trotzdem ist es nicht einzusehen, dass sich .NET überall 'einklinkt'. Das tuen 'normale' Programme nicht (in diesem Umfang ;-), insoern Dein Argemnt doch für die Katz ist, oder?

Schön dass .NET-basierende Proggis nicht mehr in die Registery schreben, wenn .NET selber dies schon getan hat und das in einem Umfang, der wohl schlicht einzig ist.

Razor

P.S.: Hat bis hierhin denn mal jemand überhaupt einen Beleg für effiziente Programmierung unter .NET erbracht?
Oder wird hier einfach nur rungefaselt und damit ausschließlich theoretisiert?
.NET ist (für mich!) die neueste Möglichkeit wahrhaftig "quick & dirty" zu proggen... nicht mehr, aber auch nicht weniger.
Und so etwas unterstütze ich nicht!

r@h

2004-10-03, 09:31:08

Was du hier presentieren willst, interessiert keine Sau. Da kannst du dich freilich weiterhin als Mr. Wichtig Mod aufspielen, bei den ganzen .NET Profis hier im 3DC. Warum versuchst du dein Missionierungsversuch mal nicht in entsprechenden .NET Foren oder NG's? Da reicht wohl dein Wissen dann doch nicht aus, Mr. Profi.Dann bring Du endlich Beispiele für effiziente Programmierung unter .NET!
DU bist es, der hier nur rumfaselt und lediglich theoretische Argumente für .NET beizutragen weiß.

Mich interessieren solche Beispiele sehr wohl, wie auch solche, die die Effizienz von .NET-Produkten belegen...
(wenn es sie denn gibt ;-)

Razor

r@h

2004-10-03, 09:34:36

Kennst du das GeForce Tweak Utility (http://www.guru3d.com/geforcetweakutility)? Das ist von mir.Würdest Du ein solches Tool unter .NET schreiben wollen?
:confused:

Razor

r@h

2004-10-03, 09:37:40

Dies hier möchte ich einfach nochmal wiederholt sehen:

Doch Quasar, ich bin mir durchaus über die Tragweite bewußt, und es freut mich, daß wenigstens Einer zwischen den Zeilen lesen konnte. Ich wollte damit nur ergänzend zu Razors Ausführungen verdeutlichen, daß es den Halbspezialisten Vorteile bringt, und daß es diese sind, die am Endeffekt dafür sorgen, daß wir. a) ggf. minderwertige Qualität bekämen und b) weiterhin am Tropf vom Monopolisten hängen blieben.Denn dem kann ich nur zu 100% zustimmen.
Und das CCC von ATI ist ein wunderbares Beispiel dafür...
(minderwertige Qualität und Monopolfestigung in einem Produkt ;-)

In diesem Sinne

Razor

Kennung Eins

2004-10-03, 09:51:25

Würdest Du ein solches Tool unter .NET schreiben wollen?
:confused:

Razor
Aus welchem Grund sollte ich das nicht wollen? Wenn ich gut genug in (e.g.) C# wäre, könnte ich das durchaus machen.

Nur ist C# eben nicht meine stärkste Programmiersprache.

Xmas

2004-10-03, 16:07:55

Ich wehre mich gegen Trivial-Anwendungen, die a) in ihrem Ressourcenverbrauch native deutlich übersteigen, b) ohne extra installierte Runtime nicht lauffähig sind und c) ich als Entwickler den Quellcode der mitgelieferten Komponenten nicht mal bei Bedarf verändern/erweitern kann. Ganz zu schweigen davon daß d) ich keinen Bock darauf habe, mich der Art in eine Anhängigkeit eines nicht gerade für Offenheit bekannten Monopolisten zu begeben. Wie gesagt: Bei ersichtlichem Bedarf an solchen Tools ja, ansonsten nein. Ich muß nicht alles - Die Control Panels der beiden großen IHVs lassen grüßen - mit .Net erledigen.
Nein, musst du sicher nicht. Was beim CCC leider viel zu oft übersehen wird ist dass es viel mehr ist als das alte CP. Die Leute regen sich dann über .NET auf, dabei ist es möglicherweise nur aus Sicht der "Puristen" schlechtes Design. ATI wollte ein erweiterbares Panel. Das ist mit .NET sehr simpel zu realisieren.

a) Welche Ressourcen meinst du genau. Zum Speicherverbrauch von GC-Anwendungen habe ich ja schon was geschrieben.
b) Das Thema wird sich ja dann mit Longhorn erledigen. Klar ist es erst einmal nervig, für eine 1MiB-Anwendung nochmals 20MiB aus dem Netz ziehen zu müssen, das verstehe ich durchaus. Wenn man viele .NET-Anwendungen verwendet kann sich das aber durchaus umkehren.
c) Das kannst du bei vielen anderen Paketen auch nicht. Aber sicher, wenn dafür Bedarf besteht solltest du eben nicht .NET verwenden. Mich hat das bisher noch nicht gestört.
d) Firmenpolitik spielt für mich bei der Wahl der Tools eine geringe Rolle.

Je mehr Nichtspezialisten, desto mehr was von ihnen stammt. Nicht ganz aber dennoch vergleichbar mit "je mehr Fernostprodukte, desto billiger muß hier produziert werden, desto mehr nimmt die Qualität ab, desto mehr minderwertige Qualität, teils Wegwerfware kommt auf den Markt." Hat sicher alles Vor- und Nachteile, ich sehe aus meinem Standpunkt halt mehr die Nachteile.
Wenn der Bedarf an Software steigt, kann nicht mehr alles von den besten Entwicklern erledigt werden. Wenn hohe Qualität entscheidende Vorteile bringt, wird sie sich am Markt auch durchsetzen.

Die Gefahr besteht - wie Quasar schon schrieb - eben auch darin, daß auch die Spezialisten irgendwann zu "Blackbox-Bedienern" werden, weil es keine Werkzeuge mehr gibt, um diese Boxen zu öffnen. ;)
Das Blackbox-Prinzip ist ein zentrales Element der Objekt- und Komponentenorientierung. Und bei steigender Komplexität der Projekte einfach häufig notwendig. Wenn du nur In-House-Komponenten verwendest, hast du natürlich volle Kontrolle, aber das kann sich kaum jemand erlauben. Du magst da in deiner Firma andere Erfahrungen gemacht haben.
Die Boxen muss ja auch irgendeiner mal entwickeln, dafür braucht es Spezialisten. Spezialisten braucht es auf jeder Kapselungsebene, nur ändern sich dann die Aufgaben. Wer statt selbst allen Code zu schreiben ein UML-Tool verwendet um einen Entwurf in Rahmencode zu überführen und dann den Rest auffüllt, ist nicht weniger "Spezialist", nur eben auf andere Dinge spezialisiert.

Quasar

2004-10-03, 16:17:17

b) Das Thema wird sich ja dann mit Longhorn erledigen.
Das denke ich auch - aber auf einer anderen Ebene.
Linux ist heute um ein vielfaches zugänglicher für Endbenutzer geworden, als damals, als es den letzten größeren "Windows-Update"-Upgrade-Schwung gab.

Und hier liegen, soweit mir bekannt, um ein vielfaches mehr Quellen offen für den, der sich für interne Funktionsweisen interessiert, als es unter Windows der Fall ist und soweit sich das sagen läßt, sein wird.

Crushinator

2004-10-03, 17:04:31

(...) Den Vorteil die Laufzeitumgebung statisch zu linken sehe ich nicht, das ist eher ein Nachteil. Dadurch muss sie nicht nur immer zusammen mit der Software ausgeliefert werden (ggf. auch nur teilweise) sondern ist auch mehrfach auf der Platte. Bei immer größer werdenden Laufzeitumgebungen ist das nicht mehr sinnvoll. Statisches linken der zur Laufzeit benötigten Funktionen == Alles befindet sich als Maschinensprachencode in der Executable, sprich in der "Exe-Datei". Es muß somit nichts gesondertes "zusammen mit der Software" ausgeliefert werden. Dadurch, daß nur das in die Executable hineinkommt, was zur Laufzeit benötigt wird, dürfte das Vorhandensein desselben Code in ggf. mehreren "Exe-Dateien" in den meisten Fällen zu verschmerzen sein, zumal wir in diesen Fällen von wenigen 100 KBs sprechen. Ein sehr großer Vorteil davon ist, daß man die Software sehr einfach installieren und später sauber deinstallieren kann. Denn notfalls (ohne Installer) schiebt man die Executable(s) in irgendein Verzeichnis eines neuen PC und startet die Anwendung, ohne sich Gedanken darüber machen zu müssen, ob dies und das an Framework/RE/DLL oder OCX schon und wenn in welcher Version auf jenem existiere. Bei der Deinstallation löscht man einfach das Verzechnis samt Inhalt.

Crushinator

2004-10-03, 18:01:18

Was beim CCC leider viel zu oft übersehen wird ist dass es viel mehr ist als das alte CP. Die Leute regen sich dann über .NET auf, dabei ist es möglicherweise nur aus Sicht der "Puristen" schlechtes Design. ATI wollte ein erweiterbares Panel. Das ist mit .NET sehr simpel zu realisieren. Da stellen sich für mich gleich mehrere Fragen: a) Ist das CCC wirklich so komplex, daß es nicht mehr als Trivial-Desktopanwendung alá PowerStrip bezeichnet werden kann, b) war die Komplexität notwendig oder gar Kundenwunsch und c) wenn schon Softwareentwickler einer solchen Allerweltsfirma offenbar nicht in der Lage sind für echte Begeisterung zu Sorgen, in dem ihr CCC nicht wirklich glänzt, besteht denn noch Hoffnung, daß es andere besser machen? ;)
a) Welche Ressourcen meinst du genau. Zum Speicherverbrauch von GC-Anwendungen habe ich ja schon was geschrieben. Resourcen = Startzeit, RAM-Verbrauch, Arbeitsgeschwindigkeit. Von mir aus kann's nur am Garbage Collector liegen, nur das Ergebnis zählt IMHO.
b) Das Thema wird sich ja dann mit Longhorn erledigen. Klar ist es erst einmal nervig, für eine 1MiB-Anwendung nochmals 20MiB aus dem Netz ziehen zu müssen, das verstehe ich durchaus. Wenn man viele .NET-Anwendungen verwendet kann sich das aber durchaus umkehren. Klar, irgendwann kann alles besser werden, im Momment ist es aus meiner Sicht eben weniger akzeptabel.
d) Firmenpolitik spielt für mich bei der Wahl der Tools eine geringe Rolle. Spätestens dann, wenn man gezwungen wird zu irgendetwas zu migrieren, was Einen ordentlich Geld kostet (http://www.heise.de/newsticker/meldung/40832), fängt man an bei der Beschaffung von fast allem darüber nachzudenken. ;)
Wenn der Bedarf an Software steigt, kann nicht mehr alles von den besten Entwicklern erledigt werden. Wenn hohe Qualität entscheidende Vorteile bringt, wird sie sich am Markt auch durchsetzen. Warum sind mir das bloß nur zuviele "wenn und Aber"? :D ;)
Das Blackbox-Prinzip ist ein zentrales Element der Objekt- und Komponentenorientierung. Und bei steigender Komplexität der Projekte einfach häufig notwendig. (...) :confused: Was genau spricht Deiner Meinung nach absolut dagegen, daß der Quellcode von vorbildlich gekapselten Komponenten für Notfälle (Portierungszwecke) einsehbar sei?

Grestorn

2004-10-03, 19:01:00

Statisches linken der zur Laufzeit benötigten Funktionen == Alles befindet sich als Maschinensprachencode in der Executable, sprich in der "Exe-Datei". Es muß somit nichts gesondertes "zusammen mit der Software" ausgeliefert werden.Entschuldige, aber Du musst mir nun wirklich nicht erklären, was statisches Linken bedeutet.

Mit "zusammen mit der Software" meine ich, dass Teile der Laufzeitumgebung immer mitgeliefert werden, als Teil des Executables oder als extra Datei ist doch völlig unerheblich.

Dadurch, daß nur das in die Executable hineinkommt, was zur Laufzeit benötigt wird, dürfte das Vorhandensein desselben Code in ggf. mehreren "Exe-Dateien" in den meisten Fällen zu verschmerzen sein, zumal wir in diesen Fällen von wenigen 100 KBs sprechen.So lange es sich um ein einfaches Laufzeitsystem handelt, mag das stimmen. Bei komplexeren widerspreche ich Dir.

Ein sehr großer Vorteil davon ist, daß man die Software sehr einfach installieren und später sauber deinstallieren kann. Denn notfalls (ohne Installer) schiebt man die Executable(s) in irgendein Verzeichnis eines neuen PC und startet die Anwendung, ohne sich Gedanken darüber machen zu müssen, ob dies und das an Framework/RE/DLL oder OCX schon und wenn in welcher Version auf jenem existiere. Bei der Deinstallation löscht man einfach das Verzechnis samt Inhalt.Das alles stimmt, wenn auch nur teilweise.

Die Grenze zwischen Laufzeitsystem und Betriebssystem verwischt immer mehr. Ist DirectX ein Laufzeitsystem? Teil des Betriebssystems?

Die Problematik dass die zur Verfügung stehenden Bibliotheken in der richtigen Version vorliegen und abwärtskompatibel sein müssen, lässt sich nicht übersehen.

Statisches Linken ist aber nicht die Lösung. Am Anfang wurde auch die Glide Bibliothek statisch zu den Spielen gelinkt (TombRaider I z.B.). Dass dies nicht unbedingt vorteilhaft war, dürfte inzwischen klar sein.

Grestorn

2004-10-03, 19:11:33

Resourcen = Startzeit, RAM-Verbrauch, Arbeitsgeschwindigkeit. Von mir aus kann's nur am Garbage Collector liegen, nur das Ergebnis zählt IMHO.Du bist auch Java-Gegner, richtig?

Dass Software insgesamt stabiler und sicherer wird (keine Pointerfehler mehr, keine Speicherlecks, keine C Buffer-Overflows mehr) spielt dabei keine Rolle, oder?

Das lässt sich alles auch mit anderen Mitteln erreichen, ich weiß. Binärkompatibilität auf allen Plattformen dagegen nicht mehr.

Java und .net sind leistungsstarke Werkzeuge. Ich empfehle Dir, Dich mal damit auseinanderzusetzen, und sie nicht von vorne herein dogmatisch abzulehnen.

Crushinator

2004-10-03, 19:21:09

Grestorn, ich habe den Eindruck, daß Du meinst, ich sei grundsätzlich gegen dynamisches Linken bzw. gegen Laufzeitumgebungen oder gar gegen jene, die das OS um neue Funktionalitäten erweiterten. Nein, das bin ich nicht. Ich möchte nur selbst entscheiden, wann ich was und vor allem wie linke, und auch gegen Plattformunabhängigkeit habe ich keine Einwände. Nur muß ich mich gerade jetzt fragen, warum z.B. ein Controlpanel für Grafikkarten, welches zu 90% aus Funktionalitäten besteht, Windows-Anwendungen (DX-Games) Optionen eines Treibers zur Verfügung zu stellen, nun unbedingt plattformunabhängig sein soll bzw. ob Du selbst ein solches Interface (zu einem Windows-Treiber) auch unbedingt in Java geschrieben hättest? ;)

grakaman

2004-10-03, 20:45:32

Du bist auch Java-Gegner, richtig?
Dass Software insgesamt stabiler und sicherer wird (keine Pointerfehler mehr, keine Speicherlecks, keine C Buffer-Overflows mehr) spielt dabei keine Rolle, oder?

Was ja auch wichtig ist, sind die Möglichkeiten damit, weil eben z.B. Codeeinheiten (Assemblys) alle Typeninformationen enthalten. Damit kann man das Deployment und Versionierung extrem vereinfachen und man hat ein paar extrem flexible Möglichkeiten durch Reflections. Gerade das dynamische Instanzieren halte ich mit für den entscheidenten Punkt.

KiBa

2004-10-03, 21:26:44

@crushinator
wenn du alles statisch linkst, dann wird die exe aber unhandlich groß, den die c-runtime libs sind nicht gerade klein. bei .net programmen wird halt nicht mehr die c-runtime sondern die umgebung von .net verwendet. hier hat .net den vorteil, dass die dateien meist kleiner sind.
beim speicherverbrauch hat .net sicher seine nachteile, aber das framework muss wie gesagt nur einmal geladen werden und der extra speicherbedarf zur laufzeit ist auch kein großes problem dank gc.
in sachen geschwindigkeit hab ich aber eher verschiedene erfahrungen gemacht. ein relativ großes projekt, was ich in c# mal geschrieben hab von einer c++ vorlage, hatte fast dieselbe performance. das war aber bei mir auch die einzigste ausnahme, fast alle anderen tests, die ich durchgeführt habe, liefen wesentlich langsamer als die gegenstücke in c++.
ich denke, so ein control-panel ist genau das richtige für .net, ein kleines programm, was keine geschwindigkeitsrekorde aufstellen soll, sondern einfach nur funktionieren muss. es ist schnell programmiert und einfach erweiterbar, wenn mans richtig macht. (kenne atis lösung nicht, kann sein, das die da mist gebaut haben, ist ja nicht das erste mal ;) )

grakaman

2004-10-03, 21:37:42

ich denke, so ein control-panel ist genau das richtige für .net, ein kleines programm, was keine geschwindigkeitsrekorde aufstellen soll, sondern einfach nur funktionieren muss.

Nunja, für größere Dinge ist es auch geeignet. Der Biztalk Server 2004 enthält z.B. >1Mio Zeilen C# Code.

Xmas

2004-10-03, 23:54:07

Da stellen sich für mich gleich mehrere Fragen: a) Ist das CCC wirklich so komplex, daß es nicht mehr als Trivial-Desktopanwendung alá PowerStrip bezeichnet werden kann, b) war die Komplexität notwendig oder gar Kundenwunsch und c) wenn schon Softwareentwickler einer solchen Allerweltsfirma offenbar nicht in der Lage sind für echte Begeisterung zu Sorgen, in dem ihr CCC nicht wirklich glänzt, besteht denn noch Hoffnung, daß es andere besser machen? ;)
Allerweltsfirma?
a) und b) kann dir nur ATI beantworten, aber irgendwas werden sie sich schon dabei gedacht haben.
c) Na sicher doch.

Resourcen = Startzeit, RAM-Verbrauch, Arbeitsgeschwindigkeit. Von mir aus kann's nur am Garbage Collector liegen, nur das Ergebnis zählt IMHO.
Das "Ergebnis" ist aber nicht direkt vergleichbar, wenn z.B. der GC bei viel freiem Speicher seltener durchläuft.

Warum sind mir das bloß nur zuviele "wenn und Aber"? :D ;)
Tja, das weißt nur du. Das erste wenn war temporal, nicht konditional. Und das zweite bezog sich auf die von dir geäußerte "höhere Qualität".

:confused: Was genau spricht Deiner Meinung nach absolut dagegen, daß der Quellcode von vorbildlich gekapselten Komponenten für Notfälle (Portierungszwecke) einsehbar sei?
Nichts. Ich halte es aber für recht nebensächlich.