Delphi-PRAXiS - Visual J# und C#... Definitionen?

Delphi-PRAXiS (https://www.delphipraxis.net/forum.php)

- Programmieren allgemein (https://www.delphipraxis.net/40-programmieren-allgemein/)

- - Visual J# und C#... Definitionen? (https://www.delphipraxis.net/52252-visual-j-und-c-definitionen.html)

Visual J# und C#... Definitionen?

Hi!

Ich hab schon die Suche bemüht, allerdings verläuft die Suche danach schwierig...

MS hat ja als "erste" .NET-Sprache C# entwickelt. Und C# basiert ja stark auf Java. Aber basiert Visual J# nicht auch auf Java? Immerhin Hat MS nach C# auch noch eine weitere "Java-Sprache" nach .NET portiert.

Mich würde nun mal interessieren, wo die genauen Unterschiede zwischen VJ# und C# liegen, da ja immerhin beide auf Java basieren und dann "nach .NET portiert wurden" ;)

Re: Visual J# und C#... Definitionen?

C# basiert auf den Konzepten von Java/Delphi (bzw. VB)/Smalltalk und neuen Konzepten wie den Attributen. Von C++ hat es die "Mächtigkeit" geerbt (und vieleicht in .NET 2.0 das Template-Konzept.

J# ist m.E. primär dafür da um alten Java 1.1-Code einfach zu übernehmen. Für neue Entwicklungen würde ich es komplett ignorieren. Da hat C# (und auch VB.NET) einiges mehr zu bieten und wird von MS verstärkter weiterentwickelt.

Aber man könnte ja wieder einwerfen: In .NET ist es egal mit was man für einer (.NET-)Sprache man entwickelt. Aber für ein Projekt sollte man wenn möglichst nur eine Sprache verwenden. Kaufkomponenen können sicherlich in einer anderen Sprache sein.

Re: Visual J# und C#... Definitionen?

MS pusht J# genau wie es C#, mC++ und die Kindersprache pusht.
C# _ist_ ein Java-Derivat. Nix C++, Delphi,...
Sicher hat die CLR ein paar Dinge von Java _und_ von Delphi gelernt, aber C# hat nachdem man es sich eine Weile betrachtet nicht viel mit Delphi zu tun.

Außerdem halte ich es für ein Gerücht, dass man nur eine Sprache nehmen sollte.
Chrome & C# sind zum Bleistift prima geeignet wenn man entweder sehr schnell sein Modell runtertippen will (C#) oder elegant und wartbarer programmieren will (Chrome). Warum sollte ich mich auf eine festlegen? :gruebel:

Re: Visual J# und C#... Definitionen?

Zitat:

Zitat von Robert_G

MS pusht J# genau wie es C#, mC++ und die Kindersprache pusht.
C# _ist_ ein Java-Derivat. Nix C++, Delphi,...

Properties kommen ja wohl aus der Delphi/VB-Ecke. In Java gibts/gabs ja "nur" Setter/Getter-Methoden.
Und das Klassenmodell (ok hat jetzt nichts mit der Sprache an sich zu tun) der FCL schaut ja in vielen Bereichen sehr nach der VCL aus.

Zitat:

Zitat von Robert_G

Außerdem halte ich es für ein Gerücht, dass man nur eine Sprache nehmen sollte.

In einem Projekt. Stell dir vor Du hast 20 Entwickler und jeder nimmt seine Sprache (VB.NET, C#, Chrome, DelphiLangauge, SmallTalk und was es sonst noch gibt). Ob du dich auf Anhieb mit jeder Syntax fließend auseinander setzen kannst?
Und das wirst Du müssen wenn währen der Urlaubszeit des Smalltalk-Entwicklers du dessen Konstrukte verstehen mußt um Bugs zu beheben. Und Syntax-Unterschiede sind vorhanden. Sonst würde es ja nicht so viele Sprachen geben.

Re: Visual J# und C#... Definitionen?

Och mönsch Bernhard, musst du immer alles so zerpflücken?
Properties sind eine Eigenschaft der CLR. Und wie sind sie definiert? Genau: set_Property / get_Property
Und was du hier mit der VCL oder sinnlos vielen Sprachen willst? :gruebel:
Natürlich wäre es Blödsinn 5 Mio. Sprachen in ein Projekt zu stopfen. Ich halte es aber genauso für Blödsinn die Muttersprache von .Net (C#) nicht zu nutzen, wenn sie sich anbietet.
Auch wenn man eigentlich mit Chrome (VB, Delphi, whatsoever) programmiert...
Wer C# nicht lesen/schreiben kann ist sowieso am *piep*...

Re: Visual J# und C#... Definitionen?

Zitat:

Zitat von Robert_G

Och mönsch Bernhard, musst du immer alles so zerpflücken?
Properties sind eine Eigenschaft der CLR. Und wie sind sie definiert? Genau: set_Property / get_Property

Aber in Java muß man immer mit set/get-Methoden arbeiten.

Zitat:

Zitat von Robert_G

Und was du hier mit der VCL oder sinnlos vielen Sprachen willst? :gruebel:

VCL um darauf hinzuweisen das einiges von Delphi ins .NET-System geflossen ist und nicht nur alles von Java genommen wurde.

Zitat:

Zitat von Robert_G

Natürlich wäre es Blödsinn 5 Mio. Sprachen in ein Projekt zu stopfen. Ich halte es aber genauso für Blödsinn die Muttersprache von .Net (C#) nicht zu nutzen, wenn sie sich anbietet.
Auch wenn man eigentlich mit Chrome (VB, Delphi, whatsoever) programmiert...
Wer C# nicht lesen/schreiben kann ist sowieso am *piep*...

Das mein ich ja. Man sollte sich auf möglichst wenig Sprachen festlegen. Genauso wie es sinnlos/kontraproduktiv in Word ein Dokument zu verfassen und möglichst viele Fonts zu verwenden weil sie ja vorhanden sind oder möglichst viele Farben da der Drucker ja diese unterstützt ist es beim Programmieren kontraproduktiv wenn jeder Entwickler.

Aber nochmal zu J#. Ich denke mal damit will MS ähnlich wie schon mit ihren verkrüpelten J++ Sun eins Auswischen. Es ist zwar eine zu Java ähnliche Sprache aber Java macht nicht nur die Syntax aus sonder auch das Klassenmodell und ähnliches aus. Und wenn man eine Java 1.5-Anwendung umzusetzen will kann man gleihc es mit C# oder Chrome machen. Aufgrund des Unterschiedlichen Objektmodells muss man eh viel neu entwickeln.

Re: Visual J# und C#... Definitionen?

Zitat:

Aber nochmal zu J#. Ich denke mal damit will MS ähnlich wie schon mit ihren verkrüpelten J++ Sun eins Auswischen. Es ist zwar eine zu Java ähnliche Sprache aber Java macht nicht nur die Syntax aus sonder auch das Klassenmodell und ähnliches aus. Und wenn man eine Java 1.5-Anwendung umzusetzen will kann man gleihc es mit C# oder Chrome machen. Aufgrund des Unterschiedlichen Objektmodells muss man eh viel neu entwickeln.

Haben die nicht alle Java Klassen mitimplementiert? Es gibt doch auch ein Tool welches Java Bytecode direkt in eine Assembly konvertiert.

Re: Visual J# und C#... Definitionen?

Zitat:

Zitat von LarsMiddendorf

Zitat:

Haben die nicht alle Java Klassen mitimplementiert? Es gibt doch auch ein Tool welches Java Bytecode direkt in eine Assembly konvertiert.

Java 1.1. Und die Zeit ist in der Java-Welt nicht stehen geblieben. Also kann man nur die (wenigen noch vorhandenen) Browser-Applets umsetzen. Und da werden die meisten eh schon auf serverseitiges Java umgestellt haben um nicht bei Java 1.1 zu verhungern.