🚀 go-pugleaf

In article <3c73694a$0$4602$e4fe514c@dreader3.news.xs4all.nl>, Frans Bouma wrote:
> "Marco van de Voort" <marcov@toad.stack.nl> wrote in message news:slrna755t3.1ml.marcov@toad.stack.nl...
>> In article <1014140987.432050@seven.kulnet.kuleuven.ac.be>, Pieter Philippaerts wrote:
>> > Alle andere manieren om produktiviteit te meten (inclusief empirisch
>> > bewijs) bevestigen dat .NET gewoon sneller werkt (zowel programmeren
>> > als uitvoeren).
>>
>> 1. Sneller dan ... ? VB?
> 
>     wat ben je nou aan het doen, Marco?

Beetje M$ headers vertalen, servers in de gaten houden, koffie drinken.

> Beetje zeuren dat .NET niet  beter is?

Neuh. Gewoon bewijs of zelfs maar een simpel review van een onafhankelijke
instantie, geen Microsoft of adepten. "Gevoelens" van
"Ervaringsdeskundigen" zijn leuk, en ik neem ze ter indicatie aan, maar
overtuigd? nee.

Ik heb de laatste tijd wat ingelezen over .NET hier en daar, omdat het nuttig
lijkt voor sommige doeleinden.

> Waarom ga je er niet een tijdje mee werken en concludeer je zelf of het
>     brandhout is of precies wat je zocht.

Op mijn werk-PC PPro 233 met 128 MB? Dacht het niet :-)

> Ik zit 12 uur per dag in Visual Studio, al jaren, en ik kan je verzekeren
>     dat VS.net de productiviteit sterk verhoogd. Zeker op het gebied van
>     C++.

> Ook voor mensen die webscripting doen is het een verademing. Er
>     wordt gewoon veel voor je geregeld wat anders veel tijd kostte en DUS
>     is dat gemak. De mensen die alles altijd met de hand willen doen...
>     tja... moeten we daar nog woorden aan smerig maken?
 
>> 2. Mooi. Waar zijn de links naar de niet Microsoft
>> gerelateerde/georienteerde sites?
> 
>     Hij zit hier, op deze stoel :) ervaringsdeskundige ;).

Zie boven :-) (en ja, ik had dit al gezien)

>     Of ben je zelf ook ervaringsdeskundige en wil je beweren dat
>     jij het totaal anders ziet?

Nee, ik ben iemand die niets weet, en alleen maar wat redelijk onpartijdige
referenties zoekt.
 
>> >> - Microsoft's gauging developer efficiency by counting lines of code
>> > Ik heb nooit gezegd (en Microsoft trouwens ook niet) dat hoe minder
>> > lijnen code hoe beter een programma is.
>> > Het is wel opvallend dat er een aantal dingen altijd samengaan in
>> > vergelijkingen.
>> > Deze zijn snelheid, aantal lijnen code en het (korte) programmeerswerk.
>>
>> Aantal lijnen is _nooit_ belangrijk. Als het typewerk zo veel meer en
>> vermoeiend is, dan komt dat ook in de totale tijd ten uitdrukking.
> 
>     aantal regels is wel belangrijk, want het is het enige wat je
>     hebt.

Mwhaa, de meeste kantoren hebben een klok, en die vind ik toch wat
genuanceerder. Tijd van begin tot deployment dus. Daar zit namelijk ook
debugging bij.

> Het is een (niet de) graadmeter om te meten of een stuk code
>     'simpel' dan wel 'uitgebreid' dan wel 'complex' te noemen is.
>     (dwz: niet complex in 'moeilijk te begrijpen', maar in 'moeilijk
>     uit te programmeren')

Niet echt. Compressed syntax of niet, want dit ging over een voorbeeld in
twee talen.
 
>> >> niet iedereen zie overschakelen.
>> >
>> > Hier zijn een aantal redenen voor:
>> >  - het is nog (te) nieuw.. (niet vergeten dat je het nog maar sinds enkele
>> >     weken in de winkel kan kopen)
>>
>> Developpers krijgen grut meestal eerder.
> 
>     Mja, maar dat is maar betrekkelijk. de .NET beta's en de docs omtrent
>     de .NET talen en het framework zijn al bijna een jaar beschikbaar.
>     Je kunt een vliegende start maken op 1 maart, als je het hebt
>     bijgehouden :).

Als ik hier en daar rondlees, en hoor dat het nog niet eens niet-debug code
kan genereren :-)
 
>     Maar ik denk dat het wel even gaat duren voordat je die dubbele
>     productiviteit er uithaalt. DIt komt mede omdat je in den beginne
>     niet kunt leunen op een bestaande bak met eigen objects waar je mee
>     kunt bouwen. Die moet je dus zelf aanleggen. 

Mee eens, maar dat geldt voor elke nieuwe API. Aan de andere kant kan je
waarschijnlijk nog lang met plain win32 doorwerken.

> Verder is het framework dermate nieuw dat veel platgetreden paden mbt
>     n-tier development bijvoorbeeld toch iets anders lopen in sommige
>     applicaties, waardoor er tijd verloren gaat met het vinden van de
>     beste oplossing voor problemen die men al door en door kent.

Half jaar wachten tot inet vol zit met voorbeelden dus.
 
>> >  - de implementaties op de andere OSen zijn nog niet af
>>
>> Als ze al af komen. Of beter gezegd, ik denk dat de Open Source community
>> uiteindelijk wel wat af krijgt, maar dat de Windows .NET apps voldoende aan
>> Windows zullen worden gehangen omdat effectief nog nutteloos te maken.
> 
>     Mono is al erg ver en ziet er goed uit. Een aantal projects zijn
>     wat stil gevallen binnen Mono, maar Ximian heeft de vaart er goed in.
>     Ik heb er wel vertrouwen in.

Het is een high profile project ja. Ik geloof wel dat er wat uit komt, maar
de uitwisselbaarheid met een gemiddelde op win32 ontwikkelde app zie ik
donker in.

Maar misschien ben in een pessimist.
 
>> Als Microsoft zich niet commit voor de implementatie op andere platformen,
>> dan geef ik er nog geen halve eurocent met een gat voor de portabiliteit van
>> .NET.
> 
>     Je begrijpt ook niet veel van webservices of wel? :)

Is niet mijn sterkste punt.

>  portabiliteit
>     is niet meer op 'programmatuur'niveau geregeld maar op 'functioneel'
>     niveau: een doos in de hoek die een service levert is van nut
>     voor programmatuur op andere platforms, of dat nu solaris is of
>     linux, dat boeit niet. Die doos in de hoek mag win2k / .NET draaien
>     en op de solaris bak maak je daar middels soap gewoon gebruik van.
>     andersom kan ook trouwens.

Wat is dan het punt van het hebben van .NET op Solaris. Als je daar toch
gewoon iets pakt dat native SOAP doet?
 
>     Waarom moet die doos in de hoek dan OOK solaris draaien?

Ik doel er meer op dat beide kanten .NET draaien. Irrespecive van OS.
Gemeenschappelijke codebase tussen die verschillende hybride netwerk
servers/clients e.d.