پرش به محتوای اصلی

ما باید با نرم افزاری که می سازیم جاه طلب تر باشیم

هکرنیوز۱۴۰۵ آبان ۳, یکشنبه، ساعت ۰۱:۱۷حدود 18 دقیقه مطالعه

آدرس مقاله: https://danluu.com/ambitious/ آدرس نظرات: https://news.ycombinator.com/item?id=50225695 امتیاز: 194 # نظرات: 158

از اوایل امسال، مایکل مالیس (از pgrust) کارهای جالبی را که انجام داده به من نشان می دهد و می گوید

[ما]با نرم افزاری که می سازیم باید جاه طلب تر باشیم

قابل درک است که در مورد پروژه هایی مانند pgrust تردیدهای زیادی وجود دارد زیرا پروژه های تولید شده با هوش مصنوعی با کیفیت بسیار پایین وجود دارد. اگر Malis را نمی‌شناختم و به آن نگاه نمی‌کردم، فقط فرض می‌کردم که pgrust پروژه‌ای دیگر است که هیچ‌وقت کار نمی‌کند. اما من مالیس را آنقدر خوب می شناسم که بدون بررسی به کار او اعتماد کنم، و اگر کمی به آن نگاه کنید، خواهید دید که در آزمایش pgrust، او به اندازه کافی در حال آزمایش کامل است که حتی اشکالات واقعی را در Postgres کشف می کند، مانند این باگ عددی که می تواند باعث شکست عملیات معتبر SP-GiST شود، این فرمت cache bu

g که می تواند باعث نتایج نادرست از JSONPath شود، این باگ pgcrypto که می تواند باعث خرابی عملیات بعدی شود، چندین اشکال ایمنی حافظه در دیکشنری لودر 2، این اشکال سرریز پول و غیره.

این بدان معنا نیست که pgrust بدون اشکال است 3، اما نشان می دهد که مقدار قابل توجهی از آزمایش در حال انجام است و، حتی اگر pgrust خود هرگز موفق نباشد، فقط تلاش باعث بهبود Postgres به روشی بادوام می شود. گام اصلی برای pgrust در واقع عملکرد است، و اینجاست که کار واقعا جالب در حال رخ دادن است. اگر pgrust شکست بخورد، ممکن است برخی از بهینه‌سازی‌هایی که آنها نشان داده‌اند به Postgres، Clickhouse و غیره تبدیل شوند، اما بدیهی است که نسبت به ثبت باگ‌های Postgres که رفع می‌شوند مستقیم‌تر است.

با این حال، به نظرم قابل درک است که هر بار که می‌بینم pgrust در یک جمع‌آوری اخبار مورد بحث قرار می‌گیرد، اکثر مردم آن را به عنوان زباله‌های vibeslop نادیده می‌گیرند، زیرا تقریبا همه این پروژه‌های بازنویسی بی‌حساب هستند. اگر مالیس را نمی‌شناختم، همین فرض را می‌کردم، زیرا چه کسی وقت دارد همه این پروژه‌ها را بررسی کند؟ چون مالیس را می شناسم، حوصله نگاه کردن به آن را نداشتم. من فقط به او اعتماد کردم (من فقط موارد بالا را پیدا کردم زیرا می خواستم قبل از استفاده از pgrust به عنوان نمونه برای این پست، آن را بررسی کنم).

به‌عنوان مصرف‌کننده نرم‌افزار، به هر کجا که نگاه کنید، نرم‌افزار کندی وجود دارد که سازنده ادعا می‌کند سریع است، زیرا سازنده در حال تبلیغ برخی معیارهای شیب‌دار است، به عنوان مثال، در اینجا یکی از چندین نمونه‌ای است که دیروز دیدم، و البته نرم‌افزاری با کیفیت پایین که کار نمی‌کند، رایج‌تر از همیشه است.

اما، به‌عنوان سازنده نرم‌افزار، اهمیتی ندارد که تقریبا همه این پروژه‌ها پر از ویبس لوپ هستند، اینکه افراد دیگر در حال بیرون آوردن انبوهی از مزخرفات هستند و آن را طلا می‌نامند. می‌توانید چیزهایی مانند pgrust یا پروژه‌های دیگری بسازید که در گذشته خیلی بزرگ بوده و واقعا امکان‌پذیر نبوده‌اند، و اگر کار معقولی را با آزمایش و محک زدن انجام دهید، آن چیزها در واقع می‌توانند کیفیت کافی برای استفاده داشته باشند.

اگر داشتم آن را می نوشتم، می گفتم "ما می توانیم با نرم افزاری که می سازیم جاه طلب تر باشیم" و نه "باید"، اما مالیس وقتی این را می گوید به طور معمولی با من چت می کند، بنابراین شاید در یک پست واقعی همین را بگوید. در اینجا بیش از حد باید در مقابل می توانید مطالعه نکنید. چیزی که برای من جالب است این است که چگونه قابلیت ها به گونه ای پیشرفت کرده اند که می توانیم کارهای بیشتری انجام دهیم.

فقط برای مثال، پس از شنیدن این موضوع که OpenAI قصد دارد از Cerebras برای مدل‌های SOTA خود و نه فقط مدل‌های سریع، اما با کیفیت پایین مانند 5.3-Codex-Spark استفاده کند، به این موضوع نگاه کردم که اگر از یک مدل SOTA استفاده می‌کنم، زمان کامپیوتر من به کجا می‌رود، اما 10 برابر تا 100 برابر سریع‌تر. برخی از چیزهایی که قبلا گاهی اوقات یک گلوگاه بودند که با یک مدل سریع‌تر بدتر می‌شدند:

در سطح پروژه "برای من کار می کند"، همه اینها چیزهایی هستند که می توانند به طور جدی بهبود یابند. من در حال حاضر وقت خالی زیادی ندارم، اما با این وجود، این موتور regex را ساختم که می‌توان آن را بهینه کرد تا سریع‌تر از سایر کتابخانه‌های regex عمومی برای هر بار کاری خاصی که برایم مهم است، این فورک ripgrep که از کامپایلر کد بومی موتور regex استفاده می‌کند و برای کدکس ریپ‌گرپ من سریع‌تر است، البته راه‌حل کار ایندکس بهتری است و این یک پروژه "فقط برای سرگرمی" بود که در آن من سعی نمی کردم کار بهینه را انجام دهم)، و یک روسیه

t که ساخت‌ها را برای پروژه‌های من افزایش می‌دهد (پیشرفت بسیار زیاد برای ساخت‌های سرد، متوسط ​​برای گرم، محدود به جلوگیری از دوشاخه کردن کامپایلر Rust). برای سیستم فایل و سربار سیستم، تنها تغییر توسعه از مک به لینوکس این امر را بسیار بهبود بخشید، و البته این یکی دیگر از مواردی است که می‌توان آن را نیز بسیار افزایش داد، به خصوص زمانی که عوامل بسیاری از عملیات‌های سیستم فایل کوچک را چکش می‌کنند (معمولی نیست که ببینم دستگاه من در انتظار عملیات‌های سیستم فایل است، زیرا رابط فایل سیستم استاندارد عملکرد دیسک با ذهن مدرن طراحی نشده است).

برای کسی مثل من که چیزی در مورد رجکس‌ها، الگوریتم‌های تطبیق رشته‌ها، کامپایلرها، مفسرها و غیره نمی‌داند، این مجموعه از پروژه‌ها یک سال یا بیشتر طول می‌کشد تا به کیفیت «برای من کار می‌کند». درعوض، این تعداد تک رقمی کمی از ساعات وقت من بود. اگر بخواهم هر یک از این موارد را با نوار کیفیت "محصول مفید یا پروژه منبع باز" مطابقت دهم، کار بسیار بیشتری خواهد بود 0، اما هنوز هم بسیار باورنکردنی است که سرعت این فرآیند چقدر است.

برداشت من از معنای مالیس وقتی می‌گوید «با نرم‌افزاری که می‌سازیم باید جاه‌طلبانه‌تر باشیم» این است که حتی به ذهن مردم نمی‌رسد که این کارها را انجام دهند که اکنون آسان است. برای هفته‌ها، هر بار که وارد توییتر می‌شدم، می‌دیدم که شخصی از کندی و محدود کردن سرعت کامپایل Rust شکایت می‌کند (فکر می‌کنم وقتی شکایت‌ها را دیدم این در واقع درست نبود، زیرا قبل از در دسترس بودن 5.6 Sol و 6 Astra در Cerebras بود، و اگر زمان را اندازه‌گیری می‌کردید که واقعا زمان سپری شده است، زمان کامپایل Rust در آن زمان واقعا کم نبود).

مطمئنا، سازگاری Rust کند است. شما فقط می توانید یک مترجم Rust بنویسید و همچنین سرعت کامپایل را مستقیما افزایش دهید. مشکلاتی از این دست وجود دارد که من می بینم مردم هر روز از آنها شکایت می کنند که اکنون بدون وقت و تلاش زیاد قابل حل هستند. تا آنجا که من می توانم بگویم، این مشکلات مشکلاتی هستند زیرا مردم به طور ضمنی مدل هزینه پیش از نمایندگی را دنبال می کنند.

ده سال پیش، آن دسته از افرادی که یک کامپایلر جدید را پیاده سازی کردند، زیرا کامپایلر آنها کند بود، از آن دسته افرادی بود که وقتی می خواستند یک بازی مستقل بسازند، شروع به برنامه نویسی یک موتور بازی سه بعدی جدید کردند، یعنی افرادی که هرگز چیزی را ارسال نمی کنند. اکثر برنامه نویسان سازنده که من می شناسم هنوز نسبت به این نوع چیزها بیزار هستند، حتی اگر اکنون اجرای این نوع چیزها در حال حاضر منطقی است.

پروژه دیگری که قبلا به آن اشاره کردم، این هوش مصنوعی Azul بود که در کنترل‌های زمان منطبق، فوق بشری است. وقتی این کار را انجام دادم (با GPT-5.1/5.2)، با دانش هوش مصنوعی صفر، حدود 5 ساعت از زمان من طول کشید تا چیزی فوق بشری به دست بیاورم، و حدود 20 ساعت از زمان من برای تبدیل شدن به قوی ترین هوش مصنوعی در آن زمان، از جمله قوی تر بودن در برابر انسان ها از این هوش مصنوعی که برای تقلب در Board Game Arena استفاده می شد، طول کشید. گابریل کانگوسو اخیرا یک هوش مصنوعی ساخته است که هوش مصنوعی من را از بین می‌برد، و AFAICT، به طور قابل‌توجهی کمتر از زمانی که هوش مصنوعی من به من اختصاص داد، زمان برد.

از صحبت با او در مورد آن، یک تفاوت کلیدی این است که Fable 5.1 و Opus 5.5 درک بسیار بهتری از هوش مصنوعی بازی رومیزی دارند. وقتی از GPT-5.1/5.2 استفاده می کردم، تقریبا هر پیشنهادی که آنها داشتند اشتباه بود و من مجبور بودم فرمان زیادی را انجام دهم تا همه چیز از راه دور منطقی باشد. اگر GPT یک پایگاه کد یا مقاله ای را برای پیاده سازی تکنیک های مربوطه از مقاله بخواند، شکست می خورد.

اگر من مقاله را خودم بخوانم و تکنیکی را نام ببرم، می‌گوید این تکنیک را انجام می‌دهد، اما به طور کلی کاری انجام می‌دهد که ظاهرا شبیه تکنیک است، اما تا زمانی که برخی اصلاحات را انجام دهم، تکنیک واقعی نبود. زمانی که مدل بسیار دور از توانایی انجام کار است، اگر هیچ پیشینه ای در آن منطقه ندارید، بررسی اینکه آیا مدل کار درستی را انجام داده است، بسیار زمان بر است، زیرا باید به اندازه کافی در مورد کاری که قرار است انجام دهد یاد بگیرید تا بتوانید بررسی کنید که آیا آنچه را که ادعا شده انجام داده است یا خیر.

وقتی آن پروژه را انجام دادم، به دوستان گفتم که فکر نمی‌کنم مدل‌های موجود در حالت ماندگار باشند. غیرممکن به نظر می رسید که آنها به اندازه کافی خوب نشوند که بتوانند به زودی یک مقاله را بخوانند و تکنیک ها را پیاده سازی کنند، و به نظر می رسید که آنها همچنین باید بتوانند پایگاه های کد و کاغذهایی را برای تخت خواب انتخاب کنند.

با توجه به تجربه من که کمی با Fable 5 و تجربه Cangussu با Fable 5.1 و Opus 5.5 بهم ریخته ام، به نظر می رسد که این اتفاق افتاده است، که برای فردی مثل من که چیزی در مورد هوش مصنوعی بازی های تخته ای نمی داند (الان کمی می دانم، اما کمتر از هر محقق واقعی هوش مصنوعی) صرفه جویی زیادی در زمان است.

BTW، وقتی مردم گفته اند که از مدل جدید استفاده کرده اند و همه چیز فقط کار می کند، نرم افزار حل می شود و غیره، من اصلا این را درست ندیدم. درست است که چیزهای بیشتری وجود دارد که مدل جدیدتر می تواند یکبار عکس بگیرد، که در آن چیزها اساسا کار می کنند، اما این فقط به این معنی است که من در نهایت روی چیزهای جاه طلبانه تری کار می کنم، جایی که مدل ها هنوز با مشکل مواجه می شوند.

من بهره‌ورتر هستم و می‌توانم سریع‌تر کار کنم، اما از نظر کاری که انجام می‌دهم، با هر مدل توانمندتر از «فقط کار می‌کند» دورتر می‌شوم زیرا شکاف بین آنچه مدل می‌تواند به‌طور مؤثر بدون دست‌گیری قابل توجه تأیید کند و آنچه مدل می‌تواند پیاده‌سازی کند، افزایش یافته است. همه این‌ها روشی طولانی و کم‌تر شیوا برای گفتن است: ما باید با نرم‌افزاری که می‌سازیم جاه‌طلبانه‌تر باشیم.

با تشکر از لارنس ترات، یوسی کرینین، الکس کولوفسکی و مایکل مالیس برای نظرات/اصلاحات/بحث.

من این یادداشت را در پست های اخیر خود داشتم که در مورد این مورد نیز صدق می کند. برای اینکه پست‌های بیشتری منتشر کنم، سعی می‌کنم پست‌ها را در نیم ساعت منتشر کنم و زیاد آنها را مرور نکنم. این قطعا به معنای پست هایی است که پشتیبانی کمتری دارند. اگر من این را به سبک استاندارد خود می نوشتم، برای همه پروژه هایم که ذکر کردم، معیارهای جامعی داشتم. در عوض، من یک مقایسه سریع انجام دادم که کنجکاویم را برآورده کرد و این را بدون محک زدن دقیق می نویسم، و شاید بیست یا سی کار در این پست وجود داشته باشد که دوست دارم انجام دهم اما انجام نداده ام.

من حتی این مترجم Rust را هم ننوشته ام. اگر پنج سال پیش، مترجم Rust را با هم ترکیب می‌کردم که در کامپایل‌های سرد 50 برابر سرعت داشت و در ساخت‌های گرم/حافظه پنهان 2 برابر (در صورتی که ویرایش‌ها در کامپایلر Rust در محدوده باشد، امکان بسیار بیشتری وجود داشت)، چیز فوق‌العاده جالبی بود که می‌خواهم بنویسم، اما حتی در این حالت کار نمی‌کنم و در این حالت کار نمی‌کنم. برای نوشتن به اندازه کافی جالب است، زیرا انجام کارهایی که تا همین چند وقت پیش بسیار جالب تلقی می شدند بسیار آسان است.

در اینجا یک نظر از Yossi Kreinin نقل شده است (البته با اجازه):

اگر این را منتشر کنید، پاسخی را منتشر خواهم کرد که توضیح می‌دهد برای اکثر افراد باید با نرم‌افزاری که با هوش مصنوعی می‌سازند، جاه‌طلبی کمتری داشته باشند، در غیر این صورت با شکست شدیدی مواجه خواهند شد. من فکر می‌کنم بسیاری از مشکلات به خوبی به «حلقه‌های عامل» نمی‌خورند، زیرا معیارهای قبولی/شکست واضحی ندارید، و حتی زمانی که این کار را انجام می‌دهید، اکثر مردم در استدلال در مورد جعبه‌های سیاه غول‌پیکر مشکل دارند که می‌توانند محدودیت‌هایی را بر آن‌ها تحمیل کنند، اما نمی‌توانند درونیات [من خودم را در این مجموعه گنجانده‌ام.] درک کنند.

اما احتمالا برای اکثر مردم، کمتر به آن نیاز دارند و اصلا نمی‌توانند از آن به خوبی استفاده کنند. من به نوعی حسادت می کنم به کسانی که باید و در واقع می توانند در مورد نرم افزاری که می سازند اینقدر جاه طلب باشند. نمی گویم اصلا نباید جاه طلب تر باشید، اما تعدیل کردن جاه طلبی بخش بزرگی از مدیریت وضعیت فعلی برای اکثر افراد است.

من فکر مشابهی در مورد "دلیلی برای کند بودن نرم افزار وجود ندارد" BTW دارم. در بسیاری از موارد، اگر از هوش مصنوعی برای سرعت بخشیدن به جریان استفاده می‌کنید، یک سری کدهای آشفته اضافه می‌کنید که برای موارد استفاده‌ای که روی آن آزمایش کرده‌اید بیش از حد مناسب هستند و نه تعمیم‌دهنده، کاملا عاقلانه برای همه موارد استفاده‌ای که باید به آن‌ها اهمیت می‌دهید و نه در صورت تغییرات آتی قابل نگهداری خواهند بود.

اگر می‌دانید دارید انجام می‌دهید و می‌دانید که چگونه سیستم باید به قطعات تجزیه شود و چه زمانی منطقی است که روی بهینه‌سازی بخشی یا ترکیبی از آن‌ها که با هم کار می‌کنند، همه کاره شوید و چگونه به درستی آن را بنچمارک کنید و غیره، همه چیز عالی است، اما اگر برای مثال مدیری دارید که فکر می‌کند دلیلی برای کند بودن نرم‌افزار وجود ندارد و او مردم را تحت فشار قرار می‌دهد تا نرم‌افزارهای سریع Run را پوشش دهند تا از هوش مصنوعی استفاده کنند...

احساس من این است که، به طور کلی، وضعیت اینجا کمی شبیه به بحث اینجاست که چرا من دوست ندارم وقتی مردم در مورد اینکه چگونه هوش مصنوعی 100 یا 1000 برابر بهره وری را افزایش می دهد، صحبت می کنند. برخی چیزها هستند که با یک عامل بسیار بزرگ، به راحتی بیش از 1000000 برابر سرعت می‌یابند. و بعضی چیزها در حال حاضر اصلا سرعت نمی‌گیرند. اگر دقیقا همان کاری را انجام می‌دهید که پنج سال پیش انجام می‌دادید، اما با هوش مصنوعی، به دلیل قانون Amdahl، سرعت نسبتا ضعیف است.

اما، در حالت کلی، شما می‌توانید انتخاب کنید که چه چیزی را تسریع کنید و اگر به دنبال کارهایی هستید که برای انجام آنها مفید باشد، به نظر می‌رسد که این اغلب شامل کارهایی می‌شود که قبلا انجام آنها بسیار گران بودند.

من احساس می‌کنم بسیاری از مشکلات در چیزی شبیه به این دسته از مشکلات هستند، جایی که می‌توان نوعی تنظیم حداقل تا حدی خودکنترلی را راه‌اندازی کرد که یک انسان بتواند زمان کمی را صرف آن کند. این نیز مشابه وضعیت آزمایش نرم‌افزار در کل است، جایی که (قبل از عوامل کدنویسی) آزمایش‌های فازی و مبتنی بر ویژگی را بسیار مؤثر تشخیص دادم. برای اکثر دامنه‌ها، مردم به من گفتند که این نوع آزمایش جواب نمی‌دهد، اما وقتی این تکنیک‌ها را با همه دامنه‌ها امتحان کردم، مردم به من گفتند که این تکنیک‌ها برایشان کار نمی‌کنند، خوب کار می‌کنند.

آنها تا حدودی کار بیشتری برای اعمال دارند، اما هنوز هم قابل اجرا هستند و، AFAICT، کارآمدتر و موثرتر از نوشتن تست های واحد سنتی هستند.

بخشی از اصل نظر یوسی این است که مردم چنین کاری را انجام نمی دهند. با توجه به اینکه الان چند باگ بیشتر از گذشته می بینم، به عنوان مثال، آخرین باری که گپ وب را برای یک آزمایشگاه بزرگ هوش مصنوعی باز کردم، در عرض یک دقیقه با تعداد دو رقمی باگ مواجه شدم، گفتن اینکه یوسی اشتباه می کند سخت است. اما، تا آن نقطه، من هنوز نظر اصلی خود را دارم. صرفا به این دلیل که افراد دیگر مقادیر زیادی شیب به سختی کار می کنند به این معنی نیست که شما باید همان کار را انجام دهید.

مثال‌هایی در متن پستی که برای کارهایی که انجام داده‌ام آورده‌ام، کارهای ابزاری هستند که هرگز انجام نمی‌دادم. چیزهای بیشتری مانند آن وجود دارد زیرا ساخت ابزار با کیفیت "برای من کار می کند" که فقط برای من در نظر گرفته شده است بسیار آسان است. من فکر می‌کنم می‌توان فراتر از مولد بودن رفت، به عنوان مثال، استیو یگ در مورد شهر گاز و میزان سازنده آن بسیار نوشت، اما زمانی که در حال ساخت چارچوب عامل بعدی خود بود، خاطرنشان کرد که هرگز از Gas Town برای ساخت موفقیت‌آمیز چیزی غیر از شهر گاز استفاده نکرده است، مردم برای مدتی به رالف لوپز علاقه‌مند بودند، حتی زمانی که آنها را مقایسه کردم.

آنها به نظر بدتر از انجام کارهای ساده لوحانه ای بودند که من در آن زمان انجام می دادم، حلقه های معمولی با زمینه ای که گاهی اوقات به جای انجام پیش فرض در نقطه ای کاملا دلخواه در زمانی که یک چرخش منفرد انجام می شود و غیره، متن را به صورت مناسب پاک می کنید، بنابراین من سعی کرده ام به چیزهایی بچسبم که تأثیر آنها کاملا مستقیم است.

علاوه بر دلیل واضح موثر بودن این امر، تغییر چشمگیر در مدل و قابلیت مهار در طول زمان به این معنی است که ساخت ابزارها بسیار سریع تغییر می‌کند، بنابراین صرف زمان زیادی برای کار کردن بر روی هر ابزار خاصی که در بهترین حالت و احتمالا در عرض سه ماه منسوخ خواهد شد، واقعا منطقی نیست.

و برای بسیاری از ابزارهای شخصی من، فرض من این است که یک آزمایشگاه هوش مصنوعی هر چیزی را که من بسازم در کوتاه مدت منسوخ خواهد کرد. برای مثال بسیار احمقانه‌ای از این، من ابزاری دارم که از زمان انتشار GPT-5.6 Sol مفید بود که با پیدا کردن نشت حافظه، کدکس را مجددا راه‌اندازی می‌کند. احتمالا OpenAI در نقطه ای این مشکل را برطرف می کند و این ابزار بی ارزش می شود. برای مثال کمی احمقانه تر، مترجم Rust I had some agent build را در نظر بگیرید. به دلایل بودجه رمزی، بسیاری از کارهایی که برای یک مترجم با کارایی بسیار بالا باید انجام شود، انجام نشده است.

چیز دیگری که ممکن است کسی آن را جاه طلبانه نخواند، اما نشان دهنده آن چیزی است که ممکن است، بازی هایی است که من ساخته ام. بازی‌هایی هستند که من به آنها فکر کرده‌ام و می‌خواهم آن‌ها را بسازم که فکر نمی‌کنم عموما آنقدر لذت‌بخش باشند که برای مخاطب واقعی معنا پیدا کنند، اما می‌خواستم بازی کنم. به عنوان مثال، از زمانی که کتاب‌های گرگ ستاره دیوید جرولد را در دهه 90 خواندم، می‌خواستم بازی‌ای را انجام دهم که مبارزه را همانطور که در کتاب‌ها توضیح داده شده است، اجرا کنم، که به نوعی شبیه نبرد زیردریایی است.

حداقل در میان بازی‌های جنگی واقع‌گرایانه، این ژانر فوق‌العاده خاص است، زیرا تقریبا برای همه، نبرد دریایی خسته‌کننده است، و مبارزه زیردریایی یک زیرژانر به‌ویژه خسته‌کننده از بازی‌های رزمی دریایی است، بنابراین واقعا به عنوان یک بازی پول‌ساز منطقی نیست، اما اجرای بازی‌ها به قدری آسان است که از یک مامور مجبور شدم بازی را اجرا کند تا بتوانم آن را برای یک یا دو ساعت بازی کنم. من هرگز 10 تا 20 ساعت را صرف اجرای یک بازی نمی کردم تا بتوانم آن را برای یک یا دو ساعت بازی کنم، اما 5 دقیقه وقت صرف می کردم. من همچنین قبلا به اجرای یک بازی با قوانین مشابه Scout and Guards of Atlantis 2 اشاره کرده ام.

من هرگز قرار نبودم برای اجرای این بازی‌ها به صورت دستی وقت بگذارم، فقط برای این که در مواقعی که نمی‌توانیم حضوری دور هم جمع شویم، راهی برای بازی با دوستانم داشته باشم، اما خوشحالم که LLM این چیزها را کنار می‌زند. و البته برای افرادی که می‌خواهند بازی‌هایی با مخاطبان بیشتری بسازند، در حال حاضر به دلیل عوامل کدنویسی، رنسانس بازی در جریان است. بسیار شگفت انگیز است که اکنون چقدر بازی های جالب و خلاقانه ساخته می شود که داشتن مهارت های برنامه نویسی و زمان استفاده از آنها دیگر گلوگاهی برای ساخت بازی نیست.

تجزیه و تحلیل داده ها چیز دیگری است که در آن ضریب بهره وری می تواند بسیار بالا باشد و من می توانم انواع کارهایی را انجام دهم که هرگز انجام نمی دادم. همانطور که در تعدادی از آخرین پست‌هایم اشاره کرده‌ام، من تعداد زیادی از این پروژه‌ها را دارم که واقعا قادر به نوشتن آنها هستم، حتی زمانی که سعی می‌کنم خیلی سریع بنویسم و ​​پست‌ها را در نیم ساعت هرکدام از بین ببرم.

وقتی با مردم در مورد ابزار یکباره آنها صحبت کردم، کارهای سرگرم کننده زیادی وجود دارد که مردم انجام داده اند. به عنوان مثال، در اینجا چیزی است که پیتر جوگگان یکی دو ماه پیش به آن اشاره کرد:

من از Fable یک تابع سفارشی Neovim Lua را خواستم که کد را بر اساس ترجیحات بسیار خاص من قالب بندی می کند. این هم چیزی است که من نمی خواهم خودم را حفظ کنم و هم ذاتا یک دستگاه Rube Goldberg است. از نظر تئوری، من می‌توانم همان نتیجه را به شیوه‌ای اصولی با وصله کردن فرمت clang به دست بیاورم، اما الزامات من آنقدر دقیق هستند که فکر می‌کنم آن رویکرد هرگز رضایت‌بخش نخواهد بود.

ما از ابزاری به نام pgindent استفاده می کنیم که فورک bsd_indent ما است. شما می توانید قوانین قالب بندی مشابه را با استفاده از clang-format تقریبی کنید، اما این به اندازه کافی خوب نیست. اگر چیزی را مرتکب شوم که مطابق با pgindent کاملا قالب‌بندی یا تورفتگی نداشته باشد، با یک نقص CI مواجه می‌شوم که انتظار می‌رود سریع آن را برطرف کنم -- چیزی که واقعا ترجیح می‌دهم از آن اجتناب کنم ...

از نظر عملی، قالب‌بندی نرم و به سبک clang که از ایمیل‌های ناراحت کننده درباره کدهای نادرست جلوگیری می‌کند، نیاز به یک آشفتگی معماری کامل دارد (من همچنین نمی‌خواهم زمان صرف توسعه یک رویکرد اصولی کنم، اما این واقعا یک موضوع جداگانه است). این تابع به من اجازه می دهد تا بدون زحمت یک بلوک کد معین از Neovim را فرمت کنم، شبیه به ادغام LSP با فرمت cang. البته من در اینجا به طور غیرمنطقی پرحاشیه هستم، اما متوجه شدم که LLM به من اجازه می دهد که در مورد ابزارسازی اینقدر سختگیر باشم.

این تابع چندین پاس را انجام می دهد: یک پاس قالب بندی اولیه با استفاده از clang-format/clangd و یک پاس قالب بندی جداگانه با استفاده از pgindent. من به آن نیاز دارم تا هر دو را انجام دهد زیرا فرمت clang برخی از موارد را که pgindent از دست می دهد به درستی مدیریت می کند. این شکننده است زیرا من فقط می‌خواهم کد را در محدوده‌ای از خطوط انتخاب شده از طریق حالت بصری بلوک قالب‌بندی کنم (نمی‌خواهم فرمت clang را روی کدی که توسط پچ من اضافه نشده است اجرا کنم). این با طراحی pgindent در تضاد است. فقط می تواند کل فایل های C را فرمت کند.

خواندن متن کامل در هکرنیوزبه زبان اصلی، در سایت ناشر باز می‌شود
متن اصلی (انگلیسی)

We should be more ambitious with the software we build

Article URL: https://danluu.com/ambitious/ Comments URL: https://news.ycombinator.com/item?id=50225695 Points: 194 # Comments: 158

همه‌ی اخبار فناوری