Likes: 
Rene Pijlman <reply.in.the.newsgroup@my.address.is.invalid>:
> robert:
>>Rene Pijlman:
>> > Ontwerp toch een normaal OO-programma met classes, exception handling
>> > etc., dat functioneel hetzelfde doet.
>>
>>gzip zelf bouwen, tar zelf bouwen, grep zelf bouwen, sed zelf bouwen, tr
>>zelf bouwen, enzovoort.
>
> Nu haal je twee dingen door elkaar:
>
> 1) Programmeermodel Java vs. shell script
>
> 2) Hergebruiken vs. zelf bouwen
>
> Ik had het over punt 1.
Jij hebt het over dezelfde functionaliteit, oftewel 'hergebruiken versus
zelf bouwen'.
>>Plus dat ik niet verwacht dat jij in Java een grep kunt bouwen die
>>sneller is dan de commandlineversie; en met mega-GB logfiles is snelheid
>>toch vaak echt wel een vereiste.
>
> Nu haal je twee dingen door elkaar:
>
> 1) Programmeermodel Java vs. shell script
>
> 2) De performance van C vs. die van Java.
>
> Als performance belangrijk is dan zou ik zeggen: implementeer de code in
> C en gebruik JNI.
Puntje 2 van hierboven, dus: hergebruiken versus zelf bouwen. Daarnaast is
JNI voor lokaal gebruik wellicht een oplossing, maar het remote aanroepen
van een systeembeheertaak _die als pipeline moet worden uitgevoerd_ is geen
werkbare optie, tenzij je op de remote machine ook meteen je hele Java
runtime wilt gaan draaien (en dat voor alleen wat systeembeheertaken!).
> Het wordt tijd dat we shell scripts naar het computermuseum verbannen en
> dat we normale OO-talen, APIs en componentarchitecturen gaan gebruiken
> om bouwstenen aan elkaar te knopen.
Shellscripting is vooralsnog noodzakelijke glue tussen componenten die
ervan uitgaan dat je ze vanaf een commandline draait.
Jij hebt het over applicatieontwikkeling, en ik heb mezelf in deze gehele
thread nog niet zien roepen dat shellscripts daar de perfecte omgeving voor
zijn...
> Shell scripts zijn een idee uit de jaren 80, toen nog niemand
> daadwerkelijk gebruik maakte van OO-talen en componentarchitecturen.
Nu haal je twee dingen door elkaar:
1) programmeren
2) batchprocessing
--
robert
Quote
