Real Programmers - the more things change the more the stay the same.

I've known people like this. [LOL]

http://www.pbm.com/~lindahl/real.programmers.html

Jeff
[small][purple]It's never too early to begin preparing for [/purple]International Talk Like a Pirate Day
"The software I buy sucks, The software I write sucks. It's time to give up and have a beer..." - Me[/small]

 

[fredericofonseca]

Rofl. haven't seen that one in awhile.

Regards

Frederico Fonseca
SysSoft Integrated Ltd

http://www.syssoft-int.com

FAQ219-2884
FAQ181-2886

 

[gbaughma]

Yeah... that brings back memories.

Of course, one of my favorites:

http://www.anvari.org/fun/Computer/101_Things_You_Do_Not_Want_Your_System_Administrator_to_Say.html

Just my 2¢

"What the captain doesn't realize is that we've secretly replaced his Dilithium Crystals with new Folger's Crystals."

--Greg

http://parallel.tzo.com

 

[lionelhill]

Unfair to Pascal. Pascal offers some real creative possibilities. I'm referring of course to classics like Borland Turbo Pascal up to about 6.0 (i.e. DOS, before everything went silly)
(1) you can define a variable as one type but type-cast it to another every time you use it.
(2) you can just reserve great chunks of memory, point at it with a pointer, and cast your pointer to point to anything you like. Of course there's absolutely no reason why the pointer should remain pointing at the region of memory you reserved.
(3) it has a built-in assembler, which means you can do all the normal cute things, like call obscure BIOS interrupts, or write self-modifying graphics code in the middle of an otherwise innocent unit.
(4) you can do all sorts of lovely things like define a text constant in a Pascal unit, and, knowing that it is the first thing in that unit's code segment, fill it with code and call it in an assembler procedure by pushing zero and executing a near ret.
(5) you can even define procedures as called by interrupts, but much more fun is just defining them as a normal assembler procedure, and ending them like an interrupt anyway, and then pointing an interrupt vector at them. Then they can run at any moment in your code, even when the ds register doesn't point to the data-segment. So if they need data, you have to store it somewhere in your current code segment.
(6) and don't make me feel guilty about all this. Pascal encourages it. Just look at the numerical coprocessor emulation: an interrupt which overwrites its own call with coprocessor instructions if one is present, but otherwise does the maths. Niiiice.

I gather someone stuck object orientated programming in TP5, but I think they only did it to add interest, not to make life simpler. Anyway, one can always ignore it.

 

[lionelhill]

(7) oh and I forgot one of the best! The built-in assembler is 16-bit, but you can add prefix-bytes for 32-bit as db's, and then use the 16-bit instruction that ought to work. So you can
db 066h; mov ax, 05678h; dw 01234h
to put a 32-bit dword into eax. Don't blame me if I've got the prefix byte wrong. It's a long time since I did it.

 

[Glenn9999]

Speaking of Pascal and things like what was linked to in the original post, Brian W. Kernighan's "Why Pascal Is Not My Favorite Programming Language" seems to perpetually get kicked around even to this day by the C zealots. Of course the issue with that one was time (being written in 1981), but also how poorly researched and ultimately how manufactured some of his "criticisms". Pair that with how little effort he placed into trying to overcome his perceived "deficiencies" with Pascal, placed next to the (some) super-human efforts he went to to overcome deficiencies he perceived in other languages, it becomes very questionable that Kernighan had bias on it.

This paper has problems with it in every way today (including being wholly inaccurate as of Turbo Pascal 6.0), but it still gets kicked around as "holy unquestioned writ". It's amazing too how many (modern) resources cite this paper. Funny how these kind of things go.

(I can't think I ever posted it, but I wrote a rebuttal one time. It's a rather easy computer-science project idea if one is ever in need of an idea)

It is not possible for anyone to acknowledge truth when their salary depends on them not doing it.

 

[MasterRacker]

Real programmers, of course, tend to like UNIX. The rest of us tend to like The UNIX Haters Handbook. ;-)

Jeff
[small][purple]It's never too early to begin preparing for [/purple]International Talk Like a Pirate Day
"The software I buy sucks, The software I write sucks. It's time to give up and have a beer..." - Me[/small]

 

[lionelhill]

On a serious note, Glenn, as a hobbyist and lightweight work-orientated programmer, my only genuine frustration with Pascal was the fact that array lengths had to be defined on declaration before knowing how big the array needed to be. But even this was hardly a problem. I used routinely to define a few types like "BArray = array[0..9999] of byte", reserve the right amount of memory at runtime, and then type-cast the contents to a BArray as necessary.

A good C programmer who I knew at the time said (slightly facetiously) he couldn't see a lot of difference; if you just translated "{" into "begin" and "}" into "end" it all became clear! My personal view was that (1) C was better for poor typists as you can get more done with less characters; (2) but both were system-near, expandable languages available in a wide range of dialects, and that if either had never been invented, probably the world wouldn't have been significantly different; we'd just have used the other.

It's certainly true that both offer(ed) a huge range of possibilities for writing incomprehensible code and including subtle memory leaks and other bugs. Nowadays I don't stray further than vba so I don't count myself worthy to tie a real programmer's shoelaces together.