Здравствуйте, Pavel Mosunov, Вы писали:

E>>Что посоветуете? Как быть в данной ситуации?
E>>Заранее благодарен.
PM>Я начинал с Delphi. Аналогично работал в госсруктуре, работал на дельфах 3 года. И нисколько не жалею о приобретенном опыте. Более того, он мне очень помог. Когда я уже давно работал на плюсах, я возвращался к дельфам, когда нужно было подкалымить. Считаю, что для ниши, где нужно сделать несложную прогу, работающую с базой, альтернативы дельфи нет.

PM>Потом я легко переходил на другие языки. И на ПХП, и на С#, и на С++. Развиваться нужно в сторону ПРОГРАММИРОВАНИЯ, я не в сторону какого либо языка.
PM>Так что совет такой — учись программировать, учись проектировать. Если контора устраивает, платят нормально, то нет никакого смысла уходить на понижение ЗП только из-за того, что там юзают типа модные технологии.

Немного несогласен относительно "...нет никакого смысла уходить на понижение ЗП только из-за того, что там юзают типа модные технологии" . .Net технологии развиваются, соответственно необходимо приобрести опыт, а как его приобрести кроме как не в работе над проектом. Опыт приходит с практикой.

нет

WH>>А почему они зло? Я в функциональщене никакого зла не вижу.
WH>>Функциональщина это инструмент со своими плюсами, минусами и областью применения.

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

интересно, чем абстрагирование отличается от изолирования. и знаком ли автор сего перла со схемотехникой

к примеру, устройство процессора ibm-360 было описано на apl. сейчас архитектуру микросхем описывают на VHDL. императивный же характер высокоуровневой, ассемблерной архитектуры обусловлен именно тем, что на нём было удобней прошраммировать в 40-е годы, а сейчас уже остался чистым анахронизмом. если посмотреть скажем архитекутуру GPU, не связанную проблемами обратной совместимости, то имеративность там найти сложно. просто поток данных, пролетающий черех исполнительные устройства, GPGPU — сотни параллельно выполняющихся вычислений

Здравствуйте, IT, Вы писали:

T>>>Выучите какой-нибудь функциональный язык, чтобы понять почему они — зло.
WH>>А почему они зло? Я в функциональщене никакого зла не вижу.
IT>Это потому что ты уже набрал нужное количество очков и перешёл на следующий уровень. А на предыдущем уровне функциональщина — это зло.
Нет, функциональщина — зло потому, что ее нет в С++/Java/C#.

Здравствуйте, Cyberax, Вы писали:

C>Нет, функциональщина — зло потому, что ее нет в С++/Java/C#.

В шарпе уже некоторые зачатки есть. Можно вполне писать в функциональном стиле, но получается пока громоздко.

Здравствуйте, IT, Вы писали:

C>>Нет, функциональщина — зло потому, что ее нет в С++/Java/C#.
IT>В шарпе уже некоторые зачатки есть. Можно вполне писать в функциональном стиле, но получается пока громоздко.
Так и на Java с анонимными классами можно. Только вот жутко это неудобно — проще обычные for/while воткнуть, чем делать map/reduce и т.п.

Здравствуйте, IT, Вы писали:

IT>Здравствуйте, Cyberax, Вы писали:

C>>Нет, функциональщина — зло потому, что ее нет в С++/Java/C#.

IT>В шарпе уже некоторые зачатки есть. Можно вполне писать в функциональном стиле, но получается пока громоздко.

а уж как шикарно можно на C++. в ru.cpp один чел писал, как он написал какую-то функцию с ленивыми вычислениями, коллеги ужаснулись и велели ему переписать по-человечески. на этом основании он считал, что ленивые вычисления — зло

Здравствуйте, BulatZiganshin, Вы писали:

BZ>а уж как шикарно можно на C++. в ru.cpp один чел писал, как он написал какую-то функцию с ленивыми вычислениями, коллеги ужаснулись и велели ему переписать по-человечески. на этом основании он считал, что ленивые вычисления — зло
Я тоже так считаю Функциональщина не обязана быть ленивой.

Ну и на С++ в функциональном стиле уж слишком неудобно писать.

Здравствуйте, BulatZiganshin, Вы писали:

IT>>В шарпе уже некоторые зачатки есть. Можно вполне писать в функциональном стиле, но получается пока громоздко.

BZ>а уж как шикарно можно на C++.

На плюсах принципиально нельзя из-за невозможности реализации замыканий.

Здравствуйте, IT, Вы писали:

IT>Здравствуйте, BulatZiganshin, Вы писали:

IT>>>В шарпе уже некоторые зачатки есть. Можно вполне писать в функциональном стиле, но получается пока громоздко.

BZ>>а уж как шикарно можно на C++.

IT>На плюсах принципиально нельзя из-за невозможности реализации замыканий.

Помню с кем то ругались насчет сахара И вдруг невозможно
Так что берем рефлектор и тупо переносим реализацию замыканий в C++, добавив пару умных укзателей

Если серъезно можно и без замыканий писать в функциональном стиле. На C++ это действительно сложно, но в близком к нему D уже вполне нормально.

Здравствуйте, FR, Вы писали:

IT>>На плюсах принципиально нельзя из-за невозможности реализации замыканий.

FR>Помню с кем то ругались насчет сахара И вдруг невозможно

FR>Так что берем рефлектор и тупо переносим реализацию замыканий в C++, добавив пару умных укзателей

Вот с умными указателями как раз и будет проблема. Они только называются умные, а на самом деле довольно тупые.

FR>Если серъезно можно и без замыканий писать в функциональном стиле.

Можно. Но только это будет не "в функциональном стиле", а "в кастрированном функциональном стиле".

FR>На C++ это действительно сложно, но в близком к нему D уже вполне нормально.

В D появился GC?

Здравствуйте, IT, Вы писали:


IT>Вот с умными указателями как раз и будет проблема. Они только называются умные, а на самом деле довольно тупые.

Угу но все решаемо, хотя и коряво.

FR>>Если серъезно можно и без замыканий писать в функциональном стиле.

IT>Можно. Но только это будет не "в функциональном стиле", а "в кастрированном функциональном стиле".

Да, но синица в руках тоже полезная вещь

FR>>На C++ это действительно сложно, но в близком к нему D уже вполне нормально.

IT>В D появился GC?

Он там всегда был.

Здравствуйте, FR, Вы писали:

IT>>Вот с умными указателями как раз и будет проблема. Они только называются умные, а на самом деле довольно тупые.

FR>Угу но все решаемо, хотя и коряво.

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

IT>>В D появился GC?

FR>Он там всегда был.

Тогда для D ещё не всё потеряно.

Здравствуйте, IT, Вы писали:

IT>Здравствуйте, FR, Вы писали:
IT>>>Вот с умными указателями как раз и будет проблема. Они только называются умные, а на самом деле довольно тупые.
FR>>Угу но все решаемо, хотя и коряво.
IT>Это ты потом потом будешь своим заказчикам рассказывать почему у тебя при замыканиях образуются протухшие указатели. А мне не надо.
К C/С++ можно элементарн прикрутить консервативный GC, так что такой проблемы не будет.

Да, некрасиво. Но работает.

Здравствуйте, Cyberax, Вы писали:

C>К C/С++ можно элементарн прикрутить консервативный GC, так что такой проблемы не будет.

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

Мое мнение — Delphi хоронить рано.

Есть (и долго будет) ряд задач, для которых не требуется мощь Web-технологий. Например, не масшатбное ПО по автоматизации бухгалтерии, по складскому учету и т.д.

И еще долгое время будут (не активно, но все же будут) стартовать проекты на Delphi.

Паскалевский синтаксис, что бы ни говорили намного удобнее Cшного. В Паскале не так намудрено с указателями и нет, например, таких конструкций, когда вместо if(i==j) ошибочно пишешь if(i=j), компилятор это пропускает, но потом у программы начинает сносить башню, и ты мучаешься часами в отладчике, пока найдешь это. Паскалевский компилятор конструкцию if(i:=j) просто не пропустит.

Мне могут возразить, что зато он беднее — труднее, например, реализовать перегрузку операторов. Согласен. Но часто ли этой функциональностью пользуются?

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

Мое мнение, что "умирающий" Delphi не корректно сравнивать с Java и даже C++ — разные цели и задачи у них. У последних они конечно шире, но и у первого их множество не пусто.

На мой взгляд Delphi логичнее сравнивать с Visual Basic. Давайте обсудим такое сравнение — что из этих двух перспективнее.

К тому же, декларируется, что Delphi (последяя версия) будет работать на платформе .NET — т.е. как минимум попытки догнать время предпринимаются (и это хорошо, что монополии MS на средства разработки по .NET нет). Т.е. ситуация, когда продукт просто застыл в каком-то статическом состоянии нет — он все же развивается.

В заключение добавлю, что сам я профессионально программировал достаточно давно (основным инструментом, кстати был Delphi) — потом стал подниматься до аналитика и дальше развиваюсь в менеджмент. И сейчас для меня совершенно не важно, задачи, под которые я провожу аналитику, будут реализованы на Delphi, который я знаю или на C++ или еще на чем-то мне не знакомом.

Отсюда ВЫВОД и СОВЕТ — если не собираешься до седых волос заниматься кодированием, не дергайся — на твой век хватит работы на Delphi (а может и до седых волос хватит). К тому же, сейчас в ВУЗах наверняка уже .NET во всю обучают, и очень скоро рынок может оказаться перенасыщен именно специалистами в части "современных" технологий — любой студент утрет тебе, программисту со стажем, нос. А специалистов по тому же Delphi, будет не много, хотя спрос, хоть и не большой, но будет. Развивайся с ростом и рассматривай варианты ухода от кодирования (тогда подобные вопросы снимутся сами собой).

Почему-то, когда говорят о переквалификации говорят о модных технологиях но почему-то забывают учитывать насыщенность рынка специалистами этого профиля. Когда появляется какая-то новая технология конечно же будет период, что специалистов в области этих технологий мало, и они будут высоко цениться, но этот период будет весьма коротким — то, что технология новая это быстро просекается, и рынок специалистов достаточно быстро насыщается. Т.е. почему-то зачастую ошибоно принимают во внимание спрос на специалистов вместо того, чтобы принимать отношение спрос/предложение. Например, по Java/C++ много задач, но много и квалифицированных специалистов, по Delphi мало задач, но гораздо меньше и специалистов, и в какой области это соотношение выше, еще вопрос.

P.S.
Можешь поделиться, в какой конторе в Минске работаешь (можно лино в почту) и сколько получаешь?

Эти вещи взаимосвязанны. За не интересные задачи много не платят.

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

Здравствуйте, VovkaMorkovka, Вы писали:

VM>Неправда ваша, за имхо скучнейшую веб — разработку платят куда больше чем за игры одного масштаба, по крайней мере в Харькове
Игроделание это отдельная история.
Туда ломится толпа студентов-фанатиков готовых работать за еду.

Здравствуйте, WolfHound, Вы писали:

WH>Игроделание это отдельная история.
WH>Туда ломится толпа студентов-фанатиков готовых работать за еду.

Не знаю, не знаю — большинству студентов скажи что нибудь типа:"Каноническое уравнение прямой, или теорема синусов", так они впадают в глубокий ступор, а это вещи элементарнейшие. Гораздо легче студенту освоить программирование простых вещей на php или C# — никакой математики не надо

Здравствуйте, VovkaMorkovka, Вы писали:

VM>Не знаю, не знаю — большинству студентов скажи что нибудь типа:"Каноническое уравнение прямой, или теорема синусов", так они впадают в глубокий ступор, а это вещи элементарнейшие. Гораздо легче студенту освоить программирование простых вещей на php или C# — никакой математики не надо
Ой. Да какая там математика... так мелочи.
В любом случае это не отменяет толпу студентов готовых работать за еду.