Wat programmeren jullie allemaal
 

Dit topic is puur uit nieuwschierigheid, willen jullie neerzetten in welke talen en scripting /website talen jullie programmeren. en dan op volgorde van welke je het meest gebruikt.

En als het er dan nog af akn graag vermelden wat voor soorrtprogramma's je het meeste maakt, en wat voor soort website.

Bij voorbaat dank

Programmeertalen:
-Assembly
-Visual Basic 6.0
-Java
-C(++) (alleen als het moet)


Html / scripting / overige:
Php
MySql
Html
JavaScript
Vbscript


Programma's:
Dll's
Simpele Games
TestProgramma's (om ff een dll of een api te testen)

Sites:
Momenteel site metphp en MySql, aanbieden vna freeware en tools, items via de database

Programmeertalen:
-Delphi Pascal
-Java

Html / scripting / overige:
-Php
-Sql (weet niet of je dit een taal kan noemen.. eerder een interface met je db).
-Html

Programma's:
- Informatie systemen

Sites:
- CMS'en
- Message Boards

Een petit peu ASP en PHP, en de videorecorder.

Voornamelijk PHP. Veel talen een beetje, maar ze bevallen me toch niet; PHP vind ik heerlijk coden. Bovendien trekt webdevelopment me veel meer. :cool:

Python! :cool:
PHP

Verder XHTML, meestal icm CSS (d0h) en een klein stukje JavaScript, maar via XML en vooral niet te vergeten XSLT.

Ik heb ook wel eens wat Java en C++ gedaan, maar die vind ik te low-level.

Mijn wekker als ik vroeg op moet,

Verder PHP en MySQL en dus ook een beetje HTML om het aan te kleden.

Visual FoxPro
C#


Perl
PHP
(x)HTML & CSS 2.1

MS SQL Server 2000 / 2005
Active Directory

Voornamelijk C# en Java omdat dat de voornaamste enterprise talen zijn, ik ben nu voor een klant bezig de PHP2Java bridge te evalueren (en zie ook weer waarom ik blij ben geen PHP meer te hoeven doen). Als de keuze aan ons is doen we het in C#, maar het gebeurt regelmatig dat we in bestaande systemen moeten integreren, dus dan is het afhankelijk van de klant.

Ik programmeer eigenlijk nooit meer voor mezelf, vind 8 uur per dag wel genoeg ;)

Misschien een beetje offtopic en aso, maar ik kan het niet laten om te vragen wat je ongeveer verdient per maand? Met programmeren als fulltime baan.(A)

Nouja, ik ben geen programmeur, maar consultant, ik programmeer niet 8 uur per dag (gelukkig), veel werk is bij klanten langsgaan, systeemontwerpen maken e.d. Ik stuur je wel even een PM.

professioneeel?
taal:
* php, sql, javascript
SQL is wel een taal, en een bijzonder weirde ook!

dingen:
www.eigenspel.nl, www.paginamarkt.nl, www.marktgrazer.nl

(javascript is de gaafste taal in webdevelopment)


voor de lol?
taal:
* c, ruby, lisp
dingen:
NIL (interpreter voor LISP, met gc, lexical scoping, en objects, nog in alfa)
kleine dingetjes

verdien:
10 euro/uur

C++
Delphi

OpenGL
Allegro
OpenLayer


werk:
Simulatie software

vrije tijd:
Games
Educatieve software
Aries Software

Turbo Pascal
af en toe een Firmware aanpassen
en binnenkort de computer van mijn Pontiac Firebird

Basic! :cool:

(en html, bash, zeer klein beetje mysql, java en c.)

In volgorde van meestgebruikt naar zelden:

Php, sql, bash, java, python, perl, javascript, C++

Java beheers ik het beste (servlets, JSP, EJB, SOA e.d.), maar ik ben gewoon niet zo kapot van de taal.

Kwa verdiensten is niet je uurtarief interessant, maar wat je bruto per maand verdient. Als je een paar dagen per maand werkt pikt de overheid niks in, maar bij een fulltime baan sta je ongeveer 50% af aan die klootzakken ;)

Coden is de laatste tijd heel wat minder, maar toch de volgende talen:
(Q)Basic, Objet Pascal (Delphi als IDE dus), beetje Visual Basic en Visual Basic for Applications (in Office dus). Ook al eventjes met PHP en (My)SQL bezig en daar ben ik de laatste tijd meer in bezig dan in de rest.

QBasic was vroeger mijn taal, in het Windows 95-tijdperk (ja, je moet het ergens mee leren he), Object Pascal is de taal die ik gebruik om simpele dingetjes te implementeren in Windows, gewoon vlug eventjes iets in elkaar flansen, kleine tooltjes enzo. Visual Basic heb ik na QBasic een tijdje gebruikt, niet echt mijn favoriete taal, dat is ook de reden dat ik toen op Object Pascal ben overgegaan en later heb ik zelfs op school het gewone (Turbo) Pascal moeten 'leren'.

Assembly lezen lukt vaak ook nog net wel, alleen heb ik er dan beter een boek bijliggen, omdat ik er nooit echt zelf in geprogrammeerd heb (daarvoor is het iets te omslachtig en heb ik het nooit echt nodig gehad, maar wel een boek erover gekocht omdat ASM altijd handig kan zijn).

In PHP is mijn huidige project een soort bestandsdeelportal, vermits ik op locatie niet aan mijn bestanden thuis geraak (Telenet blokkeert de toegang van buitenaf blijkbaar, plus nog een NAT tussen) ga ik dus op een publieke server een database (MySQL) en webpagina (PHP in combinatie met HTML/XHTML en CSS normaal) maken van waarop ik een bepaald request kan sturen naar mijn thuiscomputer die met behulp van een zelfgeschreven client-programma (in Object Pascal hoogstwaarschijnlijk, of misschien toch gewoon één of ander scriptje in command line PHP) dan eerst controleert of het bestand verstuurd mag worden (naar mijn e-mail, naar een e-mail van iemand anders of naar een bepaalde FTP-server etc.) door mij te vragen of het bestand verstuurd mag worden en het dan pas te versturen naar dat mailadres of naar die server.

Programmeertalen:
Visual Basic 2005 (pas een maandje mee begonnen, ik ga in de winter pas weer verder)

Html / scripting / overige:
Php
MySql
Html
JavaScript


Hiermee al van alles gemaakt: website, gastenboek, forum, webshop (schoolopdracht) en meer van zulke dingen.

HTML kan ik niet echt een programmeertaal noemen, maar ik beheers 't wel, dan nu van volgorde van tijd (chronologisch, ja)

Basic
Q-Basic
VB
(BATCH)
(HTML)
mIRC-scripting
JavaScript
PHP
MySQL (????? programmeer taal ?)
TCL
Perl
Python
C

Misschien nog wat vergeten, maar dat zal dan iets zijn waar ik niet echt heel lang mee bezig ben geweest (ik probeer graag nieuwe dingen uit ^_^)
En vaak repareerde ik dingen, als ik een script/programma niet volledig aan m'n wensen voldeed, maar dan beheers ik de taal niet echt, maar verander andermans code

SQL is een programmeertaal, ja, met procedures, events, if-then-else, iteratie/recursie, aritmetiek, etc.

Hmm... Haal je SQL dan niet door de war met PL/SQL?

hmm hmm
dat zou kunnen
dan nog is het een programmertaal wat mij betreft :-)

PHP, SQL, ActionScript en HTML en CSS.
En XML, voor zover als dat telt.

Ik nerd ik.

mhoah, een SQL syntax maken vind ik niet echt programmeren, alhoewel 't er idd wel dicht tegenaan zit (struggles als 't niet doet wat je verwacht :P)

En jah, als HTML als taal geld, zit je met XML ook wel goed :)

Leuk en aardig, maar ik zou het niet op een jobinterview melden ;) Je moet bij ons niet aankomen met SQL als een programmeertaal. SQL staat voor Structured Query Language, het is precies dat, een query language. Verwar ook SQL niet met alle script zooi die DB vendors eromheen hangen, dat is compleet wat anders.

Ook hier geldt: alleen PHP en waarschijnlijk actionscript (ken het niet maar zal wel JS achtig zijn) zijn programmeertalen. HTML en CSS is puur textopmaak, XML is een data modelling language.

html, css, xml en as :)

mwah, het enige dat ik niet mag noemen op een jobinterview is tot nu toe LISP geweest, sommige mensen hebben daar nogal een allergische reactie op :P

(En dan vraag je wat ze zelf programmeren en dan is het java/php :rolleyes: )

Lots of Insignificant Silly Parentheses was het geloof ik? :)

Wat is er mis met Java? Een van de meest gebruikte enterprise talen.

Pfff; vrij lomp dat ze allergisch zijn voor LISP. Als je dat er tussen hebt maakt dat IMHO juist duidelijk dat je echt kan programmeren.

En met Java is genoeg mis: zelf vind ik statische typering achterhaald, maar er zijn volgens mij op internet genoeg artikelen te vinden over wat er zoal mis is met Java.

Waarom?

Err, static typing is goed. Er gaat geen enkele taal doorbreken die niet static types is. Als je als programmeur niet vooraf weet wat voor'n type je primitive wordt, moet je niet gaan programmeren.

Daarnaast is het leuk en aardig dat sommige mensen Java niks vinden, maar de markt spreekt voor zich.

Alleen statische types bieden je maar heel weinig zekerheid. Als je echt goed geteste code wil hebben moet je toch aan de unit tests. Daarentegen kost zijn aan statische typering kosten verbonden, in termen van programmer productivity.

Chimera: het is nogal makkelijk om te zeggen dat er geen taal gaat doorbreken die geen statische types heeft. Volgens mij is PHP al jaren aan het groeien, terwijl recentelijker ook Ruby en Python steeds meer aandacht krijgen. Ik zeg niet dat ze het marktaandeel van Java al geevenaard hebben, maar wel dat het best eens zou kunnen dat een van die talen Java zal gaan evenaren of overtreffen. Ook de bewustheid van dynamische talen in de enterprise neemt volgens mij toe.

Oh, das nieuw.

Dus perl en php zijn niet de meest populaire scriptingtalen? Want ik dacht toch echt, dat die dynamische typing hadden?
En ruby is zeker plotseling statically typed? Net als python?

Ik denk dat statische types uiteindelijk je programma limiteren. Want ik heb het idee dat je van te voren zelden weet wat voor type je variabelen moet zijn. Bovendien is er het idee van 'closure'; dat alles wat je in een taal maakt je ook in die taal kan gebruiken als object. Als je taal types statisch definieert, dan werk je daar jezelf mee tegen als je abstracties hoger wil leggen. Maar ik kan dat het beste door SICP
laten uitleggen :)

Wat betreft de populariteit van java, je zou toch niet echt zeggen dat COBOL (ook eens de meest populaire taal) een betere taal was dan LISP (uit dezelfde tijd)?
Ik hoop het in ieder geval niet.

Heerlijk dynamic typing! En wat is er mis met type casting op de plaats waar je deze nodig hebt?

Het is maar hoe je als programmeur wenst te werken. Sommigen houden van een heel stricte taal als Java en anderen van een veel lossere taal als PHP. Persoonlijk schrijf ik PHP apps met een veel grotere snelheid dan Java. En Java trekt me sowieso al niet door de licentie-issues.

Als iemand die toch al een paar jaartjes in het vak zit kan ik je zeggen dat dat laatste sowieso grote onzin is :)

En dat je unit tests nodig hebt, dat heeft bijzonder weinig met al dan niet hebben van statische typing te maken.

Ik weet niet wat jij enterprise noemt, maar van al onze klanten (25+) gebruiken er welgeteld 2 PHP (rest is vooral Java of .Net gebaseerd), en die zijn beiden in verhouding tot andere klanten gewoon hardstikke klein. We hebben het hier over systemen die miljoenen kosten. Een simpele site heeft niks met enterprise level applications te maken.

Ruby en Python zie je gewoon helemaal nergens.

Ghe. Ja, leuk dat je daar je hobby projectjes in klust, maar noem eens een paar grote bedrijven die Python gebaseerd zijn?

Dan ben je een slechte SE. Ontwerp -> Programmeren. Niet andersom.

Programmeertalen:
-Basic (GW/Q/VB/VBS)
-2 paar naamloze talen voor m'n werk.
-tijdje geleden beetje C#

Html / scripting / overige:
-Perl
-PHP
-SQL
-HTML
-CSS
-JavaScript
-VBScript

Programma's:
Simpele dingetjes zoals sudoku solver of een kaartspel of pff, kleine webapplicaties. Ooit voor de gein het s.com forum via een C# programma gelinked met MSN's sms service; sms'en van/naar 't forum (n) :D. Hele directory vol met onafgemaakte shit. Vroeger in basic kleine spelletje en dat soort shit. Ooit in qb45 een MSN client geschreven; en geholpen aan een 4-op-een-rij over internet in qb45 :o . Javascript, perl, VBScript gebruik ik meer op m'n werk. C# al een tijd niet gedaan. Ook wat kleine dingen in vb gemaakt om me te helpen bij m'n werk.

Sites:
Met HTML/CSS/PHP/MySQL gewoon een simpele site voor een stuk of 30 ex-basic fanaten die nu meer over religieuze zaken zeuren.

ojah, dat ken ik, een hele map met progjes die half werken in alle mogelijke talen
ik heb ook een sudoku-solver onlangs gemaakt, in PHP. Kaartspelletjes heb ik ook gemaakt (TCL en VB), maar ik heb ze nooit echt afgemaakt

"vroeger" in basic heb ik veel game's aangepast, allemaal hacks toegebracht zoals onsterfelijkheid enzo, wat was dat geweldig leuk ^_^ (en gemakkelijk, als 8-jarig jochie kon ik ik games hacken, paar jaar later ook m'n eigen games 'gemaakt')

Nou, PHP en Perl zijn zeker ook dynamisch getypeerd, al denk ik zelf dat Perl stagnerende is, zie ook "Perl is dying" op perlmonks.com (de permalink werkt momenteel niet).


Ik zeg alleen dat statische typering weinig toevoegt bovenop unit tests.

Google gebruikt Python extensief, Philips gebruikt het in zijn semiconductor line, NYSE, Industrial Light & Magic, Honeywell, en vele anderen.

:D (y) Dat hoort erbij :D Ik ben (helaas) mijn basic map met alle rotzooi kwijtgeraakt :'-( Kaartspel wat ik gemaakt heb was omdat m'n vriendin me een chinees kaartspel had geleerd; hij is eigenlijk redelijk af; alleen de AI moe(s)t flink verbeterd worden. m'n vriendin verslaat de computer telkens :'-( (n) )

Bwhehe ja dat ken ik ja :D Dingen overtypen uit boeken/tijdschriften en dan helemaal aanpassen. :o

Mee eens. Je hebt ook unit tests nodig in java.

Ik werk in web development. Het is moeilijk om een site te vinden die *niet* in php is gemaakt :) Dat zou ik ook liever veranderen, vind php een baggertaal die eigenlijk veel te weinig begrijpt van wat je aan het doen bent, maar van de andere kant, daar hebben de jsp's ook last van.


Hmm, amazon gebruikt perl (en zelfs emacs lisp), google gebruikt python, 37signals gebruikt ruby. Geen kleine applicaties zijn dat.


Beard; de aanname dat het zo simpel zou zijn, is de dood van een verschrikkelijk groot aantal projecten. Het *kan* goed uitwerken, maar ik heb met teveel codebases gewerkt die zo in elkaar gedraaid zijn dat ik erin geloof.

Wat moet je dan, volgens mij, wel doen?

Bedenken wat je wil bereiken, en dan:
loop:
programmeren -> evalueren -> abstracties maken/veranderen -> testen

Waarbij je iedere keer op een 'hoger niveau' werkt dan de andere keer. Als je niet telkens abstracter gaat werken, kom je nooit echt voorruit. De testfase is er om te zorgen dat je abstracties werken. In de programmeerfase maak je gebruik van je abstracties. In de evalueerfase kijk je of je programmeerwerk (en daarmee de gemaaktte abstracties) goed uitwerken; als je programmeerwerk niet goed uitwerkt, heb je waarschijnlijk de verkeerde abstracties gebruikt.

Wat ik bedoel met het gevaar van statische types is dat het je limiteerd in abstractie; je kunt niet oneindig complexere primitieven gebruiken, als je de types van de primitieven van te voren moet specificeren. Daardoor zorg je ervoor dat je abstracties niet 'gesloten' zijn, dwz. je kunt ze niet even makkelijk gebruiken als al bestaande primitieven.

Ik zou iedereen hier aanraden om SICPSICP
toch eens te kijken :).

Het is ook zo eenvoudig. Eerst je ontwerp netjes maken (mbv UML bijvoorbeeld), daarna pas coden.

Nee. Ontwerp -> programeren -> testen -> bugs oplossen -> testen -> bugs oplossen -> testen -> etc...


Je 'abstracties' maak je in de ontwerpfase (Functioneel Ontwerp en Technisch Ontwerp). Daarna weet je gewoon welke types je nodig hebt dus levert het geen enkele beperkingen op voor de programmeur.

Het levert alleen maar voordelen op: minder kans op 'implicit-conversions'-die-toch-niet-kunnen, betere foutafhandeling, compile-time fout-detectie (door incompatible types bijv af te vangen), etc.

Dus nu beweer je dat je nog nooit nodige abstracties bent tegengekomen die je nog niet hebt voorzien in je 'ontwerpfase'?

Dan ben je of heel slim, of je hebt alleen bijzonder simpele dingen gemaakt, of je liegt. Jij kiest.

Ik ontwerp niet; ik programmeer hetgene dat ontworpen is :)

Het ontwerpen van een systeem is een vak opzich. Daarom hebben wij daar ook speciale mensen voor (de 'functioneel ontwerper' bijv.).


Wanneer ik is voor mezelf in elkaar flans, ga ik (uiteraard) niet ontwerpen op papier/uml (teveel werk en niet nodig), maar wel een gedeelte in mijn hoofd. Omdat ik het niet uitteken vergeet ik wel eens diverse 'abastracties', waardoor ik tijdens het programmeren nieuwe objecten bedenk. Maar dit is eerder het gevolg van geen zin hebben in het maken van een fatsoenlijk/degelijk ontwerp, dan het 'niet kunnen'.

En als ik moet kiezen, dan zeg ik: heel slim :p (ervaring)

tsja...

voor een functioneel ontwerp (wat moet het programma doen) ben ik ook wel, daar niet van. Het is belangrijk te weten wat een programma gaat doen, en het liefst ook hoe.

Maar in een technisch ontwerp als oplossing voor alles, daar geloof ik gewoon niet in. Omdat software maken meer is dan simpel regels typen en bugs vinden.

Stel nu dat je een internet-markt aan het maken. En omdat tags helemaal te gek zijn (en bovendien een goede manier om heterogene data te ordenen) wil je die toevoegen aan je werkende systeem; een benodigheid die je nog helemaal niet had voorzien. Wat doe je nu? Een heel nieuw model maken en je software ertegenaan schrijven? Tags eraan hacken?

Beide zijn niet zo aantrekkelijk, of wel?

Het probleem met technische modellen is dat het heel makkelijk is om ze te afhankelijk en rigide te maken (lasagne code). De truc aan het maken van een robuuste codebase is componenten onafhankelijk van elkaar te maken, op elkaar, in verschillende lagen, die door duidelijke abstracties van elkaar gescheiden zijn.

En (in mijn ervaring) bereik je dat vanzelf met het ontwikkelschema dat ik heb laten zien.

Mind you, dat werkt alleen als je werkelijk *tijd* neemt voor iedere fase. Je moet echt evalueren wat je fout deed, of je wel in de goede richting gaat, je moet echt tijd nemen voor je abstracties, je moet echt de tijd nemen om te testen of je nieuwe abstracties niet je systeem breken.

Een voorbeeld van een abstractie waar ik op die manier achter ben gekomen: zelfvalidatie van objecten. Iedereen weet hoe die een class moet schrijven die een object maakt uit een database, wijzigt en opslaat. Waar ik achter kwam is dat in de code buiten die classes nogal veel validatie ('bussines-logic' als ik maar een afgrijselijk woord mag gebruiken) had staan. Door die validatie binnen de class zelf te zetten, was het mogelijk om veel simpelere interactie-pagina's te schrijven.

Wat ik probeer te zeggen: door het ontwerp op te delen in kleinere (meer ad-hoc, toegegeven) stukken die je vaak herhaalt is het vaak veel makkelijker om uiteindelijk een goedwerkend systeem te krijgen, omdat je veel makkelijker kunt inspelen op veranderingen.

Ik doe voor mijn bedrijf ook regelmatig jobinterviews, en een van de 'vervelende' vragen die wij stellen is hoe je het bouwen van een applicatie aanpakt. Wij zijn niet geinteresseerd in mensen die maar wat proggen.

Als je vooraf niet weet wat een applicatie gaat doen, moet je er niet aan beginnen. Een functioneel ontwerp is niet alleen belangrijk voor de programmeur, maar ook om de project scope in de gaten te houden. Feature niet in het ontwerp? Jammer dan, volgende versie.

Helemaal mee eens, functionele ontwerpen zijn noodzakelijk. Je moet wel weten of je de goede richting op gaat.

Maar ook met mate: je moet weten wanneer je van een functioneel ontwerp af kan stappen, of deze moet wijzigen, als de benodigdheden veranderen :)

P.s.: chimera, waar werk je eigenlijk?

Een functioneel ontwerp zegt wat een applicatie moet doen, niet tot in elk detail hoe het gedaan moet worden. Een functioneel ontwerp zegt dus absoluut niet dat class X member Y moet hebben.

Als de klant met andere wensen komt kwa functionaliteit, pas je daar het ontwerp op aan. Je beoordeeld de wijzigingen, kijkt of deze in de beoogde architectuur passen, maakt inschattingen wat betreft de tijd die het je kost, en als dat allemaal rond is, laat je een hele dikke vette handtekening onder het ontwerp zetten. Waarom? omdat je als je lukraak dingen gaat wijzigingen en feature creep modus trechtkomt, je deadlines met 5 maanden overshoot, en het je erg veel geld gaat kosten.

Als ik de link post zie je forum.scholieren.com in de referral logs van onze website, en dat vind ik niet een heel erg goed idee ;)

Ik werk bij een bedrijf dat een database gespecialiseerd in erg snel zoeken levert. Zegmaar Oracle maar dan wel schaalbaar ;) Ik ben consultant, ga dus bij klanten langs om hun te adviseren. Danwel over de koppeling met bestaande systemen, over technische eisen, danwel in de functionele fase. Of ik mag, zoals afgelopen dinsdag, langs komen om uit te leggen welke domme fouten de applicatiebouwer allemaal gemaakt heeft ;) Ons probleem is dat als een applicatiebouwer niet weet waar 'ie mee bezig is (en daar hebben ze vaak last van helaas), onze software niet voldoende benut wordt. Als een klant een zoekmachine in huis heeft die hem veel geld kost, en welke niet gebruikt wordt, is de kans groot dat ze het maintenance contract niet verlengen. Snap je misschien waarom ik zo allergisch ben voor broddelwerk ;)

Dit is helaas eerder regel dan uitzondering, het gebeurt maar al te vaak dat er op contracten gewezen moet worden mbt tot de randvoorwaarden etc :/

Ik heb de problemen vaak genoeg gezien, maar gelukkig is er voor het soort werk dat wij doen vrij makkelijk om alle functionaliteit af te bakenen. Meestal zijn wij sowieso diegene die met ideeen voor bepaalde stukken functionaliteit komen waar ze of niet opkomen, of denken dat het te complex is.

Maar ik zit nu dus met een klant waar de applicatiebouwer fouten gemaakt heeft, het productiesysteem voor een deel niet functioneert en die mensen reageren met "we komen na 31 juli wel een keer langs". Hoewel het helemaal niet ons probleem is, zijn wij nu 't brandje aan 't blussen :)