সাক্ষরিত প্রোগ্রামিং কেন মূলধারার নয়? [বন্ধ]

32

সাহিত্যের প্রোগ্রামিং ভাল আদর্শ আছে। আপনি কেন ভাবেন যে এটি মূলধারার নয়? এটি বিতরণ করতে ব্যর্থ হয়েছে কারণ?

programming-practices literate-programming

— Casebash
সূত্র

2

কারণ এর জন্য যে সরঞ্জামগুলি বিকাশ করা হয়েছিল সেগুলি এখনও বেশ দুর্বল। মাইক্রোসফ্ট সম্ভবত এই ক্ষেত্রে নেতৃত্বের একটি সুযোগ আছে।

— কাজ

3

কোনও নতুন সমস্যার কাছে যাওয়ার সময়, আমি প্রায়শই পেনসিল এবং কাগজ ব্যবহার করে আমার নিজের 'লিটারেট প্রোগ্রামিং' শর্টহ্যান্ড ব্যবহার করি। এটি আমাকে ভাষার শব্দার্থবিজ্ঞানগুলি উপেক্ষা করতে এবং মানব ভাষায় মিশ্রিত করে সেই জিনিসগুলিকে ফাংশন ইত্যাদি বলে বর্ণনা করতে পারে

— ওস্টারওয়াল

1

এমনকি নথও এই ধারণার বিষয়ে আর বিশ্বাসী নন: "এবং আমরা" সাক্ষর প্রোগ্রামিং "এর পুরানো ধারণাটি এড়িয়ে যাচ্ছি যেটি আমি TEX82 বিকাশের সময় ব্যবহার করেছি, কারণ ডকুমেন্টেশন খুব বেশি ব্যথার প্রমাণিত হয়েছে।" tug.org/TUGboat/tb31-2/tb98knut.pdf ।

— h0b0

6

টেক্স এবং এর দর্শনের সাথে যারা অপরিচিত তাদের জন্য এটি উল্লেখ করা উচিত যে নথের উদ্ধৃতিটি সম্ভবত ব্যঙ্গাত্মকভাবে বোঝানো হয়েছে।

3

@ h0b0 এবং ব্যবহারকারী 1249: নুথের পুরো নিবন্ধটি বিড়ম্বনাজনক, কারণ আপনি কেবল এলোমেলো পড়ে এটি জানতে পারেন। তিনি স্টিভ জবস, ওয়েব, এগিল, রিফ্যাক্টরিং, ওওপি, এওপি এবং আরও অনেক কিছুর উপহাস করেছেন। এটা একটা রসিকতা!

— আন্দ্রেস এফ

35

আমি প্রথমে এটি নুথের লেখার বইয়ে দেখেছি এবং ভেবেছিলাম এটি ঝরঝরে দেখাচ্ছে। তারপরে আমি প্রোগ্রামটিতে কী চলছে তা বোঝার জন্য সাহিত্য প্রোগ্রামিং ডিসপ্লেটি ব্যবহার করার চেষ্টা করেছি এবং এটি দেখতে তার চেয়ে কঠিন বলে মনে হয়েছে। এটি হতে পারে যে আমি প্রোগ্রামের তালিকাগুলির মধ্য দিয়ে যেতে অভ্যস্ত ছিলাম তবে এটি বিভ্রান্তিকর বলে মনে হয়েছিল seemed

তারপরে আমি সোর্স কোডটির দিকে চেয়েছিলাম এবং এটি আমাকে তখন এবং সেখানেই বন্ধ করে দিয়েছে। প্রোগ্রামের পাঠ্য এবং সংকলক যা দেখেছিল তার মধ্যে কম চিঠিপত্রের সাথে আমি পুরোপুরি নতুন উপায়ে প্রোগ্রামগুলি লিখতে শিখেছি এবং এর সাথে কোনও উপকার দেখেনি।

তদ্ব্যতীত, লোকেরা দীর্ঘ এবং দৃinc়প্রত্যয়ী যুক্তি লিখতে পারে যে কোডটি এক্সটি করছে যখন এটি আসলে ওয়াই করছে এবং আমি বিভ্রান্তিমূলক মন্তব্যগুলিতে আমার অংশ নিয়েছি। মোটামুটি তাড়াতাড়ি কী করছে তা দেখতে কোডটি পড়ার জন্য আমি আগ্রহ অনুভব করেছি। সাহিত্যের প্রোগ্রামিং হ'ল এর বিরোধী।

— ডেভিড থর্নলি
সূত্র

4

শিক্ষিত প্রোগ্রামিং, সেইসাথে সাধারণভাবে মন্তব্য, সম্পর্কে নয় কি আপনার কোড করছে। আপনি কোড থেকে এটি পড়তে পারেন। এটি কেন এবং কীভাবে হয় তার সব কিছুই , এবং এই অপরিহার্য তথ্যটি প্রায়শই একটি সঠিক শিক্ষিত প্রোগ্রামিং ছাড়াই অনুপস্থিত। " কেন? " অংশটি প্রায়শই বিস্তৃত এবং জটিল গণিত, কখনও প্লট এবং টেবিল, কখনও কখনও ডায়াগ্রাম জড়িত তা উল্লেখ করার প্রয়োজন নেই । পাঠ্য উপায়ে এ জাতীয় মন্তব্য বজায় রাখতে সাহিত্যের প্রোগ্রামিং সরঞ্জামগুলি প্রয়োজনীয়।

— এসকে-যুক্তি

1

@ এসকে-লজিক মেলা, তবে ডেভিড থর্নলি যে বিষয়টি তৈরি করছেন তা হ'ল এমনকি কেন ডাবলু বিভ্রান্তিকর মিথ্যা হতে পারে (এটি বোঝার পক্ষে আসলে আরও কঠিন)।

— মিঃফক্স

1

+1 নুথ প্রোগ্রামিংয়ের (বিষয়ভিত্তিক) বুনো পশ্চিমের দিনগুলিতে ফিরে লিখছিলেন যখন "উন্নত" ভাষায় কাজ করার অর্থ মেশিন কোড ব্যবহার না করে ধাতব উপরে প্রায় "সি" লেখা ছিল। মেমোরিটি এত টাইট ভেরিয়েবল ছিল এবং অন্যান্য নামগুলি কেবলমাত্র একক অক্ষর ছিল, প্রায়শই সুযোগ থেকে স্কোপে পুনরায় ব্যবহৃত হয়। প্রোগ্রামের বিশাল সংখ্যাগরিষ্ঠ যেখানে টার্ন-কী এক শট লিখেছেন এবং একটি নিজস্ব ব্যক্তিত্বের শৈলীতে একেক জন দ্বারা রক্ষণাবেক্ষণ করেছেন। একটি কোড বেস গ্রহণ করা পড়ার চেয়ে ডিক্রিপ্টিং ছিল। সাহায্য করার জন্য কোনও উত্স নিয়ন্ত্রণ ইত্যাদি ছিল না।

— টেকজেন

1

আজ থেকে 30 বছর আগে নূথ রাস্তাটি দেখছিলেন। তিনি জানতেন যে প্রোগ্রামগুলি আরও বড় হয়ে উঠবে, আরও জটিল হবে, শিফটিং সদস্যদের নিয়ে দলগুলি লিখবে, বছর বা দশক ধরে চলবে এবং ইনপুট, মূল্যায়ন এবং অবশেষে নন-প্রোগ্রামারদের কাছ থেকে গ্রহণযোগ্যতা প্রয়োজন require সাহিত্যের প্রোগ্রামিং সমস্ত সম্বোধনের জন্য একটি ধারণা ছিল। আমরা আজকে ব্যবসায় যুক্তি এবং বিডিডি বলে থাকি He মূল ধারণাটি হ'ল যে প্রোগ্রামাররা কী করতে হবে তা জানত এবং নন-প্রোগ্রামাররা সেগুলি অনুসরণ করতে পারে। যেমনটি উল্লেখ করা হয়েছে, ধারণাটি ব্যর্থ হয়েছে কারণ "साक्षিত" পাঠ্য এবং কোডের মধ্যে যোগসূত্র প্রয়োগের জন্য কোনও ব্যবস্থা নেই।

— টেকজেন

বিটিডাব্লু: এ কারণেই আমি ওজেক্টিভ-সি এর মতো "স্ব-ডকুমেন্টিং" ভাষা পছন্দ করি। প্রথমে কোডটি অযৌক্তিকভাবে দীর্ঘ পদ্ধতির নামগুলির সাথে বিশৃঙ্খলার উপায় দেখায়, তবে এমন কোনও প্রোগ্রামার যারা ভাষা বা এপিআই জানেন না তা কোড কী করছে তা দ্রুত ধাঁধা দিতে পারে। সর্বোপরি কোডটি এবং "মন্তব্যগুলি" সিঙ্কে স্বয়ংক্রিয়ভাবে পরিবর্তন করুন। অবশ্যই সে কারণেই অবজেক্টিভ-সি লেখা ছিল স্বতঃপূর্ন অন্তর্নির্মিত সাথে। এটি ছাড়া, অবজেক্টিভ-সি লেখা বেশ নরককর।

— টেকজেন

13

আমি নেটওয়ার্কের প্রভাবটিকে দোষ দেব । অন্যদের আপনার কোড এবং ডকুমেন্টেশন সম্পাদনা করার জন্য তাদের অবশ্যই এটি বুঝতে সক্ষম হতে হবে।

এটি লোকেদেরকে cweb / noweb এর মতো কিছু থেকে দূরে ঠেলে দেয় কারণ এগুলির ব্যবহারের জন্য আপনি প্রকল্পের জন্য যে প্রোগ্রামিং ভাষার ব্যবহার করছেন তার উপরে টেক্স এবং প্রোগ্রাম-নির্দিষ্ট সিনট্যাক্স শিখতে হবে। এটিকে সময়ের অপচয় হিসাবে দেখা যায়, বিশেষত যদি তাদের কোনও গণিতের টাইপসেটিংয়ের প্রয়োজন না হয় যা টেক্সের জন্য প্রথম দিকে এত বড় অঙ্কন। (এবং অনেক অ্যাপ্লিকেশন প্রোগ্রামারদের, তাদের সত্যই এটির প্রয়োজন হবে না)) পরিবর্তে তারা ভিজ্যুয়াল স্টুডিওর এক্সএমএল মন্তব্যের মতো কিছু পছন্দ করে, কারণ এটি ইতিমধ্যে জনপ্রিয় এবং সুপ্রতিষ্ঠিত।

আমি যে জায়গাগুলি সাক্ষর প্রোগ্রামিং প্রত্যাহার করে দেখেছি সেগুলি বৈজ্ঞানিক / পরিসংখ্যানগত কম্পিউটিংয়ে রয়েছে, যেখানে বেশিরভাগ প্রোগ্রামারগণ গণিত, সিএস বা পরিসংখ্যানগুলিতে উল্লেখযোগ্য প্রশিক্ষণ (ওরফে পিএইচডি) রাখেন এবং এভাবে ইতিমধ্যে লটেক্সের সাথে ফ্যামিলিয়ার রয়েছে। তারা যে ডকুমেন্টেশনটি লেখেন তাতে জটিল জটিল সূত্রগুলি অন্তর্ভুক্ত হওয়ার সম্ভাবনা রয়েছে যা টেক্সে সবচেয়ে ভাল লেখা হয় এবং তারা আর-তে প্রোগ্রামিং করার সম্ভাবনা বেশি থাকে program আর এস প্রোগ্রামারদের অনুপাত যারা এসওয়েভ সম্পর্কে জানে তারা অবশ্যই বলার চেয়ে অনেক বেশি say সি প্রোগ্রামার যারা অনুপাত সম্পর্কে জানে অনুপাত।

— ল্যারি ওয়াং
সূত্র

2

এই উত্তরটি ধরে নিয়েছে যে সমস্ত শিক্ষিত প্রোগ্রামিং সরঞ্জাম লটেক্স ব্যবহার করছে। এটা কি সত্য? ধারণাটি যা প্রয়োজন এটি সম্পর্কে কিছু আছে বলে মনে হয় না।

— এশেলি

@ শ্যাশলি: এটির প্রয়োজন নেই - আমি জানি যে এখনই কমপক্ষে আপনাকে এইচটিএমএল ব্যবহার করতে দেয়। তবে অনুশীলনে, যে সমস্ত মানুষ এইচটিএমএল ডকুমেন্টেশন লেখেন তারা সাক্ষরিত প্রোগ্রামিং সরঞ্জামগুলির পরিবর্তে জাভাদোক এবং এই জাতীয় ব্যবহার করবেন।

— ল্যারি ওয়াং

1

@ শ্যাশলি, সাক্ষরিত প্রোগ্রামিংয়ের কাজ করার জন্য, আপনাকে মুদ্রণের জন্য দস্তাবেজ তৈরি করতে সক্ষম হতে হবে। এই অনেক, অনেক সহজ যখন বিন্যাস পাঠ্য-ভিত্তিক, এবং আমার জ্ঞান সবচেয়ে শক্তিশালী পাঠ্য-ভিত্তিক ডকুমেন্ট ফরম্যাটার হয় TeX, আর টেক্স লেটেক্ ব্যবহার করছে এর সাথে কাজ করা সবচেয়ে সহজ উপায়।

@ শ্যাশলি আপনি সাক্ষরিত org-modeপ্রোগ্রামিংয়ের জন্য সমর্থনগুলি একবার দেখে নিতে পারেন । এটা বেশ সুবিধাজনক, এবং আমি এটা খুঁজে অনেক (যদিও উল্লেখ করতে হৃদয়ঙ্গম করা সহজ পরিচালনা ) ওয়েব বা NOWEB একা থাকে। কোডের একটি গুরুত্বপূর্ণ বিষয় হ'ল পাঠযোগ্যতা এবং এটি পঠনযোগ্য। (সিএফ github.com/vermiculus/stack-mode )

— শন অলরেড

12

পড়াশুনা করার সময় 90-এর দশকের শেষের দিকে আমি লিটারেট প্রোগ্রামিংয়ের ধারণাটি দেখে মুগ্ধ হয়েছি এবং আমি এখনও প্রোগ্রামিং, এবং টাইপসেটিংয়ের জন্য নুথের পদ্ধতির সাথে আগ্রহী। সেরা কিছুই করবে না।

লিখিত সাহিত্যের প্রোগ্রামিং সিস্টেম যা নুথ ডিজাইন করেছিলেন তা তাত্ক্ষণিকভাবে চোখের সাক্ষাত হওয়ার চেয়ে অনেক বেশি, অর্থাত্ অন্তর্নিহিত প্রোগ্রামিং ভাষায় এমন অনেকগুলি ত্রুটিগুলি কাটিয়ে উঠেছে যা নথস উত্স নথি থেকে উত্পন্ন কোড জেনারেশন সরঞ্জাম, স্ট্যান্ডার্ড পাস্কাল।

ভাগ্যবানদের জন্য যারা স্ট্যান্ডার্ড পাস্কালটি ব্যবহার না করে, তাদের জন্য এখানে কয়েকটি হাইলাইট দেওয়া আছে।

একক-পাস সংকলকটি সহজতর করার জন্য, ভাষা স্পেসিফিকেশন বলেছে যে সমস্ত ঘোষণা একটি নির্দিষ্ট ক্রমে আসতে হয়েছিল। উইকিপিডিয়া পৃষ্ঠা থেকে: "প্রতিটি প্রক্রিয়া বা ফাংশনটির গোটো লেবেল, ধ্রুবক, প্রকার, ভেরিয়েবল এবং অন্যান্য পদ্ধতি এবং ক্রিয়াগুলির নিজস্ব ঘোষণা থাকতে পারে, যা অবশ্যই এই ক্রমে থাকা উচিত" " এর অর্থ আপনি উত্স ফাইলে যৌক্তিকভাবে আপনার জিনিসগুলি গোষ্ঠীভুক্ত করতে পারবেন না ।
স্ট্রিং হ্যান্ডলিং প্লেইন সি এর চেয়ে বেশি ক্লান্তিকর ছিল in
শনাক্তকারীদের নির্বিচারে দৈর্ঘ্য থাকতে পারে না।
আরও অনেক কিছুই আমি আর মনে করতে পারি না।

এই সমস্ত বিষয়গুলির মূলত অর্থ হ'ল নথের আরও ভাল প্রোগ্রামিং ভাষার প্রয়োজন ছিল (সুতরাং তিনি একটি আবিষ্কার করেছিলেন) এবং এটি পাস্কালকে এর সমাবেশের ভাষা হিসাবে ব্যবহার করেছিল।

বেশিরভাগ আধুনিক ভাষাগুলি খুব বেশি প্রচেষ্টা ছাড়াই এই জিনিসগুলি করতে পারে, সুতরাং লিটারেট প্রোগ্রামিংয়ের যে কাজটি সমাধান করা উচিত ছিল তার একটি বড় অংশ সরিয়ে ফেলুন।

এছাড়াও আধুনিক ভাষাগুলি আরও ভাববাদী যা আরও বেশি চিন্তাভাবনা কোডে রাখে।

তো, কী বাকি? সোর্স কোড থেকে ডকুমেন্টেশন একটি typeset ফর্ম জেনারেট করতে ক্ষমতা এবং যে আজ বিদ্যমান।

জাভাডোকটি মনে করুন - জাভা রানটাইম এপিআই সম্ভবত আজ লিটারেট প্রোগ্রামিংয়ের বৃহত্তম টুকরা উপলব্ধ (কোডটি প্রকৃতপক্ষে উপস্থাপন করা ব্যতীত, তবে জাভা শুরু থেকেই খোলা স্রোত থাকলে এটিই ছিল)। উদাহরণস্বরূপ দেখুন http://download.oracle.com/javase/6/docs/api/java/util/ Collections.html এ সংগ্রহের কাঠামোর উপস্থাপনা দেখুন

আমি বিশ্বাস করি। নেট এবং অন্যান্য মূলধারার প্রোগ্রামগুলির জন্য একই রকম সিস্টেম বিদ্যমান।

To make it possible to have a single-pass compiler, all declarations had to come in a certain order. এর মতো একটি ঘোষণার আদেশ অবশ্যই সংকলক ডিজাইনকে সহজতর করে তবে এটি একক-পাস সংকলন সক্ষম / প্রতিরোধ করে না। উদাহরণস্বরূপ, ডেলফির সেই আদেশের সীমাবদ্ধতা নেই, তবে এটি এখনও কঠোরভাবে একক-পাস পাস্কাল সংকলক।

— ম্যাসন হুইলারের

একমত। টার্বো পাসকালেরও এই বাধা ছিল না। তবে নোট করুন, এই সীমাবদ্ধতা শুরু থেকেই পাস্কেলের সংজ্ঞা ছিল।

1

নাহ, নুথ অনেক আগে সিডব্লিউইবিতে স্যুইচ করেছে, এটি পাস্কলের ঘাটতিগুলি সমাধান করার বিষয়ে নয়। নাহ, জাভাডকের নুথের "সাক্ষর প্রোগ্রামিং" এর সাথে কোনও সম্পর্ক নেই - তিনি কীভাবে কোড তৈরি করেন তা মৌলিকভাবে পরিবর্তনের বিষয়ে কথা বলছেন , এবং দাবি করেছেন যে তাকে জটিলতা মোকাবেলায় মঞ্জুরি দেয় যে অন্যথায় তাঁর পক্ষে বা অন্য কারও পক্ষে কাজ করা সম্ভব হবে না।

— রন বার্ক

@ রনবার্ক সিডব্লিউইবি কেবল একটি আরও ভাল "অ্যাসেম্বলি ভাষার" সংকলন করেছে। এটি মূল নকশার সিদ্ধান্তগুলিকে অকার্যকর করে না।

— থরবজর্ন রাভন অ্যান্ডারসন

5

নব্বইয়ের দশকে আমি যখন সাক্ষর প্রোগ্রামিংয়ের সাথে আমার ঝাপটায় পড়েছিলাম তখন আমি একটি জিনিস আবিষ্কার করেছিলাম এটি হ'ল খুব আবেগপ্রবণ লোকদের প্রতি আকৃষ্ট করেছিল যারা সঠিকভাবে সঠিক জিনিসটি করতে চেয়েছিল - এবং এতে তাদের নিজস্ব সাক্ষরিত প্রোগ্রামিং সিস্টেম লেখার সাথে জড়িত ছিল কারণ তাদের পক্ষে বিদ্যমান কোনওটিই যথেষ্ট ভাল ছিল না। প্রত্যেকের জন্য যথেষ্ট পরিমাণে সাধারণতম ডিনোমিনেটর সরবরাহ করে এখনই কেটে ফেলার একটি ভাল প্রচেষ্টা ছিল, যদিও তারপরেও আমি আমার বেশিরভাগ এলপি সময়টির জন্য একটি প্রিন্ট-প্রিন্টার তৈরি করতে ব্যয় করেছি ...

আরেকটি বিষয় হ'ল এটি সত্যই চঞ্চলবিরোধী। কিছু উপায়ে, ধীর হয়ে যাওয়া ভাল কারণ এটি আপনাকে আরও বেশি মুখোমুখি চিন্তা করতে এবং জিনিসগুলি প্রথমবারে পেতে বাধ্য করে। অন্যদিকে, সাবধানতার সাথে ডকুমেন্ট করার সময় আপনার কোডটি রিফ্যাক্টর করার ক্ষেত্রে একটি বড় বাধা রয়েছে। এবং যদি আপনি এলপি-ইফির আগে আপনার কোডটিকে কঠোর না করা পর্যন্ত অপেক্ষা করেন তবে আপনি একটি বহু দিনের ডকুমেন্টেশন টাস্কটি শেষ করেন, যা আপনাকে সত্যই আপনার ট্র্যাকগুলিতে থামিয়ে দিতে পারে।

— dfan
সূত্র

পরীক্ষার পরে আমি দেখতে পেয়েছি যে আমাদের বাকিদের জন্য এলপির মিষ্টি স্পটটি প্রকৃত কোডের ঠিক পরের নকশার সিদ্ধান্ত এবং আর্কিটেকচারের বিবরণ ডকুমেন্টিংয়ে থাকতে পারে । আমি এলপিকে চুল্লী করা শক্ত হওয়ার সাথে একমত। এটা আমার বোঝা যায় যে নথ প্রাথমিক নকশাটি কাগজে তৈরি করেছিলেন এবং কেবল সন্তুষ্ট হলেই বাস্তব বাস্তবায়ন শুরু হয়েছিল। এটি সম্ভবত আমার জন্য কাজ করে এমন একই পরিস্থিতি।

— থরবজর্ন রাভন অ্যান্ডারসন

3

আমার নম্র মতামত অনুসারে, অনেক সংস্থার একটি সংস্কৃতি রয়েছে যারা লিট্রেট প্রোগ্রামিংয়ের লক্ষ্যগুলির বিপরীতে: তারা দ্রুত ফলাফল চায় (অ্যাপটি উত্পাদনশীল অবস্থায় তারা কেবল মানের বিষয়ে কাঁদে)। আমার নিজের অভিজ্ঞতায়, আমার কর্তারা তা বুঝতে অস্বীকার করেছিলেন যে দ্রুত ফলাফলের অর্থ "আমার কাছে জিজ্ঞাসার পরের দিন একটি প্রোগ্রাম চলমান" নয়। তাদের জন্য, যদি কোনও বিকাশকারী তার কীবোর্ডে টাইপ করতে ব্যস্ত না হন, তবে তিনি কাজ করছেন না, তিনি "ডিজাইন-অ-বুদ্ধিতে তার সময় নষ্ট করছেন"। হ্যাঁ, আমি জানি, আমার বস একটি আর্সহোল।

— Nisanio
সূত্র

তারপরে লিটারেট প্রোগ্রামিংয়ের সাথে তারা ভাবতে পারে আপনি এখনও-অন্য-সফটওয়্যারটির পরিবর্তে সায়েন্স-ফাই বুক লিখতে ব্যস্ত! : ডি

— মাহদি

এর মতো সংস্থাগুলি বুঝতে পারে না যে ভাল সফ্টওয়্যারটি খুব দীর্ঘ সময় বেঁচে থাকে এবং উত্সটির পক্ষে আরও ভাল ডকুমেন্টেশন।

— থর্বজর্ন রাভন অ্যান্ডারসন

2

কোডাররা ইংরেজী নয় কোড লেখেন।

কোডার্স ডকুমেন্টেশন লিখতে পছন্দ করেন না কারণ এটি কোড চালাতে সহায়তা করে না।

কোডার ডকুমেন্টেশন লিখতে ভাল নয় কারণ এটি তাদের মতামত প্রকাশের জন্য একটি দুর্বল মাধ্যম।

সাহিত্যের প্রোগ্রামিংটি পরবর্তী স্তরে ডকুমেন্টেশন নেওয়ার ধারণা বলে মনে হচ্ছে যেখানে কোডটি চিন্তা-ভাবনার পরে বেশি। সম্ভবত এটি কাজ করবে তবে বেশিরভাগ কোডারের কাছে এটি অদৃশ্য ডকুমেন্টেশনের মতো দেখাচ্ছে।

— উইনস্টন ইওয়ার্ট
সূত্র

29

আপনি বর্ণিত পয়েন্টগুলি মেনে চলেন এমন কোডাররা কোডার নয় যা আমি আমার সাথে কাজ করতে চাই।

— পল নাথান

1

@ পল, মঞ্জুর। তবে সেখানে আসলে কী আছে। তবে এটি আমার কাছে মনে হয়েছে যে আরও ডকুমেন্টেশনগুলি আরও ভাল নয়।

— উইনস্টন ইওয়ার্ট

1

যথেষ্ট সম্ভবত সেরা

— mlvljr

6

অভিজ্ঞ প্রোগ্রামাররা জানেন যে তাদের ডকুমেন্টেশন লেখার দরকার আছে কারণ সেখানেই "কেন আমি এটি এরকম করলাম" যায়।

1

@ থরবজর্ন রাভন অ্যান্ডারসন, হ্যাঁ এটি সত্য। কিন্তু সাক্ষরিত প্রোগ্রামিং, (আমি যেমন এটি বুঝতে পারি) আপনাকে পরামর্শ দেয় যে আপনি আপনার কোডের সাথে ডকুমেন্টেশনের পরিবর্তে আপনার ডকুমেন্টেশনের সাথে কোড লিখবেন। এটি কি অনেক ডকুমেন্টেশন সত্যই সহায়ক?

— উইনস্টন ইওয়ার্ট

2

মূলত কারণ মানুষেরা খুব বোকা। স্পষ্ট সাক্ষ্য হ'ল এই সাধারণ কৌশলটির প্রকৃতি সম্পর্কে তরুণরা অনুমান করা এবং ভুল বোঝাবুঝির অন্তহীন প্রবাহ।

লোকজন এলপিকে গ্রহণ করে: (ক) ডকুমেন্টেশনের একটি পদ্ধতি (খ) কিছু পালিশ রচনা লেখার একটি পদ্ধতি যা কিছু বিশেষ দক্ষতা বা দক্ষতার প্রয়োজন হয় (গ) কেবল তার কোনও ক্লু নেই - লিও প্রোগ্রামিং সম্পাদকের স্রষ্টা হিসাবে, তার নিজের স্বীকৃতি দ্বারা ইত্যাদি ইত্যাদি ইত্যাদি

এলপি অবশ্য সহজভাবে: (1) মানব ভাষাতে কোড এবং বাক্যাংশের মিশ্রণে প্রোগ্রামগুলি লেখার জন্য, যেখানে পরবর্তী কোডগুলি এবং / অথবা অন্তর্ভুক্ত বাক্যাংশের জন্য রয়েছে। সংক্ষিপ্ত প্রোগ্রামিং পাঠ্যপুস্তকের লেখকরা ঠিক এটিই করেন এবং .. (2) এটি একটি সাধারণ প্রিপ্রেসেসর যা মানুষের সেই বাক্যাংশগুলিকে প্রসারিত করে (যা অন্তর্ভুক্ত সাব্রোটাইনগুলির নাম হিসাবে পরিণত হয়েছিল) ফলাফলটি কম্পিউটারের মাধ্যমে আবশ্যকভাবে উন্মোচন করতে পারে (বা অনুবাদক)। অন্যথায় কেউ "স্বাক্ষর উত্স" কে একটি ভাল-বিন্যাসযোগ্য পাঠযোগ্য পাঠ্যে রূপান্তর করতে ফর্ম্যাটিং প্রতীকগুলি অন্তর্ভুক্ত করার জন্য লিখিত পাঠ্যটিকে অন্য একটি ছোট্ট ইউটিলিটি সহ প্রসারিত করতে পারেন।

তরুণরা কখনও এই অত্যন্ত সহজ ধারণাটি ব্যবহার করে না - এবং কল্পনা করেই বা ভুয়া কারণগুলির কল্পনা করে কেন তারা কখনই চেষ্টা করে না বা করবে না।

মূলত একটি মানব ভাষায় লিখিত "ইন সিউডোকোড" প্রোগ্রামিংয়ের মূল ধারণা এবং তারপরে একটি সাধারণ প্রিপ্রোসেসর ইউটিলিটি হেল্পস ম্যানেজমেন্ট এন্টিটিশন (সীমিত, যে কোনও দীর্ঘস্থায়ী প্রোগ্রামের জন্য একটি প্রধান অসুবিধা) এর সাহায্যে এটি প্রসারিত করার মূল ধারণা, আপনার কোড ফোল্ডিং বা আপনার প্রোগ্রামের প্রবাহের বিভাজনের মতো আপনার নিজের বিবরণে না হারাতে প্রয়োজন, তবে মেশিনের সঞ্চালনের জন্য সম্পূর্ণ অপ্রয়োজনীয় ফাংশন / সাবরুটাইনগুলিতে।

3

আপনি একটি গুরুত্বপূর্ণ বিট নিখোঁজ রয়েছেন: (3) যে কোনও ভাষাতে কোনও কোডকে সর্বাধিক পঠনযোগ্য এবং প্রাকৃতিক অনুক্রমের মধ্যে পুনরায় অর্ডার করার একটি উপায়, যা সংকলককে একই আদেশের সাথে মোকাবিলা করতে হবে তা অগত্যা নয়। এর মধ্যে রয়েছে পাদটীকাগুলিতে বা কোডের বাহ্যরেখা থেকে দূরে যেখানেই বাস্তবায়নের বিশদটি গোপন করা।

— এসকে-যুক্তি

1

সেখানে শিক্ষিত প্রোগ্রামিং এর 2 দিক যে, আমি হয় না অভিলাষও অবশিষ্ট মূলধারার প্রোগ্রামিং মধ্যে গ্রথিত হয়ে যায় - এম্বেড চিত্রাবলী (যেমন, নকশা ডায়াগ্রামে) এবং পূর্ববর্তী এবং বিকল্প প্রচেষ্টা (পয়েন্টার যেমন, "কারণ এটা ভালো হয়, কারণ আমি এই অন্য উপায় চেষ্টা এবং এটি কার্যকর হয়নি কারণ ... ")। এই উভয় দিকই ডক-মন্তব্য এবং ইউআরআই দিয়ে পরিচালনা করা যায়।

— ল্যারি ওব্রায়েন
সূত্র

1

কারণ প্রোগ্রামগুলির লজিক আমাদের কথা মতো কাজ করে না। একটি প্রোগ্রামের একটি ভাল নির্দিষ্ট প্রবাহ এবং শর্তাদি এবং লুপ রয়েছে।

প্রচুর কোডিং করার পরে, আমি এই পদগুলিতে ভাবি। আমার মস্তিষ্ক সমস্যাগুলি এক্সিকিউটেবল কোডের লক্ষ্য ডোমেনে রূপান্তর করে। আমার প্রোগ্রামগুলি সাক্ষর করতে অতিরিক্ত রূপান্তর পদক্ষেপ না করে আমার কাছে সাধারণত একটি প্রোগ্রামিং ভাষায় এটি লেখার পক্ষে আরও দক্ষ is

প্রকৃতপক্ষে, আমি বিশ্বাস করি যে আমার প্রোগ্রামগুলি ইতিমধ্যে শিক্ষিত ... স্পিকার শনাক্তকারী, ভাল ফাংশন নাম, মন্তব্য যেখানে আমি কিছু হ্যাকারি করেছি যা আমি কয়েক মাস পরে তত্ক্ষণাত নিজেই বুঝতে পারি না।

উপসংহারে: প্রতিটি "সাক্ষর" প্রোগ্রামিং যেমন চায় তেমনভাবে আমার জাভা কোডটি আরও স্বাক্ষরিত।

— ড্যানিয়েল
সূত্র

2

একটি জাভা কোড শিক্ষিত হতে পারে না। আপনার "স্পিকিং আইডেন্টিফায়ার্স" কখনই ব্যাখ্যা করবেন না আপনি কেন এই নির্দিষ্ট অ্যালগরিদমকে অন্যের চেয়ে বেছে নিয়েছেন, সীমাবদ্ধতাগুলি কী, আপনার পারফরম্যান্স প্রোফাইলের প্রত্যাশা কী ছিল ইত্যাদি lite ইংরেজি পাঠ্য তবে এগুলি সমস্ত একটি কোডে প্রকাশ করা যায় না এবং সাধারণ মন্তব্যের ভিতরে কুৎসিত দেখা যায় না।

— এস কে-যুক্তি

1

আমি অন্যান্য উপায়ে প্রোগ্রামিংকে সাক্ষর করতে এসেছি - আমি স্বপ্ন দেখেছিলাম যে কোডটি আমার মনের সাথে খাপ খায় এমনভাবে সংগঠিত করে, সংকলকটির এটির প্রয়োজন হয় না। আমি লিওকে এই উদ্দেশ্যে প্রায় আদর্শ বলে মনে করেছি। এটি বাইরে পরিবর্তিত ফাইলগুলির ট্র্যাক রাখতে সহায়তা করে। এই ফাইলগুলিতে কোনও বিশেষ মার্কআপ থাকতে হবে না, তাই আমি টিমের অন্যদের জানার দরকার ছাড়াই নিজের জন্য লিওটি ব্যবহার করতে পারি। এই বৈশিষ্ট্যটি - "@ শ্যাডো ট্রি" - খুব আশাব্যঞ্জক, যদিও এখনও কিছুটা বগিযুক্ত, আরও চোখের বলের প্রয়োজন। এবং এটি গাছের রূপরেখায় এবং বাহ্যিক ফাইলগুলির জন্য সমর্থন দ্বারা সবকিছুকে সংগঠিত করে "ওহ, না, একটি বড় ফাইলের সবকিছু" সমস্যা উভয়ই সমাধান করে।

আমার কাছে, নামের বিপরীতে, "লিট্রেট প্রোগ্রামিং" ডকুমেন্টেশন মোটেই নয়। আমার কাছে আগের চেয়ে বেশি ডকুমেন্টেশন নেই। এটি এমন কাঠামো থাকার কথা যা আমাকে হারিয়ে যেতে না সহায়তা করে । আমি এর শপথ করছি বিশেষত বেহমথ জেএসপি ফাইলগুলি পরিচালনা করার সময় (এবং যে লিও সত্ত্বেও মূলত পাইথনের উদ্দেশ্যে ছিল এবং এটি জেএসপি ভাষার পক্ষে সমর্থন করে না - আমাকে ফাইলটি নিজেই লিও ট্রিতে বিভক্ত করতে হবে!)।

— Juraj
সূত্র

0

আমি এটিকে একটি মূল্যবান শিক্ষণীয় সরঞ্জাম হিসাবে দেখছি, যেখানে কোডের উপর একটি গবেষণামূলক লিখন লেখা যেতে পারে এবং তারপরে কোডটির কীভাবে, কী এবং কী হবে তা পাঠকদের নির্দেশ দেওয়ার জন্য এতে ওয়ার্কিং কোডের স্নিপেট।

খাঁটি শিক্ষামূলক পরিবেশের বাইরে, আমি মনে করি কেবল নথই এটি ব্যবহার করবেন কীভাবে সেরা তা বুঝতে পারে।

— greyfade
সূত্র

-4

এটি সমস্ত বিশ্বের সবচেয়ে খারাপ - আপনাকে একটি খুব অ-নির্দিষ্ট ভাষা = ইংরেজিতে একটি অত্যন্ত সঠিক, অত্যন্ত নির্দিষ্ট কম্পিউটার প্রোগ্রাম লিখতে হবে। সুতরাং আপনাকে সঠিক বাক্যাংশটি ব্যবহার করে সাবধানতার সাথে এটি লিখতে হবে - যাতে আপনি কেবল কোড লিখতে পারেন।

— মার্টিন বেকেট
সূত্র

3

আপনার কোডটি ইংরেজীতে পুনরাবৃত্তি করা উচিত নয়। মন্তব্যগুলি কোডটি কেন করছে তার কারণ নয় কেন তা ব্যাখ্যা করতে হবে। আমি প্রায়শই আমার সাক্ষর মন্তব্যে গ্রাফ, ডায়াগ্রাম এবং প্লটগুলি স্টাফ করি এবং এটি কোডটি সত্যই বুঝতে সহায়তা করে।

— এসকে-যুক্তি

যদি মন্তব্যগুলি কোডটি কী করছে তা না বলে তবে এটি কীভাবে শিক্ষিত প্রোগ্রামিং - এটি কেবল মন্তব্য সহ নিয়মিত প্রোগ্রামিং। আমি ভেবেছিলাম সাক্ষরিত প্রোগ্রামিংয়ের পুরো বিষয়টি ডক্সে প্রোগ্রামটি বর্ণনা করা এবং ডকুমেন্টেশন থেকে সিস্টেমটি কোড উত্পন্ন করা উচিত?

— মার্টিন বেকেট

3

"টেক্স, প্রোগ্রাম" পড়ার চেষ্টা করুন। কোড কখনও মন্তব্যে পুনরাবৃত্তি হয় না। মন্তব্যগুলি কেন কোডটি সেভাবে লেখা হয় তা ব্যাখ্যা করে এবং আর্কিটেকচারটি ব্যাখ্যা করে।

— এসকে-যুক্তি 19

3

@ মার্টিনবেকেট আপনি যা বর্ণনা করেছেন তা এলপি নয়।

— আন্দ্রেস এফ