Търся съвет

31 отговора 816 прегледа
#1

Търся съвет

Каква е разликата ( приликата ) м/у JAVA , Wisual J++ , JavaScript .
Препоръчайте ми добри книги по тематиката .
Компилатори и развойни среди също ( варианта с пл. Славейков го знам ).
Липсват ми контакти с хора от тая ( и подобна ) сфера и предизвикателни теми за пазработка .
lnlbg@yahoo.com

Отговор
в отговор на LNL #2

Re: Търся съвет

Java e ezik za programirane t.e. ezik izcqlo oboshten kato C++ primerno. Toj e na Sun Microsystems. Javascript-a e na Netscape i e kakto move bi predpolagash scriptow ezik za html programirane. Te pomevdu si nqmat nishto obshto. Az lichno se zanimawam s Java i ako imash nqkakwi wyprosi shte se opitam dati otgoworq.
Dokolkoto do Visual J++ e sreda za programirane na Java.

Отговор
в отговор на Even #3

Re: за Even

Благодаря за отговора - това е потвърждение не информацията , която имам , но действително ми беше нужна . Казвам се Лъчезар , 32год .
Не съм програмирал на JAVA , но започвам и ми е нужен съвет за да избера подходяща книга - нещо сериозно , но и с повече примери . Също и развойна
среда . В коя област JAVA превъзхожда C++ ?
lnlbg@yahoo.com

Отговор
в отговор на LNL #4

Re: за LNL

В много области . IDEA е много готина среда за Java, но не е визуална. За визуална среда може би JBuilder или CodeWarrior. Колкото до книги - всичките на Славейков (а и навсякъде другаде) са на практика еднакви. Хващаш една - която и да е. Все пак (не съм я чел) "Принципи на програмирането с Java" я хвалят много. А в нет-а tutorial-и колкото искаш.

Отговор
в отговор на Sten #5

Re: за LNL

Obshto wzeto zapochwash s Java-ta e slovna rabotata ;-))))
Naj-dobre si wzemi kato zanachalo "Thinking In Java". Towa e osnowata na Java.
S editor moga da te posywetwam za JCreator Pro. kato ponaprednesh mivesh da minesh na Forte for Java.
Teglish jdk 1.3 Standard Edition ili nqkoe po nowo, zaedno s documentaciqta i tutoriala i towa e. Sled wreme pochwash da si prawish razni programki za da gi nauchish neshtata oshte po dobre i taka.
Az sega sym na towa niwo i si tyrsq nqkakyw stav ili rabota wyw Sofiq. Inache sym ot Warna.

Отговор
в отговор на Sten #6

Re: за LNL

ia kaji koi sa tezi mnogo oblasti w koito java prevyzhojda C++ che mi stana interesno

Отговор
в отговор на l #7

Re: за I

;-))))
Ne movesh da kash che neshto prewyzhovda drugoto tyj kato sa w razlichni oblasti na programiraneto.

Отговор
в отговор на Even #8

Re: за I


1. Java е абсолютно преносим
2. в Java най-обичайните проблеми на C(++) като препълване на буфери, сочещи към нищото указатели и пр. (сещаш се, предполагам) са решени на най-ниско ниво и програмиста не се съобразява с тези неща. Т.е. нивото на абстракция е малко по-високо.
3. Написаното на Java e много (пъти!) по-читаемо от това на C, освен това има вградена поддръжка на документация.
4. на Java може да се напише почти всичко, което може и на C, като в по-голямата си част се използват готови неща.
5. в Java полиморфизма е не "възможност" а "всеобщо свойство"
6. написаното на Java е много по-стабилно от това на C, при сходни умения на програмистите.

В интерес на истината и C си има плюсове:
1. по-бърз е, когато това се налага да е така и не е необходима голяма преносимост на кода.
2. на C могат да се напишат програми, които са в стихотворна форма, или работят след сортиране на редовете на сорса
3. Има и други, но предпочитам да ги изброи някой, който по-се кефи на C

Отговор
в отговор на Sten #9

Re: за I

1. Java е абсолютно преносим
Убеден ли си в това? Знам, че това е идеята, но нещо май не е съвсем така.

2. в Java най-обичайните проблеми на C(++) като препълване на буфери, сочещи към нищото указатели и пр. (сещаш се, предполагам) са решени на най-ниско ниво и програмиста не се съобразява с тези неща. Т.е. нивото на абстракция е малко по-високо
Тука ще се съглася, но все пак всичко това си има цена.

3. Написаното на Java e много (пъти!) по-читаемо от това на C
Хм, че на C++ добре написаните неща според мене са не по-малко читаеми. Да не разправяме, че има и разни малки екстри (като const методи, параметри и т.н.), които в Java липсват, но са доста полезни.

4. на Java може да се напише почти всичко, което може и на C, като в по-голямата си част се използват готови неща
И на C/C++ има доста готови неща и библиотеки.

5. в Java полиморфизма е не "възможност" а "всеобщо свойство
И при двата езика ги има тези неща - има ли значение как се наричат, т.е. това не е нито предимство, нито недостатък на който и да е език. Да не разправяме, че в Java пък нямаш множествено наследяване, нито пък различни нива на видимост при наследяването (private, protected, public), нещо което в някои моменти е доста полезно (макар и понякога да противоречи на някои ОО концепции).

Ами това е засега - темата кой е по-добрия език и т.н. е многократно разисквана в клуб Програмисти и нямам намерение да почвам отново.
Просто идеята е, че няма идеален език - всеки си има плюсове и минуси.

Отговор
в отговор на josarjan #10

Re: за I

Темата, въпреки че е изтъркана все още е интересна.
1. Да, убеден съм и ако имаш контра-примери би ми било интересно да ги видя. Освен това проблема би бил във бъг на виртуалната машина, за който най-вероятно е да се намери пач.
2. Тук съм съгласен - цената е скоростта
3. Колкото и добре да е написано нещо, създадено от примерно 50-тина програмисти, в проекти със съизмерима сложност, която е по-голяма от средната, Java трудно може да се сравнява със C, най-вече заради стандартите и javadoc
4. Има, да. Както има и за всеки друг език, но дори и на Delphi е по-лесно използването на странични библиотеки. Колкото до Java - там най-ценното е, че се използва API, създадено от един (обикновенно - Sun), и имплементирано от много други. Т.е. сменяш библиотеката и програмата ти пак работи (поне в 95% от случаите )
5. Тук вече пролича, че говориш доста наизуст. Дори не съм убеден, че знаеш какво точно . Нито за модификаторите (и в Java ги има), нито за полиморфизма. Колкото до множественото наследяване - то не е необходимост, не съм убеден и доколко е удобство, въпреки че бих го приел като такова.

Отговор
в отговор на Sten #11

Re: за I

a moje bi ti goworish na izust za 5?
ne stava wypros za modifikatorite pri definirane na mehotdi i poleta, a za takiva pri opredeliane na naslediavaneto. primer:

class ala : private bala {
};

ako shte se zaiajdame, naslediavaneto izobshto ne e neobhodimost, mnojestvenoto syshto. tolkowa programi sa napisani na C bez da ima naslediavane. :P
inache mnojestvenoto naslediavane si e polezno -- pone wednyj na 4-5 meseca syjaliavam che go niama.

no nai-mnogo me iadosvat java collections -- typecasting-a do/ot Object izobshto ne e dobra idea, dano skoro da wywedat templates ...

Отговор
в отговор на Sten #12

Re: за I

Значи това е моето:
5. в Java полиморфизма е не "възможност" а "всеобщо свойство
И при двата езика ги има тези неща - има ли значение как се наричат, т.е. това не е нито предимство, нито недостатък на който и да е език. Да не разправяме, че в Java пък нямаш множествено наследяване, нито пък различни нива на видимост при наследяването (private, protected, public), нещо което в някои моменти е доста полезно (макар и понякога да противоречи на някои ОО концепции).


Това е твоето:
Тук вече пролича, че говориш доста наизуст. Дори не съм убеден, че знаеш какво точно . Нито за модификаторите (и в Java ги има), нито за полиморфизма. Колкото до множественото наследяване - то не е необходимост, не съм убеден и доколко е удобство, въпреки че бих го приел като такова

Кое е наизуст - това че във в C++ има повече изразни средства ли?
Айде кажи ми как да отбележа (в Java), че дадена операция няма да промени обекта, който и подавам като аргумент (това в C++ си става с const).
Да не разправяме, че в Java няма enum, typedef и т.н. Според мен е много по извратено да декларираш интерфейс или абстрактен клас, само за да въведеш 5 константи.
За templates да не говорим - това в Java все още го няма, а според мене
vector<SomeClass> е много по-четливо от Collection.
Как според теб, човек в горния пример ще разбере, че тоя Collection съдържа еди-какви си обекти?
Това за полиморфизма - какво значи според теб всеобщо свойство. Това че не ти се налага да пишеш отпред virtual ли? Ами понякога пък това си е удобно - все пак показваш кои операции могат се предполага да бъдат override-нати.
А за private inhetinace - ами това във Java го няма, а някой път е доста удобно. Знам че подобно нещо може да се симулира с inner класове, ама не мисля че подобен код е по-четлив (мака че това може да е въпрос на навик).

Ами това засега - ако искаш голям спор - прехвърли темата в Програмисти и гледай кво става.

Отговор
в отговор на josarjan #13

Re: за I

>> как да отбележа (в Java), че дадена операция няма да промени обекта, който и подавам като аргумент

- declarirai argumenta final

>> Как според теб, човек в горния пример ще разбере, че тоя Collection съдържа еди-какви си обекти?

- ami tochno polimorhichen call shte ti opredeli pravilnia downcasting sled kato izteglish object-a ot vectora (posle mojesh da testvash type-a s instanceof )

Osven tova public, private, protected sa reserved words v Java i se izpolzvat v syshtia context kakto i v C++. A za mnojestvenoto naslediavane polzvai interface class.

-----
out.close();

Отговор
в отговор на josarjan #14

Re: за I

cast-vaneto do Object ne e goliam problem tyi kato Object e superclass na vseki drug... hierarchiata v java e sys single root.... Sled kato navlezesh v java-ta poveche niama da imash nujda ot template-i.. a kolkoto do mnojestvenoto naslediavane - to prosto ne e neobhodimo... ima neshto kato mnogestveno naslediavane (interface-ite mogat da naslediavat po niakolko interface-a) koeto e udobno v niakoi sluchaj.. no mnojestvenoto naslediavane na class-ovete e po-skoro problematichno otkolkoto udobno..

niva na vidimost ima v java... public, private, protected i friendly(ne se pishe, kogato se propusne kvalifikatora za dostyp po podrazbirane e friendly)

inner class-ovete si imat svoite prilojeniq.. syshto i anonimnite classove... niama smisal da diskutirame tova sega....
trudno e da se kaje che niakoi ezik e po-dobyr ot drug... vseki e udoben za niakakvi celi i ne tolkova za drugi... podobni sporove sa bezsmisleni... vse pak edin ezik e tolkova dobyr KOLKOTO PROGRAMISTA, KOITO GO IZPOLZVA... dori i na naj-syvyrshenniq ezik edin posredstven programist shte si pishe loshi programi... analogichno dobria programist shte si pishe dobri programi na kakvoto i da e... v kraia na kraia vajni sa dannite, algoritmite i t.n. a ne na kakyv ezik shte gi opisvame..

Отговор
в отговор на j1 #15

Re: за I

kogato stava duma za obekti final niama da pomogne... promenlivite ot tip obekti sa referenci kym obekti i tova che sa deklarirani final oznachava che na syotvetnia reference ne mojem da prisvoim drug obekt a ne che niakoi koito ima dostup do obekta niama da moje da go promenia :))

naprimer kato se podava parametyra na niakoi method moje vmesto obekta (napr. obj) da se predade negovo kopie (obj.clone()) i togava syotvetnia method niama nachin da promeni originalnia obekt...
ima i drugi varianti no tova po-skoro opira do design-a na prilojenieto...

Отговор
в отговор на nicko #16

Re: за I

Ами съгласен съм с това, което казваш - аз по-скоро исках да оборя човека, че Java-та едва ли има по-добри изразни средства, а не че не могат да се направят/симулират същите неща.
За public, private и т.н. имах предвид че не можеш да направиш:
class X : private Y
{
}
Това е в C++ - това може да се използва, когато не искаш някой да те вика през даден интерфейс, но пък искаш да го реализираш. В Java ще ти трябва inner класове, които имат достъп до outer класа.

Отговор
в отговор на j1 #17

Re: за I

final няма да ми свърши работа - компилатора няма да ми даде грешка, ако примерно в
class X
{
private String name;
void setName(String newName);
}

class Y
{
void f(final X x) // забележи final
{
x.setName("boza"); // в C++ компилатора тук ще ти даде грешка
}
}

за Collection и vector - ами пак - в Java ако type-cast - на нещо не както трябва това ще се хване чак по време на изпълнение, а не на компилация
ако ползваш vector в C++ - просто компилатора ще ти даде грешка
Разбираш, че грешките, които се случват по време на изпълнение, може и никога да не се хванат по време на тестове.
Да не разправяме, че да разпитваш обекта какъв тип рядко пъти е добро решение - ако утре смениш нещо, пак ще се наложи да се преправя код. Въобще кода е добре да се пише, така че да може да се разширява без да се променя, като само се добавя нов. В този случай това едва ли ще е така.

Отговор
в отговор на josarjan #18

Re: за I

da tochno tova imam predvid za final...

a za Collection-ite... az gi polzvam ot dosta vreme i niamam nikakvi problemi... :)))
i otnovo vsichko opira do design-a na prilojenieto...

Отговор
в отговор на josarjan #19

Re: за I

Ами как ли... с нещо, което все така не е изпипано в C - reflection :)

Отговор
в отговор на josarjan #20

Re: за I

Тук вече изплеснахте нещата... Не разбирам защо изобщо се хващате (феновете на C++) за грешките по време на компилация... Може би защото по правило компилиралата се без грешки програма не работи като хората otkacham]... Хехе!
Не е проблемът в това кога ще ти изгърми компилацията и кога не. Става въпрос за много по общи проблеми в C-то. Не казвам, че има нещо което може или не може да се направи само с единия език, а как, за колко време, колко стабилно ще работи, дали ще може да се използва от други и т.н.
Не се хващайте за конкретните структури на езика. Например това с final - до сега никога (!) не ми се е налагало нещо в java да ми е final параметър. В C-то може и да спестява някои проблеми, но аз не съм се сблъсквал с такива на Java.


Четете "Параграф 22" за да научите C++

Отговор