Fredonner...
Il semble que je sois un peu en retard dans cette discussion - mais je viens de le découvrir maintenant. Et je vous suis reconnaissant à tous pour votre contribution.
Je suis l'auteur de G-WAN, ce qui montre clairement que j'ai sérieusement travaillé sur le sujet: G-WAN est à la fois plus rapide que tous les autres serveurs Web (aucun traitement) et tous les autres serveurs d'applications Web (tout traitement que vous pouvez imaginer).
Oui, ANSI C a également permis de traiter plus de contenu statique - avec des processeurs moins puissants (ANSI C ne consiste pas seulement à faire voler des contenus dynamiques).
En passant, G-WAN utilise des scripts C (aucun compilateur C ni éditeur de liens n'est nécessaire), de sorte que le cycle / délai de compilation / liaison n'existe pas.
En train de comparer G-WAN à .NET Java et PHP, j'ai écrit des applications similaires dans les 4 langues: http://gwan.ch/source/
Et, à ma grande consternation, les langages de script modernes n'étaient pas plus faciles à utiliser.
Une partie du travail qui est particulièrement frustrante est de rechercher désespérément l'appel d'API «magique» qui fera ce que vous voulez faire.
Réfléchissez à la façon de faire de jolis milliers de:
C #
String.Format("{0:n}"...
Java
new DecimalFormat("0.00"); ...
PHP
number_format($amount, 2); ...
ANSI C
sprintf("%'.2f", amount);
Le "..." signifie qu'une pré-configuration, ou un post-traitement, est nécessaire. ANSI C est clairement plus facile à utiliser et à retenir.
Lorsque PHP a plus de 5900 appels d'API (C # et Java non loin), trouver le bon appel d'API est un défi en soi. Le temps perdu pour trouver cela (et ensuite pour trouver à quel point l' appel API natif est mis en œuvre), le temps de l'apprendre par cœur pour la prochaine fois que vous en aurez besoin, tout ce temps vous prive du temps nécessaire pour résoudre votre application problèmes.
J'ai lu (ci-dessus) que PHP est plus concis que ANSI C? Pourquoi alors utiliser "//:: this is a comment ::"plutôt que "// this is a comment"? Pourquoi avoir une syntaxe si stupidement complexe de «jolis milliers»?
L'autre argument habituel est que Java et autres fournissent des appels dédiés pour les applications Web.
Je n'ai rien trouvé pour échapper au HTML en Java, alors j'en ai écrit ma version:
// all litteral strings provided by a client must be escaped this way
// if you inject them into an HTML page
public static String escape_html(String Name) {
int len = Name.length();
StringBuffer sb = new StringBuffer(len);
boolean lastWasBlankChar = false;
int c;
for(int i=0; i<len; i++) {
c = Name.charAt(i);
if(c == ' ') sb.append(" "); else
if(c == '"') sb.append("""); else
if(c == '&') sb.append("&"); else
if(c == '<') sb.append("<"); else
if(c == '>') sb.append(">"); else
if(c == '\n') sb.append("<br/>"); else {
c = c&0xffff; // unicode
if(c < 32 || c > 127) {
sb.append("&#");
sb.append(new Integer(c).toString());
sb.append(';');
} else
sb.append(c);
}
}
return sb.toString();
//szName = sb.toString();
}
Pensez-vous vraiment que le même code en ANSI C serait plus complexe? Non, ce serait à la fois immensément plus simple et plus rapide.
Java (dérivé de C) oblige les programmeurs à lier des chaînes multilignes avec un '+'
C # (dérivé de C) oblige les programmeurs à lier des chaînes multilignes avec un '+'
PHP (dérivé de C) oblige les programmeurs à liez les chaînes multilignes avec un '.'
ANSI C n'a pas cette exigence maintenant complètement stupide (obsolète).
Alors, est-ce que le progrès si évident est revendiqué par les langues modernes? Je le cherche toujours.
Cordialement,
Pierre.