C Programlama Dilinin Evrimi

Aşağıdaki yazı benim çok ilgimi çekti paylaşmak isterim sanırım herkes benim gibi bu dilin nasıl ortaya çıktığını merak etmiştir.

C'nin tarihini tartışmaya UNIX'ten bahsedilmeden başlanamaz çünkü işletim sistemi ve sistem üzerinde çalışan programların bir çoğu C'de yazılmıştır.

UNIX'in tarihi New Jersey Murray Hill'deki Bell Laboratuvarlarında imal edilen DEC PDP-7'nin 1969 yılında geliştirilmeye başlanmasıyla ortaya çıkar. UNIX'in bu ilk sürümü tamamen PDP-7 denilen makina dilinde yazılmıştı. UNIX işletim sistemi, programcılara faydalı olsun, kolaylık sağlasın diye ve sistem seviyesinde geliştirme araçları olacak ve göreli olarak açık donanımı bulunacak şekilde oluşturulmuştu.

PDP-7 için UNIX'in geliştirilmesindeki bu hızlandırıcı başarıyı yaratan Ken Thompson, derleyiciler için üretilen yeni dile B adını verdi. Thompson, Bell Laboratuvarlarında sistem programlayıcısıydı. B dilinin ilginç bir gelişimi vardır. Arkasından C gelmiştir. Aslında C dilinin bilinen 4 ayrı atası vardır. Algol68, CPL, BCPL ve B.

Algol68, Avrupa tabanlı bir dildir. 1960'ların başında uluslararası komite tarafından hazırlanmıştır. Algol68, FORTRAN'ın tanıtıldığı yıldan sonra ortaya çıkmıştır. Bu yeni dil, FORTRAN'dan çok daha karmaşıktı ve geleceğin programlama dillerini etkilemiştir. Yaratıcıları, yazılım kurallarının düzenliliği, modüler yapıları ve diğer özellikleri ile bir yüksek seviyeli yapısal bir dilde olması gereken özellikleri bir araya getirmeye özen göstermişlerdi.

Ne yazik ki ALGOL68, ABD'de hiç anlaşılamadı. Bu dilin genelliği ve özü hakkında pek çok şey söylendi. Biraraya getirilmiş programlama dilleri (CPL), bir başka Avrupa kaynaklı programlama diliydi ve Cambridge ile Londra Üniversitelerinde 1963 başlarında birlikte geliştirildi. Dilin evrim aşamaları izlendiğinde CPL, ALGOL68'in çok güzel amaçlarından bilgisayar gerçeklerine geçişini sağlamıştır. Ancak Algol68'in en büyük sorunlarından birisi olan dilin karmaşık olması ve boyutlarındaki esaslar, CPL'de geçmiştir. Bu kısıtlar dili zor ve calışılması güç hale getirmiştir ve çöküşünü açıklamaktadır.

BCPL (temel birleştirilmiş programlama dili) bir önceki sürümü olan CPL'ye cok benziyordu. 1967'lerin ortasında Cambridge'de Martin Richards tarafından geliştirilmiştir. Yine de CPL'nin önerdiklerine bağlı kalınmıştı. BCPL'nin yaratıcıları, CPL'nin temelindeki iyi özellikleri kazanmak istiyorlardı.

B dili 1970'de Ken Thompson tarafından Bell Laboratuvarlarında geliştirilmişti. Thompson, UNIX'in ilk denemelerini B dili ile oluştururken, BCPL dilini de daha fazla basitleştirmeye çalışmaktaydı. Onun başarısı, elindeki donanıma en iyi uyan dili yaratması olmuştur. BCPL ve B, sınırlı problemlere çözüm getirme başarısını göstermiş ancak bu nedenle de sınırlı bir dil olmuş ve yanlızca bazı özel problemlerin çözümünde kullanılabilmiştir. Olayın bu noktasında Thompson DEC PDP-7 makinasında B dilini calıştıramaz bunun yerine DEC PDP-11 denilen makinayı tanıtır. Bu yeni makinada UNIX ve B derleyicisi birarada bulunmaktaydı. Ancak başarıya ulaşma konusunda iki büyük problem vardı.

Yeni DEC PDP-11, atası olan PDP-7'den daha büyüktü. Onun yalnızca 24KB belleği vardı ve sistem 16KB'ını kullanıyordu. 512 KB'lık sabit diski vardı. İlk sorun B dilinde UNIX'ın yazılmasıydı. Ne yazık ki B dili yorumsal yapısı nedeniyle cok yavaştı. Bununla birlikte en büyük problem, B'nin byte düzenlemeli dil olmasıydı; fakat DEC PDP-11, harf düzenlemeliydi. Bütün bu nedenlerden dolayı B dilini başarılı hale getircek çalışmalar 1971 yılında başladı ve buna uygun olarak C dili geliştirildi.

C dili, B ile aynı coğrafi kökenlere sahiptir. 1972 yılında Bell Laboratuvarlarında Dennis Ritchie tarafından geliştirilmiştir. C'deki en büyük gelişmeler Ritchie tarafından sağlanmıştır. Ritchie BCPL ile B dili arasında kaybolan bağları yeniden kurmayı başarmıştır. Veri tiplerini zekice kullanarak güzel bir yapı meydana getirirken CPL'nin orjinal düzenlenmesinde amaçlanan basit hedefleri de korumuştur. C dilinin bu kadar başarılı olmasında en büyük payın Dennis'in deneyim ve uzmanlık dizilerindeki çalışmalarının yansımasından kaynaklanır. C donanıma yakın bağıl düşük seviyeli bir dildir. C programcıya bilgisayarın yeteneklerini en fazla kullanabilmesi için tüm detayları kapsayacak algoritmaları kurma olanağı sağlar.

Kaynak: C/C++ Programcının Rehberi, Chris H. Pappas - William H. Murray, SİSTEM Yayıncılık A.Ş

Görüşler

muhendisce
22 yıl önce

High School/Jr.High 10 PRINT HELLO WORLD 20 END First year in College program Hello(input, output) begin writeln(''Hello World'') end. Senior year in College (defun hello (print (cons ''Hello (list ''World)))) New professional #include void main(void) { char *message[] = {Hello , World}; int i; for(i = 0; i Seasoned professional #include #include class string { private: int size; char *ptr; public: string() : size(0), ptr(new char(''\0'')) {} string(const string &s) : size(s.size) { ptr = new char[size + 1]; strcpy(ptr, s.ptr); } ~string() { delete [] ptr; } friend ostream &operator Master Programmer [ uuid(2573F8F4-CFEE-101A-9A9F-00AA00342820) ] library LHello { // bring in the master library importlib(actimp.tlb); importlib(actexp.tlb); // bring in my interfaces #include pshlo.idl [ uuid(2573F8F5-CFEE-101A-9A9F-00AA00342820) ] cotype THello { interface IHello; interface IPersistFile; }; }; [ exe, uuid(2573F890-CFEE-101A-9A9F-00AA00342820) ] module CHelloLib { // some code related header files importheader(); importheader(); importheader(); importheader(pshlo.h); importheader(shlo.hxx); importheader(mycls.hxx); // needed typelibs importlib(actimp.tlb); importlib(actexp.tlb); importlib(thlo.tlb); [ uuid(2573F891-CFEE-101A-9A9F-00AA00342820), aggregatable ] coclass CHello { cotype THello; }; }; #include ipfix.hxx extern HANDLE hEvent; class CHello : public CHelloBase { public: IPFIX(CLSID_CHello); CHello(IUnknown *pUnk); ~CHello(); HRESULT __stdcall PrintSz(LPWSTR pwszString); private: static int cObjRef; }; #include #include #include #include #include thlo.h #include pshlo.h #include shlo.hxx #include mycls.hxx int CHello::cObjRef = 0; CHello::CHello(IUnknown *pUnk) : CHelloBase(pUnk) { cObjRef++; return; } HRESULT __stdcall CHello::PrintSz(LPWSTR pwszString) { printf(%ws , pwszString); return(ResultFromScode(S_OK)); } CHello::~CHello(void) { // when the object count goes to zero, stop the server cObjRef--; if( cObjRef == 0 ) PulseEvent(hEvent); return; } #include #include #include pshlo.h #include shlo.hxx #include mycls.hxx HANDLE hEvent; int _cdecl main( int argc, char * argv[] ) { ULONG ulRef; DWORD dwRegistration; CHelloCF *pCF = new CHelloCF(); hEvent = CreateEvent(NULL, FALSE, FALSE, NULL); // Initialize the OLE libraries CoInitializeEx(NULL, COINIT_MULTITHREADED); CoRegisterClassObject(CLSID_CHello, pCF, CLSCTX_LOCAL_SERVER, REGCLS_MULTIPLEUSE, &dwRegistration); // wait on an event to stop WaitForSingleObject(hEvent, INFINITE); // revoke and release the class object CoRevokeClassObject(dwRegistration); ulRef = pCF->Release(); // Tell OLE we are going away. CoUninitialize(); return(0); } extern CLSID CLSID_CHello; extern UUID LIBID_CHelloLib; CLSID CLSID_CHello = { /* 2573F891-CFEE-101A-9A9F-00AA00342820 */ 0x2573F891, 0xCFEE, 0x101A, { 0x9A, 0x9F, 0x00, 0xAA, 0x00, 0x34, 0x28, 0x20 } }; UUID LIBID_CHelloLib = { /* 2573F890-CFEE-101A-9A9F-00AA00342820 */ 0x2573F890, 0xCFEE, 0x101A, { 0x9A, 0x9F, 0x00, 0xAA, 0x00, 0x34, 0x28, 0x20 } }; #include #include #include #include #include #include pshlo.h #include shlo.hxx #include clsid.h int _cdecl main( int argc, char * argv[] ) { HRESULT hRslt; IHello *pHello; ULONG ulCnt; IMoniker * pmk; WCHAR wcsT[_MAX_PATH]; WCHAR wcsPath[2 * _MAX_PATH]; // get object path wcsPath[0] = ''\0''; wcsT[0] = ''\0''; if( argc > 1) { mbstowcs(wcsPath, argv[1], strlen(argv[1]) + 1); wcsupr(wcsPath); } else { fprintf(stderr, Object path must be specified ); return(1); } // get print string if(argc > 2) mbstowcs(wcsT, argv[2], strlen(argv[2]) + 1); else wcscpy(wcsT, LHello World); printf(Linking to object %ws , wcsPath); printf(Text String %ws , wcsT); // Initialize the OLE libraries hRslt = CoInitializeEx(NULL, COINIT_MULTITHREADED); if(SUCCEEDED(hRslt)) { hRslt = CreateFileMoniker(wcsPath, &pmk); if(SUCCEEDED(hRslt)) hRslt = BindMoniker(pmk, 0, IID_IHello, (void **)&pHello); if(SUCCEEDED(hRslt)) { // print a string out pHello->PrintSz(wcsT); Sleep(2000); ulCnt = pHello->Release(); } else printf(Failure to connect, status: %lx, hRslt); // Tell OLE we are going away. CoUninitialize(); } return(0); } Apprentice Hacker #!/usr/local/bin/perl $msg=Hello, world. ; if ($#ARGV >= 0) { while(defined($arg=shift(@ARGV))) { $outfilename = $arg; open(FILE, > . $outfilename) || die Can''t write $arg: $! ; print (FILE $msg); close(FILE) || die Can''t close $arg: $! ; } } else { print ($msg); } 1; Experienced Hacker #include #define S Hello, World main(){exit(printf(S) == strlen(S) ? 0 : 1);} Seasoned Hacker % cc -o a.out ~/src/misc/hw/hw.c % a.out Guru Hacker % echo Hello, world. New Manager 10 PRINT HELLO WORLD 20 END Middle Manager mail -s Hello, world. bob@b12 Bob, could you please write me a program that prints Hello, world.? I need it by tomorrow. ^D Senior Manager % zmail jim I need a Hello, world. program by this afternoon. Chief Executive % letter letter: Command not found. % mail To: ^X ^F ^C % help mail help: Command not found. % damn! !: Event unrecognized % logout Anonymous

tongucyumruk
22 yıl önce

Bu kadar kasmanın yerine şu linki verseydin?

Laugh Along With GNU

Görüş belirtmek için giriş yapın...

İlgili Yazılar

Yazılım Mühendisliğinde Çıkmaz Sokak Tarifleri: Anti-Patterns

FZ
21 Mart 2005, 1 dakika okuma süresi

Bilgisayar yazılımları geliştirmekle yıllardır uğraşılmakta. Son yarım yüzyılda ortaya çıkan bu alanda çeşitli paradigmalar (prosedürel, nesne tabanlı, fonksiyonel, vs) ve çeşitli modeller (code reuse, unit testing, component model, extreme programming, design patterns) ortaya atıldı. Daha çok "Özgür Yazılım'' ile birlikte dağıtık geliştirme yöntemleri gündeme geldi. Tasarım, uygulama ve test aşamalarını kapsayan geniş bir açıdan baktığımızda bize önerilen çeşitli "doğru'' geliştirme yöntemleri var.

Diğer her alanda olduğu gibi dengeli ve sağlıklı bir kavrayışa sahip olmak için doğruların yanında "yanlış'' yöntemler hakkında da bilgi sahibi olmak gereklidir. Bu konuda yaşanmış çok tecrübe olmakla birlikte, yazılı olarak birkaç kaynak dışında ciddi bir eksiklik bulunmaktaydı. Bu makale, ağırlıklı olarak yazılım mühendisliği ile ilgili birkaç Internet sitesinden derlenmiş, daha çok özgür yazılım alanını ilgilendiren bu tür çıkmaz yolları tanıtmaktadır. Ortak noktaları:

* Çoğu bir problemi çözmek isterken ortaya çıkar
* İlk bakışta harika bir fikir gibi gözükebilirler
* En çok tasarım aşamasında görülürler
* Sizden çok daha üretken ve başarılı grupları batırmışlardır!

Gürer Özen'in Anti-Patterns çevirisinin devamını burada okuyabilirsiniz.

Matrix ve Felsefe

FZ
31 Ocak 2003, 1 dakika okuma süresi

Sizin de kafanız Keanu Revees gibi Matrix'ten sonra karıştıysa bu kitap kesinlikle sizin için yazılmış. Eğer film kafanızı karıştırmadıysa, hemen bir doktora görünün. Matrix'i henüz seyretmediyseniz, o zaman bu kitabı mutlaka okumalısınız. Böylece bu filmin insanlar için neden o kadar önemli olduğunu bulursunuz.

Tim O'Reilly tarafından yazılan bir açık kitabın hikayesi...

misafir
29 Ekim 2005, 1 dakika okuma süresi

1987 yılında O'Reilly Networks'un kurucularından Tim O'Reilly, Dale Dougherty ile beraber "Unix Text Processing" adlı bir kitap yazarlar. Kitapta vi editörünün kullanımından awk programlama diline, hatta troff macrolarının nasıl yazılacağına kadar pek çok değerli bilgi vardır. Bir süre sonra kitap piyasadan kaldırılır.

Da Vinci Şifresi Deşifre Oldu

malkocoglu_2
9 Ağustos 2004, 1 dakika okuma süresi

Şimdiye kadar bu kitaptaki kadar, "gerçeklere dayandığını" beyan edip gerçeği bu kadar "esneten" az kitap okumuşumdur. Daha başta "açık anahtar şifrelemeyi Da Vinci nin bulduğu" lafı ile uyandım. Google'da "Da Vinci Code mistakes" kelimelerini kullanarak arama yapınca binlerce sonuç geri geldi.

Dil Üstadları ile Araç Ustaları: IDE Ayrımı

FZ
23 Aralık 2004, 1 dakika okuma süresi

Geliştirici dünyası iki kampa ayrılmıştır. Bir kampta dil üstadları vardır, bu yazılımcılar yüksek seviyeli programlamadan -- birinci-sınıf fonksiyonlar, aşamalı programlama, AOP, MOP, kendi kendini sorgulama -- bahsederler. Araç ustaları ise tümleşik geliştirme ve hata ayıklama araçlarında ustadırlar, kod tamamlama, "refactoring", vs. Dil üstadları Emacs ya da VIM kullanır, bu tür editörler yeni dilleri denemek için daha uygundur. Araç ustaları ise Visual Studio, Eclipse, IntelliJ gibi IDE'leri kullanırlar.

Laszlo ve Groovy gibi yeni diller ya da AOP (Aspect Oriented Programming) gibi dil uzantıları genellikle öncelikli olarak metin-editörü tabanlı yazılım geliştirme ortamlarında ortaya çıkarlar ve ancak ondan bir süre sonra IDE dünyası bu tür desteklere kavuşur. Eğer dil ya da uzantı gerçekten başarılı ise araçlar da bunu desteklemeye başlar. Bu ayrımın tek sebebi araç geliştirmenin dil geliştirmekten zor olması değildir. Asıl mesele bir dile hakim olmak ile bir araç setine hakim olmanın çok farklı iki mantalite olmasıdır, belli bir ölçüye dek bunlar birbirlerini dışlayan alternatiflerdir. Acaba neden? İşte sebepleri...

Oliver Steele'nin The IDE Divide başlıklı makalesini tüm yazılım geliştiricilerin okumasında fayda var. (Not: Şöyle sağlam bir FM üyesi çıksa da bahsi geçen makaleyi Türk diline kazandırsa... hani yani küçük bir olasılık olsa da, belki diyorum, belki biri üstlenir, FM'ye bir katkıda bulunur...)