Python ไม่ใช่ภาษาที่เหมาะกับ Data Science

• ในงานข้อมูลที่ ไม่ใช่ดีปเลิร์นนิง เช่น การวิเคราะห์ การทำภาพข้อมูล และการสรุปผล แม้ Python จะมีความสามารถเพียงพอ แต่ ประสบการณ์การใช้งานมักซับซ้อนและไหลไปสู่ความไม่มีประสิทธิภาพได้ง่าย
• จากกรณีตัวอย่างในห้องแล็บหลายกรณี พบรูปแบบซ้ำ ๆ ว่า Python ต้องใช้โค้ดและเวลามากกว่า R แม้กับการแปลงกราฟง่าย ๆ หรือการคำนวณสถิติพื้นฐาน
• แม้จะใช้ pandas, matplotlib, NumPy ฯลฯ ก็ยังมักติดอยู่กับ ไวยากรณ์ การทำ indexing วงเล็บ และโครงสร้าง method chain จนโฟกัสไปที่ รายละเอียดการลงมือทำ (Logistics) มากกว่าตรรกะของงาน
• ตรงกันข้าม tidyverse ของ R สามารถแสดงลำดับการประมวลผลข้อมูลได้ใกล้เคียงภาษาธรรมชาติ ทำให้ ถ่ายทอดตรรกะของงานเป็นโค้ดได้ง่ายกว่า
• ในฐานะภาษาสำหรับ data science, Python มี ข้อจำกัดเชิงโครงสร้างในการแยกตรรกะออกจาก logistics และนี่เป็นปัญหาที่มาจากการออกแบบของภาษาและ ecosystem

---

เปรียบเทียบประสบการณ์ใช้งานจริงของ Python และ R

• สมาชิกในห้องแล็บสามารถเลือกภาษาได้อย่างอิสระ แต่มีผู้ใช้ Python จำนวนมาก และพบรูปแบบอย่างสม่ำเสมอว่าคนกลุ่มนี้มักไม่สามารถจัดการคำขอวิเคราะห์เพิ่มเติมแบบง่าย ๆ ได้อย่างรวดเร็ว
  • แม้แต่การเปลี่ยนภาพจาก boxplot → violin plot, histogram → density plot, หรือ line chart → heatmap ก็ยังทำได้ไม่ทันที
  • งานที่ใน R จบได้ภายในไม่กี่บรรทัด กลับให้ความรู้สึกใน Python ว่า “ต้องกลับไปนั่งเขียนโค้ดใหม่”
• แม้เวลาร่วมสอนกับผู้เชี่ยวชาญ Python ก็ยังเห็น ความแตกต่างอย่างมากของความยาวและความซับซ้อนของโค้ดเมื่อเทียบกับ R
  • ปฏิกิริยาแบบ “ทำไมมันต้องซับซ้อนขนาดนี้?” ปรากฏซ้ำในหลายสถานการณ์ และดูเหมือนจะเป็น ความต่างเชิงโครงสร้างของสถาปัตยกรรมภาษาและไลบรารี ไม่ใช่เรื่องความสามารถเฉพาะบุคคล
  • แม้จะเป็นตรรกะเดียวกัน แต่ใน Python มักต้องทำ indexing, แยกข้อมูล, ประกอบกลับ, และเชื่อมหลายเมธอดเข้าด้วยกัน จนโครงสร้างยืดยาว
  • ส่วน R tidyverse สามารถเขียนได้ตรงไปตรงมาด้วย chain แบบธรรมชาติอย่าง filter → group_by → summarize

เหตุผลที่ Python ถูกใช้อย่างแพร่หลาย และข้อจำกัดของมัน

• สถานะของ Python ในโลก data science ตั้งอยู่บน การแพร่หลายทางประวัติศาสตร์ ความเป็นภาษาทั่วไป และขนาดของ ecosystem มากกว่าความเหมาะสมเฉพาะทาง
  • ในสายดีปเลิร์นนิง Python เป็นศูนย์กลางอย่างชัดเจนจาก PyTorch และ ecosystem ด้าน AI
  • แต่ในงาน ทำความสะอาดข้อมูล การสำรวจข้อมูล การทำภาพข้อมูล และการสร้างแบบจำลองทางสถิติ ก็ยังมีความไม่สะดวกอยู่มาก
• มันเป็นความนิยมที่ “ใกล้เคียงกับอุบัติเหตุทางประวัติศาสตร์ (historical accident)” และ ความหนักของโครงสร้างภาษาเมื่อเทียบกับ R ก็ปรากฏซ้ำผ่านหลายตัวอย่าง

คุณสมบัติของภาษาที่ดีสำหรับ data science

• สำหรับงานที่เน้นการสำรวจข้อมูล การสรุปผล การ fit โมเดล และการทำภาพข้อมูล สิ่งสำคัญที่สุดคือ สภาพแวดล้อมแบบโต้ตอบ ต้นทุนการตั้งค่าต่ำ และการวนรอบทดลองได้รวดเร็ว
  • ภาษาสคริปต์แบบ interpreter เหมาะกว่าภาษาคอมไพล์
  • สิ่งที่ควรให้ความสำคัญก่อนประสิทธิภาพคือ ความเรียบง่ายของโค้ด การลดความเสี่ยงของข้อผิดพลาด และการลดภาระทางความคิด
  • หากจำเป็น ก็เพียง rewrite บางส่วนของการคำนวณให้เป็นภาษาประสิทธิภาพสูงอย่าง Rust แทน ไม่จำเป็นต้องทำทั้งระบบ
• ในทางปฏิบัติ ภาษาที่พิจารณาได้จริงคือ R และ Python
  • Matlab, Mathematica ฯลฯ เป็นซอฟต์แวร์เชิงพาณิชย์หรือมี ecosystem จำกัด
  • Julia มักถูกพูดถึงอยู่บ่อย แต่ผู้เขียนยังไม่ได้ใช้อย่างเพียงพอ จึงขอสงวนการประเมินไว้

ปัญหา “Logic vs Logistics”

• ภาษาสำหรับการวิเคราะห์ข้อมูลควรแยกระหว่าง จะคำนวณอะไร (logic) กับ จะคำนวณอย่างไร (logistics)
  • ถ้ายังต้องคอยสนใจชนิดข้อมูล index, loop หรือการประกอบข้อมูลด้วยมือ ก็แปลว่าถูก logistics ครอบงำไปแล้ว
• ในตัวอย่าง Palmer Penguins, tidyverse ของ R สามารถแสดงการคำนวณค่าเฉลี่ยและส่วนเบี่ยงเบนมาตรฐานด้วยลำดับที่ใกล้เคียงภาษาธรรมชาติ
  • ไม่จำเป็นต้องรื้อ data flow ออกมาแล้วประกอบกลับเข้าไปใหม่
• pandas ให้ความสามารถคล้ายกัน แต่ มีงานประกอบอย่างการระบุสตริง วงเล็บ method chain และ reset_index มากเกินไป ทำให้อ่านยากและไม่เรียบง่าย
• หากจะทำงานเดียวกันด้วย Python ล้วน ๆ
  • ต้องจัด loop → สร้าง group key → แยกข้อมูล → คำนวณค่าเฉลี่ย → คำนวณความแปรปรวน → คำนวณส่วนเบี่ยงเบนมาตรฐาน → ประกอบกลับ → เรียงลำดับ ฯลฯ
  • ทุกอย่างต้องทำด้วยมือ และเป็น ตัวอย่างคลาสสิกที่โค้ดด้าน logistics กลบ logic ของงานจนหมด

บทสรุปและเกริ่นถึงเนื้อหาต่อไป

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

ประเด็นอภิปรายเพิ่มเติมและมุมมองเปรียบเทียบ (รวมความเห็นผู้อ่าน)

• มีความเห็นว่า tidyverse อาจยืดยาวกว่า R แบบพื้นฐาน แต่ก็ทรงพลังในด้าน expressiveness, ความสม่ำเสมอ และ abstraction ของการจัดการข้อมูล
• ขณะเดียวกันก็มีข้อโต้แย้งว่า R มีความไม่สะดวกมากในมุมการพัฒนาซอฟต์แวร์ เช่น modularization, testing, และการทำ CLI
• Python มี developer experience ที่ดีในเรื่อง logging, virtual environment, packaging, และโครงสร้าง class แต่
  • matplotlib มี การออกแบบที่ไม่ intuitive,
  • pandas มี ไวยากรณ์ที่ไม่สม่ำเสมอ,
  • scikit-learn ก็มักถูกวิจารณ์เรื่อง ปัญหาด้านการออกแบบ
• บางความเห็นมองว่า Python เป็น “ภาษาที่ผลิตโค้ดไม่เสถียรและคุณภาพต่ำได้อย่างรวดเร็ว” และกล่าวว่า ภาษาที่มี static type เหมาะกับ การพัฒนาที่ยั่งยืน มากกว่า

[kaydash]

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

[GN⁺]

ความคิดเห็นจาก Hacker News

• ยกตัวอย่างการแปลงหลายแบบ เช่น เปลี่ยน boxplot เป็น violin plot หรือเปลี่ยน line plot เป็น heatmap
  ที่จริงแล้วการถกเถียงนี้เป็นเรื่องของ matplotlib มากกว่า Python
  ถ้าต้องการดีไซน์แบบ ggplot ใน Python ก็ใช้ plotnine ได้
  ที่โค้ด R ดูกระชับกว่าก็เพราะ non-standard evaluation ของ R
  Python ไม่เปิดให้มีการขยายแบบนี้ในระดับภาษา
  ดูเพิ่มเติมได้ที่ Computing on the language

  • สุดท้ายแล้วนี่คือเรื่องของความต่างระหว่าง Python กับ R
    non-standard evaluation สะดวกในสภาพแวดล้อมแบบโต้ตอบ แต่พอเขียนโค้ดวิเคราะห์ที่ซับซ้อนกลับกลายเป็น ข้อเสีย
    บางครั้งงานง่าย ๆ ก็ต้องอ้อมไปทำ
  • การวาง pipe ไว้ท้ายบรรทัดในโค้ด R อ่านได้ยาก
    คิดว่าแบบ วางตัวดำเนินการ pipe ไว้ข้างหน้า เหมือน Elixir จะดีกว่า
    Python ก็พอเลียนไวยากรณ์คล้ายกันได้ด้วยลูกเล่นอย่าง getattr แต่สุดท้ายนี่เป็นปัญหาเรื่อง การออกแบบ API ของไลบรารี มากกว่าตัวภาษา
  • ถ้าต้องทำงานแบบโลจิสติกใน R โดยไม่มีไลบรารี? แค่นึกก็สยองแล้ว
    R ใช้ง่ายก็ต่อเมื่อมีไลบรารีและ recipe ให้ใช้ ถ้าไม่มีจะยากมาก และส่วนใหญ่คนก็ไม่ทำกัน
  • สำหรับจุดประสงค์นี้ seaborn เหมาะกว่า
    มันช่วยซ่อนความยุ่งยากของ matplotlib แต่ก็ยังมีความสามารถที่ครบถ้วน
    บทแนะนำ Seaborn
  • สรุปแล้วประเด็นสำคัญดูจะไม่ใช่ Python แต่เป็นการชี้ว่า R ทำอะไรได้บ้างที่ Python ทำไม่ได้

• สงสัยว่าทำไมในภาษาโปรแกรม ตารางถึงไม่ใช่วัตถุชั้นหนึ่ง
  ภาษาส่วนใหญ่ต้องไปเรียน API แยกอย่าง pandas หรือ polars เพื่อจัดการตาราง
  ใน R นั้น data.frame ค่อนข้างใกล้เคียงกับการเป็นวัตถุชั้นหนึ่ง แต่ในทางปฏิบัติมักใช้ tibble ของ dplyr มากกว่า
  เรายังไม่มี ภาษาสำหรับนิพจน์ของข้อมูลแบบตาราง ที่เป็นมาตรฐาน
  แม้ Polars กับ dplyr จะมีแนวคิดคล้ายกัน แต่สุดท้าย SQL ก็ดูเหมือนจะเป็นฐานร่วมเดียว
  คิดว่า Python ยังไม่สมบูรณ์ก็จริง แต่ R ก็ไม่ได้ต่างกัน

  • รู้สึกว่ามีโครงสร้างหลายอย่างที่ขาดหายไปในระดับภาษา
    โครงสร้างอย่าง ตาราง, เมทริกซ์, กราฟ, state machine ไม่ได้รับการรองรับในระดับภาษา จึงทำให้การใช้งานมีข้อจำกัด
    เครื่องมือที่มีมาให้ในภาษาตั้งแต่ต้นเป็นตัวกำหนด “เส้นทางสวยงาม” ของภาษานั้น
    เมื่อก่อนแม้แต่ key-value store ก็ยังเป็นไลบรารีภายนอก แต่ตอนนี้กลายเป็นมาตรฐานไปแล้ว
  • ภาษาอย่าง Q, Rye, Lil จัดการตารางเป็น ชนิดข้อมูลชั้นหนึ่งจริง ๆ
    คาดว่าสักวันภาษากระแสหลักก็น่าจะดูดซับแนวคิด การเขียนโปรแกรมบนฐานตาราง แบบนี้เข้าไป
    ภาษา Q, บทความเปรียบเทียบ Rye, เครื่องมือทดลอง Lil
  • tibble และ data.table สืบทอดจาก data.frame ดังนั้น ฟังก์ชันพื้นฐาน ของ R จึงยังใช้งานได้เหมือนเดิม
    การแปลงไปมาระหว่างทั้งสามอ็อบเจ็กต์ก็ง่ายมาก
  • เมื่อขนาดตารางโตจาก 1 ล้าน, 1 พันล้าน, ไปถึง 1 ล้านล้านแถว ธรรมชาติของปัญหาจะเปลี่ยนไปโดยสิ้นเชิง
    การออกแบบ API มาตรฐานที่จัดการความต่างของสเกลแบบนี้ได้อย่างสวยงามไม่ใช่เรื่องง่าย
  • data.table ของ R ยอดเยี่ยมมาก
    เพียงแต่ dplyr ชนะในด้านเอกสารและการ onboarding จนได้การยอมรับในภาคอุตสาหกรรม

• ประเด็นหลักของบทความก็โอเค แต่เสียดายที่ผู้เขียนเฉลยเหตุผลสนับสนุนเร็วเกินไป
  R เก่งเรื่อง การจัดการ data frame แต่ไม่เด่นเรื่อง การจัดการไฟล์หรือการบำรุงรักษา
  ถ้าต้องทำงานพวกนี้เยอะ Python จะดีกว่า และถ้าความเร็วสำคัญมากก็อาจเอนเอียงไปทาง Julia
  แต่ละภาษาควรถูกเลือกตามลำดับความสำคัญ
  มักเห็นนักเรียนพยายามใช้ pandas แก้ปัญหาที่ไม่ใช่ข้อมูลแบบตาราง เช่น กราฟ ซึ่งในกรณีนั้นควรทบทวนการเลือกเครื่องมือใหม่

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

• ในฐานะโปรแกรมเมอร์ Python ก็เคยใช้ R เหมือนกัน และ Python คือ “ภาษาที่ทำได้เกือบทุกอย่างค่อนข้างดี แต่ไม่สมบูรณ์แบบ”
  ถ้าทำ data analysis ทั้งวัน การเรียน R ก็เป็นทางเลือกที่ถูกต้อง
  R เป็นภาษาออกแบบมาตาม วิธีคิดของนักสถิติ
  ตอนแรกอาจรู้สึกแปลก แต่การเปลี่ยนวิธีคิดนั้นกลับมีประโยชน์
  ถึงอย่างนั้นฉันก็ยังทำงานส่วนใหญ่ใน Python

• ทำ data science ด้วย pandas ได้ก็จริง แต่รู้สึกว่า หยาบและซับซ้อน
  พอใช้ polars ก็ดีขึ้นนิดหน่อย แต่พอใช้ duckdb แล้วรู้สึกต่างออกไปอย่างสิ้นเชิง
  สามารถรัน SQL query ตรงใน notebook และวิเคราะห์ไฟล์ parquet ได้
  ถ้าสลับใช้ทั้ง SQL cell และ Python cell โค้ดจะสะอาดขึ้น
  พอเห็นการเปรียบเทียบ Python vs R ตอนท้ายก็รู้สึกว่า “เขียนเป็น SQL น่าจะดีกว่าไหม?”

  • ฉันชอบแนว dataframe-centric มากกว่า SQL และชอบให้ทุกอย่างจบอยู่ภายในภาษาเดียว
  • ใช้ polars บ่อยเหมือนกัน คงต้องลอง duckdb บ้างแล้ว

• ตัวอย่าง Python ตอนท้ายยืดยาวเกินความจำเป็น
  ถ้าใช้ defaultdict กับ statistics.stddev จะกระชับขึ้นมาก

  • ที่ใส่การแก้แบบ Bessel เองก็น่าสนใจ
    หลายคนมักลงมือเขียนโดยไม่คิดก่อนว่าการแก้นั้นมีความหมายจริงหรือไม่
    จริง ๆ แล้วควรเรียกว่า sample_std_dev จึงจะถูกต้องกว่า
  • ใช้ itertools.groupby ก็ได้
    แม้โค้ดจะไม่สั้น แต่สามารถ สื่อเจตนาได้ชัดเจน
  • โค้ดเดิมอ่านง่ายกว่า
    การพยายามเขียนให้สั้นแล้ว เสียความอ่านง่าย ไม่ใช่เรื่องดี

• ลองทำตัวอย่างเดียวกันด้วย TidierData.jl ของ Julia แล้ว ผลออกมาแทบเหมือนเวอร์ชัน R
  ไวยากรณ์แบบแมโครอย่าง @chain, @group_by, @summarize คล้ายกับ tidyverse ของ R มาก

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

• อยากให้คนใช้ Julia มากกว่านี้
  เมื่อก่อนเคยนำ อัลกอริทึมสำหรับงานวิจัยด้าน psychometrics มาเขียนใหม่ด้วย Julia แล้วรันได้เร็วกว่า MATLAB สามเท่า
  ลิงก์บทความที่เกี่ยวข้อง

  • สงสัยว่าการประหยัดเวลารัน 40 นาทีนั้นสำคัญต่อไทม์ไลน์การเขียนงานวิจัยทั้งหมดแค่ไหน

• ตัวอย่างสุดท้ายดูเหมือน งานล้อเลียน anti-Python มากกว่าจะเป็นโค้ด Python ที่ใช้กันจริง
  การเขียนส่วนเบี่ยงเบนมาตรฐานเองเป็นงานระดับการบ้านปริญญาตรี
  ในความเป็นจริงทั้ง R และ Python ต่างก็วนลูปแบบนี้อยู่ภายในเหมือนกัน

  • เข้าใจได้ว่าบทความโฟกัสที่ บริบทในห้องวิจัย
    แต่ในสภาพแวดล้อมอุตสาหกรรมจริง Python ทำให้ ทำงานร่วมกับทีมวิศวกรรม ได้ง่ายกว่ามาก
    เคย deploy โค้ด R ไป production แล้วไม่เสถียรมาก
    R ยอดเยี่ยมสำหรับ exploratory data analysis (EDA) แต่ไม่เหมาะกับ การพัฒนาซอฟต์แวร์ขนาดใหญ่