[Alg] Voor- nadelen programmeertalen

donderdag 22 januari 2004 12:43

-= Tja =-

Om het nog lastiger te maken.. er zijn veel meer talen dan alleen wat jij daar noemt. Iedere programmeur hanteert een aantal talen, XML, SQL, HTML etc. En zo nu en dan kun je je ook vergrijpen aan volledig andere talen zoals bv Prolog, Clean, EBNF, Velocity. Alle talen hebben sterke en zwakke punten en meestal kies je dus voor een combinatie.

SQL = voor database toegang
HTML = voor opmaken tekst
XML = data opmaak
XSLT = data transformatie
Prolog = symbolische taal.. word veel binnen de ai gebruikt.
EBNF = voor het ontwerpen van parsers.

en zo kan je nog wel even doorgaan.

[ Voor 32% gewijzigd door Alarmnummer op 22-01-2004 13:30 ]

Acties:

TheRebell

Velocity een programmeertaal

(maar verder heb je gelijk

)
En what about .NET

[ Voor 14% gewijzigd door TheRebell op 22-01-2004 12:44 ]

donderdag 22 januari 2004 12:45

Acties:

donderdag 22 januari 2004 12:45

-= Tja =-

TheRebell schreef op 22 januari 2004 @ 12:43:
Velocity een programmeertaal

Ik vind de grens zo nu en dan nogal vaag worden

Volgens hun zelf is het een 'template' language.

En what about .NET

.NET is een platform en niet een taal. .NET heeft een soort tussenformaat (te vergelijken met java bytecode) waar verschillende talen (c++, delphi, haskell, eiffel, basic) naar toe kunnen compileren.

[ Voor 38% gewijzigd door Alarmnummer op 22-01-2004 12:47 ]

Acties:

Devilfish

denk dat je .net langzamerhand ook niet meer mag uitvlakken. Java wordt vooral gebruikt met applicaties die crossplatform moeten zijn.

Vergeet daarnaast niet de functionele talen!

donderdag 22 januari 2004 13:02

Acties:

Verwijderd

ben niet helemaal eens met je bewering over populairste talen... Maar ik zal mijn steentje ff bijdragen:

Visual Basic - Mee begonnnen... SImpele taal bij gebruik van Visual Basic studio.. Makkelijk interfaces en weinig code (heb een spel gemaakt om leerlingen te leren lezen als opdracht voor de middelbare school (havo informatica)

HTML/ASP - Leuk om procedurele zaken mee te programmeren in een webinterfacje... Jammer dat het duur is om te laten hosten (je moet een host vinden die met windows NT server pakketen host (PHP is dan wat toegankelijker)... Beste resulaten voor deze talen zij nte behalen met simpele editors met enkel een systax highlighting (dus geen sleur/pleur ala frontpage)

JAVA - mee begonnen op hio.. leuke platform onafhankelijke taal... Nadeel is de traagheid en het ontbreken van een compile voor native code. Voordeel is dat je met de goede SDK voor alle platformen kunte devellopen... Maar al je users/clients moeten de goede runtimes hebben anders werkt t niet dus daar gaat je portabiliteit... Pluspunt is ook: de garbage collector.. dus geen handmatig objecten destroyen. JBuilder is een goed programma voor java

C++ goede taal om native exes mee te maken.. lastig te leren en vrij onveilig vanwege pointers en het ontbreken van een garbage collector. Veel informatie over te vinden en goed om diverse windows interfaces mee te maken. Console apps zijn uit te wisselenen over alle systemen die C++ begrijpen (ook linux). Bij interfaces lastigen omdat linux andere librarys gebruikt. goed voor windows is bolrand C++ (vanwege gui design), adners is DEVC++ goed voor pure coding... KDevelop is een goede gui creator voor linux....

Delphi, simpele taal voor BIS studenten... Makkelijk interfaces maken en data oplaten halen zonder code. Zeer toegankelijke voor RAD, maar beroerd om goede code in te zetten. Object pascal (ligt onder delphi) is lastig te leren als je de andere talen kent vanwege afwijkende notaties.... Goed programma is Delphi7 van borland... Kylix zou het portable moeten maken voor linux, maar dat werkt ook niet altijd...

C# op stage mee begonnen.. Combineerd JAVA en C++. De coding conventions zijn iets anders, maar daar hoef je je niet aan te houden. Geen pointers (kan wel, maar specifiek aangeven) bezit ook een garbage colletor. Voordeel is ook dat je websites kan bouwen. Ondersteund via het .NET framework dll geschreven in iedere taal vanuit .NET (van C++.NET, J#). NAdeel is dat het is wennen om als je een webpage maakt je deze moet compilen. Verder is het rot dat om het te draaien de .net runtimes nodig zijn, maar deze worden ook geleverd bij windows update. Goed proggie is C# builder en Visual studio.NET (laatste is te duur, eerste is gratis te downloaden)... Geruchten gaan dat .NEt toch voor het linux platform gaat verschijnen...

Nou hopelijk heb je er wat aan....

donderdag 22 januari 2004 13:26

Acties:

xtra

Het verbaast me dat html zo eenvoudig in het rijtje programmeertalen wordt gezet. Ik zou het eerder een opmaaktaal noemen.

Ik kon zo snel geen "formele" definitie van "programmeertaal" vinden maar zaken als conditioneel het programmaverloop kunnen bepalen, werken met variabelen etc. lijkt me toch wel een voorwaarde.

Voor ASP(.Net) geldt ook dat het geen taal is maar een framework waarin je verschillende talen kunt gebruiken zoals standaard VBScript en JScript.

donderdag 22 januari 2004 13:26

Acties:

xx77qq

Delphi:
+ Hele goede IDE
- Mindere taal

C++:
+ Kan portable zijn
+ Kan snelle code opleveren.
+ Goede IDE's beschikbaar
- Je bent vaker met de taal zelf bezig dan met het probleem dat je wilt oplossen.
- Aantal standaard klassen niet echt groot in vergelijking met java
- bloated en onleesbare code (denk aan operator overloading)
- relatief lange compilatie/link tijden
- Kan trage code opleveren
- Overhyped

Java:
+ portable
+ grote hoeveelheid standaard klassen
- kan bloated source code leveren
- gevoelsmatig traag

Je zou eigenlijk nog een scripting taal moeten gebruiken. Ik ben erg gecharmeerd van python, een scripting taal met een ontzettende hoeveelheid basis klassen en ontzettend eenvoudig en handig in het gebruik. Mijn ervaring: Slechts 1/3 van de tijd t.o.v. C++ heb ik nodig om een probleem op te lossen en de code is minstens zoveel kleiner.

Python:
+ Programmeren wordt *echt* leuk met deze taal
+ portable
+ grote hoeveelheid standaard klassen
+ Erg duidelijk syntax
+ Eenvoudige koppeling naar b.v. C++ voor performance
- Is standaard niet geinstalleerd op office machines.

donderdag 22 januari 2004 13:29

Acties:

curry684

left part of the evil twins

Alarmnummer schreef op 22 januari 2004 @ 12:42:
Om het nog lastiger te maken.. er zijn veel meer talen dan alleen wat jij daar noemt.

'Hello World' in 204 verschillende talen

Professionele website nodig?

donderdag 22 januari 2004 13:31

Acties:

whoami

C++ goede taal om native exes mee te maken.. lastig te leren en vrij onveilig vanwege pointers en het ontbreken van een garbage collector. Veel informatie over te vinden en goed om diverse windows interfaces mee te maken. Console apps zijn uit te wisselenen over alle systemen die C++ begrijpen (ook linux). Bij interfaces lastigen omdat linux andere librarys gebruikt. goed voor windows is bolrand C++ (vanwege gui design), adners is DEVC++ goed voor pure coding... KDevelop is een goede gui creator voor linux....

Tja, dat ligt aan de programmeur. Je moet weten wat je doet.
Het ontbreken van een GC maakt een taal imo niet onveilig. Je moet gewoon weten wanneer je geheugen kunt vrijgeven.
Ook de mogelijkheid om met pointers te werken maakt een taal niet tot een onveilige taal. (In Pascal kan je ook met pointers werken trouwens).

Delphi, simpele taal voor BIS studenten... Makkelijk interfaces maken en data oplaten halen zonder code. Zeer toegankelijke voor RAD, maar beroerd om goede code in te zetten. Object pascal (ligt onder delphi) is lastig te leren als je de andere talen kent vanwege afwijkende notaties.... Goed programma is Delphi7 van borland... Kylix zou het portable moeten maken voor linux, maar dat werkt ook niet altijd...

Daar ben ik ook niet mee akkoord. Delphi is een krachtige OO taal, waar je heel krachtige applicaties mee kunt bouwen.
Omdat Delphi je een goeie RAD omgeving biedt, wil dat nog niet zeggen dat het een 'simpele sleur en pleur' taal is zoals VB.
Als je een goede applicatie wilt bouwen, zal je wel wat meer nodig hebben in Delphi dan enkel wat componenten bij elkaar sleuren en properties zetten.
Delphi is heel krachtig, en je kan er goeie app's mee maken, maar het is wel zo dat je ook 'slechte' apps kan maken met Delphi als je Delphi gebruikt als VB6.

C# op stage mee begonnen.. Combineerd JAVA en C++. De coding conventions zijn iets anders, maar daar hoef je je niet aan te houden. Geen pointers (kan wel, maar specifiek aangeven) bezit ook een garbage colletor. Voordeel is ook dat je websites kan bouwen. Ondersteund via het .NET framework dll geschreven in iedere taal vanuit .NET (van C++.NET, J#). NAdeel is dat het is wennen om als je een webpage maakt je deze moet compilen. Verder is het rot dat om het te draaien de .net runtimes nodig zijn, maar deze worden ook geleverd bij windows update. Goed proggie is C# builder en Visual studio.NET (laatste is te duur, eerste is gratis te downloaden)... Geruchten gaan dat .NEt toch voor het linux platform gaat verschijnen...

C# is meer dan Java en C++. C# kent bv. zo iets als Attributes; iets wat Java
en C++ niet kennen.
C# kan je (net als VB.NET) gebruiken om ASP.NET web-applicaties mee te maken.

Daarnaast kan je imho misschien beter een opsplitsing / verslag maken tussen / over functionele, procedurele, OO, declaratieve talen maken, ipv een aantal programmeertalen te nemen die eigenlijk voor het grootste deel enkel in syntax verschillen.

https://fgheysels.github.io/

Acties:

Janoz

Moderator Devschuur®

!litemod

TheRebell schreef op 22 januari 2004 @ 12:50:
Java:
enkele voordelen
* crossplatform
* leve OO !
* voor erg veel toepassingen geschikt
* mega veel documentatie
* ondersteuningen voor vanalles en nog wat

nadelen
* vaak traag op verschillende apparaten

Eigenlijk alleen met de GUI. Voor webapps is dit te verwaarlozen en als je toch een GUI gebruikt is er afaik bij IBM nog wel een leker snelle te vinden

* ide's zijn ook niet alles (al hoewel JBuilder 9/X wel aardig zijn )

Kijk eens naar Intellij's IDEA. Een dikke aanrader (* Janoz vindt hem prettiger dan VS

* soms zie je door de bomen het bos niet meer qua wat je allemaal kunt

Als je dat bij java een nadeel vindt, vindt je dat bijna overal. Misschien bij andere talen juist wel erger aangezien er in de java standaard zelf al een standaard documentatie methode is afgesproken waardoor alle documentatie op elkaar lijkt.

..ik vul hem verder nog wel eens aan

Ken Thompson's famous line from V6 UNIX is equaly applicable to this post:
'You are not expected to understand this'

Acties:

whoami

xtra schreef op 22 januari 2004 @ 13:26:
Voor ASP(.Net) geldt ook dat het geen taal is maar een framework waarin je verschillende talen kunt gebruiken zoals standaard VBScript en JScript.

In ASP (3.0) gebruik je VBScript of JScript, in ASP.NET gebruik je C# of VB.NET.

https://fgheysels.github.io/

Acties:

-= Tja =-

xtra schreef op 22 januari 2004 @ 13:26:
Het verbaast me dat html zo eenvoudig in het rijtje programmeertalen wordt gezet. Ik zou het eerder een opmaaktaal noemen.

Ik heb daarom het woord programmeertaal ook maar niet genoemt

Voor XML geldt namelijk hetzelfde.

donderdag 22 januari 2004 13:42

Acties:

Robtimus

me Robtimus no like you

xx77qq schreef op 22 januari 2004 @ 13:26:
Je zou eigenlijk nog een scripting taal moeten gebruiken. Ik ben erg gecharmeerd van python, een scripting taal met een ontzettende hoeveelheid basis klassen en ontzettend eenvoudig en handig in het gebruik. Mijn ervaring: Slechts 1/3 van de tijd t.o.v. C++ heb ik nodig om een probleem op te lossen en de code is minstens zoveel kleiner.

Python:
+ Programmeren wordt *echt* leuk met deze taal
+ portable
+ grote hoeveelheid standaard klassen
+ Erg duidelijk syntax
+ Eenvoudige koppeling naar b.v. C++ voor performance
- Is standaard niet geinstalleerd op office machines.

In mijn ogen is Python toch echt een programmeertaal. Tevens is er met Jython ook een koppeling met Java. Het is verder idd best leuk om mee te programmeren.

More than meets the eye
There is no I in TEAM... but there is ME
system specs

Acties:

xtra

whoami schreef op 22 januari 2004 @ 13:32:
[...]

In ASP (3.0) gebruik je VBScript of JScript, in ASP.NET gebruik je C# of VB.NET.

En voor de liefhebber Perl of Python. (In ieder geval in ASP.)

donderdag 22 januari 2004 13:45

Acties:

Soultaker

Begin eens met een representatieve verzameling van programmeertalen om te onderzoeken en een verzameling van relevante toepassingen. Als je zomaar "wat programmeertalen" gaat vergelijken, gaat je onderzoek (en dit topic) helemaal nergens over; je kunt de waarde van een programmeertaal alleen inschatten binnen de context van een bepaalde toepassing (en misschien ontwikkelingsvorm).

Als je voor- en nadelen zoekt van talen, kun je met Google ook een heel eind komen. Je vind dan wel vooral persoonlijke meningen en de betrouwbaarheid daarvan is natuurlijk wisselend (net zoals de meningen die in dit topic gespuid worden).

donderdag 22 januari 2004 13:50

Acties:

Soultaker

Alarmnummer schreef op 22 januari 2004 @ 12:45:
Ik vind de grens zo nu en dan nogal vaag worden

Wat mij betreft trekken we de grens tenminste bij de Turing-complete talen. Dan vallen XML, HTML en EBNF af, maar slimme template engines (misschien Velocity, al ken ik het niet) niet.

Hoe het zit met dingen als SQL of XSLT weet ik niet zo 1-2-3. Een enkele SQL query kan nooit een Turing-compleet programma opleveren, dus op zichzelf zou ik het geen taal willen noemen. XSLT ken ik niet goed genoeg om de inschatting te maken.

[ Voor 3% gewijzigd door Soultaker op 22-01-2004 13:51 ]

donderdag 22 januari 2004 13:57

Acties:

TheRebell

Janoz schreef op 22 januari 2004 @ 13:32:
[...]
Eigenlijk alleen met de GUI. Voor webapps is dit te verwaarlozen en als je toch een GUI gebruikt is er afaik bij IBM nog wel een leker snelle te vinden
[...]

Zeker. Voor webapp's heb je dit inderdaad niet

Kijk eens naar Intellij's IDEA. Een dikke aanrader (* Janoz vindt hem prettiger dan VS
[...]

ik zal zeker eens kijken

Als je dat bij java een nadeel vindt, vindt je dat bijna overal. Misschien bij andere talen juist wel erger aangezien er in de java standaard zelf al een standaard documentatie methode is afgesproken waardoor alle documentatie op elkaar lijkt.
[...]

Dit is netzoveel een voordeel als een nadeel. Het is echter niet een echt nadeel, juist geweldig dat er zoveel is. Maar je moet het wel even vinden. En dat is bij Java gelukkig erg goed gedocumenteerd

imho was het geen java-is-klote post ofzo hoor. Ben er zelf veel mee bezig en vindt java top

donderdag 22 januari 2004 14:00

Acties:

Verwijderd

curry684 schreef op 22 januari 2004 @ 13:29:
'Hello World' in 204 verschillende talen

Ook leuk: het "Towers of hanoi"-probleem in 108 verschillende talen.

[ Voor 7% gewijzigd door Verwijderd op 22-01-2004 14:01 ]

donderdag 22 januari 2004 14:00

Acties:

donderdag 22 januari 2004 14:21

Am-Ende!

Alarmnummer schreef op 22 januari 2004 @ 12:42:
Iedere programmeer hanteerd een aantal talen, XML, SQL, HTML etc.

Topic gaat over programmeertalen. XML en HTML zijn markup languages, SQL is een query taal.

on-topic

Ik behandel alleen de talen ik gebruik(-t heb) doh

Assembler
Pro's:
1) Retesnel (mits goed geprogd) +++++
2) Makkelijk om te gebruiken icm met meer high-level languages als bepaalde dingen even echt snel en geoptimaliseerd moeten zijn* +++
3) Vrij simpel voor kleine dingen +

Con's:
1) Het 'simpel zijn' betekend dat alles in hele kleine stapjes gaat per commando, hiermee kun je alles maken, maar wordt snel heel veel voor heel weinig werk -----
2) Een echt (beetje uitgebreid) programma is geen doen om hierin te schrijven. Kost veel te veel tijd en de door de uitgebreidheid is het overzicht heel snel weg -----
3) Geen echte goeie IDE's moor voor (vanwege 1 en 2) -

Mening:
Erg handige taal, gebruik hem wegens bovenstaande con's heel weinig, maar als ik 'em gebruik dan ben ik ook altijd blij met het resultaat

Visual Basic
Pro's:
1) Taal is makkelijk +++
2) Wordt heel veel gebruikt +

Con's:
1) Visual Basic

---
2) BASIC is nou niet echt een mooie taal ---
3) Veel dingen zijn in VB niet te doen en heb je er DLL (in C++ of Object Pascal of zo) -----
4) Een echte MS taal, en die hebben er een handje van om opvolgende versies heel incompatible te zijn met bestaande code ---

Menig:
Ik heb het er liever niet over.

Java
Pro's:
1) Mooie taal, érg OO +++
2) Platformonafhankelijk +++
3) Niet moeilijk te leren** +
4) Handig webbased te gebruiken ++

Con's:
1) Geen scheiding tussen declaratie en code -
2) IDE's zijn niet echt om over naar huis te schrijven (al ben ik het wel met TheRebell eens, JBuilder is één van de betere)

Mening:
Tja, "is leuk"

Het is een beetje een kruising tussen Delphi en C++. Als het écht platform onafhankelijk moet zijn gebruik ik toch liever C++ (personal preference though

)

C#

Pro's:
1) Taal is niet zo heel moeilijk +
2) Min of meer platformonafhankelijk vanwege .NET +++

Con's:
1) Compileerd (tot nog toe) alleen naar .NET *** --
2) Is nog vrijwel alleen voor windows machines te gebruiken --
3) Een echte MS taal, en die hebben er een handje van om opvolgende versies heel incompatible te zijn met bestaande code. ---

Menig:
Goeie taal met waarschijnlijk een grote toekomst, .NET is alleen nog niet zo platvormonafhankelijk als ik het zou willen zijn en daarom voor mij momenteel niet de beste keus.

C++
Pro's:
1) C++ valt op vrijwel OS te compilen, makkelijk dus voor dingen die op echt veel OS'en moeten draaien (icm met bijvoorbeeld gcc) +++++
2) Ontzettend veel over te vinden +++++
3) Met bepaalde IDE's ook ontzettend RAD +++++

Con's:
1) Verschillende C++ 'standaarden' (alsin, er is maar één echte standaard, maar er worden verschillende flavors gebruikt in de "real world") --
2) Soms erg cryptische taal ---
3) 's avonds op building, 's ochtends hopen dat 'ie al klaar is --

Mening:
Dit is naar mijn mening de taal voor redelijk platformonafhankelijke dingen. Na assembler zonder meer de krachtigste taal die er is. Door de soms cryptische taal (dit toont zich vooral bij debuggen en uitzoeken wat er ergens precies gebeurd) maak je snel fouten en vergeet je dingen te doen (wel door documentatie op te lossen maar dan moet je wel heel erg hard gaan documenteren

)

Object Pascal
Pro's:
1) Delphi (Geweldige IDE en component libraries hiervoor) +++
2) Mooie taal +
3) Makkelijke taal +++++
4) Compiles gaan erg snel. Zelfs builden met grote projecten gaat vaak binnen een paar minuten +++++
5) Kan errrug RAD zijn (Bij Delphi/Kylix; FreePascal en gpc meer niet dan wel

) ++++
6) Redelijk platformonafhankelijk ++
7) Ontzettend veel over te vinden +++++

Con's:
1) Geen goeie IDE/RAD voor native AMD64 gepland, behalve via .NET --
2) Vaak vertalingen van API headers vanuit C(++) nodig, en niet altijd 100% compatible hiermee. Van de meer bekende API zijn meestal zonder veel moeite vertaalde API's te vinden. Dat dan weer wel. --
3) FreePascal en gpc zijn niet erg RAD, om met RAD goed platformonafhankelijk te zijn moet je de combinatie Delphi/Delphi.Net/Kylix gebruiken, en Kylix komt in de buurt van maar is nog net geen echte Delphi voor Linux, wat dus problemen kan leveren, ook .NET is nog lang niet beschikbaar voor alle platformen, en is weer (nog) niet compatible met Kylix ---
4) De taal is wel makkelijk, maar hoe dieper je gaat hoe stiekem ingewikkelder hij wordt (de zgn. 'steep lurningcurve')

Menig:
Mijn favoriete taal, ik vind het super

Het coden gaat naar mijn mening sneller dan het coden in C++ mbv C++Builder. De standaard libraries (VCL) zijn hetzelfde maar toch gaat het langzamer omdat je de taal wat cryptischer is. Op het windows platform bijna net zo krachtig als C++ (kan alleen geen kernelmode toepassingen (drivers, very lowlevel systeem tools enzo) maken zonder wat haken en ogen.

Hopelijk heb je er wat aan

* Daarom staat 'ie erbij

** Zonder andere programmeer ervaring
*** Ben ik niet helemaal zeker van

Over over patformonafhankelijkheid: ik heb hier geen verschil gemaakt tussen: zonder extra werk zomaar draaien - vij makkelijk te porten (mits vanaf het begin aan bedacht dat dit wil eens nodig zou kunnen zijn) - per platform een nieuwe compile (met of zonder wat extra coden)

Acties:

xx77qq

Kan je dat ook onderbouwen? Met Object Pascal kan je evenveel doen als in C++.

Allereerst vind ik de syntax minder. Bijvoorbeeld een assignment :=, deze heeft 3 toetsaanslagen nodig. Dit is mijn persoonlijke mening

Heb je generieke klassen (templates) in Object Pascal? Qua OO is er verder niets mis mee.

Operator overloading is er juist om je code duidelijker en leesbaarder te maken.

Het kan je code overzichtelijker maken, maar dan vrijwel alleen voor wiskundige klassen. Maar over het algemeen vertroebeld operator overloading de code, het is te eenvoudig om het verkeerd te gebruiken. Je hebt niet echt houvast aan de code met operator overloading, het zegt je niets over onderhuidse lokale objecten die aangemaakt en verwijderd kunnen worden.
Volgens mij is dat de reden waarom er geen operator overloading in Java zit.

donderdag 22 januari 2004 14:51

Acties:

donderdag 22 januari 2004 15:20

-= Tja =-

Soultaker schreef op 22 januari 2004 @ 13:50:
[...]

Wat mij betreft trekken we de grens tenminste bij de Turing-complete talen. Dan vallen XML, HTML en EBNF af, maar slimme template engines (misschien Velocity, al ken ik het niet) niet.

Hoe het zit met dingen als SQL of XSLT weet ik niet zo 1-2-3. Een enkele SQL query kan nooit een Turing-compleet programma opleveren, dus op zichzelf zou ik het geen taal willen noemen. XSLT ken ik niet goed genoeg om de inschatting te maken.

Ik zou het eerlijk gezegd ook niet weten. En het ging mij erom dat de topicstarter ook weet dat er naast de programmeertalen ook veel andere talen gebruikt worden.

boomsmurf
Topic gaat over programmeertalen. XML en HTML zijn markup languages, SQL is een query taal.

Ik ben blij dat mijn opmerking zoveel commentaar losmaakt

En zie verder vorige commentaar.

on-topic

Ik behandel alleen de talen ik gebruik(-t heb) doh

Ik ook

[ Voor 3% gewijzigd door Alarmnummer op 22-01-2004 14:52 ]

Acties:

LordLarry

Aut disce aut discede

Verwijderd schreef op 22 januari 2004 @ 13:02:
Object pascal (ligt onder delphi) is lastig te leren als je de andere talen kent vanwege afwijkende notaties

Dat komt omdat je nu hoofdzakelijk talen opnoemd die van C/C++ afgeleid zijn. Nogal wiedus dat Object Pascal anders is

VB is overgens nog veel meer anders als C/C++, IMHO. Ik zie dan ook niet waarom pascal lastiger te leren zou zijn als een andere taal. Ik ben zelfs van mening dat het zelfs sneller en makkelijker aan te leren valt als C/C++. Pascal is zelfs origineel ontworpen met als 1 van de doelen dat het makkelijk te leren moest zijn. Verder is Object Pascal verder geevolureerd waarbij we nu op een punt aangekomen zijn dat Object Pascal niet onder hoeft te doen voor C# en C++. Inclusief operator overloading sinds Delphi 8.

xx77qq schreef op 22 januari 2004 @ 14:21:
Allereerst vind ik de syntax minder. Bijvoorbeeld een assignment :=, deze heeft 3 toetsaanslagen nodig. Dit is mijn persoonlijke mening

Heb je generieke klassen (templates) in Object Pascal? Qua OO is er verder niets mis mee.

twee tel ik er. Das 1 meer als bij C. Bij C moet je weer == gebruiken ipv = en dat is er dus weer 1 minder in Pascal. Staan we toch gelijk.

Ja, je zal iets meer moeten typen, maar daarvoor krijg je, mijns inziens, wel een duidelijkere structuur, minder kans op fouten en de compiler kan je een duidelijkere foutmelding geven.

We adore chaos because we like to restore order - M.C. Escher

donderdag 22 januari 2004 15:42

Acties:

ATS

In de post hierboven wordt voor het eerste C genoemd (welliswaar samen met C++, maar toch). Dat is vreemd. De taal wordt nog altijd veel gebruikt. Zowel Windows als Linux (kernel) zijn, AFAIK, nog altijd gemaakt in C.

De talen die beheers zijn Visual Basic, C++ en, in mindere mate Delphi. Ik laat me verder niet uit over andere talen zoals HTML, PHP, SQL, etc., omdat dit IMHO geen programmeertalen zijn.

Visual Basic is wat de naam al zegt: Basic. Het is geschikt om snel wat basis dingen te doen, maar je loopt al heel snel tegen de grenzen aan. Bovendien vraagt het om onoverzichtelijke code.

Delphi is een grote stap vooruit ten opzichte van Visual Basic. Het is vele, vele malen gestructureerder en veel krachtiger.

Tengewoordig gebruik ik bijna alleen nog maar C++. Het grote voordeel tegenover C is de object georienteerdheid. Naar mijn mening kan dat bij goed design een heel erg elegante en overzichtelijke structuur opleveren, wat uiteindelijk resulteert in goed onderhoudbare code en uit te breiden code. De taal is erg krachtig. Dat resulteert er ook in dat je je jezelf eenvoudig kan 'ophangen': "C gives you the string to hang you with, C++ gives you the object tree to tie the string to", of zoiets. Als je netjes werkt hoeft dat geen probleem te zijn trouwens. Het is denk ik een trade-off van krachtige talen: die staan je juist daarom ook fouten met grote gevolgen toe. Een voorbeeld zijn de pointers in C++ en C. Hier kan je hele leuke dingen mee doen (even eenvoudig en efficient een array van objecten doorwandelen bijvoorbeeld, maar ook functiepointers zijn een goed voorbeeld), maar ze kunnen je op een segfault of erger komen te staan als je een ongeinitialiseerde pointer gebruikt.

My opinions may have changed, but not the fact that I am right. -- Ashleigh Brilliant

donderdag 22 januari 2004 15:46

Acties:

donderdag 22 januari 2004 15:57

Moderator Devschuur®

Demotivational Speaker

LordLarry schreef op 22 januari 2004 @ 15:20:
Pascal is zelfs origineel ontworpen met als 1 van de doelen dat het makkelijk te leren moest zijn.

was dat niet omdat het makkelijk te parsen moest zijn? Pascal dialecten worden niet voor niets gebruikt in de compilerbouw e.d.

Verder vind ik het punt van xx77qq ook een beetje bullshit. Of je nu := en = gebruikt of = en ==, het is slechts een luttele afweging, en totaal niet relevant voor wat je er voor de rest van de taal wel of niet mee kan.

Ik zou zelfs nog wel een argument vóór kunnen verzinnen: als je := en = gebruikt heb je geen kans op verkeerde typefouten die je in een taal als C++ wel hebt:

C++:

void f (int i)
{
    if (i = 3)
        std::cout << "woei" << std::endl;
}

Ik vind dit echter geen goed argument om aan te tonen dat de syntax van C/C++ slechter zou zijn (in java en C# geldt dit sowieso al niet, omdat die een fundamental type niet automatisch kunnen casten naar bool)

En iedereen die klaagt over het niet aanwezig zijn van een GC in C++ wil ik graag verwijzen naar de signature van MSalters

[ Voor 6% gewijzigd door .oisyn op 22-01-2004 15:48 ]

Give a man a game and he'll have fun for a day. Teach a man to make games and he'll never have fun again.

Acties:

Count

BoomSmurf schreef op 22 januari 2004 @ 14:00:
[... mooi overzichtje/recensie ...]

Dit is de beste post in het draadje tot nu toe. Hoewel veel dingen natuurlijk subjectief zijn. Ik vind (Object) Pascal namelijk foeilelijk qua syntax. Maar dat maakt het dan niet direct een beroerde taal voor de volgende persoon.

Verder is C++ gewoon een taal die wat meer ervaring en nauwkeurigheid vereist (vergeleken met 3GL zoals Java). Maar dingen zoals garbage collection etc kun je zelf automatiseren mbv templates (std::autoptr). Dus wanneer je de eenmaal de ervaring/kennis hebt opgebouwt is het niet een heel moeilijke taal meer.

De überwijsheid is dat elke taal zijn eigen niche heeft. Bepaalde dingen zijn gewoon makkelijker te maken in de ene taal als de andere. Simpele database software kun je sneller schrijven in Access/VB dan in C++ terwijl voor andere projecten VB weer totaal ongeschikt is.

Great minds think in parallel gutters.

donderdag 22 januari 2004 15:59

Acties:

LordLarry

Aut disce aut discede

.oisyn schreef op 22 januari 2004 @ 15:46:
was dat niet omdat het makkelijk te parsen moest zijn? Pascal dialecten worden niet voor niets gebruikt in de compilerbouw e.d.

Beide zelfs:

There were two original goals for Pascal. According to the Pascal Standard (ISO 7185), these goals were to a) make available a language suitable for teaching programming as a systematic discipline based on fundamental concepts clearly and naturally reflected by the language, and b) to define a language whose implementations could be both reliable and efficient on then-available computers.
bron: http://www.pascal-central.com/ppl/

We adore chaos because we like to restore order - M.C. Escher

donderdag 22 januari 2004 16:16

Acties:

xx77qq

LordLarry schreef op 22 januari 2004 @ 15:20:

[...]

twee tel ik er. Das 1 meer als bij C. Bij C moet je weer == gebruiken ipv = en dat is er dus weer 1 minder in Pascal. Staan we toch gelijk. Ja, je zal iets meer moeten typen, maar daarvoor krijg je, mijns inziens, wel een duidelijkere structuur, minder kans op fouten en de compiler kan je een duidelijkere foutmelding geven.

Helaas, := doe je met shift, dubbelepunt en een =, dat zijn drie toetsaanslagen! . Hetzelfde over BEGIN END, is ook weer meer invoeren in vergelijking met C(++), Java en python. Als je naar de python manier kijkt dan heb je de begin en end keywords niet nodig. Gewoon met whitespaces doen, precies zoals je de code nu ook maakt.
Maar goed, een goed en leesbaar stuk Pascal code is nog altijd veel beter dan een bagger stuk C++ code.

Duidelijke foutmeldingen van de compiler zijn heel belangrijk. Ik ga over mijn nek als ik in C++ en STL een foutmelding krijg als (gedeeltelijk afgedrukt):
/usr/include/c++/3.3/bits/basic_string.h:606: error:
std::basic_string<_CharT, _Traits, _Alloc>& std::basic_string<_CharT,
_Traits, _Alloc>::replace(__gnu_cxx::__normal_iterator<typename
_Alloc::pointer, std::basic_string<_CharT, _Traits, _Alloc> >,
__gnu_cxx::__normal_iterator<typename _Alloc::pointer,
std::basic_string<_CharT, _Traits, _Alloc> >, const
std::basic_string<_CharT, _Traits, _Alloc>&) [with _CharT = char, _Traits =
std::char_traits<char>, _Alloc = std::allocator<char>]

Dat als je een iterator i.p.v. een integer gebruikt in een replace functie. Fout van de programmeur, maar het is fijn als de compiler een handje meehelpt ;-)

donderdag 22 januari 2004 16:34

Acties:

donderdag 22 januari 2004 16:36

Moderator Devschuur®

Demotivational Speaker

Dat heeft puur en alleen te maken met templates, waarbij het vrij moeilijk is voor een compiler om een gedegen error te schrijven (door de immens complexe typen gecreëerd door templates). Een goede compiler geeft in zo'n geval vaak wel aan waar de basis van de fout zich bevindt (oftewel: de plek waar de template geïnstantieerd wordt), en met een snelle klik op de fout (ik ga er even vanuit dat je een gedegen IDE gebruikt) en je ziet al snel waarom het fout gaat.

Dat als tegenargument voor C++ vind ik dus wederom niet valide, je bent immers niet verplicht om van templates gebruik te maken (en op oudere compilers doe je er zelfs beter aan om ze in het algemeen maar te vermijden). Ze zijn handig, niet nodig

[ Voor 22% gewijzigd door .oisyn op 22-01-2004 16:35 ]

Give a man a game and he'll have fun for a day. Teach a man to make games and he'll never have fun again.

Acties:

Verwijderd

BoomSmurf schreef op 22 januari 2004 @ 14:00:
[...]

Topic gaat over programmeertalen. XML en HTML zijn markup languages, SQL is een query taal.

XML zelf is een data beschrijvings taal, maar een dialect kan wel zeer zeker een programmeertaal zijn.

Bv de taal JDL (Job Description Language, zie www.sourceforge.net/projects/jdawn ).

Deze werkt dmv een dataflow een applicatie te schrijven. Ongeveer zoiets als Unix pipe and filters, maar in plaats van alleen een pipe-line heb je dan een DAG. Leent zich ook zeer goed voor grafische programmeren.

Aanrader om eens te bekijken (werk er zelf aan mee, post er binnenkort nog wel wat meer over

)

Assembler
Pro's:
1) Retesnel (mits goed geprogd) +++++

Dat was voornamelijk waar toen de ISA primair ingericht was voor de menselijke programmeur. In sommige CPU's was de ISA erg high level, met dingen als string compare enz. In (alle?) hedendaagse CPU's is de ISA voornamelijk gericht naar de compiler. Vele kleine erg basic instructies, voor mensen bijna niet bij te houden ILP potentie enz. Deze ISA's zijn helemaal gericht op compiler optimalisaties, zelfs in zoverre dat compilers echt noodzakelijkerwijs tegelijk met moderne CPU's moeten worden ontwikkeld (bv IA64). M.a.w. assembler is primair een machine to machine language vandaag de dag.

Dat Assembler sneller zou zijn is vooral een thing of the past die verstokte old school programmeurs niet los willen laten. En geef ze eens ongelijk. In hun tijd waren ze de 'king' met de beheersing van een moeilijk te leren vaardigheid. Lachend keken ze neer op de 'dommere' C, Pascal enz programmeurtjes. Helaas heeft de tijd deze mensen ingehaald, en dat is natuurlijk moeilijk te verkroppen.

Toch is kennis van Assembly absoluut een voordeel, omdat het je simpelweg kennis van de computer architecturen geeft. Verwacht echter niet op mainstream PCs dat assembly je een snelheids winst gaat geven voor normale apps (zelfs niet voor enkele kleine routines). Device drivers en embedded is overigens nog wel een uitzondering, maar een heel specificieke markt.

Java
Pro's:
[...]
2) Platformonafhankelijk +++

Min or meer

Con's:
1) Geen scheiding tussen declaratie en code -
2) IDE's zijn niet echt om over naar huis te schrijven (al ben ik het wel met TheRebell eens, JBuilder is één van de betere)

En Eclipse natuurlijk

C++
[...]
Con's:
[...]
3) 's avonds op building, 's ochtends hopen dat 'ie al klaar is --

Dat valt toch wel mee? Over wat voor soort projecten praten we dan? Het Jdawn project (bovengenoemde JDL is daar onderdeel van) waar ik aan werk(te) is bv +- 35.000 regels C++. Op een PII/266 met VC7 compileerd dat in 10 a 15 minuten. Op mijn P4/2.8 is het een minuutje ofzo.

Als we even uitgaan dat de snelheid linear scaled, we 8 uur voor de nacht nemen en bovengenoemde compile tijd even ruim nemen, zou jij dus elke nacht 30*8*35.000 = 8.4 MILJOEN regels compileren ???

(of werk je op een echt hele oude machine ofzo ?)

donderdag 22 januari 2004 16:40

Acties:

donderdag 22 januari 2004 16:46

Moderator Devschuur®

Demotivational Speaker

Verwijderd schreef op 22 januari 2004 @ 16:36:
Deze ISA's zijn helemaal gericht op compiler optimalisaties, zelfs in zoverre dat compilers echt noodzakelijkerwijs tegelijk met moderne CPU's moeten worden ontwikkeld (bv IA64). M.a.w. assembler is primair een machine to machine language vandaag de dag.

Dat is een beetje kort door de bocht, assembly wordt vandaag de dag nog altijd gebruikt in tight loops op essentiele plekken in applicaties. Bovendien heb ik nog nooit een general-purpose compiler gezien die een stuk code sneller kan maken dan een met de hand geschreven SSE/3DNow! routine voor de IA32.

Het is natuurlijk wel zo dat dit een last-resort optimalisatie is, die je pas uitvoert na het verbeteren van je gebruikte algoritmes en gedegen profiling om op te sporen waar de bottleneck nou precies zit

[ Voor 14% gewijzigd door .oisyn op 22-01-2004 16:45 ]

Give a man a game and he'll have fun for a day. Teach a man to make games and he'll never have fun again.

Acties:

Verwijderd

Alarmnummer schreef op 22 januari 2004 @ 12:45:

.NET is een platform en niet een taal. .NET heeft een soort tussenformaat (te vergelijken met java bytecode) waar verschillende talen (c++, delphi, haskell, eiffel, basic) naar toe kunnen compileren.

.NET is een platform ja, oa bestaande uit de .NET library, 1 VM (CLR genoemd) met 1 native taal (CL). Je zou kunnen zeggen dat in principe er ook 1 high level taal toe behoord en dat is dan C# (alhoewel dat strict genomen niet zo is geloof ik)

In het geval van Java heb je ongeveer de zelfde componenten. Het Java platform als geheel, met componenten Java library, Java VM, bytecode & Java Language.

donderdag 22 januari 2004 16:47

Acties:

donderdag 22 januari 2004 17:10

Moderator Devschuur®

Demotivational Speaker

Het ging over talen. Java is naast een platform ook gewoon een taal. .Net niet

Give a man a game and he'll have fun for a day. Teach a man to make games and he'll never have fun again.

Acties:

Verwijderd

.oisyn schreef op 22 januari 2004 @ 16:40:
[...]
Dat is een beetje kort door de bocht

Het is inderdaad een beetje kort door de bocht. Toch is het wel zo dat assembly optimalisatie tegenwoordig veel moeilijker is dan vroeger en veel vaker het tegenovergestelde effect heeft.

Vroeger keek je naar de assembly source die je compiler genereerde en keek je oa naar overbodige loads en stores, die vaak makkelijk op te sporen waren. Tegenwoordig moet je tot in het absurde rekening houden met welke combinaties van instructies de superscalar pipe-lines het beste werken. Iets wat er in code (voor een op de traditionele optimalisaties getrainde geest) langzamer uit ziet kan juist op de CPU sneller zijn.

Ik heb vroeger die assembly optimalisaties nog echt gedaan ('92 ofzo), en de code werd er echt sneller door. Ik ben er mee gestopt toen keer op keer bleek dat mijn hand made optimalisaties door nieuwere compilers moeiteloos overtroffen werden. Mischien ben ik een slechte assembly optimalisator, maar andere mensen vertelden over gelijke ervaring.

Bovendien heb ik nog nooit een general-purpose compiler gezien die een stuk code sneller kan maken dan een met de hand geschreven SSE/3DNow! routine voor de IA32/

Dat is waar. Intrinsics vergemakkelijken dat process nog enigzins. Je kunt ook bv types als __m64 in vc redelijk transparant gebruiken in je algoritmes. Of je dan echt met assembly bezig bent? In feite natuurlijk wel :-)

Overigens optimized de Apple gcc compiler niet automatisch voor altivec?

donderdag 22 januari 2004 17:53

Acties:

farlane

Overigens ben ik van menig dat voor het debuggen een basiskennis van ASM onontbeerlijk is.

Voor veelgebruikte uProcs zijn er vaak wel C compilers bijvoorbeeld, maar het komt maar al te vaak voor dat deze code produceren die gewoon niet goed is.

Als je dan een listingfile kunt lezen en enigzins begrijpen heb je een grote voorsprong.

Op de PC is dit weliswaar niet van groot belang, maar ook daar heb ik voor het debuggen al meerdere keren een ASM stacktrace moeten uitpluizen.

Somniferous whisperings of scarlet fields. Sleep calling me and in my dreams i wander. My reality is abandoned (I traverse afar). Not a care if I never everwake.

donderdag 22 januari 2004 17:58

Acties:

donderdag 22 januari 2004 18:07

Am-Ende!

@ alarmnummer

Ik ben blij dat mijn opmerking zoveel commentaar losmaakt En zie verder vorige commentaar.

Meteen na jou post begon ik het al te typen, duurde alleen effe voor ik m'n hele bericht geplaatst had

@ count

Dit is de beste post in het draadje tot nu toe. Hoewel veel dingen natuurlijk subjectief zijn. Ik vind (Object) Pascal namelijk foeilelijk qua syntax. Maar dat maakt het dan niet direct een beroerde taal voor de volgende persoon.

Met dank

Verder is C++ gewoon een taal die wat meer ervaring en nauwkeurigheid vereist (vergeleken met 3GL zoals Java). Maar dingen zoals garbage collection etc kun je zelf automatiseren mbv templates (std::autoptr). Dus wanneer je de eenmaal de ervaring/kennis hebt opgebouwt is het niet een heel moeilijke taal meer.

Zelf ben ik niet zo gek op templates - het wordt mijninsziens zo'n warboel ervan. Ik kan best aardig C++ (al zou ik mezelf geen guru noemen

) maar ik blijf het vinden, door de syntax van de taal heb je al snel ergens een pointer error zitten (wat ik bij Object Pascal een stuk minder vind)

De überwijsheid is dat elke taal zijn eigen niche heeft. Bepaalde dingen zijn gewoon makkelijker te maken in de ene taal als de andere. Simpele database software kun je sneller schrijven in Access/VB dan in C++ terwijl voor andere projecten VB weer totaal ongeschikt is.

@ henk_DE_man

komt neer op: compilers zijn beter in optimalisatie dan een mens

Hier ben ik het zeer zeker niet mee eens.

Veel loops en bepaalde operaties zijn echt wel sneller als je ze met de hand in assembler gaat doen, het ligt er maar net aan wat er in die loop gebeurd. En verder zijn natuurlijk niet alle compilers zo 'snel' als bijvoorbeeld de Intel C++ compiler (gelukkig zijn de meeste wel een stuk stabieler

). Als ik het gebruik beat ik de compiler meestal met een aardige factor, maar ik kijk natuurlijk ook zorgvuldig naar wat ik weet dat de compiler niet goed optimaliseerd (dat moet je natuurlijk wel weten dan

).

Ik ben het er inderdaad wel mee eens dat in je mainstream app je hier waarschijnlijk nooit tot zeer zelden voordeel in zult zien, maar hoe vaak maak je nou iets mainstreams?

['s avonds op building, 's ochtends hopen dat 'ie al klaar is --]

Dat valt toch wel mee? Over wat voor soort projecten praten we dan? Het Jdawn project (bovengenoemde JDL is daar onderdeel van) waar ik aan werk(te) is bv +- 35.000 regels C++. Op een PII/266 met VC7 compileerd dat in 10 a 15 minuten. Op mijn P4/2.8 is het een minuutje ofzo.

Die hele nachten builden is natuurlijk sterk overdreven. Het duurt gewoon lang. Irritant lang.

Het grootste project waar ik aan meegewerkt heb is ongeveer 250.000 regels code, dit is wel in Object Pascal maar in C++ zal het er niet zo heel ver naast zitten.
Op mijn 2.4@1.8ghz (moet een nieuwe fan op

) werk pc compiled Delphi dat in ongeveer 1 seconde, een build duurt minder dan een halve minuut.

Jouw VC7 zou daar (ongeveer jouw cijfers volgend) dan 7 a 8 minuten over doen. Ik zou er helemaal irritant van worden, kan net zo goed een jaar zijn.

Acties:

donderdag 22 januari 2004 18:20

Moderator Devschuur®

Demotivational Speaker

BoomSmurf schreef op 22 januari 2004 @ 17:58:
Zelf ben ik niet zo gek op templates - het wordt mijninsziens zo'n warboel ervan. Ik kan best aardig C++ (al zou ik mezelf geen guru noemen ) maar ik blijf het vinden, door de syntax van de taal heb je al snel ergens een pointer error zitten (wat ik bij Object Pascal een stuk minder vind)

Hangt natuurlijk een beetje van het gebruik ervan af. Ik vind het gebruik van een std::autoptr of een std::vector nou niet echt bepaald een warboel worden. Als je een library als Loki erbij pakt dan is dat idd vaak wel zo, omdat het juist heel erg gericht is op generalisiteit. Het is een mooie opgezette library, maar verder gebruik ik het idd ook niet.

Imho zijn templates het best in te zetten als containers en kleine wrapper classes die het gebruik ergens van een stuk makkelijker maken. In andere gevallen zorgen ze vaak voor code-bloat, teveel dependencies, en daarom ook te lange build tijden

I

templates trouwens verder

[ Voor 6% gewijzigd door .oisyn op 22-01-2004 18:10 ]

Give a man a game and he'll have fun for a day. Teach a man to make games and he'll never have fun again.

Acties:

Verwijderd

BoomSmurf schreef op 22 januari 2004 @ 17:58:

@ henk_DE_man

Hier ben ik het zeer zeker niet mee eens.

Veel loops en bepaalde operaties zijn echt wel sneller als je ze met de hand in assembler gaat doen, het ligt er maar net aan wat er in die loop gebeurd.

Lees ook mijn andere post. Bottomline is: Nog niets eens zo heel lang geleden werd voor een bepaalde architectuur de assembly taal speciaal voor mensen gemaakt. Tegenwoordig, zeker voor de nieuwste architecturen, wordt de assembly taal speciaal voor compilers gemaakt.

Dat is zowieso een verandering. Of jij als mens nog steeds beter kunt optimizen (in elke situatie) dan een compiler, wil ik dan wel geloven, mischien ben jij gewoon heel erg goed. Toch... als jij echt zo veel en vaak en ook al lang met de hand optimaliseerd, moet je toch toegeven dat het een heel andere discipline is geworden dan pak em beet 10 jaar terug. De taal is simpelweg niet meer bedoeld voor mensen.

Het grootste project waar ik aan meegewerkt heb is ongeveer 250.000 regels code, dit is wel in Object Pascal maar in C++ zal het er niet zo heel ver naast zitten.
Op mijn 2.4@1.8ghz (moet een nieuwe fan op ) werk pc compiled Delphi dat in ongeveer 1 seconde, een build duurt minder dan een halve minuut.

Hmmm, dat is dus zo'n 7 cycles per regel gemiddeld. Het lijkt mij dat alleen het inlezen van een gemiddelde regel al iets meer kost, zelfs al zou je alles al in het geheugen hebben. Weet je wel zeker dat ie al die 250.000 regels daadwerkelijk compiled?

Met een build bedoel je dan alleen het linken en het naar disk schrijven?

donderdag 22 januari 2004 18:22

Acties:

donderdag 22 januari 2004 18:24

Moderator Devschuur®

Demotivational Speaker

Delphi doet geen full rebuild, als ie dat wel zou doen dan zou het veel langer kosten dan 1s

Give a man a game and he'll have fun for a day. Teach a man to make games and he'll never have fun again.

Acties:

Verwijderd

.oisyn schreef op 22 januari 2004 @ 18:07: Imho zijn templates het best in te zetten als containers en kleine wrapper classes die het gebruik ergens van een stuk makkelijker maken.

Inderdaad. Je ziet bv bij Java dat voor alle collection classes bijna altijd een cast nodig is om iets uit de collection te halen. Nee, dat maakt het er overzichtelijk op!

donderdag 22 januari 2004 18:53

Acties:

jvdmeer

curry684 schreef op 22 januari 2004 @ 13:29:
[...]

'Hello World' in 204 verschillende talen

En zelfs in deze pagina mis ik een taal!

Whitespace: info

met natuurlijk ook: Hello world!

Verwijderd schreef op 22 januari 2004 @ 14:00:
[...]

Ook leuk: het "Towers of hanoi"-probleem in 108 verschillende talen.

En ook deze is in whitespace te vinden.

[ Voor 30% gewijzigd door jvdmeer op 22-01-2004 19:07 ]

donderdag 22 januari 2004 20:52

Acties:

donderdag 22 januari 2004 22:15

Am-Ende!

Verwijderd schreef op 22 januari 2004 @ 18:20:
Dat is zowieso een verandering. Of jij als mens nog steeds beter kunt optimizen (in elke situatie) dan een compiler, wil ik dan wel geloven, mischien ben jij gewoon heel erg goed. Toch... als jij echt zo veel en vaak en ook al lang met de hand optimaliseerd, moet je toch toegeven dat het een heel andere discipline is geworden dan pak em beet 10 jaar terug. De taal is simpelweg niet meer bedoeld voor mensen.

Geloof vooral niet dat ik in elke situatie de compiler klop - dat is gewoon niet waar. Als ik er echt mee bezig ga om iets te optimizen, in dat geval vaak wel.

Dat het een andere discipline is moge wel duidelijk zijn

Ik heb 'em er puur bijgezet omdat het toch een programmeertaal is, en je hem af en toe nog best gebruikt.

Hmmm, dat is dus zo'n 7 cycles per regel gemiddeld. Het lijkt mij dat alleen het inlezen van een gemiddelde regel al iets meer kost, zelfs al zou je alles al in het geheugen hebben. Weet je wel zeker dat ie al die 250.000 regels daadwerkelijk compiled?

Met een build bedoel je dan alleen het linken en het naar disk schrijven?

Compile = wat veranderd is opnieuw compilen
Build = al je source opnieuw compilen

30 seconden = 30 * 1.8 * 1.000.000.000 = 54.000.000.000 cycles
Cycles per regel = 54.000.000.000 / 250.000 = 216.000 cycles/regel

[ Voor 11% gewijzigd door BoomSmurf op 22-01-2004 20:57 ]

Acties:

HarmoniousVibe

Talen waar ik ervaring mee heb (in chronologische volgorde):

Java
+ Min of meer platformonafhankelijk
+ Gemakkelijk te leren
+ OO
+ Brede ondersteuning
- Geen fatsoenlijke GUI
- traag/instabiel, vooral met GUI
- Verbose

Python
+ OO
+ Erg leesbare code
+ Veel GUI toolkits en RAD tools beschikbaar
+ Draait op redelijk wat platforms
+ Hoge productiviteit
+ Leuk
+ Niet moeilijk
- Aan de trage kant
- Nog weinig ondersteuning

PHP
+ Erg eenvoudig
+ Brede ondersteuning
+ Goede database en http connectivity
- Veiligheid

Object Pascal
+ Goede IDE
+ Snel genoeg
- Syntax/code ligt me niet echt (echt niet)

Dit zijn mij subjectieve ervaringen met een aantal programmeer- en scriptingtalen. Hou me momenteel vooral bezig met Python.

12 × LG 330Wp (Enphase) | Daikin FTXM-N 3,5+2,0+2,0kW | Panasonic KIT-WC03J3E5 3kW

donderdag 22 januari 2004 22:24

Acties:

Verwijderd

BoomSmurf schreef op 22 januari 2004 @ 20:52:
[...]
Geloof vooral niet dat ik in elke situatie de compiler klop - dat is gewoon niet waar.

Uhmm... elke compiler die de standaard van een taal implementeerd wordt geacht een vertaling te making die semantisch precies overeenkomt met de taal regels. M.a.w de output van een (standard conforming) compiler klopt altijd, eventuele bugs natuurlijk buiten beschouwing gelaten.

Wat jij mischien bedoelt is dat de code die gegenereerd wordt niet altijd 1:1 correspondeerd met wat je denkt dat er uit zal komt. Als simpelste voorbeeld het wegwerken van constanten. Schrijf bv een functie als:

C++:

int bla() {
   int a = 4;
   int b = 2*a;
   return b-1;
}

Als je deze functie gebruikt moet je niet raar staan te kijken als in je gegenereerde assembly code gewoon de constante 7 komt en er helemaal geen functie call plaatsvindt. Klopt dat volgens jou niet?

Dat het een andere discipline is moge wel duidelijk zijn

Wat ik eigenlijk bedoelde is dat werken met de assembly van vandaag een andere discipline is dan vroeger.

Vroeger werden Assembly talen ontworpen voor mensen, vandaag voor compilers.
Dat is gewoon een verschil. De nieuwe assembly talen zijn niet meer bedoeld om door mensen geschreven te worden, hoogstens nog om te lezen.

Ik heb 'em er puur bijgezet omdat het toch een programmeertaal is, en je hem af en toe nog best gebruikt.

Zoals hierboven iemand brilliant opmerkte, voor debugging gebruik je hem natuurlijk nog wel. En zoals ik zelf opmerke, in special cases (drivers, embedded) ook nog. .oisyn melde nog dat voor de special purpose ISA extensies (meestal voor multi media) ook assembly gebruikt wordt. Het is dus nog wel zeer zeker in gebruik en ook 100% een programmeer taal die heel interesant is om in taal vergelijkingen mee te nemen. Zeker als dit vanuit een historisch oogpunt gebeurt.

Compile = wat veranderd is opnieuw compilen

Compile = transformatie van source code naar target code
Differential/incremental compilation = wat veranderd is opnieuw compilen

Build = al je source opnieuw compilen

Build = alle (nog nodige) acties ondernemen om de complete target resource(s) (meestal executable) te genereren.
Rebuild = Alle tijdens een build gegenereerde resources verwijderen en overnieuw builden.

Volgens jou kan mijn compiler 6 miljard regels in 0 sec. compilen; namelijk ik maak gewoon geen veranderingen. duh...

Overigens heeft VC ook vele opties om niet na elke verandering alles opnieuw te builden. Bv minimal rebuild en pre-compiled headers. Maar zelfs zonder die opties wordt er niet domweg alles overnieuw gecompileerd bij een verandering in 1 file. Als die file independent is wordt er gewoon een nieuw object file gemaakt en die wordt overnieuw gelinked (en ja, incremental linking bestaat ook al). gcc icm met bv make of een IDE kan dat ook.

M.a.w. je argument dat dat mooie delphi van je zo snel compiled slaat dus echt helemaal nergens op.

[ Voor 7% gewijzigd door Verwijderd op 22-01-2004 22:29 ]

donderdag 22 januari 2004 22:41

Acties:

whoami

Verwijderd schreef op 22 januari 2004 @ 22:24:

M.a.w. je argument dat dat mooie delphi van je zo snel compiled slaat dus echt helemaal nergens op.

Wat bedoel je nu?
Delphi is er voor gekend dat het een van de snelste compile/build processen heeft. Ik heb hier net nog ff een testje gedaan: ik heb een Delphi projectje van 17600 regels, ik heb m'n object files verwijderd en het project gebuild: in minder dan 2 seconden was ie klaar. (Op een P4 2.6, 512 mb RAM)

https://fgheysels.github.io/

donderdag 22 januari 2004 22:52

Acties:

donderdag 22 januari 2004 23:49

Moderator Devschuur®

Demotivational Speaker

M.a.w. je argument dat dat mooie delphi van je zo snel compiled slaat dus echt helemaal nergens op.

Het is wel zo dat delphi veel minder dependencies heeft. C(++) heeft gewoon een traag compileerproces door de headers die gigantisch veel dependencies creëren

Give a man a game and he'll have fun for a day. Teach a man to make games and he'll never have fun again.

Acties:

Verwijderd

.oisyn schreef op 22 januari 2004 @ 22:52:
[...]

Het is wel zo dat delphi veel minder dependencies heeft. C(++) heeft gewoon een traag compileerproces door de headers die gigantisch veel dependencies creëren

Ja natuurlijk, jullie hebben allemaal gelijk $_/-\o_$ .
Ik wilde het er nog bij schrijven, maar vergat het stukje. Vanzelfsprekend is Delphi op zich met compileren een stuk sneller. Dit kan wel zeker aan de mechanismes en structuur van de taal liggen. Neem nou ook bv Java die geen link fase kent.

Wat ik echter bedoelde boven is dat die BoomSmurf enkel op grond van het incremental builden beweerde dat Delphi zo snel was. De suggestie werd gewekt dat C++ in alle gevallen 7~8 minuten over een full build zou doen terwijl Delphi het in 1 seconde of een halve minuut kon.

Ik wees er toen op dat C++ net zo goed incremental kan builden en dat het dan ook in zeer korte tijd kan.

Het is natuurlijk wel interesant om naar 2 eigenschappen te kijken:

1) Welke taal kan van scratch sneller compileren
2) Welke taal kan sneller incremental compileren

Bij 2) dan niet alleen de snelheid opzich, maar ook de hoeveelheid code die naar een typische kleine verandering overnieuw moet. Ik vrees zo dat C++ op beiden punten het wel zal verliezen van veel andere talen

vrijdag 23 januari 2004 14:43

Acties:

vrijdag 23 januari 2004 14:51

Am-Ende!

Verwijderd schreef op 22 januari 2004 @ 22:24:

< snip henk_DE_man >

Misschien moet je eens opnieuw lezen wat ik getypt heb, en reactie daar op geven, ipv reageren alsof ik dingen zeg die ik helemaal niet zeg.

Acties:

vrijdag 23 januari 2004 21:37

-= Tja =-

Persoonlijk vind ik dit topic een beetje verzanden in een voor de topicstarter oninteressant stuk geneuzel over details. Ik hoop dat we weer on topic kunnen komen met voor en nadelen tussen verschillende talen en hoop ook dat mensen niet zo kleingeestig zijn en alleen de gebruikelijke talen te willen toelichten.

Acties:

alienfruit

the alien you never expected

Ik snap de reactie van sommige mensen hier niet, dat de Dephi Syntax niet lekker aan voelt. Het lijkt er erg op dat deze mensen begonnen zijn met een C achtige syntax begonnen zijn, en nu een aversie hebben tegen anderen syntax soorten zoals Delphi en/of Lingo (om effe een but taal te noemen

). Zelf vind ik Delphi een vergelijkbare taal als met C++. Zelfs Delphi.NET is uitgebreider dan C#. C# kan je niet gebruiken om assemblies te maken die werken vanuit win32, class helpers e.d.

maandag 26 januari 2004 14:57

Acties: