[ALG] Visual en niet-visual

[Verwijderd]

Volgens mij is het een hele simpele n00b vraag van mij, maar ik stel hem toch even:
zelf heb ik alleen nog maar in delphi geprogrammeerd, dit is dus met een ontwikkelomgeving waarbij je alle knopjes, invoerveldjes en dingetjes naar het "scherm"/form van je programma sleept en daarmee een interface creeert. Visueel dus, wat ik me nou afvraag: wat moet ik me voorstellen bij programmeren zonder dat je van je form uit kunt gaan? Dus text-based programmeren, hoe maak je dan een interface??

Ik stel trouwens deze vraag, omdat ik geintereseerd ben om in C(++) of Java te gaan programmeren. Ik weet ook dat er visuele ontwikkelomgevingen zijn voor in elk geval C++ maar ik heb gelezen dat je het beste NIET visueel kunt beginnen met C++ dus wat moet ik me daar bij voorstellen?? Wat zijn grote verschillen als je kwa programmeren alleen delphi kent??

[whoami]

Verwijderd schreef op 28 september 2004 @ 11:22:
Volgens mij is het een hele simpele n00b vraag van mij, maar ik stel hem toch even:
zelf heb ik alleen nog maar in delphi geprogrammeerd, dit is dus met een ontwikkelomgeving waarbij je alle knopjes, invoerveldjes en dingetjes naar het "scherm"/form van je programma sleept en daarmee een interface creeert. Visueel dus, wat ik me nou afvraag: wat moet ik me voorstellen bij programmeren zonder dat je van je form uit kunt gaan? Dus text-based programmeren, hoe maak je dan een interface??

De Delphi IDE (en ook de IDE in VS.NET, etc...) zijn idd makkelijk om je user interface in elkaar te klikken. Echter, als jij in die IDE een button ofzo op je form sleept, dan zal je IDE daar code voor gaan genereren.
De IDE zal een variable maken die die button representeert (een instance van TButton bv) en de positie etc... gaan zetten.

Als je geen IDE hebt die dit voor je doet, moet je dus zelf die objecten gaan instantieren, en de properties gaan zetten. Dat is niet zo moeilijk, maar gewoon wat meer werk en er kruipt wat meer tijd in.

maar ik heb gelezen dat je het beste NIET visueel kunt beginnen met C++ dus wat moet ik me daar bij voorstellen??

Daar ben ik het mee eens. Het is beter dat je eerst leert programmeren zonder dat je je met de UI gaat gaan bezighouden. Het is beter dat je leert wat een class is, wat polymorphisme is, wat een functie is, etc....
Een 'gevaar' van dergelijke IDE's is dat je eigenlijk je programma niet goed opzet. Het is natuurlijk makkelijk om je UI in elkaar te klikken en dan mbhv hier en daar wat code de stukken aan elkaar te lijmen. Echter, op die manier heb je niet echt een aanpasbaar/goed geschreven programma.

Wat zijn grote verschillen als je kwa programmeren alleen delphi kent??

Dat hangt ervan af wat jij verstaat onder Delphi kennen.
Als jij enkel in Delphi kunt programmeren door gewoon wat componenten op je form te slepen, wat properties te zetten, en deze componenten met elkaar kunt laten samenwerken, wil dat IMHO daarom niet zeggen dat je kunt programmeren.
Ik programmeer ook soms in Delphi, maar ik gebruik Delphi niet op de 'VB manier'.

[Verwijderd]

Dat hangt ervan af wat jij verstaat onder Delphi kennen.
Als jij enkel in Delphi kunt programmeren door gewoon wat componenten op je form te slepen, wat properties te zetten, en deze componenten met elkaar kunt laten samenwerken, wil dat IMHO daarom niet zeggen dat je kunt programmeren.
Ik programmeer ook soms in Delphi, maar ik gebruik Delphi niet op de 'VB manier'.

Ik weet niet of ik daar zoveel zinnigs over kan zeggen. Opzich voor mijn gevoel wel meer gedaan als wat jij omschrijft, maarjah

Misschien helpt het als ik een voorbeeld noem van wat ik geprogrammeerd heb?? (en misschien zegt het alsnog wel helemaal niks maargoed )
Heb laatst (voor school) een programma geschreven wat via het I2C protocol mbv library een meetkaart (zelf gemaakt) aanspreekt, dmv pollen met een timer. Deze meetkaart stuurt dan een bepaalde frequentie door een (band)filter, meet de ingangsamplitude en uitgangsamplitude van de sinus die door het filter gestuurd word en stuurt het weer terug naar de pc. De meetwaarden moesten dan geplot worden in een grafiekje en overgestuurd kunnen worden via tcp/ip (component "indy" voor gebruikt) naar een andere pc die het programmatje draaid.

Naja, ik denk dan dat ik aan het programmeren ben maar ik merk tegelijk ook dat het niet echt diep gaat --> in delphi kun je dit soort dingetjes maken zonder te snappen wat een class is (want dat weet ik dus niet zo goed )... Weet wel de basic dingen als loops en heb ook wat assembly en microcode kennis if it helps

[farlane]

Het grootste probleem van zo een visuele IDE is dat het visueel is.

Zo vraag ik me af, waarom een timer of een socket op een formulier moet staan ? Je ziet ze niet, dus die representatie is gewoon verkeerd. In VB ( ken Delphi niet goed ) krijg je dus ook code onder je formulier die te maken heeft met die timer, of die socket. Die code hoort daar gewoon niet ! Op die manier werkt visueel software ontwikkelen dus een verkeerd design in de hand. ( Alle code in je UI klasse bijvoorbeeld )

Echter, als ik een UI in elkaar moet zetten, zit ik echt niet te wachten om wederom in een resource file, of nog erger in code, alles te ontwerpen. Daar zijn die visuele omgevingen weer een uitkomst.

Uiteindelijk zal het maken van een degelijke applicatie niet makkelijker of moeilijker zijn in een visuele omgeving, met uitzondering van de UI.

[Verwijderd]

ik begrijp je post bijna helemaal, behalve "UI" wat bedoel je daarmee?

[Johnny]

Verwijderd schreef op 28 september 2004 @ 13:06:
ik begrijp je post bijna helemaal, behalve "UI" wat bedoel je daarmee?

User Interface

GUI is een Graphical User Interface

[Mir]

UI = User Interface.. het grafische gedeelte... de knoppen etc.

[Verwijderd]

Je noemt daar ook dat bijvoorbeeld die timers en knoppen bij visueel programmeren een voordeel zijn omdat je er niet op zit te wachten ze zelf te programmeren,
maar heb je dan bij niet-visueel programmeren ook geen kant-en-klare bijvoorbeeld knop en timer classes (of wat het dan ook zijn )??

[.oisyn]

farlane schreef op 28 september 2004 @ 12:31:
Zo vraag ik me af, waarom een timer of een socket op een formulier moet staan ? Je ziet ze niet, dus die representatie is gewoon verkeerd. In VB ( ken Delphi niet goed ) krijg je dus ook code onder je formulier die te maken heeft met die timer, of die socket. Die code hoort daar gewoon niet !

Hier zit dan wel weer een implementatiedetail achter, namelijk dat het voor zowel sockets als timers mogelijk is om messages te sturen naar een window. Logischerwijs plaats je het component dan ook op de window waar je de messages heen wilt hebben. VB vangt dat af en roept vervolgens weer de desbetreffende functies in je form aan

[Creepy]

.oisyn schreef op 28 september 2004 @ 13:25:
[...]


Hier zit dan wel weer een implementatiedetail achter, namelijk dat het voor zowel sockets als timers mogelijk is om messages te sturen naar een window. Logischerwijs plaats je het component dan ook op de window waar je de messages heen wilt hebben. VB vangt dat af en roept vervolgens weer de desbetreffende functies in je form aan

Datzelfde geld dus ook voor Delphi.

En je kan natuurlijk ook de timer of socket in code aanmaken zodat je ze niet op een form hoeft te plaatsen. Je moet ze dan ook zelf weer vrijgeven, iets wat anders al voor je geregeld wordt.

[ Voor 8% gewijzigd door Creepy op 28-09-2004 13:31 ]

[whoami]

Verwijderd schreef op 28 september 2004 @ 13:15:
Je noemt daar ook dat bijvoorbeeld die timers en knoppen bij visueel programmeren een voordeel zijn omdat je er niet op zit te wachten ze zelf te programmeren,
maar heb je dan bij niet-visueel programmeren ook geen kant-en-klare bijvoorbeeld knop en timer classes (of wat het dan ook zijn )??

Dat zegt farlane niet.
Het is natuurlijk handig dat je die niet zelf moet implementeren, maar farlane geeft aan dat die componenten eigenlijk niet op form-niveau thuishoren. Ze zijn geen onderdeel van je UI.
Het is echter ook niet omdat je niet iets op je form kan slepen, dat je die component zelf hoeft te gaan ontwikkelen/implementeren.

[Verwijderd]

Er zijn ook visual versies van Java en C++, bv van Symantec en Borland. Vaak wordt aan g++ of java scripting met vi gerefereerd, maar er zijn ook wel andere smaken van deze talen te koop.

Ik moet bekennen: van de Windows GUI weet ik alleen nog maar op papier hoe die werkt. Heel vroeger wel es een GUI met VC++ gemaakt: ik heb op het graf van m'n 286 gezworen dat nooit weer te doen. "Visual C++", hoe hebben ze die naam bedacht ???? GUI's bouwen in Delphi of C-Builder vind ik toch prettiger.

Wat paketten als Delphi in de hand werken is dat de huis-tuin-en-keuken-gebruiker het Object-Oriented-Programming niet meer in verband brengt met Class-Oriented-Modelling en de laatste geheel uit gezicht verdwijnt. Maar ook een visual ontwikkelomgeving staat nog steeds toe de GUI de modellen, en bij een beetje GUI in Delphi zou ik dat ook zeker doen.

[farlane]

.oisyn schreef op 28 september 2004 @ 13:25:
Hier zit dan wel weer een implementatiedetail achter, namelijk dat het voor zowel sockets als timers mogelijk is om messages te sturen naar een window.

Tuurlijk, ik snap ook wel dat men op die manier te werk gaat, maar naar mijn idee is dit de verkeerde manier. Je kunt dus geen timer of socket maken zonder een formulier te gebruiken, terwijl dat de onderliggende API's wel degelijk ondersteunen. Een formulier is imho een object dat in je UI laag zit, terwijl een socket bv daar absoluut niet thuishoort.

Bovendien wordt de reusability op die manier behoorlijk ondermijnd.

[Creepy]

farlane schreef op 28 september 2004 @ 16:37:
[...]


Tuurlijk, ik snap ook wel dat men op die manier te werk gaat, maar naar mijn idee is dit de verkeerde manier. Je kunt dus geen timer of socket maken zonder een formulier te gebruiken, terwijl dat de onderliggende API's wel degelijk ondersteunen.

Over welke API heb je het hier? Waarschijnlijk niet over bijv. de VCL zoals die bij Delphi zit want ook daar kan je kan je dezelfde classes gebruiken zonder ze op een form te zetten.

Een formulier is imho een object dat in je UI laag zit, terwijl een socket bv daar absoluut niet thuishoort.

Bovendien wordt de reusability op die manier behoorlijk ondermijnd.

Reusability ondermijnd? De Timer of Socket classes kan je ook prima gebruiken zonder ze op een form te zetten. Reusability blijft zo 100% intact.

[ Voor 10% gewijzigd door Creepy op 28-09-2004 16:48 ]

[farlane]

Creepy schreef op 28 september 2004 @ 16:47:
Over welke API heb je het hier? Waarschijnlijk niet over bijv. de VCL zoals die bij Delphi zit want ook daar kan je kan je dezelfde classes gebruiken zonder ze op een form te zetten.

Met onderliggende API's bedoelde ik hier de Win32 SetTimer en WinSock API's.

Reusability ondermijnd? De Timer of Socket classes kan je ook prima gebruiken zonder ze op een form te zetten. Reusability blijft zo 100% intact.

Ik heb het idd over VB ( misschien scheer ik de VIDE's wel te veel over een kam, want met Delphi heb ik weinig ervaring. )

[Creepy]

farlane schreef op 28 september 2004 @ 17:01:
[...]

Met onderliggende API's bedoelde ik hier de Win32 SetTimer en WinSock API's.


[...]


Ik heb het idd over VB ( misschien scheer ik de VIDE's wel te veel over een kam, want met Delphi heb ik weinig ervaring. )

Daar was ik al bang voor

Maar ook in VB is het toch wel mogelijk om een Socket class te gebruiken zonder ze op een Form te zetten?
Blijkt maar weer dat ik nauwelijks ervaring met VB heb
Net zoals whoami zegt kan je in Delphi op de "VB manier" ontwikkelen. Daarnaast kan je ook prima rechtstreeks de Windows API aanspreken of rechtstreeks de VCL gebruiken zonder "sleur en pleur" acties.

Om alle classes nou te beperken voor gebruik op een form lijkt mij ook niet nuttig nee.