असाधारण प्रोग्रामिंग भाषा Hurl

 (hurl.wtf)
2 पॉइंट द्वारा GN⁺ 2024-05-27 | 1 टिप्पणियां | WhatsApp पर शेयर करें
  • Hurl एक experimental programming language है, जिसमें सामान्य branching या loop के बजाय सिर्फ exception handling से control flow बनाया जाता है
  • इसकी शुरुआत Nicole Tietz-Sokolskaya और Recurse Center के दोस्तों के बीच हुई बातचीत से हुई, और साइट usage docs, examples, debugging guide और सवाल-जवाब भी देती है
  • introduction page के testimonials में “monstrosity is beautiful”, “Certified unhinged™” जैसी पंक्तियों के जरिए जानबूझकर मजाकिया माहौल को सामने रखा गया है
  • Hurl और साइट का source code सार्वजनिक है, लेकिन email patch भेजने के लिए patch rights assignment जरूरी है
  • license AGPL-3.0, GAL-1.0 और commercial license में से किसी एक को चुनने के तरीके से उपलब्ध है

सिर्फ exception handling छोड़ देने वाला भाषा प्रयोग

  • Hurl को एक ही मकसद से बनाया गया है: यह तलाशना कि क्या exception handling-based control flow से बनी भाषा संभव है
  • idea Nicole Tietz-Sokolskaya और Recurse Center के दोस्तों की बातचीत से आया, और दोस्तों की पहचान “शालीनता के लिए” सार्वजनिक नहीं की गई है
  • साइट Hurl usage docs, examples, debugging guide, और सवाल-जवाब उपलब्ध कराती है

मजाक जैसा दिखता है, लेकिन सच में publicly released project

  • introduction page पर Hurl के स्वभाव को दिखाने वाले testimonials दिए गए हैं
    • “This monstrosity is beautiful, and I must never touch it”
    • “Certified unhinged™!”
    • “is "🤮" an available quote?”
  • अगर आप अतिरिक्त testimonial शामिल कराना चाहते हैं, तो Nicole को email भेजना होगा, और quote शामिल करने के लिए स्पष्ट सहमति जरूरी है

source code और license terms

  • Hurl language और इस site का source code Hurl's repo पर सार्वजनिक है
  • अगर कोई bug या error मिलता है, तो email patch भेज सकते हैं, लेकिन patch के सभी rights सौंपने होंगे
    • यह relicensing और commercial licensing की संभावना बनाए रखने की शर्त है
  • project को नीचे दिए गए तीन licenses में से किसी एक के तहत इस्तेमाल किया जा सकता है

    • AGPL-3.0

      • GAL-1.0: Gay Agenda License
      • commercial license
      • license review प्रक्रिया में joke licenses और unfortunate licenses पर भी विचार किया गया, लेकिन अंततः ऊपर दिए तीन licenses इस्तेमाल किए गए

संबंधित पढ़ाई

1 टिप्पणियां

 
GN⁺ 2024-05-27
Hacker News की रायें

  • अगर कोई programming language डिजाइन कर रहा हो, तो include/import में namespace अनिवार्य करना और हो सके तो top-level side effects भी रोकना बेहतर होगा
    let foo = include "lib/foo.hurl" की तरह लेकर foo.init() कॉल करें, तो reasoning करना कहीं आसान हो जाता है
    इसके उलट include "lib/foo.hurl" // side effects के बाद baz(buz) आए, तो यह समझना मुश्किल होता है कि functions और variables standard library से हैं या कहीं से include किए गए हैं

    • अगर explicit name binding नहीं है, तो import statement और namespace का मिलना enforce करना बेहतर होगा
      import "foo/bar" से foo.* या bar.* इस्तेमाल हो सकना चाहिए, bazz.* नहीं आना चाहिए। Go तुरंत याद आता है
    • असहमत तो नहीं हूं, लेकिन काम में इस्तेमाल होने वाला IntelliJ साफ दिखाता है कि कौन-सा reference कहां से import हुआ है, और shortcut से वहां जा भी सकते हैं
      VSCode भी plugins और LSP से कुछ ऐसा ही करता है, लेकिन काफी कमजोर है। Code navigation इतनी धीमी है कि VSCode में काम नहीं कर सकता
      सोचता हूं कि ऐसी सलाह सिर्फ तब उपयोगी है जब ऐसे tools न हों। कम से कम professional environment में ऐसे tools के बिना रहना असंभव लगता है
    • ऐसा करने से foo.init() में parameters pass किए जा सकते हैं, जबकि bare import से यह संभव नहीं होता
    • अगर किसी भाषा में flow control exception-केंद्रित है, तो लगता है “reasoning आसान” वाली नाव पहले ही निकल चुकी है
      इसका मतलब यह नहीं कि यह project बेकार है; बल्कि मैं इसे एक कलाकृति मानता हूं
    • 100% सहमत
      मैंने कभी Ruby को fork करके require को symbol table overwrite न करने वाला बनाया था, लेकिन लगा कि Ruby ecosystem shared global mutable state पर बहुत ज्यादा निर्भर है, और अंततः Ruby में ही रुचि खत्म हो गई

  • Exceptions हमेशा खराब लगे, क्योंकि वे caller और callee के बीच का contract समझना कठिन बनाते हैं और code coupling भी बढ़ाते हैं
    मुझे Go या Rust की तरह return values से handle करने का तरीका पसंद है। भाषा को सरसरी तौर पर देखने पर नहीं पता कि इसमें इस समस्या को हल करने वाली कोई चीज है या नहीं
    अगर IDE किसी function की सभी uncaught exceptions को dynamically पता लगा सके और जहां exception throw हो सकती है वहां jump करा सके, तो ऐसा model ठीक हो सकता है। हालांकि coupling को कैसे संभालेगा, यह नहीं पता, और control flow graph बेहद अस्थिर हो जाएगा लगता है

    • Java में IntelliJ ठीक यही करता है। कोई function exception throw करता है और project में कहीं caller उसे catch नहीं करता, तो उसे problem की तरह दिखाता है, और implementation या call site पर आसानी से जा सकते हैं
      हालांकि Java में, जब तक वह RuntimeException inherit नहीं करता, function जो exceptions throw कर सकता है वे function signature का हिस्सा होती हैं। ऐसे में signature में जोड़े बिना exception throw करने पर compile नहीं होता
      Java की स्थितियां IDE के लिए uncaught exceptions report करना बहुत आसान बना देती हैं, लेकिन non-runtime exceptions के मामले में यह static analysis से हल होने वाली समस्या है
      दूसरी ओर standardized Ok/Err wrapped values return करने का तरीका tooling support और developer convenience दोनों के लिहाज से सरल लगता है
    • exception throw करने और exception को variable के रूप में return करने के बीच सचमुच कोई अंतर नहीं है
      फर्क सिर्फ इतना है कि exception propagation वाले तरीके में compiler जो boilerplate code कर देता, उसे आपको हाथ से लिखना पड़ता है
      2024 में ठीक से काम करने वाले दिमाग वाला कोई व्यक्ति यह हाथ से क्यों करना चाहेगा, यह मेरी समझ से बाहर है
    • अगर Go error context को स्वाभाविक रूप से निगल न जाता, तो शायद मुझे वह ज्यादा पसंद आता
      जितना मैंने इस्तेमाल किया, उसमें debugger के बिना root cause ढूंढना कहीं ज्यादा दर्दनाक था

  • toss example में लिखा है कि “यह function के बाहर कई values pass करने के लिए मुख्य रूप से इस्तेमाल होता है, जरूरी नहीं है पर cute है”, लेकिन यह बेकार तो दूर, resumable generator लागू करता है
    बेशक तुरंत resume करने के अलावा कुछ और करवाना हो तो यह काफी दिलचस्प हो सकता है। बस पूरी codebase को toss के inner-outer stacks के रूप में बनाना होगा

    • बिल्कुल वही नहीं है। Resumable generator को program में बाद के किसी भी point पर resume किया जा सकता है, लेकिन यहां return को handler की ओर lexically scoped होना पड़ता है
      उदाहरण के लिए Python में कहीं से भी next() call कर सकते हैं
      यह side channel से callback pass करने जैसा ज्यादा है। toss उस callback को call करता है, और return सचमुच वहीं से return करता है
    • पढ़ने के बाद मेरा पहला विचार भी बिल्कुल यही था
      दूसरी languages में जो सचमुच उपयोगी feature होता, उसे यहां discard की जा सकने वाली cute feature की तरह treat करना थोड़ा joke जैसा लगा
    • यह stack-based event propagation जैसा ज्यादा है
    • क्या यह C# के yield जैसा है?
    • मेरा पहला विचार भी यही था। Generator वाली छोटी और अच्छी language, ठीक है

  • Hurl, Smalltalk या Common Lisp शैली के condition system के काफी करीब लगता है
    stack unwinding और resumption संभावित restarts में से सिर्फ दो हैं: https://gigamonkeys.com/book/beyond-exception-handling-condi...

  • project से अलग, मेरा पक्का मानना है कि अगर ज्यादा चीजें domains में .wtf extension इस्तेमाल करें, तो दुनिया बेहतर हो जाएगी

  • यह algebraic effects का कमजोर रूप जैसा सुनाई देता है, लेकिन ऐसी language और उससे क्या किया जा सकता है, यह देखना फिर भी शानदार है

    • मैंने algebraic effects कभी समझे नहीं, लेकिन Hurl docs समझ में आ गए
      अगर algebraic effects मूल रूप से Hurl के toss keyword जैसी चीज हैं, तो सोचता हूं कि वे toss से किस तरह ज्यादा शक्तिशाली हैं

  • मजेदार thought experiment है
    मुझे exceptions सच में नापसंद हैं, और मैं ऐसी language चाहता हूं जिसमें exceptions न हों
    exceptions हमारे दौर का goto हैं
    जब Maybe/Option और Effect/Result मौजूद हैं, तो exceptions throw करने और वे कहां handle होंगी यह दिमाग में track करने की बहुत कम वजह बचती है
    थोड़ा डर है कि algebraic effects और popular हो जाएं और पहले से ही बहुत complex frontend JS पर भी असर डालें। क्योंकि वे flow control के लिए “exceptions” throw करने के तरीके को encourage करते हैं
    अगर यह सब async/sync color problem से बचने के लिए है, तो निजी तौर पर मेरे लिए यह बिल्कुल worth नहीं है

  • वाह, यह मुझे पसंद नहीं। लेकिन अजीब तरह से इसमें लगभग elegance है
    दिमाग में model करना बहुत मुश्किल है, फिर भी
    थोड़ा गंभीर होकर कहूं तो resumable exceptions और non-resumable exceptions के लिए syntax के स्तर पर अलग catch constructs होते, तो अच्छा होता। इससे यह syntactic ambiguity खत्म हो जाती कि return control flow को nearest immediate exception के thrower की ओर वापस भेजता है या नहीं
    और standard library को सामान्य value-returning functions की ओर भागना नहीं चाहिए। अपना बनाया हुआ खाना खाकर acidity हो जाए, तो उसे न खाने की वजह नहीं बनती

    • सही। हालांकि एक और विकल्प यह हो सकता है कि जहां value expected हो वहां function call करने पर syntax अपने-आप catch कर ले

  • क्या मेरी समझ सही है कि hurl की गई चीज catch की जा सकती है, लेकिन toss की गई चीज नहीं? इसकी आदत पड़ने में समय लगेगा
    यह भी चिंता है कि मुझे कितना Hurl लिखना पड़ेगा, तब लोग मुझे tosser कहना शुरू करेंगे

  • Toss एक दिलचस्प language construct जैसा लगता है। यह stack पर ऊपर चढ़कर exception handler ढूंढता है, फिर मूल जगह पर लौटकर ऐसे execution resume करता है जैसे कुछ हुआ ही न हो
    इस construct से runtime पर additional behavior inject किया जा सकता है लगता है
    आम तौर पर object-oriented code में service constructors के जरिए dependency injection किया जाता है, लेकिन क्या toss “toss handler” के जरिए यह संभव बनाता है?

    • Koka देखें। यह algebraic effect system वाली “असली” language है
      https://koka-lang.github.io/koka/doc/book.html#why-handlers
    • यह Common Lisp के condition system से काफी मिलता-जुलता है
      मुझे बहुत ज्यादा जानकारी नहीं है, लेकिन इतना पता है कि यह runtime पर behavior इस तरह inject करने देता है
    • VB के Resume Next जैसा है