Archief - [PROG]/ een gamekkelijke programmeer taal?
Het archief is een bevroren moment uit een vorige versie van dit forum, met andere regels en andere bazen. Deze posts weerspiegelen op geen enkele manier onze huidige ideeën, waarden of wereldbeelden en zijn op sommige plaatsen gecensureerd wegens ontoelaatbaar. Veel zijn in een andere tijdsgeest gemaakt, al dan niet ironisch - zoals in het ironische subforum Off-Topic - en zouden op dit moment niet meer gepost (mogen) worden. Toch bieden we dit archief nog graag aan als informatiedatabank en naslagwerk. Lees er hier meer over of start een gesprek met anderen.
Slicer
Legacy Member
The Crazy Frog zei:
De huidige compilers zijn een stuk beter in het vertalen naar machinecode dan als wij zelf asm zouden schrijven.
Trouwens, ASM instructies zijn opgebouwd via microcode (de instructies die in je processor zitten) en daarin kun je dus ook programmeren (hoewel ik het echt niet zou aanraden)
).
), een asm programma niet.killgore
Legacy Member
Programmeer kijk/stijl hangt NIET af van de taal. ASM geeft je een inkijk in de interne werking van een processor, niet meer inzicht in programmeren. Dit inzicht in processoren KAN zijn nut hebben natuurlijk voor bepaalde gevoelige applicaties van specifieke code en snelheidswinst te voorzien. Maar deze applicaties zijn maar een zeer beperkt aandeel van het marktaanbod.
Als je eens nieuw inzicht wilt: zoek eens op termen als extreme programming en zo
. Dit is een programmeer-concept dat ik zeer goed vind op bepaalde vlakken (bv. test-units schrijven VOOR uw eigenlijke code), tis nie makkelijk en lijkt van tijd absurd, ma eenmaal ge het beetje onder de knie hebt merkte wel da ge betere initiële code schrijft en dat het debuggen vlotter gaat.
Als je eens nieuw inzicht wilt: zoek eens op termen als extreme programming en zo
. Dit is een programmeer-concept dat ik zeer goed vind op bepaalde vlakken (bv. test-units schrijven VOOR uw eigenlijke code), tis nie makkelijk en lijkt van tijd absurd, ma eenmaal ge het beetje onder de knie hebt merkte wel da ge betere initiële code schrijft en dat het debuggen vlotter gaat.wlibaers
Legacy Member
The Crazy Frog zei:
Welnee, dat is machinetaal. Assembly vereenvoudigt het werk aanzienlijk:
1. Je kan namen gebruiken voor variabelen, labels, instructies en registers, in plaats van nummers te moeten onthouden.
2. Variabelen krijgen automatish een geheugenlokatie. In machinecode zou je, als er extra data/code toegevoegd wordt bij het begin, alle variabelen en labels (doelen van jumps) later in het programma moeten aanpassen. (dit is ook voor een deel te danken aan de linker)
Voor een voorbeeldje van hoe het zonder assembler en linker gaat:
http://webster.cs.ucr.edu/Page_TechDocs/pe.txt (zie onderaan voor het programma)
Ponskaarten zijn trouwens ook niet de meest "die-hard" manier van programmeren. Ze zijn ouder dan het gebruik van een hex-editor om je machinetaal programma's te schrijven. Maar al handiger dan je programma invoeren vie schakelaars op de computer (en daarmee bedoelik geen toetsenbord, maar het selecteren van een binair adres met schakelaars en dan met andere schakelaars een binair getal kiezen voor dat adres), of het gewoon manueel bedraden van delen van het geheugen.
Slicer zei:
Microcode is, in tegenstelling tot de machinetaal, vaak ook slecht gedocumenteerd omdat de chipmaker zelf gewoonlijk de enige is die het gebruikt.
Wat optimalisaties betreft: het is nog steeds mogelijk de compilers te verslaan, maar gewoonlijk overbodig, of het gaat in tegen andere doelstellingen (je zou stukken moeten herschrijven als je het op een ander type CPU moet gebruiken). De oude technieken (instructies tellen voor minimaal aantal klokcycli) zijn ook minder relevant geworden, en caches zijn nu zeer belangrijk (optimaliseren voor compacte code levert soms snellere code op dan pogingen om op de oude manier snelheid te winnen).
killgore
Legacy Member
en dan kunde komen op lampen verdraaien en dan op telramen en uiteindelijk op figuurkes tekenen int zand <_< (geen aanval op wlibaers btwwlibaers zei:
, gewoon aanvulling).compacte code niet noodzakelijk, eerder uw geheugen niet verspillen aan alles en nog wat.
Neem bv. een functie normalize, weer om vectoren te normaliseren (heb dit hier al eerder aangehaald). Dit wordt zeer vaak inline geforceerd, wat leidt tot "uitgebreidere", maar zeker geen tragere code.
Slicer
Legacy Member
wlibaers zei:
Natuurlijk, niemand behalve de maker van de processor gebruikt dit om de basisinstructies te maken, ik wou er enkel eens op wijzen dat je alsmaar dieper kunt gaan maar eigenlijk is dat niet nodig want het maakt het ontwikkelproces nodeloos ingewikkelt en maakt dat je veel meer kans heb op bugs.
Inderdaad we kunnen nog altijd compilers verslaan maar de tijd die daarvoor nodig is weegt niet op tegen de tijd die de compiler daarvoor nodig heeft. Zeker als je zoals je zelf zegt ook rekening moet gaan houden met de pipelining van de processor e.d.
azerty
Legacy Member
killgore zei:
dan komen we weeral terug op de discussie wat is een scripting taal en wat niet, want JSP en ASP.NET, zijn dan volgens uw definitie beiden scripttalen ???
Ik zou eerder durven zeggen dat JSP en ASP.NET (wat trouwens zeer sterk geïnspireerd is op JSP/J2EE) wat meer ge-evolueerd zijn van het scripting-taal gebeuren, met een betere ondersteuning voor MVC en distributed programming.
Maar uiteindelijk is JSP of ASP.NET allebei bijna hetzelfde, noem je dat scripting taal of progtaal, whatever...
<TABLE>
<TR>
<TD>Concepts</TD>
<TD>J2EE</TD>
<TD>.NET</TD>
</TR>
<TR>
<TD>Presentation</TD>
<TD>JSP/Servlets</TD>
<TD>ASP.NET</TD>
</TR>
<TR>
<TD>Business Logic</TD>
<TD> EJB/Servlets</TD>
<TD>Code Behind, Remoted Classes</TD>
</TR>
<TR>
<TD>Language</TD>
<TD> Java</TD>
<TD>C#, C++, VB.NET, etc</TD>
</TR>
</TABLE>
killgore
Legacy Member
kvraag mij af of al die jsv/asp aanhangers ooit al es op hoger niveau in php gewerkt hebben :ironic:. 'T is precies alsof gen enkel in asp/jsp deftig kunt ontwikkelen op hoger niveau <_<
Ma zover ik weet worden jsp en asp en php nog steeds onder scripttalen gerekend. En het blijft spijtig genoeg vrij simpel: niet-compileerde taal == scripttaal (java wordt wel degelijk gecompileerd, zij het naar bytecode en niet naar machinecode).
Ma ik had het dus enkel op talen als c++, java, c#, hoe je ze ook van elkaar onderscheidt in men vb.
Ma zover ik weet worden jsp en asp en php nog steeds onder scripttalen gerekend. En het blijft spijtig genoeg vrij simpel: niet-compileerde taal == scripttaal (java wordt wel degelijk gecompileerd, zij het naar bytecode en niet naar machinecode).
Ma ik had het dus enkel op talen als c++, java, c#, hoe je ze ook van elkaar onderscheidt in men vb
.Quilombo
Legacy Member
asm is tof 
iemand asm tuto die em aanraadt??
zoals killgore zei geeft da idd beter inzicht in hoe een processor werkt, wij zien asm samen bij computerarchitectuur en da wordt parallel gegeven zoda ge begrijpt wat voor wat dient etc.
cobol vin k ook wel neig
da zal wel aan mij ligge ...
iemand asm tuto die em aanraadt??
zoals killgore zei geeft da idd beter inzicht in hoe een processor werkt, wij zien asm samen bij computerarchitectuur en da wordt parallel gegeven zoda ge begrijpt wat voor wat dient etc.
cobol vin k ook wel neig
da zal wel aan mij ligge ...
Tyfius
Legacy Member
Cobol is zo simpel als da het groot is en totaal nutteloos, tenzij ge ergens op een dienst gaat werken waar ze nog met software van voor de oorlog werken (cfr. banken).
En zoals killgore reeds zei, je kan elke dag meer met talen als JSP, ASP.NET en PHP maar ze behoren nog niet tot het clubje van de echte programmeertalen.
Nu soms kan je die wel compilen (denk maar aan PHP, via bepaalde extensies kan je een GTK interface maken en compilen naar een uitvoerbaar bestand) maar strict gezien zijn het nog steeds scriptingtalen.
En zoals killgore reeds zei, je kan elke dag meer met talen als JSP, ASP.NET en PHP maar ze behoren nog niet tot het clubje van de echte programmeertalen.
Nu soms kan je die wel compilen (denk maar aan PHP, via bepaalde extensies kan je een GTK interface maken en compilen naar een uitvoerbaar bestand) maar strict gezien zijn het nog steeds scriptingtalen.
Het archief is een bevroren moment uit een vorige versie van dit forum, met andere regels en andere bazen. Deze posts weerspiegelen op geen enkele manier onze huidige ideeën, waarden of wereldbeelden en zijn op sommige plaatsen gecensureerd wegens ontoelaatbaar. Veel zijn in een andere tijdsgeest gemaakt, al dan niet ironisch - zoals in het ironische subforum Off-Topic - en zouden op dit moment niet meer gepost (mogen) worden. Toch bieden we dit archief nog graag aan als informatiedatabank en naslagwerk. Lees er hier meer over of start een gesprek met anderen.