"exotische" talen in de praktijk?

[Anoniem: 129028]

Hier in Programming zie je voornamelijk de veelgebruikte talen voorkomen als Java, C++, C#, VB en PHP. Perl, Python, Javascript en Pascal zie je ook nog wel eens. Maar je hoort maar zeer zelden iets over de wat meer exotische (en vaak naar mijn mening veel leukere en interessantere) talen als Lisp, Smalltalk, of zelfs Prolog, Haskell, Ocaml of Erlang...

In de beroepspraktijk is het nog erger. De meeste collega's die ik tegenkom, hebben van talen als Lisp, Fortran, Ada en Algol nog nooit gehoord, terwijl deze talen toch aan de wieg van onze moderne technologie hebben gestaan, en erg populair en wijdverbrijd zijn geweest.

Dit is mogelijk omdat je als professionele programmeur tegenwoordig prima je geld kunt verdienen met kennis van 1 taal zoals Java of C#. Persoonlijk vind ik dit erg jammer, omdat ik veel plezier kan beleven aan het "spelen" met nieuwe talen met gave features, en vaak leidt het ook tot nieuwe ideeen en het kan zelfs zijn dat je er een betere programmeur van wordt. En soms is een bepaalde taalkeuze verstandig omdat het leidt tot een betere/snellere implementatie, minder bugs, etc. etc. etc. (hoewel dat nooit alleen door de taal komt - je hebt ook een goede programmeur nodig).

Uit pure nieuwsgierigheid nu mijn vraag: wie heeft er ervaring met het gebruik van "exotische" talen in het bedrijfsleven? Wordt er in Nederland nog professioneel Lisp geschreven? Of Tcl/Tk? Of (vul hier zelf je taal in)? En wat zijn je ervaringen hiermee?

[The Eagle]

Lisp: wel ooit van gehoord, schijnt ook wel krachtig te zijn, maar ken verder niemand die er iets mee doet.
Wel vraag ik me af in hoeverre Cobol onder een exotische taal valt. Indien ja: dan gebruik ik dat nog wel eens ooit. Programmeer er gelukkig niet in, krijg ze pre-compiled standaard aangeleverd. We draaien op het werk met PeopleSoft en daar zit onderhuids en beetje Cobol verwerkt. Is alleen niet echt te vervangen door andere logica, puur omdat het zo snel werkt

Mocht iemand een freeware /shareware Cobol-compiler onder Windows weten, dan hou ik me aanbevolen

Overigens heb ik in een studieverleden ook nog wel met Openroad van CA gewerkt. Werkte best fijn, vrij voor de hand liggend

[ Voor 10% gewijzigd door The Eagle op 05-02-2007 22:18 ]

[Not Pingu]

The Eagle schreef op maandag 05 februari 2007 @ 22:18:
Mocht iemand een freeware /shareware Cobol-compiler onder Windows weten, dan hou ik me aanbevolen

Cobol.NET?

Ik ken zelf wel een aantal talen (C#, Java, VB.NET, VBA, PHP, Javascript, GML ,...) dus niet alleen de talen waarin ik primair werk (C#). Wel wil ik nog een keer met talen als Progress4GL of AOP talen.

[Pino]

The Eagle schreef op maandag 05 februari 2007 @ 22:18:
Overigens heb ik in een studieverleden ook nog wel met Openroad van CA gewerkt. Werkte best fijn, vrij voor de hand liggend

Aargh, HHS zeker?

[Anoniem: 14065]

Zeer waarschijnlijk kom je bij banken nog een hoop COBOL tegen. Ongedocumenteerd welteverstaan, met geen hond die meer weet hoe het werkt...

[gerbie71]

Pino schreef op maandag 05 februari 2007 @ 22:27:
[...]

Aargh, HHS zeker?

OpenRoad is inmiddels niet meer van CA, maar is wel open source geworden
http://www.ingres.com/products/openroad-2006.php

[mcdronkz]

Ik heb het idee dat Delphi zelfs een beetje exotisch begint te worden.

[Mastermind]

Prolog!! AAH!

Een van de laatste opdrachten die ik moest doen op de Hanzehogeschool HIO ging alsvolgt (ik heb 'm nog):

Een schaakliefhebber wil een database bijhouden van schaakpartijen uit heden en verleden met als doel om bij een willekeurige stelling van schaakstukken op het schaakbord in zijn database de partijen op te sporen waarin die schaakstelling voorgekomen is en tevens om het verloop van deze partijen te kunnen bestuderen. Hij betrekt zijn gegevens van bevriende schakers, die hem per e-mail het verloop van schaakpartijen toezenden in de zogenaamde PGN-notatie. Deze gegevens moeten door middel van een programma in de database worden geplaatst. Verder moet er een programma geschreven worden die de database doorzoekt op voorkomende schaakstellingen.

1. Ontwerp een relationele database voor de opslag van schaakpartijen en de bijbehorende schaakzetten. Schrijf het eerstgenoemde programma met behulp van de programmeertaal Prolog. Implementeer daartoe je database met behulp van Prolog-predikaten.

2. Voer eerst opdracht 1 uit.
Implementeer nadien je database met behulp van tekstfiles of in een relationeel DBMS en schrijf een programma in Java waarmee je de partijen in de database kunt vinden waarin een door de gebruiker in te voeren schaakstelling voorkomt. Geef als uitvoer het nummer van de betreffende partijen en de zetten die op de betreffende stelling in elk van de partijen gevolgd zijn.

3. Schrijf een rapport van ongeveer drieduizend woorden, waarin je:
• De functionaliteit van je programma,
• De uitgevoerde testen en hun resultaat,
• Je eigen oordeel over de kwaliteit van het programma
beschrijft



Lol ik heb de code ook nog zie ik

Man man wat heb ik daar mee zitten hoofdbreken. Maar het werkte...

[ Voor 7% gewijzigd door Mastermind op 05-02-2007 23:05 ]

[Anoniem: 14829]

Delphi exotisch? Ga je mond spoelen!

Talen als Haskell, Occam, etc. zijn leuk in een universitaire omgeving, en heel erg leuk om mee te experimenteren, maar in 'real life' situaties worden gewoon mainstream talen gekozen. Niet zozeer omdat ze beter zijn, maar omdat ze op de lange duur onderhoudbaarder zijn. Wanneer die ene Haskell guru weggaat, moet 't product nog wel ondersteund worden. Dat gaat een stuk gemakkelijker bij C++, Java, C# en Delphi ()...

[MTWZZ]

Hm ik ken wel wat Fortran (F77 variant) maar dat gebruik ik niet professioneel. Normaal doe ik alleen maar C#, maar ik gebruik wel af en toe de directe IL voor .Net wat toch wel wat weg heeft van assembler. (ik weet het wannabe-assembler )

[The Eagle]

Pino schreef op maandag 05 februari 2007 @ 22:27:
[...]

Aargh, HHS zeker?

Hoe raad je het zo
Was op een gegeven moment luk, 70+ studenten die gingen devven in Openroad, op de zelfde Ingress DB-server als waar de productieomgeving van de administraties op draaide
Hoop werk in moeten halen toen though, knalde er iedere keer uit

@Pino: dan ben je vast ook nog wel bekend met de taal D

[ Voor 7% gewijzigd door The Eagle op 05-02-2007 23:26 ]

[Anoniem: 129028]

Anoniem: 14829 schreef op maandag 05 februari 2007 @ 23:00:
Talen als Haskell, Occam, etc. zijn leuk in een universitaire omgeving, en heel erg leuk om mee te experimenteren, maar in 'real life' situaties worden gewoon mainstream talen gekozen.

Dat is niet in alle "real life" situaties het geval. Er kunnen goede redenen zijn om voor niet-mainstream talen te kiezen. Een van die redenen kan zijn dat je eraan vastzit doordat men ooit is begonnen met zo'n taal. Er is in voorbije jaren vaak gewerkt met allerlei talen die nu "exotisch" zijn. Vergeet niet dat de talen die jij noemt (C#, C++. Java, Delphi) allemaal nog vrij jong zijn. Het is niet voor niets dat Cobol nog zoveel gebruikt wordt. Er was bijv een tijd dat bijv. Lisp een van de meest populaire talen was, om van Ada, Algol en Fortran maar te zwijgen.

Er bestaan best bedrijven die niet-mainstream talen gebruiken. Neem Erlang, dat is ontwikkeld door Ericsson en wordt ook bijvoorbeeld door T-mobile gebruikt. Zelf heb ik ervaring met een werkgever die een soort kruising tussen javascript en pascal ontwikkeld heeft in het begin van de jaren 90 (ben de naam van de taal kwijt, werd alleen binnen dat bedrijf gebruikt). Veel van hun produkten zijn daarin geschreven en daarom wordt het nog steeds gebruikt door hen.

Als TS ben ik gewoon benieuwd naar de "real life" situaties waarin dus WEL exotische talen worden gebruikt, ondanks het idee van sommigen dat dit "alleen in een universitaire omgeving" zin heeft.

[HawVer]

Mastermind schreef op maandag 05 februari 2007 @ 22:57:
Prolog!! AAH!

Een van de laatste opdrachten die ik moest doen op de Hanzehogeschool HIO ging alsvolgt (ik heb 'm nog):

[...]

3. Schrijf een rapport van ongeveer drieduizend woorden, waarin je:
• De functionaliteit van je programma,
• De uitgevoerde testen en hun resultaat,
• Je eigen oordeel over de kwaliteit van het programma
beschrijft



Lol ik heb de code ook nog zie ik

Man man wat heb ik daar mee zitten hoofdbreken. Maar het werkte...

Lijkt me een leuke opdracht. Echt van die dingen waar je je eerst heel erg in moet verdiepen voordat je een goed programma kan neerzetten.

[Anoniem: 31450]

HawVer schreef op dinsdag 06 februari 2007 @ 08:53:
[...]

Lijkt me een leuke opdracht. Echt van die dingen waar je je eerst heel erg in moet verdiepen voordat je een goed programma kan neerzetten.

Dat is zowiezo iets wat wel aan te raden is, ongeacht de opdracht of de taal.

Ik heb vorig jaar nog een vak over logisch programmeren (in Prolog) gevolgd, helaas is me er niet zo heel veel van bijgebleven omdat ik het in 1 week gedaan heb, wat voor het tentamen ook ruim voldoende was.
Verder heb ik vorig jaar ook nog een vak over functioneel programmeren gevolgd (waarvoor we Miranda gebruikten). Deze twee talen hebben elk zo zijn eigen voor- en nadelen en kunnen voor specifieke problemen toch zeker wel een stuk geschikter zijn dan een iteratieve taal als C of Java. Daarnaast zijn ze ook bedoeld om je algemene inzicht te vergroten, wat je ook weer in andere type talen kunt gebruiken.

[Alarmnummer]

Mastermind schreef op maandag 05 februari 2007 @ 22:57:
Prolog!! AAH!

Prolog kicks ass!

Ik heb in het verleden veel met Prolog gedaan en je moet de knop om zien te krijgen.

Maar afgezien van wat prototyping dingen, doe ik zelf eigelijk niets meer met Prolog.

Ik hoop ook dat er binnenkort meer gedaan gaat worden met 'the right language for the job' op het java platform. Dat geprogrammeer in XML is nasty and Java is een prachtige taal voor bepaalde technische domeinen en het is ook een redelijke all round taal. Maar het moet veel eenvoudiger worden om een taal te pakken die je nodig bent, bv (J)Ruby voor de presentation en business layer of voor de Spring applicatiecontext.

Java als platform = krachtig.
Java als taal =... maar zo zo...

Dus misschien dat het dan ook eenvoudiger gaat worden om meer 'exotische' talen te gaan gebruiken.

En functionele talen kunnen denk ik grote rol spelen doordat ze eenvoudig te multithreaded zijn te maken (je hoeft het niet expliciet te doen zoals bij de meeste imperatieve talen).

[ Voor 53% gewijzigd door Alarmnummer op 06-02-2007 10:57 ]

[The Eagle]

@Alarmnummer: Java @runtime: behoorlijk traag, tenzij er zware hardware ingezet wordt.
Als ik Oracle's ERP suite (die vrijwel geheel Java gebaseerd is) vergelijk met PeopleSoft, dan is Oracle op snellere hardware niet vooruit te branden.

[Alarmnummer]

The Eagle schreef op dinsdag 06 februari 2007 @ 11:13:
@Alarmnummer: Java @runtime: behoorlijk traag, tenzij er zware hardware ingezet wordt.

Ik ga geen tijd verspillen om op dit soort FUD te reageren.

[edit]
klein beetje tijd dan.
1) Java is niet zo traag meer als het ooit eens is geweest
2) Java compileert naar native instructies en kan gebruik maken van runtime kennis om bepaalde optimalisaties uit te voeren, integenstelling tot platformen waarbij er volledige statische compilatie wordt gedaan zoals c/c++.
3) Je kunt een met goed platform, een traag product neerzetten. EJB is wel een van de meest bekende oorzaken van trage software omdat het niet goed wordt gebruikt.
4) De snelheid van applicaties zit hem vaak niet alleen in de hardware, maar in de IO. Vaak zijn externe systemen de bottleneck (bv databases).

En hardware kost geen kont meer. Als je kijkt naar wat een gemiddelde developer per uur kost (75/150 euro per uur), dan is wat meer hardware voor de meeste enterprise applicaties niet zo'n groot issue.

[ Voor 65% gewijzigd door Alarmnummer op 06-02-2007 11:39 ]

[Xymox]

Anoniem: 14065 schreef op maandag 05 februari 2007 @ 22:28:
Zeer waarschijnlijk kom je bij banken nog een hoop COBOL tegen. Ongedocumenteerd welteverstaan, met geen hond die meer weet hoe het werkt...

Vooral grote bedrijven hebben core applicaties in Cobol op mainframe draaien. Zoals bij Centraal Beheer Achmea, waar erg veel Cobol applicaties draaien. Ook nieuwe projecten worden in deze ontwikkelomgeving opgeleverd. Voordeel is de snelheid. Cobol is onklopbaar wat performance betreft en de machines waar dit op draait zijn uiterst stabiel. Kost wel een paar centen trouwens.

Een ontwikkelomgeving waar ik mee werk is Gupta SqlWindows. Dit was de eerste visuele ontwikkeltool op Windows. Daar worden momenteel veel projecten mee gedaan. Voordeel is de ontwikkeltijd die vele malen korter is dan de mainstream omgevingen van tegenwoordig. Nadeel is de onbekendheid van de omgeving en daarmee het tekort aan ontwikkelaars. Voordeel is dan meteen dat het uurloon voor professionals weer een stuk hoger kan liggen.

De nieuwere versies van Gupta Team Developer zijn trouwens cross platform. De applicaties die je bouwt kan je zonder veel code aanpassingen ook op Linux draaien, zolang je geen specifieke WinAPI's gebruikt.

Het mooiste van de omgeving is de outline editor. Deze feature was er reeds lang voordat Microsoft op het idee kwam inklapbare code in de Studio lijn in te bouwen. Echter kan de implementatie van MS er niet aan tippen. Alle code is gestuctureerd geplaatst in secties. Hierdoor kan je snel definities vinden en wordt de code automatisch goed uitgelijnd. Ik kan echt niet meer zonder.

[ Voor 3% gewijzigd door Xymox op 06-02-2007 11:38 ]

[The Eagle]

@Alarmnummer: Ik had wel het vermoeden dat ik zo'n reactie uit zou lokken. Maar is gebaseerd op mijn eigen ervaringen, er zullen dan wel prutsende devver's aan het werk geweest zijn als ik je zo lees Anyway, zonder meer inhoudelijke kennis is daar toch niks over te zeggen. Dus ik denk dat we die discussie idd niet aanmoeten

@Xymox: Cobol is idd onklopbaar qua performance, althans van wat ik er van heb gezien. Nadeel is wel dat de echte compilers behoorlijk aan de prijs zijn. Dat krijg je met exotische programmeertalen volgens mij.
Vandaar ook mijn vraag om een freeware cobol compiler onder windows. Werk @een ROC, en mag allemaal niks kosten. Onze cobols zijn gecompileerd onder UNIX omdat we ze daar op draaien @produktieomgeving, maar op mijn beheer/dev-werkstation zou het ook wel handig zijn als ik er 1 had.

[ Voor 20% gewijzigd door The Eagle op 06-02-2007 13:58 ]

[MSalters]

Is Regex een exotische taal? 't Is een behoorlijk verschil met de C/C++/Java/Pascal talen, maar toch een echte taal en breed gebruikt.

[Anoniem: 14829]

Anoniem: 129028 schreef op dinsdag 06 februari 2007 @ 00:21:
Dat is niet in alle "real life" situaties het geval. Er kunnen goede redenen zijn om voor niet-mainstream talen te kiezen. Een van die redenen kan zijn dat je eraan vastzit doordat men ooit is begonnen met zo'n taal.

Onderhoud aan legacy software is altijd een reden om legacy talen te gebruiken. Ik doe zo nu en dan ook nog bugfixes aan programma's die we in Clipper hebben geschreven...

Er is in voorbije jaren vaak gewerkt met allerlei talen die nu "exotisch" zijn. Vergeet niet dat de talen die jij noemt (C#, C++. Java, Delphi) allemaal nog vrij jong zijn. Het is niet voor niets dat Cobol nog zoveel gebruikt wordt. Er was bijv een tijd dat bijv. Lisp een van de meest populaire talen was, om van Ada, Algol en Fortran maar te zwijgen.

C++ en Delphi hebben een basis die niet zo heel erg jong meer zijn, hoor (C en Turbo Pascal). In mijn belevingswereld is Lisp nooit echt populair geweest, behalve als Logo of AutoLisp derivaat (voor resp. onderwijs en scripting taal voor AutoCad).

Voor mijn gevoel is er niks exotisch aan Cobol, Fortran, Algol en Ada. Dat waren toen gewoon de gereedschappen waar je 't mee moest doen.
Object Cobol of Cobol.NET vind ik dan weer een stuk exotischer...

[qless]

Prolog: arggg... maar volgens mij vooral uni/hogeschool werk.
Clean: nog erger komt oa. van Uni Nijmegen vandaan.

Sources zou ik nog ergens moeten hebben liggen...

Werkomgeving:
Perl (intranet oude omgeving)
Php (deels)
C (autocad modules)
C++ (erp systeem)
Fortran (rekensoftware)
Java (fabrieksaansturing)

Eigenlijk zou ik van dit lijstje alleen Fortran, Perl en C aanwijzen als "exotisch"

[sam.vimes]

MSalters schreef op dinsdag 06 februari 2007 @ 20:56:
Is Regex een exotische taal? 't Is een behoorlijk verschil met de C/C++/Java/Pascal talen, maar toch een echte taal en breed gebruikt.

Volgens mij bedoel je REXX. Regex staat voor REGuliere EXpressie, een taal (met zeer veel dialecten) om patroonherkenning op strings uit te voeren.
REXX is vergelijkbaar met DOS batch files, maar dan veel krachtiger (en veel ouder). Ontworpen door IBM. Zie wikipedia.

[sam.vimes]

The Eagle schreef op maandag 05 februari 2007 @ 22:18:
Lisp: wel ooit van gehoord, schijnt ook wel krachtig te zijn, maar ken verder niemand die er iets mee doet.

emacs (the other editor) is voor het grootste deel in Lisp geschreven.
lilypond (een programma om professioneel ogende bladmuziek te maken) idem.

[Anoniem: 82930]

The Eagle schreef op dinsdag 06 februari 2007 @ 13:56:
Cobol is idd onklopbaar qua performance, althans van wat ik er van heb gezien. Nadeel is wel dat de echte compilers behoorlijk aan de prijs zijn. Dat krijg je met exotische programmeertalen volgens mij.
Vandaar ook mijn vraag om een freeware cobol compiler onder windows. Werk @een ROC, en mag allemaal niks kosten. Onze cobols zijn gecompileerd onder UNIX omdat we ze daar op draaien @produktieomgeving, maar op mijn beheer/dev-werkstation zou het ook wel handig zijn als ik er 1 had.

Gratis COBOL-compilers zijn zeldzaam, maar wel bestaande. De beste die je kan vinden is Fujitsu COBOL die gratis is voor studenten.

Verder bestaat er nog OpenCOBOL, maar de ondersteuning hiervan is soms nogal beperkt, alhoewel er wel mensen zijn die er in slagen dit goed in te zetten.

Andere hebben ook bestaan maar zijn vandaag dood of niet meer bruikbaar.

[PrinsEdje80]

Fortran wordt heel veel in de Sterrenkunde gebruikt. Veelal door de 'oude' profs of door mensen die een oud programma hebben en het niet omschrijven naar een 'modernere' taal. Dat laatste onder het motto: "If it ain't broken, don't fix it". De reden waarom fortran (zowel 77 als 95, maar er zijn meer varianten) nogal vaak wordt gebruikt is dat het vaak veel sneller is dan programma's die voortvloeien uit c/c++/etc compilers. In principe niet een probleem zou je denken, maar als je 10-30% tijd kunt besparen op een simulatie van een aantal dagen, dan moet je wel, want supercomputer tijd is duur!

Moet wel toegeven dat ik zelf niet een theoreet ben die supercomputers nodig heeft, maar meer de waarnemer, dus vooral werk met data reductie. Dit gaat meestal in de hogere talen/pakketten, zoals IDL, perl, c/c++, IRAF (laatste is niet echt een taal meer).

[Anoniem: 25712]

Ik vind het inderdaad ook wel interresant of er in 'real life' ^{(management lingo alarm)} dit soort talen worden gebruikt. Werk tegenwoordig veel in Ruby, (meer hype dan exotisch ) maar ons bedrijf is ook serieus bezig om te kijken of we onze backend servers (voor mobiele applicaties) ook niet beter in Erlang kunnen schrijven.

Eerst maar even spiken om te zien hoe het gaat, de initiele verkenningen zien er zeer interresant uit. 'Meeste robuuste' PBX switch ooit (link kan ik zo snel niet meer vinden) blijkt erin geschreven te zijn.
Leuke video over erlang: http://video.google.com/videoplay?docid=-5830318882717959520

Het lijkt in ieder geval alsof Erlang weer van alle kanten wat leven in wordt geblazen. Leuk om te zien voor ons in elk geval. Groot knelpunt blijft natuurlijk het vinden (of omscholen) van developers.

[Dido]

Ik mis een beetje een onderscheid tussen exotisch als in "theoretisch leuk bedacht, maar er is geen serieus programma in te schrijven (Brainfuck anyone?)" en exotisch als in "bestaat daar nog sourcecode van die niet met een hamer en bijtel in het silicium geslagen is?".

In die laatste categorie heb ik gewerkt (of werk nog) met Cobol, RPG, Lansa, Eazytrieve+, CL, JCL en zelfs S390/ASM. Simpelweg omdat je bedrijfssystemen die ooit op een mainframe of midrange in elkaar gezet zijn niet gaat migreren naar nieuwlichterij

[Mithrandir]

Oh mijn god, wat een vreselijk naar filmpje over erlang! Wat een bozo's

Ik gebruik zelf veel prolog op de universiteit, omdat ik AI studeer. Er wordt redelijk veel onderzoek gedaan in prolog, maar wanneer je iets wilt toepassen in een productieomgeving is prolog meestal te langzaam. Het is volgens mij vooral een goede taal om lekker in te prototypen.

[whoami]

Dido schreef op dinsdag 20 maart 2007 @ 13:16:
In die laatste categorie heb ik gewerkt (of werk nog) met Cobol, RPG, Lansa, Eazytrieve+, CL, JCL en zelfs S390/ASM. Simpelweg omdat je bedrijfssystemen die ooit op een mainframe of midrange in elkaar gezet zijn niet gaat migreren naar nieuwlichterij

Dergelijke talen zou ik niet als exotisch bestempelen. Als ze ooit 'mainstream' gebruikt werden, dan zijn het geen exotische talen.
Exotische talen zijn voor mij talen die niet veel gebruikt worden.

[LuCarD]

whoami schreef op dinsdag 20 maart 2007 @ 13:43:
[...]

Dergelijke talen zou ik niet als exotisch bestempelen. Als ze ooit 'mainstream' gebruikt werden, dan zijn het geen exotische talen.
Exotische talen zijn voor mij talen die niet veel gebruikt worden.

Zoals jBase basic? Dat is een leuke taal waar ik regelmatig mee in aanraking kom. Het is een proprietary taal van Temenos. In deze taal word nog actief ontwikkeld.

Het is een leuke taal zonder variables types alles is string. Het is een taal specifiek geschreven voor MV databases ( PICK databases ). De code word door de compiler omgezet naar C code en die word dan weer gecompileerd door een C compiler.
Alle variablen die je in functies aanroepen gebruikt worden zijn ByRef doorgegeven, en dat kan je ook niet wijzigen...
Er word intensief gebruik gemaakt van super globals... ( zoals bij PHP $_GET, $_POST ). Er word binnen jBase alleen ook naar geschreven binnen de applicatie.

[ Voor 10% gewijzigd door LuCarD op 20-03-2007 13:59 ]

[Dido]

whoami schreef op dinsdag 20 maart 2007 @ 13:43:
Dergelijke talen zou ik niet als exotisch bestempelen. Als ze ooit 'mainstream' gebruikt werden, dan zijn het geen exotische talen.

Dat was mijn insteek op zich ook, maar toen las ik de startpost en kwam ik voorbeelden als Fortran tegen. Vandaar mijn opmerking over dat onderscheid tussen exotisch = oude en exotisch = weinig gebruikt.

[dr snuggles]

Ik kan er geen traan om laten dat de oude relikwiën in de kast worden gezet. De talen worden niet voor niets nauwelijks meer gebruikt.

Ook denk ik niet dat je bijzonder veel leert van het spelen met een oude taal. Als je goed bent in taal A, ben je niet automatisch goed in taal B. Van C -> C++ gaan is zo'n voorbeeld. Ik denk wel dat het goed is om de onderliggende taal te begrijpen. Als je iets van assembly weet, dan snap je een stack trace bijvoorbeeld beter.

Mijn meest vreemde taal is denk ik Parallel Fortran .

[Anoniem: 25712]

ik denk trouwens ook dat talen zoals Fortran, Erlang, LISP wat meer gebruikt zou worden als het bedrijfsrisico niet zo hoog was op gebied van programmeurs vinden. Vandaar dat de meeste grote jongens door blijven gaan met ontwikkelen in .NET & Java met (vaak slechte) programmeurs.

[mazz]

Nooit van Assembler gehoord?
Nod32 is daar ook in geprogrammeerd Assembler komt al dicht in de buurt van de 1 en 0 en

[Insanergy]

Ik heb in een ver verleden me nog eens verdiept in lisp (festival, toon/spraakgeneratie).
Het is zeker een krachtige taal, maar het enige wat me nu nog bij staat is het constante gekloot met de haakjes
Hier een stukje code voor het idee:

code:

(defun sphere-intersect (s pt xr yr zr)
  (let* ((c (sphere-center s))
         (n (minroot (+ (sq xr) (sq yr) (sq zr))
                     (* 2 (+ (* (- (x pt) (x c)) xr)
                             (* (- (y pt) (y c)) yr)
                             (* (- (z pt) (z c)) zr)))
                     (+ (sq (- (x pt) (x c)))
                        (sq (- (y pt) (y c)))
                        (sq (- (z pt) (z c)))
                        (- (sq (sphere-radius s)))))))
    (if n
        (make-point :x  (+ (x pt) (* n xr))
                    :y  (+ (y pt) (* n yr))
                    :z  (+ (z pt) (* n zr))))))

[T.T.]

*kleine schop*

Wij gebruiken Erlang nu ook voor een nieuw project. Onze architect had de taal 'ontdekt' en er een Memcached variant in geschreven als oefening (Cacherl) en het bleek inderdaad te voldoen aan de verwachtingen : snel, eenvoudig en robuust.

Ik kan helaas niet precies zeggen wat we doen, maar als je denkt aan Apache FastCGI, dan zou je zeker ook eens naar Erlang moeten kijken. Natuurlijk kennen de meeste programmeurs het niet, maar het is een bijzonder prettige taal om in te werken. Dezelfde architect heeft inmiddels voor een ander project ook een Erlang component geschreven en die is gelijk in productie genomen: presteert fantastisch: lage load, hoge uptime.

Gelukkig hebben we bij mijn werkgever de nodige vrijheid om dingen uit te proberen PHP + Erlang is volgens mij de meest Agile manier van werken die je maar kan bedenken. Super productiviteit

[ Voor 9% gewijzigd door een moderator op 27-04-2008 21:39 . Reden: *url ff weggehaald ;) * ]

[T.T.]

Jammer dat dit topic niet erg actief is. Toch is er weldegelijk nieuws te melden. Zelfs Facebook gebruikt nu Erlang:

http://www.facebook.com/notes.php?id=9445547199

Op mijn website ben ik links aan het verzamelen over Erlang. Fantastische taal, jammer dat het nog weinig gebruikt wordt, maar nu met Facebook denken we een goed argument te hebben om Erlang in ons bedrijf verder te promoten.

[PrisonerOfPain]

T.T. schreef op zondag 27 april 2008 @ 16:16:
*kleine schop*

Wij gebruiken Erlang nu ook voor een nieuw project. Onze architect had de taal 'ontdekt' en er een Memcached variant in geschreven als oefening (Cacherl) en het bleek inderdaad te voldoen aan de verwachtingen : snel, eenvoudig en robuust.

Het eerste waar ik aan dacht toen ik met Erlang in aanraking kwam was hoe ideaal het zou zijn voor development op de PS3; echter weet ik van allebei eigenlijk net niet genoeg om er iets zinnigs over te kunnen zeggen. Zeker de geheugen constraints van het systeem op de core zelf zouden een bottleneck kunnen vormen maar in principe lijken ze qua architectuur perfect op elkaar aan te sluiten.

Gelukkig hebben we bij mijn werkgever de nodige vrijheid om dingen uit te proberen PHP + Erlang is volgens mij de meest Agile manier van werken die je maar kan bedenken. Super productiviteit

Dit klinkt nog best interessant, zou je iets meer uit kunnen diepen waar de combinatie voor gebruikt word en hoe dat in elkaar steekt?

[RayNbow]

Erlang is niet gemaakt voor performance, he?

quote: http://osdir.com/ml/lang....ral/2003-04/msg00350.html

[...]

The *reason* for independent processes is NOT efficiency (I don't give a hoot about efficiency) - it is to allow large teams of programmers to work together. Give each programmer their own processes to work with and let them hack away - if their process dies, who cares, "some other process will fix the error."

[...]

Me, I can make an incorrect program run arbitrarily quickly - that is no challenge, the following program, for example, computes factorial(10000000000) in less than a picotwinkle.

factorial(N) -> 42.

/Joe

[Sebazzz]

mazz schreef op zaterdag 24 maart 2007 @ 00:01:
Nooit van Assembler gehoord?
Nod32 is daar ook in geprogrammeerd Assembler komt al dicht in de buurt van de 1 en 0 en

Assembly is niet echt exotisch. Het wordt nog best wel veel gebruikt hoor.
Rollercoaster Tycoon 1 en 2 en Locomotion zijn bijvoorbeeld puur in x86 assembly geschreven. (buiten de code voor de win32 forms en interface tot direct3d na dan)

[chris]

Wij programmeren in Ruby (OK, misschien niet echt exotisch), maar doen ook veel in Haskell. Tot nu toe hebben we Haskell nog gebruikt voor een commerciële opdracht, maar daar zijn we nu wel actief naar toe aan het werken. Hoewel we er vrij zeker van zijn dat de code beter, onderhoudbaarder en zelfs sneller zal zijn hebben we één groot issue met Haskell: er zijn vrijwel geen bedrijven die de support van een Haskell-project van ons over zouden kunnen nemen.

Binnenkort gaan we bezig met een eigen product dat we wel helemaal in Haskell gaan schrijven, ik ben benieuwd of het daadwerkelijk zo gaat werken als we verwachten!

[T.T.]

PrisonerOfPain schreef op vrijdag 16 mei 2008 @ 19:19:
Dit klinkt nog best interessant, zou je iets meer uit kunnen diepen waar de combinatie voor gebruikt word en hoe dat in elkaar steekt?

Dit is de eerste architectuur die wij ontwikkelen met het Facebook platform in het achterhoofd. We willen dus Agile kunnen werken en makkelijk componenten kunnen toevoegen/uitbreiden enz. Aangezien we geen voorgaande ervaring hebben met dergelijke architecturen, zijn we niet gelijk aan iets als Facebook's Thrift begonnen, maar iets wat makkelijker te begrijpen is.

Wij doen het als volgt:

frontend : html + JS, gegenereerd door PHP (Zend Framework)
api server : geimplementeerd als Erlang, op basis van Mochiweb
backend : C++ application servers, gebruik makend van ofwel MySQL+Memcached of in-house gespecialiseerde database/caching.

De PHP layer heb ik ontworpen, maken gebruik van HTTP protocol om met de API server te communiceren. De berichten zijn JSON gecodeerd. Dus simpelweg curl naar api server. Natuurlijk verstopt in een abstractie laag, zodat ipv HTTP ook sockets gebruikt kunnen worden (mocht de performance tegenvallen) of een ander formaat. In het begin hadden we bovendien nog geen ApiServer en ontwikkelde ik tegen een Mock server.

De ApiServer is grotendeels door onze architect ontwikkeld, gebaseerd op Mochiweb. Het is dus een zeer eenvoudige http server. Ontvangt JSON encoded GET/POST requests en roept vervolgens de juiste Api module aan. De Api module gebruikt een App module die de C++ backend servers aanroept. Hier gebruiken we socket communicatie met een eigen packet format waarbij de body weer JSON encoded is (in binary vorm). Ik heb de ontwikkeling van de ApiServer nu overgenomen en implementeer het verder.

De C++ backend jongens kunnen volledig onafhankelijk hun servers ontwikkelen, via een standaard framework. Zij bieden een API dat de Api Server gebruikt.

Ontwikkelen gaat echt heel soepel, omdat alles mooi is opgebroken in verschillende lagen. Volgens mij hebben we voor elke laag een geschikte taal gebruikt en is alles met http/socket communicatie netjes aan elkaar geknoopt. Ik ben een fan van PHP, maar mocht het om een of andere reden niet goed bevallen, dan is het makkelijk om deze laag door iets anders te vervangen. De PHP laag bevat wel wat logica, maar gebruikt puur en alleen de ApiServer om data te krijgen en op te slaan. We zouden zelfs Ajax requests direct naar onze ApiServer (of via een proxy) kunnen sturen, om zo nog iets betere performance te krijgen. Ook het uitbreiden van services lijkt vrij eenvoudig met deze opzet door het gebruik van PHP + JSON. Je kan gewoon wget op de command line gebruiken om de Api Server te testen.

[ Voor 12% gewijzigd door T.T. op 17-05-2008 12:42 . Reden: typo ]

[ByteDelight]

Ik ben een Smallworld-ontwikkelaar.
Smallworld is een softwarepakket van GE Networks, het betreft een GIS (geografisch informatie systeem).
Wij ontwikkelen in de taal Magik, elke dag, elke week, elk jaar

Magik heeft Smalltalk als basis.
Omdat de branche van Netwerk-bedrijven zo'n 'niche' is, zijn er maar weinig IT-ers die de stap wagen, daarom is het ook moeilijk aan ontwikkelaars te komen.
Ten opzichte van 'administratieve' ontwikkelomgevingen heeft het een extra dynamiek, namelijk dat Smallworld-objecten ook een grafische ligging hebben; het hele systeem is daarop gebaseerd. Je krijgt er een heel ander gevoel bij dan een .NET omgeving.

Er is best wel vraag naar ontwikkelaars voor GIS-systemen, ondanks het beperkte gebruik van de taal.
De salarissen zijn ook best redelijk, misschien vooral omdat het een niche-markt is.

Worden voor andere exotische talen ook nog steeds nieuwelingen aangetrokken om op te leiden?

[Niemand_Anders]

Da's grappig, wij zijn nu juist bezig alles te standariseren naar C# zodat elke programmeur met de code aan de slag kan. Vorig jaar tijdens de orientatie van de verschillende talen zijn wij 19 talen tegen gekomen. Eifel, Fortran, PHP, Perl, Java, C, C++, C#, ASP/VB, VB.NET, Delphi, Ruby, Python, TCL, BASH, etc, etc.

Voor HTML scripting houden wij Javascript aan (we zijn ook tientallen IE-only vbscripts tegengekomen), general development gebeurt in C#, via Mono kunnen applicaties ook voor OS X of Linux (GTK) geschreven worden. Daarnaast gebruiken we bash zowel onder BSD, Linux en Windows (UnixTools).

Developers in 'mijn' team moeten in elk C# machtig zijn, dat is namelijk de primaire taal waarin alles geschreven wordt. Kennis van andere talen is wel meegenomen.

[Sijmen]

Ik gebruik geregeld Objective-C, een taal waar ook weinig mensen van hebben gehoord. Maar echt 'exotisch' zou ik die niet noemen.

Bij ons op school (HBO Technische Informatica) hebben we trouwens alleen maar grote talen gehad. Er zijn wel een paar andere talen genoemd, maar we zijn er nooit mee bezig geweest.

[Zoijar]

Fortran wordt wel veel gebruikt, maar om dat nou exotisch te noemen... zelf gebruik ik het eigenlijk alleen voor LAPACK. Er wordt ook wel veel code in Matlab geschreven; dat is toch wel een taal op zich. Ik probeer altijd een soort van Matlab omgeving in C++ te krijgen door LAPACK en UBLAS bindings te gebruiken, maar het blijft behelpen.

[-Klimaks-]

Wij doen hier alles in Caché ObjectScript, soms zo , maar ook en meestal
Is een opvolger van MUMPS en niet echt bekend, denk ik/

[Gerco]

MUMPS is bij de bezoekers van TheDailyWTF in ieder geval wel bekend (of eerder, berucht)

De opvolger van MUMPS klinkt dan ook niet bepaald veelbelovend...

[Teun_2]

Alarmnummer schreef op dinsdag 06 februari 2007 @ 11:17:
[...]

Ik ga geen tijd verspillen om op dit soort FUD te reageren.

[edit]
klein beetje tijd dan.
1) Java is niet zo traag meer als het ooit eens is geweest

akkoord

2) Java compileert naar native instructies en kan gebruik maken van runtime kennis om bepaalde optimalisaties uit te voeren, integenstelling tot platformen waarbij er volledige statische compilatie wordt gedaan zoals c/c++.

Bij een compilatie van c/c++ compileer je voor een vaststaand platform en ligt het dsu vast welk mogelijkheden je hebt. je kan in veel compilers (vooral intel dan bijv) aangeven dat je ook gebruik wil maken van geavanceerdere instructies voor x86 (sse ofzo). Bij java moeten die optimalisaties nog op runtime worden verwerkt, wat lijdt tot langere opstarttijd. Java compileert NIET naar native instructies, maar naar java-bytecode. Dit ligt er dicht tegenaan, maar is het niet. Een conversieslag is altijd wel nodig.

3) Je kunt een met goed platform, een traag product neerzetten. EJB is wel een van de meest bekende oorzaken van trage software omdat het niet goed wordt gebruikt.
4) De snelheid van applicaties zit hem vaak niet alleen in de hardware, maar in de IO. Vaak zijn externe systemen de bottleneck (bv databases).

Vaak, maar niet altijd.

En hardware kost geen kont meer. Als je kijkt naar wat een gemiddelde developer per uur kost (75/150 euro per uur), dan is wat meer hardware voor de meeste enterprise applicaties niet zo'n groot issue.

Maar als ontwikkeling in java evenveel kost als in c++ en je platform ligt vast, spaar je toch alweer die kost uit. Bij een beperkt aantal applicaties is performance wel belangrijk. (denk aan 3d rendering, databases, etc)

Overigens vraag ik me af hoe het komt dat er voor java eigenlijk nog nooit een 'gewone' compiler is geschreven. Dan zou je de performantie van een taal als c++ hebben. Probleem is dan wel de garbage collection die nu relatief efficient geïmplementeerd wordt, maar dat moet toch op te lossen zijn?

edit: bestaat blijkbaar al: http://schmidt.devlib.org/java/native-compilers.html

Ontopic:
op unief heb ik leren programmeren in Oberon ( ), beetje lisp, beetje haskell, beetje prolog, java, c++ en volgend jaar waarschijnlijk nog wel eentje.

[ Voor 7% gewijzigd door Teun_2 op 19-05-2008 11:40 ]

[.oisyn]

Zoutvat schreef op maandag 19 mei 2008 @ 11:25:
[...]

akkoord

[...]

Bij een compilatie van c/c++ compileer je voor een vaststaand platform en ligt het dsu vast welk mogelijkheden je hebt. je kan in veel compilers (vooral intel dan bijv) aangeven dat je ook gebruik wil maken van geavanceerdere instructies voor x86 (sse ofzo). Bij java moeten die optimalisaties nog op runtime worden verwerkt, wat lijdtleidt tot langere opstarttijd.

Wat natuurlijk ook maar 1 keer hoeft te gebeuren. De resulterende machinecode kan gewoon opgeslagen worden zodat de volgende keer opstarten wel snel is.

Java compileert NIET naar native instructies, maar naar java-bytecode. Dit ligt er dicht tegenaan, maar is het niet. Een conversieslag is altijd wel nodig.

Nou hoef je dat Alarmnummer natuurlijk niet uit te leggen dus je zal het er wel voor de volledigheid bij hebben gezet, maar het is natuurlijk maar hoe je ernaar kijkt. Waar Alarmnummer volgens mij op doelde was dat Java niet geinterpreteerd wordt. En dus gewoon uiteindelijk naar machinecode wordt gecompileerd wat wordt uitgevoerd. Wanneer dat gebeurt is feitelijk niet zo interessant. De bytecode is maar een tussenstap. Een C++ compiler kan dat intern ook best doen voordat de backend er machinecode van maakt voor de opgegeven target processor. De clue was dat machinecode direct op je processor runt .

Het grote voordeel van C++ is het kunnen interfacen met de hardware, en dan denk ik met name aan de processor zelf. De meeste compilers hebben al sinds jaar en dag intrinsics voor SIMD instructies, memory barriers en atomic operations. Nu, met de komst van multicore solutions, zie je die laatste pas een beetje naar Java komen. Maar ik kan nog altijd geen code schrijven waar mooie SIMD instructies uitkomen.

PrisonerOfPain schreef op vrijdag 16 mei 2008 @ 19:19:
[...]

Het eerste waar ik aan dacht toen ik met Erlang in aanraking kwam was hoe ideaal het zou zijn voor development op de PS3; echter weet ik van allebei eigenlijk net niet genoeg om er iets zinnigs over te kunnen zeggen.

Waarom in hemelsnaam? Maar goed, je zei het zelf al: je weet niet genoeg van beide om die conclusie te trekken. Maar waarom trek je die conclusie dan toch?

Sijmen schreef op maandag 19 mei 2008 @ 08:45:
Ik gebruik geregeld Objective-C, een taal waar ook weinig mensen van hebben gehoord. Maar echt 'exotisch' zou ik die niet noemen.

Is dat niet de de-facto Mac ontwikkeltaal? Ik vind 'm iig vreselijk

[ Voor 6% gewijzigd door .oisyn op 19-05-2008 15:15 ]

[-Klimaks-]

Gerco schreef op maandag 19 mei 2008 @ 11:11:
MUMPS is bij de bezoekers van TheDailyWTF in ieder geval wel bekend (of eerder, berucht)

De opvolger van MUMPS klinkt dan ook niet bepaald veelbelovend...

Waarin je opvolger vooral moet zien als : we houden de oude rommel en we kieperen er een semi-objectgeörienteerd-sausje over. Heb hier een stuk OO-code met keihard GOTO statements in. Waarbij de GOTO statements dan nog kunnen zijn label+zoveel lijnen. Lege lijnen tussen voegen kan dus gewoon keihard je code breken. Om van te huilen die MUMPS, maar tis wel snel

[roy-t]

-Klimaks- schreef op maandag 19 mei 2008 @ 15:37:
[...]

Waarin je opvolger vooral moet zien als : we houden de oude rommel en we kieperen er een semi-objectgeörienteerd-sausje over. Heb hier een stuk OO-code met keihard GOTO statements in. Waarbij de GOTO statements dan nog kunnen zijn label+zoveel lijnen. Lege lijnen tussen voegen kan dus gewoon keihard je code breken. Om van te huilen die MUMPS, maar tis wel snel

lol dat klinkt als Visual Basic 6 (waar ik trouwens tijden prettig mee gewerkt heb )

[.oisyn]

En als PHP

[ Voor 142% gewijzigd door .oisyn op 20-05-2008 14:21 ]

[-Klimaks-]

roy-t schreef op dinsdag 20 mei 2008 @ 14:09:
[...]


lol dat klinkt als Visual Basic 6 (waar ik trouwens tijden prettig mee gewerkt heb )

Had ik al verteld dat de database eigenlijk geen database is, maar een multidimensional storage
Bijvoorbeeld voor een artikelglobal:

code:

^ART("Artikel1")="Huppeldepup\EUR\4\"
^ART("Artikel1",0)=etiketinformatie
^ART("Artikel1",1)=enz...

Waarbij er dus geen enkele relatie, indexen enz... bestaan. Dit onderhoud je dus fijn allemaal zelf. Als ik iets verander in de artikelglobal, mag ik nog mooi mee tig indexen gaan aanpassen. Voor meer informatie moet je hier maar eens kijken. Het ziet er leuk uit, maar niet om een ERP-pakket op te bouwen

De gemiddelde MUMPS-programmeur is ook aanhanger van security to obscurity en if it was hard to write, it should be hard (impossible) to read. Aanpassen van die programma's betekent meestal om per commando door het programma te steppen om even te kijken wat er allemaal gebeurd. Geloof me, Visual Basic is heaven in vergelijking met MUMPS

[T.T.]

.oisyn schreef op maandag 19 mei 2008 @ 15:13:
Waarom in hemelsnaam? Maar goed, je zei het zelf al: je weet niet genoeg van beide om die conclusie te trekken. Maar waarom trek je die conclusie dan toch?

Ik denk dat hij dat zei, vanwege de eenvoud om parallele programma's te maken in Erlang (zonder al die deadlock, thread en mutex ellende ). Ik weet niet veel van de PS3, maar ik meen dat de PS3 een aantal gespecialiseerde cpu's heeft die bepaalde taken snel kunnen uitvoeren en een Ibm risc als centrale verdeel processor? Deze architectuur past niet direct bij de Erlang programma's die ik ken. Die gaan er allemaal vanuit dat de cores generieke cpu's zijn. En dan nog, Erlang is meer highlevel werk, voor PS3 programmeren heb je denk ik vaak lowlevel code nodig. Je kan Erlang wellicht wel gebruiken, maar betwijfel of het handig is

[mux]

roy-t schreef op dinsdag 20 mei 2008 @ 14:09:
[...]


lol dat klinkt als Visual Basic 6 (waar ik trouwens tijden prettig mee gewerkt heb )

Ik bewonder je doorzettingsvermogen: ik word zeer moedeloos van Visual Basic. Wat een dramatische taal. Niks komt in de buurt van c-based. Performance, leesbaarheid, timing, ...

In other news: ik zag heel even Logo voorbij komen, heeft iemand hier ervaring met de meest geniale erlang-implementatie SuperLOGO? Ik heb er iets van twee middagen als 11-jarige mee mogen spelen en het was prachtig (maar je wist ook meteen alles wat het wel en niet kon binnen die twee middagen...). Volgens mij was het best obscuur. Niet functioneel, maar zo hoort het ook. Altijd maar van die nuttige talen is ook veel te goede tijdsbesteding.

[PrisonerOfPain]

.oisyn schreef op maandag 19 mei 2008 @ 15:13:
Waarom in hemelsnaam? Maar goed, je zei het zelf al: je weet niet genoeg van beide om die conclusie te trekken. Maar waarom trek je die conclusie dan toch?

Omdat ik wél weet dat voor soort multi-threading systeem goed werkt op de PS3; namelijk een job based systeem (ergo een thread per core en die continu jobs uit een lijst laten trekken en af laten handelen). Ik had het idee dat Erlang mooi aansloot bij die manier van werken. Verder heb ik het idee hier op school ook geopperd maar de leraar was niet bekend genoeg met Erlang om er iets zinnigs over te zeggen (wel met de PS3); vandaar dat ik het idee hier opper.

[ Voor 14% gewijzigd door PrisonerOfPain op 24-05-2008 13:59 ]

[RayNbow]

ssj3gohan schreef op zaterdag 24 mei 2008 @ 13:38:
[...]

Ik bewonder je doorzettingsvermogen: ik word zeer moedeloos van Visual Basic. Wat een dramatische taal.

VB6 werkt prima voor bepaalde zaken en het werd door best veel programmeurs gebruikt. Nu is het natuurlijk zo dat populariteit niets zegt over de kwaliteit van de taal (zie bijv. ook PHP), maar er is een reden waarom VB populair was. De kern van de taal was simpel en het was geschikt voor RAD. Formpje pakken, wat controls op dumpen, beetje code kloppen en je had al een applicatie.

Het probleem was alleen dat VB6 over de jaren gegroeid is tot een wat ongestructureerd zooitje. Je wilt niet weten hoeveel legacy constructies erin zitten. VB6 ondersteunt line numbers in combinatie met goto's. Naast de For/Next en Do/Loop met While/Until heeft VB6 ook nog de oudere While/Wend constructie. En om maar af te ronden, VB6 kent meerdere assignment statements, namelijk Let en Set, waarbij Let de default is en mag worden weggelaten.

Niks komt in de buurt van c-based. Performance, leesbaarheid, timing, ...

Iets wat gebaseerd is op C hoeft niet per se snel te zijn. Sowieso hangt de performance af van de compiler, niet de programmeertaal zelf (wat niets anders is dan wat grammatica, een woordenlijstje en wat betekenisregels).

Verder is leesbaarheid redelijk subjectief. Vroeger had ik echt een hekel aan C-style syntax, maar nu kan ik het gewoon lezen.

In other news: ik zag heel even Logo voorbij komen, heeft iemand hier ervaring met de meest geniale erlang-implementatie SuperLOGO?

Ten eerste, "erlang"-implementatie?
SuperLogo is een Nederlandse implementatie van de taal Logo wat door AW Bruna werd uitgebracht.

Ik heb er iets van twee middagen als 11-jarige mee mogen spelen en het was prachtig (maar je wist ook meteen alles wat het wel en niet kon binnen die twee middagen...). Volgens mij was het best obscuur.

SuperLogo werd voornamelijk gebruikt waar Logo om bekend stond: Turtle graphics.

Niet functioneel, maar zo hoort het ook.

Voor deze betekenis van functioneel kun je beter een synoniem gebruiken als het gaat om programmeertalen. Hiermee voorkom je de verwarring als het gaat om functionele programmeertalen.

Altijd maar van die nuttige talen is ook veel te goede tijdsbesteding.

Waarom zou Logo niet nuttig zijn? Het is educatief. (al wordt het denk ik niet meer zo veel gebruikt )

[Onbekend]

In SuperLogo heb ik vroeger programmaatjes geschreven. Het was toen vrij gemakkelijk en volgens mij heb ik er aardig wat van geleerd.

Even op de TS terug te komen:

In m'n vorige bedrijf heb ik Delphi 7 geprogrammeerd, en het werkte perfect. De nadelen hierbij waren dat we sommige libraries niet konden aanspreken omdat Delphi sommige typen variablen anders behandelt en dat sommige bewerkingen relatief langzaam zijn.


Nu bij m'n nieuwe bedrijf programmeer ik in VB.NET met VS2005. Dat is een en al ellende. Traag opstarten en een trage compiler, beschadigde databases, de standaard controls zitten vol met fouten en visueel ziet het er niet uit.

Edit @hieronder: VS2005 is frustratie. Delphi is wil wat exotisch....

[ Voor 5% gewijzigd door Onbekend op 25-05-2008 13:32 ]

[Confusion]

Onbekend schreef op zondag 25 mei 2008 @ 13:24:
Even op de TS terug te komen:
[..]
Delphi 7
[..]
VB.NET met VS2005.

Ehmm, exotisch?

[Anoniem: 14829]

Onbekend schreef op zondag 25 mei 2008 @ 13:24:
In m'n vorige bedrijf heb ik Delphi 7 geprogrammeerd, en het werkte perfect. De nadelen hierbij waren dat we sommige libraries niet konden aanspreken omdat Delphi sommige typen variablen anders behandelt en dat sommige bewerkingen relatief langzaam zijn.

Ik programmeer al 10 jaar in Delphi (vanaf D2), en heb nog nooit last van bovenstaande 2 'problemen' gehad.
En Delphi exotisch? Misschien ietsje meer niche tegenwoordig, maar toch nog heel erg veel gebruikt. En 't is gewoon een erg prettige en performante ontwikkelomgeving.

[ToolkiT]

The Eagle schreef op dinsdag 06 februari 2007 @ 13:56:
@Alarmnummer: Ik had wel het vermoeden dat ik zo'n reactie uit zou lokken. Maar is gebaseerd op mijn eigen ervaringen, er zullen dan wel prutsende devver's aan het werk geweest zijn als ik je zo lees Anyway, zonder meer inhoudelijke kennis is daar toch niks over te zeggen. Dus ik denk dat we die discussie idd niet aanmoeten

Het enge is dat Fusion door dezelde devers (aangevult met PSFT devers) geschreven word... dus ik ben erg benieuwd..

The Eagle schreef op dinsdag 06 februari 2007 @ 13:56:@Xymox: Cobol is idd onklopbaar qua performance, althans van wat ik er van heb gezien. Nadeel is wel dat de echte compilers behoorlijk aan de prijs zijn. Dat krijg je met exotische programmeertalen volgens mij.
Vandaar ook mijn vraag om een freeware cobol compiler onder windows. Werk @een ROC, en mag allemaal niks kosten. Onze cobols zijn gecompileerd onder UNIX omdat we ze daar op draaien @produktieomgeving, maar op mijn beheer/dev-werkstation zou het ook wel handig zijn als ik er 1 had.

kijk eens op http://edelivery.oracle.com/ misschien staat er daar 1 tussen.. waarschijnlijk valt dat wel onder jullie license...

[HawVer]

Onbekend schreef op zondag 25 mei 2008 @ 13:24:
In SuperLogo heb ik vroeger programmaatjes geschreven. Het was toen vrij gemakkelijk en volgens mij heb ik er aardig wat van geleerd.

Even op de TS terug te komen:

In m'n vorige bedrijf heb ik Delphi 7 geprogrammeerd, en het werkte perfect. De nadelen hierbij waren dat we sommige libraries niet konden aanspreken omdat Delphi sommige typen variablen anders behandelt en dat sommige bewerkingen relatief langzaam zijn.

Met Delphi 7 heb ik nooit snelheidsproblemen gehad..

Nu bij m'n nieuwe bedrijf programmeer ik in VB.NET met VS2005. Dat is een en al ellende. Traag opstarten en een trage compiler, beschadigde databases, de standaard controls zitten vol met fouten en visueel ziet het er niet uit.

Edit @hieronder: VS2005 is frustratie. Delphi is wil wat exotisch....

VS2005 idem.. Vergeleken bij de standaard controls van Delphi heb je met Visual Studio toch een mooi setje standaard controls en wat is er visueel mis mee? Voor een skin oid zul je toch echt naar producten van derden moeten kijken.

[phobosdeimos]

Professioneel ben ik vooral bezig met Python (80%) en onderhoud van legacy Perl code (20%).
Plus hier en daar wat kleine shell scriptjes (bash).
In mijn vrije tijd gebruik ik ook nog C, C++ en Scheme erbij.
Ben reuze blij dat ik mijn handen niet hoef vuil te maken aan Java/C# zoals de andere 98% van hedendaagse programmeurs.

[HawVer]

phobosdeimos schreef op vrijdag 11 juli 2008 @ 10:32:
Ben reuze blij dat ik mijn handen niet hoef vuil te maken aan Java/C# zoals de andere 98% van hedendaagse programmeurs.

En waarom niet?

[RobLemmens]

Hier werken we nog met Progress voor ons financiele pakket. Het is een heel flexibel platform voor wat betreft data verweking, zeker voor de tijd waaruit het pakket stamt maar de originele devver heeft er gigantische zooi van gemaakt: .... 700+ source files die elk direct richting de daily wtf kunnen, _alle_ vars zijn globaal, het barst van de includes, string database velden die gevuld zijn met
numerics, of mooier, een int gevuld met een ?... Een sql client die niet werkt doordat de db vulling ongelijk is aan de definitie (vraag me niet hoe dat kan), enz. Gelukkig is de rest in Delphi & C++ en door ons opgezet.

[Vaudtje]

offtopic:
Ik kwam een programeertalen-shootout tegen die wel eniszins gerelateerd is.
De reacties zijn soms ook sterk: "AND WHAT ABOUT COBOL YELLING ALL THE TIME?"

[ Voor 17% gewijzigd door Vaudtje op 11-07-2008 13:10 ]

[phobosdeimos]

HawVer schreef op vrijdag 11 juli 2008 @ 12:22:
[...]

En waarom niet?

Om flame wars te vermijden: grotendeels een kwestie van persoonlijke smaak.

[.oisyn]

Hah, 20% van de tijd in Perl moeten werken en dan blij zijn dat je niets met Java of C# hoeft te doen. Masochist!

[phobosdeimos]

Vind ik niet, code schrijven in Java (wat ik al een paar jaar niet meer heb hoeven doen), dat voelt pas aan als zelfpijniging.
Perl code vloeit eigenlijk vlot uit mijn gedachtengang.
Dat gevoel heb ik allerminst niet bij een super expliciete taal als Java, waar je 3000 lijntjes moet schrijven om de meest eenvoudige dingen gedaan te krijgen.
En dan nog die dwang om alles in OO te doen, argh.
Multi-paradigm programming FTW!

P.S. nu ik er wat langer over nadenk is de verhouding van de laatste maanden eerder 90% python, 5% perl, 5% javascript/html/css

[ Voor 13% gewijzigd door phobosdeimos op 11-07-2008 13:21 ]

[Creepy]

offtopic:
Als ik het zo bekijk is je oordeel over Java meer gebaseerd op vooroordelen dan iets anders

Maaruh, alleen Scheme zou ik onder "exotisch" willen scharen, de overige talen die je noemt zijn wat mij betreft nu niet echt exotisch te noemen (met als Delphi trouwens)

[ Voor 4% gewijzigd door Creepy op 11-07-2008 13:42 ]

[roy-t]

Onbekend schreef op zondag 25 mei 2008 @ 13:24:
Nu bij m'n nieuwe bedrijf programmeer ik in VB.NET met VS2005. Dat is een en al ellende. Traag opstarten en een trage compiler, beschadigde databases, de standaard controls zitten vol met fouten en visueel ziet het er niet uit.

Edit @hieronder: VS2005 is frustratie. Delphi is wil wat exotisch....

Ehm, ik werk dagenlijks met C#.NET (gebruikt dezelfde runtime en controls als VB.net). Ik heb echt nog nooit fouten in controls gevonden. (ok het enige dat ik kon bedenken was dat een list (het control) geen events had voor itemAdded/itemRemoved). Verder ben ik echt nog geen gekke dingen tegen gekomen en werk er nu toch al meer dan een jaar mee.

Ik ben wel benieuwd naar voorbeelden.


Verder beschadigde databases? Dit kan inherent niet liggen aan VB.Net omdat deze communiceerd via een dataprovider met de database. De interface naar de dataprovider moet je zelf schrijven, en de dataprovider zelf is niet van .Net, zelfs als je MSSQL gebruikt daar wordt namenlijk een eigen dataprovider voor gebruikt. Natuurlijk is er wel de Data namespace en databinding maar dat gaat toch allemala net even anders.

Ik ben erg benieuwd tegen welke problemen je bent aangelopen.

Nog even een "exotische taal" voor het ontopic . Ik gebruik zelf af en toe HLSL (High Level Shader Language) voor wat game probeerseltjes en 3D rendering experimenten. Het is niet echt exotisch als in de meeste gamedevelopers die programmeren tegen DX aan zullen het wel gebruiken, maar het is wel een bijzonder taaltje af en toe vind ik. Ook heb ik eens 68KASM aangeraakt en VHDL. (niets met shaders te maken).

Verder programmeer ik in de "standaard" talen, C#, Java en VB6, en met alle 3 ben ik eigenlijk redelijk content, zelfs met VB6. Ik ben wel benieuwd naar talen als C++ om is flink unmanaged bezig te gaan, maar vanuit mijn opleiding zal dat vanzelf komen (Informatica op de RUG) en tot nu toe ben ik nog meer dan zoet met de geheimen van OO en managed talen.

[ Voor 26% gewijzigd door roy-t op 11-07-2008 13:56 ]

[Korakal]

bverstee schreef op zaterdag 17 mei 2008 @ 07:15:
Ik ben een Smallworld-ontwikkelaar.
Smallworld is een softwarepakket van GE Networks, het betreft een GIS (geografisch informatie systeem).
Wij ontwikkelen in de taal Magik, elke dag, elke week, elk jaar

Magik heeft Smalltalk als basis.
Omdat de branche van Netwerk-bedrijven zo'n 'niche' is, zijn er maar weinig IT-ers die de stap wagen, daarom is het ook moeilijk aan ontwikkelaars te komen.
Ten opzichte van 'administratieve' ontwikkelomgevingen heeft het een extra dynamiek, namelijk dat Smallworld-objecten ook een grafische ligging hebben; het hele systeem is daarop gebaseerd. Je krijgt er een heel ander gevoel bij dan een .NET omgeving.

Er is best wel vraag naar ontwikkelaars voor GIS-systemen, ondanks het beperkte gebruik van de taal.
De salarissen zijn ook best redelijk, misschien vooral omdat het een niche-markt is.

Worden voor andere exotische talen ook nog steeds nieuwelingen aangetrokken om op te leiden?

Hé cool, nog ééntje! Ik ben ook Smallworld ontwikkelaar! Als één van de weinige nieuwe aanwas, want ik heb het de afgelopen 2 jaar geleerd en nu is het mijn dagelijkse job.

Heb laatst eens zitten tellen, maar er zijn in Nederland toch op z'n minst 100 man in meer of mindere mate mee bezig... exotisch zat?

[phobosdeimos]

Creepy schreef op vrijdag 11 juli 2008 @ 13:36:

offtopic:
Als ik het zo bekijk is je oordeel over Java meer gebaseerd op vooroordelen dan iets anders

Maaruh, alleen Scheme zou ik onder "exotisch" willen scharen, de overige talen die je noemt zijn wat mij betreft nu niet echt exotisch te noemen (met als Delphi trouwens)

Zoek even op monsterboard naar de termen Java, C#, Perl en Python.
Conclusie: java en .NET maken 99.9% van de markt uit.
Dus mag je de overblijvers best exotisch noemen, althans op de jobmarkt (idd niet in hobby en opensource land).

[Creepy]

Uit de topicstart:
Hier in Programming zie je voornamelijk de veelgebruikte talen voorkomen als Java, C++, C#, VB en PHP. Perl, Python, Javascript en Pascal zie je ook nog wel eens. Maar je hoort maar zeer zelden iets over de wat meer exotische (en vaak naar mijn mening veel leukere en interessantere) talen als Lisp, Smalltalk, of zelfs Prolog, Haskell, Ocaml of Erlang...

Talen in de praktijk != talen op de jobmarkt.

Als we jouw conclusie van 99% = java en .NET gaan doortrekken dan zou PHP ook en exotische taal zijn.

[ Voor 10% gewijzigd door Creepy op 11-07-2008 14:18 ]

[phobosdeimos]

Daarom dat ik even verduidelijk dat ik meer over de jobmarkt sprak.
PHP was ik even over het hoofd gezien daarbij.

[.oisyn]

phobosdeimos schreef op vrijdag 11 juli 2008 @ 14:10:
Dus mag je de overblijvers best exotisch noemen, althans op de jobmarkt (idd niet in hobby en opensource land).

Want opensource is geen onderdeel van de jobmarkt?

[farlane]

roy-t schreef op vrijdag 11 juli 2008 @ 13:51:
Ehm, ik werk dagenlijks met C#.NET (gebruikt dezelfde runtime en controls als VB.net). Ik heb echt nog nooit fouten in controls gevonden.

Gebruik je wel eens DateTimePicker of DataGridViews?

[YopY]

Nu ik dit topic lees zou ik toch wel eens goeie cijfers willen zien over het gebruik van programmeertalen. Misschien een leuk idee voor een internet-enquete oid?