PDA

Archiv verlassen und diese Seite im Standarddesign anzeigen : Welche Programmiersprache für diese Projekt / Sprachauswahl


icemanemp
2004-11-11, 17:13:09
Hi,

hab mal ne generell und spezielle Frage:

Generell: Wie kann man entscheiden, für welches Projekt welche Sprache am besten geeignet ist.

Speziell: Will eine Wirtschaftssoftware für Winzer aufbauen. Zu kaufen gibt es auch eine aber die Kostet 800 EURO für eine Lizenz! Ich mach das nur nebenher und nur weil ich ein Winzer kenn der ne Software braucht. Beruflich programmiere ich auch an einer Warenwirtschaftssoftware, aber in einem viel viel grösseren Stil. Kenntnisse würde ich da ja schon mitbringen. Falls ich dies Software irgendwann verkaufne will, muss ich das mit dem jetzigen Arbeitgeber abklären, das ist klar... Dort benutzen wir Delphi. Ich will aber wenns geht Datenbank als Open-Source und Programmiersprache weiss ich eben nicht! Schön wären Vorschläge mit Begründungen...

Danke

Gast
2004-11-11, 17:39:16
ich würd bei delphi bleiben, wenn du es schon gewohnt bist
mit den ganzen netten komponeneten ersparst du vor allem
bei der datenbankanbindung ne menge zeit

verarbeitungsgeschwindigkeit ist bei dem programm ja absolut nebensächlich
von daher würd ich mit der bequemsten variante arbeiten

lg
ronin

ScottManDeath
2004-11-11, 18:39:35
Da Du mit Delphi schon Erfahrung hast würde ich das Pferd nicht unbeding wechseln.

Wenn Du allerdings 'was Neues lernen möchtest wäre C# vielleicht ein Blick wert. GUI geht angenehm und DB Zugriff ist auch möglich.

C++ würde ich nicht unbedingt empfehlen da mit Win32API, MFC oder WTL GUI Programmierung nahe an Selbstgeißelung grenzt. ;)

Das Ganze hängt auch davon ab welche IDEs du hast bzw. welche Du beschaffen könntest.

Aqualon
2004-11-11, 19:27:47
Wenn du die Software später auch auf anderen Betriebssystemen einsetzen möchtest, würde ich dir Java empfehlen, da der Aufwand diese zu portieren sehr gering ist.

Alternativ kannst du auch .NET verwenden und es gleichzeitig immer unter Linux mit Hilfe von Mono testen.

Bei Delphi weiß ich nicht, wie gut Kylix für Linux-Ports schon verwendbar ist. Wenn dies bereits gut läuft, würde ich bei Delphi bleiben.

Wenn die Software eh nur unter Windows laufen soll, würde ich an deiner Stelle auch Delphi vorziehen, da du einerseits schon Erfahrung damit hast und andererseits die wenigsten Probleme bei den Kunden hast, da du native exe-Files erstellst und keine Runtime Environment brauchst wie bei .NET und Java.

Aqua

icemanemp
2004-11-11, 19:50:51
Einzigste Problem wäre nur, das wir Delphi 5 benutzen und noch die BDE und das auhc noch mit eigenen Komponente, wo der Zugriff auf die Datenbanken auf der BDE umgeswitcht wird... also nicht so wie Borland das vorgesehen hatte... aber Erfahrung ist halt schon einiges da...
Interessant ist natürlich auch ne andere Sprache, da ich in der Ausbildung fast nur professionell Delphi gemacht habe und in der Schule, das bischen Pascal und C kann man sich schenken, aber da ich z.Z. Prüfungen mach und dann Fachinformatiker bin, wäre es nicht schlecht eine 2 Sprache näher kennen zu lernen. Java wäre sehr interessant, aber da kenn ich mich nicht wirklich aus. C++ ist mir eher bekannt... aber mit MFC hab ich keine Erfahrung... C# bräuchte ich ja Microsoft Visual Studio. Net...
Ausschliessen kann man ganz klar den Rest wie: Visual Basic und restliche...
Wie sieht es bei Java aus mit der Datenbankanbindung? C# dürfte genauso einfach sein wie Delphi.Net... Vielleicht ist auch genau Delphi.Net ne gute alternative...
Habt mir schon ein bischen weiter geholfen. Falls ich z.B. Java einsetzen möchte, welche IDE soll ich das nutzen, die mir so viel Komfort bietet wie ich jetzt von Delphi gewohnt bin? Gibt es noch ne andere Entwicklungsumgebung für C# am besten für lau...? Wäre eben jetzt schon eher die Frage wie die Datenbankanbindung zur realisieren wäre... Ich brauich für so ne Software ja Reportingmöglichkeiten... Datenbankanbindung am besten an ne realationale Datenbank, da gibt es ja genug Datenbanken, die gute und umsonst sind...

Demirug
2004-11-11, 20:00:06
C# Entwicklungsumgebung: http://www.sharpdevelop.com/

Aqualon
2004-11-11, 20:01:01
Die Datenbankverbindung ist bei Java ziemlich einfach über JDBC (http://java.sun.com/products/jdbc/) lösbar.

Als kostenlose Entwicklungsumgebung für Java bietet sich natürlich Eclipse (http://www.eclipse.org/) an.

Aqua

darph
2004-11-11, 20:18:59
Als kostenlose Entwicklungsumgebung für Java bietet sich natürlich Eclipse (http://www.eclipse.org/) an.

Aqua
Das Programm ist ja die Katastrophe... Also wenn man damit um kann, ist es ja sicher ganz toll, aber bis ich das soweit hatte, daß es mein Hello World kompiliert hat... ;(

Gast
2004-11-11, 20:44:59
Wenn du eine kleine schlange IDE Probieren willst kannst ja mal JCreator probieren.
Ist einfach einzurichten und mir hat er damals gut gefallen.
http://www.jcreator.com/

Gast
2004-11-11, 20:45:37
Achso JCreator hat aber keinen GUI Builder.

pajofego
2004-11-11, 20:50:41
C# Entwicklungsumgebung: http://www.sharpdevelop.com/

Ich würde dir unbedingt einmal empfehlen diese Empfehlung nachzugehen. Bin selbst von Delphi gekommen und fand .NET und C# einfach nur cool, einfach und schnell erlenbar. Leider ist noch kein Debugger on board, aber bei dem .NET SDK ist der von MS dabei und die sind wirklich gut! Ausserdem ist alles kostenlos hast nix zu verlieren! Falls es dir gefällt kannst dir immer noch überlegen ob du unbedingt VS2003 brauchst!

Mein Tipp probiers einfach mal! Ist echt klasse!

HellHorse
2004-11-11, 22:17:39
Als kostenlose Entwicklungsumgebung für Java bietet sich natürlich Eclipse (http://www.eclipse.org/) an.
Oder NetBeans (http://www.netbeans.org/) oder JBuilder Foundation (http://www.borland.de/jbuilder/foundation/index.html) oder ...

ScottManDeath
2004-11-11, 23:38:51
MS Visual C# .NET 2003 (http://www.amazon.de/exec/obidos/ASIN/B00009QWKV/qid=1100212164/sr=1-1/ref=sr_1_10_1/302-9353862-1636034)gibts für 118€, das ist IMHO im grünen Bereich wenn man damit kommerziell arbeiten möchte. Hängt aber davon ab wieviel Du deinem Winzer rausleiern kannst ;)

Delph.NET hätte den Vorteil dass Du deine Delphi-Erfahrung weiter nutzen könntest und dabei .NET kennenlernen würdest. Wenn Du dann irgendwann C# nutzt kannst Du deine Delphi.NET Komponenten weiter nutzen. Allerdings ist IMHO C# ein "netter" C++/Java/Delphi Bastard ;) dass es sich fast nicht mehr lohnt den "Umweg" über Delphi.NET zu machen, da der Umstieg nicht so dramatisch ist. Ist ja eh bloß GUI-Klicki-Bunti =)

IRC ist das .NET Framework im SP1/SP2 mit dabei.

Aqualon
2004-11-11, 23:45:28
IRC ist das .NET Framework im SP1/SP2 mit dabei.
Ist es nicht. Es wird zwar als optionales Update auf http://windowsupdate.microsoft.com angeboten, aber war bisher noch bei keinem Service Pack verpflichtend dabei (das .NET Framework 1.1 ist zwar auf der SP2 CD von Microsoft, aber man muss es nicht installieren).

Aqua

Blumentopf
2004-11-12, 08:12:31
Für kleinere Datenbankprojekte würd ich bei Delphi bleiben oder in .NET (VB8, C#) investieren.
Wobei letzteres nicht kostenlos ist, aber Delphi gabs immer ne personal free edition. Da könntest du auf Delphi 7 umsatteln.

Ich hab noch irgendwo ne Delphi 6 pro rumliegen... braucht die wer? ;)

icemanemp
2004-11-12, 11:33:36
Hab mir heute morgen nochmal paar Gedanken gemacht...

Die Links von euch sind super Danke! Auch Danke für eure Anregungen...
Ich glaub ich werd nochmal 2-3 Wochen Zeit extra verbrauchen nur um mal Java + Datenbanken + GUI und C# + Datenbanken + GUI zu testen... Da ich wirklich erst im Januar mit den Prüfungen fertig bin und bis dahin schon Delphi 9 rausgekommen ist (wovon es wieder eine Personal geben wird!) werd ich die mir auch anschauen, da dort viel im Gegensatz zu Delphi 5 auf 7 passiert ist... auch im Win32-Bereich

Danke nochmals

grakaman
2004-11-12, 12:12:55
Wenn du Delphi.NET verwendest, musst du aufpassen, welche API du benutzt (FCL oder VCL.NET). VCL.NET wrapped bloss die VCL, also arbeitet so gut wie nur mit PInvoke -> performancefressend, da ständig hin- und hergemarshallt werden muss. FCL wrapped hingegen das .NET Framework und ist für .NET Anwendungen besser geeignet.

icemanemp
2004-11-12, 13:30:59
Ich weiss... Ich kenne die Performancetest, wo die VCL im einiges langsamer ist... da ich noch kein bischen mit .Net gearbeitet habe, müsste ich davor natürlich auf den einschlägigen Delphiseiten, die Tutorials zu FCL anschauen...
Wenn ich Delphi 9 benutzen würde, dann eher Win32... mit Delphi und .Net bin ich noch sehr skeptisch, da mir Borland zu viel hinter Microsoft hinterherarbeiten muss. Die arbeiten in Delphi 8 mit so viel Tricks, nur um .net Fähigkeit zu erlangen...

Shink
2004-11-12, 14:28:41
Ich persöhnlich würde Java mit Borlands JBuilder empfehlen. Gerade einfache GUI-Anwendungen mit Datenbankzugriff sind damit sehr einfach zu realisieren.
Bei meinem ersten diesbezüglichen Projekt war ich damals sehr überrascht, wie schnell ich trotz fehlender Vorkenntnisse ein funktionierendes Produkt hatte.
Ich finde Java für Datenbanken auch deshalb sinnvoll, da führende komerzielle Datenbankhersteller (IBM, Oracle) Java sehr unterstützen.

grakaman
2004-11-12, 14:50:39
Wenn ich Delphi 9 benutzen würde, dann eher Win32... mit Delphi und .Net bin ich noch sehr skeptisch, da mir Borland zu viel hinter Microsoft hinterherarbeiten muss. Die arbeiten in Delphi 8 mit so viel Tricks, nur um .net Fähigkeit zu erlangen...

Wie meinst du das mit hinterherarbeiten? Borland hat einfach nur aus Kompatibilitätsgründen und der Einfachheit die VCL.NET über PInvoke laufen lassen. Damit du eben VCL erstellte Anwendungen problemlos portieren kannst, deshalb diese "Tricks".

icemanemp
2004-11-12, 15:29:07
@ grakaman
Borland entdeckt, das die derzeitige .NET Technologie auf normalen Win32 Aufrufen basiert, deshalb sind sie hingegangen und haben die VCL entsprechend angepasst. Wenn Microsoft die Basis z.B. mit Longhorn schnell ändert, weil es dort kein Win32 mehr gibt, dann muss Borland hinterher ziehen... Ausser ich irre mich da, aber so weit ich alle Quellen noch in Erinnerung habe, dürfte sie so vorgegangen sein...

so hab den Bericht gefunden:
Wir erwogen zuerst, die VCL auf das WinForms-Framework aufzusetzen. Nach ein wenig Forschung wurde klar, dass die gleichen Architekturunterschiede, die es schwierig machten, VCL-Anwendungen nach WinForms zu portieren, es schwierig machen würden, eine VCL-Schicht über WinForms zu erstellen - und trotzdem auf VCL-Art zu funktionieren.

Was wir beim Evaluieren von WinForms feststellten war, dass WinForms direkt auf Win32-API-Aufrufe aufsetzt. WinForms-Fensterklassen rufen CreateWindow() auf, um Win32-Fenster-Handles zu erzeugen, sie hooken die Win32-WndProc, um Fensterbotschaften abzuhören und feuern entsprechende Events innerhalb der Klasse und so weiter und so fort.

Genau wie die VCL.

Wenn Win32-API-Aufrufe von verwaltetem .NET-Code gut genug für das .NET-Framework sind, sollten sie gut genug für die VCL sein! Der Prozess, die VCL auf der .NET-Plattform zu implementieren, wurde ein wenig dazu, herauszufinden, wie die Win32-API-Aufrufe zu machen waren, auf die sich die bestehende VCL-Architektur verlässt, und trotzdem so wenig Änderungen am VCL-Code selbst zu machen wie wir es nur hinbekamen.

Quelle: www.delphi-source.de

oder hab ich den Abschnitt vollkommen falsch verstanden?

grakaman
2004-11-12, 15:41:41
@ grakaman
Borland entdeckt, das die derzeitige .NET Technologie auf normalen Win32 Aufrufen basiert, deshalb sind sie hingegangen und haben die VCL entsprechend angepasst.


Das ist so nicht richtig. Die .NET API ist kein Wrapper für Win32. Dass allerdings Kernelfunktionen über die W32 API realisiert werden müssen (z.B. Fenster zeichnen), ist ja logisch. Ansonsten ist .NET eine vollkommen neue API.


Wenn Microsoft die Basis z.B. mit Longhorn schnell ändert, weil es dort kein Win32 mehr gibt, dann muss Borland hinterher ziehen


Win32 wird es immer noch geben und zumindest die Kernelfunktionen sind ja unabdingbar.

icemanemp
2004-11-12, 15:45:16
Achso na dann, war das nur für Fenster... für allgemeine Funktionen wird PInvoke benutzt?

grakaman
2004-11-12, 15:57:33
Achso na dann, war das nur für Fenster... für allgemeine Funktionen wird PInvoke benutzt?

PInvoke wird nur benutzt, wenn man entweder auf Funktionen zurückgreifen will, die es noch in Win32 gibt und noch nicht in .NET oder man ist auf Kernelfunktionalitäten angewiesen. Letzteres ist überall so, egal in welchem Framework, auch wenn du das vielleicht beim Programmieren nicht mitbekommst. Mit Longhorn und WinFX ist dann die komplette Win32 Funktionalität auch über die managed .NET API (WinFX) verfügbar. Aber für bestimmte low level Aufgaben wie z.B. Serial/Parallel Port ansprechen oder Fenster zeichnen ist man eben auf die OS API (Win32) angewiesen.

icemanemp
2004-11-12, 16:45:28
naja, war jetzt mal ne reise ins "Offtopic-Land", aber trotzdem danke dir...

und dem Rest...