Hum ...
Görünüşe göre bu tartışmaya biraz geç kaldım - ama şimdi keşfettim. Ve bu kadar çok katkı için hepinize minnettarım.
Ben G-WAN'ın yazarıyım, bu konu üzerinde ciddi bir şekilde çalıştığımı açıkça ortaya koyuyor: G-WAN hem diğer tüm Web Sunucularından (işleme yok) hem de diğer tüm Web Uygulama Sunucularından (hayal edebileceğiniz herhangi bir işlem ) daha hızlıdır .
Evet, ANSI C, daha az güçlü CPU'larla daha statik içeriği işlemeyi de mümkün kıldı (ANSI C yalnızca dinamik içeriği uçurmakla ilgili değildir).
Bu arada, G-WAN C betikleri kullanır (C derleyicisi ve bağlayıcı gerekmez) bu nedenle derleme / bağlama döngüsü / gecikmesi mevcut değildir.
G-WAN'ı .NET Java ve PHP ile karşılaştırma sürecinde 4 dilde de benzer uygulamalar yazdım : http://gwan.ch/source/
Ve benim dehşet içinde, modern betik dillerinin kullanımı kolay değildi .
İşin özellikle sinir bozucu olan bir kısmı, umutsuzca yapmak istediğiniz şeyi yapacak 'sihirli' API çağrısını aramaktır.
İçinde 'oldukça binlerce' nasıl yapılacağını düşünün:
C #
String.Format("{0:n}"...
Java
new DecimalFormat("0.00"); ...
PHP
number_format($amount, 2); ...
ANSI C
sprintf("%'.2f", amount);
"...", bazı ön konfigürasyonların veya sonradan işlemenin gerekli olduğu anlamına gelir. ANSI C'nin kullanımı ve hatırlanması açıkça daha kolaydır.
PHP'nin 5900'den fazla API çağrısı (C # ve Java çok uzakta değil) olduğu durumlarda, doğru API çağrısını bulmak başlı başına bir zorluktur. Bunu bulmak için harcanan zaman (ve daha sonra yerel API çağrısının ne kadar kötü uygulandığını bulmak için), bir dahaki sefere ihtiyacınız olduğunda onu öğrenmenin zamanı, tüm bu zamanlar sizi başvurunuzu çözmek için gereken zamandan mahrum ediyor sorunlar.
PHP'nin ANSI C'den daha kısa olduğunu okudum (yukarıda)? O zaman neden "//:: this is a comment ::"yerine kullanın "// this is a comment"? Neden bu kadar aptalca karmaşık 'güzel binler' sözdizimi var?
Diğer olağan argüman, Java ve benzerinin Web uygulamaları için adanmış çağrılar sağlamasıdır.
Java'da HTML'den kaçacak hiçbir şey bulamadığım için kendi sürümümü yazdım:
// 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();
}
ANSI C'de aynı kodun daha karmaşık olacağına gerçekten inanıyor musunuz? Hayır, ikisi de gayet kolay olurdu ve daha hızlı.
(C türetilmiştir) Java edilir gerektiren bir '+' ile bağlantı çok hatlı dizeleri için programcılar
edilir (C türetilmiş) C # gerektiren bir '+' ile bağlantı çok hatlı dizeleri için programcılar
(C türetilmiş) PHP edilir gerektiren programcıları çok satırlı dizeleri bir '.' ile bağlayın
ANSI C artık bu tamamen aptalca (eski) gereksinime sahip değil.
Öyleyse, modern dillerin iddia ettiği bu kadar açık ilerleme miydi? Hâlâ arıyorum.
İçtenlikle,
Pierre.