Mit welcher Sprache programmiert ihr?
- Ersteller PseudoReal
- Erstellt am
skyphab
Grand Admiral Special
wo ist abap? 
JKuehl
Grand Admiral Special
für die RAD entwicklungsumgebung...
wir coden ja auch kein delphi in notepad
wir coden ja auch kein delphi in notepad
W
wertjojo
Guest
....
Zuletzt bearbeitet:
Fruchtnektar
Admiral Special
Java (so halb ), C und Visial Basic bis 6 (rudimentäre Kenntnisse)
), C und Visial Basic bis 6 (rudimentäre Kenntnisse)
Icemanemp
Lieutnant
- Mitglied seit
- 10.03.2003
- Beiträge
- 73
- Renomée
- 0
Ich darf doch sehr bitten!!! Pascal und Delphi sind 2 paar Schuhe! Jemand der Pascal kann, kann noch lange kein Delphi! Die Syntax ist ja extra gleich gehalten, aber hinter Delphi steht etwas ganz anderes als hinter Pascal!!! Objektorientierung usw.
Schon alleine weil einem durch die VCL-Komponenten grafische Oberfläche zur Verfügung steht bzw. Win32 Programmierung möglich ist, für die die die VCL nicht mögen. Bitte sofort ändern!
Delphi.net sollte auch extra augezählt werden, da es zum bisherigen Delphi sehr viele veränderung hinsichtlich .net kompatibilität gab und weil es 2. einige Sachen beherrscht, die Microsofts .net Sprachen nicht können!!
Also ich wähle Delphi, da ich in der Arbeit mit Programmiere und wenn was daheim anfällt, dann auch. In der Berufsschule haben wir keine Sprache und wenn uberhaupt Pascal/C++. Mehr Theoretische Dinge und Verständnissachen (Struktogramme, UML usw.)
Schon alleine weil einem durch die VCL-Komponenten grafische Oberfläche zur Verfügung steht bzw. Win32 Programmierung möglich ist, für die die die VCL nicht mögen. Bitte sofort ändern!
Delphi.net sollte auch extra augezählt werden, da es zum bisherigen Delphi sehr viele veränderung hinsichtlich .net kompatibilität gab und weil es 2. einige Sachen beherrscht, die Microsofts .net Sprachen nicht können!!
Also ich wähle Delphi, da ich in der Arbeit mit Programmiere und wenn was daheim anfällt, dann auch. In der Berufsschule haben wir keine Sprache und wenn uberhaupt Pascal/C++. Mehr Theoretische Dinge und Verständnissachen (Struktogramme, UML usw.)
Das Problem ist, wer jetzt auseinanderfrimelt wer von den Leuten für Pascal, und wer für Delphi gestimmt hat - desswegen bleibt das zusammen.
Übrigens gibt es von der Sprache her afaik wenig Unterschiede zwischen Delphi und Pascal. Pascal kann Klasse usw. (oder etwa nicht? Hab Pascal nie programmiert![:]](https://www.planet3dnow.de/vbulletin/images/smilies/rolleyes.gif "Augen rollen (sarkastisch) :]")
) - was sollen denn da wir C-Progger sagen? Ich kann GTK proggen, also bitte noch einen Punkt C/GTK? Und dann noch C/GTK+, C/Qt, C/Motif, C/WxWindows oder wie?
Man braucht Zeit um sich in die Dinge einzuarbeiten, aber es ist alles C. Genauso wie Delphi an sich Pascal ist.
Bei VB/QBasic ist es was anderes, QBasic kann sprachlich viele Dinge nicht, die VB kann. Dazu gehören zb. Klassen und natürlich OO. Dann hat VB viele neue Sachen mitgebracht (zb. neue Variablentypen) - bei QBasic schlägt schon ein einfaches For a=0 to 12 fehl.
VisualBasic.net ist so ziemlich komplett umgekrämpelt, da sind Klassen (afaik) vollständig drinnen und es hat sich viel am Code getan (ist im Gegensatz zu VB6 und QBasic viel mehr wie C, wo man so ziemlich alles machen kann). Siehst du schon daran, dass in einem leeren VB.net projekt schon haufenweise Code steht, wohingegen ein leeres VB6 Projekt eben komplett leer ist (nicht eine Code-Zeile).
Übrigens gibt es von der Sprache her afaik wenig Unterschiede zwischen Delphi und Pascal. Pascal kann Klasse usw. (oder etwa nicht? Hab Pascal nie programmiert
) - was sollen denn da wir C-Progger sagen? Ich kann GTK proggen, also bitte noch einen Punkt C/GTK? Und dann noch C/GTK+, C/Qt, C/Motif, C/WxWindows oder wie?Man braucht Zeit um sich in die Dinge einzuarbeiten, aber es ist alles C. Genauso wie Delphi an sich Pascal ist.
Bei VB/QBasic ist es was anderes, QBasic kann sprachlich viele Dinge nicht, die VB kann. Dazu gehören zb. Klassen und natürlich OO. Dann hat VB viele neue Sachen mitgebracht (zb. neue Variablentypen) - bei QBasic schlägt schon ein einfaches For a=0 to 12 fehl.
VisualBasic.net ist so ziemlich komplett umgekrämpelt, da sind Klassen (afaik) vollständig drinnen und es hat sich viel am Code getan (ist im Gegensatz zu VB6 und QBasic viel mehr wie C, wo man so ziemlich alles machen kann). Siehst du schon daran, dass in einem leeren VB.net projekt schon haufenweise Code steht, wohingegen ein leeres VB6 Projekt eben komplett leer ist (nicht eine Code-Zeile).
Icemanemp
Lieutnant
- Mitglied seit
- 10.03.2003
- Beiträge
- 73
- Renomée
- 0
Delphi für .NET-Features, die nicht in C# verfügbar sind
Signifikante Punkte:
* Kann Assemblies in eine Exe linken, ohne den Sourcecode für die Assemblies zu haben (unter Verwendung der Delphi-Package-Syntax)
* Funkionen in einer managed Delphi für .NET-Assembly kann direkt von unmanaged Win32 x86-Code ohne COM-Interop oder .NET-Dingen aufgerufen werden.
* Gespeicherte Symbol-Informationen für eine schnellere Compilierzeit
* Virtuelle Konstruktoren
* Benannte Konstruktoren
* Virtuelle Aufrufe von Klassenmethoden
* Ressourcenstrings
Delphi für .NET beinhaltet alle CLS-Features, aber beinhaltet auch Features, die nicht im CLS enthalten sind, wie z.B. virtuelle Konstruktoren. Deshalb können Sie virtuelle Konstruktoren in Ihrem Delphi-Code einsetzen; Clients, die Ihre Assemblies von C# aus nutzen, haben kein Konzept der virtuellen Konstruktoren, weshalb sie für sie wie normale .NET-Konstruktoren aussehen.
Das Aufrufen von Assembly-Exporten aus Win32-Code ohne COM-Interop: Eines der Dinge, die IL tun kann, C# aber nicht, ist das Produzieren von unmanaged Exports. Auf .NET-Seite müssen Sie deklarieren, dass Ihr Code als unsicher markiert ist, weil der Compiler eine Tabelle mit plattformspezifischen Pointern auf die Methoden in einem undokumentierten Abschnitt der PE-Datei erstellen muss. Ihr Assembly wird als Win32-spezifisch gekennzeichnet (offensichtlich, da die Exports für nichts anderes als Win32 nützlich sind).
Wenn Delphi für .NET ein Package sieht, importiert es die Symbole aus Metadaten und schreibt sie dann in nativem Delphi-Format auf Platte. Der Compiler kann sie nun etwa tausendmal schneller laden, als wenn er sie aus den Metadaten importiert. Delphi Package Syntax erlaubt es Ihnen, Assemblies in Ihre Exe zu linken, ohne deren Sourcecode zu haben. In C# müssen Sie den Sourcecode haben, um dies zu tun.
Delphi für .NET unterstützt virtuelle Klassenmethoden; ihr Aufruf aus C# ist allerdings ein bisschen ungewöhnlich, da C# diese nicht unterstützt. Verwenden Sie für größtmögliche C#-Unterstützung stattdessen statische Klassenmethoden. Allerdings können statische Klassenmethoden keine virtuellen Methoden aufrufen.
Signifikante Punkte:
* Kann Assemblies in eine Exe linken, ohne den Sourcecode für die Assemblies zu haben (unter Verwendung der Delphi-Package-Syntax)
* Funkionen in einer managed Delphi für .NET-Assembly kann direkt von unmanaged Win32 x86-Code ohne COM-Interop oder .NET-Dingen aufgerufen werden.
* Gespeicherte Symbol-Informationen für eine schnellere Compilierzeit
* Virtuelle Konstruktoren
* Benannte Konstruktoren
* Virtuelle Aufrufe von Klassenmethoden
* Ressourcenstrings
Delphi für .NET beinhaltet alle CLS-Features, aber beinhaltet auch Features, die nicht im CLS enthalten sind, wie z.B. virtuelle Konstruktoren. Deshalb können Sie virtuelle Konstruktoren in Ihrem Delphi-Code einsetzen; Clients, die Ihre Assemblies von C# aus nutzen, haben kein Konzept der virtuellen Konstruktoren, weshalb sie für sie wie normale .NET-Konstruktoren aussehen.
Das Aufrufen von Assembly-Exporten aus Win32-Code ohne COM-Interop: Eines der Dinge, die IL tun kann, C# aber nicht, ist das Produzieren von unmanaged Exports. Auf .NET-Seite müssen Sie deklarieren, dass Ihr Code als unsicher markiert ist, weil der Compiler eine Tabelle mit plattformspezifischen Pointern auf die Methoden in einem undokumentierten Abschnitt der PE-Datei erstellen muss. Ihr Assembly wird als Win32-spezifisch gekennzeichnet (offensichtlich, da die Exports für nichts anderes als Win32 nützlich sind).
Wenn Delphi für .NET ein Package sieht, importiert es die Symbole aus Metadaten und schreibt sie dann in nativem Delphi-Format auf Platte. Der Compiler kann sie nun etwa tausendmal schneller laden, als wenn er sie aus den Metadaten importiert. Delphi Package Syntax erlaubt es Ihnen, Assemblies in Ihre Exe zu linken, ohne deren Sourcecode zu haben. In C# müssen Sie den Sourcecode haben, um dies zu tun.
Delphi für .NET unterstützt virtuelle Klassenmethoden; ihr Aufruf aus C# ist allerdings ein bisschen ungewöhnlich, da C# diese nicht unterstützt. Verwenden Sie für größtmögliche C#-Unterstützung stattdessen statische Klassenmethoden. Allerdings können statische Klassenmethoden keine virtuellen Methoden aufrufen.
skyphab
Grand Admiral Special
abap fehlt ja schließlich auch
skyphab
Grand Admiral Special
Original geschrieben von intel_hasser
Nun zufrieden?
Brav
Dumm nur, dass ich ausschließlich für Delphi abgestimmt hatte...hmmhm, *plopp*
@intel_hasser:
Dachte ich auch gerade
Hab mal gegooglet:
Caché ist eine postrelationale Datenbank. M ist die zugehörige Programmiersprache und OpenM dürfte ein M-Dialekt sein. Die GUI für das ganze wurde scheinbar in VB geschrieben.
Hmmm, klingt für mich so'n bisschen wie ein Pendant zu Access + VBA.
Dachte ich auch gerade
Hab mal gegooglet:
Caché ist eine postrelationale Datenbank. M ist die zugehörige Programmiersprache und OpenM dürfte ein M-Dialekt sein. Die GUI für das ganze wurde scheinbar in VB geschrieben.
Hmmm, klingt für mich so'n bisschen wie ein Pendant zu Access + VBA.
Na hier solls ja nur im richtige Progg-Sprachen gehen, den ganzen Datenbankkrempel können wir rauslassen. Sonst müsste da ja noch SQL, DBase, Access (uahh *schüttel*), usw. rein. Und wenn wir da einmal dabei sind könnten wir dann auch noch HTML, CSS und weis der Geier was mit dazusetzen.
Winfo
Lt. Commander
- Mitglied seit
- 28.06.2002
- Beiträge
- 108
- Renomée
- 1
Na dann müsstest du ABAP aber auch wieder rausnehmen
Davon abgesehen sind die zu einer Datenbank gehörenden Sprachen (meist Sprachen der 4 Generation, genau wie ABAP) im Vergleich zu SQL (reine Abfragesprache) und HTML (reine beschreibungssprache) durchaus richtige programmiersprachen. Ich selbst muß hier gerade ein Programm für ein ERP-System schreiben, welches komplett in einer 4GL eines Datenbank-Systems erstellt wurde. Und das ist nicht irgend ein "experimentelles" System, welches Leute aus Spaß an der Freude geschrieben haben, sondern eines, das inzwischen schon gute 10 Jahre erfolgreich vermarktet wird. Glaube nicht, daß das mit einer wirklichen 08/15 weis der Geier was Sprache zu realisieren gewesen wäre
Ich gebe dir natürlich recht, wenn du sagst, daß es gerade im Bereich der Datenbanken zu viele Dialekte gibt (jedes großes Datenbankmanagmentsystem bringt ja seine mehr oder weniger eigene mit) um hier alle aufzuführen. Aber ein Sammelpunkt wie "Datenbankprogrammierung" oder so was in der Art wäre sicherlich nicht verkehrt.
Gruß
Torsten
Ähnliche Themen
