รายการสถานที่ท่องเที่ยวในกรุงบูดาเปสต์ edit

สถานที่ท่องเที่ยวที่น่าสนใจในกรุงบูดาเปสต์โดยแบ่งตามเขตเมือง

 

Sights by list edit

โบสถ์ edit

สะพาน edit

  • สะพานอาร์ปาด (Árpád Bridge ), the busiest bridge (1950)
  • สะพานมอร์กิต (Margit Bridge ), the second oldest bridge (1876)
  • สะพานโซ่เซแชนยี (Széchenyi Chain Bridge ) the oldest and most famous bridge (1849)
  • สะพานแอร์เจแบ็ต (Erzsébet Bridge ) built across the narrowest part of the Danube (1903)
  • สะพานเสรีภาพ (Liberty Bridge ) the third oldest bridge (1896)
  • สะพานแปเตอฟี (Petőfi Bridge ) (1937)
  • สะพานราโคตซี (Rákóczi Bridge ) (1995)
รูปภาพ ชื่อสถานที่ท่องเที่ยว เขต สร้างขึ้นเมื่อ
  รัฐสภาฮังการี (Parliament) V 1885 - 1904
  โบสถ์เซนต์อิชต์วาน (St. Stephen's Basilica) V 1851 – 1906
  พิพิธภัณฑ์สถานแห่งชาติฮังการี (Hungarian National Museum) VIII 1837 – 1847
  โรงละครแห่งชาติฮังการี (National Theatre) IX 2002
  ปราสาทบูดอ (Buda Castle) I
  นิทรรศการภาพวาดแห่งชาติฮังการี (Hungarian National Gallery) I
  โบสถ์แมทเธียส (Matthias Church) I 1015
  ป้อมชาวประมง (Fisherman's Bastion) I 1899 – 1902
  กระเช้าขึ้นเขาปราสาทบูดอ (Castle Hill Funicular) I 1868 - 1870
  คฤหาสน์ชานโดร์ (Sándor Palace) I 1803 – 1805
  ค่ายทหารโรมันอาควินคุม (Aquincum Military Amphitheatre) III AD 89
  สถานบันวิทยาศาสตร์ฮังการี (Hungarian Academy of Sciences) V 1862 - 1865
  อนุสรรองเท้าข้างแม่น้ำดานูบ (Shoes on the Danube Bank memorial) V 2005
  Gresham Palace V 1907
  Tomb of Gül Baba II 1543 - 1548
  ถนนอ็อนดราชชี่ (Andrássy Avenue) VI 18th century
  โรงละครโอเปร่าแห่งรัฐฮังการี (Hungarian State Opera House) VI 1875 - 1884
  พิพิธภัณฑ์บ้านแห่งความน่ากลัว (House of Terror Museum) VI 2002
  สวนสาธารณะประจำเมือง (City Park) XIV 1811
  จตุรัสวีรชน (Heroes' Square) XIV 1896 – 1906
  City Park Lake(ice skating rink in winter) XIV
  ปราสาทว็อยดอฮุนย็อด (Vajdahunyad Castle) XIV 1904 – 1908
  พิพิธภัณฑ์วิจิตรศิลป์ (Museum of Fine Arts) XIV 1906
  Zoo XIV 1865 - 1866
  โรงอาบน้ำเซแชนยี (Széchenyi Medicinal Bath) XIV 1909 - 1913
  โบสถ์ยิวถนนโดฮาญ (Dohány Street Synagogue) VII 1854 - 1859
  Rumbach Street Synagogue VII 1869 - 1872
  Museum of Applied Arts IX 1897
  Erkel Theatre VIII 1911
  Café Gerbeaud V 1897
  ตลาดหลวงบูดาเปสต์ (Great Market Hall) IX 1897
  Liberty Statue XI 1947
  Memento Park XXII 1993
  เกาะมอร์กิต (Margit Island) none
  Aeropark XVIII

Sights by districts edit

เขต สถานที่ท่องเที่ยว
I.Várkerület (เขตปราสาท) Buda Castle, Matthias Church, Hungarian National Gallery, Castle Hill Funicular, Sándor Palace, Fisherman's Bastion, Gellért Hill, Labyrinth of Buda Castle, Vienna Gate
II. Tomb of Gül Baba, Mechwart Park, Cave of Szemlő Hill, Stalactite Cave of Pál Valley, Lukács Bath
III.Óbuda-Békásmegyer (โอบูดอ-เบกาชแมดแยร์) Aquincum Military Amphitheatre, Zichy Castle
IV.Újpest (อูยแป็ชต์) Queen of Heavens Church, Synagogue of Újpest, Water Tower of Újpest
V.Belváros-Lipótváros Parliament, Hungarian Academy of Sciences, Gresham Palace, St. Stephen's Basilica, Vigadó Concert Hall, Ethnographic Museum, Hungarian National Bank, Shoes on the Danube Bank memorial, Károlyi Garden
VI.Terézváros (แตเร็ซวาโรช) Andrássy Avenue, Hungarian State Opera House, House of Terror Museum, St. Theresa of Ávila Church.
VII.Erzsébetváros (แอร์เจแบ็ตวาโรช) Dohány Street Synagogue, Rumbach Street Synagogue, Kazinczy Street Synagogue, St. Elizabeth of Árpád House Church, Reformed Church of Fasor, Madách Theatre, Gozsdu udvar, Franz Liszt Academy of Music, Hungária Bath (today: Continental Hotel Zara), New York Palace (today: Boscolo Budapest Hotel)
VIII.Józsefváros (โยแจ็ฟวาโรช) Hungarian National Museum, Erkel Theatre, Orczy Garden, Botanic Garden, Hungarian Natural History Museum, Metropolitan Ervin Szabó Library
IX.Ferencváros (แฟแร็นซ์วาโรช) National Theatre, Palace of Arts, Kálvin Square Reformed Church, Assisi St. Francis Church, Zwack Unicum Museum, Ráday Street, Holocaust Memorial Center, Museum of Applied Arts, Central Market Hall
X.Kőbánya (เกอบาญอย) Népliget (People's Park), Planetarium, St. László Church, Csősztorony (Keeper Tower)
XI.Újbuda (อูยบูดอ) Gellért Hill, Citadella, Liberty Statue, Budapest University of Technology and Economics St. Gellért Church, Kopaszi Dike
XII.Hegyvidék (แฮ็จวิเดก/เขตภูเขา) Elizabeth Lookout Tower, Normafa
XIII. Comedy Theatre, St. Margaret of Árpád House Church, Our Lady of Mount Carmel Church
XIV.Zugló (ซุกโล่) City Park, Heroes' Square, Zoo, Széchenyi Medicinal Bath, Gundel Restaurant, Vajdahunyad Castle, Petőfi Hall, Museum of Fine Arts, Hall of Art, Transport Museum, Municipal Grand Circus, Petőfi Hall, Ferenc Puskás Stadium
XV. Water Tower
XVI. Mátyásföld Airport,
XVII.Rákosmente (ราโก็ชแม็นแต) Statue of Heroes, Statue of Pope John Paul II, Rákos Stream, Merzse Marsh
XVIII.Pestszentlőrinc-Pestszentimre (แปชต์แซนต์เลอรินซ์-แป็ชต์แซนต์อิมแร) Ferenc Liszt Airport, Sándor Petőfi Statue, Aeropark
XIX.Kispest (กิชแป็ชต์) Our Lady Church of Kispest
XX.Pesterzsébet (แป็ชแตรเจแบ็ต) St. Elizabeth of Árpád House Church, Statue of Lajos Kossuth
XXI.Csepel (แชแปล) Little Our Lady Church, Tamariska Hill
XXII.Budafok-Tétény (บูดอโฟ็ก-เตเตญ) Czuba-Durozier Castle, Nagytétény Castle, Sacelláry Castle, Törley Castle, Törley Mausoleum, Memento Park
XXIII.Soroksár (โชโร็กชาร์) Heroes' Statue, Molnár Island
Margaret Island (เกาะมอร์กิต) Dominicans' Monastery ruins, Francisian Monastery ruins, Premontrean Convent, Water Tower, Japanese Garden, Alfréd Hajós National Swimming Stadium, Palatinus Swimming Pool, Musical Fountain

Navigation menu edit

  • Read
  • Edit source
  • View history
  • Watch

More edit

Contribute edit

Tools edit

Languages edit

* Category:Articles with example pseudocode

ประวัติศาสตร์หลัง ค.ศ.1970 edit

History (post-1970)

Computer chips edit

หลังจากการประดิษฐ์ชิปวงจรรวมแบบโมโนลิทิก (Integrated circuit; IC) ในปี ค.ศ.1959 โดย Robert Noyce ที่ Fairchild และ MOSFET (ทรานซิสเตอร์ MOS) โดย Mohamed Atalla และ Dawon Kahng ที่ Bell Labs[1] Atalla ได้เสนอแนวคิดของวงจรรวม MOS (MOS integrated circuit; MOS IC) เป็นครั้งแรก ในปี ค.ศ.1960[2] จากนั้น MOS IC เชิงพาณิชย์เครื่องแรกได้มีการจัดจำหน่ายโดย General Microelectronics ในปี ค.ศ.1964[3] การพัฒนา MOS IC นำไปสู่การประดิษฐ์ไมโครโปรเซสเซอร์โดยรวมฟังก์ชันของหน่วยประมวลผลกลาง (CPU) ของคอมพิวเตอร์ไว้ในวงจรรวมเดียว . ไมโครโปรเซสเซอร์ชิปเดี่ยวตัวแรกคือ Intel 4004 ซึ่งออกแบบและผลิตโดย Federico Faggin ร่วมกับ Ted Hoff, Masatoshi Shima และ Stanley Mazor ที่ Intel ในปี 1971 ในเดือนเมษายนปี 1974 Intel ได้เปิดตัว Intel 8080 ซึ่งเป็น "คอมพิวเตอร์บนชิป" "ไมโครโปรเซสเซอร์ตัวแรกที่ใช้งานได้จริง"

Following the 1959 inventions of the monolithic (IC) chip by at Fairchild, and the (MOS transistor) by and at Bell Labs, Atalla first proposed the concept of the (MOS IC) chip in 1960, and then the first commercial MOS IC was introduced by in 1964. The development of the MOS IC led to the invention of the microprocessor,[4] incorporating the functions of a computer's central processing unit (CPU) on a single integrated circuit.[5] The first single-chip microprocessor was the Intel 4004,[6] designed and realized by Federico Faggin along with Ted Hoff, Masatoshi Shima and Stanley Mazor at Intel in 1971.[4][7] In April 1974, Intel released the Intel 8080,[8] a "computer on a chip", "the first truly usable microprocessor".

Homebrew Computer Club edit

 
Invitation to first Homebrew Computer Club meeting, 1975.

The Homebrew Computer Club was an informal group of electronic enthusiasts and technically minded hobbyists who gathered to trade parts, circuits, and information pertaining to DIY construction of computing devices.[9] It was started by Gordon French and Fred Moore who met at the Community Computer Center in Menlo Park. They both were interested in maintaining a regular, open forum for people to get together to work on making computers more accessible to everyone.[10]

The first meeting was held as of March 1975 at French's garage in Menlo Park, San Mateo County, California; which was on occasion of the arrival of the MITS Altair microcomputer, the first unit sent to the area for review by People's Computer Company. Steve Wozniak and Steve Jobs credit that first meeting with inspiring them to design the original Apple I and (successor) Apple II computers. As a result, the first preview of the Apple I was given at the Homebrew Computer Club.[11] Subsequent meetings were held at an auditorium at the Stanford Linear Accelerator Center.[12]

Venture capital edit

By the early 1970s, there were many semiconductor companies in the area, computer firms using their devices, and programming and service companies serving both. Industrial space was plentiful and housing was still inexpensive. Growth during this era was fueled by the emergence of venture capital on Sand Hill Road, beginning with Kleiner Perkins and Sequoia Capital in 1972; the availability of venture capital exploded after the successful $1.3 billion IPO of Apple Computer in December 1980. Since the 1980s, Silicon Valley has been home to the largest concentration of venture capital firms in the world.[13]

In 1971 Don Hoefler traced the origins of Silicon Valley firms, including via investments from Fairchild's eight co-founders.[14][15] The key investors in Kleiner Perkins and Sequoia Capital were from the same group, directly leading to Tech Crunch 2014 estimate of 92 public firms of 130 related listed firms then worth over US$2.1 Trillion with over 2,000 firms traced back to them.

การออกเสียง

ตารางต่อไปนี้คือการออกเสียงอักษรฮังการีตามหลักภาษาฮังการีมาตรฐาน

อักษร ชื่อเรียก หน่วยเสียง เสียงที่ใกล้เคียงในภาษาไทย ตัวอย่างเสียงที่ใกล้เคียงในภาษาอื่น การเขียนทับศัพท์ในภาษาไทย หมายเหตุ
A a /ɒ/[[:Media:Open back rounded vowel.ogg|]] (help·info) เอาะ (แบบไม่มีเสียงกัก) ภาษาไทย: ก๊ก, ล็อ

ภาษาอังกฤษ (แบบบริติช): cot

Alma: ออลมอ

Amerika: ออแมริคอ

Margit: มอร์กิต

Dunaújváros: ดูนออูยวาโรช

Buda: บูดอ

Tass:

Szarvas:

Baja:

Á á /aː/[[:Media:Open front unrounded vowel.ogg|]] (help·info) อา ภาษาไทย: าง, ข้

ภาษาอังกฤษ: father

Vár: วาร์ (ปราสาท)

Kádár: คาดาร์

János: ยาโนช

Rákoczi: ราโคตซี

Állomás:อาโลล์มาช

Vác: วาตซ์

Nagyvárad: น็อจวาร็อด

B /b/[[:Media:voiced bilabial plosive.ogg|]] (help·info) ภาษาไทย: บ้าน, บิน, บ่อน

ภาษาอังกฤษ: by, absence

Bécs: เบช

Békéscsaba: เบเกชชอบอ

Baranya: บอรอญอ

Budapest: บูดอแปชต์

Szabadság: ซอบ็อดฉาก

Bonyhád: โบญฮาด

Balaton: บอลอโตน

C /ts/[[:Media:Voiceless_alveolar_sibilant_affricate.oga|]] (help·info) ตซ ภาษาอังกฤษ: pots

ภาษาญี่ปุ่น: 波(なみ、Tsunami)

Debrecen: แดแบรตแซน

Cegléd: แซกเลด

Nyolc: โญลซ์

Kilenc: คิแลนซ์

Cigánd: ซิกานด์

Cipő: ซิเปอ

Harminc: ฮอร์มินซ์

คล้าย ต กับ ซ รวมกันเป็นเสียงเดียว
Cs csé /tʃ/ ภาษาไทย: ช้าง, เชียงใหม่

ภาษาอังกฤษ: check, cheek, etching

Csongrád: โชงกราด

Pécs: เปช

Csík:ชีค

Csaba: ชอบอ

Csemege: แชแมแก

Csípő: ชิเปอ

Csipkebogyó: ชิปแคโบดโย

D /d/[[:Media:Voiced alveolar plosive.ogg|]] (help·info) ภาษาไทย: เด็ก, ดิน, ารา

ภาษาอังกฤษ: deck, wide

Duna: ดูนอ

Diák: ดิอาค

Debrecen: แดแบรตแซน

Doktor: โดคโตร

Dabas: ดอบอช

Dohány: โดฮาญ

Dz dzé /dz/[[:Media:voiced alveolar affricate.ogg|]] (help·info) ดซ (เสียงก้อง) ภาษาอังกฤษ: kids Bodza: โบตซอ เป็นคำที่พบได้น้อยมากในภาษาฮังการี
Dzs dzsé /dʒ/ จ (เสียงก้อง) ภาษาอังกฤษ: jam, George, bridge, edge, fridge Dzsudzsák: จูจาค

Dzsungel: จุงแกล

เป็นคำที่มักพบในคำทับศัพท์จากภาษาต่างประเทศ
E e /ɛ/[[:Media:Open-mid front unrounded vowel.ogg|]] (help·info) แอะ (แบบไม่มีเสียงกัก) ภาษาอังกฤษ: less, cheque, edge, bed Esztergom: แอสแตร์โกม

Eger: แอแกร์

Hely: แฮย

Emlék: แอมเลค

Erzsébet: แอร์เจแบต

Szeged: แซแกด

Szetes: แซนแตช

Kecskemét: แคชแคเมต

É é /eː/[[:Media:Close-mid front unrounded vowel.ogg|]] (help·info) เอ ภาษาอังกฤษ: café Pécs: เปช

Észak:เอสอก

Étterem: เอตแตแรม

Tér: เตร์

Ég: เอก

Szék: เซค

Veszprém: แวสเปรม

F ef /f/[[:Media:voiceless labiodental fricative.ogg|]] (help·info) ภาษาอังกฤษ: find, euphoria Siófok: ชิโอโฟค

Forradalom: โฟร์รอดอโลม

Finnország: ฟินน์โอรสาก

Telefon: แทแลโฟน

Fiú: ฟิอู

G /ɡ/[[:Media:Voiced velar plosive.ogg|]] (help·info) ก (เสียงก้อง) ภาษาอังกฤษ: get, leg, go Gellért: แกลเลร์ต

Gödöllő: เกอเดอเลอ

Kőszeg: เคอแสก

Igar: อิกอร์

Grund: กรุนด์

Gy gyé /ɟ/[[:Media:Voiced palatal plosive.ogg|]] (help·info) ดย คล้ายกับคำภาษาอังกฤษ ที่ใช้เสียง /d/ แบบอ่อน คำว่า duke during Győr: ดเยอร์ / เยอร์ / เจอร์ / จเยอร์

Gyögy: จเยอร์จย์ / เจอร์จ / เยอร์จ / ดเยอร์ดย์

Gyöngyös: เยิงเยิช

Magyar: มอดยอร์ / ม็อดยอร์ / ม็อจยอร์ / มอจยอร์

Hegy: แฮจย์

Gyula: จยูลอ / ยูลอ / ดยูลอ

Hogyan: โฮจยอน / โฮดยอน

Vagyok: วอดโยค / วอจโยค

Nagy: นอจ / นอจย์ / นอดย์

Gyógyszertár: จโยจย์แซร์ตาร์ / โยจย์แซร์ตาร์

ออกเสียงคล้าย จ/ด กับ ย มารวมกัน เป็นเสียงเดียว ดังนั้นเวลาทับศัพท์ อาจจะทับเป็น ย เช่น Győr
H /h/ 1. [ɦ][[:Media:Voiced glottal fricative.ogg|]] (help·info)

2. ∅

3. [x]voiceless velar fricative.ogg (help·info)

4. [ç]voiceless palatal fricative.ogg (help·info)

ฮ 1. ฮ

2. ไม่ออกเสียง

3. ค, ฮ

4. ช, ฮ

ภาษาอังกฤษ: hi

1. behind 2. honest

3. Loch, Chanukah 4. human

Hatvan: ฮอตวอน

Himnusz: ฮิมนุซ

Cséh: เชฮ์

Méh: เมฮ์

Doh: โดค์

Ihlet: อิคแลต

ออกเสียงได้ 4 แบบ ตามแต่ละคำ แต่ส่วนใหญ่ ออกเสียงเหมือน ฮ ในภาษาไทย
I i /i/ อิ (แบบไม่มีเสียงกัก) ภาษาอังกฤษ: sea, key, tree Ipar:

Pitvaros:

Fagyi:

Budapesti:

Keleti:

Bangkoki:

Í í /iː/[[:Media:Close front unrounded vowel.ogg|]] (help·info) อี ภาษาอังกฤษ: leek, leave, seed, sea Ír:

Bíróság:

Kína:

J /j/[[:Media:Palatal approximant.ogg|]] (help·info) ภาษาไทย: ยักษ์, ยี่หร่า, าย

ภาษาอังกฤษ: you, yes, faith

Jézus:

János:

Újbuda:

K /k/[[:Media:Voiceless velar plosive.ogg|]] (help·info) ภาษาไทย: อง, ไก่

ภาษาอังกฤษ: ski, scar, mask

Kecskemét: แคชแคเมต

Kálmán: คาลมาน

Keleti: แคแลติ

Király: คิราย

Kijárat: คิยารอต

Kis: คิช

L el /l/[[:Media:alveolar lateral approximant.ogg|]] (help·info) ภาษาอังกฤษ: leave, list Ló: โล

Liget: ลิเกต

Lengyel: แลนดแยล

Lisszabon: ลิซซอโบน

Ly elly, el-ipszilon /j/[[:Media:Palatal approximant.ogg|]] (help·info)

/ /ʎ/Palatal approximant.ogg (help·info)

ภาษาอังกฤษ: play, pray Lyuk: ยุค

Király: คิราย

Szombathely: โซมบอตแฮย

Bagoly: บอโกย

Kodály: คอดาย

ในปัจจุบัน ly ออกเสียงเหมือน j หรือ ย ตามภาษาฮังการีมาตรฐานเนื่องจากการเปลี่ยนไปของสำเนียงการพูดภาษาฮังการี
M em /m/[[:Media:bilabial nasal.ogg|]] (help·info) ภาษาอังกฤษ: mind, assume, might Magyar: มอดยอร์

Metró: แมโตร

Műegyetem: มือแอดแยแตม

Mester: แมชแตร์

N en /n/: [ŋ][[:Media:velar nasal.ogg|]] (help·info)

[n]alveolar nasal.ogg (help·info)

ง (เมื่อนำหน้า k, g)

ภาษาอังกฤษ: thing, lying (ก่อนตัว k, g),need, bone (ที่อื่น ๆ) Nemzeti: แนมแซติ

Nógrád: โนกราด

Sopron: โชโปรน

ออกเสียงเหมือน ง เมื่อนำหน้า k, g แต่ออกเสียงเหมือน น เมื่อนำหน้าเสียงพยัญชนะอื่นทั้งหมด
Ny eny /ɲ/[[:Media:palatal nasal.ogg|]] (help·info) ญ, นย ภาษาอังกฤษ: canyon

ภาษาสเปน: niño

Nyíregyháza:ญีแร็จฮาซอ

Dohány:โดฮาญ

Nyelv: แญล็ฟ

Nyak:ญอค

Nyugta: ญุกตอ

ออกเสียงเหมือน ญ ในภาษาไทยโบราณ ภาษาไทยถิ่นเหนือ และภาษาไทยถิ่นอีสาน
O o /o/ โอะ (แบบไม่มีเสียงกัก) ภาษาอังกฤษ: force, sorcerer
Ó ó /oː/[[:Media:Close-mid back rounded vowel.ogg|]] (help·info) โอ Óra: โอรอ

Tó: โต

Szórend: โซแรนด์

Tótkomlós: โตตโกมโลช

Ö ö /ø/[[:Media:Close-mid front rounded vowel.ogg|]] (help·info) เออะ (แบบไม่มีเสียงกัก) ตัว ö ในภาษาเยอรมัน Örökség: เออเริคเชก

Gödöllő: เกอเดอเลอ

Központ: เคอโปนต์

Szöveg: เซอแวก

Ön: เอิน

Ő ő /øː/ เออ คล้ายตัว ö ในภาษาเยอรมัน แต่เสียงยาว Ő: เออ
P /p/[[:Media:Voiceless bilabial plosive.ogg|]] (help·info) ภาษาไทย: า, ระเทศ Pest: แปชต์

Pillis: ปิลลิช

(Q) ออกเสียงเหมือน k พบในคำทับศัพท์เท่านั้น
R er /r/[[:Media:alveolar trill.ogg|]] (help·info) ภาษาไทย: เรียน, รู้ ร เรือ แบบรัวลิ้น ในภาษาไทยมาตรฐาน และเหมือนกับเสียงของ rr ในภาษาสเปน
S es /ʃ/[[:Media:Voiceless_palato-alveolar_sibilant.ogg|]] (help·info) ช (เสียง ภาษาอังกฤษ: share, wish, shout การเขียนโดยใช้ s เป็นเสียง /ʃ/ และ sz เป็นเสียง /ʃ/ เป็นสิ่งที่พบได้น้อยมาก ในระบบการเขียนของยุโรป มีเพียงภาษาฮังการีที่เขียนแบบนี้
Sz esz /s/[[:Media:Voiceless_alveolar_sibilant.ogg|]] (help·info) ภาษาอังกฤษ: say, estimate
T /t/[[:Media:voiceless alveolar plosive.ogg|]] (help·info) ภาษาอังกฤษ: star, least, feast
Ty tyé /c/[[:Media:Voiceless palatal plosive.ogg|]] (help·info) ภาษาอังกฤษ: tube คล้าย ต กับ ย รวมกันเป็นเสียงเดียว
U u /u/ ภาษาอังกฤษ: rude
Ú ú /uː/[[:Media:Close back rounded vowel.ogg|]] (help·info) อู ภาษาอังกฤษ: do, fool
Ü ü /y/ อึ (แบบไม่มีเสียงกัก) ตัว ü ในภาษาเยอรมัน
Ű ű /yː/[[:Media:Close front rounded vowel.ogg|]] (help·info) อือ ตัว ü ในภาษาเยอรมัน แต่เสียงยาว Űrhajó: อือร์ฮอโย
V /v/[[:Media:voiced labiodental fricative.ogg|]] (help·info) ฟ, ว ภาษาอังกฤษ: very, every Visegrád: วิแชกราด

Vörös: เวอเริช

Viktor: วิกโตร์

Nyelv: แญลฟ์

(W) dupla vé /v/[[:Media:voiced labiodental fricative.ogg|]] (help·info) ฟ, ว ภาษาอังกฤษ: view, evolve, vacuum ออกเสียงเหมือน v พบในคำทับศัพท์เท่านั้น
(X) iksz กซ ออกเสียงเหมือน k + sz พบในคำทับศัพท์เท่านั้น
(Y) ipszilon /i/ อิ (แบบไม่มีเสียงกัก) ภาษาอังกฤษ: happy ออกเสียงเหมือน i พบในคำทับศัพท์เท่านั้น
Z /z/[[:Media:Voiced_alveolar_sibilant.ogg|]] (help·info) ซ (เสียงก้อง) ภาษาอังกฤษ: desert, roses
Zs zsé /ʒ/[[:Media:Voiced_palato-alveolar_sibilant.ogg|]] (help·info) ช (เสียงก้อง) ภาษาอังกฤษ: pleasure, leisure Zsinagóga: จินอโกกอ

ตัวอักษร ë ไม่ได้เป็นส่วนหนึ่งของชุดตัวอักษรฮังการี อย่างไรก็ตาม นักภาษาศาสตร์ใช้ตัวอักษรนี้เพื่อจำแนกความต่างระหว่างเสียง e สั้น สองชนิด (แอะ และ เอะ) ในบางภาษาถิ่นของภาษาฮังการี มีการใช้อักษรนี้ครั้งแรกในปี ค.ศ. 1770 โดยเยิดย์ ก็อลมาร์ (György Kalmár) แต่อักษรนี้ไม่เคยเป็นส่วนหนึ่งของชุดตัวอักษรฮังการีมาตรฐาน เนื่องจากในภาษาฮังการีมาตรฐานไม่ได้จำแนกความต่างระหว่างเสียงทั้งสองนี้ (อย่างที่ในภาษาไทยแยกเสียง แอะ และ เอะ ออกจากกัน) อย่างไรก็ตาม เสียง ë (เอะ) ออกเสียงต่างจากเสียง e (แอะ) ในภาษาถิ่นของภาษาฮังการี 6 ภาษาจาก 10 ภาษา และออกเสียงอย่าง ö (เออะ) ในภาษาถิ่นของภาษาฮังการี 1 ภาษา (ภาษาถิ่นทรานซิลเวเนีย)

ทวิอักษร ch ยังปรากฏอยู่ในบางคำ (เช่น [technika] error: {{lang}}: text has italic markup (help), [monarchia] error: {{lang}}: text has italic markup (help)) และออกเสียงเหมือนกับ h ส่วนในวิสามานยนาม ch จะออกเสียงเหมือน cs หรือบางครั้งออกเสียงเป็น h หรือ k (แบบภาษาเยอรมัน)

การเขียนแบบเดิม ที่ยังใช้ในชื่อเฉพาะและเอกสารทางประวัติศาสตร์ edit

การเขียนแบบดั้งเดิม (บางส่วนมีความใกล้เคียงกับการเขียนแบบเยอรมัน) มีการใช้ในชื่อเฉพาะที่เป็นภาษาฮังการี โดยตารางด้านล่างจะเปรียบเทียบการเขียนแบบดั้งเดิม กับการอ่านออกเสียงแบบปัจจุบัน ตามการสะกดของภาษาฮังการีมาตรฐาน ดังนี้:

การเขียนแบบดั้งเดิม การอ่านออกเสียงตามหลักสมัยใหม่
พยัญชนะ
bb b
cz c
tz c
z c
ch cs
cz cs
č cs
ć cs
ts cs
csh cs
tsch cs
tzsch cs
chs cs
cy cs
ʟ cs
dd d
dsz dz
ds dzs
ff f
ph f
gh g
dgy ggy
dy gy
g gy
gi gy
gj gy
gʹ~g′ gy
ǵ gy
ġ gy
j gy
jj j
l j
y j
ck k
kh k
x ks
xy ksz
xz ksz
qu kv
ll l
l ll
w lv
j ly
l ly
li ly
ry ly
lly ly
′l(ʹl)~l′(lʹ)~ŀ ly
n ny
ni ny
nʹ~n′ ny
ń ny
ny
my ny
ph p
pp p
rh r
rr r
r
sch s
ss s
ss ssz
s sz
sc sz
sy sz
z sz
th t
tt t
ti ty
tʹ~t′ ty
ty
ky ty
u v
w v
s z
s zs
ss zs
zy zs
['s] zs

[1]

การเขียนแบบดั้งเดิม การอ่านตามหลักสมัยใหม่
สระ
a á
aa á
á
áh á
ä e
ae e
ai e
ay e
áe é
ái é
áy é
e é
ee é
é
éh é
i í
í
íh í
ii í
í
å o
o ó
óh ó
oo ó
ó
ua ó
â ö
åe ö
åi ö
åy ö
ö
ew ö
oe ö
oi ö
oy ö
ő
ő
ew ő
ia ő
ö ő
őh ő
öö ő
öő ő
óe ő
ói ő
óy ő
üa ő
u ú
úh ú
ú
uu ú
ú
ue ü
ui ü
uy ü
ü ű
űh ű
üő ű
üü ű
üű ű
úe ű
úi ű
úy ű
aj
aj
aÿ aj
ei aj
áë áj
áï áj
áÿ áj
åë oj
åï oj
åÿ oj
eu oj
oj
oj
oÿ oj
óë ój
óï ój
óÿ ój
au uj
uj
uj
uÿ uj
úë új
úï új
úÿ új
(g)y ~ gÿ gi
y ji
ý
(l)y ~ lÿ (l)i
(n)y ~ nÿ (ny)i or (n)i
(t)y ~ tÿ ti

โดยทั่วไปแล้ว ตัว y ในการเขียนแบบดั้งเดิมนั้น มักจะอ่านเป็น i ในการอ่านแบบปัจจุบัน (ตย..: Teleky, Rákóczy, zsy). ด้านล่างนี้คือตัวอย่างการอ่านด้วยหลักปัจจุบัน ที่มักจะมีการอ่านผิด เนื่องจากการสะกดที่ใช้หลักต่างจากปัจจุบัน มักพบในชื่อนามสกุล

ตัวอย่าง:

ชื่อ การอ่านตามหลักสมัยใหม่
Madách Madács
Széchenyi Szécsényi หรือSzécsenyi
Batthyány Battyányi
Gajdátsy Gajdácsi
Thököly Tököli
Weöres Vörös
Eötvös Ötvös
Kassay Kassai
Debrődy Debrődi
Karczagy Karcagi
Vörösmarty Vörösmarti
Cházár Császár
Czukor Cukor
Balogh Balog
Vargha Varga
Paal Pál
Gaál Gál
Veér Vér
Rédey Rédei
Soós Sós
Thewrewk rök
Dessewffy Dezsőfi

บทความนี้มีจุดประสงค์หลักในการแยกความเหมือนและความแตกต่างของกระบวนทัศน์การเขียนโปรแกรม (programming paradigms) ต่าง ๆ as a summary in both graphical and tabular format with links to the separate discussions concerning these similarities and differences in extant Wikipedia articles.

กระบวนทัศน์การเขียนโปรแกรม edit

การเขียนโปรแกรมมีกระบวนทัศน์วิธีการเขียนโปรแกรมหลัก ๆ อยู่ 2 แบบ:

  • การเขียนโปรแกรมแบบอิมพาราทีฟ (Imperative programming) – โฟกัส focuses on how to execute, defines control flow as statements that change a program state.
  • การเขียนโปรแกรมแบบดีแคลราทีฟ (Declarative programming – โฟกัส focuses on what to execute, defines program logic, but not detailed control flow.

The following are widely considered the main programming paradigms, as seen when measuring programming language popularity:

The following are common types of programming that can be implemented using different paradigms:

The subroutines that implement OOP methods may be ultimately coded in an imperative, functional, or procedural style that may, or may not, directly alter state on behalf of the invoking program. There is some overlap between paradigms, inevitably, but the main features or identifiable differences are summarized in this table:

กระบวนทัศน์

(Paradigm)

คำอธิบาย ลักษณะเด่น กระบวนทัศน์ที่เกี่ยวข้อง นักวิจารณ์(Critique) ตัวอย่างภาษาที่ใช้
อิมพาราทีฟImperative Programs as statements that directly change computed state (datafields) Direct assignments, common data structures, global variables Edsger W. Dijkstra, Michael A. Jackson C, C++, Java, Kotlin, PHP, Python, Ruby, Wolfram Language
สตรัคเจอร์ด

Structured

A style of imperative programming with more logical program structure Structograms, indentation, no or limited use of goto statements Imperative C, C++, Java, Kotlin, Pascal, PHP, Python, Wolfram Language
โปรซีเจอรัล

Procedural

Derived from structured programming, based on the concept of modular programming or the procedure call Local variables, sequence, selection, iteration, and modularization Structured, imperative C, C++, Lisp, PHP, Python, Wolfram Language
ฟังกชั่นนัล

Functional

Treats computation as the evaluation of mathematical functions avoiding state and mutable data Lambda calculus, compositionality, formula, recursion, referential transparency, no side effects Declarative C++,[16] C#,[17] Clojure, Coffeescript,[18] Elixir, Erlang, F#, Haskell, Java (since version 8), Kotlin, Lisp, Python, R,[19] Ruby, Scala, SequenceL, Standard ML, JavaScript, Elm, Wolfram Language
Event-driven including time-driven Control flow is determined mainly by events, such as mouse clicks or interrupts including timer Main loop, event handlers, asynchronous processes Procedural, dataflow JavaScript, ActionScript, Visual Basic, Elm
ออบเจค-โอเรียนเต็ด

Object-oriented

Treats datafields as objects manipulated through predefined methods only Objects, methods, message passing, information hiding, data abstraction, encapsulation, polymorphism, inheritance, serialization-marshalling Procedural Wikipedia, และอื่น ๆ[20] Common Lisp, C++, C#, Eiffel, Java, Kotlin, PHP, Python, Ruby, Scala, JavaScript[21][22]
ดีแคลราทีฟ

Declarative

Defines program logic, but not detailed control flow Fourth-generation languages, spreadsheets, report program generators SQL, regular expressions, Prolog, OWL, SPARQL, XSLT
การเขียนโปรแกรมแบบออโตมาต้า-เบส

Automata-based programming

Treats programs as a model of a finite state machine or any other formal automata State enumeration, control variable, state changes, isomorphism, state transition table Imperative, event-driven Abstract State Machine Language

ความแตกต่างในนิรุกศาสตร์ edit

Despite multiple (types of) programming paradigms existing in parallel (with sometimes apparently conflicting definitions), many of the underlying fundamental components remain more or less the same (constants, variables, datafields, subroutines, calls etc.) and must somehow thus inevitably be incorporated into each separate paradigm with equally similar attributes or functions. The table above is not intended as a guide to precise similarities, but more of an index of where to look for more information, based on the different naming of these entities, within each paradigm. Further complicating matters are non-standardized implementations of each paradigm, in many programming languages, especially languages supporting multiple paradigms, each with its own jargon.

ภาษาที่สนับสนุน edit

Syntactic sugar is the sweetening of program functionality by introducing language features that facilitate a given usage, even if the end result could be achieved without them. One example of syntactic sugar may arguably be the classes used in object-oriented programming languages. The imperative language C can support object-oriented programming via its facilities of function pointers, type casting, and structures. However, languages such as C++ aim to make object-oriented programming more convenient by introducing syntax specific to this coding style. Moreover, the specialized syntax works to emphasize the object-oriented approach. Similarly, functions and looping syntax in C (and other procedural and structured programming languages) could be considered syntactic sugar. Assembly language can support procedural or structured programming via its facilities for modifying register values and branching execution depending on program state. However, languages such as C introduced syntax specific to these coding styles to make procedural and structured programming more convenient. Features of the language C# (C Sharp), such as properties and interfaces, similarly enable no new functions, but are designed to make good programming practices more prominent and natural.

Some programmers feel that these features are unimportant or even frivolous. For example, Alan Perlis once quipped, in a reference to bracket-delimited languages, that "syntactic sugar causes cancer of the semicolon" (see Epigrams on Programming).

An extension of this is the syntactic saccharin, or gratuitous syntax that does not make programming easier.[23]

เปรียบเทียบประสิทธิภาพการทำงาน edit

In total instruction path length only, a program coded in an imperative style, using no subroutines, would have the lowest count. However, the binary size of such a program may be larger than the same program coded using subroutines (as in functional and procedural programming) and would reference more non-local physical instructions that may increase cache misses and instruction fetch overhead in modern processors.

The paradigms that use subroutines extensively (including functional, procedural, and object-oriented) and do not also use significant inline expansion (inlining, via compiler optimizations) will, consequently, use a larger fraction of total resources on the subroutine linkages. Object-oriented programs that do not deliberately alter program state directly, instead using mutator methods (or setters) to encapsulate these state changes, will, as a direct consequence, have more overhead. This is because message passing is essentially a subroutine call, but with three added overheads: dynamic memory allocation, parameter copying, and dynamic dispatch. Obtaining memory from the heap and copying parameters for message passing may involve significant resources that far exceed those needed for the state change. Accessors (or getters) that merely return the values of private member variables also depend on similar message passing subroutines, instead of using a more direct assignment (or comparison), adding to total path length.

Managed code edit

For programs executing in a managed code environment, such as the .NET Framework, many issues affect performance that are significantly affected by the programming language paradigm and various language features used.[24]

Pseudocode examples comparing various paradigms edit

A pseudocode comparison of imperative, procedural, and object oriented approaches used to calculate the area of a circle (πr²), assuming no subroutine inlining, no macro preprocessors, register arithmetic, and weighting each instruction 'step' as only 1 instruction – as a crude measure of instruction path length – is presented below. The instruction step that is conceptually performing the state change is highlighted in bold typeface in each case. The arithmetic operations used to compute the area of the circle are the same in all three paradigms, with the difference being that the procedural and object-oriented paradigms wrap those operations in a subroutine call that makes the computation general and reusable. The same effect could be achieved in a purely imperative program using a macro preprocessor at only the cost of increased program size (only at each macro invocation site) without a corresponding pro rata runtime cost (proportional to n invocations – that may be situated within an inner loop for instance). Conversely, subroutine inlining by a compiler could reduce procedural programs to something similar in size to the purely imperative code. However, for object-oriented programs, even with inlining, messages still must be built (from copies of the arguments) for processing by the object-oriented methods. The overhead of calls, virtual or otherwise, is not dominated by the control flow alteration – but by the surrounding calling convention costs, like prologue and epilogue code, stack setup and argument passing[25] (see here[26] for more realistic instruction path length, stack and other costs associated with calls on an x86 platform). See also here[27] for a slide presentation by Eric S. Roberts ("The Allocation of Memory to Variables", chapter 7)[28] – illustrating the use of stack and heap memory use when summing three rational numbers in the Java object-oriented language.

Imperative Procedural Object-oriented
 load r;                      1
 r2 = r * r;                  2
 result = r2 * "3.142";       3
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.... storage .............
result variable
constant "3.142"
area proc(r2,res):
   push stack                                 5
   load r2;                                   6
   r3 = r2 * r2;                              7
   res = r3 * "3.142";                        8
   pop stack                                  9
   return;                                   10
...............................................
main proc:
   load r;                                    1
   call area(r,result);
    +load p = address of parameter list;      2
    +load v = address of subroutine 'area';   3
    +goto v with return;                      4
.
.
.
.
.... storage .............
result variable
constant "3.142"
parameter list variable
function pointer (==>area)
stack storage
circle.area method(r2):
   push stack                                 7
   load r2;                                   8
   r3 = r2 * r2;                              9
   res = r3 * "3.142";                       10
   pop stack                                 11
   return(res);                           12,13
...............................................
main proc:
   load r;                                    1
   result = circle.area(r);
      +allocate heap storage;                 2[See 1]
      +copy r to message;                     3
      +load p = address of message;           4
      +load v = addr. of method 'circle.area' 5
      +goto v with return;                    6
.
.
.... storage .............
result variable (assumed pre-allocated)
immutable variable "3.142" (final)
(heap) message variable for circle method call
vtable(==>area)
stack storage

The advantages of procedural abstraction and object-oriented-style polymorphism are poorly illustrated by a small example like the one above. This example is designed mainly to illustrate some intrinsic performance differences, not abstraction or code re-use.

Subroutine, method call overhead edit

The presence of a (called) subroutine in a program contributes nothing extra to the functionality of the program regardless of paradigm, but may contribute greatly to the structuring and generality of the program, making it much easier to write, modify, and extend.[29] The extent to which different paradigms use subroutines (and their consequent memory requirements) influences the overall performance of the complete algorithm, although as Guy Steele pointed out in a 1977 paper, a well-designed programming language implementation can have very low overheads for procedural abstraction (but laments, in most implementations, that they seldom achieve this in practice - being "rather thoughtless or careless in this regard"). In the same paper, Steele also makes a considered case for automata-based programming (using procedure calls with tail recursion) and concludes that "we should have a healthy respect for procedure calls" (because they are powerful) but suggested "use them sparingly"[29]

In the frequency of subroutine calls:

  • For procedural programming, the granularity of the code is largely determined by the number of discrete procedures or modules.
  • For functional programming, frequent calls to library subroutines are common,[citation needed] but may be often inlined by the optimizing compiler
  • For object-oriented programming, the number of method calls invoked is also partly determined by the granularity of the data structures and may thus include many read-only accesses to low level objects that are encapsulated, and thus accessible in no other, more direct, way. Since increased granularity is a prerequisite for greater code reuse, the tendency is toward fine-grained data structures, and a corresponding increase in the number of discrete objects (and their methods) and, consequently, subroutine calls. The creation of god objects is actively discouraged. Constructors also add to the count as they are also subroutine calls (unless they are inlined). Performance problems caused by excessive granularity may not become apparent until scalability becomes an issue.
  • For other paradigms, where a mix of the above paradigms may be employed, subroutine use is less predictable.

Allocation of dynamic memory for message and object storage edit

Uniquely, the object-oriented paradigm involves dynamic memory allocation from heap storage for both object creation and message passing. A 1994 benchmark - "Memory Allocation Costs in Large C and C++ Programs" conducted by Digital Equipment Corporation on a variety of software, using an instruction-level profiling tool, measured how many instructions were required per dynamic storage allocation. The results showed that the lowest absolute number of instructions executed averaged around 50 but others reached as high as 611.[30] See also "Heap:Pleasures and pains" by Murali R. Krishnan[31] that states "Heap implementations tend to stay general for all platforms, and hence have heavy overhead". The 1996 IBM paper "Scalability of Dynamic Storage Allocation Algorithms" by Arun Iyengar of IBM [32] demonstrates various dynamic storage algorithms and their respective instruction counts. Even the recommended MFLF I algorithm (H.S. Stone, RC 9674) shows instruction counts in a range between 200 and 400. The above pseudocode example does not include a realistic estimate of this memory allocation pathlength or the memory prefix overheads involved and the subsequent associated garbage collection overheads. Suggesting strongly that heap allocation is a nontrivial task, one open-source software microallocator, by game developer John W. Ratcliff, consists of nearly 1,000 lines of code.[33]

Dynamically dispatched message calls v. direct procedure call overheads edit

In their Abstract "Optimization of Object-Oriented Programs Using Static Class Hierarchy Analysis",[34] Jeffrey Dean, David Grove, and Craig Chambers of the Department of Computer Science and Engineering, at the University of Washington, claim that "Heavy use of inheritance and dynamically-bound messages is likely to make code more extensible and reusable, but it also imposes a significant performance overhead, relative to an equivalent but non-extensible program written in a non-object-oriented manner. In some domains, such as structured graphics packages, the performance cost of the extra flexibility provided by using a heavily object-oriented style is acceptable. However, in other domains, such as basic data structure libraries, numerical computing packages, rendering libraries, and trace-driven simulation frameworks, the cost of message passing can be too great, forcing the programmer to avoid object-oriented programming in the “hot spots” of their application."

Serializing objects edit

Serialization imposes large overheads when passing objects from one system to another, especially when the transfer is in human-readable formats such as Extensible Markup Language (XML) and JavaScript Object Notation (JSON). This contrasts with compact binary formats for non-object-oriented data. Both encoding and decoding of the objects data value and its attributes are involved in the serializing process, which also includes awareness of complex issues such as inheriting, encapsulating, and data hiding.

การเขียนโปรแกรมแบบพาราเลล edit

Carnegie-Mellon University Professor Robert Harper in March 2011 wrote: "This semester Dan Licata and I are co-teaching a new course on functional programming for first-year prospective CS majors... Object-oriented programming is eliminated entirely from the introductory curriculum, because it is both anti-modular and anti-parallel by its very nature, and hence unsuitable for a modern CS curriculum. A proposed new course on object-oriented design methodology will be offered at the sophomore level for those students who wish to study this topic."[35]

ดูเพิ่มเติม edit

อ้างอิง edit

  1. ^ "1960: Metal Oxide Semiconductor (MOS) Transistor Demonstrated". The Silicon Engine. Computer History Museum. Archived from the original on February 20, 2020. Retrieved August 31, 2019.
  2. ^ Moskowitz, Sanford L. (2016). Advanced Materials Innovation: Managing Global Technology in the 21st century. John Wiley & Sons. pp. 165–167. ISBN 9780470508923. Archived from the original on December 17, 2019. Retrieved August 21, 2019.
  3. ^ "1964 – First Commercial MOS IC Introduced". Computer History Museum. Archived from the original on December 22, 2015. Retrieved July 31, 2019.
  4. ^ a b "1971: Microprocessor Integrates CPU Function onto a Single Chip". Computer History Museum. Archived from the original on October 30, 2019. Retrieved July 22, 2019.
  5. ^ Osborne, Adam (1980). An Introduction to Microcomputers. Vol. Volume 1: Basic Concepts (2nd ed.). Berkeley, California: Osborne-McGraw Hill. ISBN 978-0-931988-34-9. Archived from the original on October 27, 2019. Retrieved August 6, 2019. {{cite book}}: |volume= has extra text (help)
  6. ^ Intel's First Microprocessor—the Intel 4004, Intel Corp., November 1971, archived from the original on May 13, 2008, retrieved May 17, 2008
  7. ^ Federico Faggin, The Making of the First Microprocessor Archived October 27, 2019, at the Wayback Machine, IEEE Solid-State Circuits Magazine, Winter 2009, IEEE Xplore
  8. ^ Intel (April 15, 1974). "From CPU to software, the 8080 Microcomputer is here". Electronic News. New York: Fairchild Publications. pp. 44–45. Electronic News was a weekly trade newspaper. The same advertisement appeared in the May 2, 1974 issue of Electronics magazine.
  9. ^ "Homebrew And How The Apple Came To Be". atariarchives.org. Archived from the original on April 7, 2015. Retrieved April 19, 2015.
  10. ^ Markoff, John (2006) [2005]. What the Dormouse Said: How the Sixties Counterculture Shaped the Personal Computer Industry. Penguin Books. ISBN 978-0-14-303676-0. Archived from the original on September 5, 2015. Retrieved March 25, 2015.
  11. ^ Wozniak, Steve (2006). iWoz. W.W. Norton & Company. p. 150. ISBN 978-0-393-33043-4. After my first meeting, I started designing the computer that would later be known as the Apple I. It was that inspiring.
  12. ^ Freiberger, Paul; Swaine, Michael (2000) [1984]. Fire in the Valley: The Making of the Personal Computer. McGraw-Hill. ISBN 978-0-07-135895-8.
  13. ^ Scott, W. Richard; Lara, Bernardo; Biag, Manuelito; Ris, Ethan; Liang, Judy (2017). "The Regional Economy of the San Francisco Bay Area". In Scott, W. Richard; Kirst, Michael W. (eds.). Higher Education and Silicon Valley: Connected But Conflicted. Baltimore: Johns Hopkins University Press. p. 65. ISBN 9781421423081. Retrieved August 11, 2019.
  14. ^ Laws, David (January 7, 2015). "Who named Silicon Valley?". Computer History Museum. Archived from the original on October 16, 2018. Retrieved October 16, 2018.
  15. ^ A Legal Bridge Spanning 100 Years: From the Gold Mines of El Dorado to the "Golden" Startups of Silicon Valley Archived June 1, 2013, at the Wayback Machine by Gregory Gromov
  16. ^ "Archived copy" (PDF). Archived from the original (PDF) on 2017-02-02. Retrieved 2015-12-18.{{cite web}}: CS1 maint: archived copy as title (link)
  17. ^ "Functional programming C#". August 2020. Retrieved 2015-08-14.
  18. ^ Ruiz, Cedric (May 2014). "Functional CoffeeScript for the impatient". Blog de Cedric Ruiz. Cedric Ruiz. Retrieved 2015-08-09.
  19. ^ http://adv-r.had.co.nz/Functional-programming.html
  20. ^ [1]
  21. ^ Crockford, Douglas. "JavaScript: The World's Most Misunderstood Programming Language". crockford.com.
  22. ^ Crockford, Douglas. "Private Members in JavaScript". crockford.com.
  23. ^ "The Jargon File v4.4.7: "syntactic sugar"".
  24. ^ Gray, Jan (June 2003). "Writing Faster Managed Code: Know What Things Cost". MSDN. Microsoft.
  25. ^ "The True Cost of Calls". wordpress.com. 2008-12-30.
  26. ^ http://en.wikibooks.org/wiki/X86_Disassembly/Functions_and_Stack_Frames
  27. ^ Roberts, Eric S. (2008). "Art and Science of Java; Chapter 7: Objects and Memory". Stanford University. Archived from the original on 2011-06-06. Retrieved 2010-05-17.
  28. ^ Roberts, Eric S. (2008). Art and Science of Java. Addison-Wesley. ISBN 978-0-321-48612-7. Archived from the original on 2011-06-06. Retrieved 2010-05-17.
  29. ^ a b Guy Lewis Steele, Jr. "Debunking the 'Expensive Procedure Call' Myth, or, Procedure Call Implementations Considered Harmful, or, Lambda: The Ultimate GOTO". MIT AI Lab. AI Lab Memo AIM-443. October 1977. [2] Archived 2009-12-29 at the Wayback Machine[3][4]
  30. ^ Detlefs, David; Dosser, Al; Zorn, Benjamin (June 1994). "Memory Allocation Costs in Large C and C++ Programs; Page 532". Software—Practice and Experience. 24 (6): 527–542. CiteSeerX 10.1.1.30.3073. doi:10.1002/spe.4380240602. S2CID 14214110.
  31. ^ Krishnan, Murali R. (February 1999). "Heap: Pleasures and pains". microsoft.com.
  32. ^ "Scalability of Dynamic Storage Allocation Algorithms" (Document). {{cite document}}: Cite document requires |publisher= (help); Unknown parameter |citeseerx= ignored (help)
  33. ^ "MicroAllocator.h". Google Code. Retrieved 2012-01-29.
  34. ^ Dean, Jeffrey; Grove, David; Chambers, Craig (1995). "Optimization of Object-Oriented Programs Using Static Class Hierarchy Analysis". Object-Oriented Programming. Lecture Notes in Computer Science. Vol. 952. University of Washington. pp. 77–101. CiteSeerX 10.1.1.117.2420. doi:10.1007/3-540-49538-X_5. ISBN 978-3-540-60160-9.
  35. ^ Teaching FP to Freshmen, from Harper's blog about teaching introductory computer science.[5]

Cite error: A list-defined reference with the name "flaws" has been invoked, but is not defined in the <references> tag (see the help page).
Cite error: A list-defined reference with the name "executioniKoN" has been invoked, but is not defined in the <references> tag (see the help page).

บทความเพิ่มเติม edit

ลิงก์ภายนอก edit