Programmer’s Town

C Compilers

October 19, 2008 · Leave a Comment

There are 34 pages for Pages For Thsi Post.This list may sometimes be slightly out of date.

A

  • Amsterdam Compiler Kit
  • Aztec C
  • BDS C

C

  • Cc65

  • Ccache

  • CodeWarrior

  • Comeau C/C++

D

  • DJGPP

  • Digital Mars

F

  • FpgaC

G

  • GNU Compiler Collection

L

  • LCC (compiler)

  • LabWindows/CVI

  • Lattice C

  • Low Level Virtual Machine

M

  • Macintosh Programmer’s Workshop

  • Megamax C

O

  • Open64

P

  • PGI compiler

  • Pelles C

  • Portable C Compiler

Q

  • QuickC

R

  • Romcc

S

  • Small Device C Compiler

  • Small-C

  • Sun Studio (software)

T

  • THINK C

  • TenDRA Compiler

  • Tiny C Compiler

  • Turbo C

V

  • VBCC

  • Visual C++

W

  • Watcom C compiler

Z

  • Z88DK

Source

→ Leave a CommentCategories: C/C++ · Principle · Programming
Tagged: , ,

Write In C……..

September 16, 2008 · 4 Comments

“For all the  C-Programmers out there. If you heard this song you will never try to use programming languages other than C again^^ I don’t know who wrote the lyrics but I like them”

Lyrics Of This SOng…………………

“Write in C”
And as the deadline fast approaches,
and bugs are all  that i can see
Someone Somewhere whispers:
“Write in C”

Write in C,Write in C
Write in C, Oh, Write in C,
LOGO’s dead and burried,
Write in C!!

i used to write lot of FORTARN
For Science it worked flawlessely

Try Using it for GRAPHICS
Write in C!!

And if you’ve nearly 30 hours
debugging some Assembely

Soon You will glad to
Write in C!!

Write in C,Write in C
Write in C, Oh, Write in C,
BASIC’s not the Answer,
Write in C!!

Write in C,Write in C
Write in C, Oh, Write in C,
PASCLE won’t quite
Write in C!!

→ 4 CommentsCategories: C/C++ · Principle · Programming
Tagged:

Programmer’s Principle

September 16, 2008 · Leave a Comment

Programmer’s Principle Taken from Eric S Raymond’s “The Art of Unix Programming“. These principles are a solid recommendation to any programmer.

  1. Rule of Modularity: Write simple parts connected by clean interfaces.
  2. Rule of Clarity: Clarity is better than cleverness.
  3. Rule of Composition: Design programs to be connected to other programs.
  4. Rule of Separation: Separate policy from mechanism; separate interfaces from engines.
  5. Rule of Simplicity: Design for simplicity; add complexity only where you must.
  6. Rule of Parsimony: Write a big program only when it is clear by demonstration that nothing else will do.
  7. Rule of Transparency: Design for visibility to make inspection and debugging easier.
  8. Rule of Robustness: Robustness is the child of transparency and simplicity.
  9. Rule of Representation: Fold knowledge into data so program logic can be stupid and robust.
  10. Rule of Least Surprise: In interface design, always do the least surprising thing.
  11. Rule of Silence: When a program has nothing surprising to say, it should say nothing.
  12. Rule of Repair: When you must fail, fail noisily and as soon as possible.
  13. Rule of Economy: Programmer time is expensive; conserve it in preference to machine time.
  14. Rule of Generation: Avoid hand-hacking; write programs to write programs when you can.
  15. Rule of Optimization: Prototype before polishing. Get it working before you optimize it.
  16. Rule of Diversity: Distrust all claims for “one true way”.
  17. Rule of Extensibility: Design for the future, because it will be here sooner than you think.

→ Leave a CommentCategories: Principle
Tagged: ,

Who is a programmer?

August 27, 2008 · 2 Comments

After work, the question got asked. It came up in the context of another discussion about the relevance of Free/Open Source Software. Availability of the source code is probably only relevant to computer programmers. After all, if you aren’t a programmer, what would you do with source code? In which case, a freely copyable binary would be equivalent to freely copyable source code. The ability to do something with the source code (i.e. to create a derivative work), is something only a programmer could do. Strikes me as the definition of a programmer. Yes, I know that benefits might accrue to the non-programmer indirectly, but conceding that there are no direct benefits to most people doesn’t seem like a great debating point.

We know that only 2.4% of the population are employed in “computer and mathematical occupations”. Which would seem to put an upper bound on the number of people to whom Free and Open Source Software would be relevant. And any movement which can only possibly be relevant to such a small fraction of the population is going to have difficulty garnering widespread support, or even interest. Assuming, of course, that we restrict ourselves to professional programmers. There might be amateur programmers.

And so, we come to the real questions: who should be a programmer? Who should be considered a programmer? Is the correct analogy that the skill of programming is like the skill of reading and writing? An esoteric skill for most of the world’s history — practiced only by specialists — professional scribes — until, in the last few hundred years, we came to expect that everybody ought to be a scribe, or at least literate. Even if only a relatively small number of people read or write for a living?

Or, is the correct analogy that being a programmer is more like being a radio technician and learning Morse code? An esoteric skill which remains esoteric.

Is it more like being a driver (chauffeur)? Or a pilot?

Because, I fear that if it is the latter, then the Free and Open Source Software has more in common with the national association for Amateur Radio than the National Institute for Literacy.

This idea of universal computer literacy has deep roots. The work that led to the desktop computing environments we use today was motivated by that vision. Alan Kay talks about it at length here.

→ 2 CommentsCategories: Programming
Tagged: , , , , ,