Sapir-Whorf แบบผกผันกับภาษาการเขียนโปรแกรม

 (lukeplant.me.uk)
1 คะแนน โดย GN⁺ 2 시간 전 | 1 ความคิดเห็น | แชร์ทาง WhatsApp
  • Inverse Sapir-Whorf มุ่งสนใจไม่ใช่ว่าภาษาทำให้คิดอะไรได้ยาก แต่คือมันทำให้ ไม่พูด อะไรได้ยาก และบังคับให้เปิดเผยข้อมูลแบบใด
  • กาลปัจจุบันในภาษาอังกฤษ, สรรพนามแบ่งเพศ, คำนามแบ่งเพศในภาษาฝรั่งเศส, และอดีตกาล mış ของภาษาตุรกี ผลักให้ผู้พูดต้องบอกข้อมูลอย่างความชั่วคราว เพศ แหล่งที่มาของข้อมูล หรือความน่าเชื่อถือ
  • ในภาษาการเขียนโปรแกรมเองก็มักบังคับให้โค้ดต้องรวมประเด็นที่นักพัฒนาอาจไม่ได้สนใจ เช่น ลำดับการคำนวณ, ความเป็น async, การจัดสรรและคืนหน่วยความจำ, สโคป, และชนิดข้อมูล
  • async ใน Python หรือ Javascript, การจัดการหน่วยความจำใน C, lifetime ใน Rust, และการระบุชนิดข้อมูลในภาษาที่มี static type ต่างบังคับให้ต้องระบุทางเลือก ขณะที่ Haskell สามารถปล่อยบางทางเลือกให้ภาษาเป็นผู้ตัดสินได้ผ่าน non-strict semantics และการวิเคราะห์ strictness
  • ภาษาการเขียนโปรแกรมที่เข้าถึงง่ายกว่าอาจมี กำแพง Inverse Sapir-Whorf ที่ต่ำกว่า คือบังคับให้น้อยลงในการพูดถึงเรื่องที่ผู้ใช้ยังไม่เข้าใจหรือยังไม่มีความเห็น

ความหมายของ Inverse Sapir-Whorf

  • สมมติฐาน Sapir-Whorf หากสรุปอย่างง่ายคือแนวคิดที่ว่าภาษาที่เราใช้ส่งผลต่อความคิด
  • รูปแบบที่แรงของ Sapir-Whorf โดยเฉพาะ ภาษากำหนดความคิด ที่มองว่าภาษาควบคุมความคิด หรือจำเป็นต้องมีภาษาบางภาษาเพื่อจะคิดบางอย่าง ทุกวันนี้ไม่ได้รับการยอมรับอย่างจริงจังอย่างกว้างขวางในภาษาศาสตร์
  • การที่ภาษาหนึ่งไม่มี tense ทางไวยากรณ์ ไม่ได้ทำให้สรุปได้ว่าผู้พูดภาษานั้นคิดเรื่องเวลาได้จำกัดกว่า เพราะยังมีวิธีอื่นในการแสดงเวลาเสมอ
  • มีหลักฐานพอสมควรว่าภาษาพูดอาจส่งผลต่อการรับรู้ ทักษะ หรือท่าทีในบางด้าน แต่โดยทั่วไปพิสูจน์ผลกระทบโดยตรงขนาดใหญ่ได้ยาก
  • Inverse Sapir-Whorf ไม่ได้มองว่าภาษาทำให้พูดหรือคิดอะไรได้ยาก แต่สนใจว่าภาษาทำให้ ไม่พูด อะไรได้ยากแค่ไหน
  • ในมุมนี้ ประเด็นสำคัญคือภาษาผลักให้ต้องพูดข้อมูลบางอย่าง หรือทำให้หลีกเลี่ยงความคิดบางอย่างได้ยากเพียงใด

การบังคับที่ปรากฏในภาษาธรรมชาติ

  • ความชั่วคราวและความถาวรในกาลปัจจุบันของภาษาอังกฤษ

    • “I’m living in London” และ “I live in London” ต่างก็หมายถึงอาศัยอยู่ในลอนดอน แต่ประโยคแรกเปิดเผยข้อมูลว่าสภาวะนั้นเป็น ชั่วคราว
    • ผู้ที่ไม่ใช่เจ้าของภาษาอาจไม่สังเกตความต่างนี้ และแม้แต่เจ้าของภาษาเองก็อาจรับรู้เพียงในระดับไม่รู้ตัว
    • ความหมายแบบ “ชั่วคราว” นี้อาจเกี่ยวข้องกับความชอบที่มีต่อลอนดอนมากกว่าระยะเวลาที่อาศัยอยู่จริง
    • ในภาษาอังกฤษต้องเลือก tense และเพราะมักเลือกอย่างไม่รู้ตัว ภาษาจึงทำให้ต้องเปิดเผยข้อมูลอย่างระยะเวลาการอยู่อาศัยหรือความรู้สึก

  • สรรพนามและคำนามแบ่งเพศในภาษาอังกฤษ·ตุรกี·ฝรั่งเศส

    • ในการพูดทั่วไปของภาษาอังกฤษ เมื่อกล่าวถึงบุคคลใดบุคคลหนึ่งก็มักต้องใช้ “he” หรือ “she”
    • แม้จะมี “singular they” อยู่ แต่เมื่อพูดถึงบุคคลเฉพาะที่รู้หรือคาดเดาเพศได้ การใช้แบบนั้นมักไม่เป็นธรรมชาติมาก
    • ภาษาตุรกีใช้เพียง “o” ตัวเดียวสำหรับ he/she/it และการไม่มีสรรพนามแบ่งเพศแบบนี้ก็ไม่ได้ขัดขวางการคิดหรือพูดเรื่องเพศของคน
    • จุดนี้จึงสนับสนุน Sapir-Whorf แบบทั่วไปได้ยาก แต่ Inverse Sapir-Whorf เห็นได้ชัดตรงที่สรรพนามภาษาอังกฤษผลักให้ต้องบอกเพศไม่ว่าจะอยากหรือไม่ก็ตาม
    • แม้ตอนพยายามเล่าถึงคนรู้จักแบบไม่เปิดเผยตัวตน หากเผลอใช้ “him” หรือ “her” ก็อาจเผยเพศและทำให้ระบุตัวได้ง่ายขึ้น
    • ในภาษาฝรั่งเศส คำนามมีเพศ และเมื่อแปล “my friend” ต้องเลือกระหว่าง “mon ami” กับ “mon amie” หรือ “mon copain” กับ “ma copine” ทำให้ต้องเปิดเผยข้อมูล
    • สรรพนามแสดงความเป็นเจ้าของก็มีการแบ่งเพศทั้งในอังกฤษและฝรั่งเศส แต่ his/her ของอังกฤษชี้เพศของเจ้าของ ขณะที่ son/sa ของฝรั่งเศสชี้เพศของสิ่งที่ถูกครอบครอง จึงเปิดเผยข้อมูลคนละแบบ

  • อดีตกาล “mış” ของภาษาตุรกี

    • หากสรุปอย่างง่าย ภาษาตุรกีมีอดีตกาลหลักสองแบบ: แบบทั่วไปที่คล้าย simple past ของอังกฤษ และรูปแบบ “mış”
    • รูป “mış” มีหน้าที่หลายอย่าง และเมื่อใช้เล่าเหตุการณ์ในอดีต มักสื่อว่าข้อมูลนั้น ได้ยินต่อมา หรือมีความน่าเชื่อถือต่ำกว่า
    • เมื่อตอบคำถามว่า “Fred ไปทำงานวันจันทร์หรือไม่?” หากเห็นด้วยตนเองจะใช้รูปอดีตทั่วไป “geldi” แต่ถ้าได้ยินมา จะใช้ “gelmiş”
    • ในภาษาอังกฤษสามารถเล่าโดยใช้เพียง simple past โดยไม่ระบุแหล่งที่มาหรือความน่าเชื่อถือของข้อมูล แต่ในภาษาตุรกีบางสถานการณ์บังคับให้รวมระดับความมั่นใจหรือการเห็นกับตาไว้ด้วย
    • เพราะมีรูป “mış” อยู่แล้ว รูปอดีตทั่วไปจึงไม่ใช่ตัวเลือกที่เป็นกลาง และเมื่อไม่มีตัวเลือกใดเหมาะกว่าอีกตัว การใช้ก็จะฟังไม่เป็นธรรมชาติ
    • เนื่องจากปัจจัยต่อท้าย “mış” ในภาษาตุรกีมักอยู่ท้ายคำสุดท้ายของประโยค จึงอาจเกิดนิสัยที่เมื่อพูดประโยคอังกฤษจบแล้วค่อยนึกออกว่ายังไม่ได้ใส่เครื่องหมายว่า “นี่เป็นข้อมูลที่ได้ยินมา ไม่ได้เห็นเอง” แล้วจึงอยากเติม “mış” ต่อท้าย
    • ภาษาอังกฤษเองก็แสดงความหมายแบบเดียวกันได้ง่ายด้วยคำอย่าง “apparently” แต่ภาษาอังกฤษ ไม่ได้บังคับ ให้ระบุ ขณะที่ภาษาตุรกีบังคับมากพอสมควร

  • การบังคับของภาษาที่เจ้าของภาษามักมองไม่เห็น

    • ความแตกต่างเหล่านี้มักสังเกตได้ยาก จนกว่าจะไปเรียนภาษาอื่นหรือพยายามสอนภาษาของตนให้ชาวต่างชาติ
    • ในช่วงเวลาส่วนใหญ่ที่ต้องเลือกระหว่าง simple present กับ present continuous เราไม่ได้คิดอย่างมีสติว่าการเลือกนั้นสื่ออะไร
    • เมื่อภาษาบังคับบางรูปแบบ มันไม่ได้ปรากฏเป็นการ “ใส่” บางอย่างเสมอไป แต่บางครั้งความหมายก็ถูกตรึงไว้ผ่าน การละไว้ ได้เช่นกัน
    • “I love cake” หมายถึงเค้กโดยทั่วไป ส่วน “I love the cake” หมายถึงเค้กชิ้นหรือก้อนที่เฉพาะเจาะจง
    • ในประโยคแรก การไม่มี “the” ทำให้ชัดว่าเป็นการพูดถึงเค้กโดยรวม และถ้าจะหมายถึงเค้กเฉพาะ ก็จำเป็นต้องใส่เครื่องหมายอย่าง “the” หรือ “this”
    • ภาษาอื่นบางภาษาอาจไม่มีรูปที่สอดคล้องโดยตรงกับความแตกต่างนี้

Inverse Sapir-Whorf ในภาษาการเขียนโปรแกรม

  • สำหรับภาษาการเขียนโปรแกรม Sapir-Whorf แบบทั่วไปอาจใช้ได้มากกว่า
  • ในภาษาอย่าง Python หรือ Haskell การพูดเรื่องการจัดสรรหน่วยความจำทำได้ยาก แต่ไม่ถึงกับเป็นไปไม่ได้
  • ข้อจำกัดของภาษาการเขียนโปรแกรมมักถูกอธิบายผ่านสิ่งที่แสดงออกได้ยากในภาษานั้น
  • บทความ Sapir-Whorf does not apply to Programming Languages ของ Hillel Wayne พูดถึงประเด็นนี้อย่างละเอียดกว่า
  • แต่ในมุมของ Inverse Sapir-Whorf ประเด็นสำคัญคือภาษาการเขียนโปรแกรมบังคับให้ต้องพูดถึงเรื่องที่จริง ๆ แล้วเราไม่ได้สนใจด้วยหรือไม่
  • การจะเห็นแรงบังคับนี้ได้ง่าย มักต้องมี มุมมองแบบผู้เรียนภาษาต่างประเทศ ที่เกิดจากการเรียนหลายภาษา

ตัวอย่างสำคัญในภาษาการเขียนโปรแกรม

  • ลำดับการคำนวณ

    • ภาษาส่วนใหญ่บังคับให้แสดง ลำดับ ที่การคำนวณจะถูกดำเนินการ
    • x = some_func(y + 1, z + 2) ใน Python บอกว่าต้องคำนวณ y + 1 ก่อน จากนั้นคำนวณ z + 2 แล้วจึงส่งทั้งสองค่าเป็นอาร์กิวเมนต์ให้ some_func
    • แม้อาจไม่ได้ใส่ใจลำดับนี้ แต่ใน Python ไม่มีวิธีเขียนการคำนวณข้างต้นโดยไม่กำหนดลำดับไปพร้อมกัน
    • ภาษาส่วนใหญ่ก็คล้ายกัน แต่บางภาษาลำดับการประเมินผลอาจซับซ้อนมาก
    • นิพจน์ที่เทียบเท่ากันใน Haskell อย่าง some_func (y + 1) (z + 2) ไม่ได้กำหนดลำดับการประเมินผลเลย เพราะ non-strict semantics
    • คุณสมบัตินี้ทำให้เทคนิคอย่าง Tying the knot ซึ่งอ้างถึงค่าที่ยังไม่ได้ประกาศนิยาม เป็นไปได้

  • สีของฟังก์ชัน async

    • สีของฟังก์ชัน async เป็นตัวอย่างที่ดี
    • ในภาษาอย่าง Javascript หรือ Python ที่มีคีย์เวิร์ด async แบบชัดเจน เราจำเป็นต้องบอกว่าโค้ดนั้น synchronous หรือ asynchronous
    • ในฟังก์ชัน synchronous เราแสดงออกผ่านการละคีย์เวิร์ด async ไว้ แต่ก็ยังเท่ากับต้องเลือกหนึ่งในสองทางอยู่ดี
    • ไม่มีวิธีเขียนโค้ดที่ยังคงวางตัวเป็นกลางกับประเด็นนี้ได้

  • การจัดสรรและคืนหน่วยความจำ

    • ภาษาส่วนใหญ่ที่ไม่มี garbage collection) จะบังคับให้ต้องพูดถึงการจัดสรรและคืนหน่วยความจำ
    • ในภาษาอย่าง C มักต้องจัดการเรื่องนี้อย่างค่อนข้างชัดเจน หรือไม่ก็ใช้การจัดสรรบนสแตกแบบแฝง แต่ไม่ว่าแบบไหนก็ต้องเลือก
    • ในภาษาอื่น ปัญหานี้อาจถูกซ่อนไว้มากขึ้น แต่ไม่ได้หายไป
    • ใน Rust ปัญหานี้เปลี่ยนรูปไปเป็นการพูดถึง lifetime หรือการนับอ้างอิงแบบ explicit
    • ตัวเลือกแบบ “ฉันไม่สนว่าเมมโมรีนี้ถูกจัดสรรและคืนเมื่อไร ช่วยจัดการให้เอง” ไม่มีให้จริง ๆ
    • การไม่พูดถึงการจัดสรรหน่วยความจำก็มีต้นทุนเช่นกัน
    • ภาษาลักษณะนั้นแทบจะแน่นอนว่าต้องวางค่าจำนวนมากไว้บนฮีป และต้องพึ่ง runtime garbage collector
    • ข้อแลกเปลี่ยนคือภาษาจะมีอิสระในการตัดสินใจมากขึ้น และ Haskell ก็มักใช้ การวิเคราะห์ strictness ในการเลือกเช่นนี้

  • สโคป

    • ภาษาสมัยใหม่ที่รู้จักกันทั้งหมดทำให้ต้องคิดเรื่อง สโคป
    • หลายกรณีสโคปถูกแสดงผ่านตำแหน่งการวางตัวแปรทางกายภาพ และหากต้องการพฤติกรรมอื่นก็ต้องใช้ไวยากรณ์เพิ่มเติมอย่าง global หรือ nonlocal ของ Python
    • หากไม่อยากคิดเรื่องสโคปเลย ก็มีแนวโน้มว่าต้องถอยลงไปใช้ assembly และยอมรับ address space แบบ global เดียว

  • ชนิดข้อมูล

    • ภาษาที่มี static type มักบังคับให้ต้องคิดและพูดถึง ชนิดข้อมูล ของตัวแปรทุกตัว
    • type inference ช่วยลดภาระนี้ได้ คล้ายผู้ฟังที่ฉลาดขึ้นและเข้าใจสิ่งต่าง ๆ จากบริบทได้มากขึ้น แต่บทสนทนานั้นก็ยังคงอยู่
    • แม้ภาษาที่เป็น dynamic type ล้วน ๆ ก็ยังให้พูดเรื่องชนิดข้อมูลได้ผ่านสิ่งอย่างการตรวจ isinstance ของ Python แต่จะไม่เป็นธรรมชาติกว่าและต่างออกไปในเชิงเทคนิค
    • เสน่ห์อย่างหนึ่งของ ภาษาแบบ gradual typing คือมันช่วยหลีกเลี่ยงปัญหา Inverse Sapir-Whorf ได้จริง โดยให้อิสระว่าจะพูดหรือไม่พูดเรื่องชนิดข้อมูลตามความต้องการ
    • อย่างไรก็ตาม ยังไม่แน่ชัดว่ามันทำงานได้ดีเพียงใดในทางปฏิบัติ เพราะธรรมเนียมของ codebase เดิมและ linter ที่ใช้มักกดดันไปทางใดทางหนึ่งอยู่เสมอ

ภาษาที่เข้าถึงง่ายและกำแพงที่ต่ำกว่า

  • คุณลักษณะหลายอย่างของภาษาการเขียนโปรแกรมที่ “เข้าถึงง่าย” หรือ “อ่านง่าย” สามารถวิเคราะห์ผ่านมุมมอง Inverse Sapir-Whorf ได้
  • ภาษาเหล่านี้อาจมี กำแพง Inverse Sapir-Whorf ที่ต่ำกว่า คือไม่บังคับให้ต้องพูดถึงสิ่งที่ยังไม่มีมุมมองหรือยังไม่เข้าใจ
  • หัวข้อที่ภาษาการเขียนโปรแกรมบังคับให้พูดถึง สามารถส่งผลต่อการรับรู้และการเลือกใช้ภาษานั้นได้

บทความที่เกี่ยวข้อง

1 ความคิดเห็น

 
GN⁺ 2 시간 전
ความคิดเห็นจาก Lobste.rs

  • การออกแบบภาษา ไม่ว่าจะเป็นภาษาโปรแกรมหรือภาษาธรรมชาติ อาจมองได้ว่าเป็นการกำหนดว่า ผู้ใช้ควรให้ความสนใจกับอะไร ผ่านการเลือกว่าจะใส่องค์ประกอบใดไว้ในภาษา
    C บอกโดยนัยว่า “จงใส่ใจกับการจัดการหน่วยความจำ” ส่วน Haskell บอกว่า “จงใส่ใจกับชนิดข้อมูลที่ตัวแปรและนิพจน์สามารถบรรจุได้”
    ถ้าภาษาพาเราไปในทิศทางที่เราอยากโฟกัสจริง ๆ มันก็จะให้ความรู้สึกเหมือนเป็นเครื่องมือที่เหมาะกับงานนั้น แต่ถ้าไม่ ก็เหมือนพยายามฟังคนที่พูดเบา ๆ ในงานค็อกเทลปาร์ตี้ ขณะที่อีกคนตะโกนอยู่คนละฝั่งของห้อง
    ความสนใจคือทรัพยากรที่มีค่าที่สุด จึงควรตระหนักว่าเครื่องมือชี้นำและหล่อหลอมมันอย่างไร

    • แนวคิดที่ว่า “ภาษาจำกัดสิ่งที่พูดไม่ได้” อาจเรียกได้ว่าเป็นอะไรทำนอง ความไม่เป็นกลางของการแสดงออก
      ในภาษาอังกฤษ การระบุหรือไม่ระบุ “the” ไม่ได้เป็นกลางต่อความเฉพาะเจาะจงของสิ่งที่พูดถึง และในภาษาตุรกี การใช้หรือไม่ใช้ miş ก็ไม่ได้เป็นกลางต่อการที่ข้อมูลนั้นได้มาจากการรับรู้โดยตรงหรือได้ยินต่อ ๆ กันมา
      นี่อาจมองได้ว่าเป็นด้านกลับของสมมติฐาน Sapir-Whorf แบบมาตรฐานที่ว่า “ภาษาจำกัดสิ่งที่พูดได้” หรือก็คือ ความเป็นกลางของการแสดงออก
      ถ้าอย่างนั้นก็อธิบายได้ว่าภาษาเป็นกลางหรือไม่เป็นกลางต่อหัวข้อใดหัวข้อหนึ่งอย่างไร และในฐานะผู้ออกแบบภาษา เราก็ปรับได้ว่าจะทำให้ความสนใจของผู้ใช้กระจายตัวหรือถูกรวมศูนย์มากขึ้น เช่น garbage collection ทำให้การแสดงออกเกี่ยวกับ heap allocation เป็นกลางมากขึ้น ส่วน effect tracking ทำให้การแสดงออกเกี่ยวกับผลข้างเคียงและอินพุต/เอาต์พุตไม่เป็นกลาง

  • ไม่แน่ใจว่าผมจับประเด็นหลักของบทความได้ครบไหม แต่ทำให้นึกถึงสิ่งที่ผมคิดวนอยู่กับ Rust มานาน
    Rust อยู่ในตำแหน่งแปลก ๆ ตรงที่มันเปิดให้จัดการกับ reference ได้ แต่ก็มีกฎเข้มงวดเพื่อรับประกัน memory safety
    ถ้าเป็น C++ พอคิดว่าสิ่งนี้ควรเป็น reference ก็แค่ทำให้มันเป็น reference แล้วหวังว่าจะไม่มีปัญหา ส่วนถ้าเป็น Python คุณไม่มีอำนาจควบคุมแบบนั้น ก็เลยคัดลอกข้อมูลอย่างไม่ลังเล
    แต่ใน Rust คุณอาจตกลงไปใน หลุมพรางของการ optimize แบบ “การคัดลอกไม่มีประสิทธิภาพ งั้นใช้ reference ดีกว่า” แล้วพอ borrow checker โวยขึ้นมา คุณก็ต้องรีแฟกเตอร์โค้ดอยู่เป็นชั่วโมงทั้งที่มั่นใจว่า reference นี้ปลอดภัย
    โปรแกรมเมอร์ Rust ที่เก่ง ๆ มักจะบอกว่า “ก็ใช้ .clone, RC, Box อะไรพวกนั้นไปสิ” ซึ่งผมก็เห็นด้วย แต่ความจริงที่ว่า reference มันวางอยู่ตรงหน้าและดูเหมือนน่าจะใช้ได้อย่างปลอดภัยก็ยังคงอยู่
    เลยยังเหลือความรู้สึกประหลาดว่าผมตัดสินใจทำมันให้แย่ลงเพื่อเอาใจ borrow checker และก็เข้าใจได้ว่าทำไมถึงมีคนยอมแพ้แล้วสรุปว่า “borrow checker นี่เกินไปสำหรับฉัน”

    • อันนี้แตะกับสิ่งที่บทความพยายามพูดค่อนข้างมากเลย Rust ทำให้คุณ ต้องคิดและต้องตัดสินใจ เรื่องที่ภาษาอื่นไม่บังคับ และด้วยเหตุนั้นทั้งภาระและพลังของการใช้ภาษานี้ก็เพิ่มขึ้นพร้อมกัน

  • เป็นหัวข้อที่ดี และก็ดีใจที่มีพูดถึงไวยากรณ์ภาษาตุรกีนิดหน่อย
    อีกตัวอย่างที่พบบ่อยคือ บางภาษาสามารถละรายละเอียดอย่าง ความเป็นพหูพจน์ ได้ ซึ่งภาษาเวียดนามก็เป็นแบบนั้น
    พอเห็นคำว่า “exaggerated” มีลิงก์ ก็คิดว่า “หรือจะเป็นบทความเกี่ยวกับ Arrival?” แล้วก็ใช่จริง ๆ ซึ่งก็สนุกดี
    เป็นหนังที่หลายคนชอบ แต่ส่วนตัวผมรู้สึกแขวนความไม่เชื่อได้ยาก เพราะมันอ้างว่าเป็นวิทยาศาสตร์ แต่ “วิทยาศาสตร์” นั้นกลับให้ความรู้สึกเหมือนภาษาศาสตร์แบบเวทมนตร์มากกว่า

    • ผมคิดว่า ความเป็นพหูพจน์ นี่แหละคือจุดที่ APL, Pandas และ SQL พยายามเอามาคลุม
      ภาษาโปรแกรมสำหรับแอปพลิเคชันส่วนใหญ่ยึดค่าหนึ่งค่าเป็นฐานแบบอะตอม คุณสร้าง list หรือ map ทับขึ้นไปได้ แต่สุดท้ายสิ่งเหล่านี้ก็ยังเป็นวัตถุเดี่ยวชนิดหนึ่ง และบ่อยครั้งก็เข้ากันได้อย่างละเอียดอ่อนไม่ค่อยดี
      ใน Rust คุณเลยต้องคัดลอกข้อมูลระหว่างโครงสร้างเหล่านี้บ่อย ส่วนใน SQL คุณกังวลเรื่องนั้นน้อยลง แต่ต้องไปกังวลเรื่อง index และ query plan แทน โดยเฉพาะเวลาฐานข้อมูลวางแผนที่ดูโง่ชัด ๆ จนทำให้สิ่งที่เราอยากถามซับซ้อนขึ้น และยังไม่ต้องพูดถึง SQL NULL
      ผลลัพธ์คือซอฟต์แวร์ส่วนใหญ่ของเราถูกกำหนดรายละเอียดมากเกินไปอย่างไม่น่าเชื่อจนถึงระดับค่ารายตัว และแม้ประสิทธิภาพพีซีจะดีขึ้น 1000 เท่า แต่เวลาแฝง UI ที่ดีที่สุดกลับแย่ลงเป็น 10 เท่าจากเมื่อก่อน
      ลัทธิความเคร่งครัดเรื่อง object-oriented programming ก็มีส่วนรับผิดชอบบางส่วน เคยลองใช้ async เหมือนกัน แต่ก็เสื่อมถอยกลับไปเป็นการมองเห็นแต่ต้นไม้ไม่เห็นป่าได้ง่ายเกินไป ด้วยการ await งานอิสระทีละอย่าง
      https://www.uiua.org/ คงต้องจินตนาการเอาว่ามีความสุข

  • เป็นประเด็นที่ดี ทุกภาษาสมัยใหม่บังคับหรืออย่างน้อยก็ชี้นำอย่างแรงให้โปรแกรมเมอร์จัดการรายละเอียด ราวกับเดินลุยเข้าไปในดงวัชพืช
    ภาษาสคริปต์มีตัวดำเนินการสำหรับสิ่งที่มีรายละเอียดน้อยลงเล็กน้อย เช่น โปรแกรมหรือหน้าเว็บ แต่ก็ยังลบรายละเอียดทิ้งไม่ได้
    คุณยังคงต้องคิดและจัดการกับรายละเอียดเล็กจิ๋วมาก ๆ อย่างตัวเลข สตริง และรหัสข้อผิดพลาด
    เราถูกฝึกและทำงานกับการจัดการรายละเอียดมาหลายปี จนคุ้นชินกับมันมาก และเลยกลายเป็นว่า การคิดโดยไม่มองโลกผ่านมุมมองของรายละเอียดนั้นทำได้ยากมาก

  • สิ่งแรกที่ผมนึกถึงคือ อินเทอร์เฟซ ของอ็อบเจ็กต์หรือโมดูล
    ในภาษาโปรแกรม สิ่งนี้มีความเป็นรูปธรรมสูงมาก แต่ในการสนทนาด้วยภาษาธรรมชาติมันพร่าเลือนกว่ามาก
    อีกตัวอย่างหนึ่งคือความต่างระหว่าง generics ใน C++ กับ generics ใน Python ใน C++ คุณต้องจัดการมันอย่างตั้งใจมาก แต่ใน Python ถ้าคุณเมิน type hint ไป มันก็ถูกจัดการแบบค่อนข้างโดยนัย

  • ประโยคที่ว่า “inverse Sapir-Whorf จำกัดสิ่งที่ภาษาพูดไม่ได้ หรือทำให้บางอย่างไม่ง่ายที่จะไม่พูดถึง หรือกระทั่งทำให้ไม่ง่ายที่จะไม่คิดถึงบางอย่าง” ทำให้นึกถึงพีระมิด ไวยากรณ์ > สำนวนการใช้ > standard library > third-party library > ecosystem
    ส่วนที่ว่า “ไม่ง่ายที่จะไม่คิดถึง” ดูเหมือนจะโฟกัสไปที่ปัญหาที่แสดงออกได้ยากหรือมีข้อจำกัดสำคัญ
    ความคุ้นเคยทำงานจากทั้งด้านบนและด้านล่างเข้ามาด้านใน และผู้คนก็เผยภูมิหลังของตัวเองผ่านวิธีที่เขียนโค้ดในแต่ละชั้น

  • แม้ผมจะอ่าน เขียน และพูดภาษาอังกฤษมามากกว่า 15 ปีแล้ว ก็ยังไม่เคยรู้ว่า “I live in London” กับ “I'm living in London” ต่างกัน
    ผมเองก็ไม่รู้เหมือนกันว่าผมอยู่ลอนดอนเป็นการถาวร หรือแค่กำลังอยู่ลอนดอนตอนนี้ 😅

    • “I'm living in London” ถ้าลองคลี่ออกเป็น “I am living in London” จะช่วยได้นิดหน่อย
      ตรงนี้ถ้าเปลี่ยนรูป gerund เป็นคำคุณศัพท์ธรรมดาแล้วลองพูดว่า “I am cold” คุณก็คงเข้าใจว่าหมายถึงตอนนี้หนาว ไม่ใช่ว่าเย็นชาอย่างถาวรแบบซูเปอร์วายร้ายอะไรทำนองนั้น
      ในทำนองเดียวกัน “I am living in London” สื่อว่าตอนนี้อาศัยอยู่ในลอนดอน แต่ในอนาคตอาจเปลี่ยนได้
      และยังมีนัยด้วยว่าไม่ได้อาศัยอยู่ในลอนดอนมาตลอด คล้ายกับที่ “I am cold” มีความหมายแฝงอยู่บ้างว่าอย่างน้อยเคยสัมผัสอุณหภูมิที่อุ่นพอมาก่อน จึงรับรู้ได้ว่าสภาวะตอนนี้ไม่ใช่ “ปกติ” แต่เป็น “หนาว”