По результатам анализа компанией Black Duck Software изменений в более чем 200 тысячах проектах свободного ПО за прошедшие 12 месяцев отмечен (http://www.blackducksoftware.com/news/releases/2009-08-12) прирост доли ПО на рынке, относящейся к Javascript и PHP, а также снижение этого параметра для Shell и Perl.
Места распределились так:
- C 40.34% (-0.6%),
- C++ 13.43% (-0.6%),
- Java 10.29% (-0.7%),
- Javascript 7.6% (+2.1%),
- Shell 7.05% (-1.9%),
- PHP 5.19% (+0.3%),
- Python 2.63% (-0.1%
- SQL 2.65% (+1.1%),
- Perl 2.43% (-0.8%),
- C# 1.32% (0.1%),
- Ruby 1.01% (+0.2%),
- Assembler 0.83% (-0.4%),
- Pascal 0.73% (-0.2%),
- TCL 0.28% (-0.1%),
- Ada 0.22%( -0.2%).В целом продолжают доминировать языки C, C++ и Java, (65% всех проектов). Язык С - единственный, число строк на котором превысило миллиард. Из проектов, выпускавшихся за 12 месяцев, Javascript был использован в 36%, что на 3% больше, чем тот же показатель для Java. 5 верхних позиций в ...
URL: http://www.blackducksoftware.com/news/releases/2009-08-12
Новость: https://www.opennet.ru/opennews/art.shtml?num=23018
откуда сишарп О_О
неужели нашлось столько извращенцев
1%, я вас прошу, это Мигель наверно наваял уже столько :)
Вы, возможно, удивитесь, но под Windows свободное ПО тоже бывает. Почему бы его не на шарпе ваять?
имхо, средняя температура по больнице
А как на SQL проги пишут? Я всегда думал, что он для оперирования набором данных
http://plnet.org/
вот, например, вроде оно, можете изучать. ;)
не знал что такое есть... спасибо за ссылку.
как минимум - интересно.
ну дак, пишут там всякие функции да процедуры.
Хранимые процедуры вполне себе SQL
не совсем так.
это уже другой язык - у оракла pl/sql, у мс t-sql и т.д.
естественно, что в стандарте sql они не значатсяыйд
но в этом рейтинге видимо имелись в виду и они, и сам sql.
Скорее всего, имелись в виду процедурные расширения SQL, на которых пишут хранимые процедуры для Дельфина и Слона. Но это, мягко скажем, не совсем SQL.
> Язык С - единственный, число строк на котором превысило миллиард.И это плохо. Потому что copy-paste и велосипедизм процветает. То что на ocaml занимает 5 строк, на Си занимает >= 25.
А еще плохо когда руки из жо..ы растут.
На java/c++ с тем же успехом делаются copy-paste и велосипеды.
И много людей воспринимают функцианальное программирование? Как видно из результатов, даже ОО программирование и то не сильно много.
Просто, как показывает практика, ООП далеко не всегда оправдано. И уж тем более ФП. В том числе и по причине ограниченного количества толковых программистов на рынке.
>Просто, как показывает практика, ООП далеко не всегда оправдано.Оно оправдано всегда ;) Вот только ООП на ведущие роли выводит системного инженера и аналитика, а такие специалисты очень редко приживаются в проектах Свободного ПО.
>>Просто, как показывает практика, ООП далеко не всегда оправдано.
>Оно оправдано всегда ;)Вы слышали про ФП?
>>>Просто, как показывает практика, ООП далеко не всегда оправдано.
>>Оно оправдано всегда ;)
>
>Вы слышали про ФП?ФП это, в отличии от ООП, не производственная методика, а частный случай. ФП довольно эффективно, к примеру, при работе со списками. Но законченную методику разработки на его основе я себе с трудом представляю.
>>>>Просто, как показывает практика, ООП далеко не всегда оправдано.
>>>Оно оправдано всегда ;)
>>Вы слышали про ФП?
>ФП это, в отличии от ООП, не производственная методика, а частный случай.Этот "частный случай" до сих пор мучительно изобретают борцы за ООП. Те же замыкания, скажем.
>ФП довольно эффективно, к примеру, при работе со списками.
У Вас какое-то просто нищее представление об ФП. Оно в первую очередь эффективно тогда, когда задача поддаётся обобщению и формализации, а не состоит из состыкованного нагромождения частных случаев aka костылей.
>Но законченную методику разработки на его основе я себе с трудом представляю.
Не уверен, что SICP для Вас, но можете попробовать отрядить кого из коллег:
http://sicp.sergeykhenkin.com
http://newstar.rinet.ru/~goga/sicp/sicp.pdf
В качестве примера могу привести систему аварийного отключения кластера СКИФ-МГУ (T60), которая была написана за считанные месяцы тремя людьми на парт-тайм, бинарник занимает несколько десятков килобайт, заработал, кажется, с первого запуска. Это один из функциональных языков, заточенных под распределённые системы.У коллег есть опыт разработки, скажем, нетривиального веб-софта (btw изначально amazon.com был написан на лиспе, IIRC одним человеком). Говорят, никакая Java рядом не валялась по удобству отладки и горячего сопровождения с живой лисп-машиной.
В ALT Linux инфраструктура управления системой создана с применением DSL на базе Scheme.
Просто это тоже другой мир -- здесь принято думать головой, потом писать несколько строчек. А не долбить кнопки от звонка до звонка по реквайрментам. Кстати о них:
---
If you don't already know exactly what to build, then you're in the wrong business.
At the very least, you should hire someone who does know. Don't gather business
requirements: hire domain experts.
--- http://steve-yegge.blogspot.com/2008/08/business-requirement...
>И это плохо. Потому что copy-paste и велосипедизм процветает. То что на ocaml занимает 5 строк, на Си занимает >= 25.Самое ужасное, что большая часть этого кода написана влоб: никаких попыток рефакторинга, обобщений конструкций; никаких попыток сделать код более наглядным, простым. Невероятное количество кода, написанного в дурном стиле, чего только такие комментарии стоят: /* Maybe this will work */. В результате имеем кучу write-only кода, который проще переписать, чем понять как это работает... вернее сказать, шевелится.
Действительно, там где могло быть 5 строк, на самом деле 25.
А смысл, если все равно для себя пишется? Другое дело если это на производительность влияет
>А смысл, если все равно для себя пишется?Есть такое понятие как вкус. В частности, им мастер отличается от лабуха. И тот, кто привык "слепить на скору руку для себя" -- не сможет сделать качественно для кого угодно, привычки не пустят.
>Другое дело если это на производительность влияет
Это как раз дело десятое.
Вы видимо никогда профессионально не программировали, иначе не говорили бы такой чуши про производительность.
>Вы видимо никогда профессионально не программировалиРазумеется, нет. Если подразумевать под профессиональностью ответственность за оплаченный результат.
Я пишу или исправляю "для души" или по производственной необходимости, но в последнем разе это побочный процесс, а не основной.
>иначе не говорили бы такой чуши про производительность.
Вы, видимо, никогда профессионально не дискутировали. Иначе б для начала подписались, чтоб своим именем за слова отвечать.
Производительность вовсе не всегда важна в первую голову. Водитель может подумать про мощность двигателя, которая не важнее надёжности тормозов и отзывчивости рулевого управления. Так и для кода бывает важнее надёжность и корректность, а это прямое следствие наличия вкуса у разработчика.
Что же до производительности -- ну одна моя софтинка, написанная для бакалаврской работы, за несколько суток выполнила на Pentium 133 расчёты до x = 3000 по задаче, вычислительная сложность которой растёт экспоненциально, а предшественники добрались в разумное время что-то до 100 или 150. Да, в этом была существенная заслуга libgmp, но мне почему-то кажется, что мои инварианты тоже помогли: http://fly.osdn.org.ua/~mike/works/chem/alkanol/alkanol.c
Поэтому прежде чем упрекать меня в пренебрежении производительностью, предъявите хоть какие-то свидетельства того, что сами понимаете, о чём говорите. В виде кода. До того буду считать пустопорожним трёпом.
PS: мне и тогда было стыдно за MAX_LEN, но на третий месяц научный уже терял терпение, а писалось это всё два вечера под настроение. :) Причесать хотел, но надо было запускать.
Да вам батенька нужно в МS работать - интерфейсы писать. (Только для них это главное в программе).
>Да вам батенька нужно в МS работать - интерфейсы писать. (Только для
>них это главное в программе).Интерфейсы еще надо уметь разрабатывать и писать. Это подчас бывает чрезвычайно сложно, так как к интерфейсу подключается то, свойства чего заранее трудно формализуемы.
(Напомню, интерфейсы - это не только ГУИ, это может быть например пайп+протокол взаимодействия. А ГУИ это не только рисование окошек и дизайн)
>Да вам батенька нужно в МS работать - интерфейсы писать.Спасибо, я и в IBM-то не пошёл -- плохо переношу здоровые лавки изнутри.
>(Только для них это главное в программе).
Программы бывают разные. Для одних действительно важнее полпроцента производительности, чем надёжность или безопасность -- но это в основном HPC. Для других действительно важнее интерфейс -- как видим из истории Apple и особенно MS, на этом можно выехать без особой технологии.
Мне кажется, что программы стоит писать "как для себя и близких" -- на совесть. Тогда и получится совместить баланс удобности, мощности, масштабируемости, производительности, поддерживаемости, расширяемости, да ещё и улучшать это всё в разумные времена и не выгорая.
Просто когда продумываешь на совесть, то писать тяп-ляп уже не лезет.
Вообще рекомендую почитать на досуге, уж больно в точку дядька описал "делать красиво":
http://www.lib.ru/MEMUARY/ERSHOW_W/zapiski_ezdowogo_psa.txt
>Вы видимо никогда профессионально не программировали, иначе не говорили бы такой чуши
>про производительность.Вы видимо никогда не работали в команде, где производительность все-таки лучше иногда принести в жертву читаемости и наглядности кода, для того, чтобы упростить его дальнейшее сопровождение.
>Вы видимо никогда профессионально не программировали, иначе не говорили бы такой чуши
>про производительность.На производительность наплевать (клиент её практически никогда не способен оценить), главное к сроку успеть и костылей побольше напихать, чтоб на поддержке ещё пару лет клиента доить.
Дяденька, а Вы правда индус-триал? :]
>Дяденька, а Вы правда индус-триал? :]Понимаете, "производительность" очень сложно продать сразу. Клиент её в расчёт, чаще всего не берёт, потому что не способен оценить её и представить, что это такое. Вы, наверное, удивитесь, но для абсолютного большиства красивая коробка при покупке более важный аргумент, чем производительность (и это в среде корпоративных клиентов). Более того, низкая начальная производительность замечательное качество. Оно позволяет значительно повысить прибыльность жизненного цикла продукта.
>>Дяденька, а Вы правда индус-триал? :]
>Понимаете, "производительность" очень сложно продать сразу.Да мне вон уже анонимный эксперт много нового про меня же и рассказал -- короче, понимаю ;)
>Более того, низкая начальная производительность замечательное качество. Оно позволяет
>значительно повысить прибыльность жизненного цикла продукта.Это с жлобской точки зрения -- я не хочу, чтоб ко мне так относились, и не отношусь так сам. Одно дело -- если к сроку не получается оптимизировать и важнее функционал в принципе (это нормально), а совсем другое -- это отношение "жрите чо дают".
Проведу аналогию: некоторые делают ресурсы и пишут контент под PR, а мы тут как-то чуть ли не случайно заметили у себя страничку с PR=7 -- там был перевод одного довольно важного документа, на который в качестве официального стояла ссылка с сайта-источника. Ну вот так вот получилось -- мы не предполагали, а просто делали на совесть.
PS: простите, не хочу обидеть, но считаю отношение к клиенту _действительно_ важным -- и что Вы в нём критическим образом неправы. Возможно, я испорчен работой с хорошими людьми и возможностью послать премьер-министра, если не хочу с ней работать.
>PS: простите, не хочу обидеть, но считаю отношение к клиенту _действительно_ важным
>-- и что Вы в нём критическим образом неправы. Возможно,
>я испорчен работой с хорошими людьми и возможностью послать премьер-министра, если
>не хочу с ней работать.Я не об отношению к клиенту. Проект чаще всего существуеют в крайне ограниченных временем пределах и для массового рынка лучше пожертвовать "производительностью", чем, условно говоря, красивой коробкой. Нет предела совершенству, но время итерации на релиз строго определены и под это время забит бюджет.
>А смысл, если все равно для себя пишется?Если для себя пишешь - то спрячь и не позорься! А в место этого вываливают в общую кучу: "посмотрите, сколько у нас свободного ПО!".
>То что на ocaml занимает 5 строк, на Си занимает >= 25.Смотря где. Если вы тупо работаете с БД, строк с подключением/авторизацией, запросом данных, обработкой рекордсета просто не избежать. И в чём тогда выйгрыш? В нахождении чисел Фибоначчи? :)))
Да и сами библиотеки (как неотъемлемая часть языка) - кому нужен суперязык, если в нём ГУЙ или БД делаются через Ж? (если они вообще есть)
Пока как промышленный язык идеален только C#, но его ублюдочное жабонаследие и виндовз-ориентация всё портят - линупсисты закономерно его отвергают.
>>То что на ocaml занимает 5 строк, на Си занимает >= 25.
>Смотря где. Если вы тупо работаете с БД, строк с подключением/авторизацией, запросом
>данных, обработкой рекордсета просто не избежать. И в чём тогда выйгрыш?(покопавшись в загашнике) Ну изобразите на сях кратенько, пожалуйста.
#!/usr/bin/env ruby
require 'dbi'
meta = Hash.new
sql = "select key,value from meta where (key='ARTIST' or key='TITLE') and content_id = 856 order by key;"
DBI.connect('DBI:Pg:xxx', 'yyy', 'zzz') do | dbh |
dbh.select_all(sql) do | k,v |
meta[k]=v
end
puts meta['ARTIST'], meta['TITLE']
endЭтот пример иллюстрирует заодно и то, что на иерархической базе данных делалось бы куда красивше. Но взять тогда ту же GT.M наскоро не получалось.
>Да и сами библиотеки (как неотъемлемая часть языка) - кому нужен суперязык,
>если в нём ГУЙ или БД делаются через Ж? (если они вообще есть)Тому, у кого сообразилка подсказывает, что если один язык прекрасно подходит для ввода и первичного обмолота данных, другой -- для их обработки, третий -- для той же визуализации, то бывает осмысленно сделать проект на трёх языках, чем уродоваться на одном.
Например, Непейвода-младшая на прошлой зимней образовательной конференции (или в Томске?) именно такой пример и показывала, с оценкой количества строк относительно C или C++, не помню точно. Разница была на порядок, опять же если не изменяет склероз.
>Пока как промышленный язык идеален только C#
Уважаемый, за пределами подкрашенного Visual Basic не все _тупо_ работают с БД.
PS: я не языковед, просто доводилось сталкиваться с немного разными вещами. И когда получается использовать оптимальные для задачи инструменты, а не костылить на ходу преобразование полярного медведя в декартовы координаты, то и писать легче, и читать, и работает оно тоже обычно веселей.
PPS: ой сколько ностальгии в загашнике нашлось... :)
Дык и пишите ядро на ocalm
Теперь буду работодателям ссылку давать, что мой любимый C занимает чуть меньше половины рынка ;-)
Растет JavaScript, PHP, SQL и Ruby. Я не хочу этого будущего.
Хм, ну ладно еще могу понять PHP и Ruby: реально крутые перцы делают сайты исключительно на Perl, ибо он куда мудренее :) А вот JS и SQL чем не угодили?
>Растет JavaScript, PHP, SQL и Ruby. Я не хочу этого будущего.Чем же они вам не угодили? С ними рентабельность большиства проектов возрастает в разы в сравнении с Явой и тем более Си. Руби так и вообще очень удачный язык. А в ява-реализации ещё и достаточно эффективный.
Assembler только 0.83%
я не хочу _такого_ будущего( деградация программистов - расцвет быдлокодеров
>Assembler только 0.83%
>я не хочу _такого_ будущего( деградация программистов - расцвет быдлокодеровсрочно переписать будущее на asm'е!!!
>деградация программистов - расцвет быдлокодеровСовсем недавно для оценки плохой работы программиста использовали очень емкую и выдержанную фразу "дурной стиль". Сейчас же повсюду слышно употребление совершенно грубого и вульгарного определения "быдлокодер". Вот это падение культуры общения - самый яркий признак деградации как программистов, так и тех, кто пользуется их трудами!
Понимали б лабораторные образцы Луговского, насколько все эти "быдло-" и "недо-" в первую очередь характеризуют именно тех, кто их использует -- задумались бы.
> Совсем недавно для оценки плохой работы программиста использовали очень емкую и выдержанную фразу "дурной стиль". Сейчас же повсюду слышно употребление совершенно грубого и вульгарного определения "быдлокодер". Вот это падение культуры общения - самый яркий признак деградации как программистов, так и тех, кто пользуется их трудами!+1 Но я не думаю, что имеет место деградация. Просто программирование становится массовой профессией, а количество разума, как известно, величина постоянная :)
> Assembler только 0.83%
> я не хочу _такого_ будущего( деградация программистов - расцвет быдлокодеровПодозреваю, что это вызвано не деградацией, а увеличивающимися тенденциями к кроссплатформенности.
>Assembler только 0.83%
>я не хочу _такого_ будущего( деградация программистов - расцвет быдлокодеровТребования к квалификации программистов должны от нынешнего, необоснованно завышенного, уровня радикально снижатся. Программист это просто машинистка.
>Программист это просто машинистка.Ну Вы даёте. "Машинистка" -- это даже не кодер, даже тот хоть чуточку должен всё-таки головой соображать, а не только качественно выдрессированным спинным мозгом. А программист может час думать и десять строк написать, _и это нормально_. С рубями и прочим высокоуровневым так тем более.
PS: "а вот блохи..." или если кому ещё пригодится подручный Pickaxe с поиском: http://ruby.osdn.org.ua
>>Программист это просто машинистка.
>
>Ну Вы даёте. "Машинистка" -- это даже не кодер, даже тот
>хоть чуточку должен всё-таки головой соображать, а не только качественно выдрессированным
>спинным мозгом.Да вот, понимаете, многолетний опыт всё больше клонит в ту сторону, что для индустрии ПО принципиально не верно готовят кадры. Ну не нужны индустрии программисты в старом понимании, т.е. грамотные математики прикладники с многолетним очень сложным университетским образованием. Такие башковитые парни достойны лучшей участи и для них есть множество куда более важных задач в этом мире. Для удачного (коммерчески удачного массового) проекта в ПО достаточно грамотного руководителя проектов, системного архитектора и коллектива системных аналитиков. Вот в квалификацию этих специалистов и стоит вкладываться. Роль же массовых программистов сводится в такой схеме к работе по сборке модулей. На это способен выдрессированый пэтэушник.
Сейчас же, по факту, мы имеет вопиющее отставание и неэффективность при производстве ПО. Потому что проектированием занимаются (если вообще проектирование имеет место быть) люди в этом некомпетентные, т.е. программисты. Ладно бы дипломированные программисты, так нет, большиство (98%) всех толковых выпускников профильных кафедр ВТ уходят в более хлебные и интересные отрасли, а программистами становится чёрти кто, когда основных критерием в получении работы является смутное знание синтаксиса какого-нибудь из массовых языков программирования (что без освоения методик разработки совершенноо бесполезно).
>Ну не нужны
>индустрии программисты в старом понимании, т.е. грамотные математики прикладники с многолетним
>очень сложным университетским образованием. Такие башковитые парни достойны лучшей участи и
>для них есть множество куда более важных задач в этом мире.Я бы еще добавил, что математиков вообще НЕЛЬЗЯ подпускать к написанию кода. После них разбираться сам черт ногу сломит. Такие выверты попадаются.. мама не горюй. Тут я согласен с Д.Спольски. Написание кода чем-то похоже на хорошее сочинение. И лингвисты для такой работы подходят лучше.
> а программистами становится чёрти кто, когда
>основных критерием в получении работы является смутное знание синтаксиса какого-нибудь из
>массовых языков программирования (что без освоения методик разработки совершенноо бесполезно).Я бы поостерегся называть этих людей программистами. Интересно где такие критерии при приеме на работу..
>Да вот, понимаете, многолетний опыт всё больше клонит в ту сторону, что
>для индустрии ПО принципиально не верно готовят кадры.Мне тоже подобное кажется.
>Ну не нужны индустрии программисты в старом понимании, т.е. грамотные математики
>прикладники с многолетним очень сложным университетским образованием.Мне кажется, что логика (даже важнее математики) и... олимпиадный опыт тут полезнее мехмата.
>Для удачного (коммерчески удачного массового) проекта в ПО достаточно грамотного
>руководителя проектов, системного архитектора и коллектива системных аналитиков.
>Вот в квалификацию этих специалистов и стоит вкладываться. Роль же массовых
>программистов сводится в такой схеме к работе по сборке модулей. На это способен
>выдрессированый пэтэушник.Возможно, Вам будет интересно почитать это: http://www.nucalc.com/Story/
Описанное намного ближе мне и думаю -- тем людям, которых считаю программистами, чем описанный Вами конвейер. Но я и не играю в "коммерчески удачное массовое", мне важней, чтоб людям было с чем лучше решать свои задачи. On a smaller scale, of course.
>Сейчас же, по факту, мы имеет вопиющее отставание и неэффективность при производстве
>ПО. Потому что проектированием занимаются (если вообще проектирование имеет место быть)
>люди в этом некомпетентные, т.е. программисты.Понимаете, паркетные архитекторы -- это, конечно, не так удручает, как паркетные генералы... но что-то не хотел бы я ни служить под началом офицера, который сам не сделает то, что приказывает другим, ни разрабатывать по проекту архитектора, который сам не может сесть и изложить в коде то, что вырисовывает. Не всё, понятно, но любой отдельный кусочек.
>Ладно бы дипломированные программисты, так нет, большиство (98%) всех толковых
>выпускников профильных кафедр ВТ уходят в более хлебные и интересные отрасли,
>а программистами становится чёрти ктоВот Вы и описали то, что для программиста всё-таки важны и мозги, и некоторые иные качества (не в последнюю очередь коммуникабельность, умение слышать, расстановка приоритетов и ответственность). Просто когда в других местах эти качества ценятся в различных смыслах более явно, то почему Вы удивляетесь, что не добираются?
У нас на конторе собралась отличная команда. И я лично считаю, что это не в последнюю очередь потому, что в людях видят -- и ценят -- людей, а не винтики M4. Чего и Вам желаю.
>Мне кажется, что логика (даже важнее математики) и... олимпиадный опыт тут полезнее
>мехмата.На сколько я знаю, ни один из победителей международных олимпиад по программированию не избрал в качестве своей профессиональной деательности труд программиста.
>Понимаете, паркетные архитекторы -- это, конечно, не так удручает, как паркетные генералы...
>но что-то не хотел бы я ни служить под началом офицера,
>который сам не сделает то, что приказывает другим, ни разрабатывать по
>проекту архитектора, который сам не может сесть и изложить в коде
>то, что вырисовывает. Не всё, понятно, но любой отдельный кусочек.Дворника должен управлять дворник? А министр транспорта обязан уметь водить паровоз? Управление и архитектура совершенно другие области деятельности, чем написание кода, и востребуют иные качества. Хотя, я считаю, что отличный программист, получив необходимые знания вполне может стать системным аналитиком или архитектором, если, как раз, отбросит оковы постоянного оглядывания на проблемы реализации.
>>Мне кажется, что логика (даже важнее математики) и... олимпиадный опыт тут полезнее
>>мехмата.
>На сколько я знаю, ни один из победителей международных олимпиад по программированию
>не избрал в качестве своей профессиональной деательности труд программиста.Я их всех не знаю; сам по математике имел диплом на городе (столица), по химии -- на республике, а вот по программированию закончилось районом (по ошибке засунули в старшую группу). Первое было на фоне обычной школы и полного отсутствия дрессировки, второе -- пару лет ввязался. Последнее было ошибкой, задачи по программированию показались тогда какими-то противоестественными (они были шаблонными под дрессировку, как понял позже). При этом моё решение на предыдущем этапе -- СЮТ -- разбирали всем преподавательским составом и так и не поняли, но развёрнутое ради хохмы в итерацию вместо ожидавшейся рекурсии тест прошло. :)
Так что честно говоря, даже и не подразумевал олимпиады по программированию, а скорее "вообще" -- как специфический вид _спорта_, где как раз и важна не только голова, а и расстановка приоритетов с отслеживанием времени.
>>Понимаете, паркетные архитекторы -- это, конечно, не так удручает,
>>как паркетные генералы...
>Дворника должен управлять дворник?Человек, понимающий эту задачу. А что, балерина должна в жэке сидеть, что ли?
>А министр транспорта обязан уметь водить паровоз?
В идеале -- да, обязан. И вообще не витающий в облаках, а думающий реалиями. Не только управленец, а и практик.
Я Вас шокировал? А между прочим, наш директор может сесть и написать код. Или вынести мусор. И ничего, корона не падает, уважения не теряет. Разумеется, это исключение, но _надо_ уметь делать то, что говоришь делать другим.
Когда этого нету -- разруха в головах выше выливается в уныние голов ниже. В безразличие к работе. В хлам, который заворачивают покрасивше. А потом удивляемся, сломав зуб о камушек в буханке хлеба -- так её кто-то такой же вот и пёк.
>Управление и архитектура совершенно другие области деятельности, чем написание кода
>и востребуют иные качества.Тем не менее рисовать верх, не имея понятия о технических и организационных ограничениях низа -- либо безумие, либо обобщённый опыт менеджера уровня той же Johanna Rothman. (btw рекомендую http://www.pragprog.com/titles/jrpm/manage-it)
>Хотя, я считаю, что отличный программист, получив необходимые знания
>вполне может стать системным аналитиком или архитектором, если, как раз, отбросит
>оковы постоянного оглядывания на проблемы реализации.Для того есть довольно простые изобретательские приёмы вроде "представьте, что у вас есть волшебная палочка" (бишь "помечтать об идеальном решении, а потом набрасывать на него ограничения и смотреть, насколько близко получается подобраться").
Я продолжаю считать, что архитектор без опыта программирования своими руками -- это лажа.
PS: свою первую заметную архитектурную тему проводил в 2002/2003. Кажется, до сих пор работает -- и российские лавки, платформы которых делались примерно как вот Вы описываете, подбирали челюсти и искали, как бы купить скопом. :) (область -- мобильный контент)
>>В идеале -- да, обязан. И вообще не витающий в облаках, а думающий реалиями. Не только управленец, а и практик.Это типичный расейский стереотип. Результаты следования ему, как говорится, на лицо. В России до сих пор нет ни одной хорошо управляемой компании, потому что дворниками вроде как должен управлять лучший дворник. Это в корне не верно. Исполнитель всегда останется исполнителем, он никогда не станет генератором эффективных свежих идей и никогда не сможет добиться их исполнения.
>> А между прочим, наш директор может сесть и написать код.
Вы путаете директора, и лидера.
>>>В идеале -- да, обязан. И вообще не витающий в облаках, а думающий реалиями. Не только управленец, а и практик.
>
>Это типичный расейский стереотип.Зато более реалистичный, чем ваши рассуждения об исполнителях и "генераторах идей" (они-то тут причём?). Если руководитель не может понять и половины "низлежащей" терминологии, он не руководитель - он "управленец", способный запороть любой проект. Для любого решения нужно представлять, чем оно воплощается в реальности. Вплоть до выбора Qt или Gnome - от этого может зависеть всё, хотя внешне это выглядит как выбор между чаем и кофе.
>Зато более реалистичный, чем ваши рассуждения об исполнителях и "генераторах идей" (они-то
>тут причём?). Если руководитель не может понять и половины "низлежащей" терминологии,
>он не руководитель - он "управленец", способный запороть любой проект. Для
>любого решения нужно представлять, чем оно воплощается в реальности. Вплоть до
>выбора Qt или Gnome - от этого может зависеть всё, хотя
>внешне это выглядит как выбор между чаем и кофе.Понимаете, чаще всего терминологией не владеют "программисты". Большинство из них и близко не знают методологию ни UML, ни IDEF, ни ARIS. Ну, допустим, это рядовому программеру и не нужно. Но вот повальное незнание шаблонов проектирования, неумение ими пользоваться это уже ни в какие ворота. А без этого невозможно управлять сложностью, невозможно управлять рисками, т.е. денег тебе никто не даст, или прийдётся привлекать крайне дорогие средства.
Руководитель никакой терминологии знать и не должен, посколько терминологию проекта определяет он сам. Утверждает словарь.
>>>В идеале -- да, обязан. И вообще не витающий в облаках, а думающий реалиями.
>>>Не только управленец, а и практик.
>Это типичный расейский стереотип.У Вас гораздо хуже -- типичный пиндосский.
>Результаты следования ему, как говорится, на лицо.
Я, пожалуй, воздержусь от характеристики общества потребления.
>Исполнитель всегда останется исполнителем, он никогда не станет генератором
>эффективных свежих идей и никогда не сможет добиться их исполнения.Вы оперируете изначально кривыми понятиями: "исполнитель" -- это в КУМИРе такой есть. А у меня за спиной бывают живые люди. В каждом из которых искра Божья есть.
>>> А между прочим, наш директор может сесть и написать код.
>Вы путаете директора, и лидера.Я ничего не путаю. Это Вас так и не научили грамотно пользоваться запятыми и частицей "не". За "лидером", который показать сам не может, идти не собираюсь. И с директором, который не соображает, чего требует -- не собираюсь работать. Потому как когда слепой ведёт слепого, оба упадут в пропасть.
Мне искренне жаль тех, кому приходится работать с Вами и тем более пользоваться тем, что Вы делаете. Вас тоже, но меньше -- поскольку упорствуете.
>Вы оперируете изначально кривыми понятиями: "исполнитель" -- это в КУМИРе такой есть.
> А у меня за спиной бывают живые люди. В
>каждом из которых искра Божья есть.Вот уж нет. Многим, большинству, чётко очерченные обязанности и требования куда больше по душе и вызывает меньший стресс. Меньше стресса -- больше результата.
Вы описываете удачный случай маленькой высокопрофессиональной команды, выполняющей разовые сложные проекты в основом для профессионального заитрересованного в результате заказчика. А массовый рынок явление несколько другое. Там и заказчик ни в чём не заинтересован, кроме того, чтоб его обманули, и исполнители -- тупые ленивые твари.
>Вы описываете удачный случай маленькой высокопрофессиональной команды,Да.
>выполняющей разовые
Нет.
>сложные проекты в основом для профессионального заитрересованного в результате заказчика.
Да.
>А массовый рынок явление несколько другое. Там и заказчик ни в чём не заинтересован,
>кроме того, чтоб его обманули, и исполнители -- тупые ленивые твари.Нет.
PS: насколько понимаю, на массовом рынке нет "заказчика", а есть "покупатель/абонент/клиент". Т.е. речь о диалоге и индивидуализации практически не идёт.
PPS: Вы пиво пьёте? Насколько понимаю -- ряд производителей в Украине (как минимум) потерял былую репутацию на ускорении процесса вызревания и потере внимания к качеству -- дескать, пипл схавает. В штатах, насколько слышу, вообще пить невозможно то, что не из небольших частных пивоварен, не рекламирующихся вообще, кроме как из рук в руки. Проверить эти утверждения самому не с руки (пиво не пью), но может быть, затронет какую струнку: можно не терять человеческое лицо и на массовом рынке.
>PPS: Вы пиво пьёте? Насколько понимаю -- ряд производителей в Украине
>(как минимум) потерял былую репутацию на ускорении процесса вызревания и потере
>внимания к качеству -- дескать, пипл схавает. В штатах, насколько
>слышу, вообще пить невозможно то, что не из небольших частных пивоварен,
>не рекламирующихся вообще, кроме как из рук в руки. Проверить
>эти утверждения самому не с руки (пиво не пью), но может
>быть, затронет какую струнку: можно не терять человеческое лицо и на
>массовом рынке.Бутылированное не пью. И другим настоятельно не рекомендую (имел опыт сотрудничества с одной, практически монопольной на территории России и Украины, пивной транскомпанией, более-менее знаком с технологией изготовления их продуктов). Пью только местных семейных пивоварен не более чем паручасовой свежести. Другое уже здоровье не позволяет.
1. Маркетолог определяет какой продукт будет иметь успех на рынке и формирует задание
для архитектора/системного аналитика.2. Все кроме маркетолога должны не просто уметь решать профессиональные задачи,
а иметь большой опыт решения этих задач.3. Объем опыта и определяет позицию на лестнице кодировщик - архитектор - аналитик.
4. Т.о. здесь имеет место стандартная схема роста в иерархической системе, когда
руководитель (генерал) должен успешно пройти все уровни, начиная с нижнего.5. Сфера программирования рождена математиками и непосредственно связана с
математикой. Лучше всего учит решать профессиональные задачи математический
анализ. Математическая квалификация является необходимым условием успешной
работы и карьеры в программировании.6. Важна и стандартная технологическая схема - требования - проект - реализация
- проверка (у нас тестирование) - сдача - поддержка.
>Места распределились так:
>- C 40.34% (-0.6%),
>- C++ 13.43% (-0.6%),Что интересно, сколько дифирамбов ни пели про ООП (уже лет 10 уши вянут), на реальности это не отражается. :) Выигрывает самый простой язык, причём даже с атавизмами типа "null-terminated strings" и ублюдочной системой модульности (заголовочные файлы, порядок объявлений).
И совсем странно, что Жаборынок ещё как-то дышит - такое ощущение, что больной сидит полностью на наркоте (читай "фин. вливаниях") и из-под простыни кто-то его шевелит, изображая "нетруп".
>[оверквотинг удален]
>>- C 40.34% (-0.6%),
>>- C++ 13.43% (-0.6%),
>
>Что интересно, сколько дифирамбов ни пели про ООП (уже лет 10 уши
>вянут), на реальности это не отражается. :) Выигрывает самый простой язык,
>причём даже с атавизмами типа "null-terminated strings" и ублюдочной системой модульности
>(заголовочные файлы, порядок объявлений).
>И совсем странно, что Жаборынок ещё как-то дышит - такое ощущение, что
>больной сидит полностью на наркоте (читай "фин. вливаниях") и из-под простыни
>кто-то его шевелит, изображая "нетруп".Тор, попробуйте создать систему контроля воздушного пространства на ПХП без всяких методик управления сложностью. Ява хороша прежде всего своей вписанностью во взрослые методики разработки (и интеграции) и своей низкой рисковостью.
>Ява хороша прежде всего своей вписанностью во взрослые методики
>разработки (и интеграции) и своей низкой рисковостью.Угу. А не низкой стоимостью разработки/поддержки, как некоторые думают.
Только такую систему я бы предпочёл заказывать у ФП-шников, а не явистов. Были тут прецеденты на АЭС -- как раз в этой плоскости.
>>Ява хороша прежде всего своей вписанностью во взрослые методики
>>разработки (и интеграции) и своей низкой рисковостью.
>
>Угу. А не низкой стоимостью разработки/поддержки, как некоторые думают.
>
>Только такую систему я бы предпочёл заказывать у ФП-шников, а не явистов.
> Были тут прецеденты на АЭС -- как раз в этой
>плоскости.Проблема в массовости. ФП-шники специалисты штучные. Их решения не шаблонируются (сомневаюсь, что есть изданный справочник ФП-шаблонов проектирования). Поэтому высок риск зависимости от частного решения.