Ich hab da noch etwas .NET Framework Müll auf dem Rechner

[Phoenix]

Zitat von Bernhard Geyer:

Es gibt schon einen Teil was den Rechner ziemlich verlangsamt. Und zwar der native Compiler soweit der Runtime Optimization Service.
Diese sollten zwar nur "relative" kurze Zeit laufen und dann wieder ruhe geben. Aber auf unseren W2012-Server sorgen diese aktuell für eine Dauerhafte Grundlast von ca. 5%.

Das kann ich hier auf keinem einzigen unserer Systeme nachvollziehen (und wir haben auf mehrere Rechenzentren verteilt schon ein paar von solchen Kisten...).

[Furtbichler]

Soweit ich das sehe, rödelt dieser .NET-Optimierer immer nach einem Update. Und das dann ne ganze Weile. Wenn man diese aber zeitlich optimiert (nachts, wochenende), merkt man davon nichts.

Zitat von Phoenix:

Ja. Leider. Been there, done that, got the T-Shirt.

Und somit als Fan geoutet. Wer kauft sich schon ein T-Shirt, von Dingen, die er nicht mag.

Zitat:

Oxygene (aus Delphi Prism) hingegen ist eine Sprache, die Object Pascal konsequent in Richtung (teilweise-)Managed Umgebungen weiterentwickelt hat, und dabei sogar Sprachelemente (z.B. Code Contracts) in einer Art und Weise umgesetzt hat, von der sich sogar C# die ein oder andere Scheibe abschneiden könnte.

"Eigenlob stinkt", sagt man doch, oder?

Zitat:

Visual Basic wurde von anderen Leuten die von Sprachdesign keine Ahnung haben

Wusste nicht, das Du die Leute kennst. Ansonsten erinnert mich dieses 'die haben keine Ahnung' an einen BuLi-Stammtisch, wenn mal wieder unqualifiziert über den Trainer/Spieler/Schiri gefaselt wird, der natürlich 'keine Ahnung' hat und man selbst alles viel viel besser weiss. Obwohl die Trainer/Spieler/Schiris das ja eigentlich gelernt haben.

Nicht böse sein, aber hier bist Du durchaus in der Lage, differenzierter zu argumentieren.

Ich behaupte nämlich: Die Leute um VB haben von Sprachdesign sehr wohl eine Ahnung (sie haben ja IT studiert, wovon ich mal ausgehe), wenden ihr Wissen (hier) aber nicht an, denn die Philosophie von VB ist ja gerade nicht, modernste Sprachkonzepte einfließen zu lassen, sondern DAUs zu befähigen, Code zu schreiben. Deswegen heißt BASIC ja BASIC ("Beginners All Purpose Symbolic Instruction Code") und nicht ("ESDIC", wie "Experts Super Duper Instruction Code").

[Phoenix]

Zitat von Furtbichler:

"Eigenlob stinkt", sagt man doch, oder?

Da ich (aus zeitlichen Gründen wegen meines normalen Jobs) schon seit über einem Jahr nichts mehr mit RO zu tun habe (letztes Post dort Dezember 2011, ich bin auch hier auf der Teamseite schon lange nicht mehr gelistet), würde ich da gerne wissen wie Du da noch auf 'Eigenlob' kommst

Ab und zu chatte ich noch mit den Jungs, aber da kam ehrlich gesagt auch nicht genug bei rum dass es sich noch gelohnt hätte.

Ganz Ehrlich:
Gegen Prism / Oxygene spricht ganz eindeutig die zu geringe Verbreitung und die komplett fehlende Toolunterstützung a) seitens offenerer API's bei MS und b) seitens Drittherstellern für z.B. Refactoring-Tools).

Das ist ein so großes Manko, dass es fast nicht mehr aufgewogen mehr kann - ausser man ist ein absoluter Pascal-Verfechter und die Vorteile der besser lesbaren Syntax des Pascal-Codes überwiegen im Einzelfall die anderen Produktivitätsvorteile in anderen .Net Sprachen.

Ausnahmefall: Man will tatsächlich a) auf Pascal setzen und b) tatsächlich für .Net (Windows Phone / Win RT), Java (Android) und Cocoa (Mac/iOS) die gleichen Anwendungen *jeweils nativ* schreiben. Dann gibt es ausser MonoTouch/MonoDroid (das ja überall über ein .Net Zwischenkompilat geht) keine Alternative.

Dennoch: Die Contracts.StaticMethod(checksomething) API (neu seit .NET 4) ist so extrem häßlich gegenüber den wunderbar direkt in die Klassen und Methoden eingewobenen Code Contracts, die es in Oxygene schon gab wo es noch Chrome hiess (also in v1, vor etlichen Jahren).

Für AOP braucht man in anderen .NET Sprachen extra Post-Compiler die den fertigen IL-Code auseinandernehmen, die Aspekte unterjubeln und neuen IL generieren. Und dabei dann fast alle vergessen die PDB's neu zu schreiben, so dass in Stack traces bei Exceptions nicht die richtigen Zeilennummern stehen (wenn überhaupt die richtige Methode). In Oxy ist das gleich des Compilers (und funktioniert übergreifend für Java und Cocoa auch genauso wie in .Net), weil man hier direkt im Compilierungsprozess drin steckt, sozusagen als Compiler-Plugin.

Auch inline Interfaces (kamen aus Java) wären in C# manchmal schön.

Ein bisschen fehlen mir die Features, aber das wird alles in allem eben durch das super-Tooling in der .Net Welt (ReSharper, Reflector, LinqPad...) alles wieder mehr als aufgewogen.

[Bernhard Geyer]

Zitat von Phoenix:

Das kann ich hier auf keinem einzigen unserer Systeme nachvollziehen (und wir haben auf mehrere Rechenzentren verteilt schon ein paar von solchen Kisten...).

Scheinbar treffen wir alle offenen Bucks in W2012:

Erst das Problem das die Kisten nicht mit WSUS wollen (händisches KB-Update musste eingespielt werden)
Dann der Deadlock-Installer der immer wieder etwas installieren wollte was nicht installierbar ist (vermutlich durch ein Update behoben), Fehler hatten nach Google-Result hunderte andere User auch
SQL-Server 2012 liest sich mit praktisch Standard-Installation erst beim 2ten Versuch installieren (erster hat alles bis auf die DB-Engine installiert)

[Phoenix]

Zitat von Bernhard Geyer:

Zitat von Phoenix:

Das kann ich hier auf keinem einzigen unserer Systeme nachvollziehen (und wir haben auf mehrere Rechenzentren verteilt schon ein paar von solchen Kisten...).

Scheinbar treffen wir alle offenen Bucks in W2012:

Oh, das hört sich eher nach echt grundsätzlich verkorkster OS-Installation an. Ich wüsste bis auf einen Fall (wo ich den IIS selber komplett zerstört hatte und zwar so, dass ein OS-Reinstall nötig war.. das mach ich nie wieder ) nicht, dass wir hier auf einer einzigen Kiste echte Probleme gehabt hätten.

[Bernhard Geyer]

Zitat von Phoenix:

Oh, das hört sich eher nach echt grundsätzlich verkorkster OS-Installation an.

Dann machen das bei W2012 scheinbar hunderte. Bei den meisten Fehlern findet man viel Suchergebnisse (auch bei MS).

[EWeiss]

Zitat:

sondern DAUs zu befähigen, Code zu schreiben

Nur weil man low level code schreibt ist man noch lange kein DAU.
Letztendlich basieren nicht aufgezählte *.pas Dateien in Delphi auf genau desselben.

Der vorteil halt nur das man die APi's nicht selber suchen muss da sie ohne umwege direkt zur verfügung stehen.

Zitat:

Die Leute um VB haben von Sprachdesign sehr wohl eine Ahnung (sie haben ja IT studiert, wovon ich mal ausgehe)

Da frag ich mich doch nun!
IT Studierte <> DAUs..

gruss

[Popov]

Auch wenn es mein Thema ist und ich somit selbst etwas OT werden, mal meine Meinung zu Basic. Ich halte Basic (Basic allgemein, weniger ein Dialekt) für eine der intelligentesten Programmiersprachen überhaupt. Damit meine ich nicht, dass sie die effektivste ist, das ist sie nicht, der Mensch ist auch nicht so effektiv beim Rechnen wie ein Computer, er ist aber intelligenter. Der Grund ist, das wenn zwischen A und C das B fehlt, er in der Lage ist diesen Fehler abzufangen. Programmiersprachen die Fehler abfangen sind für mich intelligenter, aber nicht effektiv.

Deshalb hat Basic schon seine Berechtigung in der Welt, aber wenn effektive Programme schreibt man mit anderen Sprachen. Meine Meinung.

[MrSpock]

Das hat aber nichts mit BASIC zu tun. Eine Sprache, die übersetzt wird kann "geparst" werden und einen Syntaxfehler erkennen und zur Laufzeit Laufzeitfehler erzeugen. Eine Sprache die Interpretiert wird, erzeugt quasi die Laufzeitfehler beim Interpretieren der entsprechenden Anweisung.
BASIC ist da nicht besonders "intelligent".

[Furtbichler]

Zitat von EWeiss:

Zitat:

sondern DAUs zu befähigen, Code zu schreiben

Nur weil man low level code schreibt ist man noch lange kein DAU.

BASIC ist per definitionem für Anfänger. Sagt schon der Name.

Zitat von MrSpock:

Das hat aber nichts mit BASIC zu tun. Eine Sprache, die übersetzt wird kann "geparst" werden und einen Syntaxfehler erkennen und zur Laufzeit Laufzeitfehler erzeugen. Eine Sprache die Interpretiert wird, erzeugt quasi die Laufzeitfehler beim Interpretieren der entsprechenden Anweisung.
BASIC ist da nicht besonders "intelligent".

Das liest sich so, als ob BASIC per se interpretiert wird. Und das stimmt nicht.

... Ach, das schöne gute alte BASIC. Seufz.

@Phoenix: Das mit dem Eigenlog war eh nur ein Wink, aber ich nehm's zurück...