*Kaffee aufgesetzt und Stuhl reingestellt*
PHP oder JAVA?
Einklappen
X
-
*Kuchen mitbringt*Sunshine CMS
BannerAdManagement
Borlabs - because we make IT easier
Formulargenerator [color=red]Neu![/color]
Herkunftsstatistik [color=red]Neu![/color]
Kommentar
-
*Popkorn hol**Kaffee aufgesetzt und Stuhl reingestellt**Kuchen mitbringt*
... wenn alle nur zuschauen würde, dann wäre es ja gar nicht lustig[COLOR=royalblue]Ein großes DANKE an alle, die sich auf selbstlose Weise im Forum einbringen.[/COLOR]
[COLOR=silver]btw: REAL PROGRAMMERs aren't afraid to use GOTOs![/COLOR]
[color=indigo]Etwas ernster, aber auch nicht weiter tragisch, sieht die Situation bei Software-Patenten aus. Software-Patente sind eine amerikanische Erfindung und stehen auf dem selben Blatt wie genveränderte Babynahrung, die im Supermarkt nicht mehr als solche gekennzeichnet werden soll, um die Hersteller nicht gegenüber denen natürlicher Produkte zu diskriminieren ...[/color]
(from here)
Kommentar
-
Kommentar
-
Original geschrieben von Benny-one
genau, und alle Deutschen sind Nazis, alle Muslime Attentäter, usw...
java-programmierer
oder ist das wieder nur einer dieser "meine-sprache-ist-besser(länger) als deine"-threads
EDIT:
typo
Zuletzt geändert von axo; 27.04.2006, 16:12.
Kommentar
-
Bei diesen Gegebenheiten würde ich auch auf Java setzen.
Wird für euch aber eine hohe Lernkurve sein, Java + Java Server Faces und noch mehr Frameworks / BIbliotheken
aber eure Java-Abteilung hat da hoffentlich gute Dokus so dass ihr euch schnell einarbeiten könnt.
Kommentar
-
Wenn das SAP serverseitig läuft (und Ein-Ausgabe via Browser), sollte auch die onlinehilfe serverseitig laufen. Geht das mit Java überhaupt? (dh ausser ASP, PHP und SSI kenne ich keine Serverprogrammiersprachen). Und hat es eine Datenbankanbindung und html-template-Verarbeitung?
Und ist nicht Java von Sun eine vergleichbare Mischung von flip und power wie es PHP oftmals ist, und jedes gute System immer war (remember good old hypercard?)Zuletzt geändert von vierteln; 28.04.2006, 01:14.
Kommentar
-
Original geschrieben von axo
nein. was qualitätsmanagement, testing und entwicklung angeht, sind die jungs weit hintendran. und wenn sich die API weiterhin von version zu version so stark ändert, werden sie noch die letzten vergraulen, die noch an php glauben.
Das mit dem Vergraulen hat nichtmal Visual Microsoft hingekriegt ... die haben auch für jede Studio-Version 'ne neue API - Ide ...
... Java hatte bisher nur den Vorteil, dass bei der Verwendung von Java-Anwendungen (schon mangels Performance) keine Hektik aufkommt (und erzähl hier diesbezüglich keinen Dünnpfiff ... einige hier verwenden ZDE ...)
@resturan: Im übrigen kann ich Die Einstellung deiner Firma vollkommen nachvollziehen ... es hat noch nie viel Sinn gemacht auf vielen Hochzeiten zu tanzen (wohl für nicht für den einzelnen, nicht aber für's "Kollektiv") ... in Dem Falle kommt's nicht nur auf das derzeit vorhandene Knowhow an, sondern, auch wenn Du's kaum glauben magst, auf die langfristige Perspektive ... und das bedeutet im Falle der Generalisierung immer einen höheren Aufwand im Gegensatz zur Spezialisierung.Zuletzt geändert von goth; 28.04.2006, 01:40.carpe noctem
[color=blue]Bitte keine Fragen per EMail ... im Forum haben alle was davon ... und ich beantworte EMail-Fragen von Foren-Mitgliedern in der Regel eh nicht![/color]
[color=red]Hinweis: Ich bin weder Mitglied noch Angestellter von ebiz-consult! Alles was ich hier von mir gebe tue ich in eigener Verantwortung![/color]
Kommentar
-
@axo
full ack
Ich verstehe nicht warum man hier gleich von flamewar redet.
axo hat seine meinung zu dem thema abgegeben wie jeder
andere. Und das was er sagt stimmt, meiner meinung nach.
Wieviele enterpriselösungen kennt ihr die in php entwickelt wurden
und weiter gepflegt werden ?
Php macht es wirklich einfach, einfache dinge zu tun, aber
zu einem größeren projekt gehört einfach mehr. Seid mal ehrlich
allein in diesem forum, habt ihr schon so viel grausamen phpcode
gesehen und ihr glaubt ernsthaft das kommt in professionellen
softwareschmieden nicht vor ?
Php macht es einem einfach quick n' dirty sein aufgabe zu erledigen.
Und um mal bei den buzzwords zu bleiben, es gibt tatsächlich leute,
die glauben quick n' dirty wäre pragmatic oder gar agile.
Dass dem nicht so ist, sollte den meisten hier klar sein.
Php eignet sich hervorragend zum rapid prototyping für
webanwendungen aber um ein projekt größeren ausmaßes damit
realisieren zu wollen, muss man schon eine menge inthusiasmus haben.
PHP macht es einfach code immer und immer wieder zu wiederholen.
PHP macht es unheimlich einfach unheimlich schlecht lesbaren
code zu schreiben, mehr noch, es ist sogar so, dass man kämpfen
muss um leserlichen code zu schreiben. Ich habe meistens genug
damit zu tun mich auf die aufgabe zu kontentrieren, ich will nicht
noch mit der verwendeten sprache kämpfen.
PHP ist die hölle wenn es um teamentwicklung geht:
Biblieotheken können nicht organisiert werden.
Nameclashes sind vorprogrammiert sofern man nicht auf
die mymodule_myfunction-methode zurück greift.
Inkonsistens in der sprache an sich, fördert inkonsistens der
entwickler.
Hat man die anwendung mal "fertig", dann gehts zum deployment.
Oha, andere server, andere einstellungen. (Magic-quotes, Register-globals,
andere module, ini-settings)
Die php-gemeinde ist in aller regel ein zusammenschluss aus
hobby-fricklern die irgendwann mal professionelle frickler werden.
Ganz klar gibt es da ausnahmen, nur leider zu wenige.
@OP die entscheidung der vorgsetzten ist gut nachvollziehbar,
das risiko für das projekt ist am geringsten, und bleibt auch
langfristig geringer, wenn ihr bei java bleibt.
greets(((call/cc call/cc) (lambda (x) x)) "Scheme just rocks! and Ruby is magic!")
Kommentar
-
Original geschrieben von closure
Hat man die anwendung mal "fertig", dann gehts zum deployment.
Oha, andere server, andere einstellungen. (Magic-quotes, Register-globals, andere module, ini-settings)
Wer sein Entwicklungsystem nicht analog zum späteren Produktivsystem aufsetzt, ist schon selber schuld.
Und "auf solche Einstellungen hat man bei seinem Hoster aber nicht immer Einfluss", ist da auch kein Argument - wenn wir von größeren Projekten reden, dann hostest man die wohl nicht beim shared-hosting-Provider um die Ecke ...
Und in anderen Umgebungen ist das auch nicht unbedingt anders - wer sich beispielsweise mal mit dem Customizing im SAP beschäftigt hat, wird das kennen. Und gegen die Konfigurationsmöglichkeiten in so einem Umfeld ist 'ne php.ini mit ihrer "handvoll" Optionen ein Scherz.I don't believe in rebirth. Actually, I never did in my whole lives.
Kommentar
-
Hi,
das ding bei SAP ist, dass es eine designentscheidung war es so
zu entwickeln, dass es beim endbenutzer angepasst werden muss.
Man stellt eine fülle von tools zur verfügung die genutzt werden
können um dann beim kunden das ERP-system seiner wahl
zusammen "zuklicken" (klicken bitte nicht wörtlich nehen).
Aber für die meisten anwendungen ist ja soetwas gar nicht
vorgesehen. Es ist einfach so, dass diese differenzen zwischen
entwicklungsumgebung und produktionsumgebung auftauchen
können und es auch tun. Manchmal weiss man noch gar nicht
wo letztendlich das system laufen wird. Das ist aber sicher
kein problem dass nur PHP hat, da geb ich dir recht.
greets(((call/cc call/cc) (lambda (x) x)) "Scheme just rocks! and Ruby is magic!")
Kommentar
-
Original geschrieben von closure
das ding bei SAP ist, dass es eine designentscheidung war es so zu entwickeln, dass es beim endbenutzer angepasst werden muss.
Und ich rede hier nicht nur vom optischen Erscheinungsbild und Verhalten der vom Enduser genutzen Transaktionen - sondern auch vom Verhalten des Systems "unter der Haube", was die Vielfalt der damit abbildbaren Varianten diverser Datenmodelle/Geschäftsvorfälle angeht, etc.
Um das jeweils geforderte Verhalten zu erzielen jedesmal Programmänderungen/-anpassungen zu machen, wäre absolut nicht praktikabel - egal ob man das extern oder inhouse machen lassen würde, es wäre einfach wirtschaftlich kompletter Unfug.I don't believe in rebirth. Actually, I never did in my whole lives.
Kommentar
-
hi,
full ack, und dass das model funktioniert sieht man ja.
Das kann man aber auch nur machen wenn die software
das leistet was eben SAP leistet. SAP ist der quasistandard
im bereich ERP.
Bei anderen projekten muss es möglichst einfach sein,
die anwendung bei verschiedenen kunden einzusetzen,
weil sich aufwändige anpassungen nicht rentieren.
Aber wie gesagt, du hast natürlich recht, dass es
bei den meisten anwendungen immer kleinerer änderungen
bedarf und das so also nicht als contra-php argument gelten
kann.
greets(((call/cc call/cc) (lambda (x) x)) "Scheme just rocks! and Ruby is magic!")
Kommentar
Kommentar