Ideeën voor een nieuwe programmeertaal

[Travelan]

Hey,

Ik ben voor studie bezig met het ontwerpen van een programmeertaal. Na dat project wil ik het ook uitwerken, maar dat heeft niet erg veel meer met de studie te maken. Ik wil hem wel imperatief houden, met een sterk object geörienteerd karakter. Wel zit ik er aan te denken om geintjes uit functionele programmeertalen zoals lazy evaluation toe te passen.

Misschien is het wel belangrijker wat de boze wereld denkt over een nieuwe programmeertaal dan wat ik er persoonlijk over denk. Vandaar dat ik hier een discussie start.
Vraag is:
Wat mis je nu in je favoriete programmeertaal? of
Als jij C/C++/JAVA/Basic/Haskell/(Vul in) had ontworpen, wat had je anders gedaan?
Het is wel de bedoeling dat het een industriële programmeertaal wordt. (redelijk simpel te leren, gericht op het echt ontwerpen van programma's, in tegenstelling tot het ontwerpen van algoritmes en bewijstheorie)

Ik heb al het een en ander opgeschreven in een specification report. Als je geïnteresseerd bent in dit project kun je die downloaden(pdf) van de site, staat op de voorpagina: http://www.thinder.org

Voor mijn idee van lazy evaluation heb ik dat hier duidelijk uitgelegd: http://www.thinder.org/brainstorm/idea/3

Ik hoor graag wat jullie denken!

[ Voor 0% gewijzigd door Travelan op 23-06-2008 18:50 . Reden: oeps foutje! bedankt. ]

[beany]

Ik ben altijd van mening dat je de juiste tool voor klus moet gebruiken. Zo zie ik next-gen games eerder in C++ geschreven worden dan in QuickBASIC.

Dus... wat wil jij met Thinder? Moet het high-performance worden(zoals C++) of wil je veel flexibiliteit(zoals .Net(C#, VB.NET etc)) etc etc...

Is de doelgroep applicatie programmeurs, website programmeurs, embedded programmeurs... ??

Kortom: wat wil je precies?

[RayNbow]

beany schreef op maandag 23 juni 2008 @ 19:02:
Ik ben altijd van mening dat je de juiste tool voor klus moet gebruiken. Zo zie ik next-gen games eerder in C++ geschreven worden dan in QuickBASIC.

Dus... wat wil jij met Thinder? Moet het high-performance worden(zoals C++) of wil je veel flexibiliteit(zoals .Net(C#, VB.NET etc)) etc etc...

Een taal op zich heeft weinig met performance te maken. Het is nog altijd de compiler die de uiteindelijke machinecode moet produceren. Het is wel zo dat als de taal dichter bij de target architectuur zit, de programmeur in het algemeen meer controle heeft over de geproduceerde code en dat de compiler in het algemeen gemakkelijker efficientere code kan produceren.

Travelan schreef op maandag 23 juni 2008 @ 18:50:
Wat mis je nu in je favoriete programmeertaal?

In de taal Haskell zelf mis ik weinig. De dingen die ik mis hebben vooral te maken met de beschikbaarheid van libraries (maar daar wordt hard aangewerkt).

In andere talen, zoals Java, mis ik voornamelijk de expressiviteit van Haskell. List comprehensions en higher order functions zonder al te veel syntactic noise = pluspunt.

Het is wel de bedoeling dat het een industriële programmeertaal wordt.

Wat versta je precies onder een industriele programmeertaal?

(redelijk simpel te leren,

Simpel te leren voor wie? Mensen die nog nooit geprogrammeerd hebben? Mensen die al een kunnen programmeren in een imperatieve taal? Mensen met of zonder wiskundige achtergrond?

gericht op het echt ontwerpen van programma's, in tegenstelling tot het ontwerpen van algoritmes en bewijstheorie)

De geschiktheid van het ontwerpen van programma's hangt denk ik sterk af van de kwaliteit van je standaard library en het gemak om nieuwe libraries te maken en het linken met al reeds beschikbare libraries geschreven in andere talen.

Als bijv. iemand een 3D applicatie wil bouwen, zorg er dan voor dat hij met OpenGL (of een of andere 3D lib) kan interfacen. Zorg dus o.a. voor dat je aan FFI denkt.

Voor mijn idee van lazy evaluation heb ik dat hier duidelijk uitgelegd: http://www.thinder.org/brainstorm/idea/3

Niet een heel sterk voorbeeld van lazy evaluation. Een beter voorbeeld is een waarin je laat zien dat je de ternaire operator van C zelf kunt implementeren als je taal lazy evaluation heeft.

[ Voor 0% gewijzigd door RayNbow op 23-06-2008 21:06 . Reden: typo fixed ]

[MSalters]

Simpel te leren is bij uitstek niet het kenmerk van een industriële progammeertijd. Natuurlijk wil je een taal die niet onnodig moeilijk is, en waarin programmeurs effectief zijn. Maar je hebt fundamentele trade-offs. In industriële programmeeromgevingen is het terugverdien rendement hoger, omdat er relatief veel grprogammeerd wordt. Een taal die iets moeilijker te leren is, maar daarna elke dag effectiever heeft dan de voorkeur. Daar staat een ad-hoc omgeving tegenover, waarin je misschien 1 probleem oplost met een bepaalde taal.

Voorbeeld: Als taal A 50% productiever is als taal B, maar 2 maanden leertijd extra kost, dan is A voordeliger voor wie meer dan 4 maanden met A gaat werken - dat zou 6 maanden in B kosten.

De discussie is echter grotendeels overbodig. Voor verreweg de meeste talen is de belangrijkste eigenschap dat ze begrepen worden. Bestaande talen hebben daar een onwaarschijnlijk voordeel. Een nieuwe taal is alleen relevant voor niches.

[Travelan]

RayNbow schreef op maandag 23 juni 2008 @ 20:08:
[...]

In de taal Haskell zelf mis ik weinig. De dingen die ik mis hebben vooral te maken met de beschikbaarheid van libraries (maar daar wordt hard aangewerkt).

In andere talen, zoals Java, mis ik voornamelijk de expressiviteit van Haskell. List comprehensions en higher order functions zonder al te veel syntact noise = pluspunt.

Heel mooi idee, persoonlijk vind ik list comprehensions ook erg fijn. Ik wil inderdaad ook zo min mogelijk "syntact noise", dat maakt het makkelijker leesbaar en netter, zodat het programmeren ook een stukje makkelijker is.

[...]

Wat versta je precies onder een industriele programmeertaal?

Staat tussen haakjes, nog even extra duidelijk omdat het nogal vaag is:
Gewoon een programmeertaal die gericht is op het maken van echt programma's. Geen programmeertaal waarmee je allerlei academische nonsense kan berekenen met minimale regels code. Ik wil natuurlijk geen doelgroep uitsluiten, maar de nadruk ligt dus meer op het gemakkelijk kunnen uitwerken van pseudocode dan op het gemakkelijk kunnen uitwerken van complexe wiskundige (bijv.) vraagstukken.

[...]

Simpel te leren voor wie? Mensen die nog nooit geprogrammeerd hebben? Mensen die al een kunnen programmeren in een imperatieve taal? Mensen met of zonder wiskundige achtergrond?

Ik bedoel hier meer dat een steile leercurve moet worden voorkomen (zoals Haskell dat wel heeft, maar dat is eigenlijk ook subjectief... ander onderwerp ).

[...]

Niet een heel sterk voorbeeld van lazy evaluation. Een beter voorbeeld is een waarin je laat zien dat je de ternaire operator van C zelf kunt implementeren als je taal lazy evaluation heeft.

Goed idee. Ik wilde in dit voorbeeldje de performance boost die je zou kunnen krijgen naar voren halen.

[ Voor 1% gewijzigd door een moderator op 24-06-2008 08:49 . Reden: normaal quoten is ook een vak. ]

[Onbekend]

Je moet een paar dingen van elkaar onderscheiden die wel belangrijk zijn:

De editor:
Deze moet gebruiksvriendelijk zijn. Ook moet deze logisch in elkaar zitten. Zorg ervoor dat als je grafische componenten op een form zet, dat ze gemakkelijk zijn uit te lijnen en de veranderen.
Ook moet je editor snel zijn, want steeds 2 seconden wachten nadat je van venster wisselt is niet leuk.
Nog een belangrijk punt is dat het handig is dat de editor meteen foute stukken code markeert zonder eerst proberen te compilen.

De programmeertaal:
Deze moet ook logisch opgebouwd zijn. Je vooraf ingebouwde functies moeten logische namen hebben en logisch werken.
De code zelf moet snel en eenvoudig te schrijven zijn.

De linker/compiler:
Deze moeten vlot werken, en het resultaat mag zeker geen traag programma zijn. (Denk ook over optimalisatie binnen een stuk code, en misschien zelfs nog de ondersteuning voor meerdere cores.)
Bij fouten in de programmacode waarbij het linken/compilen mislukt zijn gerichte foutmeldingen altijd handig. Niet de tekst van "Er is een fout gevonden.".

De debugger:
Een debugger je editor is echt van belang als je grote programma's gaat schrijven. Hierbij moet het programma zo gecompileerd worden waardoor je in de editor precies kan aangeven waar het programma zich bevindt. Ook de inhoud van variabelen bekijken is een must.

Voorlopig hou ik het hierbij, maar er is nog veel meer op te noemen waar je op moet letten en beter kan.

[Hydra]

Onbekend schreef op maandag 23 juni 2008 @ 21:12:
Je moet een paar dingen van elkaar onderscheiden die wel belangrijk zijn:

De editor:
Deze moet gebruiksvriendelijk zijn. Ook moet deze logisch in elkaar zitten. Zorg ervoor dat als je grafische componenten op een form zet, dat ze gemakkelijk zijn uit te lijnen en de veranderen.
Ook moet je editor snel zijn, want steeds 2 seconden wachten nadat je van venster wisselt is niet leuk.
Nog een belangrijk punt is dat het handig is dat de editor meteen foute stukken code markeert zonder eerst proberen te compilen.

Ik vind het vreemd dat je in je relaas eerst begint over de editor. Een editor staat compleet los van de taal. Daarnaast is de TS van plan een nieuwe 'taal' te maken, iets wat erg leuk is om te doen, maar ik denk niet dat de TS ooit aan een editor toe gaat komen.

De programmeertaal:
Deze moet ook logisch opgebouwd zijn. Je vooraf ingebouwde functies moeten logische namen hebben en logisch werken.
De code zelf moet snel en eenvoudig te schrijven zijn.

Definieer 'logisch'? Wat voor een Haskell programmeur logisch is, is heel anders dan wat een Java programmeur logisch vindt. Het is niet voor niets dat Java en C# voor een groot deel de C++ syntax en vorm overgenomen hebben.

De linker/compiler:
Deze moeten vlot werken, en het resultaat mag zeker geen traag programma zijn. (Denk ook over optimalisatie binnen een stuk code, en misschien zelfs nog de ondersteuning voor meerdere cores.)
Bij fouten in de programmacode waarbij het linken/compilen mislukt zijn gerichte foutmeldingen altijd handig. Niet de tekst van "Er is een fout gevonden.".

Beetje een opsomming van 'ja duh' tips. Daarnaast is het eerst zaak een grammatica te ontwerpen die uberhaupt compileerbaar is. Je begint nu al de compiler te optimalizeren.

De debugger:
Een debugger je editor is echt van belang als je grote programma's gaat schrijven. Hierbij moet het programma zo gecompileerd worden waardoor je in de editor precies kan aangeven waar het programma zich bevindt. Ook de inhoud van variabelen bekijken is een must.

Zie punt 1.

[Onbekend]

De bruikbaarheid van de programmeertaal en de snelheid om er iets mee te schrijven zit grotendeels in de editor. Daarom begon ik er mee terwijl het niet werd gevraagd.

Aan jouw reactie te zien schrijf je je code in kladblok om vervolgens uren te zitten debuggen.

[Hydra]

Onbekend schreef op maandag 23 juni 2008 @ 21:41:
De bruikbaarheid van de programmeertaal en de snelheid om er iets mee te schrijven zit grotendeels in de editor. Daarom begon ik er mee terwijl het niet werd gevraagd.

De editor heeft niks met de taal te maken.

Aan jouw reactie te zien schrijf je je code in kladblok om vervolgens uren te zitten debuggen.

Als je altijd onzin uit stukjes tekst haalt, lijkt me functioneren in het bedrijfsleven erg lastig.

[Travelan]

Ontopic please...

Ik ben absoluut niet van plan een editor te maken.
Een fatsoenlijke editor met syntax highlighting is meer dan voldoende lijkt me.

Het gaat inderdaad puur om de taal, en alles er omheen is van latere zorg.

[Gomez12]

Onbekend schreef op maandag 23 juni 2008 @ 21:41:
De bruikbaarheid van de programmeertaal en de snelheid om er iets mee te schrijven zit grotendeels in de editor. Daarom begon ik er mee terwijl het niet werd gevraagd.

Sorry?
Bij mij is het ongeveer 74% parate kennis, 25% opzoekwerk en misschien 1% editor en dan heb ik het alleen nog maar over de syntax.
Business logica heb ik in nog geen enkele editor gezien, algoritmen helpen maken heb ik in nog geen enkele editor gezien.
Bij het code-kloppen is een goede editor handig, maar al het denkwerk wat vooraf gaat aan het kloppen daar helpt geen editor mij bij hoor...

Als ik vanwege business logica moet controleren of y en z wel goed zijn als ik x verander dan helpt mij geen enkele editor hoor?

Aan jouw reactie te zien schrijf je je code in kladblok om vervolgens uren te zitten debuggen.

Grote grap, zo af en toe bij klanten code ik inderdaad in kladblok, debuggen duurt dan geen uren hoor, moet alleen iets meer checkpoints inbouwen.
Ik vind het onhandiger dan op mijn werkplek waar ik de msdn site zo kan aanroepen, de help zo kan aanroepen en de laatste nieuwtjes kan lezen.
Maar uuuuren langer, nee hoor. Grootste gedeelte van mijn tijd zit toch in het uitdenken / implementeren / opzetten en daar help geen editor mij bij hoor...

[RayNbow]

Ik wil toch nog even inhaken op het editor-gebeuren (sorry ).

Een editor kan belangrijk zijn voor een taal. De focus op de editor zie je voornamelijk bij het ontwerpen van DSLs (zie bijv. MS DSL Tools, openArchitectureWare, etc.). Zo'n editor is al helemaal niet weg te denken als het gaat om een grafische taal.

Echter, in het geval van de taal die de TS wil ontwerpen is zo'n editor een bijzaak. De taal is tekstueel en de focus ligt voornamelijk op het ontwerpen van de taal zelf (lexicaal, syntactisch, semantisch). Dus, zoals de TS ook aangeeft, welke features horen er in een nieuwe taal thuis?

(Een mooie editor/plugin/etc voor de taal kan altijd nog later gebouwd worden)

[MSalters]

Tja, zelfs de aanname dat een taal tekstueel moet zijn is geen harde noodzaak. Zoals Onbekend al meldde, een form design wil je niet tekstueel hebben.

Het grote manceo van de TS is een gebrek aan een doel. De taal is maar een middel.

[Arjan]

Wat ik interessant zou vinden zijn (virtual) inheritance en de mogelijkheid om een function pointer naar een member functie te kunnen gebruiken.

in c++ achtige syntax

C++:

class Dier {
    virtual void maakGeluid();
};

class Aap: public Dier {
    void maakGeluid();
};

class Gnoe: public Dier {
    void maakGeluid();
};

typedef void (*callBack)(void);

// het volgende zou dus geldig moeten zijn

int main() {

    Dier blaat;
    Aap aapje;
    Gnoe gnoedier;

    callBack eenGeluid;

    eenGeluid = blaat.maakGeluid;

    eenGeluid();

    eenGeluid = aapje.maakGeluid;

    eenGeluid();

    eenGeluid = gnoedier.maakGeluid;

    eenGeluid();

    return 0;
}

Wat ook erg mooi zou zijn als je dit kan combineren met default parameters en static members

[Johnny]

In je rapport zie ik in paragraaf 3.2.1 staan dat de goto statement een belangrijk onderdeel is van je taal. Iedereen die een taal ontwerpt is toch wel bekend met brief van Edgar Dijkstra http://en.wikipedia.org/w...ement Considered Harmful" uit 1968?

Wat ik vand Thinder zelf vind? Over het algemeen gaat mijn voorkeur niet uit naar low-level gecompileerde talen, zelf heb ik een voorkeur voor weaky typed geintepreteerde talen.

Het lijkt wel erg veel op C, maar biedt het ook voordelen? In het rapport wordt in paragraaf 7.3 wel een garbage collector genoemd, maar is die een onderdeel van de taal of moet de programmeur geheugenmanagement doen? Ik zie nergens iets over pointers.

Ook hebje het over een "sterk object geörienteerd karakter" terwijl er wel diverse primitieve types worden gebruikt, dat is iets wat ik ook niet fijn vind aan Java. Hoewel het misschien een goed idee is voor performance en programmeurs die al bekend zijn met low-level talen maakt het je taal wel complexer en lastiger te leren voor beginners en breekt het ook het hele concept van OO omdat de meestgebruikte types opeens niet meer de flexibliteit van objecten hebben. Verder mis ik ook nog het een type voor double precision getallen.

Ook heb je het over getters en setters functies in paragraaf 8.2, maar ik kan me daar echt niks bij voorstellen. In andere programmeertalen worden ze gebruikt om private variabelen te wrappen in een publieke functie van een object. Jij wilt ze echter gebruiken voor typecasting van objecten, kan je daar een voorbeeld van geven want ik snap niet waarom en hoe je alle mogelijke soorten objecten naar alle andere mogelijke soorten kan objecten casten.

Verder kan ik het boek Concepts of Programming Languages aanraden voor iedereen die een eigen taal wil schrijven.

[Travelan]

Arjan schreef op maandag 23 juni 2008 @ 22:21:
Wat ik interessant zou vinden zijn (virtual) inheritance en de mogelijkheid om een function pointer naar een member functie te kunnen gebruiken.

in c++ achtige syntax

C++:

class Dier {
    virtual void maakGeluid();
};

class Aap: public Dier {
    void maakGeluid();
};

class Gnoe: public Dier {
    void maakGeluid();
};

typedef void (*callBack)(void);

// het volgende zou dus geldig moeten zijn

int main() {

    Dier blaat;
    Aap aapje;
    Gnoe gnoedier;

    callBack eenGeluid;

    eenGeluid = blaat.maakGeluid;

    eenGeluid();

    eenGeluid = aapje.maakGeluid;

    eenGeluid();

    eenGeluid = gnoedier.maakGeluid;

    eenGeluid();

    return 0;
}

Wat ook erg mooi zou zijn als je dit kan combineren met default parameters en static members

Zoals je kan lezen in het specification report op de site heb ik dit er al gedeeltelijk in zitten. Functies worden beschouwd als object, en je kunt ze dus ook als object rondgooien.
In principe was het allereerste idee, wat de aanleiding was tot dit project, een functionele imperatieve taal.

[RayNbow]

MSalters schreef op maandag 23 juni 2008 @ 22:20:
Tja, zelfs de aanname dat een taal tekstueel moet zijn is geen harde noodzaak. Zoals Onbekend al meldde, een form design wil je niet tekstueel hebben.

Form design wil je meestal niet tekstueel hebben omdat de syntax van de general purpose language niet overeenkomt met de structuur van je GUI (zie slides 3-6 van deze presentatie).
Een grafische taal (GUI editor) of een tekstuele domein-specifieke taal (slides 8-10) zijn dan geschikter.

[.oisyn]

Arjan schreef op maandag 23 juni 2008 @ 22:21:
Wat ik interessant zou vinden zijn (virtual) inheritance en de mogelijkheid om een function pointer naar een member functie te kunnen gebruiken.

Wat al kan in C++. Zowel een pointer-naar-member, als een functie object waarbij het niet uitmaakt of hij naar een gewone of member-functie wijst (zie std::tr1::function en std::tr1::bind). Wat C++ dan weer wel mist is syntax om van een "object.method" meteen een gebinde tr1::function te maken. Dit werkt wat onhandig:

C++:

using namespace std::tr1;
typedef function<void ()> callback;
Dier blaat;
callback = bind(&Dier::maakGeluid, &blaat);  // callback = blaat.maakGeluid;
callback();

[ Voor 3% gewijzigd door .oisyn op 23-06-2008 22:46 ]

[RobIII]

Overigens...

quote: http://www.thinder.org/language

Why a new programming language?
C++ already is 25 years old. Java and C# are proprietary and do not compile to machine code. PHP is aimed at hypertext. Haskell is pure functional. What language is designed for both speed and usability the programmers need today?
Okay, this is a little bit exaggerated, but it is how many of us feel. We do not have the programming language that is as powerful as, say, C++ and still anticipates today's pogrammer's needs.

je bent bekend met deze en deze? Daarbij is het feit dat C++ "25 years old"* is juist (in mijn ogen) een goed teken; het heeft zich gevestigd en bewezen en still going strong. Daarbij zou ik graag een bron zien van je bewering "but it is how many of us feel". Ik heb er namelijk niet echt notie van in mijn omgeving.

* Dat is dus maar net hoe je het ziet; je kunt het ook "al" 29 jaar "oud" noemen, of "pas" 10 jaar "oud".

[ Voor 28% gewijzigd door RobIII op 23-06-2008 22:54 ]

[H!GHGuY]

Ik denk dat je met een taal waarin je parallelliteit kan uitdrukken al een grote markt bedient.

Huidige talen halen veel van hun parallelliteit uit add-ons; Zo heeft C++ OpenMP, .NET-talen hebben de parallel extensions, van Java heb ik eigenlijk geen idee.
Haskell was dacht ik natively multi-thread/core capable maar die is danweer niet echt object-oriented.

Eerder denk ik aan een taal waarin men deze dingen tot expressie kan brengen. Onze beste Herb Sutter was geloof ik binnen MS bezig met een proof-of-concept.

Enkele pseudo-code voorbeelden:

code:

active class MyClass
{
  return_type function(parameter_type pt); // automatisch gescheduled op de owning thread.
}
locked struct MyStruct
{
  // velden worden auto interlocked of via een lock geaccessed.
  // compiler genereert fouten als een niet-locked struct tussen threads gepassed wordt.
}
// pointers zijn refcounting, thread-safe en geven ook fouten als er niet-thread-safe dingen met de pointee gedaan kunnen worden

Een ander idee is een compiler die goed gedesigned code verwacht/vereist.
Denk bvb aan toepassen van de Law of Demeter en hierarchisch opdelen van een applicatie waarbij caller en callee in een structuur te gieten vallen zoals bij locking-order checking. Enkel van boven naar beneden calls uitvoeren, niet van beneden naar boven in de hierarchische structuur, tenzij via een welgedefinieerde manier. enzovoorts.

Dit zou je zelfs als een add-on (compile-pass) op een huidige taal kunnen maken.
Je gaat bvb over de parse-tree van de code en verifieert of alle condities voldaan zijn. Probleem is natuurlijk dat dit eerder tijdens de linking-stap zal moeten aangezien je heel veel moet weten. (In een taal als C# zal dat dan bvb ook gemakkelijker gaan aangezien er daar geen geklooi is met bvb includes, compilation units etc.

Het zijn maar enkele ideetjes van verbeteringen.

[.oisyn]

Multi-dispatch zou trouwens ook wel een coole feature zijn.

[Verwijderd]

Kijk ook eens naar "D Programming Language"
http://www.digitalmars.com/d/

Ik weet alleen niet hoe serieus dat project is, ze werken voor wat ik weet niet naar standarisatie toe?

[Johnny]

RayNbow schreef op maandag 23 juni 2008 @ 22:33:
[...]

Form design wil je meestal niet tekstueel hebben omdat de syntax van de general purpose language niet overeenkomt met de structuur van je GUI (zie slides 3-6 van deze presentatie).
Een grafische taal (GUI editor) of een tekstuele domein-specifieke taal (slides 8-10) zijn dan geschikter.

Ik vind de Swul aanpak in de presentatie vrij ranzig: code van een domein specifieke taal te embedden binnen de code binnen andere code. Een formulier of andere soort WIMP GUI kan je veel beter beschouwen als een document, oftewel data welke je buiten je code in apart plaatst net zoals in HTML of zoals Apple dat doet met Interface Builder waarbij de user interface gewoon een XML-bestand is.

Maar even ontopic, ik zag net dat de arrays fixed length zijn, dat vind ik altijd zo onhandig. In Java is dat ook zo, en uiteindelijk gebruik je alleen nog maar ArrrayLists omdat de standaard Array niet voldoet.

[Travelan]

H!GHGuY schreef op maandag 23 juni 2008 @ 22:49:
Ik denk dat je met een taal waarin je parallelliteit kan uitdrukken al een grote markt bedient.

Huidige talen halen veel van hun parallelliteit uit add-ons; Zo heeft C++ OpenMP, .NET-talen hebben de parallel extensions, van Java heb ik eigenlijk geen idee.
Haskell was dacht ik natively multi-thread/core capable maar die is danweer niet echt object-oriented.

Thanks, ik neem het mee. Ik dacht dat java dit standaard al deed (in elk geval multithreading)..

Er staat een hele hoop niet in het specification report, dus het kan kloppen dat ik het over bepaalde dingen niet heb.

Een hele goede opmerking van Johnny trouwens. Hier moet ik nog maar eens diep over nadenken. Het is echter wel zo dat ik zo min mogelijk spul er in stop wat duidelijk de performance naar beneden haalt. Wat mijn eerste oplossing hier zou zijn is om de primitieve objecten (naast alleen de types) op magische wijze te implementeren.
Johnny: ik heb 2 lijst objecten in het pdfje staan: lists en arrays. Alleen heb ik nog niet duidelijk uitgelegd wat lists zijn, in tegenstelling tot arrays.
Een array is per definitie eindig, een list niet. Het grote voordeel van een array is dat je de objecten die er in zitten in constante tijd kan opvragen. In een (linked) list is dat lineair.

[ Voor 3% gewijzigd door Travelan op 23-06-2008 23:13 ]

[Hydra]

Johnny schreef op maandag 23 juni 2008 @ 22:59:
Maar even ontopic, ik zag net dat de arrays fixed length zijn, dat vind ik altijd zo onhandig. In Java is dat ook zo, en uiteindelijk gebruik je alleen nog maar ArrrayLists omdat de standaard Array niet voldoet.

Tja, aan de andere kant dwingt je dat wel een bewuste keuze te maken tussen een array en een list. Arrays gebruik je typisch voor collections van 1 type met een vaste grootte, maar dit is eigenlijk net zo'n discussie als dynamisch vs. statisch getypeerde talen; voor beiden zijn argumenten aan te dragen, en uiteindelijk is het een kwestie van smaak.

Travelan schreef op maandag 23 juni 2008 @ 23:08:
Een array is per definitie eindig, een list niet. Het grote voordeel van een array is dat je de objecten die er in zitten in constante tijd kan opvragen. In een (linked) list is dat lineair.

Ik kan me niet voorstellen dat je in je collections API alleen maar linked lists aan wilt bieden, je wilt sowieso verschillende implementaties bieden en de default collection voor lijsten in Java en .Net is toch de ArrayList.

[ Voor 28% gewijzigd door Hydra op 23-06-2008 23:24 ]

[Travelan]

Hydra schreef op maandag 23 juni 2008 @ 23:21:
Ik kan me niet voorstellen dat je in je collections API alleen maar linked lists aan wilt bieden, je wilt sowieso verschillende implementaties bieden en de default collection voor lijsten in Java en .Net is toch de ArrayList.

Uiteraard, maar de scheiding lijsten en arrays is gewoon zo. Andere types zullen natuurlijk ook aangeboden worden (stack en queue als onderdeel van dequeue, maps, dictonaries, incl. hashtables, etc).

[Johnny]

In de topicstart zeg je dat je een industrieële taal wilt die makkelijk te leren is en waarbij de nadruk niet op algoritmes ligt, maar je stelt de gebruiker wel bloot aan allerlei low-level dingen ten ten behoeve van performance. Andere moderne industrieële talen zoals Java en C# doen dat minder en draaien binnen een virtuele machine en draaien daar bijna even snel, soms zelfs sneller door automatische optimalisatie van de code door techieken zoals JIT-compilatie. Maar ook een taal zoals bijvoorbeeld Scheme is soms sneller dan C omdat een compiler (vooral op huidige processors) beter kan optimaliseren dan 99.9% van de menselijke programmeurs. Je moet dus niet bang zijn om hogere functies weg te laten ten bate van een vermeende performance hit, je kan je compiler altijd nog optimaliseren. Als je het ontwerp van de taal laat lijden daaronder dan maak je zoiets als Cobol of Basic wat na enkele jaren verouderd is terwijl andere talen uit de jare 60 zoals Lisp, Scheme en Smalltalk nog wel enigsinds relevant zijn.

Ik bedacht me net ook nog, als je een industrieële taal wilt, dan moet er eigenlijk ook een Decimal type moet hebben zodat je met getallen kan werken zonder afrondingsfouten. Ook zou ik er voor kiezen om geen ASCII strings toe staan en enkel unicode te gebruiken net zoals Java dat doet. Je haalt je hiermee namelijk allerlei problemen op de hals omdat bijvoorbeeld libraries unicode gebruiken en de programmeur ASCII.

[Travelan]

Johnny schreef op maandag 23 juni 2008 @ 23:58:
In de topicstart zeg je dat je een industrieële taal wilt die makkelijk te leren is en waarbij de nadruk niet op algoritmes ligt, maar je stelt de gebruiker wel bloot aan allerlei low-level dingen ten ten behoeve van performance. Andere moderne industrieële talen zoals Java en C# doen dat minder en draaien binnen een virtuele machine en draaien daar bijna even snel, soms zelfs sneller door dautomatische optimalisatie van de code door techieken zoals JIT-compilatie. Maar ook een taal zoals bijvoorbeeld Scheme is soms sneller dan C omdat een compiler (vooral op huidige processors) beter kan optimaliseren dan 99.9% van de menselijke programmeurs. Je moet dus niet bang zijn om hogere functies weg te laten ten bate van een vermeende performance hit, je kan je compiler altijd nog optimaliseren. Als je het ontwerp van de taal laat lijden daaronder dan maak je zoiets als Cobol of Basic wat na enkele jaren verouderd is terwijl andere talen uit de jare 60 zoals Lisp, Scheme en Smalltalk nog wel enigsinds relevant zijn.

Oke thanks, zal het onthouden

Johnny schreef op maandag 23 juni 2008 @ 23:58:
Ik bedacht me net ook nog, als je een industrieële taal wilt, dan moet er eigenlijk ook een Decimal type moet hebben zodat je met getallen kan werken zonder afrondingsfouten. Ook zou ik er voor kiezen om geen ASCII strings toe staan en enkel unicode te gebruiken net zoals Java dat doet. Je haalt je hiermee namelijk allerlei problemen op de hals omdat bijvoorbeeld libraries unicode gebruiken en de programmeur ASCII.

Ik zat zelf te denken om het (omdat unicode en ascii chars 2 verschillende types zijn) op een heel laag level te converteren. Dan heb je dus ook geen problemen tussen ascii en unicode.
Ik ben benieuwd wat ik hier over het hoofd zie...

[RayNbow]

H!GHGuY schreef op maandag 23 juni 2008 @ 22:49:
Ik denk dat je met een taal waarin je parallelliteit kan uitdrukken al een grote markt bedient.

Huidige talen halen veel van hun parallelliteit uit add-ons; Zo heeft C++ OpenMP, .NET-talen hebben de parallel extensions, van Java heb ik eigenlijk geen idee.
Haskell was dacht ik natively multi-thread/core capable maar die is danweer niet echt object-oriented.

Haskell ondersteunt het niet natively, maar heeft wel een goede combinator library waarmee je code kunt annoteren (met par en pseq). Hier is een voorbeeld uit het Real World Haskell boek:

Haskell:

sort :: (Ord a) => [a] -> [a]
sort (x:xs) = lesser ++ x:greater
    where lesser  = sort [y | y <- xs, y <  x]
          greater = sort [y | y <- xs, y >= x]
sort _ = []

Met paralelle combinatoren:

Haskell:

parSort :: (Ord a) => [a] -> [a]
parSort (x:xs)    = force greater `par` (force lesser `pseq`
                                         (lesser ++ x:greater))
    where lesser  = parSort [y | y <- xs, y <  x]
          greater = parSort [y | y <- xs, y >= x]
parSort _         = []

Voor uitleg verwijs ik naar de beta-versie van hoofdstuk 26.

Dit zou je zelfs als een add-on (compile-pass) op een huidige taal kunnen maken.
Je gaat bvb over de parse-tree van de code en verifieert of alle condities voldaan zijn.

In Java kan je al min of meer extra compile-passes doen, maar dit werkt alleen op annotaties met behulp van Java's APT of het uitgebreidere Spoon framework (waarvan de site down is, handig als je ernaar wilt linken). Met het Spoon framework kon je in ieder geval checks uitvoeren op het gebruik van annotaties en je kon code genereren/vervangen/etc.

Johnny schreef op maandag 23 juni 2008 @ 22:59:
[...]

Ik vind de Swul aanpak in de presentatie vrij ranzig: code van een domein specifieke taal te embedden binnen de code binnen andere code.

Het wel of niet embedden van een DSL in de general purpose is waarschijnlijk een kwestie van smaak. Van mij mag je het ook in een aparte file stoppen. Het ging me alleen om dat een tekstuele taal wel geschikt kan zijn om een GUI in te programmeren.

[Johnny]

Travelan schreef op dinsdag 24 juni 2008 @ 00:13:
Ik zat zelf te denken om het (omdat unicode en ascii chars 2 verschillende types zijn) op een heel laag level te converteren. Dan heb je dus ook geen problemen tussen ascii en unicode.
Ik ben benieuwd wat ik hier over het hoofd zie...

Bij unicode neem ik aan dat je UTF-8 gebruikt? Dat is een superset van ASCII, maar hoe wil je UTF-8 naar ASCII converteren? Sommige talen doen dit door alle onbekende karakters te vervangen met een ? (vraagteken) waarmee je dus informatie weggooit en je data onherstelbaar beschadigd raakt. Als je intern UTF-8 gebruikt dan heeft het weinig zin om nog ASCII te gebruiken omdat het alleen maar complexiteit voor de gebruiker toevoegd.

[Verwijderd]

Johnny schreef op dinsdag 24 juni 2008 @ 00:34:
[...]

Bij unicode neem ik aan dat je UTF-8 gebruikt? Dat is een superset van ASCII, maar hoe wil je UTF-8 naar ASCII converteren? Sommige talen doen dit door alle onbekende karakters te vervangen met een ? (vraagteken) waarmee je dus informatie weggooit en je data onherstelbaar beschadigd raakt. Als je intern UTF-8 gebruikt dan heeft het weinig zin om nog ASCII te gebruiken omdat het alleen maar complexiteit voor de gebruiker toevoegd.

Ik wil, in het kader van performance(unicode gebruikt 2 keer zoveel geheugen) en compatibility, ASCII niet uitsluiten. Als ik ASCII niet zou ondersteunen zouden er ook sneller problemen opdoen met libraries. Wel lijkt het me inderdaad een goed idee om unicode(UTF-8 ja) char's standaard te maken (dus char en uchar = unicode, achar = ascii).

Ik ben aan het kijken naar parallelliteit, daar zie ik wel wat in. Vanmiddag/avond maar eens even in parallelliteit voor assembly duiken.

[Hydra]

Travelan schreef op maandag 23 juni 2008 @ 23:55:
Uiteraard, maar de scheiding lijsten en arrays is gewoon zo. Andere types zullen natuurlijk ook aangeboden worden (stack en queue als onderdeel van dequeue, maps, dictonaries, incl. hashtables, etc).

Hoe bedoel je, "is gewoon zo"? Je collection interfaces moeten los staan van de daadwerkelijke implementaties. En IMHO is het helemaal niet verstandig om je te focussen op Linked Lists.

[Janoz]

Die scheiding kwam mij ook nogal vreemd over. Nergens wordt daadwerkelijk het verschil aangegeven, laat staan verdedigd. Alleen als je doorleest staat ergens iets over fixed length, maar dat is IMHO geen verdediging om een compleet aparte taal structure te introduceren.

[Janoz]

Iets anders.

C++ already is 25 years old. Java and C# are proprietary and do not compile to machine code. PHP is aimed at hypertext. Haskell is pure functional. What language is designed for both speed and usability the programmers need today?

Dat Java en C# niet naar machine code compileren noem je als enig nadeel van die talen. Op wat voor manier lost thinder dat op? Als ik alleen al naar de aanwezige constanten kijk dan is thinder niet meer dan een geinterpreteerd taaltje.

Verder heeft de beperking dat Java en C# niet naar machine code compileren helemaal niks met de taal te maken, maar met het platform. Je zou keurig een compiler kunnen maken die beide talen naar machinecode kunnen compileren. Waarom zou dit probleem opgelost worden door een nieuwe taal te bedenken?


--edit---

Nog iets. In je wervende woorden geef je als groot voordeel aan dat alles een object is. Waarom staat er in de specificaties dan vervolgens nog wel een heel hoofdstuk over primitieve types?

[ Voor 11% gewijzigd door Janoz op 24-06-2008 09:55 ]

[djluc]

Ik snap niet waarom je een nieuwe taal gaat ontwikkelen. Je hebt totaal geen visie, geen ding om te verbeteren of wat dan ook.

Wat mij betreft moet je eerst 4 stappen terug. Voordat je moet gaan nadenken over de echte implementatie moet je eerst je visie eens duidelijk krijgen. Zodra je die duidelijk hebt doe je een concurrentie-analyse: Dat houdt in dat je een report schrijft over de bestaande talen. Hoe verhouden zij zich ten opzichte van jouw visie?

Pas dan heeft het nut om eens na te gaan denken of het wellicht interessant is om een nieuwe taal e gaan schrijven.

[Johnny]

Verwijderd schreef op dinsdag 24 juni 2008 @ 09:25:
[...]

Ik wil, in het kader van performance(unicode gebruikt 2 keer zoveel geheugen) en compatibility, ASCII niet uitsluiten. Als ik ASCII niet zou ondersteunen zouden er ook sneller problemen opdoen met libraries. Wel lijkt het me inderdaad een goed idee om unicode(UTF-8 ja) char's standaard te maken (dus char en uchar = unicode, achar = ascii).

UFT-8 is net als ASCII 8 bits per karakter (vandaar die , alleen non-ASCII tekens nemen 2 bytes in. Bij UTF-16 neemt ieder karakter 16 bits in.

The Absolute Minimum Every Software Developer Absolutely, Positively Must Know About Unicode and Character Sets (No Excuses!)

Het geheugengebruik is dus geen probleem, maar omdat de tekens een variable lengte hebben zijn andere dingen zoals het berekenen van de lengte lastiger. Maar UTF-8 hoeft nauwelijks langzamer te zijn dan ASCII, hier wordt bijvoorbeeld het tellen van het aantal UTF-8 karakters besproken: http://www.daemonology.ne...5-faster-utf8-strlen.html Het laat ook meteen zien dat een hogere taal zoals C sneller kan zijn dan Assembly omdat het makkelijker is om de compiler de code te laten optimaliseren voor moderne processors.

[Confusion]

@topicstarter: lees eens een tijdje in http://www.artima.com/weblogs/index.jsp?blogger=cdiggins. Subtitel: ruminations of a language designer. Zie ook diverse comments op zijn diverse vragen. Dat is iemand die al een tijdje heel weloverwogen bezig is met hetgeen waar jij je nu in wilt storten.

Johnny schreef op dinsdag 24 juni 2008 @ 10:31:
UFT-8 is net als ASCII 8 bits per karakter (vandaar die , alleen non-ASCII tekens nemen 2 bytes in. Bij UTF-16 neemt ieder karakter 16 bits in.

Uit je eigen link

In UTF-8, every code point from 0-127 is stored in a single byte. Only code points 128 and above are stored using 2, 3, in fact, up to 6 bytes.

[ Voor 25% gewijzigd door Confusion op 24-06-2008 10:49 ]

[Travelan]

Janoz schreef op dinsdag 24 juni 2008 @ 09:54:
Iets anders.


[...]


Dat Java en C# niet naar machine code compileren noem je als enig nadeel van die talen. Op wat voor manier lost thinder dat op? Als ik alleen al naar de aanwezige constanten kijk dan is thinder niet meer dan een geinterpreteerd taaltje.

Door wel naar machine code te compileren? Ik snap niet waar je de wijsheid vandaan haalt dat Thinder niet meer dan een geinterpreteerd taaltje. Tot nu toe is er alleen nog maar een heel erg klein deel van de specificaties beschikbaar, en dan gaat het alleen om de taal. Nergens wordt gezegd dat Thinder geinterpreteerd gaat worden.

Verder heeft de beperking dat Java en C# niet naar machine code compileren helemaal niks met de taal te maken, maar met het platform. Je zou keurig een compiler kunnen maken die beide talen naar machinecode kunnen compileren. Waarom zou dit probleem opgelost worden door een nieuwe taal te bedenken?

Omdat de taal gericht word op een machne code COMPILER. Low level features die niet geinterpreteerd kunnen worden (althans, niet met de voordelen van machine code) zijn dan een optie.[

--edit---

Nog iets. In je wervende woorden geef je als groot voordeel aan dat alles een object is. Waarom staat er in de specificaties dan vervolgens nog wel een heel hoofdstuk over primitieve types?

Als je als moderator zijnde een thread eerst doorleest zou je gezien hebben dat hier al het een en ander over gepost is. Dit is iderdaad een goed punt, en hier moet ik een oplossing voor vinden. Echter, om alles low level te kunnen houden kan ik ze er niet uit slopen. Zelf zit ik te denken aan een implementatie op magische wijze van primaire objecten.

[ Voor 1% gewijzigd door een moderator op 24-06-2008 11:29 . Reden: [b] tags vervangen door [/] en [/b] tags vervanngen door [quote] ]

[Travelan]

Johnny schreef op dinsdag 24 juni 2008 @ 10:31:
[...]


UFT-8 is net als ASCII 8 bits per karakter (vandaar die , alleen non-ASCII tekens nemen 2 bytes in. Bij UTF-16 neemt ieder karakter 16 bits in.

The Absolute Minimum Every Software Developer Absolutely, Positively Must Know About Unicode and Character Sets (No Excuses!)

Het geheugengebruik is dus geen probleem, maar omdat de tekens een variable lengte hebben zijn andere dingen zoals het berekenen van de lengte lastiger. Maar UTF-8 hoeft nauwelijks langzamer te zijn dan ASCII, hier wordt bijvoorbeeld het tellen van het aantal UTF-8 karakters besproken: http://www.daemonology.ne...5-faster-utf8-strlen.html Het laat ook meteen zien dat een hogere taal zoals C sneller kan zijn dan Assembly omdat het makkelijker is om de compiler de code te laten optimaliseren voor moderne processors.

Ah thanks! Dit is handig. Ik ga ze er toch niet uit slopen, want als je ze zou willen gebruiken, moet dat kunnen. Unicode (wss UTF-8 dus) wordt wel standaard.

[RobIII]

Travelan schreef op dinsdag 24 juni 2008 @ 11:09:
[...]

Ah thanks! Dit is handig. Ik ga ze er toch niet uit slopen, want als je ze zou willen gebruiken, moet dat kunnen. Unicode (wss UTF-8 dus) wordt wel standaard.

Unicode != UTF-8
Unicode is een character set, UTF-8 is een encoding. Heb je het (overigens wel goede) artikel überhaupt gelezen? Iets waar je ons wel van beticht, maar vervolgens zelf schuldig aan maakt.

Travelan schreef op dinsdag 24 juni 2008 @ 11:08:
[...]
Als je als moderator zijnde een thread eerst doorleest zou je gezien hebben dat hier al het een en ander over gepost is. Dit is iderdaad een goed punt, en hier moet ik een oplossing voor vinden. Echter, om alles low level te kunnen houden kan ik ze er niet uit slopen. Zelf zit ik te denken aan een implementatie op magische wijze van primaire objecten.

Implementatie op magische wijze? Je roept eerst dat alles een object is en dan toch weer (een beetje) niet. En dat gaat de taal op magische wijze oplossen? En dat is niet verwarrend?

P.s. Wil je proberen die irritante manier van quoten achterwege te laten? Op jouw manier is het helemaal lastig om je te quoten en daarbij leest die bold tekst hoogst irritant.

[ Voor 73% gewijzigd door RobIII op 24-06-2008 11:29 ]

[Janoz]

Als eerste wil ik je adviseren om te quoten door de quote tags te gebruiken ipv de bold tag. Dat maakt het reageren op je reacties een stuk makkelijker en maat het ook een stuk leesbaarder. Eerder in dit topic ben je hier al op gewezen..

k snap niet waar je de wijsheid vandaan haalt dat Thinder niet meer dan een geinterpreteerd taaltje.

Waar ik de wijsheid vandaan haal geef ik aan. Constantes als __filename__ en __path__ lijken me typisch dingen die je @runtime bepaald en zie je eigenlijk alleen terug in geinterpreteerde talen. Daarnaast stap je volledig over het punt heen waarom je een nieuwe taal wilt ontwikkelen terwijl je de nadelen van een ander platform noemt. Ik kan me dan ook alleen maar bij djluc aansluiten wanneer hij zegt dat je eigenlijk weer 4 stappen terug moet. Ik heb nog geen enkel steekhoudend argument gezien waarom er een nieuwe taal zou moet komen.

Omdat de taal gericht word op een machne code COMPILER

Waar word beschreven welke voordelen je daaruit haalt? Welke constructies in bijvoorbeeld C#, C++ of Java geven die beperkingen die door deze nieuwe taal weggenomen worden?

Echter, om alles low level te kunnen houden kan ik ze er niet uit slopen.

Dus het hele stuk over 'alles is een object en dat maakt deze taal super handig' is complete onzin? Een beetje AnimalFarm als je het mij vraagt. Everything is an Object, but some are less Object then others....


Ik zie dus nog wel redelijk wat fundamentele fouten danwel onduidelijkheden in de verdediging en specificaties. Het lijkt me dat je eerder deze punten aan kunt pakken. Dingen als een editor, debugger of zelfs character encoding lijken mij volledig niet relevant in dit stadium. Als je uberhaupt over 'tooling' zou willen kletsen dan lijkt de enige tool waar je daadwerkelijk over zou moeten kletsen de compiler zijn. Vooral omdat deze taal schijnbaar erg goed naar machinecode om te zetten zou moeten zijn lijkt me dat een erg interessant onderdeel. Ik ben wel benieuwd naar waar nu die winst te behalen is.

[Confusion]

Travelan schreef op maandag 23 juni 2008 @ 18:50:
Wel zit ik er aan te denken om geintjes uit functionele programmeertalen zoals lazy evaluation toe te passen.

Hoe verhoudt zich dit tot lambda in Python en closures in javascript?

[Travelan]

Janoz schreef op dinsdag 24 juni 2008 @ 11:25:
Als eerste wil ik je adviseren om te quoten door de quote tags te gebruiken ipv de bold tag. Dat maakt het reageren op je reacties een stuk makkelijker en maat het ook een stuk leesbaarder. Eerder in dit topic ben je hier al op gewezen..


[...]
Waar ik de wijsheid vandaan haal geef ik aan. Constantes als __filename__ en __path__ lijken me typisch dingen die je @runtime bepaald en zie je eigenlijk alleen terug in geinterpreteerde talen. Daarnaast stap je volledig over het punt heen waarom je een nieuwe taal wilt ontwikkelen terwijl je de nadelen van een ander platform noemt. Ik kan me dan ook alleen maar bij djluc aansluiten wanneer hij zegt dat je eigenlijk weer 4 stappen terug moet. Ik heb nog geen enkel steekhoudend argument gezien waarom er een nieuwe taal zou moet komen.

Dat is de preprocessor. Dat is per definitie een interpreter. http://en.wikipedia.org/wiki/Preprocessor

Ik heb naast dat het erg leuk is om te doen, nog wel meer redenen om dit project te starten. Ik mis bijvoorbeeld hele interessante functionele aspecten in pakweg alle imperatieve talen niet mogelijk zijn.

[...]

Waar word beschreven welke voordelen je daaruit haalt? Welke constructies in bijvoorbeeld C#, C++ of Java geven die beperkingen die door deze nieuwe taal weggenomen worden?

Hier staat al het een en ander over in het pdfje. Is inderdaad niet veel over te vinden, hier wil ik nog even de tijd voor nemen om goed uiteen te zetten.

[...]


Dus het hele stuk over 'alles is een object en dat maakt deze taal super handig' is complete onzin? Een beetje AnimalFarm als je het mij vraagt. Everything is an Object, but some are less Object then others....

Ik zie dus nog wel redelijk wat fundamentele fouten danwel onduidelijkheden in de verdediging en specificaties. Het lijkt me dat je eerder deze punten aan kunt pakken. Dingen als een editor, debugger of zelfs character encoding lijken mij volledig niet relevant in dit stadium. Als je uberhaupt over 'tooling' zou willen kletsen dan lijkt de enige tool waar je daadwerkelijk over zou moeten kletsen de compiler zijn. Vooral omdat deze taal schijnbaar erg goed naar machinecode om te zetten zou moeten zijn lijkt me dat een erg interessant onderdeel. Ik ben wel benieuwd naar waar nu die winst te behalen is.

Die discussie heb ik ook inderdaad afgekapt. Totaal irrelevant.

Modbreak:

Dit is de laatste keer dat je gewezen wordt op de manier van quoten en ook de laatste keer dat het voor je aangepast wordt!

[ Voor 4% gewijzigd door Janoz op 24-06-2008 11:44 ]

[Travelan]

Confusion schreef op dinsdag 24 juni 2008 @ 11:32:
[...]

Hoe verhoudt zich dit tot lambda in Python en closures in javascript?

Dat is maar een heel klein gedeelte van functioneel programmeren. Lambda is inderdaad ook wel de term die in dezelfde lijn ligt als waar ik heen wil met de kreet "functies zijn objecten". Andere technieken die ik overweeg zijn bijvoorbeeld lazy evaluation, list comprehensions, en nog iets waarvan ik nu even niet op de naam kom (minder interessant, komt neer op het splitsen van lists in de header van functies).

[Janoz]

Travelan schreef op dinsdag 24 juni 2008 @ 11:39:
[...]

Dat is de preprocessor. Dat is per definitie een interpreter. http://en.wikipedia.org/wiki/Preprocessor

Ik heb naast dat het erg leuk is om te doen, nog wel meer redenen om dit project te starten. Ik mis bijvoorbeeld hele interessante functionele aspecten in pakweg alle imperatieve talen niet mogelijk zijn.

Ik weet wat een preprocessor is. Bij het teruglezen zag ik inderdaad de voetnoot. Punt blijft wat een gebruiker straks aan een melding heeft waarin "\home\developernaam\projects\build\bladiebla" staat, maar goed

[...]

Hier staat al het een en ander over in het pdfje. Is inderdaad niet veel over te vinden, hier wil ik nog even de tijd voor nemen om goed uiteen te zetten.


[...]

Die discussie heb ik ook inderdaad afgekapt. Totaal irrelevant.

Leuk dat je die discussie afgekapt, echter staan ook in het door je gequote stukje weer enkele opmerkingen waar ik eigenlijk wel heel nieuwschierig naar ben.

[Travelan]

RobIII schreef op dinsdag 24 juni 2008 @ 11:23:
[...]

Implementatie op magische wijze? Je roept eerst dat alles een object is en dan toch weer (een beetje) niet. En dat gaat de taal op magische wijze oplossen? En dat is niet verwarrend?

Ik ben wel benieuwd hoe je primaire types wilt implementeren als objecten zonder die op magische wijze mee te geven? Misschien dat de objecten zelf (dus de class int) in de taal zelf kunnen worden geschreven, maar die moet dan toch een instantie van (bijv.) prim_int bevatten.

[Confusion]

Travelan schreef op dinsdag 24 juni 2008 @ 11:47:
Dat is maar een heel klein gedeelte van functioneel programmeren. Lambda is inderdaad ook wel de term die in dezelfde lijn ligt als waar ik heen wil met de kreet "functies zijn objecten". Andere technieken die ik overweeg zijn bijvoorbeeld lazy evaluation, list comprehensions, en nog iets waarvan ik nu even niet op de naam kom (minder interessant, komt neer op het splitsen van lists in de header van functies).

Ik bedoel meer: is er volgens jou het verschil tussen jouw 'lazy evaluation' en een closure in javascript, afgezien van de syntax? Is er een verschil tussen jouw list comprehensions en die in Python?

Travelan schreef op dinsdag 24 juni 2008 @ 11:55:
Ik ben wel benieuwd hoe je primaire types wilt implementeren als objecten zonder die op magische wijze mee te geven? Misschien dat de objecten zelf (dus de class int) in de taal zelf kunnen worden geschreven, maar die moet dan toch een instantie van (bijv.) prim_int bevatten.

Dat een object uiteindelijk pakweg een C int gebruikt, betekent niet dat de taal een primitieve int heeft. Anders zou elke taal per definitie een primitieve bit hebben: op het laagste niveau zijn ze tenslotte bits heen en weer aan het gooien.

[ Voor 30% gewijzigd door Confusion op 24-06-2008 11:58 ]

[Janoz]

Travelan schreef op dinsdag 24 juni 2008 @ 11:55:
[...]

Ik ben wel benieuwd hoe je primaire types wilt implementeren als objecten zonder die op magische wijze mee te geven? Misschien dat de objecten zelf (dus de class int) in de taal zelf kunnen worden geschreven, maar die moet dan toch een instantie van (bijv.) prim_int bevatten.

Dat is niet relevant. Jij bent degene geweest die heeft gesteld dat het een groot voordeel is dat alles een object is, om er vervolgens mee te breken in de eerste specificatie draft. Is het voordeel dan toch niet zo groot als je eerder beweerde? Moet het voordeel daardoor worden herzien? Als dat voordeel blijkbaar geen voordeel is, wat blijft er dan nog over van de verdediging van de noodzaak van deze nieuwe taal?

[.oisyn]

RobIII schreef op dinsdag 24 juni 2008 @ 11:23:
[...]

Unicode != UTF-8
Unicode is een character set, UTF-8 is een encoding. Heb je het (overigens wel goede) artikel überhaupt gelezen? Iets waar je ons wel van beticht, maar vervolgens zelf schuldig aan maakt.

Een minpuntje van dat artikel, Joel doet alsof UCS-2 hetzelfde is als UTF-16. Dat is niet zo. De eerste ondersteunt geen multi-character sequences en kan daarom alleen maar codepoints uit BMP 0 weergeven (0000 - FFFF, muv de surrogate codepoints D800 - DFFF). UTF-16 is daarom wel "backwards compatible" met UCS-2, net als UTF-8 dat is met ASCII. Windows definieerde unicode als UCS-2, maar is sinds XP als ik me niet vergis UTF-16 (hoewel veruit de meeste applicaties uitgaan van UCS-2). Ik geloof dat linux UCS-4 is? Althans, het C type 'wchar_t' is onder de meeste linux omgevingen 4 bytes lang IIRC.

[ Voor 14% gewijzigd door .oisyn op 24-06-2008 12:16 ]

[Travelan]

Janoz schreef op dinsdag 24 juni 2008 @ 12:00:
[...]

Dat is niet relevant. Jij bent degene geweest die heeft gesteld dat het een groot voordeel is dat alles een object is, om er vervolgens mee te breken in de eerste specificatie draft. Is het voordeel dan toch niet zo groot als je eerder beweerde? Moet het voordeel daardoor worden herzien? Als dat voordeel blijkbaar geen voordeel is, wat blijft er dan nog over van de verdediging van de noodzaak van deze nieuwe taal?

De implementatie en de definitie van de taal worden hier door elkaar gehaald. Hoe de (primaire) types uiteindelijk onder de motorkap van de compiler geïntegreerd worden is van latere zorg.
De noodzaak van mijn eigen nieuwe programmeertaal is in eerste instantie dat ik persoonlijk vind dat ik dingen mis in programmeertalen van nu. Dat kan alleen syntax zijn, of het hele design, maar het is puur persoonlijk. Het is dus niet erg zinnig om nu te gaan zeggen dat er geen 'noodzaak' is. Een andere belangrijke 'noodzaak' is dat het gewoon erg leuk is om te doen. De rest is puur bijzaak.

[.oisyn]

Ik heb je trouwens nog niet horen reageren op mijn opmerking over multiple dispatch. Hoe denk je daarover? Dit is wel iets dat ik vind missen in de meeste moderne OO talen.

[ Voor 5% gewijzigd door .oisyn op 24-06-2008 12:18 ]

[NMe]

Travelan schreef op dinsdag 24 juni 2008 @ 11:39:
Die discussie heb ik ook inderdaad afgekapt. Totaal irrelevant.

Leuk om te zien dat je de kritiek van iemand die serieus je specificatie doorneemt en je wil helpen om de overduidelijke fouten en tekortkoming die daarin staan aanstipt afdoet als "irrelevant". De kritiek die je nu van Janoz krijgt kun je sowieso ook verwachten van de gevestigde orde van programmeurs en je kan er dus maar beter een antwoord voor klaar hebben. "Dat is niet relevant" doet het meestal niet zo goed in discussies, en zeker niet als je een specificatie te verdedigen hebt.

Travelan schreef op dinsdag 24 juni 2008 @ 12:11:
[...]

De implementatie en de definitie van de taal worden hier door elkaar gehaald. Hoe de (primaire) types uiteindelijk onder de motorkap van de compiler geïntegreerd worden is van latere zorg.
De noodzaak van mijn eigen nieuwe programmeertaal is in eerste instantie dat ik persoonlijk vind dat ik dingen mis in programmeertalen van nu. Dat kan alleen syntax zijn, of het hele design, maar het is puur persoonlijk. Het is dus niet erg zinnig om nu te gaan zeggen dat er geen 'noodzaak' is. Een andere belangrijke 'noodzaak' is dat het gewoon erg leuk is om te doen. De rest is puur bijzaak.

Je noemt het feit dat er alleen objecten bestaan in jouw taal als voordeel van jouw taal boven enkele anderen, maar vervolgens doe je hetzelfde als die andere talen door gewoon primaire types te ondersteunen. Je breekt in je eerste specificatie al met je eigen principes waardoor je taal, op mij in elk geval, overkomt als een slap aftreksel van de gevestigde talen.

Om nog even terug te komen op het nut van het ontwerpen van een nieuwe taal, terwijl je eigenlijk alleen kritiek hebt op platformen: als ik het goed begrijp is je uiteindelijke verdediging voor je taal dat je het leuk vind om hem te maken en dat je enkele functies mist:

Travelan schreef op dinsdag 24 juni 2008 @ 11:39:
Ik heb naast dat het erg leuk is om te doen, nog wel meer redenen om dit project te starten. Ik mis bijvoorbeeld hele interessante functionele aspecten in pakweg alle imperatieve talen niet mogelijk zijn.

Ik ben eerlijk gezegd wel benieuwd naar de "functionele aspecten" uit jouw taal die mij als programmeur over moeten gaan halen om Thinder te gebruiken in plaats van C++ of Java.

[djluc]

Maak nou eens concreet wat je dan precies mist, met concrete voorbeelden, en hoe jij dat dan beter zou kunnen/willen zien.

[RayNbow]

.oisyn schreef op dinsdag 24 juni 2008 @ 12:18:
Ik heb je trouwens nog niet horen reageren op mijn opmerking over multiple dispatch. Hoe denk je daarover? Dit is wel iets dat ik vind missen in de meeste moderne OO talen.

Inderdaad, er zijn maar weinig talen die 't ondersteunen.

Gelukkig heeft VB.NET al multimethods. Zie Erik Meijer's presentatie VB IsNot C#" (slide 13).

Verder kun je aan Python gemakkelijk ondersteuning voor multimethods toevoegen door gebruik te maken van Python's decorators: Five-minute Multimethods in Python.

[dawuss]

Travelan schreef op dinsdag 24 juni 2008 @ 11:47:
[...]
en nog iets waarvan ik nu even niet op de naam kom (minder interessant, komt neer op het splitsen van lists in de header van functies).

Bedoel je pattern matching? Dat je bijvoorbeeld (x:xs) als parameter kunt nemen en dat dat dan te lezen is als "het element x op de kop van de lijst xs".

Om verder nog iets nieuws in de introductie te introduceren: je noemt in je topicstart eigenlijk voornamelijk C++ en C#/Java als voorbeelden van objectgeorienteerde programmeertalen. Dat zijn natuurlijk bijzonder populaire talen, maar ze zijn wel allemaal syntactisch heel erg nauwverwant. Heb je bijvoorbeeld al eens naar talen als Python en Ruby gekeken? Die liggen qua uitvoering veel dichter bij wat jij met Thinder voorstelt.

Zowel Python als Ruby zijn objectgeorienteerrde talen met functionele trekjes. Ze zijn beiden hoog dynamisch, en om die reden geinterpreteerd, waardoor ze niet meer binnen jouw definitie van een "industriele taal" vallen (ik denk dat de industrie daar anders over denkt). Wel zijn ze een stuk zuiverder dan de taal die je zelf voorstelt. Zo heb je in Ruby bijvoorbeeld geen primitieve types nodig en kun je dus bijvoorbeeld op een integer allemaal gein uithalen als "1.next" enzo.

Omdat je in je topicstart aangeeft dat je vooral wat wil doen aan de syntactische warboel denk ik dat je eerder een voorbeeld zou moeten nemen aan deze talen dan aan de klassiekere c-gebaseerde talen. Kun je aangeven wat er volgens jou ontbreekt aan of mis is met talen als Python en Ruby?

(overigens is het naar mijn bescheiden mening helemaal niet zo gewichtig of een taal geinterpreteerd of gecompileerd is. Met een geïnterpreteerde taal laat je wat wegen open naar dynamische dingen die je in een geïnterpreteerde taal nog wel kunt doen, maar in een gecompileerde taal niet, maar dat is maar één van de aspecten van een taal).

[XKB]

Veel van de dingen die ik hier lees zie ik terug in de taal Scala (http://www.scala-lang.org/), een hybride oo-functionele taal. Hierin zijn functies objecten, beschik je over dynamic dispatch en kan je lazy evaluation gebruiken. Verder ken een constructie die doet denken aan list comprehensions (for comprehension). De taal heeft veel weg van Java en is ook "statisch" getypeerd.

Misschien interessant om eens naar te kijken voor de TS?

[kasper_vk]

Misschien dat dit topic ook interessante ideeën bevat (een deel ervan is al langsgekomen, maar ik wilde de TS er toch even op wijzen):
\[disc-taal] welke features erin en welke eruit.

[RayNbow]

Relevante discussies op LtU:
Writing a new language - ideas?
Let's make a programming language!

[Cousin Boneless]

Volgens mij mis ik in deze taal alle object georienteerde concepten. Er wordt wel gesproken over de scope 'protected', maar dat is wat zinloos als de mogelijkheid van inheritance ontbreekt.

Ik zou multiple inheritance niet implementeren en daarvoor interfaces toevoegen.

Wat ik verder in veel talen mis zijn class references zoals in Object Pascal (Delphi). In combinatie met virtual constructors kun je daar zo makkelijk factory patterns mee opzetten.

Verder zou ik de generics (.NET) toevoegen (templates in C++)

Ik vind de geintroduceerde taalconstructie 'container' wel tenenkrommend. Volgens mij is dat veel mooier op te lossen met een interface 'ITraversable'. En ook die 'goto'.. alsjeblieft niet doen.
En ook operator overload zou niet m'n prioriteit hebben, omdat dat wel compacte code levert, maar heel veel discipline van de programmeur vereist. Het zelfde geldt voor properties. Gewoon voluit getAValue() en setAValue(). Lekker duidelijk wat er gebeurt.

Verder mis ik nog de try, catch en final blokken.

Waar ik wel voorstander van ben zijn de voorgestelde geneste functies. En functies met gelijke functienamen. Let wel op dat als je een functie als parameter doorgeeft, dat je dan wel de scope gebruikt waarin de functie is gedefinieerd. Dat lijkt me nog vrij lastig. (In Delphi mag je daarom van de compiler geen geneste functies doorgeven.)

De lijst zie ik niet als eigenschap van de taal. Dit is typisch iets voor een library.

De introductie van de oneindige integer vind ik wel grappig, maar te academisch. Dit zal vast bedoeld zijn in combinatie met dat lazy evaluation? En dat ie dan in loops binaire staartdelingen enzo gaat maken?

Verder mist er nog heel wat documentatie. Ik neem toch aan dat er een if-then-else constructie in komt en dat er op null-values kan worden getest.

En de editor (nu als laatste punt): Ik weet dat het schier onmogelijk is om te implementeren, maar de acceptatie van een taal staat of valt (bij mij) toch bij zaken als code completion (vooral bij case sensitive OO-talen) en context sensitive help. We leven immers niet meer in de jaren '80.

[.oisyn]

Cousin Boneless schreef op donderdag 26 juni 2008 @ 23:46:
Verder zou ik de generics (.NET) toevoegen (templates in C++)

Generics zijn geen templates.

Let wel op dat als je een functie als parameter doorgeeft, dat je dan wel de scope gebruikt waarin de functie is gedefinieerd. Dat lijkt me nog vrij lastig. (In Delphi mag je daarom van de compiler geen geneste functies doorgeven.)

Talen waarin dat wel mag (zoals bijvoorbeeld javascript) of talen met ondersteuning voor lambda-expressies maken dan ook gebruik van closures, en niet van ruwe functiepointers. C++0x krijgt ook lambda-expressies - en dus closures.

[djc]

Cousin Boneless schreef op donderdag 26 juni 2008 @ 23:46:
We leven immers niet meer in de jaren '80.

Klopt, daarom hebben we nu wel operator overloading en properties.

Jij wil het liefst een kopie van C# of Java, lijkt het, zonder enige features van dynamische talen.

[chris]

Wat ik zelf heel vet vind aan Agda is heel veel mogelijkheid voor de programmeur om syntax te definieren met behulp van underscores, bv:

code:

_*_ a b = if a == 1 then b else b + (a - 1) * b

of zelfs if then else:

code:

if_then_else_ cond l r | cond == true = l
if_then_else_ cond l r | otherwise = r

Zo kan je ontzettend expressieve subtaaltjes bouwen.

[oeLangOetan]

XKB schreef op dinsdag 24 juni 2008 @ 18:57:
Veel van de dingen die ik hier lees zie ik terug in de taal Scala (http://www.scala-lang.org/), een hybride oo-functionele taal. Hierin zijn functies objecten, beschik je over dynamic dispatch en kan je lazy evaluation gebruiken. Verder ken een constructie die doet denken aan list comprehensions (for comprehension). De taal heeft veel weg van Java en is ook "statisch" getypeerd.

Misschien interessant om eens naar te kijken voor de TS?

+1

Ik ben al een paar maand bezig met scala te leren. Eens je er mee bezig bent geweest voelen andere talen plots lomp aan. Ik ben nooit fan geweest van ruby, groovy etc dynamische talen vindt ik eigenlijk lastiger om mee te werken.
Ik zou iedereen aanraden om het tenminste eens te proberen. Scala vereist wel een open geest want je moet een heleboel nieuwe concepten verwerken, iets waar de meeste programmeurs eens ze OO onder de knie hebben niet veel zin meer in hebben. Terugkeren naar java is voor mij steeds een marteling omdat je weet dat het veel beter/netter kan...

James Gosling, de hoofdontwikkelaar van java, vindt dat Scala Java kan opvolgen.

Scala voorstelling op javapolis:
http://parleys.com/displa...ala;slide=1;talk=10485769
http://parleys.com/displa...2707;slide=1;talk=4653376

[NMe]

Ik vind het zo jammer dat de topicstarter ineens angstvallig stil is. Er zijn toch wat interessante vragen gesteld waar ik wel graag een antwoord op zou willen zien.

[.oisyn]

Ik denk dat dat komt omdat het de bedoeling van de TS was om gewoon te horen te krijgen wat mensen graag in een programmeertaal willen zien, ipv (terechte) kritiek te krijgen op z'n specificatie

[roy-t]

Om even terug te komen op features, na het lezen van wat info over D vind ik een apparte Cocanation Operator wel een hele handige functie, een + gebruiken voor optellen EN cocanation is soms wat onoverzichtelijk helemaal icm automatic type casting.

Voorbeeld (geen echte C# btw) Je weet dat een int toegevoegd aan een string automatisch getypcast worden naar strings

C#:

Console.out.writeln("Stringzzz" + 1 + 309);
//output: "Stringzzz310" of "Stringzzz1309"?
Console.out.writeln("Stringzzz" + (1 + 309));
//En nu?

Veel handiger als bijvoorbeeld ~ een cocanation operator zou zijn.

C#:

Console.out.writeln("Stringzzz" ~ 1 + 309);
//Nu weet je zeker dat de output "Stringzzz310" is.
//Ook zou dit dan mogelijk worden
string s = (300 + (40~1));
Console.out.writeln(s)
//Output: 701, even tussen haakjes want wat gaat voor +  of ~?

Ik ben zeer benieuwd of dit goed uit te werken zou zijn, werkt natuurlijk alleen op primitives of Classes/Objecten die gedefinieerd hebben wat er gebeurt als de "~" operator gebruikt wordt. (Zoals dat nu ook in C# zit in de reference).

[.oisyn]

Concatenation

Verder vind ik de redenatie in je voorbeelden een beetje raar. Het is namelijk gewoon gedefinieerd dat + links-associatief is, en dat het dus geparsed wordt als ("Stringzzz" + 1) + 309. En als je zelf haakjes toe gaat voegen is ook duidelijk dat er 310 wordt opgeteld.

Daarna zeg je je het met een concatenation operator zeker weet zonder operator precedence ervan te definieren. Het kan ook "Stringzzz1309" worden als de ~ geen lagere precedence heeft dan de +. In VB en PHP is de concatenation operator (resp. '&' en '.') overigens lager.

Tot slot zeg je dat de output van 300+(40~1) wel 701 moet zijn, terwijl dat in C#, VB, Java en C++ de string "300401" zou zijn

[ Voor 104% gewijzigd door .oisyn op 30-06-2008 01:45 ]

[roy-t]

.oisyn schreef op maandag 30 juni 2008 @ 01:33:
Concatenation

Verder vind ik de redenatie in je voorbeelden een beetje raar. Het is namelijk gewoon gedefinieerd dat + links-associatief is, en dat het dus geparsed wordt als ("Stringzzz" + 1) + 309. En als je zelf haakjes toe gaat voegen is ook duidelijk dat er 310 wordt opgeteld.

Daarna zeg je je het met een concatenation operator zeker weet zonder operator precedence ervan te definieren. Het kan ook "Stringzzz1309" worden als de ~ geen lagere precedence heeft dan de +. In VB en PHP is de concatenation operator (resp. '&' en '.') overigens lager.

Ah wat een rot woord .

En ja de VB & was ik helemaal vergeten daarin bestaat het natuurlijk al een stuk langer dan in D e.d. Het klopt dat de precedence nog gedefinieerd moet worden.

Ik snap dat mijn voorbeelden een beetje raar zijn omdat een goede programmeur echt wel weet wat eerst gaat + tussen 2 ints tussen haakjes versus een plus met een string. Maar het zou overzichtelijker worden met een extra operator (denk ik) ook zou je er (misschien) leuke truukjes mee kunnen uithalen op andere datatypen (IP adressen? Als je bijvoorbeeld een IP object maakt).

[NMe]

roy-t schreef op maandag 30 juni 2008 @ 01:46:
Ik snap dat mijn voorbeelden een beetje raar zijn omdat een goede programmeur echt wel weet wat eerst gaat + tussen 2 ints tussen haakjes versus een plus met een string. Maar het zou overzichtelijker worden met een extra operator (denk ik) ook zou je er (misschien) leuke truukjes mee kunnen uithalen op andere datatypen (IP adressen? Als je bijvoorbeeld een IP object maakt).

"Truukjes" zorgen zelden voor mooi leesbare code.

[Janoz]

roy-t schreef op maandag 30 juni 2008 @ 01:46:
(IP adressen? Als je bijvoorbeeld een IP object maakt).

Een ip adres moet je opslaan als wat het is. een 32bit unsigned int. Wanneer je dat doet is het hele gedoe met subnets en mask ineens triviaal. Enkel de toString methode van je object zou je kunnen gebruiken om de 4 afzonderlijke byte punt gescheiden in het decimale stelsel uit te drukken zodat het voor mensen wat leesbaarder wordt.


Kortom, slecht voorbeeld

[roy-t]

Janoz schreef op maandag 30 juni 2008 @ 09:20:
[...]

Een ip adres moet je opslaan als wat het is. een 32bit unsigned int. Wanneer je dat doet is het hele gedoe met subnets en mask ineens triviaal. Enkel de toString methode van je object zou je kunnen gebruiken om de 4 afzonderlijke byte punt gescheiden in het decimale stelsel uit te drukken zodat het voor mensen wat leesbaarder wordt.


Kortom, slecht voorbeeld

Misschien maar ik bedoel dat je dan met een ~ of & operator IP adressen in elkaar kon zetten doormiddel van:

C#:

byte[] ip = new byte[]{109.109.109.255};
IP homeIP = new IP(byte[0] ~ byte[1] ~byte[2] ~ byte[3]); //constructor van een IP eet een UINT32

Nu snap ik dat het nut hiervan niet direct duidelijk is of altijd even groot, maar ik denk toch dat er handige dingen mee bedacht kunnen worden. Het primaire doel blijft natuurlijk om Strings duidelijker te maken.

[Hydra]

roy-t schreef op maandag 30 juni 2008 @ 10:18:
Nu snap ik dat het nut hiervan niet direct duidelijk is of altijd even groot, maar ik denk toch dat er handige dingen mee bedacht kunnen worden. Het primaire doel blijft natuurlijk om Strings duidelijker te maken.

Ik vind het eerlijk gezegd alleen maar onduidelijker. Iedereen weet het verschil tussen 2 * 2 + 2 en 2 * (2 + 2). Een extra ~ operator is totaal onnodig en geeft alleen maar syntactische clutter.

[.oisyn]

Zo ver wil ik ook weer niet gaan. Een string concatenatie is wat anders dan een optelling, dus het hebben van een concatenatie-operator zoals andere talen dat hebben zou ik niet zien als clutter, zeker als je taal ook nog eens dynamische types ondersteunt (wat PHP en VB allebei doen). Wat wel zo is is dat het het haakjes-probleem helemaal niet oplost - het heeft daar dan ook weinig mee te maken.

(In VB.Net hebben de shift-operatoren bijvoorbeeld weer een lagere precedence dan de concatenatie-operator - met een expressie als "aap" ~ 1 << 2 ben je dan alsnog de sjaak (het compilet niet want je kunt een string ("aap1") niet shiften)

roy-t schreef op maandag 30 juni 2008 @ 10:18:
[...]


Misschien maar ik bedoel dat je dan met een ~ of & operator IP adressen in elkaar kon zetten doormiddel van:

C#:

byte[] ip = new byte[]{109.109.109.255};
IP homeIP = new IP(byte[0] ~ byte[1] ~byte[2] ~ byte[3]); //constructor van een IP eet een UINT32

Wat al niet klopt, omdat je de "." vergeet tussen de bytes, waardoor de regel alleen maar langer wordt en er totaal geen voordeel meer is (immers, met de "." ertussen kun je de ~ vervangen door een + en doet het precies hetzelfde).

Wat ik wel handig zou vinden, is user-defined literals zodat je in je code bijvoorbeeld direct een ip-adres in kunt tikken waar gewoon een IP object van geconstrueert wordt:

C++:

IP localhost = 127.0.0.1ip;

*kuch*

[ Voor 50% gewijzigd door .oisyn op 30-06-2008 12:27 ]

[roy-t]

.oisyn schreef op maandag 30 juni 2008 @ 12:11:

[...]

Wat ik wel handig zou vinden, is user-defined literals zodat je in je code bijvoorbeeld direct een ip-adres in kunt tikken waar gewoon een IP object van geconstrueert wordt:

C++:

IP localhost = 127.0.0.1ip;

*kuch*

Ok ik geef me over, de extra voordelen zijn er niet echt, maar toch lijkt een extra operator me handig net als VB.

Oeh user-defined literals *stemt voor.*

[XKB]

Hmm dat lijkt me nu ook wel wat! Vooral qua leesbaarheid lijkt me dit een verbetering t.o.v. eventuele constructor aanroep.

[Michali]

Ik had een tijdje geleden hier op school een presentatie over design-by-contract mogelijkheden in een taal. Dit houdt vooral in dat je voor methodes pre- en postcondities kunt bepalen waaraan voldaan moet worden en wordt. Op die manier hoef je bijna nooit meer een exception te gooien, omdat je object bijvoorbeeld in een ongeldige state verkeert. Ik zou het zelf erg prettig vinden als dit er in zou zitten, heeft veel voordelen in ieder geval.

[Woy]

.oisyn schreef op maandag 30 juni 2008 @ 12:11:
Wat ik wel handig zou vinden, is user-defined literals zodat je in je code bijvoorbeeld direct een ip-adres in kunt tikken waar gewoon een IP object van geconstrueert wordt:

C++:

IP localhost = 127.0.0.1ip;

*kuch*

Mwoah ik weet niet of dat het allemaal zoveel duidelijker maakt. En zoveel voordeel zie ik er ook niet van

C++:

IP localhost( "127.0.0.1" );

is imho net zo leesbaar. Anders zul je alsnog weer een conversie operator moeten maken. Nadeel is dat je natuurlijk alleen de juiste constructors kunt defineren bij eigen types.

Alleen compile time user-defined literals zou mischien nog een voordeel bieden qua performance, maar ik denk dat het niet vaak voorkomt dat dat een bottleneck vormt.

[roy-t]

rwb schreef op maandag 30 juni 2008 @ 15:56:
[...]

Mwoah ik weet niet of dat het allemaal zoveel duidelijker maakt. En zoveel voordeel zie ik er ook niet van

C++:

IP localhost( "127.0.0.1" );

is imho net zo leesbaar. Anders zul je alsnog weer een conversie operator moeten maken. Nadeel is dat je natuurlijk alleen de juiste constructors kunt defineren bij eigen types.

Alleen compile time user-defined literals zou mischien nog een voordeel bieden qua performance, maar ik denk dat het niet vaak voorkomt dat dat een bottleneck vormt.

Maar in de meesta talen zul je toch heel wat meer moeten typen:

C#:

IP localhost = new IP("127.0.0.1");
//Versus
IP localhost = 127.0.0.1ip;

Het is niet heel veel maar het het is wel veel makkelijker typen onder andere omdat de haakjes en de quotes telkens 2 toetsaandrukken vereisen waardoor je niet lekker door kan typen *hoewel een goede IDE hier vaak mee helpt*.

[Woy]

roy-t schreef op maandag 30 juni 2008 @ 15:59:
[...]


Maar in de meesta talen zul je toch heel wat meer moeten typen:

C#:

IP localhost = new IP("127.0.0.1");
//Versus
IP localhost = 127.0.0.1ip;

Het is niet heel veel maar het het is wel veel makkelijker typen onder andere omdat de haakjes en de quotes telkens 2 toetsaandrukken vereisen waardoor je niet lekker door kan typen *hoewel een goede IDE hier vaak mee helpt*.

Maar die paar toetsaanslagen ( Die door een goede IDE idd tot een minimum beperkt worden ) lijken me niet echt heel erg interessant. Daarentegen kan het dingen bijvoorbeeld wel onduidelijker maken

int operator "cm" (unsigned long long); // centimeters
int x = 12345cm; // fine
int y = 0xascdefcm; // oops: unknown suffix ‘m’

[Verwijderd]

rwb schreef op maandag 30 juni 2008 @ 15:56:
[...]

Mwoah ik weet niet of dat het allemaal zoveel duidelijker maakt. En zoveel voordeel zie ik er ook niet van

C++:

IP localhost( "127.0.0.1" );

is imho net zo leesbaar. Anders zul je alsnog weer een conversie operator moeten maken. Nadeel is dat je natuurlijk alleen de juiste constructors kunt defineren bij eigen types.

Alleen compile time user-defined literals zou mischien nog een voordeel bieden qua performance, maar ik denk dat het niet vaak voorkomt dat dat een bottleneck vormt.

Met user-defined literals kan je ook @compile-time checken of je een foutje hebt gemaakt. Met geparste strings kan dat niet.

[Woy]

Verwijderd schreef op maandag 30 juni 2008 @ 16:09:
[...]

Met user-defined literals kan je ook @compile-time checken of je een foutje hebt gemaakt. Met geparste strings kan dat niet.

Als user-defined literals idd compile time gemimplementeerd zijn is dat idd wel een voordeel.

[.oisyn]

rwb schreef op maandag 30 juni 2008 @ 15:56:
[...]

Mwoah ik weet niet of dat het allemaal zoveel duidelijker maakt. En zoveel voordeel zie ik er ook niet van

C++:

IP localhost( "127.0.0.1" );

is imho net zo leesbaar.

Het ip adres was wellicht ook een minder goed voorbeeld, maar hield ik aan omdat het in de lijn van de topic lag. Maar denk aan een postfix 'i' die je kunt gebruiken voor het imaginaire deel van complexe getallen:

C++:

complex c = 34.5 + 23.8i;

Of een "s" prefix om in C++ (het was immers een C++ proposal die C++0x waarschijnlijk wel gaat halen trouwens) om direct van een string literal een std::string object te maken - "bla"s is toch wat gebruikersvriendelijker dan std::string("bla").
Of SI units:

C++:

distance d = 300km;
speed s = 100kph;

Het voordeel van een postfix is dat hij een stuk korter hoeft te zijn dan het type waar hij naar converteert. Als je een functie als m() moet definieren omdat je dingen in meters wilt aangeven dan krijg je al snel ambiguïteit

Anders zul je alsnog weer een conversie operator moeten maken

Die snap ik even niet?

rwb schreef op maandag 30 juni 2008 @ 16:08:
[...]

Maar die paar toetsaanslagen ( Die door een goede IDE idd tot een minimum beperkt worden ) lijken me niet echt heel erg interessant. Daarentegen kan het dingen bijvoorbeeld wel onduidelijker maken

Een slecht voorbeeld, wanneer noteer jij aantal centimeters in het hexadecimale talstelsel? Dat dat voorbeeld in het proposal werd genoemd is omdat het belangrijk is om te definieren hoe een dergelijke constructie geparsed moet worden.

Verwijderd schreef op maandag 30 juni 2008 @ 16:09:
[...]

Met user-defined literals kan je ook @compile-time checken of je een foutje hebt gemaakt. Met geparste strings kan dat niet.

Mbt het C++ proposal: Helaas krijg je gewoon een string mee als je iets complexer wilt bereiken dan een enkel getal (int, float, etc), bijvoorbeeld in het geval van het ip-adres. Het daadwerkelijk parsen gebeurt nog steeds tijdens runtime.

[MSalters]

Ik neem aan dat het daadwerkelijke parsen gebeurt alsof het tijdens runtime gebeurt? Er is nu al niets wat de compiler verbied om van std::string("x") een compile-time operatie te maken. Het meest simpele zou wel zijn om er een std::string("x", 1) van te maken. User Defined Literals veranderen niets aan dat principe.

[.oisyn]

Hmmm, slippery slope. Een basale std::string implementatie zal een allocatie doen. Nou zou je dat eventueel ook nog compile-time kunnen doen, maar dat wordt wel heel erg vergezocht. Zoiets triviaals als het imaginaire getal voorbeeld zou wel compile-time kunnen, niet in de minste plaats omdat je dan niet de float zelf hoeft te parsen (die krijg je dan immers als parameter voor je literal constructor), en die voldoet waarschijnlijk zelfs aan de constexpr eisen.

[MicroWhale]

Integratie van meerdere DSL's (in-code)

Wiskunde is een DSL die veel gebruikt wordt en geintegreerd is in veel programmeer talen. Wat ik altijd een manco vind in een programmeertaal is dat er naast wiskunde maar één andere grammatica is: die van de object-taal.

Het zou mooi zijn als programmeurs bovenop object en wiskunde zelf talen konden ontwikkelen waarin andere DSL's gebruikt kunnen worden. Op deze manier kun je bijvoorbeeld een "verzekerings"-DSL maken. Zo kan een verzekeringsexpert zelf de logica schrijven voor verzekeringen.

Het verzinnen, uitwisselen en verbeteren van deze talen gebeurt dan (verplicht) in het open source domein, zodat talen goed op elkaar aangesloten blijven.

Deze "technologie" kan programmeren naar een hoger plan tillen en zo de opmaat vormen voor het dichten van de kloof tussen business en ICT.

*edit*
eigenlijk is er nog een taal: de scherm-definitie-taal. (en misschien nog wel meer) Ze werken allemaal met elkaar samen, dus zou het ook handig zijn dat een programmeur tijdens het programmeren alleen die dingen mag/kan veranderen waarvoor hij ook de rol heeft toegewezen gekregen. Zo kan de web-developer de schermen aanpassen, de business-expert de business-logica (in zijn eigen taal) en de platform-programmeur de object-logica.

[ Voor 20% gewijzigd door MicroWhale op 01-07-2008 13:54 ]

[MicroWhale]

en nog iets:

een mogelijkheid voor een architect om architectuur af te dwingen. Bij afwijkingen compileert de boel gewoon niet.

[XKB]

Dat laatste wil je niet, soms zijn er namelijk wel redenen te bedenken om van een vooraf gedefinieerde architectuur af te wijken. Bijvoorbeeld bij performance optimalisaties.

Qua DSL's, een functionele taal als bijvoorbeeld Haskell is uitermate geschikt om het soort DSL's te maken die jij beschrijft. Haskell biedt de syntactische mogelijkheden om een taal op te spannen met bv. parser combinators. Verder is de kern van haskell sterk gerelateerd aan wiskundige begrippen.

[ Voor 46% gewijzigd door XKB op 01-07-2008 14:23 ]

[RayNbow]

MrWilliams schreef op dinsdag 01 juli 2008 @ 13:48:
Integratie van meerdere DSL's (in-code)

Wiskunde is een DSL die veel gebruikt wordt en geintegreerd is in veel programmeer talen. Wat ik altijd een manco vind in een programmeertaal is dat er naast wiskunde maar één andere grammatica is: die van de object-taal.

Het zou mooi zijn als programmeurs bovenop object en wiskunde zelf talen konden ontwikkelen waarin andere DSL's gebruikt kunnen worden. Op deze manier kun je bijvoorbeeld een "verzekerings"-DSL maken. Zo kan een verzekeringsexpert zelf de logica schrijven voor verzekeringen.

Het verzinnen, uitwisselen en verbeteren van deze talen gebeurt dan (verplicht) in het open source domein, zodat talen goed op elkaar aangesloten blijven.

Deze "technologie" kan programmeren naar een hoger plan tillen en zo de opmaat vormen voor het dichten van de kloof tussen business en ICT.

*edit*
eigenlijk is er nog een taal: de scherm-definitie-taal. (en misschien nog wel meer) Ze werken allemaal met elkaar samen, dus zou het ook handig zijn dat een programmeur tijdens het programmeren alleen die dingen mag/kan veranderen waarvoor hij ook de rol heeft toegewezen gekregen. Zo kan de web-developer de schermen aanpassen, de business-expert de business-logica (in zijn eigen taal) en de platform-programmeur de object-logica.

Zie Concrete Syntax For Objects en de bijbehorende papers.

MrWilliams schreef op dinsdag 01 juli 2008 @ 13:58:
en nog iets:

een mogelijkheid voor een architect om architectuur af te dwingen. Bij afwijkingen compileert de boel gewoon niet.

Met behulp van het Java Spoon framework kan je al inhaken op de Java compiler en foutmeldingen/warnings genereren. Dus als de compiler die je voor een taal ontwikkelt de mogelijkheid geeft om preprocessing te doen (met een fatsoenlijke API), dan geef je dus een architect alle vrijheid om de compiler uit te breiden.

[chris]

.oisyn schreef op maandag 30 juni 2008 @ 17:28:
[...]

Het ip adres was wellicht ook een minder goed voorbeeld, maar hield ik aan omdat het in de lijn van de topic lag. Maar denk aan een postfix 'i' die je kunt gebruiken voor het imaginaire deel van complexe getallen:

C++:

complex c = 34.5 + 23.8i;

...

C++:

distance d = 300km;
speed s = 100kph;

In agda zou je iets vergelijkbaars kunnen doen (wel minder krachtig aangezien je alleen literals kan uitbreiden met postfix operatoren), maar je kan prima zelf postfix operatoren definieren, en bijvoorbeeld zeggen dat km werkt op (Int -> Distance KM) of mph op (Int -> Speed Miles). Best grappig, en met mijn voorbeeld van mixfix syntax hierboven zou je dat ook in je programmeertaal kunnen doen.

[ Voor 4% gewijzigd door chris op 02-07-2008 14:47 ]

[Verwijderd]

Datatypes voor SI grootheden, en een postfix voor de eenheid is niet zo'n heel beroerd idee. Een ToString() zou dan op basis van de current culture de goede uitvoer moeten geven (km/u, m/h, etc). Bovendien kan de compiler warnings dan wel errors geven bij onjuiste berekeningen met SI grootheden. Als je bijvoorbeeld snelheid bij tijd gaat optellen om maar wat te noemen. In .NET is de structure TimeSpan in feite al bedoeld voor de grootheid tijd (duur), maar ben je voor de rest aangewezen op general purpose floating points. Hetzelfde verhaal geldt voor geld. Delphi kent een speciaal Currency datatype die netjes de goede afrondingsmethoden gebruikt. Dit laatste zou ook op basis van current culture moeten.

Verder zou ik kijken naar de sterke eigenschappen van C#, Java en C++. Microsoft heeft met C++/CLI op basis van de C++ syntax al heel goede gooi gedaan naar een general purpose taal waarbij de programmeur native en managed code door elkaar kan gebruiken. Dat is precies iets wat ik in C# mis; de keus om expliciet managed te werken, en expliciet unmanaged. Expliciet de garbage collector gebruiken, maar ook expliciet alle vrijheid met pointers hebben. En, zoals in C++/CLI, dit alles kunnen combineren. Nu werk ik met aparte C++/CLI assemblies omdat ik wél native code wil gebruiken, maar zo min mogelijk met de C++ syntax wil werken want die is gewoon foeilelijk.

Verder vind ik attributes in .NET erg sterk. Operator overloading is inmiddels standaard. Anonymous methods en zaken als LINQ zijn ook erg mooie language features maar érg complex. Extension methods zijn ook handig. Kortom: kijk eens naar de nieuwe language features van C# 3.0.

Een sterk punt van Java vind ik het expliciet vermelden van de mogelijke exceptions van een method. Exceptions schieten in .NET te makkelijk door en zelfs de documentatie van .NET Framework zelf vermeldt niet alle mogelijke exceptions. Dit moet de compiler gewoon afdwingen - je wilt uiteindelijke nooit dat exception doorschieten naar de user interface dus je zult toch ergens alles af moeten vangen, ook in threads.

Een sterk punt in Delphi vind ik het kunnen delegeren van een interface implementatie aan een (private) property. Dit is erg mooi voor encapsulation/composition.

En dat IP adres: explicit operator voor conversie maken van string naar je IPAddress struct.

Tot slot: in C++/CLI heb je zowel primitive (gewoon native 32-bit int) als niet-primitive (bijv managed System.Int32 struct). Tis maar net of je op de managed heap zit of niet. Heerlijke expliciet en de programmeur heeft de vrije keus. Grootste nadeel aan C++/CLI (volgens mij grote overeenkomsten met C++0x), is dat ouderwetse C++ code er ook in moet werken. Lelijke syntax hier en daar. Maarja, aan jou dus de taak om het beste uit alle werelden te combineren. En een beetje kritiek hoort daar wel bij

[ Voor 15% gewijzigd door Verwijderd op 02-07-2008 22:46 ]

[Cousin Boneless]

Mee eens dat je een interface met willekeurige methods (ook anonieme) zou mogen implementeren zolang de typering overeenkomt. Zie FreePascal reference http://www.freepascal.org/docs/ref.pdf (blz. 70-71). Ik kon geen eenduidige naam vinden voor deze constructie. Method aliasing, interface redirection. http://safari.ibmpressbooks.com/1565926595/ch02-34776 (alinea 4)

De private scope is overigens ook toegestaan in C#.. dacht ik.. geen sample bij de hand.

[chris]

Verwijderd schreef op woensdag 02 juli 2008 @ 19:53:
Verder vind ik attributes in .NET erg sterk. Operator overloading is inmiddels standaard. Anonymous methods en zaken als LINQ zijn ook erg mooie language features maar érg complex. Extension methods zijn ook handig. Kortom: kijk eens naar de nieuwe language features van C# 3.0.

Dat valt best mee. Zeker in het gebruik zijn ze heel eenvoudig, het kost even wat moeite om het concept door te hebben, maar als je SQL kan, dan kan je ook LINQ (alleen is je bereik een heel stuk groter). Veel code wordt volgens mij een stuk duidelijker hierdoor.

[Verwijderd]

chris schreef op donderdag 03 juli 2008 @ 15:11:
[...]

Dat valt best mee. Zeker in het gebruik zijn ze heel eenvoudig, het kost even wat moeite om het concept door te hebben, maar als je SQL kan, dan kan je ook LINQ (alleen is je bereik een heel stuk groter). Veel code wordt volgens mij een stuk duidelijker hierdoor.

Zeker, maar ik bedoelde niet het gebruik. TS wil zelf een implementatie gaan schrijven en daar wordt het complex van. Die expression trees, de basis van LINQ, zijn dan nog niet zo eenvoudig.

[RobIII]

Verwijderd schreef op donderdag 03 juli 2008 @ 17:21:
TS wil zelf een implementatie gaan schrijven ...

Ik heb zo het vermoeden dat we van TS niets meer gaan horen. Toch jammer dan...