تبادل‌نظر

دعوت به تبادل نظر: آیا جاوا برای تولید نرم‌افزارهای عمومی گزينه مناسبی است؟

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

 در دنیا، جاوا برای تولید انواع نرم‌افزارها استفاده شده است: نرم‌افزارهای بزرگ سازمانی (مانند پورتال‌های شرکت‌ها و دانشگاهها، نرم‌افزارهای بانکی و بیمه‌ای و بورس)، نرم‌افزاهای مدیریتی (مانند سامانه‌های مدیریت سیستم‌های مخابراتی و نفتی) و نرم‌افزارهای شخصی و دسکتاپ، و البته نرم‌افزارهای عمومی.

حال سؤال این‌جاست: آیا جاوا برای تولید نرم‌افزارهای عمومی گزينه مناسبی است؟ نرم‌افزارهای عمومی با تعداد فراوان کاربران سروکار دارند و حجم تعاملات کاربران با این نرم‌افزارها و بار کاری آن‌ها بسيار زیاد است. اما در مقابل (معمولاً) فرایندها و روال‌های کاری بسيار ساده و سريع هستند.

 امروزه بسياری از شرکت‌های نوپا (startup) از زبان‌هایی مانند پایتون، اسکالا و PHP برای تولید نرم‌افزارهای عمومی استفاده می‌کنند. بسياری از شرکت‌های بزرگ هم از این فناوری‌ها استفاده می‌کنند. با این اوصاف، آیا هنوز جاوا گزينه مناسبی برای این کار است؟ نقاط ضعف و قوت جاوا در این عرصه چیست؟ چه پارامترهایی در بازار (تولیدکنندگان نرم‌افزار و مصرف‌کنندگان) ایران باید موردتوجه قرار گیرد؟

 منتظر شنیدن نظرها و تجربه‌های شما در این زمينه هستیم. لطفاً از طريق بخش «نوشتن دیدگاه» (در پایین همین مطلب) در این بحث شرکت کنید. دانش و تجربه شما، حتی در حد چند جمله کوتاه، برای خوانندگان و تصمیم‌گیرندگان این عرصه مفید و راهگشا خواهد بود.

نوشته های مشابه

‫26 دیدگاه ها

  1. سلام . از اساتید گرامی که به طور کامل جواب دادن تشکر .
    سوالی داشتم که لطفا جواب بدید ممنون میشم .
    1 : اگر کسی بخواد فروشگاه اینترنتی بزنه و یک برنامه نویس java استخدام کنه . آیا بعد از اتمام پروژه میشه بعد از چند وقت به یک نفر دیگه داد برای توسعه ؟ یا فقط باید همون شخص باشه ؟
    چون در زبان asp.net من شنیدم که اگر کسی بخواد برنامه بنویسه بعد از اینکه پروژه تموم میشه شخص دیگری نمیتونه ادامه بده یا حوصله خوندن ندارن یا مشکل چیزه دیگه ای هست.
    2 : میخواستم فروشگاه اینترنتی بزنم با زبان java . به نظر اساتید گرامی انتخاب خوبی هست ؟ یا asp.net یا c# یا c++ بهتر هست ؟
    کل افکارم برای آینده هست . که بتونم مثلا یک برنامه نویس آوردم بگم فلان جارو عوض کن یا این امکان رو میخوام یا هر چیز دیگه .

  2. درسلام
    با سپاس از نظرات مفید و خوب دوستان.

    من هم در چند سال اخیر تجربیاتی در پروژه های جاوا و .net و پایتون و کارهای Client-side‌ و Desktop‌ داشتم که به نظرم هر یک از این زبان ها واقعا کاربرد خاص خودشون رو دارن و در زمینه هایی بهتر اند. مثلا به عنوان یه استارت آپ که مشتکل از آدم های جوون و معمولا کم تجربه است شاید گزینه هایی مثل پایتون به دلیل سرعت در راه اندازی اولیه یه راه کار و صرفه جویی در هزینه ها واقعا گزینه بهتری می تونه باشه. معمولا بحث بودجه اجازه نمی ده به یک استارت آپ که روی راه اندازی یه راهکار جاوایی که به نسبت بسیار پیچیده تر از سایر پلتفرم ها هست فکر کنه. البته اگر به دنبال ساخت یه چارچوب خوب برای چند سال آینده باشیم و هزینه slow start اولیه ای که وجود داره رو بشه تحمل کرد جاوا گزینه بسیار بهتری (به نظر شخصی من) از زبان هایی مثل پایتون خواهد بود. دلیلش هم این هست که برای کارهای حرفه ای و منظم و اصولی اساسا فریم ورک های قوی تری در زبان جاوا پیدا میشه که علیرقم پیچیدگی در راه اندازی محصول نهایی با کیفیت تری رو می سازن. یه مسیله ای که باید در مورد جاوا در نظر بگیریم این هست که بسیاری از دوستانی که اینجا هستند سال ها جاوا کار کردند و میزان سختی و راحتی کار با جاوا اونقدر که برای یک تیم تازه کار یا ناآشنا با جاوا قابل لمس هست برای دوستان نیست.

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

    در مورد بحث Template Engine و کلا لایه View تیم ما به طور کامل فریم ورک های .net و جاوا رو کنار گذاشت و از AngularJS استفاده می کنیم. چند دلیل عمده برای ما وجود داشت که عبارتند از:
    *‌ کلاینت های ما معمولا موبایل دیوایس ها و وب هستند و استفاده از مدل REST امکان بازاستفاده بیشتری از کدهای سرور رو میده و هزینه کمتری داره.
    *‌ مدل MVC‌ در سمت جاوااسکریپت بسیار قوی هست و نگهداری کدها با فریم ورکی مثل Angular بسیار بهتر و راحت تر هست
    * مدل های Single Page و وب سایت های کاملا آژاکس ای پیشفرض این فریم ورک ها هستند
    * معمولا چون تکنولوژی های کلاینت مستقل از سرور میشن آموزش افراد جدید بسیار ساده است و نیازی نیست آگاهی یا وابستگی به سرور داشته باشند
    * فریم ورک های به خصوص جاوایی برای دادن سرویس های REST بسیار خوش ساخت تر و بهتر و ساده تر از حالت دارای View هستند به خصوص اینکه وابستگی به View Engine هم نخواهیم داشت و صرفا در لایه Object کار می کنیم
    * امکان تست سرویس ها و مدل های REST معمولا بیشتر و راحت تره
    * امکان Deploy ساده برای کارهای Scalable . مثلا خود ما از Spring boot و Jetty جهت دادن سرویس های REST و از AngularJS به همراه nginx جهت ارایه محتوای ثابت استفاده می کنیم. به نظرم اینکه خیلی از Html و اسکریپت های ما کامپایل بشه به جاوا و هر بار نوشته بشه روی شبکه خیلی کارایی رو کاهش میده در حالی که nginx برای این کار بهینه تر هست.

    از بحث منحرف شدیم.

    در نهایت مشکلاتی هم به نظرم جاوا (نه صرفا زبان بلکه اکوسیستم) داره:
    * زبان با وجود اینکه ویژگی های زیادی بهش اضافه شده در نسخه ۸ ولی همچنان ضعیف هست. اینکه هر ویژگی رو به زبان اضافه کنیم لزوما منطقی نیست. ولی به نظرم زبانی مثل C# با اینکه مفاهیم بسیار زیادی درونش هست اما همچنان از منظر ساختار شیی گرایی و نبود ضعف در طراحی بسیار قوی تر از جاوا هست. البته یادگیری همه ویژگی های اون سخت تر هست ولی اگر به اندازه Subset جاوا بخوایم یاد بگیریم تفاوتی از لحاظ زمان و هزینه نداره.
    * زبان هایی مثل Scala و Groovy‌ وجود دارند و میشه استفاده کرد ولی اساسا در تیم های کوچیک و متوسط وارد کردن یک زبان دیگر (روی JVM بودن به هر حال تاثیری در نگهداری نداره و چیز زیادی از سختی کار کم نمی کنه ) هزینه بر هست و به خصوص تعداد کسانی که این زبان ها رو بلدن خیلی خیلی کم هست. حتی خود ما هم برای اینکه بتونیم کتابخونه های جاوایی رو با اینها ادغام کنیم وقتی وارد جزییات کار میشیم می بینیم که کلی باید تجربه کسب کنیم که بتونیم واقعا بدون مشکل این کار رو انجام بدیم.
    * تعداد بسیار زیادی گزینه برای هر کار (ذاتا خیلی خوبه) ولی در عمل با تعداد زیادی گزینه مرده یا نابالغ و خیلی اوقات بدون مستندات کافی و Community ضعیف طرف هستیم که عملا کار رو به جای راحت کردن سخت می کنن.
    * بحث مدیریت وابستگی ها که حتی با وجود استفاده از ابزارهای متنوعی مثل Maven و Gradle و چند سال تجربه همچنان در مقایسه با بقیه اکوسیستم ها عذاب آور هستند

    جمع بندی من این هست که جاوا برای بسیاری از کارها خوب هست (لزوما بقیه بد نیستن) ولی در مواردی که نیاز به سرعت بالا با فرض تجربه کم هست می شود از گزینه های Noobie Friendly تر استفاده کرد. معمولا هم برای ساخت یک چارچوب اولیه خوب در جاوا نیاز به حدود یک سال آزمون و خطا هست و بعد از اون از لحاظ Productivity راهکار ساخته شده به نظر من می تونه با بقیه رقابت کنه. در زمینه های خاص مثل Desktop یا سمت کلاینت هم به نظرم تکنولوژی هایی مثل C# یا AngularJS بسیار قوی تر هستند که اصولا می تونن به صورت موازی در کنار جاوا مورد استفاده قرار بگیرند.

    ببخشید طولانی شد.

  3. با سلام خدمت همه‌ی اساتید محترم.

    دوست داشتم چند نکته به فرمایش دوستان اضافه کنم:

    به نظرم برای نرم‌افزارهای بزرگ به چیزی به جز جاوا نمی‌توان فکر کرد. خیلی از شرکت‌ها هم که به صورت نوپا کار رو آغاز کردند پس از زیاد شدن کاربران به سمت جاوا و اسکالا رفتند. چند سالی هست که community کاربران جاوا به سمت این مطلب رفتند که سرعت کار رو بالا ببرند. دوستانی که خیلی به فکر سرعت بالا در توسعه هستند می‌توانند به چارچوب‌های Play و Spring Boot و Spring Roo یک نگاهی بیاندازند.

    در جواب دوستی که گفتند جاوا در لایه‌ی View ضعیف هستش باید بگم که من خودم به شخصه خیلی با این موضوع مشکل داشتم و به صورت گسترده برای فناوری‌های لایه‌ی View در جاوا جستجو کردم و باید بگم که از هیچ کدوم از لایه‌های JSP و JSTL و JSF و Thymeleaf و … رضایت نداشتم و دلیل اصلی اون هم نداشتن type برای متغیرها در این تکنولوژی‌ها بود. تکنولوژی GWT نیز مناسب بود ولی به نظرم کار با اون خیلی سخت و پیچیده است. در حال حاضر، من به شخصه به Twirl که template engine چارچوب Play است علاقه دارم. Twirl مدت زیادی هست که از توی چارچوب Play بیرون اومده و به راحتی می‌شه در چارچوب‌های دیگر مانند Spring مورد استفاده قرار بگیرد. از مزیت‌های اصلی Twirl می‌توان به داشتن type برای متغیر‌ها، کامپایل شدن این تمپلیت‌ها، و پشتیبانی IDEهای اصلی جاوا (eclipse و intellij) اشاره کرد.

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

    در آخر می‌خوام بخاط جسارتی که کردم و در محضر اساتید اظهار نظر کردم معذرت خواهی کنم.

    موفق باشید

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

  5. البته به جهت جلوگیری از برداشت نادرست از صحبت هام اضافه کنم که:
    اصول و الگوهای شی‌گرا واقعا لازم هستند و در اغلب زبان ها حتی python! تا جای ممکن رعایت شده اند. گذشتن از این اصول به هیچ عنوان جایز نیست.
    روی صحبت های بنده بیشتر مخصوص سرویس های عمومی بود که سرعت توسعه کسب و کاری و چابکی بسیار بسیار در آن مهم است. از همین رو هم هست که Java رو برای SPL بهترین می دونم.
    واقعا هیچ وقت چیزی تحت عنوان Golden Hammer یا Silver Bullet وجود ندارد. یه وقت دوستان ناراحت نشن :-“

  6. در مورد صحبت دوستان چند نکته به ذهنم رسید
    .
    زبان جاوا یکی از ساده ترین زبانهای دنیاست. چیزی که جاوا را پیچیده کرده ساختار زبان نیست بلکه زیاد بودن امکانات و تنوع ارائه کنندگان است. در نتیجه نقطه صفر شروع کار با جاوا دورتر از بسترهای دیگر است. مشکل کمبود نیرو و عدم اقبال startup ها را می توان در همین مساله ریشه یابی کرد.

    من تجربه کد زدن با پایتون را ندارم و از لذتی که طرفداران پایتون را پابند کرده بهره نبردم ولی آنقدری که در جریان کار تیمهای پایتون بودم دیدم با مشکلاتی مواجه می شدند که در جاوا کاملاً حل شده است. مثلاً در هنگام تغییر نسخه اوراکل به مشکل driver برخورد کردند. یا برای تولید گزارش pdf به شکل صفحه بندی شده دچار دردسر شدند. زمان تولید کم بود ولی پشتیبانی به سادگی جاوا نبود.

    فقط ساختارهای زبان نیست که productivity را بالا می برد. در پایتون خیلی از امکاناتی که در جاوا وجود دارد با آن کیفیت وجود ندارد. مثلاً Report Engine در تراز BIRT و Jasper Report یا Rule Engine در تراز Drools یا Process Engine در تراز Activiti و JBPM. حتی امکانات بدیهی مثل JMX و JDBC با این کیفیت و سهولت وجود ندارد. نبود چنین امکاناتی زمان پروژه را تلف می کند و کیفیت محصول را پایین می آورد. البته تبعاً یادگیری این امکانات نقطه شروع را دورتر می کند.

    بیشتر بودن productivity زبانهایی مثل pyton و ruby فقط به داینامیک بودن آنها برنمی گردد بلکه بعضی از ساختارها و امکانات زبان هم در آن تاثیر دارد. خیلی از این امکانات در java 8 گنجانده شد. با این حال اگر به زبانهای دینامیک علاقه دارید پیشنهاد می کنم Groovy را تجربه کنید.

  7. ممنون از سوال خوبتون و همچنین از نظرات دوستان که خیلی جالب بود.

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

    Originally I was going to program twttr in Python, C, & Ocaml. But, I got @florian who was a core contributor to Ruby on Rails.

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

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

    مثلا به دلایل زیر توییتر کم کم روی scala رفت:
    http://ruby.about.com/b/2011/04/09/twitter-is-slowly-abandoning-ruby.htm

    به طور خاص درباره زبان جاوا (نه JVM) من فکر میکنم به دلایل سنتی بیشتر حوزه enterprise رو در قبضه خودش داره و برای استارتاپها خیلی گزینه محبوبی نیست. ولی شکی هم ندارم که اگر تیمی روی زبان جاوا مسلط باشن و بخوان ایده ای رو شروع کنن گزینه بدیهی خود زبان جاوا هست و قطعا هم بعدا از این انتخاب پشیمون نمیشن. اگرچه ممکنه کم کم پی ببرند که بهتره در کنارش برای بعضی کارها (مثلا کارهای ops) از python و زبانهای اسکریپتی استفاده کنند. روند هم که به سمت رایانش ابری و microservice هاست که دیگه تا حد زیادی زبان رو به یک گزینه غیر کلیدی تبدیل میکنه.

  8. با سلامی دوباره!

    بروس اکل خودش یک شرکت دارد که در آن به زبان پایتون کد می زنند و صرفا یک show تبلیغاتی راه ننداخته بود.

    In 1997, Bruce founded and is currently the President of MindView, Inc., a California-based corporation focused on providing outstanding training and consulting experiences in OO Design, and Python

    ضمنا متوجه نمیشم که نظر آقای بروس اکل در خصوص قدیمی شدن C++ و بی معنی بودن خیلی از سختی هایی که اون داشته چه ربطی به نظر ایشون راجع به python داره! در اون سخرانی صرفا گفتن که:

    Go makes much more sense for the class of problems that C++ was originally intended to solve.
    این چه ارتباطی با سخنرانی ایشان در خصوص پایتون دارد؟

    من توصیه می کنم به سایت شخصی خود ایشون برای شناختش مراجعه کنید. به این راحتی یکی از موثرترین و مشهورترین افراد در آموزش Java و اغلب زبان های برنامه نویسی رو زیر سوال نبرید!‌ 😛

    همچنین در خصوص Ugly code باید بگویم که بنده با Java غریبه نیستم. Ugly code زدن بسیار بسیار بیشتر از اونکه به زبان وابسته باشه به developer وابسته است. هنوز کابوس کیلومترها خط کد جاوا وسط jsp را که در یک پروژه مهم را تجربه کردم را فراموش نکرده ام! ضمناً بسیاری از ضعف های dynamic typing از طریق code assess های قدرتمند Pycharm (برای زبان پایتون) از بین رفته.

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

    در پاسخ به فرمایشات استاد گرامی آقای پیشوایی نیز عرض می کنم که آن تیمی شماره صفحه های گزارش خود را درست نکرد به علت مسائل مدیریتی بود و در اون برهه صلاح این بود تیم وقتش رو روی کار دیگری بگذارد! (بحث شخصی شد)
    بنده در محیط های جاواکار نیز حضور داشته ام. برای نصب کل پروژه بر روی لپ تاپ یکی از اعضا به همراه اوراکل و… بسیاری از اوقات مشکلات فراوان می خورند و ساعت ها درگیر همین کار ساده می شوند. بله قطعا در این بحث افرادی حضور دارند که سال هاست با جاوا انس گرفته اند و دیگر این مسائل برای آن ها مطرح نیست. اما باید همه اقشار را نگریست…

    در خصوص پکیج هایی که آقای پیشوایی نام بردند هیچ شکی نیست که java در Enterprise حرف اول را میزند. بحث ما روی سرویس های عمومی هست که نه workflow management system می خوان (و اگر بخوان هم در حدی نیست که نیازمند یک engine برای این کار باشد چرا که باید در بهینه ترین حالت ممکن باشد و تعداد فرایند ها معمولا کم است و نیازی هم به designer و… ندارد.) و نه Report generator و نه حتی Oracle. بیشتر امکانات و بسترهای scalability می خوان که اغلب پکیج های موجود مثل Hadoop برای همه زبان ها پشتیبانی می شوند.
    البته اگر سرویس ارائه شده یک سرویس سازمانی cloud باشد باز هم java مناسب تر است.

    ضمناً بنده نگرش جاوارو کاملا با Play متفاوت می دونم، نگرش جاوارو Spring، و JavaEE می دونم.

    باور بفرمایید بسیاری اونهایی که از پایتون (یا Ruby) حمایت می کنن روزی خود جاوا نیز کد زده اند. حداقل می دونن Protected Variation , inversion of control یعنی چه! می دانند DIP، PLK یعنی چه. اما خود را با این اصول محاصره نمی کنند و تمرکز خود را بر روی مسائل دیگری نیز می گذارند. جاوا نیز اخیرا بسیاری از رفتارهای خود را اصلاح کرده java8 را بیرون داده. روز به روز بیشتر به سمت Convention over configuration حرکت می کند.

    در انتها تاکید می کنم که تمام صحبت هایی که بنده کردم برای یک سرویس عمومی بود نه Enterprise و نه Software Product Line.

  9. به نظر من مهمترین ویژگی جاوا متن باز بودن اون نسبت به .net هستش که باعث میشه خود oracle ویژگی های جاوا رو به صورت JSR منتشر کنه و شرکت های مختلف اونهارو پیادسازی کنند و در نتیجه فریمورک های مختلفی با توجه به نیاز داشته باشیم و قدرت انتخاب خیلی زیادی داشته باشیم. و همچنین ما دسترسی کاملی به سورس این فریمورک ها داریم.

  10. این که چه سرویسی از چه پلتفرمی استفاده کرده به نظرم خیلی دلیل بر ضعیف یا قوی بودن یه زبان نمی شه تعبیرش کرد.

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

    ولی همین که دوستمون اشاره کرد که تو چند سال اخیر کم استفاده شده از جاوا بر می گرده به این قصیه که خیلی از فریم ورک های جاوا پیچیدهگی بیشتری دارند به نسبت زبان های دیگه و یادگیریشون زمان بیشتری می بره.

    ولی فکر می کنم پروژه spring-boot‌ می تونه محبوبیت خوبی بدست بیاره.

  11. با سلام

    اکثر نکات رو دوستان اشاره کردند. من به مدت حدود 3 سال مسئول چند تیم بودم که از پایتون برای توسعه استفاده می کردن. در اون محیط بودند کسانی که مسلط بر جاوا بودند و در ابتدای کار خیلی هم بر روی اینکه جاوا بهترین زبان است تاکید داشتند. اما به مرور چنان پایتون دغدغه های فنی و مدیریتی رو از بین می بره که می تونم به جرات بگم که شما 100% تمرکزتون رو می تونید بذارید روی طراحی کسب و کار، بهبود واصلاح آن. تقریبا واضحه که اون چه که باعث میشه در این روزگار مردم یک سرویس را رها کنند و به سراغ سرویس دیگری بروند طراحی مناسب تر کسب و کاری و UX سرویس بهتر است. زمانی که مشتریان سرویس شما به شما متعهد شدند و سایت شما با رقبا فاصله گرفت اون موقع تازه (احتمالاً) دغدغه هایی به میان میاد که جاوا رو تا حدودی برتری میده به پایتون و سایر زبون های اسکریپتی. اون موقع هست که صاحب سرویس باید به فکر انتقال “بعضی جاهای” سیستمش بکنه. تازه با پیشرفت صنعت رایانش ابری این مسئله روز به روز احتمالش کمتر میشه. چرا که هزینه تغییر بسترهای رایانش ابری بسیار کمتر است از بازنویسی بخش هایی از سامانه. اکنون دغدغه بیشتر برنامه نویسان سرویس های عمومی بحث های رایانش ابری و استفاده از پایگاه داده های توزیع شده و کلا بحث کلاسترینگ است که اغلب فارغ از زبان هستند (البته سرعت زبان جاوا و نیاز به اون رو نفی نکردم)

    در توسعه به زبان پایتون به محض اینکه یک نفر از تیمتون بره سریع می تونید یک نفر دیگه رو پیدا کنید که حتی اگر پایتون هم بلد نباشه و در مدت بین 20 الی 100 نفر ساعت اون شخص بشه مثل بقیه اعضا. یکی از مشکلات جاواکارها اینه که فقط شرایط خودشون رو می بینند. در حالی که برای توسعه چابک باید تماما افراد با تمام قابلیت ها و طبیعت کار واقعی (آمد و شد افراد و تغییر تیم ها) رو دید. این در حالیه که خود من که حدود 7 الی 10 ساله که جاوا و جاوا کارهارو میشناسم به تعداد انگشتان دستم می تونم به یک جاوا کار اعتماد کنم. از بس که ابزارهای مختلف، کانفیگ های گوناگون، ارورهای پیچیده و حفظیاتی داره که “بروس اکل” نویسنده کتاب Thinking in Java در سال 2008 در کنفرانس PyCon یک ارائه ای می دهد تحت عنوان Why I Love Python و توش میگه من که سال‌هاست مدرس جاوا هستم هنوز هم خودم برای خیلی چیزهای پیش و پا افتاده باید برم سرچ کنم چون نمی تونم پیکربندی های متعدد جاوارو حفظ کنم. به گفته ایشون سرعت توسعه با زبان پایتون بین 3 الی 5 برابر جاواست و به نظرم من اگر این نسبت فقط 1.5 برابر هم بود برای fail شدن یک سرویس عمومی در مقایسه با پیشرفت رقباش کافی بود.

    چالش دیگری که در زبان های dynamic typed به ذهن میرسه اینه که در تیم های بزرگ چالش بر انگیز است. در جواب به نظرم صرفا باید به آمار “زمان توسعه این زبان ها در مقابل جاوا”‌ رجوع کرد. قطعا در بسیاری از موقعیت‌ها مشکلاتی را ایجاد خواهد کرد و البته در بساری از موقعیت های دیگر سهولت های فراوانی را به همراه دارد. اما در کل زمان توسعه بسیار کمتر خواهد بود و در انتها آنچه که برای مدیران و در کل صنعت اهمیت دارد زمان توسعه و نگهداری (نگهداری نرم افزار نیز پارامتر های گوناگونی دارد، فقط زبان نیست) نرم افزار است.

    پ.ن:‌ پایتون صرفا یک مثال از زبان اسکریپتی بود. این مسائل می تونه برای Ruby و سایرین نیز برقرار باشد. اما مسئله community زبان نیز خیلی مهمه. بسیار سخته که بشه با زبانی که قبلا به وفور استفاده نشده حالا هرچقدر هم طراحیش خوب باشه کارهای بزرگ کرد مخصوصاً‌ در ایران که با کمبود متخصص مواجه هستیم.

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

      صحبت‌های جناب Bruce Eckel علی‌رغم احترام فراوان معمولا ماهیت تجاری دارد و ایشان در آستانه معرفی هر کتاب جدیدشان چنین صحبت‌هایی را مطرح می‌کنند. به عنوان مثال در سال 2011 برای معرفی زبان Go به اشکالات زبان ++C می‌پردازند و آن را «waste of time and effort» محسوب می‌کنند. یا در سال 2013 برای کتاب جدیدشان که “Atomic Scala” نام دارد از عبارت «Learn Programming in a language of the Future» استفاده می‌کنند که واضح است نمی‌توان به چنین صحبت‌هایی استناد کرد.

      یکی از دشواری‌های جدی زبان‌های اسکریپت نویسی مانند پایتون و روبی در دشواری نگهداری از آن‌هاست. در واقع شاید در ابتدا به علت وجود قابلیتهایی مانند Dynamic Typing در این زبان‌ها بتوان در مدت کوتاهی کد نوشت ولی در کارهای تیمی و بدون نظارت فنی و کیفی دائم و مستمر روی همه کدها به سرعت در آنها ugly code رخ می‌دهد که منجر به افزایش زمان نگهداری و سختی Debugging و رفع اشکال می‌شود. بنابراین گرچه شاید ساختارهای سفت و سخت زبان جاوا در آغاز کار محدودیت به نظر برسد اما امکان بهتری برای برون‌سپاری هر ماژول به افراد تیم و سپس تست موارد خواسته شده و در نهایت debuging و پشتیبانی را فراهم می‌کند.
      ضمنا بحث Backward Compatible بودن نیز یک دغدغه جدی برای زبان‌هایی است که می‌خواهند چند دهه به فعالیت خود ادامه دهند. چنین امکانی همیشه در زبان جاوا در نظر گرفته شده و خیلی محتاطانه با آن برخورد شده است. اما در زبان‌های اسکریپت نویسی ممکن است مثلا کدهای نوشته شده روی ورژن ۲ یک زبان، روی ورژن ۳ آن اجرا نشوند و ورژن سه یک ورژن مجزا به شمار رود.

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

      من تجربیات موفقی از تولید نرم‌افزارهای تحت وب مبتنی بر جاوا دارم و عمیقا معتقدم با استفاده از زبان جاوا نیز می‌توان به شکل Agile برای یک Startup در زمانی کوتاه برنامه‌هایی سریع و قدرتمند و قابل نگهداری در طولانی مدت نوشت.
      منظور من استفاده از فریمورک‌های سنتی مبتنی بر جاوا مانند Spring/Hibernate/GWT نیست چون چنین فریمورک‌هایی که اغلب قدمتی بیش از یک دهه دارند منجر به افزایش زمان تولید نرم‌افزار و کاهش بهره‌وری تیم می‌شوند که شرکت‌های مطرح نرم‌افزاری معمولا با تولید فریمورک‌های اختصاصی خود این نقیصه را تا حدی برطرف کرده‌اند. منظور من بیشتر این است که در سال‌های اخیر فریمورک‌های سریع و توان‌مندی مانند Play و ZK و Spring MVC و Spring ROO و Spring Boot مطرح شده‌اند که توانسته‌اند بخش زیادی از امکانات سایر زبان‌های اسکریپت نویسی را به دنیای جاوا اضافه کنند.
      از طرف دیگر پشتیبانی مناسب شرکت‌های عظیمی مانند Oracle و Apache و Spring و Google و غیره را نباید فراموش کرد که باعث شده همیشه این زبان یک زبان زنده و پر استفاده باشد و از این منظر فقط خانواده محصولات Microsoft را می‌توان با جاوا مقایسه کرد.

  12. خیلی وقت بود که می خواستم این سوال رو مطرح کنم.
    چون من هم از زمانی که برنامه نویسی جاوا رو شروع کردم مشکلات زیادی داشتم. حتی خیلی از این مشکلات بعد از چندین سال هنوز حل نشده.

    مشکلاتی که جاوا کارهایی که برای توسعه Web Application از جاوا استفاده می کنند :

    – کمبود وب فریم ورک

    – : وب فریم ورک های که داره یا ساختار قدیمی دارن یا Commiunity غیر فعالی دارن و یا برای پروژه های کوچیک یا متوسط خیلی مناسب نیستن ( بدلیل پیچیده گی بیش از حد ).
    به نظر من تنها فریم ورکی که کامیونیتی خوبی داره و ساختار مدرنی داره Spring ه که البته واسه هر پروژه ای مناسب نیست چون برنامه نویسی که می خواد تو یه پروژه ازش استفاده کنه باید با مسایل زیادی دست و پنجه نرم کنه و چیزای زیادی بدونه. برای مثال فرض کنید که یه برنامه نویسی می خواد باهاش یه بلاگ درست کنه نیازی نیست که از Dependency Injection‌ استفاده کنه. ولی مجبوره که استفاده کنه. و نکته دیگه که انقدر امکانات مختلف داره که یادگیریش واسه تازه کار ها خیلی زمان بر باشه. مثلا من یه سری فیچر ها دیدم داخل اسپرینگ که فکر نمی کنم که فریم ورک خودشو قاطی اون مسایل بکنه و برنامه نویس خودش به صورت دستی خیلی راحت تر بتونه اونو انجام بده.

    درسته جاوا پر استفاده ترین زبان برنامه نویسی ه ولی واسه Web Application‌ ها فکر نمی کنم زیاد محبوب باشه. که شاید این باعث شده که خیلی از فریم ورک های قدیمی عین قدیم توسعه داده نشن و فریم ورک جدیدی بوجود نیاد. البته PlayFramework هم انتخاب خوبی می تونه باشه. ولی یه مشکلی که داره اینکه که کلا راهشو از جاوا داره جدا می کنه.

    – نبود یه View Engine خوب

    من اوایل فکر می کردم JSP خیلی خوبه ولی وقتی با Razor (‌ Asp.net MVC View Engine ) و یا Twig ( PHP View Engine ) کار کردم. فهمیدم که واقعا JSP عمرش سر اومده. و چقدر امکانات محدود و ساختارش قدیمی شده. البته گزینه های دیگه ای هم وجود داره مثل FreeMarker و Thymleaf‌ ولی اونها هم مشکلاتی دارن. و در اکثر موارد انتخاب خوبی نیستن.

    – Deploy کردن یه پروژه Web Application‌ جاواست ( که البته این تو ایران بیشتر احساس می شه )

    که نظرم خیلی مشکل بزرگه واسه کسایی که می خوان پروژه های کوچیک یا اولین پروژه شونو با جاوا استارت بزنن. در این زمینه چند تا انتخاب وجود داره :

    – یه سرور مجازی بگیری و خودت هر چی می خوام نصب و کانفیگ و نگهداری کنی.
    – از سرویس های ابری ( Paas ) استفاده کنی. ( heroku , appfog , openshift , cloud foundary , … )

    روش اول به غیر از اینکه باید لینوکس بلد باشی و وقت زیادی صرف کنی واسه نگهداری و … پروژه , هزینه ی تقریبا زیادی می خواد شاید واسه خیلی از Application‌ ها منطقی نباشه اگه سرور داخل ایران باشه هزینه بیشتر می شه. که اگر از سرویس های خارجی ( مثل دیجیتال اوشن و … ) استفاده کنید هزینه کمتر می شه ولی سر پرداختش داستان وجود داره.

    روش دوم هزینه ی خیلی زیادی داره و با توسعه پروژه و نیاز بیشتر به منابع خیلی خیلی گرونتر خواهد شد که معمولا که واسه کاربرای ایرانی با این قیمت دلار زیاد منطقی نیست. و معمولا هم اون بخش از سرویس شون که رایگان می دن رو برای اجرای یه پروژه ی واقعی مناسب نیست و محدودیت هایی داره. ( مثل اینکه نمی تونه از دامین خودت استفاده کنی و … )

    فکر کنم اکثرا روش اول رو ترجیح می دن مثل خودم ولی تا بخواین کانفیگ کردن لینوکس و Application Server‌ ها و ابزار مختلف جاوا رو برای Production‌ یاد بگیرید. اولین پروژه هایی که اجرا کردید ۲-۳ ماه طول می کشه تا به نقطه stable‌ ای برسه و شاید اصلا fail‌ بشه. 🙂

    – کمبود جاوا کار
    یکی از معظلات شروع یه پروژه با جاوا کمبود برنامه نویسه جاواست. واسه همین خیلی شرکت ها ترجیح می دن پروژه هاشونو با php‌ و یا Asp.net MVC انجام بدن.
    و این مشکل بر می گرده به منحنی یادگیری پایین فریم ورک های جاوا.

    1. سلام
      در مورد کمبود وب فریم ورک که اصلا موافق نیستم ! بعید میدونم هیچ زبان دیگه ای مثل جاوا دارای این همه تنوع وب فریم ورک باشه ! اما قوی بودن یا نبودنش قابل بحثه ! در مورد سیاست هایی که یک فریم ورک اتخاذ می کنه هم باید بگم که معمولا یک سری principle هست که مربوط به OO هستش و باید وجود داشته باشه! اینکه ما می تونیم بدون رعایت اونها هم کار خورمون رو پیش ببریم که امری مورهنه! اگر spring اومده بحث SRP رو در بخش IOC لحاظ کرده، یک امتیاز مثبت واسشه نه منفی (IMHO)

      منظورتون از view engine رو متوجه نمیشم! اما شما هیچ محدودیتی در انتخاب در لایه presentation ندارین! یکم واضح بگین که مثلا در .net چه چیزی هست که در جاوا نیست!

      در مورد deploy باهاتون موافقم و این مشکلات در ایران هست.

      کمبود جاوا کار هم تقریبا در تمام دنیا یه مشکل بزرگه و همه می دونیم که سالانه افراد بسیار زیادی به قصد برنامه نویسی جاوا جذب شرکت های خوب میشن…

      اما اعتقاد دارم جاوا یکی از نزدیک ترین زبانها به دنیای OO هست و کسانی که مفاهیم مهندسی نرم افزار رو خوب فرا گرفته باشن و OO رو درک کرده باشن به راحتی میتونن با جاوا زندگی کنن.

  13. سلام
    به نظر من هم اکنون در جامعه امروزی بحث اینکه چه زبانی برای چه کاری نیازه خیلی مطرح نیست چون تقریبا اکثر زبان های مطرح جایگاه و نقششون مشخص شده. اما به نظرم جاوا در بخش سرور جایی که تعداد کاربرها و بار کاری خیلی بالاست عالی عمل می کنه. بخش کلاینت بخشی نیستش که بخواد معماری بخش سرور رو تحت تاثیر قرار بده ! شما به راحتی می تونین با expose کردن سرویس های rest، در کلاینت از هر تکنولوژی استفاده کنی.
    جدیدا زبانهای زیادی مطرح شدن که شاید از نظر یادگیری یه مقدار از جاوا راحت تر باشن ( که با این قسمت هم مشکل دارم، چون به نظرم زبان صرفا یک syntax هست و مهم concept پیاده سازیه)ُ اما تا اونجایی که من اطلاع دارم شرکت های بزرگ اکثرا از زبان خاصی استفاده نمی کنن و framework های خاص خودشون برای هر پروژه طراحی کردن و افرادی که وارد شرکت میشن باید کار با اون زبان رو یاد بگیرن و بشون آموزش داده میشه. در واقع کسی که مفهوما بدونه قراره به چه شکلی باید پیاده سازی رو انجام بده چه وابستگی باید به یک زبان باید داشته باشه !
    در خلاصه من جاوا رو در تمامی انواع پروژه ها عالی می بینم چون هیچ وقت محدودیت غیر منطقی رو در اون ندیدم ( IMHO).

  14. سلام،
    اسکالا (Scala) هم یک زبان اسکریپتیه که با جاوا نوشته شده و همه ی فریم ورک هایی که برای اسکالا نوشته شدند، یا با جاوا مرتبط هستند یا امکان توسعه با زبان جاوا را هم فراهم کردند

  15. سلام

    من فکر می کنم جاوا گزینه مناسبی برای سرویس های عمومی با حجم تراکنش بالا نیست. خصوصا برای استارتاپ ها.

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

    جدا از تمام این بحث ها کافیه یک نگاهی به وبگاه های بزرگ و فناوری های استفاده شده شون بندازید تا متوجه بشید که جاوا در حال حاضر دیگه جز گزینه های مطرح در ابن زمینه نیست.

    فهرست سایت های بزرگ بر روی جاوا
    http://www.quora.com/Which-large-scale-sites-are-based-on-Java
    لطفن به زمان تاسیس این سایت ها دقت کنید.
    مقایسه کنید با این فهرست
    http://www.quora.com/What-is-the-most-famous-software-written-in-python

    و باز صد البته به سال تاسیس دقت کنید.
    به نظرم حداقل در 5 سال گذشته جاوا گزینه مطرح برای ایجاد مجموعه های بزرگ نبوده.
    این هم بحثی در کورا در این خصوص
    http://www.quora.com/Why-is-Java-NOT-used-for-web-front-end-rather-than-PHP-Python-Ruby-etc-in-sites-like-Facebook-Quora-Twitter

    شاید از وضعیت با گسترش دیگر jvmای ها مانند اسکالا و زیرساخت های سریعی مثل play عوض بشه ولی به نظرم در کوتاه مدت جاوا گزینه مناسبی نیست.

    اگه بخوام خلاصه کنم من به دو دلیل فکر می کنم جاوا برای سرویس عمومی با بار واقعن زیاد (که شاید تو ایران پیش نیاد)
    مناسب نیست
    1- سختی یادگیری و در نتیجه پیدا کردن برنامه نویس
    2- عدم تطابق با الگو DIY که به نظر می رسه برای حجم بار بالا لازمه.

    1. quora خیلی سایت خوبیه ولی به عنوان رفرنس نمیشه روش حساب کرد و چیزو ثابت نمی کنه مگر در مواقع خاص که مثلا در مورد ویکی پدیا سوال بپرسی خوده Jimmy wales جواب میده

    2. بحث کورا که لینکش رو گذاشتید فقط در مورد front-end است. سرویسهای عمومی غیر از front-end لایه های دیگری دارند که جاوا در آنها مزیت بیشتری دارند. ضمناً این بحث مربوط به سال 2012 است و بعید نیست با فراگیرتر شدن REST برخی شرایط تغییر کرده باشد.

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

  17. به نظر من هم JVM موجود بسٓیار مهمی هست و تا اطلاع ثانوی مهم خواهد بود. به دو دلیل:‌۱- بستر اجرای زبانهای مهمی مثل جاوا و اسکالا و گرووی است. ۲- بسیاری از ابزارهای مهم – که در پروژه‌های بزرگ لازم می‌شوند – روی JVM اجرا میشوند (مثل محصولات Message Queue و Big Data و …)

    البته، با وجودی که JVM موجود مهمی است، به نظر من دلیل نمی‌شود که «زبان جاوا» لزوماً و همواره بهترين گزينه باشد. مثلاً چرا فیس‌بوک به طور گسترده از PHP و توئیتر از اسکالا (و قبلاً روبی) استفاده می‌کنند؟

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

  19. فکر می کنم اگر موضوع public service را از startup ها جدا کنیم دقیقتر بشود نظر داد. بستر جاوا برای تولید public service (یا به قول شما نرم افزارهای عمومی) کمبودی ندارد.
    مشکل اینجاست که خیلی از startup ها تیم های جوانی هستند که دانش، ابزارها و امکانات لازم برای استفاده از جاوا را ندارند. بنابراین نمی توانند با سرعت و هزینه قابل قبول نسخ اولیه محصول خود را به بازار برسانند. بنابراین به سراغ گزینه های سهل الوصول تر می روند. در حالیکه سازمانهای باتجربه در زمینه جاوا با فراهم کردن مجموعه ای از امکانات به مرور هم کار خود را سرعت می بخشند و هم محصولات با کیفیت تری تولید می کنند.

  20. اگه منظورتون رو از نرم افزار عمومی درست متوجه شده باشم به نظر من بله جاوا برای این مدل نرم افزار ها نه تنها مناسب نیست بلکه در حال حاضر بهترین گزینه است. در حال حاضر سرویس های عمومی زیادی مثل جیمیل، توویتر یا لینکداین بر روی JVM پیاده سازی شده اند.

    اینگونه تصمیم گیری ها تقابل بین چابکی زبان برنامه نویسی و سرعت اجرا و بلوغ محیط زمان اجرای آن است. زمانی که برای شما فقط چابکی مهم باشد زبان هایی مثل پایتون یا روبی گزینه های خوبی هستند ولی وقتی سرعت اجرا و بلوغ محیط زمان اجرا مهم باشد JVM حرف اول را می زند (البته بعد از C و C++ که در این زمینه استفاده نمی شوند).
    در حال حاضر با تغییرات بنیادی که در جاوا ۸ شاهد آن بودیم جاوا در زمینه چابکی نیز حرف های زیادی برای گفتن پیدا کرده است.
    به نظر من در حال حاضر زبان برنامه نویسی GO تنها زبان برنامه نویسی بهمراه محیط زمان اجرایی است که شاید بتواند در آینده با جاوا رقابت کند.

  21. به نظر من جاوا یک زبان بسیار قدرتمند برای بخش Server-Side یک برنامه تحت وب است ولی امکاناتی که برای بخش Client-Side ارائه می‌کند به سهولت سایر زبان‌های Script نویسی نیست.
    همواره دغدغه‌های مختلفی مانند کارآیی، امنیت، گسترش‌پذیری، تعامل‌پذیری، سرعت کدنویسی و توسعه برنامه و سهولت نگهداری از کدهای قدیمی برای انتخاب یک چارچوب تحت وب وجود دارند که جاوا در اغلب این موارد نمره قابل قبولی کسب می‌کند.
    بسیاری از نقاط ضعف جاوا مانند سرعت پایین توسعه آن نیز به مرور زمان با روشهای دیگری مانند استفاده از زبان‌های اسکریپت‌نویسی مانند Groovy و Scala رفع شده‌اند.
    شاید بهترین راه حل، استفاده از امکانات زبان جاوا در سمت سرور و استفاده از فریمورک‌های مبتنی بر جاوااسکریپت در سمت کلاینت و اتصال آنها با استفاده از روشهای استانداردی مانند وب‌سرویس‌های مبتنی بر REST باشد

  22. با سلام
    در مورد مبحث ارائه شده یعنی این که آیا زبان برنامه نویسی جاوا زبانی مناسب برای نوشتن و توسعه برنامه های عمومی است یا خیر، به این سوال میتوان از چند جهت جواب داد.
    اگر شرکتی به دنبال ساخت برنامه هایی باشد که وابستگی به سکو و سیستم عامل نداشته باشد طبیعتا جاوا گزینه ی بسیار مناسبی است.
    اما اگر هدف نوشتن برنامه ی عمومی برای یک سیستم عامل خاص باشید مثل ویندوز شاید جاوا گزینه ی مناسبی نباشد چرا که یک مبحث مهم در دسکتاپ اپلیکیشن ها مربوط به واسط گرافیکی میشود که طبیعتا کلاس های Swing و AWT در برابر فناوری های مایکروسافتی بسیار ضعیف تر عمل میکنند.
    همان طور که احتمالا میدانید شرکت اراکل نیز برای حل این مشکل و نقیصه به فکر تولید تکنولوژی جدیدی شده و در سدد جایگزینی آن با Swing، AWT است. که اگر به خوبی اطلاع رسانی شود و برنامه نویسان به آن علاقه نشان دهند جاوا می تواند سهم بیشتری از برنامه های بازار را به خود اختصاص دهد.
    به طور کلی به نظر بنده ضعف جاوا در برنامه های کاربردی و عمومی و نه تجاری عدم قدرت آن در کلاس های Swing و AWT در مقابل C# و دیگر رقبا است.

دیدگاهتان را بنویسید

نشانی ایمیل شما منتشر نخواهد شد. بخش‌های موردنیاز علامت‌گذاری شده‌اند *

دکمه بازگشت به بالا