C,C++,C#,Java,

Wenn du auf diese Trennung keinen Wert legst, hast du das Prinzip von Markup-Sprachen nicht verstanden. Lies die Posts von Helium immer wieder durch, bis du es einsiehst.

Und HTML mit C zu vergleichen ist natürlich Blödsinn. Auch ist C keine "Universalsprache", sondern (um es mal zu übertreiben) nicht mehr als ein dünner Wrapper um Assembler. C kann gar nichts, wie soll es denn eine Universalsprache sein? Es unterstützt weder objektorientierte Programmierung, noch generische, noch ...

Wenn du auf diese Trennung keinen Wert legst, hast du das Prinzip von Markup-Sprachen nicht verstanden<<

Markup-Sparchen sind eben viel zu dünn für ein derart heterogenes Anforderungsprofil, wie es der grosse Bereich Web-basioerte Anwendungen
darstellt.

Sieh's mal so: Mit einer ausgereiften Sprache wie C kann man von "Hello world"
bis zum Großrechner-Betriebssystem alles mit einer Sprache programmieren.
aber um ein Window im Browser aufpoppen zu lassen, braucht man 2 Sprachen, und
für Client-Server dann noch 2 andere plus Perl - da kann was einfach nicht
durchdacht sein.

Außerdem ist das Markup-Konzept von HTML sowieso verwässert:
Eine Markup-Sprache im reinen Sinne dürfte nicht Sachen enthalten wie
"<frameset rows=140px ..."
wohl aber
<frameset rows=30%..."
denn mit pixel ist man an eine Darstellungsart gebunden, was z.B. einen
Plotter ausschliesst - also eine Vermischung von Darstellung und Inhalt bei
HTML.

Fazit: Es bleibt dabei. Die Web-Sprachenvielfalt ist "kein Feature, sondern
ein Bug".

ChockoCookie

zwiebelsuppe schrieb:

Außerdem ist das Markup-Konzept von HTML sowieso verwässert:

Das mag sein, allerdings kommt man von solchen sachen mit XHTML eher wieder ab. Und ein riesiges monolithisches gebilde für alles was mit web zu tun hat, halte ich für unangebracht.
HTML ist ja nicht nur dazu gedacht Webseiten darzustellen, sondern dazu reinen, für die Maschine unlesbaren Text mit menschlicher Semantik zu versehen. Und gerade das sich HTML weitestgehend auf diese Aufgabe beschränkt, macht es so flexibel. zB ein Textmodebrowser wie Lynx könnte gar nicht den kompletten Standard implementieren, müsste er auch Dinge wie Stylesheets uä unterstützen.
Oder was ist mit Offlinedokumentation a la man Seiten? Wie willst du denn für einen reinen Offline Client Server-Preprocessing realisieren? Wie gesagt, HTML ist nicht nur für Web Designer.

Shade Of Mine

zwiebelsuppe schrieb:

Markup-Sparchen sind eben viel zu dünn für ein derart heterogenes Anforderungsprofil, wie es der grosse Bereich Web-basioerte Anwendungen
darstellt.

Richtiges Tool für die Aufgabe.
Die Trennung von Content Struklturierung, Content Design und Content Generierung ist vital.

Sieh's mal so: Mit einer ausgereiften Sprache wie C kann man von "Hello world"
bis zum Großrechner-Betriebssystem alles mit einer Sprache programmieren.

Es macht aber idR keinen Sinn für alles C zu nehmen.

Optimizer schrieb:

Ich find eigentlich gerade diese Template-Syntax genial. Java-Code ist schön anzusehen. HTML-Code ist schön anzusehen. In JSP kann man über Scriptlets Java-Code in HTML einfügen und damit dynamische Ausgaben erzeugen (so ähnlich ist es glaub ich bei PHP auch).

Klar, nix gegen eine Templatesprache (wobei ich da lieber gleich PHP embedde)

Vorteil: Alles was statisch ist, steht als HTML da und ist gleich erkennbar und gut lesbar.

Wirklich? Ist ein
<dhtml-if foo>
X
</dhtml-if>
wirklich so logisch?

problem ist: XML ist keine Programmiersprache. Deshalb finde ich das Konzept XML dazu umzumodeln irgendwie falsch.

Denn spätesten bei einer verschachtelten Schleife steigt man doch aus, weil Content und Logik gleich aussieht - es gibt keine Trennung (nicht mal eine optische).

Wenn man naemlich jetzt den Schritt geht, und nur XML produziert und kein HTML, hat man ein Problem: was macht der Tag? Ok, man kann sagen, alles was mit <dhtml> beginnt ist ein Zope Tag, aber das kann es doch nicht sein, oder?

Und sowas gibts dann auch für if und andere Kontrollstrukturen. Markup und Programmcode zu mischen ist wirklich hässlich, ich finde sowas also gut.

Ja, aber ich finde es schöner, wenn eine Schleife anders aussieht als eine Textausgabe

<dhtml-if foo>
  <p><dtml-var foo></p>
</dhtml-if>

<!-- versus -->

{if $foo}
  <p>{$foo}</p>
{/if}

ich finde variante 2 schöner.
weil ich klar erkennen kann was textausgabe ist und was eine kontrollstruktur.

vorallem wenn es nicht um HTML sondern XML geht, wo man die Tags nicht alle auswendig kennt.

zwiebelsuppe schrieb:

Genauso wie man die Universalsprache C in weiser Voraussicht so geschaffen hat, daß sie universell für fast alle Aufgaben geeignet oder dafür erweiterbar ist,und mit dem Standardisieren gewartet hat, bis sich die verlangte Anwedungsbreite abschätzen liess,

Auch Schwachsinn! C wurde von D. Ritchie und K. Thompson für UNIX entwicklet.

Dieser Thread erinnert mich an einen ähnlichen in diesem Forum

Shade Of Mine schrieb:

<dhtml-if foo>
 <dtml-var foo>
</dhtml-if>



{if $foo}
 {$foo}
{/if}
weil ich klar erkennen kann was textausgabe ist und was eine kontrollstruktur.

vorallem wenn es nicht um HTML sondern XML geht, wo man die Tags nicht alle auswendig kennt.

Ich finde dein konkretes Beispiel als Tag auch hässlich. Liegt wahrscheinlich irgendwie an der Bennenung, oder am Highlighting, keine Ahnung. Das ist aber IMHO ein konkretes Problem und lässt sich so nicht verallgemeinern.

Ich kann prinzipiell nicht ganz verstehen, was du z.B. gegen ein

<c:if value="...">
        <p>Nene!</p>
    </c:if>

hast. Wenn Das ist jetzt nur ein ganz kleiner Brocken Code. Wenn du aber ne größere Seite hast, die mit Scriptlets durchsetzt ist, hast du einfach nur noch nen Riesensalat und das ist bei PHP auch nicht besser. Und so hast du für alles schön Tags.

Außerdem siehst du es IMHO auf einer zu niedrigen Ebene. Man wird normalerweise viel größere Teile in ein Custom-Tag auslagern. z.B. ein Tag

<div>
    ...
    <mycustomtags:listAllEntries showHidden="true"/>
    ...
</div>

Wo dann das Tag das if( keine Einträge vorhanden ) selber vornimmt und nur ausgibt "Es existieren zur Zeit keine Einträge". Sich eigene Tags zu schreiben finde ich zukunftsträchtig.
Na wie auch immer, Markup-Code mit Programmcode zu mischen finde ich in jedem Fall verdammt hässlich.

interpreter

Marc++us schrieb:

fixer schrieb:

Wie fixt man das Problem?

Datumsroutinen verwenden, die auf 64 Bit basieren.

Dadurch verschiebt man das Problem ja auch nur nach hinten... *scnr

Auch Schwachsinn! C wurde von D. Ritchie und K. Thompson
für UNIX entwicklet. <<

Das ist ja was *ganz* neues!

Richtiges Tool für die Aufgabe. <<

Da man schon für minimalste Features der im Web unandingbaren Interaktivität
eine zweite und vielleicht noch eine dritte braucht, ist HTML eben nicht
das richtige Tool.
Das richtige Tool wäre es, wenn man mit ein paar Zusatzfunktionen aus einer
Bibliothek Funktionen wie Pull-Down-Menüs nachrüsten könnte.
Ein Tool, zu dessen Einsatz man noch zwei oder drei weitere braucht, um modernen
Anforderungen nachzukommen, ist wohl kaum das richtige. Genau das ist aber der
Stand mit HTML und Javascript, cgi-perl etc.

Shade Of Mine

zwiebelsuppe schrieb:

Da man schon für minimalste Features der im Web unandingbaren Interaktivität

Nein.

eine zweite und vielleicht noch eine dritte braucht, ist HTML eben nicht
das richtige Tool.

Richtiges Tool für den Job.

Ich will mit SQL Datenbankabfragen machen, weil das mit C nicht gut gehen würde. Ich will mit HTML und CSS das Design erstellen, weil das mit Java und Python nicht gut gehen würde.

Das richtige Tool wäre es, wenn man mit ein paar Zusatzfunktionen aus einer
Bibliothek Funktionen wie Pull-Down-Menüs nachrüsten könnte.

Keine Frage: HTML hat zuwenige GUI Features.

Ein Tool, zu dessen Einsatz man noch zwei oder drei weitere braucht, um modernen
Anforderungen nachzukommen, ist wohl kaum das richtige.

Dann schau dich mal um:

Man verwendet GUI Designer die XML Code erstellen der dann von einer Runtime zu einer GUI zusammengebaut wird. Findest du das genauso schlimm?

Es ist einfach super eine Markup Sprache verwenden zu können um Text zu formatieren. Es ist geil mit einer Sprache wie CSS das Design festzulegen (sind ja 2 absolut unabhängige Sachen, idR hat man ein Design, dass über eine beliebige Textstruktur drüber geklatscht wird, oft auch von verschiedenen Leuten erstellt). Ich will nicht Perl schreiben muss, weil das Web sich ändert und PHP momentan die geilsten Features hat. Ich kann Apache Module verwenden, was die Sache beschleunigt. Bin ja auch nicht auf CGI festgelegt, weil ich für C++ Binaris einfach fastCGI anwerfe und unter Windows hau ich mir nen IIS drauf, weil der ASP.NET kann.

Ich kann mit PHP einfach nicht vernünftig COM Anwendungen schreiben und man tut sich mit JSP schwer ein kleines Newsscript zu schreiben... Alles hat vor und nachteile.

Ach ist es nicht geil wenn du das richtige Tool für den Job verwenden kannst? Um die Vorteile besser ausnutzen zu können?

Stell dir mal vor wir würden heute alle noch mit Basic programmieren, weil wozu etwas neues nehmen, wenn Basic eh alles kann?

Shade Of Mine

Optimizer schrieb:

Sich eigene Tags zu schreiben finde ich zukunftsträchtig.

Allein das Parsen ist ja schon schwerer
warum nicht eine andere Syntax nehmen? Smarty ist doch ganz nett. Die Idee ist, dass sich der Code unterscheidt. ob ich jetzt <dhtml oder <dhtml: als Prefix habe ist ja egal. Was sind die Vorteile davon gegenüber einer anderen Syntax wie Smarty ({ und } als delimiter (wobei das frei definierbar ist).

spätestens bei
<a href="<dhtml-var url>">
dreht es doch einem den magen um, oder? Ich meine, es sieht aus wie XML, tut so als wäre es XML, ist es aber nicht. Es ist nur umständlicher zu parsen

Na wie auch immer, Markup-Code mit Programmcode zu mischen finde ich in jedem Fall verdammt hässlich.

Ich habe nix dagegen, solange man business von layout logik trennt.

Ach ist es nicht geil wenn du das richtige Tool für den Job verwenden kannst? Um die Vorteile besser ausnutzen zu können?<<

Ja, das wäre ge*l. Ich sehe dennoch nicht ein, wieso man zum Erzeugen minimalster
Interaktivitäts-Features wie einem aufpoppenden Window im Browser eine zweite
Sprache hinzunehmen müssen soll, anstatt die erste Sprache einfach um eine
neue Funktion zu erweitern. HTML ist dafür allerdings dann nicht geeignet; hätte
man warten sollen, bis klar ist, wie eine solche Sprache aussehen könnte, die
die notwendigen Features vcn HTML, Javascript, Java und cgi-Perl zusammenfaßt,
und dann standardisieren, plus Erweiterbarkeit mit Bibliotheksfunktionen.
Naja, kommt vielleicht in 10 oder 20 Jahren; es dauerte ja auch 20 Jahre vom ersten
Computer bis zur ersten echten Universal-Programmiersprache.
Aber mal im Ernst: Eine ganze Sprache wie Javascript mit OO und C-Syntax,
nur um mal ein Menü aufklappen zu lassen, das ist schon komisch.

Stell dir mal vor wir würden heute alle noch mit Basic programmieren, weil wozu etwas neues nehmen, wenn Basic eh alles kann?<<

Unschöner Gedanke. Basic ist aber auch keine Universelle Sprache, da Basic
(wie Fortran) ursprünglich
für Nicht-Programmierer erdacht wurde, wogegen C ausdrücklich für
Programmierer gemacht ist.

interpreter

zwiebelsuppe schrieb:

Basic ist aber auch keine Universelle Sprache, da Basic
(wie Fortran) ursprünglich
für Nicht-Programmierer erdacht wurde, wogegen C ausdrücklich für
Programmierer gemacht ist.

Eine Programmiersprache für Nichtprogrammierer. Interessant...

finix

Aber mal im Ernst: Eine ganze Sprache wie Javascript mit OO und C-Syntax,
nur um mal ein Menü aufklappen zu lassen, das ist schon komisch.
[/quote]
Streitest du nicht die ganze Zeit schon für eine Sprache für _alles_??

Eine Programmiersprache für Nichtprogrammierer. Interessant...<<

Ja. Basic, Fortran, Cobol wurden erfunden, damit
*Anwender* den Computer für ihre Zwecke einfach programmieren können; "echte"
Programmierer programmierten damals nämlich in Assembler.
C war die erste erfolgreiche Sprache, die dafür gedacht war, daß *Programmierer*
(Systemprogrammierer etc.) bequem programmieren konnten. Deshalb hat sich
C ja auch *allgemein* durchgesetzt und Fortran nur in Nischen.
Nachzulesen auf den "history of C" Papers vom C-Erfinder.

Helium

Ein Tool, zu dessen Einsatz man noch zwei oder drei weitere braucht, um modernen
Anforderungen nachzukommen, ist wohl kaum das richtige.

Ja, da stimme ich die vollkommen zu. Echt. Ich brauche einen Hammer, um einen Nagel in die Wand zu kloppen, aber eine Zange, um ihn Raus zu ziehen. Für eine Schraube brauch ich dann auch noch einen Schraubenzieher. Und dann gibts da auch noch Kreuz und Schlitz und auch noch in verschiedenen Größen. Und manchmal braucht man Noch ganz andere Dinge, wie Maulschlüssel, Rohrzangen, Seitenschneider, Fuchsschwänze, und und und.
Wie blöd muss man eigentlich sein.
Hätten die mit den Werkzeugen mal gewartet, bis klar geworden ist, was man alles so braucht und hätte dann das eine Universalwerkzeug erfunden.

(BTW: Tool == Werkzeug)

Jetzt redest du aber Unsinn. Du weißt doch genau, das man mit einem Apfel alles machen kann.

Bashar

zwiebelsuppe schrieb:

Nachzulesen auf den "history of C" Papers vom C-Erfinder.

Wo findet man dieses Paper, und welcher der beiden C-Erfinder hat das geschrieben? Google spuckt nichts sinnvolles zu dem Thema aus.

"The development of the c language" von D.Ritchie.

Hätten die mit den Werkzeugen mal gewartet, bis klar geworden ist, was man alles so braucht und hätte dann das eine Universalwerkzeug erfunden.<<

Meine Rede. Web-Programmierung ist heute wohl da, wo die klassischen
Programmiersprachen in den 1950ern waren: umständlich, teil-redundant, unübersichtlich. Vielleicht wird sich in 20 Jahren das html-cgi-perl-python-ruby-javascript-java-Chaos gelichtet haben und eine
passende Sprache herauskristallisiert haben, so wie sich C damals in der
klassischen Programmierung durchgesetzt hat und damit Fortran-Cobol, Algol usw.
überflüssig gemacht hat.