উচ্চ স্তরের পরিচালনকে কার্যকরী প্রোগ্রামিং বিবেচনা করার জন্য বোঝানোর জন্য কী যুক্তিযুক্ত যুক্তি থাকতে পারে? [বন্ধ]


15

ফাংশনাল প্রোগ্রামিং কেন একটি ভাল ধারণা (এর জন্য অনেকগুলি একটি উন্মুক্ত প্রশ্ন হিসাবে থাকতে পারে এবং সঠিকভাবে তাই) এর জন্য প্রচুর "তাত্ত্বিক" যুক্তি রয়েছে

যাইহোক, তাদের বেশিরভাগই তত্ত্ব ("কমনীয়তা", ইত্যাদি ...) থেকে তৈরি আর্গুমেন্ট, বা, বিকাশকারীদের লক্ষ্য করে।

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

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

সাধারণত, আমি যুক্তিগুলি সন্ধান করছি যা পরিমাণগত এবং / অথবা গবেষণা বা কেস স্টাডি ভিত্তিক on উদাহরণস্বরূপ "এই রেফারেন্স অনুসারে, লিস্প / এফ # তে মাল্টিথ্রেডেড সিস্টেমের বাগের হার 10% যা জাভা" বা "শীর্ষ স্নাতকদের 80% শীর্ষ 3 স্বার্থ অনুসারে ফাংশনাল প্রোগ্রামিং নামক কাঙ্ক্ষিত প্রযুক্তির পছন্দ প্রকাশ করে"।

আমি জানি যে গ্রাহাম স্টারআপের জন্য ফাংশনাল প্রোগ্রামিংয়ের ব্যবহারগুলি উপস্থাপন করেছিলেন এবং এটি কয়েকটি বৃহত্তর প্রতিষ্ঠিত সংস্থার জন্য বৈধ হতে পারে বলে ধরে নিয়ে তার কিছু যুক্তি প্রকাশ করবে।

আমি পুরোপুরি অবগত যে আপনি পার্ল, সম্ভবত পাইথন, এবং (সম্ভবত) এমনকি জাভা 8 বা সি ++ 14 এ ফাংশনাল প্রোগ্রামিংয়ের কাছাকাছি কিছু করতে পারেন But তবে এর অর্থ এই নয় যে পার্ল, সি ++ বা জাভা ব্যবহারকারী কোনও সংস্থা কার্যকরী বনামকে সমর্থন করবে এমনকি সেই ভাষাগুলিতেও ওওপি / পদ্ধতিগত পদ্ধতির

এই ভাষার উদ্দেশ্যগুলির জন্য, "বৃহত্তর "টিকে ডেডিকেটেড ডেভেলপমেন্ট ইঞ্জিনিয়ারিং / সরঞ্জাম গোষ্ঠী হিসাবে যথেষ্ট হিসাবে সংজ্ঞায়িত করা হয়েছে, যা সমস্ত বিকাশকারীকে কীভাবে ব্যবহার / করার অনুমতি দেয় তা নির্দেশ করে; এবং কম প্রান্তে কমপক্ষে শত শত বিকাশকারী


1
আপনি এই এক খুঁজছেন, আমার ধারণা? paulgraham.com/avg.html আসলে, আমি মনে করি নিবন্ধটি কিছুটা পুরানো, মূলধারার ভাষায় প্রচুর ক্রিয়ামূলক ধারণা প্রবেশ করেছে।
ডক ব্রাউন

34
প্রোগ্রামিং ভাষা এবং পদ্ধতিগুলি কী ব্যবহৃত হয় তা উচ্চ-স্তরের পরিচালনত্বে কেন কোনও অভিশাপ দেওয়া উচিত? তারা কেন এমন সিদ্ধান্তে জড়িত হবেন? প্রযুক্তিগত পরিচালকদের জন্য অবশ্যই এটি একটি বিষয়?
উচ্চ পারফরম্যান্স মার্ক

8
@ হাইপারফরম্যান্সমার্ক: "উচ্চ-স্তরের ব্যবস্থাপনার" জন্য "প্রযুক্তিগত পরিচালক" প্রতিস্থাপন করুন এবং আবার প্রশ্নটি মূল্যায়ন করুন।
রবার্ট হার্ভে

2
আপনি কোন ব্যবসায় করছেন? আপনি যদি কন্ট্রাক্ট প্রোগ্রামিং এবং পরামর্শ করেন, ফাংশনাল প্রোগ্রামিং এমন একটি বাজ শব্দ হতে পারে যা ম্যানেজমেন্ট ভাবতে পারে আপনার ক্লায়েন্টকে প্রভাবিত করবে।
জেফো

3
আপনি বর্তমানে যে ভাষা ব্যবহার করেন তা পরিচালনার জন্য আপনাকে কোন ব্যবসায়িক যুক্তি দিয়েছিল?
জেফো

উত্তর:


7

একটি খুব সাধারণ যুক্তি রয়েছে, যা কমপক্ষে ম্যানেজমেন্টকে আনন্দিত করতে পারে।

এটি সর্বজনবিদিত যে আধুনিক কম্পিউটারগুলি তাদের আগের মতো "দ্রুত" হয়ে উঠছে না, কারণ ফ্রিকোয়েন্সি স্কেলিং, আপাতত, সীমাবদ্ধতায় চলে hit তারা কোর যুক্ত করে তাদের সম্ভাব্য উত্পাদনশীলতা বৃদ্ধি করে।

এ থেকে বোঝা যায় যে এই আর্কিটেকচারটি থেকে সর্বাধিক উপকৃত হতে প্রোগ্রামগুলি সমান্তরাল করতে হবে। তবে সমান্তরাল প্রোগ্রামিং ক্রমক্রমিক প্রোগ্রামিংয়ের চেয়ে অনেক বেশি শক্ত, এটি প্রচুর নতুন চ্যালেঞ্জ নিয়ে আসার কারণে ( বিস্তৃত ওভারভিউয়ের জন্য উইকি নিবন্ধের পরামর্শ নিন )।

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

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

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


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

এ প্রশ্নেরই ইতিমধ্যে কয়েক বার আলোচনা করা হয়েছে, যেমন quora.com/Why-does-functional-programming-favor-concurrency বা stackoverflow.com/questions/474497/...
Ashalynd

3
অনেকগুলি ওওপি ভাষাগুলি ফাংশনাল প্রোগ্রামিংকে সমর্থন করে তবে আপনি স্নানের পানির সাহায্যে বাচ্চাকে বাইরে ফেলে দিয়ে কার্যকরী দিকগুলি ব্যবহার করতে পারেন।
অ্যান্ডি

1
ঠিক আছে, প্রশ্নটি "ফাংশনাল প্রোগ্রামিং" সম্পর্কে ছিল "ফাংশনাল ভাষা" সম্পর্কে নয়। শব্দগুচ্ছ পরিবর্তন হবে।
আশাল্যান্ড

40

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

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

সুতরাং সংক্ষিপ্তসারটি হ'ল: অন্যান্য দলের সদস্যদের, বা আপনার দলের নেতাদের বোঝান, তবে, উচ্চ-স্তরের পরিচালনা নয়!

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


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

1
@ ডিভিকে যদি অন্য কেউ আপনার কোডটি দেখতে না পান, তবে আপনাকে অন্য কাউকে বোঝানোর দরকার নেই যে আপনার ভাষা ভাল is শুধু এটি ব্যবহার শুরু করুন।
ব্যবহারকারী 253751

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

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

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

16

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

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

যদি আপনার সংস্থাটি ইতিমধ্যে Nouns কিংডমে জড়িত থাকে তবে ফাংশনাল প্রোগ্রামিংয়ে পাইকারি পরিবর্তন করা ঠিক হবে না। ভাষা পছন্দ (এবং এটি ঘিরে থাকা অন্যান্য সমস্ত পছন্দ) ইতিমধ্যে কর্পোরেট সংস্কৃতিতে গভীরভাবে এম্বেড হয়েছে।

ধরে নিই আপনার লক্ষ্যটি একটি সফ্টওয়্যার বিকাশকারী হিসাবে বৃদ্ধি করা, আপনার সেরা বেটটি হ'ল

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

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


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

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

কিংডম অফ ননসের জন্য +1। আমি এটি "নাম এবং ক্রিয়াপদগুলির মধ্যে যুদ্ধ" বলছি।
রব

4
@ ডিভিকে: যেহেতু যে কোনও কিছুর পরিচালনা বোঝানোর উপায় সময় থেকেই শুরু ছিল: এটি কীভাবে তাদের অর্থ সাশ্রয় করবে তা তাদের দেখান।
রবার্ট হার্ভে

9

আমার (কিছুটা ছদ্মবেশী) অভিজ্ঞতায়, এমন কোনও দোকানে কাজ করেছি যেখানে আমরা কার্যকরী প্রোগ্রামিং ব্যবহার করেছি, এবং বেশ কয়েকটি অন্যান্যর সাথে সাক্ষাত্কার নিয়েছি:

  1. সেখানে সর্বদা একজন সিটিও এবং অন্যান্য উচ্চ-স্তরের প্রযুক্তিবিদ ছিলেন যাঁরা কার্যকরী প্রোগ্রামিংয়ের অভিজ্ঞতা অর্জন করেছিলেন এবং এটির অ-প্রযুক্তিগত কর্মকর্তাদের বোঝাতে সক্ষম হন। (এবং ঘটনাক্রমে, এই লোকেরা আমার চেয়ে আপনার প্রশ্নের উত্তর দেওয়ার জন্য আরও দক্ষ।
  2. এই লোকেরা এই সংস্থাটি ছেড়ে চলে যাওয়ার পরে, এবং যাদের এই ঝোঁক নেই তাদের দ্বারা প্রতিস্থাপন করা হলে জিনিসগুলি দক্ষিণে চলে যাবে। নতুন ছেলেরা প্রথমে যা তৈরি হয়েছিল তা তৈরি করার জন্য ব্যবহৃত অদ্ভুত প্রোগ্রামিং ভাষা এবং দৃষ্টান্তের জন্য যা কিছু ভুল হয়েছে তার (এবং বিশেষত তাদের নিজস্ব ব্যর্থতা) দোষ দেবে। তারা বাকী লোকদেরকে কার্যনির্বাহী প্রোগ্রামিং দক্ষতা দিয়ে প্রান্তিককরণ করবে, তাদেরকে সংস্থা থেকে দূরে ঠেলে দেবে। ক্রিয়ামূলক ভাষার উপর নির্মিত সিস্টেমটি অযৌক্তিকভাবে খারাপ হয়ে যাবে। এই ধরণের জিনিসটি, আমার মনে, যদি তারা কার্যকরী ভাষা অবলম্বন করে তবে কোনও ব্যবসায় সবচেয়ে বেশি ঝুঁকির মধ্যে পড়ে, এবং তাদের অবশ্যই অবমূল্যায়ন করা উচিত নয়।
  3. এই কাজ করার জন্য এই সংস্থার একটি "কিনার পরিবর্তে বিল্ড" সংস্কৃতি থাকতে হবে। কারণ কার্যকরী ভাষা গ্রহণের অর্থ "ক্রয়" বিকল্পগুলি কম হবে।
  4. ধারণাটির প্রযুক্তিগত এবং অ-প্রযুক্তিগত প্রতিরোধকারীদের সাথে প্রায় সবসময় কিছুটা আপস ছিল । এই আপসগুলির মধ্যে সর্বাধিক প্রচলিত বিষয় হল যে কোনও জেভিএম-এর ভাষা কেবল বিবেচনার বাইরে ছিল; ক্লজিউর এবং স্কালার প্রস্তাব দেওয়া হয়েছিল, হাসেল এবং ও'ক্যামাল ঠিক ব্যাট থেকে আউট হয়ে গেলেন।

4

উচ্চতর পরিচালনার জন্য যে বিষয়গুলি বিবেচনা করার বিষয়গুলি / যদি উচ্চতর পরিচালন প্রোগ্রামিং ভাষা বাছাইয়ের সাথে জড়িত থাকে (যা অদ্ভুত, তাদের এটিকে বিশ্বস্ত, জ্ঞানবান লোক (প্রযুক্তি এবং ব্যবসায় উভয়ই জ্ঞানী) রেখে দেওয়া উচিত:

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

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


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

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

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

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

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

3

আমি মনে করি না যুক্তি বা তথ্যগুলি সাহায্য করবে। এবং অবশ্যই আপনি যে সমস্যার সমাধান করতে চান তা উল্লেখ না করেই নয়।

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

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

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

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

দৃ architect় স্থাপত্য সংক্রান্ত সিদ্ধান্ত নিয়ে আসার জন্য গুরুত্বপূর্ণ:

  • অংশীদারদের কাছ থেকে ইনপুট সংগ্রহ করুন (পরিচালনা, ব্যবহারকারী, প্রশাসক, বিক্রয়, ক্লায়েন্ট ...)
  • যে ইনপুট উপর বেস সিদ্ধান্ত
  • স্পষ্টভাবে যোগাযোগ করুন: (প্রস্তাবিত) সিদ্ধান্তগুলি কী; তারা কী ঝুঁকি হ্রাস করতে লক্ষ্য করে; বিরোধী স্বার্থগুলি কী এবং কিছুটা বিলম্বের সাথে: তারা কতটা ভাল কাজ করেছে।

যদি আপনি 10 কে + কর্মচারী বলে একটি বড় সংস্থার হয়ে কাজ করেন তবে নিম্নলিখিত কয়েকটি পাঠ শিখতে প্রস্তুত থাকুন।

  • কোডিংয়ের গতি নীচের লাইনের জন্য সত্যিই প্রাসঙ্গিক নয়।
  • দশকের স্কেলে রক্ষণাবেক্ষণের মতো জিনিস।
  • ক্রিয়ামূলক ভাষা ব্যবহার করে আপনি যে সমস্যার সমাধান করতে পারবেন বলে মনে করেন তা নীচের লাইনের জন্য আসলেই প্রাসঙ্গিক নয়
  • 1000 বিকাশকারীকে প্রশিক্ষণ দেওয়ার মতো প্রযুক্তিগত প্রযুক্তি ব্যবহারের ক্ষেত্রে 5 বছরের কম অভিজ্ঞতার সাথে বিকাশকারীদের দ্বারা লিখিত কোড বেইজ পরিবর্তন ও বজায় রাখার মতো প্রাকৃতিক প্রতিরোধ।

আপনার আর্গুমেন্টগুলি শোনা এবং বিবেচনা করার পরে আপনি এমন একটি বিশ্বাসের পর্যায়ে পৌঁছে গেছেন যে আপনি, আপনার দল এবং পরিচালনার উপর ভরসা রাখার প্রয়োজনীয়তাগুলি বিবেচনা এবং বিবেচনা করার একটি উপায়ও তৈরি করে ফেলবেন।

যদি এই প্রক্রিয়াটি আপনার দ্বারা সম্পন্ন কিছু ক্ষেত্রে কার্যকরী পদ্ধতির ব্যবহারের জন্য সুপারিশ তৈরি করে।

যদি এই প্রক্রিয়াটি বর্তমান প্রধান প্রোগ্রামিং ভাষার পাশাপাশি আপনার দ্বারা সম্পন্ন করা হয় তার বাইরে গিয়ে কার্যকরী পদ্ধতির উপেক্ষা করার জন্য সুপারিশ তৈরি করে।

খারাপ খবরটি হ'ল: সংস্থার আকার এবং শৈলীর উপর নির্ভর করে সহজেই কয়েক বছর বা দশক সময় লাগতে পারে।

সুসংবাদটি হ'ল: আপনি পথে অনেক কিছু শিখবেন।

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


3

একটি ভাল পদ্ধতির এটি দেখানো হবে যে এটি শিল্পে ভাল ফলাফল দেখিয়েছে এবং গৃহীত হয়েছে।

আপনি এর থেকে কিছু ডেটা পেতে পারেন:

আদর্শভাবে, কিছু তালিকাভুক্ত সংস্থাগুলির পরিচালকদের সাথে কথা বলার চেষ্টা করুন, বিশেষত আপনার শিল্পে যদি, এবং তাদের কাছ থেকে নম্বর এবং প্রশংসাপত্র পান।

হাস্কেল, ওক্যামেল ইত্যাদির জন্য গুগলের আরও অনেক অনুরূপ লিঙ্ক রয়েছে


3
কিছু সংস্থাগুলি এটিকে একটি মামলা হিসাবে দেখতে পাবে , যেহেতু ওও অনুশীলনকারীরা বিস্তৃত ব্যবধানে এফপি অনুগামীদের চেয়ে বেশি ।
রবার্ট হার্ভে

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

1
@ ডিভিকে: আপনি যে প্রশ্নটি জিজ্ঞাসা করেছেন (তা যদি আমি সঠিকভাবে বুঝতে পারি) তবে হ'ল "আমি কীভাবে আমার মনিবদের বোঝাতে পারি যে এফপি একটি ভাল জিনিস?" ভাল, কখনও কখনও এটি না। আমরা একটি পরিবর্তনীয় বিশ্বে বাস করি এবং ফাংশনাল প্রোগ্রামিং হ'ল বেশ সৎভাবে, একটি অদ্ভুত বল। আপনি যদি আমাকে বিশ্বাস না করেন তবে মনদেদে একবার দেখুন। এই প্রতিকূলতাকে সম্বোধন করে এমন উত্তর (এবং তারা সফ্টওয়্যার ডিজাইন এবং বিকাশ প্রক্রিয়াটিকে কীভাবে প্রভাবিত করে) কার্যকর হয়, আপনার মনে হয় সেগুলি হয় কি না।
রবার্ট হার্ভে

@ রবার্টহারভে (১) আমি এটি ফিরিয়ে নিই। এখন দরকারী উত্তরগুলির মধ্যে দুটি উত্তর সর্বনিম্ন ভোট হয়েছে :) (নতুন পোস্ট করা হয়েছে যা সত্যের সাথে উন্নত হতে পারে তবে এটি একটি ভাল শুরু)।
ডিভি কে

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

2

আপনি এটি ভুল দিক থেকে আসছেন।

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

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


2
এটি একটি তীক্ষ্ণ পেডেন্টিক, এবং প্রশ্নের উত্তর দেওয়ার পক্ষে খুব বেশি সহায়ক নয়, যা ওপিকে তাঁর "পদ্ধতির" সাহায্যে কেবল সহায়তা করা থেকে দূরে রাখা উচিত।
ভিএফ 1

1

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

বলা হচ্ছে, প্রযুক্তিগত পটভূমি (প্রথম কেস) এবং এক (দ্বিতীয় কেস )বিহীন লোকদের বোঝানোর জন্য এখানে কিছু ইঙ্গিত দেওয়া হয়েছে।

প্রথম মামলা

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

নমুনা সি # কোড যা আবশ্যক শৈলী ব্যবহার করে:

var categorizedProducts = new Dictionary<string, List<Product>>();

// Get only enabled products, filtering the disabled ones, and group them by categories.
foreach (var product in this.Data.Products)
{
    if (product.IsEnabled)
    {
        if (!categorizedProducts.ContainsKey(product.Category))
        {
            // The category is missing. Create one.
            categorizedProducts.Add(product.Category, new List<Product>());
        }

        categorizedProducts[product.Category].Add(product);
    }
}

// Walk through the categories.
foreach (var productsInCategory in categorizedProducts)
{
    var minimumPrice = double.MaxValue;
    var maximumPrice = double.MinValue;

    // Walk through the products in a category to search for the maximum and minimum prices.
    foreach (var product in productsInCategory.Value)
    {
        if (product.Price < minimumPrice)
        {
            minimumPrice = product.Price;
        }

        if (product.Price > maximumPrice)
        {
            maximumPrice = product.Price;
        }
    }

    yield return new PricesPerCategory(category: productsInCategory.Key, minimum: minimumPrice, maximum: maximumPrice);
}

ফাংশনাল প্রোগ্রামিংয়ের কথা মাথায় রেখে একই কোডটি পুনরায় লেখা:

return this.Data.Products
    .Where(product => product.IsEnabled)
    .GroupBy(product => product.Category)
    .Select(productsInCategory => new PricesPerCategory(
              category: productsInCategory.Key, 
              minimum:  productsInCategory.Value.Min(product => product.Price), 
              maximum:  productsInCategory.Value.Max(product => product.Price))
    );

তারপরে তাদের জিজ্ঞাসা করুন:

  1. একজন প্রোগ্রামার প্রথম নমুনায় কতগুলি ভুল করতে পারে? দ্বিতীয়টির কী হবে?

  2. ভুলগুলি চিহ্নিত করা কতটা কঠিন?

  3. কোডটি সংশোধন করা কতটা কঠিন?

তিনটি কারণই উত্পাদনশীলতাকে প্রভাবিত করে এবং তাই পণ্যের ব্যয়ও।

দ্বিতীয় মামলা

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

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


3
আমি সেখানে আপনি কী করেছেন তা দেখতে পাচ্ছি, তবে আপনার উদাহরণটি পুরোপুরি বিশ্বাসযোগ্য নয়। আপনি মূলত আপনার কার্যনির্বাহী উদাহরণটি একটি অত্যাবশ্যকীয় হিসাবে রেকর্ড করে রেখেছেন, যা কোনও বাস্তব কর্পোরেট উদ্বেগের মধ্যে ঘটে এমন কিছু নয় happen আপনার yield returnকিছুটা প্রতারণা, এটি কোনও উপায়ে আপনি কীভাবে লিনক দৃশ্যে ব্যবহার করার জন্য কোড প্রস্তুত করবেন তার একটি উদাহরণ এবং আপনার ifবক্তব্যগুলি টার্নারি অপারেটরগুলির সাথে আরও সাবলীলভাবে লেখা যেতে পারে। আপনার প্রথম উদাহরণের সমস্তটি আবশ্যকীয় কার্যগুলিতে রিফেক্টর করা যেতে পারে, যাতে জটিলতাটি লুকানো থাকে।
রবার্ট হার্ভে

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

1
@ রবার্টহারভে আমি নিশ্চিত না যে দুটি কোড স্নিপেট সমান কিনা, যেহেতু কেবল পুনরাবৃত্তিটি বাদ না দিয়ে দ্বিতীয় তালিকা তৈরি করে অপরিহার্য একটি "ফিল্টার"। প্রকৃত সমতুল্য কেবল একটি লুপ ব্যবহার করবে না এবং এভাবে আরও গভীরভাবে বাসা বাঁধবে?
ডোভাল

5
অন্যথায় অপরিহার্য / ওও ভাষায় কার্যকরী ধারণাটি অন্তর্ভুক্ত করার জন্য আপনি একটি ভাল ক্ষেত্রে তৈরি করার কোনও প্রশ্নই আসে না , তবে কর্পোরেট পরিবেশে সম্পূর্ণ কার্যকরী ভাষা ব্যবহারের জন্য এটি ইতিবাচক প্রয়োজন নয় যা ইতিমধ্যে অপরিহার্য / OO।
রবার্ট হার্ভে

আপনার উদাহরণের সাথে আর একটি (সম্ভবত কম বৈধ) সমস্যা: আমি প্রথম উদাহরণটি সম্পূর্ণরূপে পঠনযোগ্য বেশিরভাগ-নন-এফপি পার্ল ইনতে লিখতে পারি - আমি অনুমান করছি - আয়তনের 30%। হয়তো কম. আপনি map/ grepনন-এফপি হিসাবে গ্রহণ করবেন কিনা তা নির্ভর করে । আইওডাব্লু, আপনি যুক্তি উপস্থাপন করছেন যে জাভা একটি খারাপ ভাষা, এফপি ভাল পদ্ধতির নয়।
ডিভি কে
আমাদের সাইট ব্যবহার করে, আপনি স্বীকার করেছেন যে আপনি আমাদের কুকি নীতি এবং গোপনীয়তা নীতিটি পড়েছেন এবং বুঝতে পেরেছেন ।
Licensed under cc by-sa 3.0 with attribution required.