powered by simpleCommunicator - 2.0.60     © 2026 Programmizd 02
Целевая тема:
Создать новую тему:
Автор:
Закрыть
Цитировать
Форумы / Программирование [игнор отключен] [закрыт для гостей] / Delphi vs Java2
25 сообщений из 201, страница 6 из 9
Delphi vs Java2
    #33375264
c127
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
ASCRUS
Не знаю, как в Java, а вот в Delphi и WatcomSQL замечательно работает.


Не знаю как в джаве, а вот в С++ бывают большие проблемы при многопоточном программировании, особенно на всяких ВыньЦЕ устройствах. Приходится возвращаться к классике и использовать коды возврата.

ASCRUS
И наоборот - отсутствие в PB исключений (за вычетом работы с EAServer) иногда очень даже напрягает и превращает код в сплошные ветвления, особенно когда в ходе ошибки в любом операторе необходимо выполнить определенную последовательность действий перед выходом из процедуры по ошибке.


С этим я согласен, иногда ексепшины удобны, но очень иногда, а в среднем никакого существенного выигныша ИМХО нет. При программировании СКЛ серверов вполне хватает транзакций, необходимости в ексепшинах нет вообще, единственное что остается полезным от ексепшина это вызов ошибки в сохраненке оператором типа trow.




NotGonnaGetUs
Вы сами подтвердили этот тезис своим примером. Ваш код - скрывает причины ошибок.


Не нашим примером, а Вашим примером. Вы его придумали, реализовали на С, я только показал, как его можно упростить. Если бы Ваш код не скрывал ошибок, то мой бы тоже не скрывал. Нет ничего сложного в том, чтобы вернуть не просто -1, а -2, -3, ... в зависимости от ошибки.

NotGonnaGetUs
Да, нужно быть аккуратным, нужно тратить массу времени на то, чтобы разрешать сложности перечисленные под пунктами 1-2-3 в посте выше, вместо того, чтобы тратить свою аккуратность на описание собственно логики приложения.


Еще раз повторяю: при неаккуратном программировании Вы не тратите время на логику приложения, Вы все равно тратите время на борьбу со своей неаккуратностью (а не на логику), только в других местах программы. А услилий столько же.

Классический пример аналогичной ошибки. При возрождении объектно-ориентированного программирования в конце 80-х (С++) его сторонники говорили примерно следующее: объектно-ориентированная концепция сильно облегчает программирование и уменьшает количество проблем, ТОЛЬКО НУЖНО БОЛЬШЕ ВРЕМЕНИ ТРАТИТЬ НА ПРОДУМЫВАНИЕ ПРОГРАММЫ. Т.е. насколько сильно облегчает еще неизвестно, но уже нужно больше продумывать. И учить С++ намного сложнее чем С. Вот и получается что проблемы перетащили из одного места в другое и возможно добавили новых. Говорю сразу, что я не противник ОО в принципе, и сам считаю что программу нужно хорошо продумывать, но использование этих преимуществ не такое простое дело, это отдельная сложная задача.

То что Вы говорите аналогично, результаты неаккуратности остаются, просто сказываются в другом месте и еще неизвестно где их легче выловить и исправить.

NotGonnaGetUs
Вы приводили в пример код ядра бсд, который вылизан огромным количеством людей, и содержащий оттого чертовски мало ошибок.


На самом деле там не так много людей. К тому же они этот код постоянно изменяют, поэтому это не тот же код, который был 5-10 лет назад, так что тех разработчиков уже можно не учитывать.

NotGonnaGetUs
Конечно, код в котором НЕТ ошибок не страдает от того, что их СКРЫВАЮТ.


Насколько я понимаю ексепшины к ошибкам отношеня программирования практически не имеют, это обработка исключительных ситуаций. БСД я вспомнил чтоб в ответ на Ваше утверждение, что без ексепшинов код получится либо ненадежным, либо нечитаемым. А БСД надежна и читаема, хотя написана на С.

NotGonnaGetUs
Однако время затрачиваемое на устранение ошибок в ещё "не вылизаном" продукте существенно уменьшается при использовании технологии исключений, поскольку меньше времени уходит на выявление причин ошибок.


Тут я вообще не согласен. Устойчивые ошибки элементарно локализуются и другими средствами, а неустойчивые Вы не локализуете и с ексепшинами. Эксепшины теоретически облегчают обработку ошибок программы, данных (т.е. исключительных ситуаций), а не ошибок программиста при программировании.

NotGonnaGetUs
Ещё раз: если бы программистов не далающих ошибок хватало - не было бы этого обсуждения. Но рынок требует больше рабочик рук:


С каких это пор? Пару лет назад этих рук вроде был избыток, да и сейчас тоже избыток, причем в основном неопытных кодеров. Народ работал за 12 долларов в час, и еще не мог устроиться. Столько получает продавец на кассе.

Не нужно столько программистов на рынке.

NotGonnaGetUs
Пусть это кому-то и не нравится, но в нашем идотском мире решение остаётся за деньгами, поэтому армия формоклпателей будет жить на тех пор, пока их работа приносит реальную прибыль (отчего-то никто не пытается сэкономить кучу денег посадив 125 программистов за ассемблер, чтобы сделать GUI к БД столовой N5).


Асемблер это совсем другое дело, это машинно зависимый язык. А ГУЙ пишут и на С, например гном написан на сишной библиотеке GTK.

NotGonnaGetUs
Но причём тут домохозяйки и С ?!
Всё, что верно при программировании на С, верно и при программировании на ассме, басике, паскале, джаве - только на практике приходится помимо трудностей "алгоритмических" вникать в трудности языка.
А кому нужны лишнии трудности? Грузинскому комсомолу?


Формально C горадо проще С++ и джавы, так что вникать нужно меньше. Но сложнее паскаля. Посмотрите БНФ. Но дело не в простоте, а в отношении. Я согласен с Вами, что настоящее программирование от языка не зависит. Но реально сложилась такая ситуация, что для бейсика, иногда джавы посчитали возможным готовить неопытных программистов. Это потому, что КАЖЕТСЯ, что система простая, поэтому за 3 недели можно подготовить человека и он будет рисовать окошки и что-то там еще. Но потом оказывается, что с этими окошками, созданными таким программистом, столько мороки, что дешевле было бы их сразу заказать нормальному человеку. Одно спасение, если проект умрет, то об этих окошках никто не вспомнит. Так в основном и случается, кстати.

С в таком ключе никто не продвигал, пик его популярности пришелся на время, когда мысль о домохозяйках в программировании никому не могла прийти в голову.

NotGonnaGetUs
Вот и я про тоже. Код ядра писали далеко не дилетанты, но есть уйма задач (которые рождает рынок), где можно использовать "уже не дилетантов, но ещё не профи (или уже никогда не профи? :))".


Не согласен, я бы с дилетантами не связывался никогда ни при каких условиях, но это к делу не относится. Но дилетант и ескепшины так запутает, что три профессионала не разберутся. Немного утрирую.

NotGonnaGetUs
Может быть сила привычки?


Если бы только у меня, а то же у всех. В чужом С++ коде разбираться гораздо сложнее чем в чужом С коде. Опять же, не знаю почему, эмпирический факт. Одна радость, если внутрь лезть не нужно, но это редкость. И что интересно, знатоки С++ тоже боятся лазить в чужом С++ коде, хотя это не афишируют, и хорошо читаемые ексепшины не сильно помогают.

NotGonnaGetUs
c127
От плохих программ пользы все равно мало. Лучше иметь мало хороших, чем много плохих.

Не все определяется соображениями оптимальности программирования, часто делаются неоправданные действия, есть же еще маркетинг. Например появление C# с точки зрения технологий ИМХО неоправдано, чистый маркетинг.

Если звезды зажигают, значит это кому-нибудь нужно? (с)по телевизору было.


Это Маяковский, школьная программа, 10 класс, не помню откуда именно, лень искать.

Кстати совершенно неверно, если исходить из тогдашней (1920-1930 годы) официальной доктрины, вообще материалистической, то это никому не нужно.

NotGonnaGetUs
Маркетинг... У C# есть очень агрессивные стронники, главным образом среди людей, которые достаточно долго писали на С++. Это получается жертвы рекламы? :)


Не встречал таких. По моим наблюдениям опытные С++-сники его как раз сильно ругают, особенно те, которым приходится с ним работать.

NotGonnaGetUs
У меня было два *не* эквивалентых примера один с исключениями, другой без. Пример с кодами возврата и в вашем, и в моём варианте одинаково хорошо демонстрирует его не достатки перед кодом с исключениями, для которого вы не привели эквивалентна...

Еще раз: мой сишный пример эквивалентен Вашему. Я исходил из того, что Вы смогли построить сишный код, эквивалентный Вашему же джава коду. Если Вы построили неэквивалентные примеры на джаве и на С, то о чем мы тогда говорим вообще? Постройте эквивалентные, я попробую упростить сишный код, мы его сравним с джавой и посмотрим что окажется проще и понятнее.
...
Рейтинг: 0 / 0
Delphi vs Java2
    #33375411
NotGonnaGetUs
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Глупо обсуждать код, структура которого не ясна, но всё-таки...

softwarer
Обработкой на месте - потому что вся обработка на месте, которая может быть сделана, должна быть сделана внутри того, что Вы в своем примере назвали doSqlRefresh(). Если уж этот метод выбрасывает исключение - значит, на месте ничего сделать нельзя.

Почему? Это может быть метод doSqlUpdate() или ещё какая-нибудь бредятина, смысловая нагрузка которого (refresh) возникает только в контексте вызвывающего метода. Следовательно корректно обработать SQLExpection из этого метода можно только в методе refresh(), но никак не в doSqlХХХ().



Что касается "полей с необходимой информацией" - возникают сразу два возражения. Первое: это потеря информации. Получается, что метод refresh() начинает предполагать что-то о тех, кто его вызывает, о том, какие поля внешнему обработчику ошибок понадобятся, а какие - нет. Imho это просто принципиально идеологически криво.

Любой метод, который хоть что-нибудь возвращает, не может не "предполагать что-то о тех, кто его вызывает" и что им потребуется.
Дополнительные методы в классах Exception просто детализируют описание ошибки.


Это означает следующее: доработанный sql-движок научился возвращать дополнительную информацию, менеджер ошибок умеет ее обработать - а не сходится из-за того, что какой-то плюгавый местечковый refresh() слишком много о себе возомнил. Это нарушает принцип модульности, то, что сейчас называется инкапсуляцией.


Во-первых, если дорабатоли sql-движок и менеджер ошибок, то почему не нужно доработать refresh()?

Во-вторых, если я правильно понимаю, то менеджер ошибок не делает ничего кроме регистрации ошибок. Какая тогда разница, будет вставлен вызов к нему в методе refresh или из метода рефреш будет выкинут SQLException, котоырй будет обработан тем же самым менеджером?

Более того, тут я согласен с DarkSquid, прокидывание SQLException и т.п. как раз таки и есть нарушение инкапсуляции, т.к. выводит на ружу внтуреннее устройсто метода refresh.


Второе: это тривиально менее удобно. Одно дело, в обработчике ошибок я пишу:

Код: plaintext
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
//полагаю try был таким :)
 try {
   refresh();
}
 catch  (SQLException e) 
{
  errorManager.processSqlException (e); 
}
 catch  (RefreshFailedException e) 
{
   if  (e.causeIsSqlException()) 
    errorManager.processSqlException (e.getSqlException());
  ...
}


Код: plaintext
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
20.
21.
22.
23.
24.
25.
26.
27.
28.
29.
30.
31.
32.
 public   void  refresh()  throws  RefreshFailedException {
     try  { ... }  catch (SQLException se) {
           errorManager.processSqlException (e); 
            throw   new  RefreshFailedException();        
    }
}

...somewhere...

 try {
   refresh();
}
 catch  (RefreshFailedException e) 
{ 
  /*
    во-первых логику 
    if (e.causeIsSqlException()) 
      errorManager.processSqlException (e.getSqlException());
    
    легко перенести в 
       errorManager.processRefreshFailedException(e);

    во-вторых, тут должна быть выполнена отмена текущей операции и   
    вывод информации о том, что она не состоялась или другое действие в 
    зависимости от конекста, в котором вызывается метод...
  */
  GUITools.showErrorMessage("У нас всё поломалось, если вера в вас сильна -  нажмите кнопку ещё раз, но попозже.", 
  e /* для показа детальной информации */);
   return ;
}
...

Единственная причина, которую я могу придумать, почему у вас выкидывалось по несколько исключений разных типов - это не обходимость разных восстановительных действий после "сбоя".
Но эти действия должны быть описаны там же где и реализация refresh (возможно в методе repair определённом в том же интерфейсе, что и refresh), иначе получается самое настоящее "спаггети" вместо года...


Другое дело - там же я судорожно начинаю писать код, который в случае SQLException выдернет из него нужные поля (которые могут быть или не быть в зависимости от класса наследника SQLException) и передаст их на обработку в код, который по наличию или отсутствию значений в этих полях начнет гадать о том, каким же именно был класс ошибки.

Когда мы создаём RefreshFailedException, мы указываем в качестве cause SQLException, если обработчику (и разработчику :)) не достаточно простого стек трейса, куда сам SQLException выведет всё, что знает, то можно добавить в класс RefreshFailedException дополнительную информацию. Зачем дублировать то, что и так известно (копировать данный из объекта SQLException в RefreshFailedException) - мне не ясно.

Может быть всё упирается в самописный фреймворк для работы с ошибками? Тогда, возможно, стоит посмотреть на архитектуры таких штук как log4j, чтобы понять, как можно жить по-другому :)
...
Рейтинг: 0 / 0
Delphi vs Java2
    #33375454
NotGonnaGetUs
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
c127
Не нашим примером, а Вашим примером. Вы его придумали, реализовали на С, я только показал, как его можно упростить. Если бы Ваш код не скрывал ошибок, то мой бы тоже не скрывал. Нет ничего сложного в том, чтобы вернуть не просто -1, а -2, -3, ... в зависимости от ошибки.
...
Постройте эквивалентные, я попробую упростить сишный код, мы его сравним с джавой и посмотрим что окажется проще и понятнее.


Неужели я так путанно выражаюсь?

Имеем пример с кодом возврата:
Код: plaintext
1.
2.
3.
4.
5.
6.
 if  (- 1  == fooC(fooB(fooA()))) {
     sout("Где-то ошибка!!!");
}  else  {
  /* ... код, который будет выполняться в случае успеха fooC(B(A())); ... */
}
sout("пока!");

Имеем пример с FooException
Код: plaintext
1.
2.
3.
4.
5.
6.
7.
8.
 try {
  fooC(fooB(fooA()));
  /* ... код, который будет выполняться в случае успеха fooC(B(A())); ... */
}  catch (FooException fe){
  LOGGER.error("Ошибка тут, а не где-то!", fe);
}  finally  { //хочу быть уверенным, что все увидят эту надпись...
  sout("пока!");
}

В коде с исключением мы имеем значительно больше информации об ошибке.
Например, чтобы выяснить в каком именно методе возникла ошибка используя коды возврата нам придётся написать что-то вроде такого:

Код: plaintext
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
 int  value = fooA();
 if  (- 1 ==value) {
    sout("Ошибка в A");
}   else  {
   value = fooB();
    if  (- 1 ==value) {
        sout("Ошибка в B");
   }   else  {
        value = fooC();
         if  (- 1 ==value) {
              sout("Ошибка в C");
        }  else  {
              /* ... код, который будет выполняться в случае успеха fooC(B(A())); ... */
        }
   }
}
sout("пока!");

Но ведь FooException несёт информацию не только о методе в каком возникла ошибка, но и о строчке внутри метода, и т.д.
И говорить, что эта информация "бесползена", можно только если считать, что ошибок в приложении нет. В противном случае, существенно облегчается их нахождение (но не исправление :)).

с127
NotGonnaGetUs
Да, нужно быть аккуратным, нужно тратить массу времени на то, чтобы разрешать сложности перечисленные под пунктами 1-2-3 в посте выше, вместо того, чтобы тратить свою аккуратность на описание собственно логики приложения.


Еще раз повторяю: при неаккуратном программировании Вы не тратите время на логику приложения, Вы все равно тратите время на борьбу со своей неаккуратностью (а не на логику), только в других местах программы. А услилий столько же.

А у меня про неаккуратность ничего не написано, только про аккуратность.
Если взять двух "одинаково" аккуратных людей и одного заставить писать код с кодами возврата, а другого с эксепшинами, у второго останется больше "аккуратности" на написание кода, чем у первого :)


c127
Классический пример аналогичной ошибки. При возрождении объектно-ориентированного программирования в конце 80-х (С++) его сторонники говорили примерно следующее:

А кто в данном случае ошибался: тот кто НЕ ДУМАЛ, но писал, или тот кто говорил, что НУЖНО ПОДУМАТЬ и станет здорово? Имхо, первый.

c127
... но использование этих преимуществ не такое простое дело, это отдельная сложная задача.

Согласен. Поэтому в процессах разработки ПО фигурируют такие роли архитектор, старший программист и кодировщик. При разумной организации процесса разработки на программиста не возложат решение задач, для которых он ещё не готов.


c127
Насколько я понимаю ексепшины к ошибкам отношеня программирования практически не имеют, это обработка исключительных ситуаций.

Вполне возможно, что в С++ это и так. Но java не С++.

Для обработки исключительных ситуаций используются наследники класса Exception, который нужно объявлять в директивах throws методов и т.д.

Остальные классы - RuntimeException и Error - служат именно для информирования об ошибках программирования и ошибок среды исполнения.

c127
Тут я вообще не согласен. Устойчивые ошибки элементарно локализуются и другими средствами, а неустойчивые Вы не локализуете и с ексепшинами. Эксепшины теоретически облегчают обработку ошибок программы, данных (т.е. исключительных ситуаций), а не ошибок программиста при программировании.


Да, запись исключений в логи с полным доступом к информации о стеке вызовов приведших к исключению - не панацея от всех бед, но это хороший бонус.

Код в 4000 классов, больше полсотни разработчиков часть из которых буржуи, т.е. код постоянно эволюционирует.
Приходит багрепорт с описанием ошибки. Какими другими средствами можно быстро найти точку позникновения ошибки, выявить причину и приступить к устранению? Информация из стек трейса + ремоут дебаг приложения = от 10 минут до часа в сложных случаях.


Народ работал за 12 долларов в час, и еще не мог устроиться. Столько получает продавец на кассе.

Не нужно столько программистов на рынке.

Спрос рождает предложение. Если бы программисты были не нужны, их бы столько не было.

Работодатель хочет платить меньше => меньше получать готов менее работник => нужны способы сделать работу таких сотрудников эффективнее => появляются технлогии и т.д.

Грустно. Но не идти же, как англичане когда-то, крушить станки?


c127
Если бы только у меня, а то же у всех. В чужом С++ коде разбираться гораздо сложнее чем в чужом С коде. Опять же, не знаю почему, эмпирический факт. Одна радость, если внутрь лезть не нужно, но это редкость. И что интересно, знатоки С++ тоже боятся лазить в чужом С++ коде, хотя это не афишируют, и хорошо читаемые ексепшины не сильно помогают.

За то разбираться в чужом java коде одно удовольствие :) Тоже утрирую.
БНФ может быть простой, но симантическая нагрузка поверх синтаксической может быть очень большой.

То, о чём я говорю исходя из своего неопровержимого (т.к. был) опыта, для людей с другим неопровержимым (т.к. был) опытом будет иметь иное значение. Теоретическая нагруженность фактов страшная сила и чтобы придти к общему мнению нужно приводить сами факты целиком, а только их названия и выводы.

Если вы говорите, что были неудачи при переписывании кода (плохо читаемый, большой) - значит они были.
Вы полагаете причина в самих эксепшинах, я полагаю использование не эффективных приёмов работы с ними - без примеров злосчастного кода получается "имхо vs имхо". А потому каждый остаётся при своём :)


c127
Не встречал таких. По моим наблюдениям опытные С++-сники его как раз сильно ругают, особенно те, которым приходится с ним работать.

На форуме rsdn встречается некто Vlad2D сменивший ориентацию с C# на С++. Из его уст звучат достаточно убедительные доводы в пользу #.
Если интересно почитайте. Но это всё offtop.
...
Рейтинг: 0 / 0
Delphi vs Java2
    #33375867
Фотография softwarer
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
NotGonnaGetUs
На форуме rsdn встречается некто Vlad2D сменивший ориентацию с C# на С++. Из его уст звучат достаточно убедительные доводы в пользу #.
Если интересно почитайте. Но это всё offtop.
Еще один офтоп - читать этого некто я бы рекомендовал только тем, кто разбирается в предмете обсуждения. В моем присутствии он однажды участвовал в беседе, видимо на стыке того что знает, того что видел и того что не видел, и в результате перемежал интересные вещи откровенным бредом.

Если же говорить о доводах в пользу C#, известных мне (от людей, заслуживающих доверия) то они пожалуй скорее относятся к конкуренции с Delphi/Java, чем с C++.
...
Рейтинг: 0 / 0
Delphi vs Java2
    #33377838
c127
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
NotGonnaGetUs
Неужели я так путанно выражаюсь?


Нет, вполне нормально. Просто сначала Вы привели пример на С и пример на джаве для сравнения, насколько ексепшины упрощают код. А потом сказали, что эти примеры, оказывается, не эквивалентны. В таком случае их нельзя сравнивать, зачем же их было вообще приводить.
NotGonnaGetUs
Код: plaintext
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
 int  value = fooA();
 if  (- 1 ==value) {
    sout("Ошибка в A");
}   else  {
   value = fooB();
    if  (- 1 ==value) {
        sout("Ошибка в B");
   }   else  {
        value = fooC();
         if  (- 1 ==value) {
              sout("Ошибка в C");
        }  else  {
              /* ... код, который будет выполняться в случае успеха fooC(B(A())); ... */
        }
   }
}
sout("пока!");


Но ведь можно и так:
Код: plaintext
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
 int  value = fooС(fooB(fooA()));
 switch  (value) {
 case  ERROR_A:
.....
 case  ERROR_B:
...


 default :
  sout("пока!");
}
А функции fooX(y) начинать со строчки: if(y<0) return y;
Т.е. одна строчка, if(y<0) return y в функциях и switch. switch длинный, но это уже обработка ошибок, распечатка результатов, в примере на джаве этого тоже нет.

Этот метод в стандартнорм исполнении не позволяет достоверно определить в какой функции произошла ошибка, но если коды ошибок достаточно подробны, то локализаця ошибки не проблема. А если коды привязать к функциям, то тогда он позволяет определить и функцию, хотя так обычно не делают.

NotGonnaGetUs
Но ведь FooException несёт информацию не только о методе в каком возникла ошибка, но и о строчке внутри метода, и т.д.
И говорить, что эта информация "бесползена", можно только если считать, что ошибок в приложении нет. В противном случае, существенно облегчается их нахождение (но не исправление :)).


Это в джаве он несет информацию о строчке и пр., а в С++ такой информации нет, там же машинные коды. В джаве это возможно, поскольку это п-код со всей сопутсвующей информацией и выполняется в виртуальной машине, которая код компилирует. Хотя если извернуться, то и в С++ тоже можно это все впихнуть в екзешник, но этого никто не делает.

Я не говорю, что исключения совершенно бесполезны, я говорю что на практике программы с исключениями получаются В СРЕДНЕМ не проще и не более читаемые, чем с кодами возврата. По моим наблюдениям.

NotGonnaGetUs
c127
Насколько я понимаю ексепшины к ошибкам отношеня программирования практически не имеют, это обработка исключительных ситуаций.

Вполне возможно, что в С++ это и так. Но java не С++.

Для обработки исключительных ситуаций используются наследники класса Exception, который нужно объявлять в директивах throws методов и т.д.

Остальные классы - RuntimeException и Error - служат именно для информирования об ошибках программирования и ошибок среды исполнения.


Да, я понял о чем Вы. Согласен, действительно, в джаве ексепшины можно так использовать, в С++ это практически ничего не дает, там максимум можно вытащить стек в виде адресов функций, потом смотреть служебную информацию линкера или лазить дебаггером по екзешнику и искать эти функции по адресам, что обычно не самый экономный способ. А для джавы наверняка работает, не спорю.

NotGonnaGetUs
c127
Народ работал за 12 долларов в час, и еще не мог устроиться. Столько получает продавец на кассе.

Не нужно столько программистов на рынке.

Спрос рождает предложение. Если бы программисты были не нужны, их бы столько не было.


Так их столько и нет. Одни программисты работают по специальности, другие развозят пиццу, причем далеко не всегда вторые хуже первых. Вопрос в том, называем ли мы программистом человека, развозящего пиццу, если он в прошлом закончил курсы по программированию.

К тому же между спрос и предложение обычно смещены по времени, так что иногда когда есть предложение, спроса уже может и не быть.


NotGonnaGetUs
Работодатель хочет платить меньше => меньше получать готов менее работник => нужны способы сделать работу таких сотрудников эффективнее => появляются технлогии и т.д.

Грустно. Но не идти же, как англичане когда-то, крушить станки?


Не все так плохо. Далеко не все используемые технологии являются самыми эффективными из возможных. Так что дурная работа присутствует и требует рабочих рук.


NotGonnaGetUs
За то разбираться в чужом java коде одно удовольствие :) Тоже утрирую.
БНФ может быть простой, но симантическая нагрузка поверх синтаксической может быть очень большой.


Согласен. Но сложность обучения языку можно оценить по БНФ-у. Сравните размер книги Кернигана-Ричи, которая является хорошийм учебником, с любым учебником по С++ или джаве.

Что касается семантики, то я недавно столкнулся с независимо построенными кодами на С и С++, решающими одну и ту же довольно сложную задачу. С++ код использовать было просто невозможно, я уж не говорю разобраться. Там вообще непонятно с какой стороны к нему подойти и как подключить к нашей задаче, хотя код работающий. Сишный код сумели использовать через пару часов изучения, разобраться в алгоритмах тоже в случае необходимости проблем бы не возникло. Наверное сишные программисты были грамотнее. Но так почему-то получается постоянно.

NotGonnaGetUs
Вы полагаете причина в самих эксепшинах, я полагаю использование не эффективных приёмов работы с ними - без примеров злосчастного кода получается "имхо vs имхо". А потому каждый остаётся при своём :)


Нет, причина конечно же не в эксепшинах, я же говорил, что идея вроде правильная и должна работать. Точно так же как и ООП, очевидно что должно экономить силы программистов, уменьшать количество кода, но на практике обычно (не всегда), получается наоборот.

NotGonnaGetUs
c127
Не встречал таких. По моим наблюдениям опытные С++-сники его как раз сильно ругают, особенно те, которым приходится с ним работать.

На форуме rsdn встречается некто Vlad2D сменивший ориентацию с C# на С++. Из его уст звучат достаточно убедительные доводы в пользу #.
Если интересно почитайте. Но это всё offtop.

Не сомневаюсь что есть такие, которые добровольно забросили С++ и предпочитают использовать С#, но я лично их не встречал. К тому же я не такой знаток С++, чтоб оценить какие-то тонкости, в которых С# выигрывает. Вряд ли они окажутся для меня решающими, я из возможностей С++ использую процентов 20 и мне хватает с головой. Но вот некоторых нужных мне вещей в C# нет, например кроссплатформенности. Поэтому переходить на С# я не собираюсь и даже не смотрю в его сторону.
...
Рейтинг: 0 / 0
Delphi vs Java2
    #33378123
Фотография softwarer
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
c127Наверное сишные программисты были грамотнее. Но так почему-то получается постоянно.
В хорошем случае - именно так. Си как язык мне весьма нравится, но с моей точки зрения его сгубила (с точки зрения качества, а не коммерческого успеха) мода на него, благодаря которой с начала девяностых (у нас) на него валили орды пионеров. Потом и еще большие орды валили на C++.

Насчет картины дел на западе не уверен, но не так давно был прикол: человек в форуме спросил "как перевести вот этот фрагмент C-кода на дельфи". Я показал ему, причем мой вариант был заметно короче оригинала, и намного более "сишным" (по подходу к кодированию), чем оригинал.
...
Рейтинг: 0 / 0
Delphi vs Java2
    #33380288
c127
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
softwarer c127Наверное сишные программисты были грамотнее. Но так почему-то получается постоянно.
В хорошем случае - именно так. Си как язык мне весьма нравится, но с моей точки зрения его сгубила (с точки зрения качества, а не коммерческого успеха) мода на него, благодаря которой с начала девяностых (у нас) на него валили орды пионеров. Потом и еще большие орды валили на C++.

Согласен. Но все-таки С еще жив и неплохо себя чувствует, ИМХО его спасло то, что толпы потенциально опасных для него пионеров в основном пронеслись мимо и увалилили на С++, а С задели только самым краем. А вот С++ -у досталось по полной.

Может будет интересно посмотреть С++ подобный язык, компилируемый, со всеми наворотами в виде объектов, темплетов, но по-моему гораздо более удобный чем С++:
http://www.digitalmars.com/d
...
Рейтинг: 0 / 0
Delphi vs Java2
    #33381642
Фотография softwarer
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
c127
Cпасибо за ссылку. На досуге посмотрю поподробнее; comparision with others, к сожалению, не очень порадовал.
...
Рейтинг: 0 / 0
Delphi vs Java2
    #33382004
Фотография Worobjoff
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Посмотрел ссылку по D
Автор таблицы сравнений сильно приврал в пользу D и принизил остальные языки.
...
Рейтинг: 0 / 0
Delphi vs Java2
    #33382855
c127
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
WorobjoffПосмотрел ссылку по D
Автор таблицы сравнений сильно приврал в пользу D и принизил остальные языки.

Очень возможно что принизил другие, но приврать в пользу D, если это в смысле приписать ему то, чем он не обладает, это вряд ли.

А например?


Тут дискуссия по D, может тоже кому интересно
http://gzip.rsdn.ru/Forum/Message.aspx?mid=1152810&all=1

На всякий случай: я в дискуссии не участвовал, D почти не знаю и всерьез не исползовал. Есть пара простых программок, в принципе очень понравилось, но в тонкости не вникал.
...
Рейтинг: 0 / 0
Delphi vs Java2
    #33384077
Фотография Worobjoff
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
c127В таблице везде где "реализуется в библиотеке классов" стоит плюс для D и минус для остальных языков.
А это - дискриминация!
И как это, то что реализовано в библиотеке framework, не присуще языку C#? Абсурд.
Нет множественного наследования. Какой же это D?
Это C--
(си минус-минус)
...
Рейтинг: 0 / 0
Delphi vs Java2
    #33384425
Naug
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
--C
...
Рейтинг: 0 / 0
Delphi vs Java2
    #33384432
Tov. Drujba
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Множественное наследование - признак неправильного проектирования и вообще творение дьявола. Нет и хорошо.
...
Рейтинг: 0 / 0
Delphi vs Java2
    #33384455
Фотография Worobjoff
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Множественное наследование - признак неправильного проектирования и вообще творение дьявола. Нет и хорошо.Не все так думают.
...
Рейтинг: 0 / 0
Delphi vs Java2
    #33384596
Фотография DarkSquid
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
WorobjoffЭто C--
(си минус-минус)

Это не C--. С-- это совсем другой язык

...
Рейтинг: 0 / 0
Delphi vs Java2
    #33384785
Фотография softwarer
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Tov. DrujbaМножественное наследование - признак неправильного проектирования и вообще творение дьявола. Нет и хорошо.
Это из серии "зелен виноград".
...
Рейтинг: 0 / 0
Delphi vs Java2
    #33384818
Tov. Drujba
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
softwarerЭто из серии "зелен виноград".
Приведите пример, когда множественное наследование единственно возможный или хотя бы лучший из возможных вариант для решения какой-либо задачи.
...
Рейтинг: 0 / 0
Delphi vs Java2
    #33384987
Фотография lisp
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Обратный пример:
в asm вообще нет наследования, но на нем можно решить любую задачу.
Все зависит от языка. Есть языки где наследование вообще не нужно.
...
Рейтинг: 0 / 0
Delphi vs Java2
    #33385084
Фотография Сергей Ильич
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Tov. Drujba softwarerЭто из серии "зелен виноград".
Приведите пример, когда множественное наследование единственно возможный или хотя бы лучший из возможных вариант для решения какой-либо задачи.
Ну в Джаве, например, без множественного наследования интерфейса не обходится ни одни серьезная программа.
...
Рейтинг: 0 / 0
Delphi vs Java2
    #33385189
Фотография Timm
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Сергей Ильич Tov. Drujba softwarerЭто из серии "зелен виноград".
Приведите пример, когда множественное наследование единственно возможный или хотя бы лучший из возможных вариант для решения какой-либо задачи.
Ну в Джаве, например, без множественного наследования интерфейса не обходится ни одни серьезная программа.
наследование класса != имплементация интерфейса
...
Рейтинг: 0 / 0
Delphi vs Java2
    #33385209
Фотография softwarer
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Tov. DrujbaПриведите пример, когда множественное наследование единственно возможный
Как было справедливо указано, любую задачу можно решить вообще безо всякого наследования.

Tov. Drujba или хотя бы лучший из возможных вариант для решения какой-либо задачи.
Например, тривиальная иерархия элементов интерфейса. Типа

Component <= CheckBox, RadioGroup, Button
Button <= PressButton, ToolButton, MenuItem
ToolButton <= CheckToolButton, RadioGroupToolButton
MenuItem <= CheckMenuItem, RadioGroupMenuItem
...
Рейтинг: 0 / 0
Delphi vs Java2
    #33385258
Naug
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Timm Сергей Ильич Tov. Drujba softwarerЭто из серии "зелен виноград".
Приведите пример, когда множественное наследование единственно возможный или хотя бы лучший из возможных вариант для решения какой-либо задачи.
Ну в Джаве, например, без множественного наследования интерфейса не обходится ни одни серьезная программа.
наследование класса != имплементация интерфейса
На самом деле интерфейсы можно именно наследовать (extends), и наследовать именно множество.
...
Рейтинг: 0 / 0
Delphi vs Java2
    #33385278
Фотография softwarer
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
NaugНа самом деле интерфейсы можно именно наследовать (extends), и наследовать именно множество.
Это все же не столько наследование, сколько включение (include).

Интерфейсы же, решая свои задачи все же паллиатив именно там, где требуется наследование (наследование кода).

Кстати, попутный вопрос - реализовали ли в джаве возможность делегировать реализацию интерфейса? То есть если у меня есть класс A, реализующий интерфейс B, я создаю свой класс (C), делаю в нем поле класса A, и говорю, что класс C реализует интерфейс B, причем реализацию следует брать из A.
...
Рейтинг: 0 / 0
Delphi vs Java2
    #33385393
Tov. Drujba
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Softwarer, понял Вас. Но на мой взгляд это не есть хорошо. Если начнем спорить - получится holy war. В данном вопросе (множественное наследование) даже классики расходятся. Поэтому пусть каждый решает для себя.
...
Рейтинг: 0 / 0
Delphi vs Java2
    #33385509
Фотография Timm
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Naug Timm Сергей Ильич Tov. Drujba softwarerЭто из серии "зелен виноград".
Приведите пример, когда множественное наследование единственно возможный или хотя бы лучший из возможных вариант для решения какой-либо задачи.
Ну в Джаве, например, без множественного наследования интерфейса не обходится ни одни серьезная программа.
наследование класса != имплементация интерфейса
На самом деле интерфейсы можно именно наследовать (extends), и наследовать именно множество.
я понял :-) да, так можно
Код: plaintext
1.
2.
3.
4.
5.
6.
7.
8.
 public   interface  B
{
}
 public   interface  C
{
}
 public   interface  A  extends  B, C
{
}
это абсолютно логично. implements в этом случае выглядит просто бессмысленно.
Кстати, попутный вопрос - реализовали ли в джаве возможность делегировать реализацию интерфейса? То есть если у меня есть класс A, реализующий интерфейс B, я создаю свой класс (C), делаю в нем поле класса A, и говорю, что класс C реализует интерфейс B, причем реализацию следует брать из A.
не понял смысл. для чего это? abstract superclass по-моему должен помочь.
...
Рейтинг: 0 / 0
25 сообщений из 201, страница 6 из 9
Форумы / Программирование [игнор отключен] [закрыт для гостей] / Delphi vs Java2
Найденые пользователи ...
Разблокировать пользователей ...
Читали форум (0):
Пользователи онлайн (0):
x
x
Закрыть


Просмотр
0 / 0
Close
Debug Console [Select Text]