С каждым годом их число увеличивается, причем с непостижимой быстротой. Выходят обновленные или измененные версии прежних языков. Разрабатываются языки под отдельные программные продукты. Короче говоря, софтверный рынок требует новых технологий, а новые технологии требуют новейших, более мощных языков разработки.
И здесь возникает проблема столь же ускоренного освоения новых языков разработки или их обновленных версий. То есть, обрисовывается примерно следующая ситуация. Предположим, выходит обновленная версия популярного языка разработки. Освоение новой версии языка упрощается в том случае, если синтаксис новой версии ненамного отличается от синтаксиса старой версии. Синтаксис языка программирования не меняется, а лишь дополняется и усложняется. При этом увеличивается мощь языка разработки.
Совсем другое дело, когда новая версия языка фундаментально проработана и переделана. Изменен синтаксис, парадигма и некоторые характерные особенности данного языка разработки. Разработчикам попросту приходится осуществлять переход на абсолютно новый уровень языка разработки. Причем, происходит это не сразу, а поэтапно. Это означает, что разработчик пишет своё приложение, скажем, процентов на восемьдесят на старой версии языка, а на десять — на новой. Благо, если сохраняется поддержка старой версии. Но в результате такого смешения версий, то есть, нерационального программирования, выходит продукт, который не отвечает принципиальным требованиям стабильности и скорости работы. Это касается даже вопросов безопасности, если продукт рассчитан на сферы применения, где конфиденциальность и сохранность данных приоритетны.
Это еще не всё. Как было сказано выше, на сегодняшний день существует огромное множество языков программирования. Их разрабатывают примерно столько же компаний, больших и не очень. Иногда — даже отдельные группы людей. Возникает серьезная конкуренция, особенно у крупных разработчиков средств программирования, чьи результаты пользуются большим спросом в мире. Отсюда вытекает тот факт, что невозможно определить хотя бы три наилучших языка разработки среди имеющихся. Это значит, что ни один из наиболее распространенных языков разработки программных продуктов не отвечает (частично или полностью) некоторым требованиям, предъявляемым разработчиками приложений. Причем те возможности, которые имеются у одного из языков разработки, лишь частично реализованы в другом языке. Здесь идет, так сказать, взаимное дополнение одного языка другим.
Современные среды разработки приложений позволяют писать код для программ на различных языках программирования, причем даже на языке разработки компании-конкурента! И этим активно начинают пользоваться многие разработчики в своих проектах. Иногда даже недостаточно хороший уровень написания приложения на одном языке заставляет разработчика перейти в определенной части кода программы на другой язык и обратно. И снова проблема — стабильность и скорость подобных «винегретов».
Разработчики программных продуктов сильно расходятся во мнении, насколько хорош тот или иной язык разработки. Существует даже некий рейтинг языков программирования.
В итоге имеется многообразнейший рынок средств и языков разработки, неменьший рынок разработчиков на этих языках, которые пишут программные продукты, применяя все эти средства и вместе, и поврозь, и комбинируя их, и играя на совместимости языков… Опять же, в итоге либо получая максимально оптимизированный готовый продукт (в случае, если изощрялся профессионал), в котором из массы языков было выжато всё, что только допустимо, либо получая «сырой», нестабильный, «тяжелый», неоптимизированный продукт. Это в случае, когда извращался непрофессионал.
Но, в любом случае, здесь важен конечный результат, а не инструменты. Так что можно и нужно уметь писать программы на разных языках, в том случае, когда это действительно необходимо для реальной пользы дела.
Если 1С "ненормальный" язык программирования, то в таком случае, ассемблер "рулит", а Ява просто курам на смех...? Нелогично.
Сравнивать машинные, объектно-ориентированные, интерпретируемые и предметно-ориентированные языки программирования как полноценные или неполноценные...
0 Ответить
Александр, если не секрет, кем вы работаете?
Каждый язык "заточен" под свою конкретную нишу. С "соседними" пересекается, но обычно не более чем на три четверти.
Нормальный программист (и менеджер) выбирает язык под поставленную задачу. Иногда приходится использовать несколько. Использовать языки высокого уровня удобно, но некоторый емкие (ресурсы, время) части проще написать на языке низкого уровня. Поэтому связки С + ассемблер, например, встречаются сплошь и рядом.
Последний раз я использовал три языка, потому что так было проще и быстрее. Задача была тривиальна и в сумме на трех языках программа заняла строк сорок. Если бы писал на одном (любом из этих), то не одну сотню.
Оценка статьи: 2
0 Ответить
Поэтому связки С + ассемблер, например, встречаются сплошь и рядом.
на самом деле в последнее время ну не так то уж и часто, как раньше, до распространением дотнета, программисты обленились, найти толкового с++ программиста (а ещё и со знанием ассемблера) стало труднее
0 Ответить
Ну при чем здесь "часто/не часто", "раньше/не раньше", "найти/не найти"?
Занудствуешь...
http://www.google.com
[Модератор: ссылки нужно прописывать и выражаться прилично.]
0 Ответить
Вот ! Ну при чем здесь "часто/не часто", "раньше/не раньше", "найти/не найти"?
Занудствуешь...
рекомендую следить за своей речью, во-первых, за цензурой, во-вторых за содержимым, ибо это не занудство, это поправка по существу, не люблю когда людей вводят в заблуждение (касательно утверждения "встречаются сплошь и рядом")
гуглом пользоваться умею, вот только толку от Вашей ссылки? процентное соотношение требуемых программистов в разных направлениях изменилось явно не в пользу asm/с/с++ , то что они местами требуются это понятно, другое дело, что найти таких спецов сейчас стало гораздо труднее
0 Ответить
В заблуждение старался не ввести. Насколько утверждение "сплошь и рядом" вводит в большее заблуждение, чем утверждение "гораздо труднее"
0 Ответить
1-й вопрос: Какие три языка ты использовал в последний раз, если не секрет?
2-й вопрос: У меня мания - декомпилировать одну и ту же программу, написанную на одном/двух/трех/четырех языках и сравнивать длину ассемблерных простыней. Причем зависимость "количество строк исходного кода/количество строк ассемблерного кода" иногда бывает довольно неадекватной. Такая мания есть?
0 Ответить
Какие три языка ты использовал в последний раз, если не секрет
WHS/VBS/CMD. Это была не программа, а набор скриптов.
Такая мания есть
Мании нет, уже не интересно. Профессионально не программирую давно, занимаюсь сейчас другими проектами (Rose/SoDa/Altova).
ЗЫ Ребята, не ругайтесь, истина для каждого своя.
Оценка статьи: 2
0 Ответить
во-первых, это дурная мания и неправильное расходование рабочего времени, от которой толку ноль, лучше потратить это время на правильный выбор архитектуры приложения, на изучение паттернов и тд, в ооочень редких случаях может пригодится такая оптимизации кода, это ооочень специфическая и редкая задача
а два, учитывая что серъёзные приложения на одном языке программирования пишутся от месяца до нескольких лет, то что за программы такие, для которых можно позволить себе написание на "одном/двух/трех/четырех" (может хотя бы двух/трех/четырех?) языках? уровня универских лабораторных работ?
ps: для нормального программиста комментарии писать на русском языке дурной тон, ибо он редко работает один, а люди в команде бывают разные
pps: поработайте хотя бы годик в компании, которая использует нормальные языки программирования (1с сюда явно не входит), где будут серъёзные проекты, работа в команде, где придётся часто работать с чужим кодом и тд.. тогда Вас там и переучат, скорее всего начнёте по-другому мыслить или Вас просто оттуда уволят
0 Ответить
Дурная мания, это твоё ИМХО.
Суть была не в этом.
Возможно станешь "ненормальным" программером. Нормальные - зануды и не знают что такое функция.
делаю вывод, что Вы крутой спец. Комплекс в чем, если не секрет? 
На мании рабочее время не тратится. Программы - на уровне лабораторных университетских работ (эт ты правильно заметил). Иначе попробуй распечатай ассемблерный код, хотя бы скажем, редактора "Блокнот".
re ps: Почитай MSDN или SDK (не важно к чему) - поймешь, что значат комментарии
re pss: работал на С++. Потом на .NET (C++, VB, C#).
Из твоих, сорри, Ваших, комментариев
0 Ответить
re ps: Почитай MSDN или SDK (не важно к чему) - поймешь, что значат комментарии Возможно станешь "ненормальным" программером. Нормальные - зануды и не знают что такое функция.
, лишний раз убедился, что комментарии писать на русском языке - дурной тон, писать лучше сразу на английской, почему? см. выше
не поверите, читал
0 Ответить
Ох, сорри! А может быть это зависит от ситуации?. И не думал, что комментарии на русском - это дурной тон. Поскольку начал программировать на языке 1С (8.*), то комментарии на русском, мне очень пригодились
Не нужно постоянно переключать раскладку...
0 Ответить
повторяю ещё раз, 1с за полноценный язык программирования не считаю
0 Ответить
Здесь этого никто не утверждал.
0 Ответить
На данный момент - программистом 1С.
0 Ответить
Понятно.
А то смутила фраза "процентов на восемьдесят на старой версии языка, а на десять – на новой". Видимо 10% на налоги ушли
Оценка статьи: 2
0 Ответить
Это не очепятка
10% ушли на комментарии в коде - на русском языке. Полезная привычка когда по существу.
0 Ответить
заголовок заинтересовал, содержание огорчило, хотя за пару ссылок спасибо, может как-нить пригодятся
языков на самом деле распространённых и используемых в программировании не так то уж и много, другое дело мелкие изначально провальные проекты, таких хватает.. когда я учился в университете, у нас был даже цикл лабоработных работ, где каждый должен был создать свой собственный язык программирования.. если их тоже в подсчёте учитывать.. то число естественно увеличится, только вот считать ли это полноценным языком? это так, просто забавы
а по поводу специалистов.. они должны иметь представление о десятках текущих распространённых языках, а владеть им достаточно только парой-тройкой.. остальными забивать себе голову нет смысла, пока не будет такой конкретной задачи
0 Ответить
Абсолютно согласна - знать, что есть на рынке важно для любого профессионала. А игры в создателей языков несут в себе определенную цель - научиться понимать логику и структуру любого языка программирования. Забавы забавам рознь.
0 Ответить
На самом деле проблемы множества языков не существует.
В статье намеренно (или, что хуже, случайно) перемешаны 2 задачи - выбора языка и программирования на нем. Выбор языка определяется задачей, уровень программирование определяется знанием языка. Если выбран подходящий для задачи и знакомый язык, то никаких "монстров" не получается. В противном случае будут "уродцы".
Отсюда следует вывод: много языков - это не плохо. Язык - это инструмент. И чем лучше он подходит для какой-то задачи, тем больше пользы от него. Можно и зубочисткой огород вскапывать, только толку мало.
Многие разработчики языков сегодня стремятся сделать "универсальные" языки, чтобы "состричь капусты". Это плохо, т.к. универсальное средство никогда не будет эффективнее специализированного, в идеале может с ним только сравняться. Но при этом сравняться с тысячью специализированных средств оно просто не сможет, слишком разные направления, несовместимые между собой.
В итоге и среди языков программирования появляются уродцы, которые тщась дать все, не дают ничего.
0 Ответить
Комментарий ("Отсюда следует вывод: много языков - это не плохо. Язык - это инструмент. И чем лучше он подходит для какой-то задачи, тем больше пользы от него.") повторяет вывод из статьи: "Так что можно и нужно уметь писать программы на разных языках, в том случае, когда это действительно необходимо для реальной пользы дела". Следовательно ценности не имеет.
0 Ответить
Можно и зубочисткой огород вскопать
)) Какая разница? Главное чтобы вскопан был. Другой вопрос - время. Но о нём, я упоминать не стал - это всегда критично для программеров. А выбор языка и программирования на нём, это не всегда решает сам программер.
Спасибо за отличный коммент!
0 Ответить
Пока дойдете до конца огорода, начало уже бурьяном порастет, или зима придет...
выбор языка и программирования на нём, это не всегда решает сам программер
Грамотный менеджер проекта не станет тратить время на переучивание программистов новому языку для "это круче". Он либо наберет новую команду под "это круче", либо воспользуется существующим инструментом, либо не будет браться за проект, реализовать который его команда не в состоянии на существующем инструменте.
0 Ответить
"Пока дойдете до конца огорода, начало уже бурьяном порастет, или зима придет..." - про время я уже сказал
А за проект придется браться 
Особенно, если он руководитель штатного отдела разработки. Иначе, какой же он менеджер?
А вот по поводу новой команды.... Для менеджеров проектов, решение проблем по поводу переучивания существующего штата, либо набора нового, это еще та головная боль на сегодня
0 Ответить
К тому же вопрос в переучивании программера не стоит, если он владеет несколькими языками. Однако выбирать на каком из них (!) работать по конкретному проекту "не всегда решает сам программер". Так что тоже - коммент не по существу.
0 Ответить