একটি প্রোগ্রামিং ভাষা পিছনে সামঞ্জস্যপূর্ণ বনাম এর ত্রুটিগুলি স্থির রাখুন


56

প্রথমে কিছু প্রসঙ্গ (এমন জিনিস যা আপনার বেশিরভাগরাই জানেন):

প্রতিটি জনপ্রিয় প্রোগ্রামিং ভাষার একটি স্পষ্ট বিবর্তন থাকে, বেশিরভাগ সময় এর সংস্করণ দ্বারা চিহ্নিত করা হয়: আপনার জাভা 5, 6, 7 ইত্যাদি রয়েছে, পিএইচপি 5.1, 5.2, 5.3 ইত্যাদি। নতুন সংস্করণ প্রকাশের ফলে নতুন এপিআই উপলব্ধ হয়, বাগগুলি সংশোধন করা হয়, যোগ হয় নতুন বৈশিষ্ট্য, নতুন ফ্রেমওয়ার্ক ইত্যাদি তাই সব মিলিয়ে: এটি ভাল।

তবে ভাষার (বা প্ল্যাটফর্মের) সমস্যাগুলি কী? যদি এবং যখন কোনও ভাষায় কোনও সমস্যা হয়, তবে বিকাশকারীরা হয় এড়িয়ে চলে (যদি তারা পারে) অথবা তারা এটির সাথে থাকতে শিখবে।

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


আমি আমার প্রশ্নটির সর্বোত্তম উপায়টি উদাহরণ হিসাবে পিএইচপি ব্যবহার করতে পারি:

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

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

আমি যা বুঝতে পারি না তা হ'ল: কেন আমি পিএইচপি পিছন দিকে সামঞ্জস্যপূর্ণ রাখতে পারি? যদি আমি এই সমস্ত সমস্যার সংশোধন করে পিএইচপি 8 সংস্করণ প্রকাশ করি তবে আমি কী এটির উপরে একটি বড় সতর্কতা বলতে পারি না: "এই সংস্করণে পুরানো কোডটি চালাবেন না!"?

অবচয় বলে একটি জিনিস আছে। আমাদের এটি বছরের পর বছর ধরে ছিল এবং এটি কাজ করে। পিএইচপি প্রসঙ্গে: দেখুন কীভাবে এই দিনগুলিতে লোকেরা সক্রিয়ভাবে mysql_*ফাংশনগুলির ব্যবহারকে নিরুৎসাহিত করে (এবং পরিবর্তে mysqli_*পিডিওর প্রস্তাবনা দেয় )। অবচয় কাজ করে। আমরা এটি ব্যবহার করতে পারি। আমাদের এটি ব্যবহার করা উচিত। এটি যদি ফাংশনগুলির জন্য কাজ করে তবে এটি কেন সম্পূর্ণ ভাষার জন্য কাজ করবে না?

আসুন আমি (পিএইচপি এর বিকাশকারী) এটি করি:

  • এই সমস্ত ত্রুটিগুলি স্থির করে পিএইচপি (নতুন করে 8 বলা যাক) এর একটি নতুন সংস্করণ চালু করুন
  • নতুন প্রকল্পগুলি সেই সংস্করণটি ব্যবহার করা শুরু করবে, কারণ এটি আরও ভাল, পরিষ্কার, আরও সুরক্ষিত ইত্যাদি etc.
  • তবে, পিএইচপি-র পুরানো সংস্করণগুলি বর্জন না করার জন্য, আমি এটিতে আপডেটগুলি অবিরত করে রাখি, সুরক্ষা সংক্রান্ত সমস্যাগুলি, বাগগুলি সংশোধন করে রাখি reasons এটি এখানে কারণগুলির তালিকা না রাখার কারণে বোঝা যায়। এটি সাধারণ অনুশীলন: উদাহরণস্বরূপ দেখুন কীভাবে ওরাকল মাইএসকিউএল এর 5.1.x সংস্করণ আপডেট করে রেখেছিল, যদিও এটি বেশিরভাগ সংস্করণ 5.5.x তে নিবদ্ধ ছিল।
  • প্রায় 3 বা 4 বছর পরে, আমি পিএইচপি-র পুরানো সংস্করণগুলি আপডেট করা বন্ধ করি এবং সেগুলি মরে যেতে দেব। এটি ঠিক আছে, যেহেতু এই 3 বা 4 বছরে, বেশিরভাগ প্রকল্পগুলি যাইহোক পিএইচপি 8 এ স্যুইচ করবে।

আমার প্রশ্নটি: এই সমস্ত পদক্ষেপগুলি কী বোঝায়? এটা কি এত কঠিন হবে? যদি এটি করা যায়, তবে কেন এটি করা হয় না?

হ্যাঁ, খারাপ দিকটি হ'ল আপনি পিছনে সামঞ্জস্যতা ভেঙেছেন। কিন্তু যে মূল্য দেওয়ার মতো মূল্য নেই? উত্সাহ হিসাবে, 3 বা 4 বছরে আপনার এমন একটি ভাষা থাকবে যার 90% সমস্যা স্থির হয়েছে .... এমন একটি ভাষা যা কাজ করার জন্য আরও সুখকর। এর নাম এটির জনপ্রিয়তা নিশ্চিত করবে।

সম্পাদনা : ঠিক আছে, তাই আমি নিজেকে সঠিকভাবে প্রকাশ করি নি যখন আমি বলেছিলাম যে 3 বা 4 বছরে লোকেরা অনুমান পিএইচপি 8 এ চলে যাবে 8 আমার অর্থটি ছিল: 3 বা 4 বছরে লোকেরা পিএইচপি 8 ব্যবহার করবে যদি তারা একটি শুরু করে তবে নতুন প্রকল্প.


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

5
... আমি এও মনে করি যে আপনি যে পরিমাণ কোডটি পোর্ট করা উচিত, যে পরিমাণ জিনিসগুলি ভেঙে যাবে, তৃতীয় পক্ষের নির্ভরতার পরিমাণকে মানিয়ে নেওয়ার জন্য ইত্যাদিকে
কম মূল্যায়ন করবেন

12
" মার্টিয়ান হেডসেটস " সম্পর্কে জোয়েল স্পলস্কির এই দুর্দান্ত ব্লগ পোস্ট joelonsoftware.com/items/2008/03/17.html প্রতিটি বিকাশকারী যারা পিছনের সামঞ্জস্যের গুরুত্বকে অবমূল্যায়ন করে তাদের জন্য বাধ্যতামূলক হওয়া উচিত।
ডক ব্রাউন

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

20
পাইথন ২.x => পাইথন ৩.x হ'ল একটি ভালভাবে ডিজাইন করা ভাষা থেকে অন্যটিতে পরিবর্তিত, কিছুটা উন্নততর নকশাকৃত ভাষা, যা অনেকগুলি বেমানান কন্সট্রাক্টসকে স্বয়ংক্রিয়ভাবে পরিবর্তনের জন্য প্রথম পক্ষ সমর্থন করে। তাদের মধ্যে পোর্টিং কোডটি প্রায় সহজ হিসাবে আপনি দুটি ভাষার মধ্যে পরিবর্তন করতে পারেন। পাই 3 কে এখনও খুব ধীরে ধীরে স্থল লাভ করছে।
ফোশি

উত্তর:


25

এটি দুর্দান্ত শোনাচ্ছে, তবে বাস্তবে খুব কমই কাজ করে; লোকেরা চলমান কোড পরিবর্তন করতে অত্যন্ত অনিচ্ছুক, এবং নতুন, সবুজ-ক্ষেত্র প্রকল্পগুলির জন্যও তারা ইতিমধ্যে জানে এমন ভাষা / সংস্করণ থেকে পথ পরিবর্তন করতে খুব অনিচ্ছুক।

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

(স্পষ্টতই, এর বেশিরভাগটি কেবল শখের দ্বারা রচিত প্রকল্পগুলিতে প্রয়োগ হয় না কেবল তাদের নিজের সন্তুষ্টির জন্য here )


65

আপনি পিছনের সামঞ্জস্যের প্রভাবকে অবমূল্যায়ন করছেন; আপনার অনুমান যে সমস্ত সক্রিয় প্রকল্পগুলি 3 বা 4 বছরে স্থানান্তরিত হবে তা অনেক বেশি আশাবাদী।

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

  • আমাকে পিএইচপি 8 এর জন্য আমার কোড আপডেট করতে সময় ব্যয় করতে হবে That's এই সময়টি আমি গ্রাহকের অনুরোধের প্রতিক্রিয়া জানাতে, নতুন বৈশিষ্ট্যগুলি প্রয়োগ করে, প্রতিযোগিতা অব্যাহত রাখতে ব্যয় করতে পারি।
  • এমনকি আমি এটি করার পরেও, আমার কোডটিতে বাগগুলি প্রবর্তন করে কোনও কোণার কেস বা অপ্রত্যাশিত সামঞ্জস্যতা সমস্যাটি মিস করেছি এমন একটি ভাল সুযোগ রয়েছে।

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

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


8
চমকপ্রদ সংখ্যক সিওবিএল অবস্থান খোলা রয়েছে, বিশেষত পুরানো বীমা সংস্থাগুলির সাথে ওও
চাদ হ্যারিসন

1
@ জোশ কেলি: আমি আপনার সাথে একমত হই তবে আমি মনে করি যে এই সমস্যাগুলি কেবলমাত্র সেই ভাষাগুলিকেই প্রভাবিত করে যেখানে আপনি স্পষ্টতই নতুন কোড থেকে লিগ্যাসি কোডটি পৃথক করতে পারবেন না, যেমন পাইথন, পিএইচপি কারণ আপনার লাইব্রেরি এবং সি ++ (টেম্পলেট) অন্তর্ভুক্ত করা দরকার। ভিন্ন সংকলন মডেল সহ ভাষা (যেমন জাভা, স্কালা, ক্লোজার) দেখায় যে দুটি কোড উত্স কোডের স্তরে সামঞ্জস্যপূর্ণ না হলেও লিগ্যাসি কোডে (যেমন জাভাতে) নতুন কোড যুক্ত করা সম্ভব to
জর্জিও

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

7
@tieTYT - কিছু প্রোগ্রামিং ল্যাঙ্গুয়েজ এটি করে - পাইথনের 2to3 বা গো এর গফিক্স দেখুন ( টকস.গোলাং.আর.জি . 2 / স্প্ল্যাশ.স্লাইড # 68 )। এটি অবশ্যই পুরানো বৈশিষ্ট্যগুলি হ্রাস করার ক্ষেত্রে সহায়তা করে, তবে ভাষা শব্দার্থক পরিবর্তন হলে সফ্টওয়্যার অন্যান্য সফ্টওয়্যারটি কতটা ভালভাবে বুঝতে এবং আপডেট করতে পারে তার সীমাবদ্ধতা রয়েছে।
জোশ কেলি

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

17

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

একটি উদাহরণ জন্য অজগর তাকান। 3.x চার বছরের জন্য উপলব্ধ, এবং এখনও ব্যাপকভাবে গৃহীত হয় না। লোকেরা একে একে নতুন প্রকল্পের জন্য ব্যবহার করার চেষ্টা করে, তবে আমি মনে করি আপনি ঠিক কত কোডের কাজ রক্ষণাবেক্ষণ করছেন তা অবমূল্যায়ন করছেন।

অবশ্যই, বেশিরভাগ মানুষ পাইথন 2.x কে "ত্রুটিযুক্ত" বলে মনে করেননি। তাদের পিএইচপি ব্যবহারকারীদের মতো অভিযোগ নেই। পিএইচপি অনেক বেশি অনিশ্চিত অবস্থানে রয়েছে কারণ প্রচুর লোক কেবল বিদ্যমান কোড কোডের কারণে এটির সাথেই লেগে থাকে। আপনি যদি পিছনের দিকে সামঞ্জস্যতা হারিয়ে ফেলেন তবে প্রচুর লোকেরা সেই সুযোগটি গ্রহণ করবে যে তারা পাইথনে যাওয়ার জন্য অপেক্ষা করেছিল।


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

1
@ জর্জিও মিথ্যা সমস্যা? যে সমস্ত গ্রন্থাগার লেখককে একই সময়ে কোনও ভাষার আরও সংস্করণ সমর্থন করতে হবে তাদের বলুন।
সুইভ

@ এসভিক: পৃথক সংকলন সহ আপনার কোনও ভাষার বিভিন্ন সংস্করণ সমর্থন করার দরকার নেই। উদাহরণস্বরূপ দেখুন স্ক্যালাল জাভা লাইব্রেরিগুলি কীভাবে স্কালার জন্য সংকলিত নয় তা ব্যবহার করতে পারে।
জর্জিও

9

পিএইচপি ব্যতীত অন্য যে কোনও ভাষার জন্য আমি বলব, হ্যাঁ, এটি একেবারেই অর্থপূর্ণ! পাইথন 3-এ স্যুইচটি দিয়ে পাইথন ঠিক এটি করছে।

তবে, পিএইচপি-র সমস্যাটি হ'ল ভাষা ডিজাইনের সাথে অনেকগুলি ত্রুটি রয়েছে, সুতরাং আপনি "পিএইচপি 8" বলছেন তা সম্পূর্ণ আলাদা ভাষা হবে। এবং যদি আপনাকে আলাদা ভাষায় স্যুইচ করতে হয় তবে আপনি বর্তমানে বিদ্যমান এবং স্থিতিশীল বিকল্পগুলির চেয়ে নতুন পিএইচপি কেন ব্যবহার করবেন?

এছাড়াও পিএইচপি সম্প্রদায় নতুন কিছু মানিয়ে নেওয়ার জন্য অত্যন্ত ধীর। এ থেকে মুক্তি পেতে কতক্ষণ সময় লেগেছে তা দেখুন register_globals। এটি 2000 সালের পর থেকে একটি সুরক্ষা ঝুঁকি হিসাবে পরিচিত। এটি কেবল 12 বছর পরে শেষ পর্যন্ত সরানো হয়েছে। আর একটি উদাহরণ, যখন পিএইচপি 5 চালু হয়েছিল, এটি পিএইচপি 4 এর তুলনায় বিশাল উন্নতি হয়েছিল, তবুও সম্প্রদায় এটিকে গ্রহণ করে নি। আমি গ্রহণটি জাম্পস্টার্ট করতে 4 বছর এবং GoPHP5 এর মতো বিশাল পদক্ষেপ নিয়েছি । এবং এটিতে পিছনে অসামঞ্জস্যপূর্ণ পরিবর্তনগুলির উল্লেখযোগ্য পরিমাণও ছিল না।


5

দাবি অস্বীকার: আমি একটি কোল্ডফিউশন ব্যবহারকারী গ্রুপ পরিচালনা করি manage

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

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

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

যদি কোনও ভাষার সর্বশেষতম সংস্করণ পিছনের দিকে সামঞ্জস্যপূর্ণ হয় তবে কোনও কোড পরিবর্তন না করে পারফরম্যান্সে একটি উত্সাহের পরিচয় দেয় (সিএফ 9 সিএফ 8 এর চেয়ে 30% বেশি দ্রুত এবং সিএফ 10 সিএফ 9 এর চেয়ে অনেক দ্রুতগতিতে), যদি তারা এখনও কাজ করে তবে ফাংশন কলগুলি পরিবর্তন করার বিষয়ে কে চিন্তা করে?

একটি সংস্থা হিসাবে, আমাদের ক্লায়েন্টদের সন্তুষ্ট করা এবং তাদের বিল সরবরাহের পরিষেবাগুলি, ব্যবসা তৈরি করতে এবং আরও ক্লায়েন্ট নিয়োগের বিষয়ে তাদের উদ্বেগের বিষয়ে চিন্তা করতে হবে।

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


4

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

এটি (আমার মনে) প্রধান প্রকাশনা, ছোট প্রকাশনা এবং সংশোধনগুলির মধ্যে পার্থক্য। একটি সাধারণ নীতি হিসাবে:

  • প্রধান রিলিজগুলি ব্রেকিং পরিবর্তনগুলি ধারণ করে।
  • ছোট প্রকাশগুলি আচরণ কিছুটা বদলাতে পারে।
  • সংশোধনগুলি বেশ ক্রস-সামঞ্জস্যপূর্ণ হওয়া উচিত।

উদাহরণস্বরূপ, আমি যদি কোনও ভাষার v2.3 তে কিছু লিখছি তবে আমি v2.3.2 এ আপগ্রেড করলে কোনও পার্থক্য লক্ষ্য করার আশা করব না। যদি আমি v2.4 এ আপগ্রেড করি তবে কয়েকটি জিনিস পরিবর্তিত হতে পারে - ছোট সিনট্যাক্স টুইটস, কিছু ফাংশন কিছুটা আলাদাভাবে আচরণ করে তাই আমাকে যুক্তি তাত্ক্ষণিক করতে হবে ইত্যাদি I সম্পূর্ণরূপে - ফাংশনগুলি অবচিত বা অনুপস্থিত, ক্রিয়াকলাপগুলি এতটা সমর্থিত বা পরিবর্তন হয়নি যে আমি কেবল এটি লাইনে ফিরিয়ে দিতে পারি না, নতুন পরিবর্তনগুলির জন্য অ্যাকাউন্টে আমাকে কিছু ফাংশন আবার লিখতে হয়।

সম্পাদনা:

স্টিভ ভ্যানসের কাগজ উন্নত এসসিএম শাখা কৌশলগুলির এই কথাটি রয়েছে:

সাধারণত, প্রকাশের দুটি থেকে তিনটি স্তর থাকে, পিরিয়ডের সাথে সংযুক্ত সংখ্যার দ্বারা নামকরণ (যেমন 1.2.3)। [...] এই কাঠামোর মধ্যে প্রথম সংখ্যাটি একটি বড় সংস্করণের সাথে যুক্ত, এটি ইঙ্গিত করে যে এটির পূর্ববর্তী থেকে উল্লেখযোগ্য বৈশিষ্ট্য এবং কার্যকরী বর্ধন রয়েছে; উল্লেখযোগ্য অসম্পূর্ণতাগুলিও থাকতে পারে যার জন্য মাইগ্রেশন প্রয়োজন। দ্বিতীয় সংখ্যাটি একটি গৌণ সংস্করণ উপস্থাপন করে, এতে বৈশিষ্ট্য এবং ফাংশন বৃদ্ধি, উল্লেখযোগ্য সংখ্যক বাগ সংশোধন এবং কোনও অসঙ্গতি নেই। তৃতীয় সংখ্যাটি প্যাচ স্তরকে বোঝায়, প্রায় একচেটিয়াভাবে বাগ সংশোধনগুলির সংগ্রহ নির্দেশ করে; প্যাচ স্তরগুলির মধ্যে কোনও বৈশিষ্ট্য বা ফাংশন বর্ধন এবং কোনও অসম্পূর্ণতা অনুমোদিত নয়।

আমি কেবল এটির পরিবর্তিত নীতিটিই উল্লিখিত নীতিটি বলেছি যে প্রোগ্রামাররা প্রায়শই বাগগুলি "ব্যবহার" করার উপায় খুঁজে পান, সুতরাং "উল্লেখযোগ্য সংখ্যক বাগ সংশোধন এবং কোনও অসঙ্গতি" সহ একটি ছোটখাটো সংস্করণ কঠিন হতে পারে, কারণ সম্ভবত এটি সম্ভবত বাগগুলি হয় তাদের এমন কিছু ভেঙে দেবে যা তাদের ব্যবহার করেছে, বা কোনও কাজের অকারণে পরিণত হতে পারে এবং সমস্যা তৈরি করতে শুরু করবে।


আমি কার্যকারিতা যুক্ত করার জন্য ২.৩-> ২.৪ আশা করব, তবে এটি মুছে ফেলব না।
ডোনাল ফেলো

1
কাকতালীয়ভাবে, আমি সম্প্রতি একটি প্রাসঙ্গিক উদ্ধৃতি জুড়ে এসেছি। মন্তব্য করার জন্য এটি কিছুটা দীর্ঘ, তাই আমি আমার উত্তরটি সম্পাদনা করব।
anaximander

2

এটি ভাষাটির লক্ষ্য কী - তার উপর নির্ভর করে যে কী ধরণের অ্যাপ্লিকেশনগুলি ভাষা দ্বারা নির্মিত হবে।

উদাহরণস্বরূপ, অ্যান্ড্রয়েড উপেক্ষা করে জাভা বেশিরভাগ বৃহত এন্টারপ্রাইজ সিস্টেম এবং মাঝারি ওয়্যারে ব্যবহৃত হয়; এই ধরণের অ্যাপ্লিকেশনগুলির আকার এবং সময় উভয়ই খুব বড় হয়ে যায়। এর কিছু জড়িত রয়েছে; 500K + এলওসি সহ এমন একটি সিস্টেমের কল্পনা করুন যার বিকাশ পর্যায়ে 50+ প্রকৌশলী কর্মী। সাধারণত এই ধরণের সিস্টেমের পরে রক্ষণাবেক্ষণের জন্য প্রবেশ করুন 10 বিকাশকারীদের বলুন; এখন যদি ভাষা পরিবর্তন হয় এবং পরিবর্তনগুলি পিছনের দিকে সামঞ্জস্য না করে তবে প্রকল্পটি সহজেই একটি নতুন সংস্করণে স্থানান্তরিত হতে পারে না কারণ কিছু অংশ লিখেছেন এমন প্রোগ্রামারগুলি চলে গেছে এবং কেউ এটি স্পর্শ করতে চায় না। এটিই ক্ষুদ্র সমস্যা, বৃহত্তর সমস্যাটি এমন একটি বিষয় নিয়ে গঠিত যা 500 টি এলওসি অ্যাপ্লিকেশনটিকে নতুন ভাষার সীমাবদ্ধতার সাথে মানিয়ে নিতে বেশ ব্যয়বহুল। উদাহরণস্বরূপ যদি জেনেরিকগুলি মুছে ফেলা টাইপের সাথে বাস্তবায়ন না করা হয়List list = new List(); কয়েক মিলিয়ন লাইন কোড সংকলন করে পুনরায় লেখার প্রয়োজন পড়বে - যা একটি দুর্দান্ত ব্যয়।

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


1

কেউ যুক্তি দিতে পারেন যে মাইক্রোসফ্ট এএসপি.এনইটি (ক্লাসিক এএসপির উত্তরসূরী) বা ভিবি.এনইটের সাথে একই রকম পরিবর্তন সম্পাদন করেছে (যদিও তারা পরবর্তীকালে এত ছাড় দিয়েছিল যে ভাষার "রিবুটিং" এর বেশিরভাগ সুবিধা হ'ল)।

যাইহোক, কেউ যদি কোনও মাইগ্রেশন সরঞ্জামের সহায়তায় ভিবি.এনইটি-তে ভিবি 6 কোড সরিয়ে নেওয়ার দুঃস্বপ্নের কথা মনে রাখে তবে তারা ঠিক মেনে নেবে যে ভাষা স্থানান্তর সরঞ্জামগুলি বড় ভাষার আপডেটের জন্য খুব ভাল কাজ করে না।

প্ল্যাটফর্মটিকে সামনের দিকে নিয়ে যাওয়া সম্ভব হতে পারে তবে কমপক্ষে কয়েকটি সংশোধনীর মাধ্যমে আপনার "অবজ্ঞাত" এপিআইয়ের পক্ষে সমর্থন সরবরাহ করা উচিত।


1

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

জাভাতে ক্লোজারগুলির অভাব একটি সর্বোত্তম উদাহরণ। এটি মোটেই ভাষার কোনও ত্রুটি নয়, এবং ভাষাটি পরিবর্তনের ফলে (এজেন্ডায় দুঃখজনকভাবে) আইএমও এটিকে মূলত পঙ্গু করে দেবে বা খুব কমপক্ষে এটি পড়তে এবং বুঝতে খুব কঠিন করে তুলবে।

যে সমস্ত লোক খুব সহজেই দৃষ্টিভঙ্গি হারিয়ে ফেলেছে তা হ'ল প্রতিটি ভাষার নিজস্ব শক্তি এবং দুর্বলতা রয়েছে এবং প্রতিটি দুর্বলতা এড়িয়ে গিয়ে এমন কিছু তৈরি করার চেষ্টা করা হয়েছে যা একেবারেই অকেজো রাক্ষস তৈরি করবে যা অকার্যকর, অবিশ্বাস্যভাবে অনর্থক, অসম্ভব কার্যকরভাবে ব্যবহার করুন।

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


1

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

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

int someInt;
double someDouble;

someInt.Equals(someDouble)ভেরিয়েবলের বিষয়বস্তু নির্বিশেষে অভিব্যক্তিটি মিথ্যা প্রত্যাবর্তনের গ্যারান্টিযুক্ত। এটি সংকলন করে কারণ doubleরূপান্তরিত হতে পারে Objectএবং সেই ধরণের জন্য ওভারলোড intরয়েছে Equals, তাই সংকলক রূপান্তরটি করে এবং কল করে। আমি যদি সি # এবং .NET ফ্রেমওয়ার্কের একটি নতুন সংস্করণ ডিজাইন করছিলাম তবে আমার এটি বক্সিং রূপান্তরকে নিষেধ করতে হবে কারণ এটি সম্ভবত কার্যকর কিছু করতে পারে না। এটি এমন কিছু প্রোগ্রাম রয়েছে যা এই উপায়ে এমন একটি তুলনা করে যা অকেজো কিন্তু ক্ষতিহীন এবং সংকলকযুক্ত কোডটি প্রত্যাখ্যান করার ফলে সেই প্রোগ্রামটি ভেঙে যেতে পারে, তবে এই অকেজো কোড সংশোধন বা অপসারণ একটি উন্নতি হবে।

কিছুটা কম পরিষ্কার উদাহরণ হিসাবে, ধরে নিই

float f=16777216f;
int i=16777217;

এবং অভিব্যক্তি বিবেচনা করুন f==i। এটা যে কিছু কোড ভাসা / পূর্ণসংখ্যা তুলনা করে এবং সঠিকভাবে কাজ করে, কিন্তু কোড পারেন হিসেবে পুনর্লিখিত করা উচিত সম্ভব f==(float)i, (double)f==i;অথবা (double)f==(double)i;[ intকরার doubleপ্রচার অবচয়হীন, তাই আধুনিক দুই সমতুল্য হবে]। কিছু কোড যা সরাসরি তুলনা করে floatএবং integerমানগুলি সর্বদা এমন সংখ্যার সাথে ডিল করতে পারে যা যথেষ্ট ছোট floatএবং doubleতুলনাগুলি একইরকম আচরণ করবে তবে একটি সংকলক সাধারণত তা জানতে পারে না; কোডটির দ্বারা স্পষ্ট করা উচিত যে ভাষার নিয়মগুলি প্রোগ্রামারের অভিপ্রায়টির সাথে মিলবে এই আশা না করে কোন ধরণের তুলনা প্রয়োজন।


1

পিছনে সামঞ্জস্যতা কখনও না ভাঙ্গাই ভাল।

মাইক্রোসফ্ট ভিবি 6 প্রোগ্রামিংয়ের ভাষাটিকে একটি নতুন ভাষা দিয়ে প্রতিস্থাপন করেছিল যা সম্পূর্ণভাবে সামঞ্জস্যতা ভেঙে দেয়। সুতরাং আজও 16 বছরের পুরানো ভিবি 6 ডটনেট সংস্করণটির চেয়ে বেশি জনপ্রিয় (টিওব ইনডেক্স আগস্ট 2014)। এবং গার্টনার অনুমান করে এখনও ভিবি 6 কোডের 14 বিলিয়ন লাইনের ব্যবহার রয়েছে।

২০১৪ সালে মাইক্রোসফ্টকে আবার ঘোষণা করতে হয়েছিল যে ভিজ্যুয়াল বেসিক প্রোগ্রামিং সম্প্রদায়ের দাবি থাকা সত্ত্বেও তারা আপডেট বা ওপেন সোর্স ভিবি 6 প্রকাশ করবে না। তবে তারা 'কমপক্ষে' 2024 অবধি VB6- এর সমর্থন বাড়িয়েছে এবং এটি উইন্ডোজ 7 এবং 8-এ দুর্দান্ত কাজ করে যা ভিবি 6 এর একই সংস্করণের জন্য 26 বছরের বেশি সমর্থন করবে।

বিদ্যমান ওয়ার্কিং সফ্টওয়্যারটি কেন নতুন করে লিখতে হবে, এমনকি মাইক্রোসফ্ট ডটনেট ব্যবহার করতে অফিসকে কখনও "আপডেট" করে না?


এই পূর্বে 14 উত্তর উপর কিছু সারগর্ভ প্রস্তাব বলে মনে হচ্ছে না
মশা

1

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

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

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

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

D. নতুন ডকুমেন্টেশনগুলি রাখা এবং রক্ষণাবেক্ষণ করা দরকার। গুগলে জিনিসগুলি অনুসন্ধান করা এবং আপনি বর্তমানে ব্যবহার করছেন তার চেয়ে আলাদা সংস্করণের জন্য আপনি ডক্সটি পড়ছেন তা খুঁজে পাওয়ার এটি সর্বদা একটি বিভ্রান্তিকর অভিজ্ঞতা।

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

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

সুতরাং ভাষাগুলি নিজেদের উন্নতির জন্য ব্রেকিং পরিবর্তন না করার আরও কয়েকটি কারণ হ'ল:

E. ভাষা বিকাশকারীরা মনে করেন তাদের ব্যবহারকারীর পরিবর্তনের ভয় তাদের ভাষা স্থবির করার একটি ভাল কারণ

এফ। ভাষা বিকাশকারীরা তাদের ভাষাটি তৈরি করার সময় তাদের ভাষা পছন্দ করেছিল এবং তারা সম্ভবত এর ত্রুটিগুলি নিয়ে এটি ঠিক মনে করে।

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

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

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

  1. জিনিসগুলি যখন সরানো হবে তার আগে অবহেলা করুন।

  2. একটি ভাল , স্ট্যান্ডার্ড রূপান্তরকারী সরঞ্জাম সরবরাহ করুন। পাইথন 2to3 সরঞ্জাম সরবরাহ করেছিল, তবে এটি ভালভাবে প্রচার করা হয়নি, পাইথন 3 এর সাথে স্ট্যান্ডার্ড আসেনি যেমনটি আমি স্মরণ করি, এমনকি খুব ভাল কাজও করি না (সমস্যাগুলি সমাধানের জন্য আমি 2to3 দ্বারা উত্পন্ন প্রোগ্রামগুলি নিজে নিজেই যেতে হয়েছিল মনে আছে) ঠিক করা হয়নি)। আপনার সংকলক / দোভাষী যদি কোনও পুরানো সংস্করণ সনাক্ত করে তবে এই রূপান্তরকারী সরঞ্জামটি স্বয়ংক্রিয়ভাবে চালানো যেতে পারে। এর থেকে সহজ আর কী হতে পারে?


ফেসবুক সাদৃশ্যটি নিয়ে সমস্যাটি হ'ল কোনও ফেসবুক উত্তরাধিকার ব্যবহার নেই। উপায় নেই। হয় আপনি ফেসবুকের বর্তমান সংস্করণ ব্যবহার করেন বা আপনি ফেসবুক মোটেই ব্যবহার করেন না। এদিকে, Python 2মুক্তির সাত বছর পরেও প্রচুর সংখ্যক লোক এখনও ব্যবহার করছে Python 3কারণ এটি এখনও বিদ্যমান - যদি তা না ঘটে তবে তারা ক্ষুধার্ত হয়ে উঠত, তবে তারা বন্দরে প্রবেশ করত Python 3
কেভিন

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

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

ফেসবুকের সুবিধা রয়েছে যে, যখন এটি আপডেট হয়, পূর্ববর্তী সংস্করণগুলি মূলত আর উপস্থিত থাকে না। প্রোগ্রামিং ভাষাগুলি এর মতো নয় এবং এটি একটি প্রাসঙ্গিক পার্থক্য - আপনি কোনও প্রোগ্রামিং ভাষার পুরানো সংস্করণ যেমন ব্যবহার করতে পারেন Python 2, কারণ এটি এখনও বিদ্যমান।
কেভিন

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

0

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

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


-1

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

আমাদের সাইট ব্যবহার করে, আপনি স্বীকার করেছেন যে আপনি আমাদের কুকি নীতি এবং গোপনীয়তা নীতিটি পড়েছেন এবং বুঝতে পেরেছেন ।
Licensed under cc by-sa 3.0 with attribution required.