Gathering of Tweakers

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).

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.

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

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.

quote:

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.

quote:

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.

LuCarD wijzigde dit bericht 20-03-2007 13:59 (10%)

quote:

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.

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 .

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.

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

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:

1 2 3 4 5 6 7 8 9 10 11 12 13 14

(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))))))

*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

Een moderator wijzigde dit bericht 27-04-2008 21:39 (9%)
Reden: *url ff weggehaald ;) *

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.

quote:

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.

quote:

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?

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

quote:

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)

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!

quote:

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.

T.T. wijzigde dit bericht 17-05-2008 12:42 (12%)
Reden: typo

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?

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.

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.

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.

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

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...

quote:

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

quote:

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.

quote:

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.

quote:

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.

Zoutvat wijzigde dit bericht 19-05-2008 11:40 (7%)