2009-02-18 16 views
11

अपनी परियोजनाओं के लिए, क्या आपके पास ग्रोवी के साथ एक अनुकूल अनुभव था? परियोजना कितनी बड़ी थी? क्या भाषा के साथ समस्याएं थीं? क्या आपने ज्योथन, जेआरबी या क्लोजर पर विचार किया था?ग्रोवी की आपकी राय क्या है?

+0

लौ युद्ध के लिए तैयार हो जाओ! – BobbyShaftoe

+0

यह स्टैक ओवरफ्लो है, चीजें थोड़ा अलग हैं। –

+0

दिलचस्प सवाल .. स्टैक ओवरफ्लो में स्टैक ओवरफ्लो होगा। – yogsma

उत्तर

7

मेरी टीम ने हाल ही में Grails (और निहितार्थ, ग्रोवी) का उपयोग कर एक छोटी AtomPub सेवा लागू की है। कुल मिलाकर, यह एक अच्छा अनुभव था। हमने संक्षेप में शुद्ध जावा और जेआरबी को विकल्पों के रूप में माना, लेकिन ज्योथन या क्लोजर नहीं। टीम ग्रोवी के साथ गई क्योंकि यह जेआरबी की तुलना में कुछ और परिचित प्रतीत होता था, लेकिन जावा की तुलना में अधिक लचीलापन प्रदान करता था।

यहाँ हम जिन समस्याओं का सामना करना पड़ा में से कुछ हैं:

  • कम से कम हम में से ज्यादातर (कितना बड़ा एक सौदा यह है व्यक्तिगत डेवलपर पर निर्भर करता है आप पूछ रहे हैं)
  • भीषण लिए इस्तेमाल किया गया उपकरण समर्थन स्टैक निशान (यह ग्रोवी के मुकाबले अधिक Grails 'गलती हो सकती है)
  • फ्लाई पर भाषा सीखने वाली पूरी टीम के साथ, एक सुसंगत, अच्छी तरह से पसंद की शैली
  • कम से कम आदर्श दस्तावेज़ीकरण पर पहुंचना मुश्किल था Grails के लिए (फिर, ग्रोवी की गलती नहीं); दस्तावेज़ तेजी से बदल रहे थे, इसलिए स्थिति अब
5

मैं वर्तमान में Grails का उपयोग कर एक छोटी खोजी परियोजना पर काम कर रहा हूं। ग्रोवी, केवल जावा का उपयोग करके मुझे कोई पिछला अनुभव नहीं था।

अभी तक, मैं काफी प्रभावित हूं कि मैं कितनी जल्दी उपयोग करने योग्य कुछ हैक कर सकता हूं, और ग्रोवी की विशेषताओं, विशेष रूप से जीपीएथ एक्सप्रेशन, उसमें एक बड़ा हिस्सा खेलता है। मुझे Grails में कुछ कीड़े का सामना करना पड़ा है, लेकिन ग्रोवी पक्ष पर कोई मौलिक समस्या नहीं है।

ग्रोवी का मुख्य नुकसान (मेरे लिए) है कि यह जावा से डीबग करने के लिए काफी कम सुविधाजनक है - स्ट्राइक निशान प्रतिबिंब जादू द्वारा फूला हुआ है जो ग्रोवी के हुड के नीचे होता है, और त्रुटि संदेश गूढ़ हो सकते हैं - लेकिन यह बड़े हो सकता है भाग मेरी अनुभव की कमी के कारण हो सकता है।

2

मैंने Grails (और निश्चित रूप से ग्रोवी) में एक छोटा/मध्यम आकार का प्रोजेक्ट किया है और इसका आनंद लिया है। रास्ते में निश्चित बाधाएं थीं। वे शामिल हैं:

  • अच्छा डीबगिंग टूल का अभाव (मैं Grails के लिए अपने ज्यादातर देशी समर्थन की वजह से Netbeans का उपयोग कर पर बसे है, लेकिन यह एक डिबगर ... ओह कमी रह गई थी) वेब प्रवाह सुविधाओं में
  • बग्स। Grails 1.1 में वसंत के वेब-प्रवाह का एक नया संस्करण है जिसने इन समस्याओं में से कई को हल किया है।
  • कमजोर jquery प्लगइन समर्थन। मुझे jQuery पसंद है, लेकिन यह प्रोटोटाइप के रूप में काफी समर्थित नहीं था (और जो भी अन्य जावास्क्रिप्ट लाइब्रेरी बॉक्स से समर्थित है)। फिर भी, AJAXy सामान टेम्पलेट्स का उपयोग करके लिखना एक खुशी थी।
    • गोरम में enums और कई से अधिक रिश्तों से निपटने में कठिनाई। Grails 1.1 इन समस्याओं का समाधान करने में एक लंबा रास्ता तय करेगा।

कुल मिलाकर, मैं वास्तव में आनंद उठाया मेरी अनुभवी और समय की एक छोटी राशि में बहुत कुछ सीखा। Grails 1.1 एक बड़ा अपग्रेड है जो इस ढांचे के उद्यम को तैयार करेगा। मैं वास्तव में सिर्फ अच्छे डीबगिंग उपकरण पर इंतजार कर रहा हूं। मुझे लगता है कि मैं इतना सस्ता होने से रोक सकता हूं और सिर्फ इंटेलिजे खरीद सकता हूं। मैंने सुना है कि यह Grails के लिए सबसे अच्छा है।

जावा पृष्ठभूमि से आ रहा है, Grails के लिए सड़क एक पूरी नई भाषा और रेल के लिए उपकरणों के सेट से शुरू करने से कहीं अधिक प्रबंधनीय लग रहा था।

एंड्रयू

2

हमने हाल ही में साथ ग्रूवी/Grails, ग्रूवी होने जावा पर निर्भर टीम के बाकी द्वारा चुना गया एक मध्यम आकार की परियोजना को लागू किया। जैसा कि जावा के साथ सार्वभौमिक मामला है, सबकुछ उससे अधिक समय ले सकता है। हालांकि ग्रोवी जावा की वर्बोज़ शैली से बहुत जरूरी राहत प्रदान करता है, फिर भी यह इतना ही समान है कि एक लगातार काउंटर-सहज वाक्यविन्यास पर ठोकर खा जाता है। एचएलएल के पीछे विचार प्रोग्रामिंग टूल्स प्रदान करना है जो मानवीय विचारों को सुविधाजनक बनाता है, न कि इंसानों को बिल्कुल कंप्यूटर की तरह सोचने की आवश्यकता होती है। थोड़ी अलग पृष्ठभूमि से आ रहा है, हालांकि जावा से काफी परिचित है, आईएमएचओ रूबी, पायथन या क्लोजर जैसी दूसरी भाषा पसंद ने परियोजना के लिए एक बेहतर, अधिक त्वरित आधार प्रदान किया होगा। मैं Thoreau के साथ हूँ, थका हुआ जावा मंत्र के बजाय, "सरलीकृत, सरलीकृत, सरल" सुझाव देने में, "बढ़ाना, बढ़ाना बढ़ाना।" शुद्ध जावा की उम्मीद, जेवीएम नहीं, कोबोल के साथ प्रोग्रामिंग धूल ढेर में शामिल हो जाएगा।

10

मैं

  1. क्लोजर चाहते
  2. slurpers
  3. आम तौर पर अनावश्यक घोषणा MyType x = new MyType(), जो केवल def x = MyType() को कम किया जा सकता है की कोई जरूरत नहीं है यही कारण है कि। हालांकि, टाइपिंग ग्रोवी में मूक है (और मुझे यह पसंद नहीं है)।
  4. कि आप कंसोल के साथ त्वरित और आसान परीक्षण कर सकते हैं (हालांकि, निष्पक्ष होने के लिए, आप मुख्य (...) विधि का उपयोग कर जावा क्लास के समान कुछ कर सकते हैं)।

मुझे पसंद नहीं है

  1. यह कमजोर टाइप किए हुए है। यह प्रदर्शन को प्रभावित करता है, और बग की ओर जाता है। कुछ भी नहीं है आप बंद हो जाता है, और न ही यहां तक ​​कि, आपको चेतावनी निम्न कार्य की:

    def x = new MyComplexClass() 
    
    // oops! accidentally made x equal to 1, that is, an integer 
    x = 1 
    
    // Many lines later ... 
    
    // big fat error. Now x is an Integer, so it doesn't know handle myComplexOperation 
    println "The result is ${x.myComplexOperation(a,b,c)}" 
    

यह रन टाइम पर असफल हो जायेगी।

  1. किसी और के कोड को बनाए रखना मुश्किल है। यह ध्यान में रखते हुए कि आप वस्तुओं को गुणों को इंजेक्ट कर सकते हैं, आप अचानक अपने आप को चर के साथ पाते हैं कि आपके पास कोई सुराग नहीं है, जहां से वे आते हैं, या वे किस प्रकार हैं।

  2. प्रकार समस्या अधिक इकाई परीक्षण के साथ "कम किया" किया जा सकता है, लेकिन फिर, समय आप निम्न विधि लिख कर बचाने:

      :

      def add(a, b) { a + b} 
      

      अन्य विचार से खो दिया जा सकता

    • आपको यह तय करने की आवश्यकता है कि क्या यह स्वीकार्य होगा कि 'ए' और 'बी' एक स्ट्रिंग, एक पूर्णांक, या आपके द्वारा बनाई गई मैट्रिक्स क्लास या कुछ और हैं।
    • आप

    डीईएफ़ जोड़ने का प्रयास करते हैं (पूर्णांक एक, int ख) {a + b}

ग्रूवी सिर्फ मापदंडों के प्रकार पर ध्यान नहीं देगा। तो कोई भी स्ट्रिंग्स या विधि "जोड़ी" के लिए जो कुछ भी पास कर सकता है। संकलक शिकायत नहीं करेगा।

तो अब आप सत्यापन के कुछ प्रकार जोड़ने के लिए है, तो आप यह सुनिश्चित कर लें कि पैरामीटर पूर्णांक हैं चाहते हैं:

def (Integer a, Integer b) { 
    assert a instanceof Integer 
    assert b instanceof Integer 
    a + b 
} 

जहां तक ​​मेरा बता सकते हैं, स्थिर भाषा संकलनकर्ता के प्रयोजन में त्रुटियों से बचने के था संकलन समय, रन समय पर नहीं।

  1. आप एक कोशिश पकड़ रखा या जोड़ने के एक करने के लिए "फेंकता है" करने के लिए है कि यदि एक विधि कॉल "फेंक" एक त्रुटि, संकलक आपको चेतावनी देता नहीं है करने में सक्षम है आपकी मुख्य विधि यदि आप इस बात से अवगत नहीं हैं कि कोई विधि अपवाद फेंक सकती है, तो आप अनजाने में संकलन त्रुटियों के बिना ग्रोवी प्रोग्राम को संकलित कर सकते हैं, जब तक कि यह रन टाइम पर उछाल न जाए!

  2. कंसोल इतना अच्छा नहीं है, क्योंकि यह ग्रहण जैसे आईडीई जैसे सुझाव प्रदान नहीं करता है। तो आपको कक्षा के लिए उपलब्ध विधियों को देखने के लिए अपना ब्राउज़र या पुस्तक खोलने की आवश्यकता है। एक और छोटा जाल भी है: आपको कंसोल में एक चर परिभाषित करने के लिए 'def' का उपयोग करने की आवश्यकता नहीं है, लेकिन आपको उन्हें एक प्रोग्राम में चाहिए। इसलिए यदि कंसोल से अपने आईडीई पर कॉपी और पेस्ट करें, लेकिन डीफ़ को भूल जाएं।

  3. मेरी धारणा में ग्रोवी सीमित मात्रा में महान है, लेकिन बड़ी परियोजनाओं के लिए नहीं। ऐसा इसलिए है क्योंकि कई संभावित त्रुटियों को केवल रन टाइम पर ही पता चला है, इसलिए अधिक यूनिट परीक्षण और आवेषण आवश्यक हैं, जो भाग में हार जाते हैं कि आप ग्रोवी कार्यक्रमों को कितनी जल्दी लिख सकते हैं।

  4. डिफ़ॉल्ट रूप से, ग्रोवी में गुण सार्वजनिक हैं, और हो जाता है और सेट स्वचालित रूप से बनाए जाते हैं। आप डिफ़ॉल्ट व्यवहार को ओवरराइड कर सकते हैं, लेकिन यह एक और चीज है जिसे आप भूल सकते हैं, और अपनी कक्षाओं के समावेशन में बाधा डालता है। एक सरल और अच्छा वाक्य रचना, मौजूदा जावा टीमों, unparalled जावा एकीकरण और कई महान तरीकों के साथ मौजूदा JDK को बढ़ा देता है, विशाल उत्पादकता लाभ लाने के लिए फ्लैट सीखने की अवस्था के साथ

    ​class Test { String a, b } 
    
    class Test2 { 
        def t = new Test() 
        Test2 (String s) { t.a = s } 
        ​}​​​​​​​ 
    } 
    
    def t2=new Test2("I am public") 
    println t2.t.a 
    
+0

फ़ील्ड्स (या जब आप उन्हें "विशेषताओं" कहते हैं) ग्रोवी में सार्वजनिक नहीं हैं। वे डिफ़ॉल्ट रूप से पूरी तरह से "गुण" encapsulated हैं। – btiernay

+0

@btiernay - मैं सही हो गया ... एक बिंदु तक। जैसा कि आप http://groovy.codehaus.org/Groovy+style+and+language+feature+guidelines+for+Java+ डेवलपर में "डिफ़ॉल्ट रूप से सार्वजनिक" में देख सकते हैं, कक्षाएं और विधियां डिफ़ॉल्ट रूप से सार्वजनिक होती हैं। चूंकि गेटर्स और सेटर्स डिफ़ॉल्ट रूप से डिफ़ॉल्ट रूप से जेनरेट किए जाते हैं, इसलिए गुण डिफ़ॉल्ट रूप से भी सार्वजनिक होते हैं। – luiscolorado

+0

@btiernay - 'विशेषता' शब्द के संबंध में, मैं इसे ठीक से उपयोग करने में विफल रहा, क्योंकि इस शब्द का वास्तव में ग्रोवी स्क्रिप्ट चर (http://tinyurl.com/6lo7bk7) के लिए उपयोग किया जाता है, कक्षाओं में नहीं। – luiscolorado

3

वास्तव में एक गतिशील भाषा: उदाहरण के लिए। यह आसानी से जावा/JDK 2.0 कहा जा सकता है

नील फोर्ड ग्रूवी और JRuby http://nealford.com/downloads/conferences/Comparing_Groovy_and_JRuby(Neal_Ford).pdf

प्रदर्शन के बारे में के बीच एक महान तुलना किया था, यह एक गतिशील भाषा और ग्रूवी 2.0 समर्थन स्थिर संकलन यह वास्तव में उड़ बनाने के लिए शानदार है ।

"@ कॉम्पाइलस्टैटिक के साथ, ग्रोवी का प्रदर्शन जावा से लगभग 1-2 गुना धीमा है, और ग्रोवी के बिना, यह लगभग 3-5 गुना धीमा है। (...) इसका मतलब है कि ग्रोवी तैयार है एप्लिकेशन जहां प्रदर्शन जावा के साथ कुछ हद तक तुलनीय होना चाहिए। "

प्रदर्शन परीक्षण: ग्रोवी 2.0 बनाम।जावा http://java.dzone.com/articles/groovy-20-performance-compared

आप कभी नहीं देखी है तो गतिशील भाषाओं प्रदर्शन नंबर, इससे पहले कि आप stucked मिलता है, कृपया कोई वास्तविक उपयोग के मामले में अन्य गतिशील भाषाओं और वेब चौखटे के साथ मानक (ग्रूवी 1.8 - Grails 1.3.7) देखें: http://www.jtict.com/blog/rails-wicket-grails-play-lift-jsp/

प्रदर्शन जो भी आप करना चाहते हैं उसके सापेक्ष है। मैंने बड़ी परियोजनाओं पर बड़ी सफलता के साथ 2008 से ग्रोवी का उपयोग किया है। यह सिर्फ समय व्यापार की जरूरत में काम किया है।

आशा है कि मदद करता है!

संबंधित मुद्दे