beginnen

[anoniem]

Goed verhaal! Nog een kleine aanvulling: Borland Delphi 7 Studio heeft .NET integratie en is heel makkelijk om mee te beginnen (daar was het topic voor bedoeld). En hoezo is C/C++ alleen een echte taal? Wat dacht je van Pascal? Neppe taal? Pascal is tenminste overzichtelijk, in tegenstelling tot C++.

[anoniem]

Ik heb niet gezegd dat pascal een nep taal is. Deze discussie is eigenlijk moeilijk te voeren, omdat er verschillende factoren aan de orde komen. Het programmeren in bijvoorbeeld vb, asp etc maakt je afhankelijk van een heleboel factoren. Als je programmeur bent dan zul je van vb, asp (wat minder) wel de enorme problemen kennen met versies, dll conflicten, ocx problemen etc etc. Ja en ik weet dat het op te lossen is en dat er steeds wat aan gedaan wordt om het beter te maken, maar feit blijft dat met name vb nog altijd via een runtime werkt wat het vaak traag maakt. Alles in vb loopt door de vb runtime, zelfs A = B moet in de vbruntime worden opgeroepen als vbCompare. Kijk ik snap wel waarom veel bedrijven kiezen voor dit soort talen. Het kost namelijk veel minder tijd om een programma in vb te ontwikkelen dan in C/C++. Het is makkelijk te leren. Bedrijven kunnen in veel kortere tijd meer programma's maken en daar draait het veelal om. Het is mijn persoonlijke mening dat je pas echt leert programmeren wanneer je met C/C++ en pascal (wat meer in de richting van het programmeren) leert werken. In deze talen leer je namelijk hoe je efficient programma's maakt die tevens qua performance goed lopen. Je leert hoe de computer de variabelen opslaat en hoe deze weer vrij gemaakt worden. In talen als vb is dit niet van toepassing. Dit wordt allemaal voor je geregeld en heb je daar geen invloed op. Helaas loop je dan al snel tegen beperkingen op qua performance etc. Het is dus meer mijn eigen mening over het echte programmeren dan het in werkelijkheid gaat lopen. Kijk .NET (c)(tm) heeft natuurlijk zo'n enorme marketing machine lopen dat het overgrote deel toch gaat besluiten om deze techniek te gebruiken. Helaas dat maar een klein gedeelte werkelijk weet wat het allemaal inhoud en het overgrote deel met de massa mee gaat. [b:6734c72ef3]Tazzie[/b:6734c72ef3] De verbindingen richting internet/webservices speelt c/c++ wel degelijk mee. Loop een gemiddelde provider binnen en je zult zien dat het overgrote deel op *nix draait. Vele services worden daar op c voor geschreven. Voor mij is java nog steeds een uitstervende soort, maar ik denk dat het er maar aan ligt in welk markt segment je werkzaam bent. Veel bedrijven huren mensen in die in zo'n kort mogelijke tijd een website moeten maken. Hiervoor is met name .NET uitermate geschikt mits op redelijk kleine schaal of een vermogen uitgeven voor hardware. MS gokt nu op .NET. Ze zullen wel moeten want ze hebben al hun kansen daar op ingezet. Ze hebben recentelijk nog geprobeerd om hun software huur strategie aan de man te brengen maar de hele project is mislukt. Nu gaat de marketing machine dus op gang komen en ik ben benieuwd of het hen gaat lukken. (PS: ik ben niet tegen microsoft. Ik heb ook geprogrammeerd met VB, ASP, maar ik liep snel tegen performance problemen aan welke ik perfect op kon lossen met assembly in combinatie met c/c++)

[anoniem]

Wat je bedoelt met dat alles in VB is voorgeprogrammeerd is met alle ontwikkelomgevingen zo. Ook met Visual C++, Delphi/Kylix, JBuilder, C++Builder... Het echte programmeren is met een commandline compiler zoals Turbo Pascal of Turbo C++ iets compilen wat je bij wijze van spreken in Kladblok hebt gemaakt. Tegenwoordig ligt alles anders, heel veel is voorgeprogrammeerd en ik vind daar het echte programmeren niet minder van worden. Stel je voor dat je je eigen knoppen moest gaan maken!

[anoniem]

[quote:20015cd4a2]iets compilen wat je bij wijze van spreken in Kladblok hebt gemaakt. [/quote:20015cd4a2] Of Cobol. Toen de 4de generatie talen kwamen dacht ik nog; ja hallo, dit kan mijn grootmoeder ook. Viel achteraf wel mee natuurlijk, maar het echte programmeren was er wel een beetje af.

[anoniem]

Wat versta je dan onder écht programmeren dan?

[anoniem]

[quote:ad41ae1c8d]Wat versta je dan onder écht programmeren dan?[/quote:ad41ae1c8d] Wat jij ook stelt: pak kladblok....

[anoniem]

Haha :D Maar helaas kom je daar tegenwoordig niet ver mee... Ontwikkelomgevingen zijn echt nodig, de knoppen e.d. zijn gewoon handig om te gebruiken, stel je voor dat je die zelf moet maken! Het lijkt mij leuk om zelf iets te maken waardoor computers met elkaar kunnen communiceren, helemaal zelf dan... dit is alleen steeds moeilijker geworden in de loop der jaren.

[anoniem]

[quote:43dca894a9]Het lijkt mij leuk om zelf iets te maken waardoor computers met elkaar kunnen communiceren, helemaal zelf dan... dit is alleen steeds moeilijker geworden in de loop der jaren.[/quote:43dca894a9] Hoe bedoel je precies? Mij dunkt dat het juist eenvoudiger geworden is.

[anoniem]

Het is inderdaad veel makkelijker geworden. Het is nu nog wachten op het wereldrecord programmeren (klik klik klik klik tik klik klik klaar) [quote:c98d013e8d]Haha Maar helaas kom je daar tegenwoordig niet ver mee... Ontwikkelomgevingen zijn echt nodig, de knoppen e.d. zijn gewoon handig om te gebruiken, stel je voor dat je die zelf moet maken! [/quote:c98d013e8d] In assembly gebruik ik daar modules voor en het is echt niet moeilijk om ze te maken hoor. Verder is het een makkie om een dialog editor te gebruiken en daarbij gebruik te maken van een taal als C/C++ of assembly. Maaja zo heeft ieder zijn eigen manier van werken en ik zal niet ontkennen dat het maken van een compleet pakket in een klik-en-run taal een stuk makkelijk is dan bovenstaande talen. Maarja als performance belangrijk is voor software dan moet je toch iets he ;)

[anoniem]

[quote:5f3468db91]Maarja als performance belangrijk is voor software dan moet je toch iets he[/quote:5f3468db91] Ja, daar had je het al eerder over en het blijft me verbazen. Noem eens een praktijkvoorbeeld waarbij jij tegen een gebrek aan performance aanliep?!

[anoniem]

Enkele voorbeelden waar ik tegen deze problemen aanliep: Het vullen van een listview met gegevens welke om de halve seconde vernieuwd werden. De software moest reageren op selectie's welke gemaakt werden en op deze geselecteerde gegevens moesten een aantal berekeningen losgelaten worden. In vb gaf dit enorme problemen omdat het vernieuwen van de listview na een tijd zo traag werd dat er bijna niet meer mee te werken viel. De berekeningen werden vervolgens in een real-time grafiek weergegeven en hierop kon gereageerd worden. Ook het aanvullen van deze grafiek zorgde voor de nodige haperingen. Ook in andere programma's liep ik tegen de snelheid/performance problemen van verschillende controls aan. Het vullen van listviews en comboboxen verliep enorm traag wanneer er op de achtergrond ook diverse berekeningen werden uitgevoerd.

[anoniem]

[quote:c49b0dfe21="[DarthV]"]Enkele voorbeelden waar ik tegen deze problemen aanliep: Het vullen van een listview met gegevens welke om de halve seconde vernieuwd werden. De software moest reageren op selectie's welke gemaakt werden en op deze geselecteerde gegevens moesten een aantal berekeningen losgelaten worden. In vb gaf dit enorme problemen omdat het vernieuwen van de listview na een tijd zo traag werd dat er bijna niet meer mee te werken viel. De berekeningen werden vervolgens in een real-time grafiek weergegeven en hierop kon gereageerd worden. Ook het aanvullen van deze grafiek zorgde voor de nodige haperingen. Ook in andere programma's liep ik tegen de snelheid/performance problemen van verschillende controls aan. Het vullen van listviews en comboboxen verliep enorm traag wanneer er op de achtergrond ook diverse berekeningen werden uitgevoerd.[/quote:c49b0dfe21] Valt imho geen spelt tussen te krijgen. Dat soort dingen verloopt inderdaad tergend traag. Zeker als je de standaard meegeleverde componenten gebruikt. Het genereren van rapporten is ook zoiets waar je niet echt blij van wordt. Al is dat niet alleen bij vb vaak een heikel punt. Voor 'in huis' applicaties in kantooromgeving is vb echter een geweldige ontwikkelomgeving. Klik, klak, klaar is natuurlijk niet waar (hé, dat rijmt) maar je hebt in relatief korte tijd precies dat wat men wil. Software ontwikkelen is duur, dus de opdrachtgever is maar wat blij met dergelijke snelle oplossingen. De installatieproblemen met dll's (dll-hell) is een behoorlijk probleem. Maar ook dit is in een strak beheerde kantooromgeving zeer beheersbaar. Tot het onvermijdelijke moment natuurlijk, dat men in een onbewaakt ogenblik een vb-applicatie van een externe leverancier aanschaft....

[anoniem]

Kijk, ik zal niet ontkennen dat C/C++ op het gebied van performance sneller is. Aber, gebruik iets waar het voor dient. Een heel programma in c/c++ schrijven, omdat enkele berekeningen dan sneller gaan is onzin. Schrijf de functies die de berekeningen maken in c/c++ en de interface in een andere taal. Hou de berekening component stand-by en klaar. Over het algemeen is performance, zeker bij desktop apps, geen issue meer. De machines zijn sneller, hebben meer geheugen etc en de performance winst die je in dat geval zou halen door iets in c/c++ te schrijven is minimaal. Of iets nu 10 ms of 100 ms duurt, daar zal de gebruiker weinig van merken. Een en ander is gewoon een kwestie tussen tijd en geld en het feit dat hele stukken in visuele omgevingen als VB, Delphi, Visual C++, JBoilder, etc al beschikbaar zijn is gewoon het gevolg van het OO principe. Het heeft geen zin om het wiel 40 keer opnieuw uit te vinden en zeker niet om dat iedere keer weer opnieuw in te kloppen. Sorry, maar daar zijn wij lichtelijk te duur voor. Dat wil echter niet zeggen dat het programmeren minder is geworden.... Geld is Tijd en Tijd is Geld. Zeg tegen een klant, we maken een programma voor je dat performed als een beest, kost +- 4 maanden om te ontwikkelen, 1 maand om te testen en kost +- 1.000.000, - of een programma dat iets minder performed (maar nog steeds ruim binnen de grenzen), kost +- 2 maanden om te ontwikkelen, 1 week om te testen en kost +- 300.000, wat denk je dat de klant kiest? Daarom zeg ik, in de automatisering en proces techniek wordt dit nog veel gebruikt, omdat daar realtime en proceskritische apps draaien, maar daarbuiten? You tell me... Greetz, Taz

[anoniem]

[quote:90857b37bc="[DarthV]"]Enkele voorbeelden waar ik tegen deze problemen aanliep: Het vullen van een listview met gegevens welke om de halve seconde vernieuwd werden. De software moest reageren op selectie's welke gemaakt werden en op deze geselecteerde gegevens moesten een aantal berekeningen losgelaten worden. In vb gaf dit enorme problemen omdat het vernieuwen van de listview na een tijd zo traag werd dat er bijna niet meer mee te werken viel. De berekeningen werden vervolgens in een real-time grafiek weergegeven en hierop kon gereageerd worden. Ook het aanvullen van deze grafiek zorgde voor de nodige haperingen. Ook in andere programma's liep ik tegen de snelheid/performance problemen van verschillende controls aan. Het vullen van listviews en comboboxen verliep enorm traag wanneer er op de achtergrond ook diverse berekeningen werden uitgevoerd.[/quote:90857b37bc] Klint als een process-systeem.... Overigens, maakte je hier gebruik van non-disconnected recordsets en dynamic-cursors? Die vertragen de boel aanzienlijk...

[anoniem]

[quote:cfa66a76a2="Tazzie"]Een heel programma in c/c++ schrijven, omdat enkele berekeningen dan sneller gaan is onzin. Schrijf de functies die de berekeningen maken in c/c++ en de interface in een andere taal. Hou de berekening component stand-by en klaar. [/quote:cfa66a76a2] Dat is toch een heel gedoe, twee of meer talen doorelkaar?? Het nadeel van VB is dat deze op een runtime loopt (al eerder gezegd), Delphi programma's niet. Helaas zijn Delphi programma's zonder wat dan ook, alleen een kaal Form, al rond de 300 KB. Delphi stopt namelijk de hele VCL erin. [quote:cfa66a76a2="Tazzie"]Over het algemeen is performance, zeker bij desktop apps, geen issue meer. De machines zijn sneller, hebben meer geheugen etc en de performance winst die je in dat geval zou halen door iets in c/c++ te schrijven is minimaal. Of iets nu 10 ms of 100 ms duurt, daar zal de gebruiker weinig van merken. [/quote:cfa66a76a2] Houd wel rekening met het feit dat Windows ook zwaarder wordt... [quote:cfa66a76a2="Tazzie"]Geld is Tijd en Tijd is Geld. Zeg tegen een klant, we maken een programma voor je dat performed als een beest, kost +- 4 maanden om te ontwikkelen, 1 maand om te testen en kost +- 1.000.000, - of een programma dat iets minder performed (maar nog steeds ruim binnen de grenzen), kost +- 2 maanden om te ontwikkelen, 1 week om te testen en kost +- 300.000, wat denk je dat de klant kiest?[/quote:cfa66a76a2] Ik ga dan voor die van een miljoen :) . Delphi 7 Studio Architect kost $ 3499, Microsoft Visual Basic .NET kost lange niet zoveel... Ik ga niet af op de prijs, ik ga af op het product. Delphi is "performed als een beest" (als je bedoelt dat het dan goed werkt?)

[anoniem]

[quote:d6aa2b649f="Johan Stokking"][quote:d6aa2b649f="Tazzie"]Een heel programma in c/c++ schrijven, omdat enkele berekeningen dan sneller gaan is onzin. Schrijf de functies die de berekeningen maken in c/c++ en de interface in een andere taal. Hou de berekening component stand-by en klaar. [/quote:d6aa2b649f] Dat is toch een heel gedoe, twee of meer talen doorelkaar?? Het nadeel van VB is dat deze op een runtime loopt (al eerder gezegd), Delphi programma's niet. Helaas zijn Delphi programma's zonder wat dan ook, alleen een kaal Form, al rond de 300 KB. Delphi stopt namelijk de hele VCL erin. [/quote:d6aa2b649f] Waarom? Let wel, ik spreek hier wel over ontwikkelteams, niet een een-mans operatie. Voor het overige is het helemaal geen gedoe. [quote:d6aa2b649f="Johan Stokking"][quote:d6aa2b649f="Tazzie"]Over het algemeen is performance, zeker bij desktop apps, geen issue meer. De machines zijn sneller, hebben meer geheugen etc en de performance winst die je in dat geval zou halen door iets in c/c++ te schrijven is minimaal. Of iets nu 10 ms of 100 ms duurt, daar zal de gebruiker weinig van merken. [/quote:d6aa2b649f] Houd wel rekening met het feit dat Windows ook zwaarder wordt... [/quote:d6aa2b649f] Die in zijn eentje alle extra kracht van de processor en geheugen opslokt...? Dat valt ook wel weer mee. [quote:d6aa2b649f="Johan Stokking"][quote:d6aa2b649f="Tazzie"]Geld is Tijd en Tijd is Geld. Zeg tegen een klant, we maken een programma voor je dat performed als een beest, kost +- 4 maanden om te ontwikkelen, 1 maand om te testen en kost +- 1.000.000, - of een programma dat iets minder performed (maar nog steeds ruim binnen de grenzen), kost +- 2 maanden om te ontwikkelen, 1 week om te testen en kost +- 300.000, wat denk je dat de klant kiest?[/quote:d6aa2b649f] Ik ga dan voor die van een miljoen :) . Delphi 7 Studio Architect kost $ 3499, Microsoft Visual Basic .NET kost lange niet zoveel... Ik ga niet af op de prijs, ik ga af op het product. Delphi is "performed als een beest" (als je bedoelt dat het dan goed werkt?)[/quote:d6aa2b649f] Ik bedoel zeker niet dat het dan goed werkt. Ik bedoel dat het de resultaten levert in de tijd die je als ontwikkelaar bereid bent te wachten op gegevens. En de licentiekosten maken mij helemaal niet uit. Die worden toch betaald. Dus de keuze zou vallen op dat product, waarvan ik vind dat het lekker werkt, of dat de klant voorschrijft te gebruiken... Oh, en de klant kiest voor de oplossing van 300.000 btw, tenzij je NS heet. Die gooien net zo makkelijk 150 miljoen in de prullenbak wegen politiek geneuzel... ;) Greetz, Taz

[anoniem]

[quote:60d4e7c7c6="Tazzie"] Overigens, maakte je hier gebruik van non-disconnected recordsets en dynamic-cursors? Die vertragen de boel aanzienlijk...[/quote:60d4e7c7c6] Real-time, doe es een gok. Zou hij dan connected of disconnected gebruiken? (Ik neem aan dat je met non-disconnected connected bedoelt).

[anoniem]

[quote:886d86f379="Johan Stokking"] Dat is toch een heel gedoe, twee of meer talen doorelkaar?? Het nadeel van VB is dat deze op een runtime loopt (al eerder gezegd), Delphi programma's niet. Helaas zijn Delphi programma's zonder wat dan ook, alleen een kaal Form, al rond de 300 KB. Delphi stopt namelijk de hele VCL erin. [/quote:886d86f379] Hoezo? Zo doe je dat gewoon. Je gebruikt het juiste gereedschap voor de juiste toepassing. Front-endje in VB. Rekendoos erachter in C of C++. Interfacen via platte-ascii of XML om front-end onafhankelijk te maken van het platform waarop die rekendoos draait.

[anoniem]

[quote:c3b3609fa9]Dat is toch een heel gedoe, twee of meer talen doorelkaar?? Het nadeel van VB is dat deze op een runtime loopt (al eerder gezegd), Delphi programma's niet. Helaas zijn Delphi programma's zonder wat dan ook, alleen een kaal Form, al rond de 300 KB. Delphi stopt namelijk de hele VCL erin. [/quote:c3b3609fa9] Met name het probleem dat de executables van delphi vrij groot waren ben ik me op dat moment gaan richten op c/assembly. Na verloop van tijd bouw je een goede library op waardoor de ontwikkel periode steeds sneller gaat verlopen. De vraag over de recordsets had op dat specifieke programma geen toepassing omdat output in een eigen formaat werd weggeschreven. Als ik binnenkort wat meer tijd heb kan ik misschien eens wat snelheids testjes maken in de verschillende talen zodat dit probleem wat tastbaarder is voor sommigen.

[anoniem]

[quote:e8204167e9="Johan Stokking"][quote:e8204167e9="Tazzie"]Een heel programma in c/c++ schrijven, omdat enkele berekeningen dan sneller gaan is onzin. Schrijf de functies die de berekeningen maken in c/c++ en de interface in een andere taal. Hou de berekening component stand-by en klaar. [/quote:e8204167e9] Dat is toch een heel gedoe, twee of meer talen doorelkaar?? Het nadeel van VB is dat deze op een runtime loopt (al eerder gezegd), Delphi programma's niet. Helaas zijn Delphi programma's zonder wat dan ook, alleen een kaal Form, al rond de 300 KB. Delphi stopt namelijk de hele VCL erin. [/quote:e8204167e9] 1. Meerdere talen hoeven geen probleem op te leveren. Bijvoorbeeld taken die het beste in een andere taal geschreven kunnen worden zouden bijvoorbeeld in een .DLL geplaatst worden om maar een voorbeeld te noemen. 2. Je hoeft in Delphi/Pascal geen gebruik te maken van de VCL! Dan krijg je gewoon applicaties van 20 kB ofzo, maar dat heeft weer als nadeel dat je alles zelf m.b.v. de Windows API's moet gaan programmeren. Het is juist de bedoeling van de VCL, om dit transparant te houden het werk gemakkelijker te maken. 3. Je kunt in Delphi zelf kiezen of je alles in de executable wilt stoppen of dat je gebruik wilt maken van de [i:e8204167e9]runtime packages[/i:e8204167e9]. Project -> Options -> Packages -> Build with runtime packages [quote:e8204167e9="Tazzie"]Over het algemeen is performance, zeker bij desktop apps, geen issue meer. De machines zijn sneller, hebben meer geheugen etc en de performance winst die je in dat geval zou halen door iets in c/c++ te schrijven is minimaal. Of iets nu 10 ms of 100 ms duurt, daar zal de gebruiker weinig van merken. [/quote:e8204167e9] Wel als je die handelingen 100x wilt uitvoeren of zelfs meer, dan worden de marges toch wel iets groter. Bijvoorbeeld het opvragen van het resultaat van een SQL query kan in sommige omstandighden toch wel enig tijd duren. En dan is een factor 10 langzamer echt niet acceptabel. [quote:e8204167e9="Johan Stokking"] [quote:e8204167e9="Tazzie"]Geld is Tijd en Tijd is Geld. Zeg tegen een klant, we maken een programma voor je dat performed als een beest, kost +- 4 maanden om te ontwikkelen, 1 maand om te testen en kost +- 1.000.000, - of een programma dat iets minder performed (maar nog steeds ruim binnen de grenzen), kost +- 2 maanden om te ontwikkelen, 1 week om te testen en kost +- 300.000, wat denk je dat de klant kiest?[/quote:e8204167e9] Ik ga dan voor die van een miljoen :) . Delphi 7 Studio Architect kost $ 3499, Microsoft Visual Basic .NET kost lange niet zoveel... Ik ga niet af op de prijs, ik ga af op het product. Delphi is "performed als een beest" (als je bedoelt dat het dan goed werkt?)[/quote:e8204167e9] Ik denk dat de prijs toch wel een grote rol speelt. De klant zal het niet interesseren of de applicatie gemaakt is in Visual Basic .NET, Delphi of C(++). Zolang er maar (door de verkoopafdeling) gegarandeerd kan worden dan de applicatie doet wat er beloofd is/wordt met een behoorlijke performance.