ওয়েব ফ্রেমওয়ার্কগুলি প্রোগ্রামিং ভাষার মতো সাধারণ, মার্জিত এবং মজাদার নয় কেন? [বন্ধ]

Question

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

তবে যখন আমি ওয়েব ফ্রেমওয়ার্কগুলি সম্পর্কে চিন্তা করি (আমি বেশিরভাগ পিএইচপি করি) - যেমন কেক, সিআই, সিমফনি, লারাভেল, জেন্ড, দ্রুপাল, জুমলা, ওয়ার্ডপ্রেস, রেলস, জ্যাঙ্গো ইত্যাদি I'm আমি দেবতার মতো নই।

এমন কোনও ওয়েব ফ্রেমওয়ার্ক কেন নেই যা আমাকে প্রোগ্রামিং ভাষার মতো সহজ, মজাদার এবং শক্তিশালী কাঠামো সরবরাহ করে?

Comments

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

— ইওফোরিক

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

— ইজকাটা

@ ইজকাটা তাদের প্রত্যেকের সাথে 10 বছর?

— ইউফোরিক

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

— ইজকাটা

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

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

Answer 1

আমি পাইথনের পাশে থাকলেও বছরের পর বছর ধরে আমার এই প্রশ্ন ছিল। এই ঘটনার জন্য আমার কাছে একটি ব্যাখ্যা নেই, তবে এখানে এই বিষয় সম্পর্কে আমার মতামত রয়েছে:

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

• এইচটিএমএল + সিএসএসের মধ্যে অবজেক্ট স্থাপনের জন্য স্বজ্ঞাত এবং গাণিতিক শব্দ মডেল নেই। এমনকি টিসিএল / টাকা জ্যামিতি পরিচালকদের সংজ্ঞায়িত করতে আইএমএইচও ভাল। এটি প্রোগ্রামারকে এইচটিএমএল রেন্ডারিংটিকে কঠোর শর্তে সংজ্ঞায়িত করতে এবং তার পরিবর্তে ভাগ্যের উপর নির্ভর করতে বাধা দেয়: "সম্ভবত এই ডিভি বেশিরভাগ ব্রাউজারে কাজ করবে"। এই দিকে কিছু ইতিবাচক বিকাশ রয়েছে যদিও উদাহরণস্বরূপ, এইচটিএমএল 5 এবং টুইটার বুটস্ট্র্যাপ।

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

• ওয়েব ব্রাউজারগুলিতে এখনও সামান্য অসম্পূর্ণতা রয়েছে এবং এটি ওয়েব-ফ্রেমওয়ার্কগুলিতে অপ্রয়োজনীয় জটিলতা যুক্ত করে

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

• ওয়েব-কাঠামো অগত্যা প্রচুর ধারণা এবং প্রসেসিং পাইপ যুক্ত করে এই জটিলতার বেশিরভাগের সাথে কাজ করে।

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

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

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

ওয়েব-ফ্রেমওয়ার্কগুলিতে সাধারণ কাঠামোগুলির অভাব হয় কারণ ওয়েব-প্রযুক্তি ডোমেনে এমন কোনও জিনিস নেই। নিম্ন-স্তরের বিমূর্ততা অগত্যা উচ্চ স্তরে ফাঁস হবে।

Answer 2

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

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

এই কি কখনও পরিবর্তন হবে? আমি এটাকে সন্দেহ করি. এটি ওয়েবের আর্কিটেকচারে একটি মৌলিক পরিবর্তন প্রয়োজন।

Answer 3

সাধারণত বললে, কারণগুলি একাধিক হতে পারে:

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

Answer 4

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

Comments

আমি +1 দিচ্ছি কারণ পোস্টের চমকপ্রদ প্রকৃতি সত্ত্বেও, এটি ঠিক যে ফ্রেমওয়ার্কগুলি অবশ্যই টুরিং-সম্পূর্ণ নয়। এটি একটি সম্পূর্ণ সাধারণ-উদ্দেশ্যমূলক ভাষার অঙ্কনের মধ্যে একটি, আপনি কীভাবে জানেন তা যদি কিছু করার ক্ষমতা।

— ইজকাটা