Szum...
Wydaje się, że trochę się spóźniłem w tej dyskusji - ale właśnie to odkryłem. Jestem wam wszystkim wdzięczny za tak duży wkład.
Jestem autorem G-WAN, co daje jasno do zrozumienia, że poważnie nad tym pracowałem: G-WAN jest zarówno szybszy niż wszystkie inne serwery internetowe (bez przetwarzania) i wszystkie inne serwery aplikacji internetowych (dowolne przetwarzanie, jakie możesz sobie wyobrazić).
Tak, ANSI C umożliwiło również przetwarzanie bardziej statycznej zawartości - z mniej wydajnymi procesorami (ANSI C to nie tylko sprawianie, że dynamiczne treści są w ruchu).
Nawiasem mówiąc, G-WAN używa skryptów C (nie jest potrzebny kompilator C ani linker), więc cykl kompilacji / łączenia / opóźnienia nie istnieje.
Porównując G-WAN z .NET Java i PHP, napisałem podobne aplikacje we wszystkich 4 językach: http://gwan.ch/source/
Ku mojemu przerażeniu współczesne języki skryptowe nie były łatwiejsze w użyciu.
Jedną z części pracy, która jest szczególnie frustrująca, jest desperackie poszukiwanie „magicznego” wywołania API, które zrobi to, co chcesz.
Pomyśl, jak zrobić „ładne tysiące” w:
DO#
String.Format("{0:n}"...
Jawa
new DecimalFormat("0.00"); ...
PHP
number_format($amount, 2); ...
ANSI C
sprintf("%'.2f", amount);
„...” oznacza, że wymagana jest pewna konfiguracja wstępna lub przetwarzanie końcowe. ANSI C jest wyraźnie łatwiejszy w użyciu i do zapamiętania.
Kiedy PHP ma więcej niż 5900 wywołań API (C # i Java niedaleko), znalezienie odpowiedniego wywołania API jest wyzwaniem samym w sobie. Czas stracony, aby to znaleźć (a następnie przekonać się, jak źle zaimplementowano natywne wywołanie API), czas na naukę przez hart go następnym razem, gdy będziesz go potrzebować, cały ten czas pozbawia Cię czasu niezbędnego do rozwiązania Twojej aplikacji problemy.
Przeczytałem (powyżej), że PHP jest bardziej zwięzłe niż ANSI C? Dlaczego więc używać "//:: this is a comment ::"zamiast "// this is a comment"? Skąd taka głupio złożona składnia „ładnych tysięcy”?
Innym typowym argumentem jest to, że Java i tym podobne zapewniają dedykowane wywołania aplikacji internetowych.
Nie udało mi się znaleźć niczego, co pozwoliłoby uniknąć HTML w Javie, więc napisałem swoją wersję:
// 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();
}
Czy naprawdę wierzysz, że ten sam kod w ANSI C byłby bardziej złożony? Nie, byłoby to znacznie prostsze i szybsze.
Java (wywodząca się z C) wymaga od programistów łączenia ciągów wieloliniowych za pomocą znaku „+”
C # (wywodzący się z C) wymaga od programistów łączenia ciągów wieloliniowych z
PHP „+” (pochodzącym z C) wymaga od programistów połączyć ciągi wieloliniowe znakiem „.”
ANSI C nie ma teraz tego całkowicie głupiego (przestarzałego) wymagania.
Czy zatem tak oczywisty postęp, jakiego domagają się języki nowożytne? Ciągle tego szukam.
Szczerze,
Pierre.