[Alg] Kwaliteiten van een goeie programmeur

[whoami]

Op zaterdag 25 mei 2002 20:06 schreef tomato het volgende:

[..]

Volgens mij niet, maar misschien ben ik nu enorm aan het happen naar een programmeur?

Volgens mij is goede schrijftaal en goeie dan eerder spreektaal.

[Dennis]

whoami:
Volgens mij is goede schrijftaal en goeie dan eerder spreektaal.

Volgens mij heb jij gelijk

[dusty]

Op zaterdag 25 mei 2002 14:37 schreef lnfinitive het volgende:
[not serieus mode]

Je bent een goede programmeur als je naar:

http://www.nokia.com/flashd/flash_redir.html?flash=/findyourforce/flash.html

gaat, de StarWars Character test invult en als resultaat R2D2 matched

\me is dus geen programmeur want heb als resultaat Jango Fett...

Ehh.. test gedaan.. resultaat: R2D2

Homeworld: Naboo
Species: Droid
Height: 0.96 Meters
Manufacturer: Indusrial Automation
Type: Astromech Droid
Weapon: rc welder, buzz saw
Vehicle: X-wing
Affiliation: Rebel Alliance

Resourceful, spunky, adventurous.
You aren't afraid to speak your mind and you have a comical streak that will earn you many friends. Sometimes your sarcasm can land you in sticky situations.

De beschrijving klopt wel aardig voor mij

[Verwijderd]

Op zaterdag 25 mei 2002 17:34 schreef JonkieXL het volgende:
Overigens doe ik nu geen VB meer, maar inderdaad waren de classes in VB nogal gelimiteerd (geen overerving, polymorphism en dat soort zaken)

ehh, je kan in VB6 wel degelijk overerven! Er is een Implements statement, dat precies doet wat de naam suggereerd. Hierdoor is er toch een beetje OO mogelijk met VB .

Verder denk dat een programmeur vooral goed logisch kan nadenken, je moet zelf oplossingen kunnen bedenken, ipv. die van anderen ongewijzigd kopiëren. Dit kan zoals Mr_Blue al aangaf best goed getraind worden met een flink portie wiskunde. Helaas, maar waar .

[dusty]

Op zaterdag 25 mei 2002 13:08 schreef Mir het volgende:
Gewoon een paar punten denk ik die mee doen aan het maken van een definitie:
[..]
Iets wat niet echt met de code te maken heeft maar meer met de kunsten van de programmeur;
[..]

Persoonlijk vindt ik de kunsten van een programmeur belangrijker dan de eerste punten, aangezien de eerste punten die jij opnoemde iedereen kan leren, echter de kunsten zijn niet zo makkelijk te leren, en in veel gevallen heb je aanleg voor die kunsten of je hebt er geen aanleg voor.

[farlane]

Op zaterdag 25 mei 2002 20:04 schreef whoami het volgende:
Wat is er mis met goeie? goeie is toch evenzo goed nederlands als goede?

I write code ...

[whoami]

Op zondag 26 mei 2002 13:34 schreef farlane het volgende:

[..]

I write code ...

Ik doe liever meer dan dat. Meewerken met het design enzo.

[Delphi32]

Ik zie op mijn werk globaal gesproken 2 soorten programmeurs:
1. 'geef mij een ontwerp, het liefst uitgewerkt tot op GUI-level, en ik zorg ervoor dat het werkt volgens de specs, zonder dat ik precies hoef te begrijpen WAT ik aan het maken ben. Dat hoef ik ook niet te weten, want mijn verantwoordelijkheid is ervoor te zorgen dat wat ik maak, technisch correct is. En dat is het.'
2. 'ik vind het leuk om programma's te maken waar de klant wat aan heeft. Aangezien ik goed snap waar het over gaat, ga ik graag de discussie aan met de ontwerper om te kijken of er hier en daar verbeteringen mogelijk zijn. Ik wil uiteindelijk datgene opleveren, wat ik zelf zou willen kopen/gebruiken als ik de (potentiële) klant was. Technisch gezien kan ik aardig meekomen maar ik sta altijd open voor verbetering want ik weet dat dit niet mijn sterkste kant is.'

Volgens mij ligt de beoordeling van de oorspronkelijke vraag (wat is een goeie programmeur) voornamelijk in de klemtoon die je in de vraagstelling legt.
Een GOEIE programmeur is een type 2. Hij denkt mee, en zorgt er zo voor dat met de kennis die hij meebrengt het eindproduct zo goed mogelijk aansluit bij de wensen/eisen.
Een goeie PROGRAMMEUR is een type 1. Hij hoeft/kan/wil niet meedenken met wat hij aangeleverd krijgt, zijn focus ligt puur in de technische hoek. Sterk hierin is, dat de meest lastige zaken technisch juist en zwaar geoptimaliseerd gebouwd worden.

Mijns inziens zijn voor het welslagen van een project beide typen noodzakelijk. Ik heb in de praktijk nog maar weinig programmeurs gezien die zowel type 1 als type 2 vertegenwoordigen.

[drm]

Een programmeur die geen 1337-sp34k kan is ook geen goe(i|d)e

Maar goed, de eerste vereisten van een goede programmeur in de zin van coder:

• Hij* drm schrijft nette code
• Hij schrijft performance-gewijs goede code
• Hij weet te coderen als 2^e stap na het programmeren (ik bedoel te zeggen dat je dan elke taal kan beheersen zonder dat je programmeerskillz in 't geding komen)

In commerciele zin:

• Hij is overtuigd dat hij niet altijd het beste doet, en weet dat ook een ander wel eens gelijk kan hebben
• Hij weet zijn punten commercieel over te brengen aan elke andere partij in het bedrijf (dus ook medeprogrammeurs)
• Hij streeft naar verbetering van zichzelf als programmeur, is autodidact en heeft geen manager nodig om 'm te vertellen waar hij mee bezig moet zijn als er niets te doen is (nee, niet GoT-en dus )

_{* drm kan natuurlijk ook een Zij zijn}

[JaQ]

Volgens mij is een programmeur (1) creatief, (2) lui, (3) gehinderd door kennis en (4) goed in "ouwehoeren".

met creatief bedoel ik niet altijd het ge-eikte pad volgend. Een reeds bestaande route is niet altijd de beste. Soms is het verstandig om op een andere taal over te schakelen, kortom: gebruik gereedschap waar het voor bedoeld is. (als je buurman een "netwerkje" wilt hebben hoef je niet per definitie een 1GB glas netwerk bestaande uit sun clustes te bouwen.)

Lui is niet altijd negatief, maar dingen niet dubbel willen doen is een goede eigenschap voor een programmeur. Compacte goed doordachte code, afgeleid van een algoritme (lieft gedocumenteerd).

Gehinderd door kennis ben je als je weet waar je over praat. Het is meer dan vervelend om een stuk code door te moeten worstelen van iemand die bijna wist hoe iets werkte. (je kan moeilijk van een timmerman verwachten dat hij je uitlegd hoe een ziekenfondsverzekering premie berekend bijvoorbeeld)

Met ouwehoeren bedoel ik documenteren en een meer dan redelijke "management-samenvatting" schrijven, oftewel je ideeëen weten te verkopen aan diegenen die uiteindelijk de handtekening onder een contract kunnen / moeten zetten. Zonder deze semi-commerciele kwaliteit kom je op professioneel vlak nooit verder als semi-typgeit die ontwerpen van een ander codeerd.

Het is uiteraard waar dat het internet bedoeld is om kennis te delen (lang leven de GPL), maar aan de andere kant is closed source niet per definitie negatief. Als een bedrijf de moeite neemt om tijd (en geld) te investeren in een product mag dat product toch verkocht worden? Uiteindelijk zullen die vezels waarmee wij GoT kunnen bereiken ook betaald moeten worden. Harstike leuk dat kennis delen, maar zonder closed source bestaat er geen IT-sector. (enkel knip en plak mannetjes / vrouwtjes).

just my 2 cents.

[Dennis]

Die van type 1 en type 2 vind ik wel aardig .

[whoami]

Een goede programmeur moet ook kunnen en willen debuggen en niet direct zijn probleem op GoT posten in de hoop dat er iemand is die het wel eens voor hem oplost.

Die van type 1 en type 2 is goed. De ideale programeur zou een type 3 zijn. Een synergie van type 1 en type 2.

[dusty]

Ik mis de "Een goede programmeur is Sarcastisch"

[Janoz]

Op maandag 27 mei 2002 11:09 schreef dusty het volgende:
Ik mis de "Een goede programmeur is Sarcastisch"

Mischien ben jij wel helemaal geen goede programmeur

[drm]

Een goeie programmeur is eerder cynisch omdat hij baalt van zijn branche...

[superboer]

Ben je een goeie programmeur als je over enen en nullen
droomt ipv over vrouwen ?

Je bent ook een goede programmeur als je gelooft dat er
maar 10 soorten mensen zijn ! (oud!)

[Nielsz]

Op maandag 27 mei 2002 15:57 schreef superboer het volgende:
Ben je een goeie programmeur als je over enen en nullen
droomt ipv over vrouwen ?

Je bent ook een goede programmeur als je gelooft dat er
maar 10 soorten mensen zijn ! (oud!)

Dan mag jij ze nu voor de nieuwe mensen allemaal (uit je hoofd ) opnoemen

[drm]

superboer:
Je bent ook een goede programmeur als je gelooft dat er
maar 10 soorten mensen zijn ! (oud!)

[sup]
* drm kent 'm niet :?[/sup]
10 binair zeker?


<sub>"There are only 2 kinds of people in this world. Those with guns, and those who dig.

You dig."
Clint Eastwood ~ The Good, the Bad and the Ugly</sub>

[Nielsz]

Op maandag 27 mei 2002 17:20 schreef drm het volgende:

[..]

[sup]
* drm kent 'm niet :?[/sup]
10 binair zeker?


<sub>"There are only 2 kinds of people in this world. Those with guns, and those who dig.

You dig."
Clint Eastwood ~ The Good, the Bad and the Ugly</sub>

"There are only 3 kinds of people in this world. Those with can count, and those who don't.
"
Een sig van iemand hier

[nulkelvin]

Hmmm ik zie hier toch een paar definities, die aan goed programmeur zijn worden toegeschreven, terwijl ze naar mijn mening meer bij het coderen horen

Ik vind programmeren en coderen twee verschillende vakken.

Dat veel mensen, (vooral hobbyisten) meteen beginnen met code tikken, zelfs voordat ze weten wat ze uberhaupt willen maken betekent nog niet, dat coderen hetzelfde is als programmeren.

Programmeren : een juiste specificatie maken van WAT je wilt.

Coderen : de implementatie in een of andere taal.

[tomato]

nulkelvin: Programmeren : een juiste specificatie maken van WAT je wilt.

Coderen : de implementatie in een of andere taal.

In de letterlijke zin van het woord programmeren instrueer je een tool (of dat nou een video-recorder of een computer is) om bepaalde dingen te doen.

Wat jij onder programmeren verstaat is letterlijk misschien beter te omschrijven als 'ontwerpen'.

[Verwijderd]

Een goede programmeur is een nette programmeur. Fouten moeten altijd netjes worden opgevangen, zodat (mocht het geval zich voordoen dat de programmeur op vakantie is) z'n collega niet handmatig dingen hoeven op te lossen...
Hierdoor raakt de collega helemaal over de zeik, zeker als blijkt dat soortgelijke fouten zich al een half jaar voordoen, zodat de 'programmeur' tijd genoeg heeft gehad om dit vooraf op te lossen.

_{even zeiken over een collega hoor, maar misschien had je dit al door...}

[Verwijderd]

Op maandag 27 mei 2002 17:46 schreef nulkelvin het volgende:
Hmmm ik zie hier toch een paar definities, die aan goed programmeur zijn worden toegeschreven, terwijl ze naar mijn mening meer bij het coderen horen

aan wat? Dit is geen Demoscene-talk "I'm a l33t c0der!".

Ik vind programmeren en coderen twee verschillende vakken.

Volgens mij is coderen iets wat ze deden in de WO II

Dat veel mensen, (vooral hobbyisten) meteen beginnen met code tikken, zelfs voordat ze weten wat ze uberhaupt willen maken betekent nog niet, dat coderen hetzelfde is als programmeren.
Programmeren : een juiste specificatie maken van WAT je wilt.
Coderen : de implementatie in een of andere taal.

In jouw definitie is een 'coder' dus iemand die een compiler imiteert?

[Jiffy]

Een héle ouwe (plm '83), doch niet te versmaden: 'Real Programmers' (& excuusje voor de lengte). Needless to say dat ik géén 'Real Programmer' ben...

Back in the good old days-- the "Golden Era" of computers-- it was easy to separate the men from the boys (sometimes called "Real Men" and "Quiche Eaters" in the literature). During this period, the Real Men were the ones who understood computer programming, and the Quiche Eaters were the ones who didn't. A real computer programmer said things like "DO 10 I=1,10" and "ABEND" (they actually talked in capital letters, you understand), and the rest of the world said things like "computers are too complicated for me" and "I can't relate to computers-- they're so impersonal". (A previous work [1] points out that Real Men don't "relate" to anything, and aren't afraid of being impersonal.)

But, as usual, times change. We are faced today with a world in which little old ladies can get computers in their microwave ovens, 12 year old kids can blow Real Men out of the water playing Asteroids and Pac-Man, and anyone can buy and even understand their very own personal Computer. The Real Programmer is in danger of becoming extinct, of being replaced by high school students with TRASH-80s.

There is a clear need to point out the differences between the typical high school junior Pac-Man player and a Real Programmer. If this difference is made clear, it will give these kids something to aspire to-- a role model, a Father Figure. It will also help explain to the employers of Real Programmers why it would be a mistake to replace the Real Programmers on their staff with 12 year old Pac-Man players (at a considerable salary savings).

The easiest way to tell a Real Programmer from the crowd is by the programming language he (or she) uses. Real Programmers use Fortran. Quiche Eaters use Pascal. Nicklaus Wirth, the designer of Pascal, gave a talk once at which he was asked, "How do you pronounce your name?". He replied, "You can either call me by name, pronouncing it 'Veert', or call me by value, 'Worth'." One can tell immediately by this comment that Nicklaus Wirth is a Quiche Eater. The only parameter passing mechanism endorsed by Real Programmers is call-by-value-return, as implemented in the IBM/370 Fortran G and H compilers. Real Programmers don't need all these abstract concepts to get their jobs done-- they are perfectly happy with a keypunch, a Fortran IV compiler, and a beer.


Real Programmers do List Processing in Fortran.

Real Programmers do String Manipulation in Fortran.

Real Programmers do Accounting (if they do it at all) in Fortran.

Real Programmers do Artificial Intelligence programs in Fortran.
If you can't do it in Fortran, do it in assembly language. If you can't do it in assembly language, it isn't worth doing.

The academics in computer science have gotten into the "structured programming" rut over the past several years. They claim that programs are more easily understood if the programmer uses some special language constructs and techniques. They don't all agree on exactly which constructs, of course, and the example they use to show their particular point of view invariably fit on a single page of some obscure journal or another-- clearly not enough of an example to convince anyone. When I got out of school, I thought I was the best programmer in the world. I could write an unbeatable tic-tac-toe program, use five different computer languages, and create 1000 line programs that WORKED (Really!). Then I got out into the Real World. My first task in the Real World was to read and understand a 200,000 line Fortran program, then speed it up by a factor of two. Any Real Programmer will tell you that all the Structured Coding in the world won't help you solve a problem like that-- it takes actual talent. Some quick observations on Real Programmers and Structured Programming:


Real Programmers aren't afraid to use GOTOs.

Real Programmers can write five page long DO loops without getting confused.

Real Programmers like Arithmetic IF statements-- they make the code more interesting.

Real Programmers write self-modifying code, especially if they can save 20 nanoseconds in the middle of a tight loop.

Real Programmers don't need comments-- the code is obvious.

Since Fortran doesn't have a structured IF, REPEAT ... UNTIL, or CASE statement, Real Programmers don't have to worry about not using them. Besides, they can be simulated when necessary using assigned GOTOs.
Data structures have also gotten a lot of press lately. Abstract Data Types, Structures, Pointers, Lists, and Strings have become popular in certain circles. Wirth (the above mentioned Quiche Eater) actually wrote an entire book [2] contending that you could write a program based on data structures, instead of the other way around. As all Real Programmers know, the only useful data structure is the Array. Strings, Lists, Structures, Sets-- these are all special cases of arrays and can be treated that way just as easily without messing up your programming language with all sorts of complications. The worst thing about fancy data types is that you have to declare them, and Real Programming Languages, as we all know, have implicit typing based on the first letter of the (six character) variable name.

What kind of operating system is used by a Real Programmer? CP/M? God forbid-- CP/M, after all, is basically a toy operating system. Even little old ladies and grade school students can understand and use CP/M.

Unix is a lot more complicated of course-- the typical Unix hacker never can remember what the PRINT command is called this week-- but when it gets right down to it, Unix is a glorified video game. People don't do Serious Work on Unix systems: they send jokes around the world on UUCP-net and write Adventure games and research papers.

No, your Real Programmer uses OS/370. A good programmer can find and understand the description of the IJK305I error he just got in his JCL manual. A great programmer can write JCL without referring to the manual at all. A truly outstanding programmer can find bugs buried in a 6 megabyte core dump without using a hex calculator. (I have actually seen this done.)

OS is a truly remarkable operating system. It's possible to destroy days of work with a single misplaced space, so alertness in the programming staff is encouraged. The best way to approach the system is through a keypunch. Some people claim there is a Time Sharing system that runs on OS/370, but after careful study I have come to the conclusion that they were mistaken.

What kind of tools does a Real Programmer use? In theory, a Real Programmer could run his programs by keying them into the front panel of the computer. Back in the days when computers had front panels, this was actually done occasionally. Your typical Real Programmer knew the entire bootstrap loader by memory in hex, and toggled it in whenever it got destroyed by his program. (Back then, memory was memory-- it didn't go away when the power went off. Today, memory either forgets things when you don't want it to, or remembers things long after they're better forgotten.) Legend has it that Seymore Cray, inventor of the Cray I supercomputer and most of Control Data's computers, actually toggled the first operating system for the CDC7600 in on the front panel from memory when it was first powered on. Seymore, needless to say, is a Real Programmer.

One of my favorite Real Programmers was a systems programmer for Texas Instruments. One day, he got a long distance call from a user whose system had crashed in the middle of saving some important work. Jim was able to repair the damage over the phone, getting the user to toggle in disk I/O instructions at the front panel, repairing system tables in hex, reading register contents back over the phone. The moral of this story: while a Real Programmer usually includes a keypunch and line printer in his toolkit, he can get along with just a front panel and a telephone in emergencies.

In some companies, text editing no longer consists of ten engineers standing in line to use an 029 keypunch. In fact, the building I work in doesn't contain a single keypunch. The Real Programmer in this situation has to do his work with a "text editor" program. Most systems supply several text editors to select from, and the Real Programmer must be careful to pick one that reflects his personal style. Many people believe that the best text editors in the world were written at Xerox Palo Alto Research Center for use on their Alto and Dorado computers[3]. Unfortunately, no Real Programmer would ever use a computer whose operating system is called SmallTalk, and would certainly not talk to the computer with a mouse.

Some of the concepts in these Xerox editors have been incorporated into editors running on more reasonably named operating systems-- EMACS and VI being two. The problem with these editors is that Real Programmers consider "what you see is what you get" to be just as bad a concept in Text Editors as it is in Women. No, the Real Programmer wants a "you asked for it, you got it" text editor-- complicated, cryptic, powerful, unforgiving, dangerous. TECO, to be precise.

It has been observed that a TECO command sequence more closely resembles transmission line noise than readable text[4]. One of the more entertaining games to play with TECO is to type your name in as a command line and try to guess what it does. Just about any possible typing error while talking with TECO will probably destroy your program, or even worse-- introduce subtle and mysterious bugs in a once working subroutine.

For this reason, Real Programmers are reluctant to actually edit a program that is close to working. They find it much easier to just patch the binary object code directly, using a wonderful program called SUPERZAP (or its equivalent on non-IBM machines). This works so well that many working programs on IBM systems bear no relation to the original Fortran code. In many cases, the original source code is no longer available. When it comes time to fix a program like this, no manager would even think of sending anything less than a Real Programmer to do the job-- no Quiche Eating structured programmer would even know where to start. This is called "job security".

Some programming tools NOT used by Real Programmers:


Fortran preprocessors like MORTRAN and RATFOR. The Cuisinarts of programming-- great for making Quiche. See comments above on structured programming.

Source language debuggers. Real Programmers can read core dumps.

Compilers with array bounds checking. They stifle creativity, destroy most of the interesting uses for EQUIVALENCE, and make it impossible to modify the operating system code with negative subscripts. Worst of all, bounds checking is inefficient.

Source code maintenance systems. A Real Programmer keeps his code locked up in a card file, because it implies that its owner cannot leave his important programs unguarded [5].
Where does the typical Real Programmer work? What kind of programs are worthy of the efforts of so talented an individual? You can be sure that no Real Programmer would be caught dead writing accounts-receivable programs in COBOL, or sorting mailing lists for People magazine. A Real Programmer wants tasks of earth-shaking importance (literally!).


Real Programmers work for Los Alamos National Laboratory, writing atomic bomb simulations to run on Cray I supercomputers.

Real Programmers work for the National Security Agency, decoding Russian transmissions.

It was largely due to the efforts of thousands of Real Programmers working for NASA that our boys got to the moon and back before the Russkies.

The computers in the Space Shuttle were programmed by Real Programmers.

Real Programmers are at work for Boeing designing the operation systems for cruise missiles.
Some of the most awesome Real Programmers of all work at the Jet Propulsion Laboratory in California. Many of them know the entire operating system of the Pioneer and Voyager spacecraft by heart. With a combination of large ground-based Fortran programs and small spacecraft-based assembly language programs, they are able to do incredible feats of navigation and improvisation-- hitting ten-kilometer wide windows at Saturn after six years in space, repairing or bypassing damaged sensor platforms, radios, and batteries. Allegedly, one Real Programmer managed to tuck a pattern matching program into a few hundred bytes of unused memory in a Voyager spacecraft that searched for, located, and photographed a new moon of Jupiter.

The current plan for the Galileo spacecraft is to use a gravity assist trajectory past Mars on the way to Jupiter. This trajectory passes within 80 +/- 3 kilometers of the surface of Mars. Nobody is going to trust a Pascal program (or Pascal programmer) for navigation to these tolerances.

As you can tell, many of the world's Real Programmers work for the U.S. Government-- mainly the Defense Department. This is as it should be. Recently, however, a black cloud has formed on the Real Programmer horizon. It seems that some highly placed Quiche Eaters at the Defense Department decided that all Defense programs should be written in some grand unified language called "ADA" ((C), DoD). For a while, it seemed that ADA was destined to become a language that went against all the precepts of Real Programming-- a language with structure, a language with data types, strong typing, and semicolons. In short, a language designed to cripple the creativity of the typical Real Programmer. Fortunately, the language adopted by DoD had enough interesting features to make it approachable-- it's incredibly complex, includes methods for messing with the operating system and rearranging memory, and Edsger Dijkstra doesn't like it [6]. (Dijkstra, as I'm sure you know, was the author of "GOTOs Considered Harmful"-- a landmark work in programming methodology, applauded by Pascal Programmers and Quiche Eaters alike.) Besides, the determined Real Programmer can write Fortran programs in any language.

The Real Programmer might compromise his principles and work on something slightly more trivial than the destruction of life as we know it. Providing there's enough money in it. There are several Real Programmers building video games at Atari, for example. (But not playing them-- a Real Programmer knows how to beat the machine every time: no challenge in that.) Everyone working at LucasFilm is a Real Programmer. (It would be crazy to turn down the money of fifty million Star Trek fans.) The proportion of Real Programmers in Computer Graphics is somewhat lower than the norm, mostly because nobody has found a use for Computer Graphics yet. On the other hand, all Computer Graphics is done in Fortran, so there are a fair number of people doing Graphics in order to avoid having to write COBOL programs.

Generally, the Real Programmer plays the same way he works-- with computers. He is constantly amazed that his employer actually pays him to do what he would be doing for fun anyway (although he is careful not to express this opinion out loud). Occasionally, the Real Programmer does step out of the office for a breath of fresh air and a beer or two. Some tips on recognizing Real Programmers away from the computer room:


At a party, the Real Programmers are the ones in the corner talking about operating system security and how to get around it.

At a football game, the Real Programmer is the one comparing the plays against his simulations printed on 11 by 14 fanfold paper.

At the beach, the Real Programmer is the one drawing flowcharts in the sand.

At a funeral, the Real Programmer is the one saying "Poor George. And he almost had the sort routine working before the coronary."

In a grocery store, the Real Programmer is the one who insists on running the cans past the laser checkout scanner himself, because he never could trust keypunch operators to get it right the first time.
What sort of environment does the Real Programmer function best in? This is an important question for the managers of Real Programmers. Considering the amount of money it costs to keep one on the staff, it's best to put him (or her) in an environment where he can get his work done.

The typical Real Programmer lives in front of a computer terminal. Surrounding this terminal are:


Listings of all programs the Real Programmer has ever worked on, piled in roughly chronological order on every flat surface in the office.

Some half-dozen or so partly filled cups of cold coffee. Occasionally, there will be cigarette butts floating in the coffee. In some cases, the cups will contain Orange Crush.

Unless he is very good, there will be copies of the OS JCL manual and the Principles of Operation open to some particularly interesting pages.

Taped to the wall is a line-printer Snoopy calendar for the year 1969.

Strewn about the floor are several wrappers for peanut butter filled cheese bars-- the type that are made pre-stale at the bakery so they can't get any worse while waiting in the vending machine.

Hiding in the top left-hand drawer of the desk is a stash of double-stuff Oreos for special occasions.

Underneath the Oreos is a flow-charting template, left there by the previous occupant of the office. (Real Programmers write programs, not documentation. Leave that to the maintenence people.)
The Real Programmer is capable of working 30, 40, even 50 hours at a stretch, under intense pressure. In fact, he prefers it that way. Bad response time doesn't bother the Real Programmer-- it gives him a chance to catch a little sleep between compiles. If there is not enough schedule pressure on the Real Programmer, he tends to make things more challenging by working on some small but interesting part of the problem for the first nine weeks, then finishing the rest in the last week, in two or three 50-hour marathons. This not only impresses the hell out of his manager, who was despairing of ever getting the project done on time, but creates a convenient excuse for not doing the documentation. In general:


No Real Programmer works 9 to 5. (Unless it's the ones at night.)

Real Programmers don't wear neckties.

Real Programmers don't wear high heeled shoes.

Real Programmers arrive at work in time for lunch.

A Real Programmer might or might not know his wife's name. He does, however, know the entire ASCII (or EBCDIC) code table.

Real Programmers don't know how to cook. Grocery stores aren't open at three in the morning. Real Programmers survive on Twinkies and coffee.
What of the future? It is a matter of some concern to Real Programmers that the latest generation of computer programmers are not being brought up with the same outlook on life as their elders. Many of them have never seen a computer with a front panel. Hardly anyone graduating from school these days can do hex arithmetic without a calculator. College graduates these days are soft-- protected from the realities of programming by source level debuggers, text editors that count parentheses, and "user friendly" operating systems. Worst of all, some of these alleged "computer scientists" manage to get degrees without ever learning Fortran! Are we destined to become an industry of Unix hackers and Pascal programmers?

From my experience, I can only report that the future is bright for Real Programmers everywhere. Neither OS/370 nor Fortran show any signs of dying out, despite all the efforts of Pas- cal programmers the world over. Even more subtle tricks, like adding structured coding constructs to Fortran, have failed. Oh sure, some computer vendors have come out with Fortran 77 compilers, but every one of them has a way of converting itself back into a Fortran 66 compiler at the drop of an option card-- to compile DO loops like God meant them to be.

Even Unix might not be as bad on Real Programmers as it once was. The latest release of Unix has the potential of an operating system worthy of any Real Programmer-- two different and subtly incompatible user interfaces, an arcane and complicated teletype driver, virtual memory. If you ignore the fact that it's "structured", even 'C' programming can be appreciated by the Real Programmer: after all, there's no type checking, variable names are seven (ten? eight?) characters long, and the added bonus of the Pointer data type is thrown in-- like having the best parts of Fortran and assembly language in one place. (Not to mention some of the more creative uses for #define.)

No, the future isn't all that bad. Why, in the past few years, the popular press has even commented on the bright new crop of computer nerds and hackers ([7] and [8]) leaving places like Stanford and MIT for the Real World. From all evidence, the spirit of Real Programming lives on in these young men and women. As long as there are ill-defined goals, bizarre bugs, and unrealistic schedules, there will be Real Programmers willing to jump in and Solve The Problem, saving the documentation for later. Long live Fortran!

Ok, wie het tot hier heeft volgehouden: gefeliciteerd! Nu weet je wat een échte programmeur is. Een échte programmeur heeft spierballen op z'n hersens...

[Verwijderd]

ja hallo, dat ga ik ff niet lezen als je 't niet erg vindt... sjonge jonge, wat een lap tekst...

[Scare360]

lache, maar wel een tikkeltje kwats

[Tsjipmanz]

Op zaterdag 25 mei 2002 13:08 schreef Mir het volgende:

En nu douchen

Ook een onderschatte kwaliteit onder sommige informatica-studenten

[Verwijderd]

ja hallo, dat ga ik ff niet lezen als je 't niet erg vindt... sjonge jonge, wat een lap tekst...

Aha... dus http://www.tweakers.net/nieuws/21891 klopt nog aardig ook! *blub*

[Verwijderd]

Een echte programmeur zou deze post niet lezen omdat ie bezig zou zijn met het bedenken van een nieuw algorithme door de wortel van pi te verdraaien met de op 3 na laatste column uit het fluxquadrant.

[drm]

paasklaas:
Een echte programmeur zou deze post niet lezen omdat ie bezig zou zijn met het bedenken van een nieuw algorithme door de wortel van pi te verdraaien met de op 3 na laatste column uit het fluxquadrant.

Een echte programmeur houdt zich niet bezig met dat soort termen. Al helemaal niet in het nederlands

[Verwijderd]

Mijn God, waat een lulverhaal

Maar ik lag dubbel aan het einde, spierballen op hersens
dat is een goede!

[Varienaja]

Goede programmeurs zijn integer: ik vond de opmerking van Dijkstra heel treffend: "Je moet de mensen niet geven wat ze willen, maar wat ze nodig hebben."

Deze moet ik ff opschrijven:
Real programmers look both ways before crossing a one-way street.
Don't comment your code: if it was hard to program, it should be hard to understand.

[Verwijderd]

Op maandag 27 mei 2002 17:20 schreef drm het volgende:

[..]

[sup]
* drm kent 'm niet :?[/sup]
10 binair zeker?


<sub>"There are only 2 kinds of people in this world. Those with guns, and those who dig.

You dig."
Clint Eastwood ~ The Good, the Bad and the Ugly</sub>

<sub>"There are only 2 kinds of spurs. Those that come by the door, and those that come by the window.


Tuco ~ The Good, the Bad and the Ugly</sub>

[Verwijderd]

Op dinsdag 28 mei 2002 12:54 schreef Tsjipmanz het volgende:

[..]

Ook een onderschatte kwaliteit onder sommige informatica-studenten

En uiteraard HTML handleidingen schrijven!
waar jij gelukkig genoeg ervaring mee hebt!

[raptorix]

Ik ben programmeur maar om nou te zeggen dat ik goeie programmeur ben, nou niet zo, maar ik ben wel handig in het leren van nieuwe trucjes en zeker als je ergens werkt waar men graag technologie koopt en implementeert is dat erg handig. Kortom als programmeur gaat het niet alleen om programmeerkunstjes, goed documentatie kunnen lezen dan wel code kunnen lezen is imo net zo belangrijk.

[drm]

Glorfindel:

<sub>"There are only 2 kinds of spurs. Those that come by the door, and those that come by the window.


Tuco ~ The Good, the Bad and the Ugly</sub>

Die 's ook ERG leuk ja
[sub]
* drm loves that movie :)[/sub]

[drm]

raptorix:
Kortom als programmeur gaat het niet alleen om programmeerkunstjes, goed documentatie kunnen lezen dan wel code kunnen lezen is imo net zo belangrijk.

Ik denk dat het 1 onlosmakelijk met het ander verbonden is. Hoe kan je nou een goeie programmeur zijn als je nooit documentatie goed gelezen hebt, of wanneer je geen code kan lezen?

_{edit: en deze post was natuurlijk als edit bedoeld}

[Feyd-Rautha]

zoals Scott Adams (Dilbert) het zo mooi kon zeggen:

Er zijn twee verschillende soorten mensen:
de eerste soort zijn de verstandige mensen die zoals jij en ik Dilbert lezen,
die andere soort zijn de andere 5 miljard dombo's die Dilbert niet lezen

[whoami]

Op dinsdag 28 mei 2002 16:57 schreef -Avalanche- het volgende:
zoals Scott Adams (Dilbert) het zo mooi kon zeggen:

Er zijn twee verschillende soorten mensen:
de eerste soort zijn de verstandige mensen die zoals jij en ik Dilbert lezen,
die andere soort zijn de andere 5 miljard dombo's die Dilbert niet lezen

Ik zie niet direct in wat dat met de kwaliteiten van een goede programmeur te maken heeft.

[drm]

whoami:
Ik zie niet direct in wat dat met de kwaliteiten van een goede programmeur te maken heeft.

oftewel: ontopic plz

[Verwijderd]

Ik beschouw een programmeur als iemand die voornamelijk programma's maakt, dus code schrijft, maar die ook het grote geheel ziet en begrijpt. Denk daarbij aan de eindgebruikers, de opdrachtgever, de projectmanager, de functionele / technische ontwerpen, commerciele aspecten, quility management, documentatie, etc.

Een echt hele goede programmeur moet daarom de volgende vaardigheden bezitten en ervaringen hebben. (Ik gebruik "hij", maar dat kan natuurlijk net zogoed "zij" zijn.)

Technische kennis
- Hij kent meerdere programmeertalen, en ziet daarom meer dan de details van de taal, maar ook de algemene concepten van programmeertalen.
- Hij begrijpt zowel procedurele als OO programmerconcepten, en kent de voor- en nadelen van beiden. Bovendien is het prettig als hij ook wat kennis heeft van functionele programmeertalen zoals Miranda.
- Hij heeft kennis van veel verschillende soorten software die gebruikt worden om systemen te maken, zoals databases, directory services, web servers, een CRM, ERP, CMS pakket
- Hij begrijpt de concepten van netwerkstructuren, -componenten en -protocollen, zoals routers, firewalls, proxies, internet exchanges, TCP/IP, HTTP, SSL, SMTP, telnet, FTP, etc
- Hij heeft kennis van / kan overweg met (D)HTML, CSS, JavaScript, XML, XSL(T), DOM
- Hij kan technische en functionele ontwerpen kritisch lezen en begrijpen (UML, ERD, DFD, etc), en kan eventueel zelf ook helpen met het maken / wijzigen ervan
- Hij heeft een heel goed begrip van RDBMSen, kent de verschillende SQL dialecten, weet wat zaken als indexen, transacties en rollbacks zijn en hoe ze te gebruiken, en kan eenvoudige DBA handelingen verrichten
- Hij begrijpt het verschil tussen "performance" en "scalability" van een systeem, en weet ook grofweg de voorwaarden voor een systeem om beide situaties te bereiken, en dat beide soms lijnrecht tegenover elkaar staan.
- Hij weet wat "design patterns" zijn en heeft er ook weleens mee gewerkt
- Hij begrijpt de problemen van security en hoe dat in verschillende systemen van belang is

Werkwijze
- Hij werkt gedisciplineerd en gestructureerd, omdat hij begrijpt dat kwaliteit niet alleen kan komen van veel testen, maar voornamelijk van gestructureerd werken
- Hij denkt na voordat hij code begint te schrijven, en zal evalueren of hij echt voldoende informatie heeft om zijn werk goed te kunnen doen, en eventuele informatie die ontbreekt of aannames die niet kloppen aan anderen duidelijk maken
- Hij ontleedt problemen in kleinere, abstracte problemen, die niet tot in detail hoeft uit te werken om ervan overtuigd te zijn dat het gaat werken. Daarna zal hij voor de kleinste losse deelproblemen een framework opzetten (objecten, procedures o.i.d.) om deze vervolgens met code in te vullen.
- Hij documenteert zijn code en geeft het een goede layout. Daarnaast heeft hij een strak versiebeheer, zodat hij altijd achteraf kan terugvinden wat wanneer is gewijzigd, en waarom.
- Hij begrijpt dat "Maar het werkt toch?" absoluut de verkeerde instelling is, en weigert ook op dergelijke basis te werken.

Samenwerking & communicatie
- Hij zal vooraf ideeen vaak overleggen met collega's, zodat hij een secod opinion krijgt voordat hij aan de slag gaat. Achteraf laat hij zijn code reviewen, en reviewt hij actief de code van anderen.
- Hij neemt verantwoordelijkheid voor zijn werk, maar ook voor het succes van het hele project, en zal daarom zijn collega's aanspreken als er iets niet of juist wel goed gaat, en staat zelf ook open voor opbouwende kritiek, opmerkingen en complimenten.
- Hij begrijpt dat perfectie niet berijkt kan worden, maar streeft daar wel naar binnen de parameters van zijn opdracht (tijd, budget, functionele en niet-functionele eisen van de klant)
- Hij dwingt af dat anderen hem op zijn waarde schatten, omdat andere (vaak 'hogere') medewerkers in het projectteam zijn expertise nodig hebben om het project af te ronden, en dan wel die expertise moeten respecteren, net zoals dat andersom moet plaatsvinden

Ervaring
- Hij heeft weleens een klein project vrijwel zelfstandig gedaan, inclusief functionele / technische specificaties, overleg met klanten, tijdschatting en budgettering en dergelijke, of anders met ieder van deze taken in aanraking zijn geweest in projecten
- Hij heeft weleens in een groter (> 10 man, > 1 miljoen Euro) project gewerkt, en kent alle problematiek die dat geeft
- Hij heeft weleens leiding gegeven aan een (kleine) groep collega's of heeft weleens trainees
- Hij heeft weleens een systeem in onderhoud genomen dat in productie is, en kent de moeilijkheden van die situatie.
- Hij heeft weleens een project helemaal naar de kloten zien gaan, en weet dat die dat nooit meer wil meemaken

Deze lijst is verre van compleet, en aanvullingen / opmerkingen zijn van harte welkom. Overigens wil dit niet zeggen dat je geen goede programmeur bent als je aan een van de voorwaarden niet voldoen, maar ik heb het gevoel dat het stukken kennis en ervaring zijn die je beter maken dan dat je bent als je ze nog niet hebt.

[Apollo_Futurae]

"A truly outstanding programmer can find bugs buried in a 6 megabyte core dump without using a hex calculator. (I have actually seen this done.)"

[TheDane]

hmm, ik vind dat een goede programmeur best foutjes kan maken. als ie daardoor z'n deadline kan halen, en een goed genoeg produkt kan afleveren.


een goed programmeur maakt imo dus een afweging tussen verschillende ideeen en belangen, die best met elkaar in conflict kunnen zijn. De juiste balans daartussen vinden is moeilijker dan een stukkie foutloze code prutsen

[Verwijderd]

The three great virtues of a programmer are Laziness, Impatience and Hubris

The Camel Book.

[TGEN]

Een goede programmeur heeft een uitgebreide kennis van het platform waar hij op werkt, en dus niet alleen van alle keywords e.d. in een taal. Een goede programmeur moet dus weten hoe het systeem zijn opdrachten verwerkt, en hoe zijn opdrachten aan het systeem worden toegevoerd. Hierbij is kennis van het programmeren in Assembly natuurlijk onontbeerlijk .

Daar mogen jullie het mee doen .

[Tomatoman]

Een echte programmeur kan lachen om het verhaal over de Real Programmer en herkent zichzelf er wel een beetje in.

Serieus, de echte programmeur begrijpt dat het niet draait om zijn geweldig elegante oplossing voor dat ingewikkelde probleem. De echte programmeur ziet in dat een DOS prompt in deze tijd toch echt achterhaald is - we leven in de tijd van Windows XP. De echte programmeur begrijpt dat de gemiddelde gebruiker een hekel heeft aan dikke gebruikershandleidingen.

De echte programmeur zorgt ervoor dat het programma doet wat het moet doen. De echte programmeur zorgt ervoor dat zijn programma nét wat meer doet dan de gebruiker in eerste instantie verwacht. De echte programmeur schrijft een programma waaraan hij flink verdient.

[mbravenboer]

tomatoman:
1. de echte programmeur begrijpt dat het niet draait om zijn geweldig elegante oplossing voor dat ingewikkelde probleem.

2. De echte programmeur ziet in dat een DOS prompt in deze tijd toch echt achterhaald is - we leven in de tijd van Windows XP.

3. De echte programmeur schrijft een programma waaraan hij flink verdient.

Ik vrees (en ben tegelijk blij) dat ik niet door je test heen kom . Althans, ik gebruik inderdaad geen DOS prompt .

[killercow]

Op woensdag 29 mei 2002 03:33 schreef MrX het volgende:
Ik beschouw een programmeur als iemand die voornamelijk ... text

is dat jouw contract?
naja anyway, ik slaag voor 95% van die punten wel denk ik al zijn sommige dingen afhankelijk van de werk-omgeving en projecten (bijvoorbeeld kennis van zaken)

[Soultaker]

Op donderdag 30 mei 2002 22:41 schreef mbravenboer het volgende:
Ik vrees (en ben tegelijk blij) dat ik niet door je test heen kom

Waarom? Omdat er geen fatsoenlijke ontwikkelomgeving voor jou favoriete besturingssyteem bestaat? (Waarom zou je daar blij mee zijn)? Of omdat onder een shell ontwikkelen ECHT beter werkt?

[TheDane]

Op donderdag 30 mei 2002 23:42 schreef Soultaker het volgende:

[..]

Waarom? Omdat er geen fatsoenlijke ontwikkelomgeving voor jou favoriete besturingssyteem bestaat? (Waarom zou je daar blij mee zijn)? Of omdat onder een shell ontwikkelen ECHT beter werkt?

onder een shell werken brengt je veel dichter bij de code waaraan je zit te prutsen.
met andere woorden: je bgrijpt veel beter waar je mee bezig bent; ergo je verstaat je vak beter. ergo je bent een betere programmeur


verder heeft tomatoman met punt 1 en 3 100% gelijk
afgezien van 't feit dat een echte programmeur zijn werk niet zelf verkoopt .. dat laat ie doen :8

[mbravenboer]

Soultaker: Waarom? Omdat er geen fatsoenlijke ontwikkelomgeving voor jou favoriete besturingssyteem bestaat? (Waarom zou je daar blij mee zijn)? Of omdat onder een shell ontwikkelen ECHT beter werkt?

Allereerst ging het niet alleen om het werken met een shell/command prompt . Als je een stukje terugbladerd naar een bijdrage van mij op de eerste pagina zal je zien dat vooral de andere twee punten niet bepaald aansluiten bij mijn ideeen. Het hangt er vanaf wat je onder 'goed' verstaat, wat je ook al terug ziet op de eerste pagina. In een bepaalde visie van 'goed' passen deze voorwaarde wellicht, in de definitie die ik aanhield, passen ze absoluut niet.

Het hele shell verhaal lijkt mij nog irrelevant eigenlijk voor de kwaliteit van de programmeur, maar goed: die functioneert inderdaad uitstekend. Ik gebruikte toen ik nog onder MS Windows werkte al een combinatie van Ant+Jext en dat doe ik nog steeds naar volle tevredenheid. Met name Ant is enorm goed toe te passen in een grote diversiteit aan projecten. Voor builden heb ik dus geen IDE nodig omdat Ant simpelweg vanaf de shell kan worden aangeroepen (net als uiteraard make).

Verder zou een IDE sowieso nooit voldoen omdat de meeste tools voor mij al oud zijn als ze eindelijk als productie-release uitkomen en dan na een flink aantal maanden in een IDE worden ondersteund. Ik werk al een jaar met de early-access Java Generics compiler, wat je in de meeste IDE's niet voor elkaar kunt krijgen.

Sinds ik onder Linux werk bewijst de shell zijn nut nog veel meer. Ik gebruik diverse handige shell-scriptjes (ook voor het aanroepen van Java tools) en combineer software componenten snel en gemakkelijk. Dat is erg makelijk in de tool-set waar ik tegenwoordig m'n meeste tijd in door breng: XT.

Ik ben niet trots omdat ik in tegenstelling tot andere mensen als een 'freak' (vage gedachte uberhaupt ) op de shell werk. Ik kan met behulp van een shell goed functioneren en dat is voor mij belangrijk. Dat anderen liever een IDE willen gebruiken kan ik goed begrijpen en ze worden er echt geen 'watjes' van.

Wat ik dus wel fout vind, is het afschilderen van de huidige wereld als de MS Windows XP wereld, want dat is toch wel een wat beperkte kijk op de werkelijkheid die wellicht vooral ontstaan is door een kijk op de IT vanuit de prive-wereld of wellicht nog vanwege de commerciele bedrijven die zich richten op desktop gebruik.

Helaas is er nog steeds erg veel interessant materiaal wat zelfs niet beschikbaar is voor een Microsoft operating system.

(maar goed: dit is de discussie niet, maar moest hier toch even op reageren).

[Kris]

Nog een puntje: Als hij in staat is om andersmans code aan te begrijpen en aan te passen.

[Soultaker]

Op vrijdag 31 mei 2002 00:01 schreef TheDane het volgende:
onder een shell werken brengt je veel dichter bij de code waaraan je zit te prutsen.
met andere woorden: je bgrijpt veel beter waar je mee bezig bent; ergo je verstaat je vak beter. ergo je bent een betere programmeur

Dat is natuurlijk maar een gedeeltelijke waarheid. Jou bewering klopt wel, maar dat wil niet zeggen dat je, door in een IDE te werken, geen ervaring op kan doen of geen begrip van programmeren kan hebben. Ik durf te beweren dat het in principe niet uitmaakt, hoewel door de bank genomen de programmeurs die met een shell werken waarschijnlijk betere programmeurs zijn.

Op vrijdag 31 mei 2002 01:51 schreef mbravenboer het volgende:
Allereerst ging het niet alleen om het werken met een shell/command prompt . Als je een stukje terugbladerd naar een bijdrage van mij op de eerste pagina zal je zien dat vooral de andere twee punten niet bepaald aansluiten bij mijn ideeen.

Klopt, ik las ook je vorige reactie nog eens en het sloeg op alledrie de punten. Door de extra opmerking over de shell/prompt was ik even misleid.

Verder zou een IDE sowieso nooit voldoen omdat de meeste tools voor mij al oud zijn als ze eindelijk als productie-release uitkomen en dan na een flink aantal maanden in een IDE worden ondersteund. Ik werk al een jaar met de early-access Java Generics compiler, wat je in de meeste IDE's niet voor elkaar kunt krijgen.

Dat was dus mijn punt: dan werk je dus niet op de shell omdat dat beter is, maar simpelweg omdat er geen geschikte IDE bestaat. Zelf zit ik ook vaak met een shell opgescheept, maar dat betekend niet dat ik liever een IDE ter beschikking zou willen hebben.

Ik kan met behulp van een shell goed functioneren en dat is voor mij belangrijk. Dat anderen liever een IDE willen gebruiken kan ik goed begrijpen en ze worden er echt geen 'watjes' van.

Helemaal mee eens.

Wat ik dus wel fout vind, is het afschilderen van de huidige wereld als de MS Windows XP wereld, want dat is toch wel een wat beperkte kijk op de werkelijkheid die wellicht vooral ontstaan is door een kijk op de IT vanuit de prive-wereld of wellicht nog vanwege de commerciele bedrijven die zich richten op desktop gebruik.

Ik moet toegeven dat ik zelf nog met Visual Studio 6 en Windows 2000 werk, maar ik wil niet ontkennen dat Windows XP de toekomst heeft. Het ging natuurlijk niet om Windows XP an sich, maar om geavanceerde IDE's in het algemeen. Onder diverse non-Windows besturingssytemen draait KDE 3 met KDevelop, wat een vergelijkbare manier van werken oplevert.

Het is naar mijn idee niet zinnig om met primitieve methoden te blijven werken als geavanceerdere middelen eenvoudig beschikbaar zijn. Natuurlijk moeten die 'geavanceerde middelen' dan wel aan bepaalde eisen voldoen (wat nu nog niet altijd het geval is). Zoniet, dan is het logisch dat je als ontwikkelaar kiest voor een interface die niet aan de laatste 'mode' meedoet, maar wel alle gewenste functionaliteit biedt.

Wat betreft on-topic: ik kan me wel aardig vinden in het lijstje van MisterX. Ik zou er graag wat aan willen toevoegen, maar ik zou niet weten wat.

[whoami]

Op vrijdag 31 mei 2002 06:58 schreef Kris het volgende:
Nog een puntje: Als hij in staat is om andersmans code aan te begrijpen en aan te passen.

Ehm. Ik zou het graag omdraaien. Een goede programmeur moet er voor zorgen dat zijn code leesbaar is voor andere programmeurs.

[Soultaker]

Op vrijdag 31 mei 2002 10:36 schreef whoami het volgende:
Ehm. Ik zou het graag omdraaien. Een goede programmeur moet er voor zorgen dat zijn code leesbaar is voor andere programmeurs.

En ik zou dan allebei zeggen. Zelfs als je je aan (soms zeer stricte) coding standards houdt, zullen verschillende mensen verschillende stukken code schrijven.

Een verstandig programmeur schrijft de code zo, dat de uitwerking ervan herkenbaar is. Aan de andere kant, kan een verstandig programmeur ook de werking van code doorzien, die niet zo is opgebouwd als hij dat zelf gedaan had.

[drm]

Als ik even mag samenvatten?
mbravenboer zegt, net als Soultaker

• Een IDE is geen vereiste voor een goede programmeur
• Helaas zijn IDE's vaak niet toereikend, en is de programmeur gedwongen shells te gebruiken. Het feit dat een programmeur de shell gebruikt maakt hem geen goede programmeur, noch is een goede programmeur verplicht om een shell te gebruiken, puur om een goede programmeur te zijn
• De tools die een programmeur gebruikt zijn dus (tot op zekere hoogte* drm ) irrelevant voor het zijn van een goede programmeur.
• Een goede programmeur herkent echter wel goede tools, om tot het resultaat te komen wat hij wil (dit is in Soultaker's geval een Windows omgeving, in mbravenboer's geval een linux shell met een stel shellscripts)

en daar kan ik mij helemaal in vinden

Soultaker:
[Code leesbaar kunnen schrijven, code kunnen lezen zijn beide eigenschappen van een goede programmeur]

Ben ik het ook al mee eens.

_edit:
* drm ) Volgens mij weten we allemaal wel wat ik bedoel

[Verwijderd]

Op vrijdag 31 mei 2002 10:35 schreef Soultaker het volgende:
Dat was dus mijn punt: dan werk je dus niet op de shell omdat dat beter is, maar simpelweg omdat er geen geschikte IDE bestaat. Zelf zit ik ook vaak met een shell opgescheept, maar dat betekend niet dat ik liever een IDE ter beschikking zou willen hebben.

Er zijn genoeg IDE's voor *NIX beschikbaar, en dat gaat van TP5 achtige text-interfaces tot volledig grafische sleur-en-pleur interfaces zoals KDevelop en de combinatie Glade + Anjuta. Ook SGI heeft een mooie IDE.

Het probleem met IDE's is zoals al gezegd:
1) programmeren vanaf de shell is sneller als de programmeur ingespeeld is op de shell (en wat leuke scripts/aliassen maakt).
2) Je hebt niets aan een sleur-en-pleur RAD IDE als je serverdaemons of compilers ontwikkelt, RAD is leuk in userland, maar gewoon niet realiseerbaar voor een systeemprogrammeur (ff een linux-kernel in elkaar drag&droppen...).

[Soultaker]

Op vrijdag 31 mei 2002 13:20 schreef mietje het volgende:
Het probleem met IDE's is zoals al gezegd:
1) programmeren vanaf de shell is sneller als de programmeur ingespeeld is op de shell (en wat leuke scripts/aliassen maakt).

Dat lijkt me sterk. Jij kan niet 'make' intypen in de tijd dat ik op F7 druk. Ik zou dan ook niet weten waarom een shell sneller zou zijn. Daarbij kun je in de meeste IDE's ook onderdelen scripten (zeker in bijvoorbeeld KDevelop).

2) Je hebt niets aan een sleur-en-pleur RAD IDE als je serverdaemons of compilers ontwikkelt, RAD is leuk in userland, maar gewoon niet realiseerbaar voor een systeemprogrammeur (ff een linux-kernel in elkaar drag&droppen...).

Ik heb Apache modules ontwikkeld in VisualStudio hoor. Dat gaat prima. Uiteraard kan je dan geen GUI maken, maar het edit gemak (syntax highlighting, autocompletion, documentatie, jump to definition) blijft bestaan. Het grootste voordeel van een IDE is wel de geintegreerde debugomgeving en ook die kan je gebruiken bij het ontwikkelen van 'daemons of compilers'.

[Verwijderd]

Op vrijdag 31 mei 2002 13:23 schreef Soultaker het volgende:
Ik heb Apache modules ontwikkeld in VisualStudio hoor. Dat gaat prima. Uiteraard kan je dan geen GUI maken, maar het edit gemak (syntax highlighting, autocompletion, documentatie, jump to definition) blijft bestaan.

Dit kunnen de standaard texteditors op een *NIX systeem al, daar heb je geen IDE voor nodig. Zowel vi(m) als emacs kunnen wat je hierboven opnoemt (en nog veel meer).

[mbravenboer]

Het is erg off-topic, maar nu we het toch over IDEs en hun (on)mogelijkheden hebben:

Ik heb pas kennis gemaakt met de Toolbus, die ontwikkeld is aan het CWI in Amsterdam. Dit is een aardig idee om individuele tools te laten samenwerken in een interactieve, IDE achtige omgeving.

De Toolbus wordt gebruikt voor zaken waar typsich geen IDE voor beschikbaar is: grammatica's, parser-generators, programma-transformaties in speciale talen, compilers enzovoorts.

De userinterface wordt geboden door de ASF+DSF Meta-Environment. Alle tools die je gebruikt communiceren via de Toolbus met op elkaar op basis van een standaard voor data-structuren (ATermen, die vergelijkbaar zijn met XML).

Het aardige van de Toolbus is dat je nu zelfstandige toools goed kunt laten samenwerken en je deze tools ook individueel kunt verbeteren (in tegenstelling tot de 'componenten' van een IDE, die je meestal in 1x upgrade).

Al met al best een aardig idee voor een extreem component georienteerde IDE, waarbij de tools nu dus ook in alle mogelijke programmeertalen geschreven kunnen zijn (van exotisch tot C).

[Soultaker]

Op vrijdag 31 mei 2002 13:30 schreef mietje het volgende:
Dit kunnen de standaard texteditors op een *NIX systeem al, daar heb je geen IDE voor nodig. Zowel vi(m) als emacs kunnen wat je hierboven opnoemt (en nog veel meer).

Pff, in vi kan ik niet eens klikken! Waar is de menubalk? Functietoetsen? Debugging environment? Data display? Link met (API/taal) documentatie?

Wie denk dat vi een volwaardig alternatief vormt voor een IDE heeft nooit met een goede IDE gewerkt. Ik wil benadrukken dat een IDE niet voor elk doel geschikt is, maar in veelvoorkomende gevallen biedt een IDE de programmeur zoveel ondersteuning dat 'ie z'n werk in minder tijd (en met minder moeite) kan uitvoeren.

[TheDane]

Op vrijdag 31 mei 2002 10:35 schreef Soultaker het volgende:

[..]

Dat is natuurlijk maar een gedeeltelijke waarheid. Jou bewering klopt wel, maar dat wil niet zeggen dat je, door in een IDE te werken, geen ervaring op kan doen of geen begrip van programmeren kan hebben. Ik durf te beweren dat het in principe niet uitmaakt, hoewel door de bank genomen de programmeurs die met een shell werken waarschijnlijk betere programmeurs zijn.
[..]

heb je helemaal gelijk in; ik breng 't wat ongenuanceerder

maar 't toeval wil dat bij 't bedrijf waar ik werk in in principe geen enkel tool wordt gebruikt. we werken met oracle 8i, php en pl/sql en alles wordt met de hand gemaakt, geconfigureerd etc

hierdoor weten we wel precies wat er aan de hand is, en bijvoorbeeld het tweaken van een applicatie; het zoeken van errors, het optimaliseren van de database performance gebeurt gewoon vanaf de prompt.

we hadden laatst een sollicitant die een ZEER indrukwekkend cv had, qua programmeerervaring, gebruik van methodes, protocollen etc. Maar toen we hem nu vroegen wat er nou eigenlijk echt gebeurde .. daar kon ie geen antwoord op geven. Met tools kon ie alles, maar een simpele database corruptie fixen was voor hem totaal onmogelijk; wist nog niet eens dat je corrupties kon fixen

Wat ik dus wil zeggen: doordat we heel dicht bij de code zitten, weten we precies waar we mee bezig zijn, en wat de consequenties ervan zijn. het duurt dan wel langer voordat we concreet resultaat hebben/zien (met sql forms tooltje gewoon lekker een formulier bij elkaar slepen vanuit het database model (of iets dergelijks; geen bal verstand van) gaat supersnel, en wij zitten bij wijze van spreken een dag code te kloppen voordat we iets kunnen laten zien.

maargoed, voor beide methodes is wat te zeggen i presume

[whoami]

Op vrijdag 31 mei 2002 13:49 schreef TheDane het volgende:

we hadden laatst een sollicitant die een ZEER indrukwekkend cv had, qua programmeerervaring, gebruik van methodes, protocollen etc. Maar toen we hem nu vroegen wat er nou eigenlijk echt gebeurde .. daar kon ie geen antwoord op geven. Met tools kon ie alles, maar een simpele database corruptie fixen was voor hem totaal onmogelijk; wist nog niet eens dat je corrupties kon fixen

Dus, hebben jullie hem niet aangenomen? Indien dit zo is, zonde misschien. Zo'n dingen vallen te leren en zijn ook interessant voor die sollicitant.

[Nielsz]

Op vrijdag 31 mei 2002 13:49 schreef TheDane het volgende:

Tja, de vraag is of 'jouw' methode beter is als die bij andere bedrijven. Want jullie kunnen nu bugs oplossen in 1 dag ipv 2. Maar jullie doen er wel 3 dagen langer over om het product af te hebben. Dus in totaal zijn jullie een stuk trager. Lijkt me ook niet optimaal.

[Soultaker]

Op vrijdag 31 mei 2002 13:49 schreef TheDane het volgende:
hierdoor weten we wel precies wat er aan de hand is, en bijvoorbeeld het tweaken van een applicatie; het zoeken van errors, het optimaliseren van de database performance gebeurt gewoon vanaf de prompt.

Klopt, dat zie je vaak, en dat brengt vaak veel voordelen met zich mee. Daar ben ik het en sich wel mee eens.

we hadden laatst een sollicitant die een ZEER indrukwekkend cv had, qua programmeerervaring, gebruik van methodes, protocollen etc. Maar toen we hem nu vroegen wat er nou eigenlijk echt gebeurde .. daar kon ie geen antwoord op geven.

De vraag is of dit zo slecht is. Natuurlijk zijn er mensen die niet weten wat er intern gebeurd en tegelijkertijd rampzalige code schrijven, maar als je gewoon een goed begrip hebt van hoe interfacs (API's e.d.) benaderd dienen te worden en in staat bent naar specificaties te werken, kun je zeker goede programma's schrijven. Een sterk punt van OO-programmeren (en andere methoden voor het programmeren van complexe systemen) is nu juist dat je de implementatie niet hoeft te kennen om een component te kunnen gebruiken. Door juist niet te kijken wat er intern gebeurd, kun je er voor zorgen dat je implementatieonafhankelijke code schrijft.

Wanneer je bugs moet vinden, fouten moet herstellen of moet optimaliseren, ben je met deze filosofie sterk in het nadeel. Je hebt de kennis van de implementatie dan immers nodig. Dat betekent echter niet dat voor het programmeerwerk zelf de abstracte aanpak zeer geschikt is.

maargoed, voor beide methodes is wat te zeggen i presume

Dat ben ik dan wel weer met je eens.

[Verwijderd]

Op vrijdag 31 mei 2002 13:35 schreef Soultaker het volgende:
Pff, in vi kan ik niet eens klikken! Waar is de menubalk? Functietoetsen? Debugging environment? Data display? Link met (API/taal) documentatie?

/me zucht, dan maar verder offtopic

Klikken is nu juist wat een IDE (en een GUI) langzaam maakt. Telkens als ik een hand van m'n keyboard moet nemen om de muis te grijpen verlies ik tijd. Menubalk: idem dito, je bindt keys, en een keystroke gaat nog altijd sneller dan menunavigatie. Je kunt perfect een debugger starten via vi, of contextgevoelig een man/info page oproepen. De *NIX editors, en met name vi, zijn gemaakt om zo snel mogelijk te kunnen werken.

Wie denk dat vi een volwaardig alternatief vormt voor een IDE heeft nooit met een goede IDE gewerkt.

Het lijkt er meer op dat jij nog geen 5% van de features van de *NIX standaard editors kent.

[TheDane]

Op vrijdag 31 mei 2002 13:54 schreef Nielsz het volgende:

[..]

Tja, de vraag is of 'jouw' methode beter is als die bij andere bedrijven. Want jullie kunnen nu bugs oplossen in 1 dag ipv 2. Maar jullie doen er wel 3 dagen langer over om het product af te hebben. Dus in totaal zijn jullie een stuk trager. Lijkt me ook niet optimaal.

heb je op zich wel gelijk in. maar ik zeg ook niet dat 'mijn' methode beter is en als je eenmaal een x aantal componenten klaarhebt, die je maar in je nieuwe code hoeft in te bakken, dan ben je opzich ook best snel klaar.

Maar per saldo, als je over een heel jaar, met veel verschillende projecten, bekijkt, dan zou een 'toolfreak' (sorry voor de uberfoute woordkeuze) waarschijnlijk wel efficienter werken ja, maar da's een afweging natuurlijk, wij/ik vind 't belangrijk om ook te begrijpen waar ik mee bezig ben .. en als dat als keerzijde heeft dat ik er langer over doe .. helaas. maar dat heeft dan weer als keerzijde dat ik problemen sneller zie, en ook stukken sneller kan fixen.

dusja, ellek voordeel heb z'n nadeel

[Alarmnummer]

Op vrijdag 31 mei 2002 13:49 schreef TheDane het volgende:

[..]

heb je helemaal gelijk in; ik breng 't wat ongenuanceerder

maar 't toeval wil dat bij 't bedrijf waar ik werk in in principe geen enkel tool wordt gebruikt. we werken met oracle 8i, php en pl/sql en alles wordt met de hand gemaakt, geconfigureerd etc

hierdoor weten we wel precies wat er aan de hand is, en bijvoorbeeld het tweaken van een applicatie; het zoeken van errors, het optimaliseren van de database performance gebeurt gewoon vanaf de prompt.

we hadden laatst een sollicitant die een ZEER indrukwekkend cv had, qua programmeerervaring, gebruik van methodes, protocollen etc. Maar toen we hem nu vroegen wat er nou eigenlijk echt gebeurde .. daar kon ie geen antwoord op geven. Met tools kon ie alles, maar een simpele database corruptie fixen was voor hem totaal onmogelijk; wist nog niet eens dat je corrupties kon fixen

Wat ik dus wil zeggen: doordat we heel dicht bij de code zitten, weten we precies waar we mee bezig zijn, en wat de consequenties ervan zijn. het duurt dan wel langer voordat we concreet resultaat hebben/zien (met sql forms tooltje gewoon lekker een formulier bij elkaar slepen vanuit het database model (of iets dergelijks; geen bal verstand van) gaat supersnel, en wij zitten bij wijze van spreken een dag code te kloppen voordat we iets kunnen laten zien.

maargoed, voor beide methodes is wat te zeggen i presume

Er bestaat ook een gulden middenweg. Ik gebruik IDEA als IDE voor Java en dat werkt echt super. Er zit dus geen wizzards in zoals in jbuilder (hou ik zelf ook niet van), maar het werkt echt super handig. Je hebt hele goeie refactor mogelijkheden (geaumomatiseerd transformeren van stukken code), code completion, auto imports, syntax checking, inzich in code door extra text coloring (member variablen paars, ongebruikte variablen/methodes grijs). Ik zou niet meer zonder willen werken.

Ik ben het dus zeker niet met je eens dat je in een zo kaal mogelijke omgeving moet zitten om veel inzicht in je code te blijven houden.

link: http://www.intellij.com/idea/overview.jsp

[Bananenplant]

hmm... hoe word je een goede programmeur?

ik heb als het goed is straks m'n propedeuse WO informatica, en ik heb als het om manieren van denken gaat best wel wat geleerd dit jaar.

over algoritmen en dat analyse van problemen vaak efficiency kan winnen.

en bij inleiding object oriented programming hoe je een model maakt en uitprogrammeert etc.

ik heb ook gemerkt dat mensen die menen dat wiskunde en programmeren niks met elkaar te maken hebben fout zitten.

ik ben nu bezig mezelf sql, php te leren. eerst een model maken, daarna implementeren. gestructureerd deze keer, in tegen stelling tot de bloated code qbasic die ik in klas 2 maakte.

documenteren hou ik niet zo van eigenlijk. maar zulke grote programma's maak ik ook nog niet....

[drm]

mietje:
Het lijkt er meer op dat jij nog geen 5% van de features van de *NIX standaard editors kent.

pico roelt !!

[TheDane]

Op vrijdag 31 mei 2002 14:47 schreef drm het volgende:

[..]

pico roelt !!

geef mij maar vi

of liever nog vim

[Bananenplant]

vind emacs wel fijn. wel frustrerend dat de keycombo's niet in windowsprogramma's werken.

ctrl-e, ctrl-a, ctrl-k werken wel in de meeste X-programma's, nl.

[TheDane]

Op vrijdag 31 mei 2002 14:41 schreef Alarmnummer het volgende:

[..]

Er bestaat ook een gulden middenweg. Ik gebruik IDEA als IDE voor Java en dat werkt echt super. Er zit dus geen wizzards in zoals in jbuilder (hou ik zelf ook niet van), maar het werkt echt super handig. Je hebt hele goeie refactor mogelijkheden (geaumomatiseerd transformeren van stukken code) in. Code completion, auto import, syntax checking. Ik zou niet meer zonder willen werken.

Ik ben het dus zeker niet met je eens dat je in een zo kaal mogelijke omgeving moet zitten om veel inzicht in je code te blijven houden.

link: http://www.intellij.com/idea/overview.jsp

ik ken maar een kwart van die termen

( en weet totaal nul komma nul van java )

Ik heb me sinds borland pascal (een jaar of 7 geleden) niet meer beziggehouden met IDE's, ben er van overtuigd dat er hele goeie IDE's zijn, die 't werk stuk voor stuk een stuk efficienter maken, maar ik voel me d'r persoonlijk niet prettig bij,

ik gruwel al van zoiets als editplus, terwijl 't alleen maar makkelijker en overzichtelijker werkt (schijnbaar)

ieder z'n voorkeur

[Alarmnummer]

Om maar weer even ontopic te komen:

wat maakt een goeie programmeur goed..

hmmz...

1) technisch inzicht, goed abstractie vermogen. Als je dit niet hebt dan houd het allemaal op.
2) doorzettings vermogen.
3) plezier in wat je doet.
4) inzien dat jij niet altijd de beste oplossing hebt
5) open staan voor nieuwe ideeen ipv vast roesten in een bepaalde denk wereld.

[Verwijderd]

Op vrijdag 31 mei 2002 00:01 schreef TheDane het volgende:
[..]
onder een shell werken brengt je veel dichter bij de code waaraan je zit te prutsen.
met andere woorden: je bgrijpt veel beter waar je mee bezig bent; ergo je verstaat je vak beter. ergo je bent een betere programmeur

Wat een onnozel gebazel. Je moet werken met de tool die je het meeste resultaat oplevert. En als dat een codegenerator is, dan ben je slimmer die te gebruiken dan in een of andere kut-ascii editor met een 80x23 schermpje ellenlange lappen onoverzichtelijke bagger te tikken zonder enige hulp.

[TheDane]

Op vrijdag 31 mei 2002 15:46 schreef Otis het volgende:

[..]

Wat een onnozel gebazel. Je moet werken met de tool die je het meeste resultaat oplevert. En als dat een codegenerator is, dan ben je slimmer die te gebruiken dan in een of andere kut-ascii editor met een 80x23 schermpje ellenlange lappen onoverzichtelijke bagger te tikken zonder enige hulp.

heb jij uitleg hiervan in mijn latere posts gelezen ?

goezo

[Verwijderd]

Op vrijdag 31 mei 2002 16:12 schreef TheDane het volgende:

[..]

heb jij uitleg hiervan in mijn latere posts gelezen ?

goezo

Iedereen die roept dat een shell ook maar iets beter is dan wat dan ook snapt het niet. Iedere uitleg daarvan helpt dan niet.

Uberhaupt over tools praten in het kader van 'goede programmeur' is onzin, dan begrijp je het begrip 'programmeren' niet.

[Verwijderd]

Op vrijdag 31 mei 2002 13:49 schreef TheDane het volgende:
[..]
maar 't toeval wil dat bij 't bedrijf waar ik werk in in principe geen enkel tool wordt gebruikt. we werken met oracle 8i, php en pl/sql en alles wordt met de hand gemaakt, geconfigureerd etc

NIH in full effect!

hierdoor weten we wel precies wat er aan de hand is, en bijvoorbeeld het tweaken van een applicatie; het zoeken van errors, het optimaliseren van de database performance gebeurt gewoon vanaf de prompt.

En omdat je alles zelf maakt, moet je ook alles zelf testen en debuggen en uitontwikkelen nog voordat je met je eigenlijke werk kunt beginnen! Je concurrent pakt een pak tools van de plank, en begint meteen met wat hij wil bouwen, nl. wat de klant wil. Jullie moeten eerst jullie tools uitontwikkelen totdat ze productiviteit opleveren. Allemaal zonde van de tijd.

we hadden laatst een sollicitant die een ZEER indrukwekkend cv had, qua programmeerervaring, gebruik van methodes, protocollen etc. Maar toen we hem nu vroegen wat er nou eigenlijk echt gebeurde .. daar kon ie geen antwoord op geven. Met tools kon ie alles, maar een simpele database corruptie fixen was voor hem totaal onmogelijk; wist nog niet eens dat je corrupties kon fixen

Nou, die persoon mag blij zijn dat hij niet bij jullie is komen werken. No offence, maar een programmeur bouwt software en een systeembeheerder beheert systemen, een DBA beheert de database(s). Wellicht had die persoon met wat docs in de hand het allemaal snel opgelost. Nu wijs je hem af omdat hij die onnozele kennis niet bij zich heeft, die hij als programmeur helemaal niet HOEFT te hebben, want een goed bedrijf heeft iemand in dienst die dat oplost, die systemen beheert en de daarop draaiende databases, webserver software etc. Anders verlies je nl. kostbare productiviteit aan de developerkant, dat geld kost maar ook zeer frustrerend is voor de programmeurs.

Wat ik dus wil zeggen: doordat we heel dicht bij de code zitten, weten we precies waar we mee bezig zijn, en wat de consequenties ervan zijn.

Iemand die in Visual Studio.NET in C# een programma schrijft zit niet 'dicht bij de code' ? Wat zit die persoon dan? er ver vanaf? Weet die persoon NIET wat er gebeurt? Ik denk dat die persoon volledig weet wat er gebeurt. Anders kan die persoon nl. niet een programma bouwen. Die persoon gebruikt een off-the-shelf api en een serie off-the-shelf tools en is vanaf minuut 1 productief. IEDERE regel code die hij intikt bouwt mee aan hetgeen hij moet bouwen ipv dat deze is bedoeld voor tools die er al hadden moeten zijn.

De bekrompenheid druipt van je posting af. Als ik een tip mag geven: open je ogen en kijk om je heen en ga nadenken over wat er WERKELIJK telt bij het bouwen van software. Not Invented Here syndrome is een verschijnsel dat NIET telt bij het bouwen van software, het zorgt eerder voor afbreuk.

het duurt dan wel langer voordat we concreet resultaat hebben/zien (met sql forms tooltje gewoon lekker een formulier bij elkaar slepen vanuit het database model (of iets dergelijks; geen bal verstand van) gaat supersnel, en wij zitten bij wijze van spreken een dag code te kloppen voordat we iets kunnen laten zien.

Maar het eindresultaat van die off-the-shelf tools is beter dan jouw code. Weet je waarom? Omdat die off-the-shelf tools werken. Je kan verwachten wat het resultaat is. Al waar je op moet letten is of je ze correct bedient en dan is in theorie je resultaat foutloos. Jij moet allereerst je tools bugfree zien te krijgen en dan nog eens de bediening ervan foutloos doen (via code of handmatig). Dubbel traject, dubbele kans op fouten.

maargoed, voor beide methodes is wat te zeggen i presume

Nee. Er is maar 1 weg naar succes in de software wereld: voortbouwen op gestabiliseerde kennis en kunde. Zelf alles willen doen is de grootst mogelijke domme blunder die je kunt begaan. ZEKER als er bakken met tools beschikbaar zijn maar je per se kiest voor 'zelf doen', het Not Invented Here syndrome.

[Soultaker]

Op vrijdag 31 mei 2002 16:23 schreef Otis het volgende:
Iedereen die roept dat een shell ook maar iets beter is dan wat dan ook snapt het niet. Iedere uitleg daarvan helpt dan niet.

En bedankt voor de genuanceerde uitspraak. Als ik zeg dat een beter shell is dan niets, dan snap ik het niet? Als je het met TheDane's redenatie niet eens hebt, val 'm dan aan op zijn aannames en argumenten. Hier hebben we niets aan.

Uberhaupt over tools praten in het kader van 'goede programmeur' is onzin, dan begrijp je het begrip 'programmeren' niet.

Jij wel dan? Volgens mij is er geen vaste definitie van wat wel en niet programmeren is.

[Nielsz]

Op vrijdag 31 mei 2002 16:38 schreef Otis het volgende:
Nee. Er is maar 1 weg naar succes in de software wereld: voortbouwen op gestabiliseerde kennis en kunde. Zelf alles willen doen is de grootst mogelijke domme blunder die je kunt begaan. ZEKER als er bakken met tools beschikbaar zijn maar je per se kiest voor 'zelf doen', het Not Invented Here syndrome.

Echt waanzinnig offtopic:

The knights who say NIH!
Nu snap ik 'm

[Verwijderd]

Op vrijdag 31 mei 2002 16:40 schreef Soultaker het volgende:
[..]
En bedankt voor de genuanceerde uitspraak. Als ik zeg dat een beter shell is dan niets, dan snap ik het niet? Als je het met TheDane's redenatie niet eens hebt, val 'm dan aan op zijn aannames en argumenten. Hier hebben we niets aan.

Beter dan niets voor wat? Je dorst lessen? Vervoer? Zie je hoe dom het is om uberhaupt over tools te praten mbt het begrip 'goede programmeur' ? Ik gebruik een shell alleen voor af en toe een commandootje te executeren. (dir /b /s *.asp | findstr /f:/ "bla" bijvoorbeeld) Maw: de effectiviteit van een tool is relatief aan het doel, de omgeving, de bediener en de kwaliteit van de alternatieven. Programmeren is echter een abstract begrip en staat los van welke taal/tool dan ook (programmeertaal is ook een tool btw)

[..]
Jij wel dan? Volgens mij is er geen vaste definitie van wat wel en niet programmeren is.

Jawel, die staat gewoon inde vandale:

pro·gram·Žme·ren (ov.ww.)

1 [ook abs.] (computeropdrachten) vaststellen in een gecodeerde taal
2 een programma opstellen van
3 (een computer) laden met een programma

[Verwijderd]

Anders bouw je gewoon ff alles van scratch. Onzin

Ik vind gewoon dat je een bepaalde kennis moet hebben van het systeem waar je op bouwt. Of het nou unix is of winhoos. Ik bouw al jaren Db appl op windows 2000 en SQL. Mijn kennis wordt steeds groter op het gebied van proggen maar ook op een stuk systeembeheer. De meest programmeurs willen alleen de software kant kennen. Lang leve het OSI model. Als je die kent, ken je het systeem, en dan pas kan je kinky dingen bouwen.

Of je nou tools gebruikt of niet. Je hoeft niet het wiel opnieuw uit te vinden. Aan zulke dingen zijn bedrijven failliet gegaan of ze gaan heel slecht. Je pakt toch gewoon de taal die jouw het meeste bied!

[TheDane]

Op vrijdag 31 mei 2002 16:38 schreef Otis het volgende:

[..]

NIH in full effect!
[..]

En omdat je alles zelf maakt, moet je ook alles zelf testen en debuggen en uitontwikkelen nog voordat je met je eigenlijke werk kunt beginnen! Je concurrent pakt een pak tools van de plank, en begint meteen met wat hij wil bouwen, nl. wat de klant wil. Jullie moeten eerst jullie tools uitontwikkelen totdat ze productiviteit opleveren. Allemaal zonde van de tijd.
[..]

Nou, die persoon mag blij zijn dat hij niet bij jullie is komen werken. No offence, maar een programmeur bouwt software en een systeembeheerder beheert systemen, een DBA beheert de database(s). Wellicht had die persoon met wat docs in de hand het allemaal snel opgelost. Nu wijs je hem af omdat hij die onnozele kennis niet bij zich heeft, die hij als programmeur helemaal niet HOEFT te hebben, want een goed bedrijf heeft iemand in dienst die dat oplost, die systemen beheert en de daarop draaiende databases, webserver software etc. Anders verlies je nl. kostbare productiviteit aan de developerkant, dat geld kost maar ook zeer frustrerend is voor de programmeurs.
[..]

Iemand die in Visual Studio.NET in C# een programma schrijft zit niet 'dicht bij de code' ? Wat zit die persoon dan? er ver vanaf? Weet die persoon NIET wat er gebeurt? Ik denk dat die persoon volledig weet wat er gebeurt. Anders kan die persoon nl. niet een programma bouwen. Die persoon gebruikt een off-the-shelf api en een serie off-the-shelf tools en is vanaf minuut 1 productief. IEDERE regel code die hij intikt bouwt mee aan hetgeen hij moet bouwen ipv dat deze is bedoeld voor tools die er al hadden moeten zijn.

De bekrompenheid druipt van je posting af. Als ik een tip mag geven: open je ogen en kijk om je heen en ga nadenken over wat er WERKELIJK telt bij het bouwen van software. Not Invented Here syndrome is een verschijnsel dat NIET telt bij het bouwen van software, het zorgt eerder voor afbreuk.
[..]

Maar het eindresultaat van die off-the-shelf tools is beter dan jouw code. Weet je waarom? Omdat die off-the-shelf tools werken. Je kan verwachten wat het resultaat is. Al waar je op moet letten is of je ze correct bedient en dan is in theorie je resultaat foutloos. Jij moet allereerst je tools bugfree zien te krijgen en dan nog eens de bediening ervan foutloos doen (via code of handmatig). Dubbel traject, dubbele kans op fouten.
[..]

Nee. Er is maar 1 weg naar succes in de software wereld: voortbouwen op gestabiliseerde kennis en kunde. Zelf alles willen doen is de grootst mogelijke domme blunder die je kunt begaan. ZEKER als er bakken met tools beschikbaar zijn maar je per se kiest voor 'zelf doen', het Not Invented Here syndrome.

fijne post, maar met je laatste paragraaf kukelt het hele zaakje natuurlijk wel genadelijk in elkaar: voortbouwen op bestaande dingen is leuk, maar al het gezeik waar bijvoorbeeld microsoft / windows nu mee zit, is het gevolg van een fout begin. backwards compatibility, vastzitten aan een gedachtengoed dat tig jaar geleden state of the art was ,.

enzovoort enzovoort,.
allemaal leuk en aardig dus, maar dan kies ik er liever voor om m'n zaakjes nog wel een keer opnieuw uit te vinden. en dan WEL goed.

overigens: jij hebt 't over bedrijven die een aparte systeembeheerder / dba etc werk kunnen bieden. d'r zijn genoeg kleine bedrijven waarbij zo'n functie niet dagvullend is, dus ga je je met meer dingen bezighouden.


maar iemand die met tooltjes kan werken, kan ongetwijfeld goed werk afleveren, en zoals je zelf al zegt: in theorie foutloos. maarja, d'r zijn altijd wel zaken waar geen rekening mee gehouden is; bijvoorbeeld een corrupte database,.

ik heb inmiddels 't gros van de foutmeldingen wel meegemaakt, en daar ben ik blij om! Met tools leren werken kan iedereen; begrijpen hoe het tool werkt niet ..

maargoed, we gaan nu wel erg ver offtopic, dussuh,
/off

[Verwijderd]

Op vrijdag 31 mei 2002 17:01 schreef TheDane het volgende:
[..]
fijne post, maar met je laatste paragraaf kukelt het hele zaakje natuurlijk wel genadelijk in elkaar: voortbouwen op bestaande dingen is leuk, maar al het gezeik waar bijvoorbeeld microsoft / windows nu mee zit, is het gevolg van een fout begin. backwards compatibility, vastzitten aan een gedachtengoed dat tig jaar geleden state of the art was ,.

Nee, je snapt het niet. Gebruik de tools die voorhanden zijn en focus op de dingen die je moet maken, alleen DAN kom je vooruit.

Je gelul over windows/microsoft snap ik niet, wat is daar fout aan? Is het unix systeem geen fout begin geweest?

.NET bijvoorbeeld geeft aan dat een flexibele instelling mbt tools/talen en een abstracte kijk op programmeren je als developer veel sneller ergens brengt dan het halsstarrige dreinen dat je alles zelf wilt bouwen: zodra jouw platform out-dated is ben je het haasje en moet je voor een nieuw platform ALLE tools weer opnieuw maken. Iemand die off-the-shelf spul gebruikt past zn denken toe in een ander raamwerk maar komt binnen no-time tot goed resultaat, immers de tools werken al, hij hoeft alleen ze maar te gebruiken.

enzovoort enzovoort,.
allemaal leuk en aardig dus, maar dan kies ik er liever voor om m'n zaakjes nog wel een keer opnieuw uit te vinden. en dan WEL goed.

*gaap*. Dus jij koopt ook een stuk ijzer en gaat daar eerst een hamer van bakken voordat je gaat timmeren? Of is dat ineens anders?

overigens: jij hebt 't over bedrijven die een aparte systeembeheerder / dba etc werk kunnen bieden. d'r zijn genoeg kleine bedrijven waarbij zo'n functie niet dagvullend is, dus ga je je met meer dingen bezighouden.

Dat boeit toch niet? Je wijst dan toch iemand aan in de organisatie die dat regelt? En aangezien deze persoon nieuw was, hebben jullie al zo'n persoon intern. (als het goed is).

maar iemand die met tooltjes kan werken, kan ongetwijfeld goed werk afleveren, en zoals je zelf al zegt: in theorie foutloos. maarja, d'r zijn altijd wel zaken waar geen rekening mee gehouden is; bijvoorbeeld een corrupte database,.

Je snapt het werkelijk niet he. Als een developer met een corrupte database wordt geconfronteerd (wat je daar onder ook moge verstaan, ik neem aan dat je niet bedoeld een corrupte mempage table of corrupte pages in de storage), kan hij documentatie pakken en het proberen op te lossen of een daarvoor aangewezen persoon inzetten.

Iemand die met tools werkt en daarmee resultaat bereikt is productief en dus nuttig bezig. Iemand die eerst zn eigen development omgeving moet programmeren voordat hij productief kan zijn, gaat maar in de hobbykamer spelen, want dat wordt niet wat: tools zijn er niet voor niets. Gebruik ze. En doet een tool iets voor 99% en je hebt net die ene 1% nodig, kijk dan naar een andere tool of bouw een additional tool die die ene 1% aanvult, ipv een tool te bouwen die 100% op zich neemt.

Dit topic gaat over 'goede programmeur'. Ik vind dat wanneer je NIET inziet dat productiviteit in de breedste zin van het woord (dus gelet op alle gestelde randvoorwaarden) key is, je geen goede programmeur bent en zeker niet goed wordt geleid/gestuurd: een manager van een bedrijf dat zn developmentteam opzadelt met het opnieuw bouwen van tools die je zo kunt downloaden of kunt kopen voor een habbekrats, leidt niet maar remt.

ik heb inmiddels 't gros van de foutmeldingen wel meegemaakt, en daar ben ik blij om! Met tools leren werken kan iedereen; begrijpen hoe het tool werkt niet ..

Oh, dus jij bent er zoeen die vindt dat je pas goede software kunt schrijven als je weet hoe de compiler werkt? Software bouwen is abstract. Of schrijf jij alles in assembler, want dat staat het dichtst bij de code gebruikt door de processor en kun je tenminste goed bepalen hoe het geheel wordt geoptimaliseerd ? Als voor jouw werk een generator wordt gebouwd, die code kan genereren die jij anders met de hand inklopt, waarom zou men die niet gebruiken? Genereren die hap, handmatig wat tweaken en klaar. Of minder radicaal: een 4GL omgeving voor je 3GL werk: puur simpele statements ingeven die de functionaliteit verwoorden die je moet implementeren: een abstractieniveauverhoging die de softwarebouwer alleen maar helpt: het werk ontdoen van randverschijnselen en de developer puur laten focussen op hetgeen gedaan moet worden. Juist DIE keuze maken als developer is de enige correcte en geeft aan dat de developer JUIST weet waar hij mee bezig is. Die keuze bewust NIET maken laat zien dat de developer juist NIET snapt waar hij mee bezig is en programmeren verwart met het werk dat de 4GL compiler / 3GL generator ook doet.

maargoed, we gaan nu wel erg ver offtopic, dussuh,

Nee, het is juist on topic, want dit is de kern van de zaak.

[mbravenboer]

Het blijft wel een terugkerend verhaal hoe je productiviteit het beste kunt vergroten.

Productiviteit staat denk ik voor een groot deel gelijk aan abstractie en beheersing van complexiteit. Ik praat daarom maar even over abstractie ipv productiviteit omdat bij productiviteit snel andere randzaken betrokken kunnen worden. De kern van de zaak voor de lange termijn is echter abstractie.

Otis omschrijft abstractie graag in termen van code-generators, tools, visueel werken. Zoals we al in een eerdere discussie over abstractie hebben gezien ben ik het daar niet mee eens. Althans: tools en code-generatie zijn belangrijk, maar het gaat niet om de tools, maar om de input van de tools.

De effectiviteit van een taal hangt daarom vooral af van de vorm van de input. In hoeverre:

1. abstraheert deze? Lift het de kijk op de zaak op een hoger niveau?
2. zijn de input mogelijkheden niet te specifiek voor een bepaald probleem?

Ik zelf geloof dat visueel werken, interactieve tools en ad-hoc code generatoren niet veel toevoegen omdat ze voornamelijk op punt (2) op dit moment vaak zeer gebrekkig zijn.

Het gaat namelijk in heel de informatica om het specificeren van een situatie.

Als voorbeeld: bij imperatief programmeren is de afstand tot een specificatie vaak erg groot. Je moet in je hoofd tijdens het programmeren de specificatie omzetten in een implementatie: je geeft aan hoe iets moet gebeuren waarvan in de specificatie beschreven staat wat er moet gebeuren.

Bij talen als SQL zie je een duidelijke abstractie: je geeft op een hele prettig manier aan wat er moet gebeuren en abstraheert daarbij werkelijk enorm van de concrete implementatie: hoe moet de query of update uitgevoerd worden. SQL is dus duidelijk een taal die een stuk dichter bij een specificatie staat. Dit wordt ook weleens declaratief genoemd, maar dat vind ik eigenlijk geen prettige term.

Ik zie erg veel toekomst voor specificerende talen. Dit kan twee kanten opgaan:

1. Talen die zich richten op een algemeen toepassingsgebied. Ze zijn dus niet domein-specifiek. Deze groep van talen zal echter meer bieden tov de huidige imperatieve talen omdat de implementatie niet direct gericht is op de architectuur van een moderne computer zoals je in alle imperatieve talen ziet. Ze bieden dus een hele eigen manier van uitdrukking zonder dat ze daarbij rekening houden met de architectuur van een computer. Bekende voorbeelden zijn functionele talen (Haskell, Clean) maar bijvoorbeeld ook transformatie-talen als XSLT (wat gericht is op een bepaald type operatie, maar niet op een bepaald applicatie domein) en Stratego.

2. Talen die zich richten op een bepaald domein. Dit worden ook wel domein specifieke talen genoemd (DSL). De grens met de talen in punt (1) is niet altijd even duidelijk, maar je kunt het vaak wel aanvoelen. DSLs zijn gericht op een bepaald domein en zorgen dat jij voor dat domein heel prettig kunt beschrijven (specificeren) wat jouw situatie is. De specificatie in een DSL gaat vaak erg richting een soort data: je schetst een situatie.

Persoonlijk denk ik dat de talen in categorie (1) toch ooit nog eens belangrijk gaan worden. XSLT is een treffend voorbeeld en eigenlijk de eerste declaratieve taal die door de 'gewone man' echt algemeen gebruikt wordt. In de toekomst zullen er meer van zulke talen doorbreken.

De talen in categorie (1) zullen altijd taal-georienteerd blijven. Tools voor deze categorie zijn in feite compilers of eenvoudigere transformaties die een taal omzetten naar een implementatie in termen van een computer-architectuur: ze voegen een hoe toe voor een uitvoer op een computer.

De talen in categorie (2) zouden wellicht eerder richting visueel werken kunnen gaan, maar toch geloof ik het zelfs daar niet echt. Specificeren in een taal is qua uitdrukkingskracht op dit moment volledig superieur aan specificeren via visualisatie en interactie. Bij interactie met een visuele omgeving moet de visuele omgeving namelijk behoorlijk geavanceerd in elkaar zitten en rekening kunnen houden met allerlei typen van gebruik en combinaties daarvan. Het ontwerpen van zo'n visuele omgeving (waarin je dus echt visueel programmeert, ik heb het niet over een feature rijke editor) is enorm lastig (wat natuurlijk niet per definitie betekent dat het nooit goed gedaan zal worden).

Ik moest van week een tooltje schrijven wat een vrij lastige bewerking op een XML-achtig document uitvoerde. Deze bewerking was ik eerst aan het implementeren in Java, maar om 2 redenen was ik dit na een regel of 200 zat: (1) ik moest een aantal aannames maken die ik niet wilde maken in 200 regels Java code. (2) ik besefte dat ik veel beter een krachtige transformatie-taal kon gebruiken. Ik heb toen de code weggeflikkerd en de hele zaken compact gespecificeerd in ongeveer 10 regels Stratego code. Resultaat: de code was inzichtelijk, aannames waren compact beschrijven en de correctheid van de code is eenvoudig in te zien. Bij 200 regels Java/C# code is dat gegarandeerd een stukje lastiger .

In de toekomst zou je steeds meer talen moeten kunnen pakken waarin je je probleem compact kunt specificeren. Deze talen moeten gerealiseerd worden met tools, de tools zijn daarbij een noodzakelijk iets: het gaat niet om de tools, maar om het niveau waarop je over je probleem kunt praten en op welke manier je het dus kunt specificeren.

Tot zover dit verhaaltje over abstractie, tools, visueel werken, talen en de toekomst .

Als je reageert vanuit een pro-tool visie: merk op dat ik niets tegen tools zeg, maar dat het naar mijn mening duidelijk om de input-mogelijkheden van een tool gaat.

[Verwijderd]

Op vrijdag 31 mei 2002 18:29 schreef mbravenboer het volgende:
Otis omschrijft abstractie graag in termen van code-generators, tools, visueel werken. Zoals we al in een eerdere discussie over abstractie hebben gezien ben ik het daar niet mee eens. Althans: tools en code-generatie zijn belangrijk, maar het gaat niet om de tools, maar om de input van de tools.

Erm, nee, dat doe ik juist niet. Ik omschrijf abstractie in het geheel niet in termen van tools etc., ik gebruik voorbeelden van tools als metafoor/middel om aan te geven dat abstractie van hetgeen men mee bezig is juist hetgeen hier bediscussieerd moet worden en verder totaal niets. Je kunt nl. wel praten over abstractie maar veel mensen kunnen daar al snel geen touw meer aan vast knopen. Een metafoor als 4GL <-> 3GL is al veel tastbaarder. Ik bedoel echter wel degelijk de abstractie, of het begrip abstractie in de context softwarebouw/engineering, en niet '4GL' of '3GL', dat is slechts het middel om iets duidelijk te maken.

Als je verder had gekeken, schoffeer ik het begrip 'tool' en 'taal' (wat ik gelijk stel aan 'tool') in deze discussie want ze zijn totaal niet belangrijk: het zijn middelen om te bereiken wat je wilt/moet bereiken en verder niets. Denken in tools is in mijn ogen dan ook bekrompen en past alleen maar bij een hobbykamer of bij fetisjistenmeetings met gelijk gestemden.

De effectiviteit van een taal hangt daarom vooral af van de vorm van de input. In hoeverre:
1. abstraheert deze? Lift het de kijk op de zaak op een hoger niveau?

Abstraheren is afleiden. , je bedoelt: in hoeverre maakt de taal de materie abstract voor de gebruiker?

2. zijn de input mogelijkheden niet te specifiek voor een bepaald probleem?
Ik zelf geloof dat visueel werken, interactieve tools en ad-hoc code generatoren niet veel toevoegen omdat ze voornamelijk op punt (2) op dit moment vaak zeer gebrekkig zijn.

De uitvoering van een idee is nooit de scherprechter voor de kwaliteit van een idee. Nooit vergeten.

Het gaat namelijk in heel de informatica om het specificeren van een situatie.

Onder andere ja. Maar niet alleen het specificeren van een situatie, maar ook het specificeren van het waarom van die situatie, het bereiken van die situatie en de gevolgen van die situatie. (ik neem aan dat je met 'situatie' bedoelt, de gewenste state na analyse van een zekere problematiek)

Als voorbeeld: bij imperatief programmeren is de afstand tot een specificatie vaak erg groot. Je moet in je hoofd tijdens het programmeren de specificatie omzetten in een implementatie: je geeft aan hoe iets moet gebeuren waarvan in de specificatie beschreven staat wat er moet gebeuren.

Maar in feite ben je handmatig aan het uitvoeren wat een 4GL compiler genereert voor een 3GL (voorbeeld). Je zou dus kunnen stellen, dat wanneer je een 4GL compiler hebt voor een zekere 3GL, je programmeren OF opnieuw moet definieren, vanuit de POV van de 3GL developer, OF je programmeren uberhaupt als abstract begrip moet definieren ZONDER te letten op talen/tools, en dus moet gaan praten over de specificatie WAT gebouwd moet worden, of beter: het opstellen van die specificatie(s) met inbegrip van de nevenwerkzaamheden daarbij (ontwerpbeslissingen nemen/analyses etc).

[de toekomst volgens mbravenboer]
In de toekomst zou je steeds meer talen moeten kunnen pakken waarin je je probleem compact kunt specificeren. Deze talen moeten gerealiseerd worden met tools, de tools zijn daarbij een noodzakelijk iets: het gaat niet om de tools, maar om het niveau waarop je over je probleem kunt praten en op welke manier je het dus kunt specificeren.

De taal is ook een tool. Immers: hij is net zo inwisselbaar als een tool. t.a.t. is een taal niets anders dan een tussenvorm tussen ontwerp/ideeen enerzijds en lowlevel implementatie in opcodes anderzijds. En als je een tussenvorm hebt tussen 2 uitersten, kun je altijd een andere tussenvorm definieren die dichter bij een van beide uitersten staat. Hoe dichter bij de ontwerp/ideeen kant, hoe abstracter. Door de tool 'abstractievergroting' krijg je een taal op abstractieniveau n+1 die je als tool kunt zien van de taal op abstractieniveau n.

Op dit moment zijn programmeertalen een noodzakelijk iets. In theorie zijn ze niet nodig: als je in een zekere vorm je ontwerp kunt weergeven zodat het ook door computers kan worden gelezen heb je geen programmeertalen meer nodig. Iedere vorm van programmeertaal is dus in feite het invullen van het gebrek aan die feature. Het handmatig inbeitelen van ellenlange lappen cryptische programmateksten is een gevolg van het gebrek aan een taal/tool op een abstractieniveau hoger dan het abstractieniveau waar de taal/tool van de cryptische programmateksten op is gesitueerd.

Ik geloof stellig dat over een veelvoud van jaren de mensheid een zeker abstractieniveau zal bereiken in 'programmeertalen' dat men werkelijk daarmee automatisch programmeertalen overbodig maakt. Tot die tijd zijn beitelaars nodig en eigenlijk nog meer mensen die de abstractieniveaus van hedendaagse talen/tools opwerken naar een hoger level zodat noeste beitelaars steeds minder en minder nodig zullen zijn.

Als je reageert vanuit een pro-tool visie: merk op dat ik niets tegen tools zeg, maar dat het naar mijn mening duidelijk om de input-mogelijkheden van een tool gaat.

It's software, thus it solves a problem. Solve the cause of the problem and kill the need for the software.

[mbravenboer]

het zijn middelen om te bereiken wat je wilt/moet bereiken en verder niets. Denken in tools is in mijn ogen dan ook bekrompen en past alleen maar bij een hobbykamer of bij fetisjistenmeetings met gelijk gestemden.

Er is best wel een reden om te kicken op een tool of een taal. Je bent geen fan van een tool omdat je het tool zo mooi vind, maar omdat het iets moois doet. Het stelt jezelf in staat om te abstraheren en je prettiger en compacter uit te kunnen drukken. Denken in tools als oplossingen is daarom niet bekrompen, zolang je de tools maar wel als middel blijft zien.

Abstraheren is afleiden. je bedoelt: in hoeverre maakt de taal de materie abstract voor de gebruiker?

Nee hoor, ik bedoel precies wat ik zeg . Ik bedoel uiteraard niet abstraheren van het probleem, maar het abstraheren in de implementatie: in hoeverre biedt het tool een kijk op de zaak die niet belandt in een overzichtelijke lap zooi die zich met irrelevante details bezig houdt (zoals in imperatieve implementaties).

De taal is ook een tool

Mwah, daar ben ik het niet mee eens. Een programmeertaal is een methode om een computer te instrueren om bepaalde operaties uit te voeren. De taal is echter geen uitvoering: je kunt in de taal slechts de situatie specificeren. Zelfs in een imperatieve taal ben je aan het specificeren: je specificeert in het model van een computer wat er gedaan moet worden. In een functionele taal specificeer je wat er moet gebeuren met behulp van vele functies en in XSLT specificeer je wat er moet gebeuren door middel van templates die toegepast kunnen worden op bepaalde paden in een boom.

Je kunt je probleem op allerlei methoden specificeren, maar voor alle specificaties gebruik je een taal. Je kunt gerust een andere taal gebruiken, dan specificeer je de situatie gewoon in een andere model.

Formele freaks specificeren hun probleem bijvoorbeeld graag in formele definities, wannabee wiskundige informatici specificeren hun probleem graag in termen functies en hobbyisten die server-side applicaties bouwen specificeren hun probleem in PHP. Dat daarvoor wellicht nog andere vormen van specificaties hebben plaats gevonden staat los van het feit dat je nog steeds aan het specificeren bent.

Een tool is iets heel anders: in een tool specificeer je niets. Een tool geef je een input en het tool gaat aan de hand van die input iets voor jou genereren of doen. Uitvoering van specificaties vindt dus plaats in tools. Een compiler is ook slechts een uitvoering van een specificatie. Een compiler zet de specificatie in een bepaalde input-taal namelijk om naar een bepaalde andere vorm. Een compiler zelf kan je echter niet inrichten voor een bepaalde situatie.

Op dit moment zijn programmeertalen een noodzakelijk iets. In theorie zijn ze niet nodig: als je in een zekere vorm je ontwerp kunt weergeven zodat het ook door computers kan worden gelezen heb je geen programmeertalen meer nodig. Iedere vorm van programmeertaal is dus in feite het invullen van het gebrek aan die feature.

Je ziet het begrip 'taal' denk ik te beperkt. Je kunt in een taal iets specificeren. Ook een ontwerp is in feite geschreven in een taal. Dat je bij het samenstellen van een UML echter niets intikt, is slechts omdat er een tool is die een visuele manier biedt waarop jij je probleem kunt specificeren.

De tekst-gerichte input is ook slechts 1 manier van input. Je kunt gerust zeggen dat visuele ontwikkeling naar jouw mening een betere of makkelijkere manier is om iets te specificeren in een taal, maar daarmee zeg je dus niet dat de taal onzinnig is. Talen zijn een feit waar je niet omheen kunt en ook niet wilt. De syntaxtische vorm kan je wellicht niet aanstaan, maar dat is een detail.

Overigens vind ik dus wel dat de syntaxtische vorm meer toekomst heeft dan de visuele vorm, maar goed... Dat is een hele lastige discussie ;-) .

Het handmatig inbeitelen van ellenlange lappen cryptische programmateksten is een gevolg van het gebrek aan een taal/tool op een abstractieniveau hoger dan het abstractieniveau waar de taal/tool van de cryptische programmateksten op is gesitueerd.

Helaas associeer jij het handmatig inbeitelen van ellenlange lappen cryptische programmateksten met het fenomeen 'taal'. Dat is dus onjuist. Om jezelf even te citeren:

De uitvoering van een idee is nooit de scherprechter voor de kwaliteit van een idee. Nooit vergeten.

Kijk eens naar SQL, XPath, Haskell, Stratego of 1 van de vele, vele domein specifieke talen. Kijk eens naar generatoren van relationeel-OO mappings, kijk eens naar XML data-binding specificaties: het zijn allemaal talen die je in staat stellen om de specificatie op een compacte en duidelijke manier aan te geven. Ook dit zijn talen en dit zijn dus de ideeen die naar mijn mening de toekomst hebben: talen die je voor een bepaald domein in staat stellen om prettig te specificeren wat de situatie is.

[TheDane]

Op vrijdag 31 mei 2002 17:42 schreef Otis het volgende:

[..]

Nee, je snapt het niet. Gebruik de tools die voorhanden zijn en focus op de dingen die je moet maken, alleen DAN kom je vooruit.

Je gelul over windows/microsoft snap ik niet, wat is daar fout aan? Is het unix systeem geen fout begin geweest?

.NET bijvoorbeeld geeft aan dat een flexibele instelling mbt tools/talen en een abstracte kijk op programmeren je als developer veel sneller ergens brengt dan het halsstarrige dreinen dat je alles zelf wilt bouwen: zodra jouw platform out-dated is ben je het haasje en moet je voor een nieuw platform ALLE tools weer opnieuw maken. Iemand die off-the-shelf spul gebruikt past zn denken toe in een ander raamwerk maar komt binnen no-time tot goed resultaat, immers de tools werken al, hij hoeft alleen ze maar te gebruiken.
[..]

*gaap*. Dus jij koopt ook een stuk ijzer en gaat daar eerst een hamer van bakken voordat je gaat timmeren? Of is dat ineens anders?
[..]

Dat boeit toch niet? Je wijst dan toch iemand aan in de organisatie die dat regelt? En aangezien deze persoon nieuw was, hebben jullie al zo'n persoon intern. (als het goed is).
[..]

Je snapt het werkelijk niet he. Als een developer met een corrupte database wordt geconfronteerd (wat je daar onder ook moge verstaan, ik neem aan dat je niet bedoeld een corrupte mempage table of corrupte pages in de storage), kan hij documentatie pakken en het proberen op te lossen of een daarvoor aangewezen persoon inzetten.

Iemand die met tools werkt en daarmee resultaat bereikt is productief en dus nuttig bezig. Iemand die eerst zn eigen development omgeving moet programmeren voordat hij productief kan zijn, gaat maar in de hobbykamer spelen, want dat wordt niet wat: tools zijn er niet voor niets. Gebruik ze. En doet een tool iets voor 99% en je hebt net die ene 1% nodig, kijk dan naar een andere tool of bouw een additional tool die die ene 1% aanvult, ipv een tool te bouwen die 100% op zich neemt.

Dit topic gaat over 'goede programmeur'. Ik vind dat wanneer je NIET inziet dat productiviteit in de breedste zin van het woord (dus gelet op alle gestelde randvoorwaarden) key is, je geen goede programmeur bent en zeker niet goed wordt geleid/gestuurd: een manager van een bedrijf dat zn developmentteam opzadelt met het opnieuw bouwen van tools die je zo kunt downloaden of kunt kopen voor een habbekrats, leidt niet maar remt.
[..]

Oh, dus jij bent er zoeen die vindt dat je pas goede software kunt schrijven als je weet hoe de compiler werkt? Software bouwen is abstract. Of schrijf jij alles in assembler, want dat staat het dichtst bij de code gebruikt door de processor en kun je tenminste goed bepalen hoe het geheel wordt geoptimaliseerd ? Als voor jouw werk een generator wordt gebouwd, die code kan genereren die jij anders met de hand inklopt, waarom zou men die niet gebruiken? Genereren die hap, handmatig wat tweaken en klaar. Of minder radicaal: een 4GL omgeving voor je 3GL werk: puur simpele statements ingeven die de functionaliteit verwoorden die je moet implementeren: een abstractieniveauverhoging die de softwarebouwer alleen maar helpt: het werk ontdoen van randverschijnselen en de developer puur laten focussen op hetgeen gedaan moet worden. Juist DIE keuze maken als developer is de enige correcte en geeft aan dat de developer JUIST weet waar hij mee bezig is. Die keuze bewust NIET maken laat zien dat de developer juist NIET snapt waar hij mee bezig is en programmeren verwart met het werk dat de 4GL compiler / 3GL generator ook doet.
[..]

Nee, het is juist on topic, want dit is de kern van de zaak.

/bla
fijn jij wint

sjonge jonge, waar gaat dit nog over

lees ff mijn eerste post , die WEL ontopic was, en reageer daar op ofzo

overigens:

de manier van werken verschilt per organisatie.

een nieuweling die alles van werken met tools weet, maar niets van de onderliggende aspecten just does not fit in, want dan zouden we de hele bedrijfscultuur aan zijn manier van werken aan moeten passen, met alle gevolgen van dien.

vast niet de bedoeling.

en jij overschat 't bedrijf waar ik werk

[Verwijderd]

Leuk topic. .

Mijn bijdrage: een goede programmeur staat boven zijn code en snapt dus waar hij mee bezig is.

Dat is alles ja. En dat is het moeilijkste wat er is.

Daarnaast zijn er specifieke eisen die een programma goed maken, zoals een cleane opbouw (code design) qua classes, functions per class, etc., efficiente code (zo weinig mogelijk code duplicaten, zoveel mogelijk een classed design dus), het liefst enigzins geoptimaliseerd voor minder perfecte hardware. Maar het allerbelangrijkste is dat een programmeur verder kijkt dan zijn eigen systeem, dat hij dus overzicht houdt en weet waar hij mee bezig is. En dan kom je al snel weer terug bij mijn eerste punt.

[Kappie]

Een goede programmeur is iemand die de problemen van een gebruiker kan omzetten in een goed werkend programma.

Meeste programmeurs kunnen dit technisch gezien wel aan. De moeilijkheid met programmeren is het zo dat de gebruiker er goed mee kan omgaan.

[Sponz]

Op vrijdag 31 mei 2002 22:07 schreef beelzebubu het volgende:
Leuk topic. .

Mijn bijdrage: een goede programmeur staat boven zijn code en snapt dus waar hij mee bezig is.

Dat is alles ja. En dat is het moeilijkste wat er is.

Gelul. Elke programmeur die iets maakt dat werkt snapt z'n code wel.

Verder ontbreekt in de discussie aan een referentie kader. Wat is slecht, wat is goed, wat is goed genoeg, wat is uitstekend?

* Sponz is goed genoeg voor een aardig salaris

Beheersing van tools, editors of IDE's geeft aan of iemand handig is, niet of ie kan programmeren. Dat zijn vaardigheden die makkelijk te leren zijn.

[whoami]

Nu, ik had bij het starten van dit topic niet alleen technische vaardigheden enzo in gedachten maar ook eerder persoonlijke/sociale vaardigheden.

Qua overtuigingskracht, communicatie, ed...

[Verwijderd]

Op vrijdag 31 mei 2002 22:16 schreef Kappie het volgende:
Een goede programmeur is iemand die de problemen van een gebruiker kan omzetten in een goed werkend programma.

Meeste programmeurs kunnen dit technisch gezien wel aan. De moeilijkheid met programmeren is het zo dat de gebruiker er goed mee kan omgaan.

De grote vraag is: is het bepalen van hoe het programma door de klant makkelijk is om te gebruiken een taak voor een programmeur? Ik vind van niet. Dat is de taak van een functioneel ontwerper, of misschien in een nog eerder stadium van een consultant.

Natuurlijk kan het zijn dat 1 persoon meerdere rollen heeft binnen een project, maar de rol van functioneel ontwerper is heel anders dan die van een programmeur.

Ik vind bijvoorbeeld ook niet dat een goede functioneel ontwerper een goede programmeur moet zijn, hoewel ik wel vind dat hij de concepten van programmeren moet begrijpen, liefst zelf wat ervaring ermee hebben.

[Verwijderd]

Op zaterdag 01 juni 2002 01:20 schreef Sponz het volgende:
Gelul. Elke programmeur die iets maakt dat werkt snapt z'n code wel.

Dat is pas gelul. Zo ongeveer alle mensen die ik ken (note: ik ben geen professioneel programmeur en programmeren is op de farmacie opleiding slechts als bijvak te doen) die klooien maar wat aan. Ze hebben geen idee waar ze mee bezig zijn, ze schrijven wat code en ze verwachten dat het werkt.

Boven je code staan betekent dat je het design snapt. Dat je dus exact kan dromen, van detail (functie, variabele) tot aan het volledige applicatiedesign, wat het nut daarvan is, wat het doet en waarom het op die manier gaat en niet anders. Dan snap je waar je mee bezig bent - dat maakt een goede programmeur imo.

* Sponz is goed genoeg voor een aardig salaris

Uit ervaring zeg ik dat dat helemaal niks zegt.

[jopiek]

ik ben bij een Software Engineer en geen ordinaire programmeur te zijn
die lui kibbelen mij teveel

[Verwijderd]

Op zaterdag 01 juni 2002 10:29 schreef jopiek het volgende:
ik ben bij een Software Engineer en geen ordinaire programmeur te zijn
die lui kibbelen mij teveel

/me rotflmao ....
Programmeur A: "Ik heb gelijk."
Programmeur B: "Nee, ikkeh!"
Programmeur A: "Nietus, ik weet het beter!"
SoftwareEngineer: "Joh, weetje, geef mij maar een bom met duiten en zeg wat je wil, dan maak ik het wel terwijl zij het uitvechten."

Tja, voor pragmatisme valt ook wel iets te zeggen als een kwaliteir voor een programmeur / software engineer.

[odysseus]

Naar mijn idee - en dan ben ik het denk ik met beelzebubu eens - is de kwaliteit van een programmeur niet af te meten aan zijn kennis van specifieke API's en dergelijke, maar veel meer aan zijn vermogen om een probleem te analyseren, in stukken op te delen en op elk onderdeel een antwoord te vinden op zo'n manier dat al die losse delen het grote probleem oplossen. Op welke manier je het daarna naar echte code vertaalt (welke taal, met welke tools) is dan meer een kwestie van smaak en van omstandigheden.

Zelf programmeer ik het een en ander als hobby, maar heel serieus is dat niet. Dat doe ik graag met XEmacs, al doe ik kleine perl-scripts ook nog wel in vi. KDevelop ken ik ook redelijk (ik ken ook een aantal van de ontwikkelaars ervan) en ook dat werkt niet slecht. Het is naar mijn idee onzinnig om te stellen dat je met een console veel minder zou kunnen doen dan binnen een GUI. Het bouwen van een GUI is logischerwijs wat lastig, maar gewone code schrijven doe ik liever op mijn 132x60 console dan in een editor. De console heeft ook heeft ook dingen als ctags, syntax highlighting en de mogelijkheid om naar definities en documentatie te springen, al zal het dan door op een toets te drukken zijn in plaats van door te klikken. Daarnaast biedt de console het voordeel van de flexibiliteit: je kunt door het aaneenschakelen van een aantal kleine tools veel meer dingen doen dan door het gebruik van een stel functies uit één groot programma. De GUI-variant van 'ls -hdl `find / -name .cpp` | awk '{print $5 $9}' | less' is vast ook wel te bedenken maar kost waarschijnlijk aanmerkelijk meer tijd. Om nog maar niet te beginnen over het gebruik van korte sed-scriptjes die het leven aanzienlijk vergemakkelijken...dergelijke mogelijkheden biedt een grafische omgeving in de meeste gevallen niet. Wel eens geprobeerd om een programma te schrijven en daarna één van je core-classes een andere naam te geven? Zonder een recursieve sed-functie zou ik er niet graag aan beginnen, alleen de gedachte al dat ik alle bestanden handmatig zou moeten gaan wijzigen...en mocht een GUI dat ook kunnen, dan kun je weer een net iets ander probleem verzinnen waar dan weer geen grafisch antwoord op is.

* odysseus merkt op dat KVim en misschien binnenkort ook wel KXEmacs (!) het er wel een stuk beter op zouden kunnen maken, maar de eerste bestaat pas net en de tweede nog helemaal niet, dus daar heb ik nog niet mee kunnen spelen .

[Verwijderd]

Op zondag 02 juni 2002 16:03 schreef odysseus het volgende:
Naar mijn idee - en dan ben ik het denk ik met beelzebubu eens - is de kwaliteit van een programmeur niet af te meten aan zijn kennis van specifieke API's en dergelijke, maar veel meer aan zijn vermogen om een probleem te analyseren, in stukken op te delen en op elk onderdeel een antwoord te vinden op zo'n manier dat al die losse delen het grote probleem oplossen. Op welke manier je het daarna naar echte code vertaalt (welke taal, met welke tools) is dan meer een kwestie van smaak en van omstandigheden.
[...]

Is waar, maar vaak zal blijken dat ervaring met veel gebruikte talen / omgevingen / API's /etc., zoals SQL, XML, LDAP, e.d., je wel tot een beter programmeur maken, omdat je al geleerd hebt wat de valkuilen zijn, etc.

Als je die kennis nog niet hebt, en je moet in een project iets toepassen wat je nog nooit gedaan hebt, kost dat veel meer tijd en is de kwaliteit over het algemeen minder. Daarom is het zeker aan te raden kennis te hebben van veel gebruikte zaken.

[Soultaker]

Waarschuwing! (Deels) off-topic!

Op vrijdag 31 mei 2002 19:20 schreef Otis het volgende:
Abstraheren is afleiden.

Abstraheren is het terugbrengen van een model bestaande uit implementatiespecifieke componenten tot een model bestaande uit algemeen toepasbare componenten en begrippen.

Afleiding is deductie, hoewel ik zelf liever afleiden zeg dan deduceren (waarom moeilijk doen, als de termen equivalent zijn).

Elke goede programmeer begint het ontwerp van zijn applicaties met een abstract model en werkt dat steeds verder uit, totdat er genoeg implementatiedetails bekend zijn om de applicatie te implementeren.

Het voordeel talen die abstracte invoer toestaan, (zoals 4th level languages en declaratieve programmeertalen) is natuurlijk dat de programmeur zich het ontwerp op implementatienivo kan besparen. Dat scheelt tijd en moeite, maar gaat vaak ten koste van de uiteindelijke prestaties van de applicatie. In veel talen van hoog nivo valt code wel te optimaliseren, maar dan is de programmeur natuurlijk weer op een laag nivo bezig.

[Bananenplant]

is bottom-up werken niet de beste manier? dat zegt mijn intuïtie mij. hoewel ik een dbase-applicatie top-down aan het maken ben...

en over gebruik van andermans dingen: wat ga je doen als de programmeur daarvan met pensioen gaat? ik geloof dat ten tijde van y2k er ook een boel stokouwe software doorgespit moest worden waarbij dat het geval was...

trouwens, ik heb wel eens recursief gedroomd

maar als je een procedure van iemand anders pakt waarvan je pre- en post-condities weet lijkt het me niet dat je ineens minder slim bent dan wanneer je die procedure zelf gemaakt had.