Ik overweeg om een applicatie in C# te schrijven aangezien Delphi tegenwoordig niet meer zo geweldig is en C++ niet al te productief is. Maar hoeveel mensen hebben tegenwoordig .NET geinstalleerd? Zijn er statistieken beschikbaar? Want ik wil mijn gebruikers niet vragen om eerst een 100 MB .NET runtime te downloaden voordat ze mijn programma kunnen gebruiken.
/u/56680/gurgi.png?f=community)
/u/32913/crop5609886665acc.png?f=community)
Ik heb het iig wel standaard geinstalleerd omdat ik zelf ook aan het knutselen ben met .NET, maar daar heb je niet veel aan
Maar hoe kom je er bij dat het 100MB is? .NET 2.0 Framework is "maar" +/- 23MB?
This posting is provided "AS IS" with no warranties, and confers no rights.
Ik gok dat hij de SDK verward met de redistributable, maar je hebt idd die laatste nodig.:
[...]
Ik heb het iig wel standaard geinstalleerd omdat ik zelf ook aan het knutselen ben met .NET, maar daar heb je niet veel aan
Maar hoe kom je er bij dat het 100MB is? .NET 2.0 Framework is "maar" +/- 23MB?
Digitaal onderwijsmateriaal, leermateriaal voor hbo
/u/30977/crop654a08a5866a6_cropped.png?f=community)
Vista zal .NET standaard geinstalleerd hebben (meen ik). Mensen die de officiele ATi drivers geinstalleerd hebben zullen ook .NET hebben. Misschien dat het huidige aantal gebruikers nu nog niet extreem groot is, maar het zal snel groeien.
Weet ook dat .NET applicaties mogelijk op Unix (Linux / OS X) aan de praat te krijgen zijn met Mono, daardoor kun je zo weer een grote groep erbij pakken. Ik kan je helaas geen ervaringen over Mono geven
Weet ook dat .NET applicaties mogelijk op Unix (Linux / OS X) aan de praat te krijgen zijn met Mono, daardoor kun je zo weer een grote groep erbij pakken. Ik kan je helaas geen ervaringen over Mono geven
🌞🍃
:strip_icc():strip_exif()/u/80211/crop625154a54bd09_cropped.jpg?f=community)
Dan moet je het combineren met andere zoekwoorden
http://www.google.nl/sear...t+without+framework&meta=
http://www.google.nl/sear...Framework+installed&hl=nl
Digitaal onderwijsmateriaal, leermateriaal voor hbo
:strip_exif()/u/26373/anim4.gif?f=community)
"I had a problem, I solved it with regular expressions. Now I have two problems". That's shows a lack of appreciation for regular expressions: "I know have _star_ problems" --Kevlin Henney
:strip_icc():strip_exif()/u/105199/crop5cb76c6d18020_cropped.jpeg?f=community)
:strip_icc():strip_exif()/u/180657/texacoiq2.jpg?f=community)
Ow kom op. Java = traag kennen we nu wel 
. Als je aan de hand daarvan wilt gaan bepalen welke taal je wilt gaan gebruiken dan kan je beter nu stoppen. Als je java prog gaat swappen ligt dat aan het geschreven programma en echt niet aan de JVM.
Daarnaast heb je ook nog zoiets als Object Pascal en Kylix (zuigt, is buggy, maar werkt wel) dus ook je punt m.b.t. aan MS vastzitten met Delphi gaat niet echt op. En de punten die je opnoemt om zowel C als Delphi niet te willen gebruiken wil ik het niet eens over gaan hebben.
Sorry hoor, maar ik vindt je meeste argumenten echt kul en ik kan me ook bijna niet voorstellen dat je een gedegen onderzoek hebt gedaan naar de verschillende ontwikkelomgevingen die je op het oog hebt.
Als mensen je programma willen gebruiken en het is geschreven in .NET dan installeren ze het .NET framework echt wel. De figuren die .NET weigeren te installeren loop je dan mis maar ik kan me niet voorstellen dat je je keuze laat afhangen van deze groep mensen.
. Als je aan de hand daarvan wilt gaan bepalen welke taal je wilt gaan gebruiken dan kan je beter nu stoppen. Als je java prog gaat swappen ligt dat aan het geschreven programma en echt niet aan de JVM.Daarnaast heb je ook nog zoiets als Object Pascal en Kylix (zuigt, is buggy, maar werkt wel) dus ook je punt m.b.t. aan MS vastzitten met Delphi gaat niet echt op. En de punten die je opnoemt om zowel C als Delphi niet te willen gebruiken wil ik het niet eens over gaan hebben.
Sorry hoor, maar ik vindt je meeste argumenten echt kul en ik kan me ook bijna niet voorstellen dat je een gedegen onderzoek hebt gedaan naar de verschillende ontwikkelomgevingen die je op het oog hebt.
Als mensen je programma willen gebruiken en het is geschreven in .NET dan installeren ze het .NET framework echt wel. De figuren die .NET weigeren te installeren loop je dan mis maar ik kan me niet voorstellen dat je je keuze laat afhangen van deze groep mensen.
[ Voor 3% gewijzigd door Creepy op 19-08-2006 16:23 ]
"I had a problem, I solved it with regular expressions. Now I have two problems". That's shows a lack of appreciation for regular expressions: "I know have _star_ problems" --Kevlin Henney
Nee, dat kan niet. De runtime heb je altijd nodig.
Het is wel zo dat er bepaalde tooltjes zijn, die ervoor zorgen dat de runtime in je executable zelf vervat zit, maar da's imho meer een nadeel dan een voordeel.
Zowiezo heb je de runtime nodig.
Je kan wel je .NET code direct naar native code compileren, zodanig dat je de IL stap overslaat, en de JI compiler niet nodig hebt, maar ook hier kleven er nadelen aan.
Dan zit je aan Sun vast.
Is er een nadeel verbonden om aan 'MS' vast te zitten ? AFAIK is MS een redelijk stabiel bedrijf, dat niet gauw over de kop zal gaan, en die wel nog een tijdje zal investeren in .NET
Komt dit dan gewoon niet omdat je die exceptie niet opvangt ? Unhandled exceptions willen je applicatie wel eens doen crashen ja...
[ Voor 43% gewijzigd door whoami op 19-08-2006 16:39 ]
https://fgheysels.github.io/
/u/2305/crop653618cca8542_cropped.png?f=community)
De Java JVM zal dan wel niet geinstalleerd hoeven te zijn, maar je kan dat ding heel mooi mee packagen met ja applicatie. Zelfde geldt voor .NET.
Als mense jou applicatie downloaden, dan kan dat beetje extra ook wel mee. Als mensen het krijgen op een CDtje, waar praten we dan nog over.
Mensen die weigeren een JVM of .NET runtime te installeren zijn er praktisch niet. Enkel diegenen die niet weten wat het is en het nog nooit nodig gehad hebben. Verder gewoon aangeven dat het meegeinstalleerd wordt. Gebeude bij VB applicaties toch ook altijd al?
Als mense jou applicatie downloaden, dan kan dat beetje extra ook wel mee. Als mensen het krijgen op een CDtje, waar praten we dan nog over.
Mensen die weigeren een JVM of .NET runtime te installeren zijn er praktisch niet. Enkel diegenen die niet weten wat het is en het nog nooit nodig gehad hebben. Verder gewoon aangeven dat het meegeinstalleerd wordt. Gebeude bij VB applicaties toch ook altijd al?
[ Voor 31% gewijzigd door The - DDD op 19-08-2006 16:49 ]
"I had a problem, I solved it with regular expressions. Now I have two problems". That's shows a lack of appreciation for regular expressions: "I know have _star_ problems" --Kevlin Henney
/u/44276/got_icon5.png?f=community)
Aan de inhoud van de bovenstaande tekst kunnen geen rechten worden ontleend, tenzij dit expliciet in dit bericht is verwoord.
Verwijderd
Tja, net als een paar honderd andere compilers werkt Delphi niet met een VM en een garbage collector. Maar wat is er mis met zelf je rommel opruimen wanneer je 't niet meer nodig hebt? Ik moest er heel erg aan wennen dat ik in C# de boel niet eens kon free-en...
Idem in C#, ik zie geen verschil wat dat betreft.
De editor is op sommige punten minder dan die van Visual Studio, maar daar zijn prima add-ins voor te krijgen (GExperts, CodeRush, etc.). En op sommige punten is 'ie doodgewoon beter: bookmarks, block edit functies, etc.
Maar ik kan er met de beste wil van de wereld niet bij wat de kwaliteit van een editor te maken heeft met de kwaliteit van een compiler.
Ook in C# zul je bindings naar 3rd party C/C++ libraries zelf moeten schrijven. Dat het .NET framework veel van die libraries overbodig maakt is mooi meegenomen, maar alweer: geen verschil.
In C# zijn pointers binnen managed code uit den boze, dus van dat probleem ben je meteen af. Nu nog zien of je die C libraries aan de praat krijgt in 'unsafe' mode, maar dan kom je in hetzelfde pointer-wespennest als onder Delphi.
Nog nooit meegemaakt in de afgelopen 8 jaar dat ik met Delphi werk, maar dan gebruik je toch gewoon StrToIntDef? Wel zo handig...
Compileer je C# project maar 's in release mode, dan heb je hetzelfde probleem.
Ik verdien m'n brood met het schrijven van programma's in zowel Delphi als C#, en ik zie niet zo bar veel verschillen. OK, op .NET gebied blijft Delphi 2006' IDE nog hangen op 't 1.1 framework, maar de compiler kan goed overweg met 2.0. En op native niveau doet Delphi m.i. ook niet onder voor MS's C++ compiler.
Verwijderd
Perl, Python en Ruby zijn interpreters, en wanneer je voor C++ een GC nodig hebt, ben je wel heel erg beroerd aan het programmeren...
Tools -> Editor options, 'Use tab character' aanzetten, en 'Smart tab' uitzetten. Precies het tegenovergestelde van wat ik prettig vind.
D6 is niet de meest geniale Delphi versie die er is. Probeer 's te downgraden naar D5 (als je die webservices dingen niet nodig hebt) of te upgraden naar D7. D2006 duurt inderdaad even voor 'ie opgestart is (vergelijkbaar met VS2005), maar bij mij crasht 'ie niet bij het afsluiten.
Hoe gaat dat dan in z'n werk, garbage collection zonder VM ?
Doet het OS het dan voor jou ?
https://fgheysels.github.io/
"I had a problem, I solved it with regular expressions. Now I have two problems". That's shows a lack of appreciation for regular expressions: "I know have _star_ problems" --Kevlin Henney
Verwijderd
Niet eens naar gekeken, maar als C++ of Delphi programmeur weet je gewoon dat je de objecten die je zelf hebt gemaakt ook weer moet opruimen. Daar zullen vast wel vuilnismannen voor uitgevonden zijn die dat voor je doen, maar dan blijft 't nog steeds jouw veratwoordelijkheid dat 't opgeruimd wordt.
Dan gooi ik ze liever zelf weg.
Verwijderd
Net even op http://www.yaml.org gekeken, maar dat lijkt me een project dat gedoemd is te mislukken. Ze willen XML opnieuw uitvinden, maar dan "human readable". Met als gevolg dat 't slechter "computer parsable" is. En laten computers nou 's heel goed zijn in het "human readable" maken van dingen die ze goed kunnen parsen.
Ik zie er zo gauw geen voordeel in t.o.v. XML met een duidelijke XSD of schema, en een leuk XSL transformation scriptje om de boel "human readable" te maken.
Maar niks staat je in de weg om zelf een YAML parser te maken, toch?
Garbage collection kan de productiviteit verhogen en redundancy schelen. Neem een voorbeeld als dit:
Zie je het probleem ook? "CloseFile(F);List.Free;" komt maar liefst 3 keer voor, dikke redundancy. (Ja, dit zou je ook op een andere manier kunnen oplossen maar het is maar 1 voorbeeld.) Met garbage collection zal dat automatisch voor je gedaan worden.
Bovendien wordt handmatig vrijmaken lastiger wanneer je te maken hebt met een shared resource die wordt gebruikt door meerdere threads. Dan moet je je eigen reference count code schrijven. Het zou toch handig zijn als je dat niet hoeft?
"Gedoemd om te mislukken" is een groot woord. Definieer eerst "mislukken". Het wordt intensief gebruikt in Ruby on Rails.
of:
Ik heb mijn keuze snel gemaakt. XML bevat tonnen redundancy. Leuk voor complexe documenten of markup, maar overkill voor simpele object serialization.
Maar, zoals ik al zei: vliegenmepper vs atoombom. Ze zijn allebei ontworpen voor andere dingen, klaar.
code:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
| List := TStringList.Create;
AssignFile(F, "foo.txt");
// Ervan uitgaande dat we I/O exceptions gebruiken
try
Reset(F);
Readln(Line);
List.Add(Line);
DoeIetsMet(List); // Dit kan een DoeIetsError gooien
except
on E: DoeIetsError do
CloseFile(F);
List.Free;
raise EenAndereException.Create("Kan niets doen met foo.txt.");
end;
on E: Exception do
CloseFile(F);
List.Free;
raise EenAndereException.Create("Onbekende fout: " + E.Message);
end;
end;
Close(F);
List.Free; |
Zie je het probleem ook? "CloseFile(F);List.Free;" komt maar liefst 3 keer voor, dikke redundancy. (Ja, dit zou je ook op een andere manier kunnen oplossen maar het is maar 1 voorbeeld.) Met garbage collection zal dat automatisch voor je gedaan worden.
Bovendien wordt handmatig vrijmaken lastiger wanneer je te maken hebt met een shared resource die wordt gebruikt door meerdere threads. Dan moet je je eigen reference count code schrijven. Het zou toch handig zijn als je dat niet hoeft?
Je denkt dat het gedoemd is om te mislukken omdat je denkt dat ze XML opnieuw uitvinden. Dat is een zeer veelgemaakte vooroordeel, en is niet het geval. YAML is geen "human readable XML". YAML is een object serialization taal, geen markup taal. YAML is een keukenmes en XML is een zwitserse legermes. YAML is een vliegenmepper en XML is een atoombom. Je kan een vlieg doden met een atoombom, een atoombom is immers een alleskiller, net als XML een soort 'alles-markup' is. Maar ja, misschien is het handiger om een vliegenmepper te gebruiken als je alleen maar een vlieg wilt doden.
"Gedoemd om te mislukken" is een groot woord. Definieer eerst "mislukken". Het wordt intensief gebruikt in Ruby on Rails.
Het voordeel is dat de boel korter is. Wat type je liever:
code:
1
2
3
4
| menu: - aardappel - kokosnoot - tomaat |
of:
code:
1
2
3
4
5
6
7
8
| <?xml version="1.0" encoding="utf8"?>
<root>
<menu>
<item>aardappel</item>
<item>kokosnoot</item>
<item>tomaat</item>
</menu>
</root> |
Ik heb mijn keuze snel gemaakt. XML bevat tonnen redundancy. Leuk voor complexe documenten of markup, maar overkill voor simpele object serialization.
Maar, zoals ik al zei: vliegenmepper vs atoombom. Ze zijn allebei ontworpen voor andere dingen, klaar.
Behalve het feit dat ik wat beters te doen heb.
[ Voor 48% gewijzigd door FooBarWidget op 19-08-2006 23:03 ]
"I had a problem, I solved it with regular expressions. Now I have two problems". That's shows a lack of appreciation for regular expressions: "I know have _star_ problems" --Kevlin Henney
Pagina: 1
Dit topic is gesloten.