Насколько сложно перейти на Java после С++? Проще/сложнее сама жаба по сравнению с С++? По моим нынешним представлениям вроде проще. И какого тогда хрена у жаба-программистов зарплаты больше?
01.03.09 01:48: Перенесено модератором из 'C/C++' — Кодт
Re: Переход на Java
От:
Аноним
Дата:
25.02.09 08:51
Оценка:
Здравствуйте, opener, Вы писали:
O>Насколько сложно перейти на Java после С++? Проще/сложнее сама жаба по сравнению с С++? По моим нынешним представлениям вроде проще. И какого тогда хрена у жаба-программистов зарплаты больше?
Во первых зарплата определяется не сложностью работы, а тем сколько бабла приносят ее результаты
Во вторых я бы не говорил так однозначно
Здравствуйте, opener, Вы писали:
O>Насколько сложно перейти на Java после С++? Проще/сложнее сама жаба по сравнению с С++? По моим нынешним представлениям вроде проще. И какого тогда хрена у жаба-программистов зарплаты больше?
Сам недавно начал делать проект на Java, до этого работал только с C++. imho язык чуть проще, но своих нюансов хватает. Основную сложность составляет изучения сопутствующих технологий, без которых в Java никак. А вообще переход с C++ на Java подразумевает смену области деятельности, т.к. языки созданы для решения разных задач.
Не проще. Java другая. Например, GC предполагает другие идиомы создания и удаления объектов. Есть еще распространенное заблуждение, что в Java нет утечек памяти... Есть. Но они возникают гораздо реже, чем в C/C++.
И главное — библиотеки. В Java создано огромное множество кросс-платформенных библиотек. В С/С++ немного не так. Здесь же чувствуется единство этих библиотек. Не случайно, Java часто называют "платформой".
Здравствуйте, opener, Вы писали:
O>Насколько сложно перейти на Java после С++? Проще/сложнее сама жаба по сравнению с С++? По моим нынешним представлениям вроде проще. И какого тогда хрена у жаба-программистов зарплаты больше?
Смотря, что значит перейти на Java. Если изучить язык, то где-то неделя примерно. Как язык, она действительно проще, это типичный bondage & discipline язык
И на какую именно Джаву, J2ME, J2SE, J2EE... Изучение не только языка, но и изучение сопутствующих подходов, библиотек, требует чуть больше времени.
Насчет зарплат, то она не коррелирует со сложностью инструмента, а зависит от производительности труда программиста, использующего тот или иной инструмент.
Lisp is not dead. It’s just the URL that has changed: http://clojure.org
opener пишет:
> Насколько сложно перейти на Java после С++?
Сложно будет сдержать рвотный рефлекс, самопроизвольно
возникающий при виде кода на Java и спецификации языка.
Проще/сложнее сама жаба по > сравнению с С++?
Во много-много раз. Java -- вообще примитивный язык.
По моим нынешним представлениям вроде проще. И какого > тогда хрена у жаба-программистов зарплаты больше?
Там не язык сложнее. Там сложнее всё остальное.
Потому что надо компенсировать убогость языка сложностью
программ, которые на нём пишут.
Если ты тупо знаешь язык, то тебе ничего платить не
будут. Если ты к этому ещё знаешь всяческие EJB/STRUTS/JPA/AJAX
и прочую херню, то -- да, тут тебе отвалят.
Здравствуйте, MasterZiv, Вы писали:
MZ>Аноним 321 пишет:
>> нет утечек памяти... Есть. Но они возникают гораздо реже, чем в C/C++.
MZ>Есть другое мнение (не моё). Что там утечки ВООБЩЕ ПОСТОЯННО ВОЗНИКАЮТ.
MZ>
странное мнение. если говорить о утечках памяти — есть gc, в чем проблема? а вот с утечками ресурсов — ну, тут уж никакой язык не поможет, это логическая ошибка.
unix_hater пишет:
> странное мнение. если говорить о утечках памяти — есть gc, в чем > проблема? а вот с утечками ресурсов — ну, тут уж никакой язык не > поможет, это логическая ошибка.
Имеется в виду то, что GC — и есть одна большая утечка памяти.
Постоянная. Мнение — не моё, ещё раз.
_>странное мнение. если говорить о утечках памяти — есть gc, в чем проблема? а вот с утечками ресурсов — ну, тут уж никакой язык не поможет, это логическая ошибка.
А в чем отличие освобождения памяти от освобождения ресурсов? До появления gc ошибки освобождения памяти точно так же назвали бы логической ошибкой, нет?
Здравствуйте, opener, Вы писали:
O>Насколько сложно перейти на Java после С++? Проще/сложнее сама жаба по сравнению с С++? По моим нынешним представлениям вроде проще. И какого тогда хрена у жаба-программистов зарплаты больше?
1. Меня лично напрягала необходимость обязательно писать обработку исключений.
2. Большая библиотека. Гораздо больше С++ и разнообразней.
Ну. еще памятью управлять явно не нужно.
Хочешь быть счастливым — будь им!
Без булдырабыз!!!
Здравствуйте, opener, Вы писали:
O>Насколько сложно перейти на Java после С++? Проще/сложнее сама жаба по сравнению с С++? По моим нынешним представлениям вроде проще. И какого тогда хрена у жаба-программистов зарплаты больше?
Перешел, скучаю по С++, особенно при работе с Generic'ами...
Поскольку нищи у языков разные, то переход на Java подразумевает изучение кучи всего помимо Java, но об этом уже писали.
Что такое "куча всего" в моём случае (из основного, что вспомнилось):
JPA/Eclipselink
Spring/Security/orm/rcp
JAX-WS/WS-I
OSGi
Ant
Maven
AOP/AspectJ
ЗЫ
Самое стремное по началу -- gc...
Кто вообще сказал, что на C++ часто возникают утечки памяти? Если придерживаться определенного стиля кодирования, и руки у программистов растут из правильного места, то утечек не будет.
Нашему проекту на C и C++ уже пара лет, за все это время у нас возникла ровно одна (1 — одна) утечка памяти, которая была исправлена за пять минут, и то она возникла потому, что программист, который написал код, имеет привычку писать неаккуратно.
Зато от коллег, пишущих на C#, я много раз слышал разговоры об утечках.
Ключевое слово using их спасает. А то у них вообще был бы практически C.
Вот как мучаются те, кто пишет на J#:
import System.*;
import System.IO.*;
import System.Text.*;
class Test
{
public static void main(String[] args)
{
String path = "c:\\temp\\MyTest.txt";
// Delete the file if it exists.if (!(File.Exists(path))) {
// Create the file.
FileStream fs = File.Create(path);
try {
ubyte info[] =(new UTF8Encoding(true)).GetBytes("This is some"
+ " text in the file.");
// Add some information to the file.
fs.Write(info, 0, info.length);
}
finally {
fs.Dispose();
}
}
// Open the stream and read it back.
FileStream fs = File.Open(path, FileMode.Open);
try {
ubyte b[] = new ubyte[1024];
UTF8Encoding temp = new UTF8Encoding(true);
while (fs.Read(b, 0, b.length) > 0) {
Console.WriteLine(temp.GetString(b));
}
}
finally {
fs.Dispose();
}
} //main
} //Test
Ну это же точно как в C! Забудешь закрыть файл — получишь утечку ресурсов. И все надо закрывать руками, отслеживая ветви выполнения.
Конечно, это же совсем не то, что «неуправляемый» C++!
#include <fstream>
using namespace std;
int main()
{
ifstream file("file.txt");
if (!file)
{
return 1;
}
int n;
file >> n;
if (n < 0)
{
// И не надо вручную ничего закрывать.return 1;
}
return 0;
}
Здравствуйте, Аноним, Вы писали:
А>А в чем отличие освобождения памяти от освобождения ресурсов?
В масштабе. Память есть самый интенсивно используемый ресурс. Посему и необходимость снижения возможностей для ошибок в управлении ею стоит в первых рядах.
Здравствуйте, Аем Вопля, Вы писали:
АВ>Кто вообще сказал, что на C++ часто возникают утечки памяти? Если придерживаться определенного стиля кодирования, и руки у программистов растут из правильного места, то утечек не будет.
+1
У меня в проекте-тесте для либы даже спецом есть код который намеренно делает утечку чтоб убедится что BoundsChecker не поломался вдруг и мышек все еще ловит.
Здравствуйте, LaptevVV, Вы писали:
LVV>2. Большая библиотека. Гораздо больше С++ и разнообразней.
В С++ декларируется "принцип платишь только за то, что реально используешь". В соответствии с ним — поставляется жизненно необходимый минимум.
Вот мне всегда было непонятно, почему в плюс языка всегда пытаются отнести большую стандартную библиотеку?
Это конечно плюс, но не самого языка.
ИМХО появление новых языков с большими библиотеками в комплекте необходимая мера в последнее время.
Во сколько раз меньше народу в момент появления той же Java стало бы писать на ней не будь под нее большой библы с готовыми велосипедами?
Поэтому хочешь продвинуть язык — сделай так, чтоб начать лабать на нем можно было сразу. Отсюда наличие большой библиотеки просто must have.
Здравствуйте, Аем Вопля, Вы писали:
П>>Теперь внимание, вопрос: какое отношение имеют утечки памяти к приведенному фрагменту кода?
АВ>Файл — это участок памяти, распределенной на энергонезависимом запоминающем устройстве.
Не очень понятно что Вы конкретно имели в виду, однако, в любом случае, утечка всё равно не вытанцовывается.
Ну не вызвали Dispose() у FileStream'а, и что ? "Распределённой на энергонезависимом запоминающем устройстве" памяти в виде файла от этого ни холодно, ни жарко. Как был файл, так он и остался. Особенно при работе "только на чтение"
