Основной критерий выбора технологий программирования: "Чтобы вас можно было заменить на васю, не знающего языка и он мог прочесть код": http://ugenk.livejournal.com/188023.html
"Полноценных" - это в смысле "тьюринг-полных"? Потому что придумать десяток действительно полноценных языков, в которые не войдут хаскель и перл, я очень затрудняюсь... Перл при этом, конечно, нишевый, и под него может тупо не быть задач, но вменяемой замены перлу в его нише (быстро и лаконично обработать текст или то, что к нему легко сводится) я не знаю.
Боюсь, что на самом деле там message "чтобы вас можно было заменить на Васю, не знающего ни...чего, и он мог доделать то, за что вам не захотели заплатить". Просто если его выдать честно, то облом очевиден даже сказавшему, а очень хочется, чтобы так получалось... Вот и прикрываются эвфемизмами.
А этого никто и не скрывает. Вопрос даже не в том, что "заменить". А в том, что система сдается в эксплуатацию, и "вы" пропадаете (по разным причинам). А "нам" - бегай по Беларуси и ищи знатоков F#.
Ребе, у вас будет та же проблема с ораклами-жабами-крестиками-гопнетами и вообще любыми языками. По той причине, что вопросы "кто и как будет поддерживать" нужно задавать и закладывать в ТЗ/договоры до внедрения, а не давать это на откуп начальству.
А это известная болезнь. Сначала не хотят платить за поддержку или аутичные админы не хотят общаться с поставщиками системы на тему "внятно описать новые требования", а вместо этого лезут делать чернь своими пхпшными ручонками. Или сразу экономят, заказывая говнище, в котором нужно копаться и допиливать, вместо того, чтобы обратится к нормальным подрядчикам.
Тогда писать надо на эрланге, у него продакшен код по сравнению с джавой, сишарпом или там питоном читается проще всего (имхо) из-за минимизации стэйта и философии fail early (тоже имхо)
Я сугубо по своему опыту - владею C#, JS, Python, при этом код на Эрланге мне понятен гораздо более кода на Скале и Хаскеле, его можно бегло читать, при том что я на нем ничего не писал и не пытался специально изучать в отличие от того же Х.
краткий пересказ поста по ссылке: «Денег нет, платить не хотим, работу делать надо. поэтому мы набираем студентов на испытательный срок, они ебошат за еду как проклятые, затем их увольняем и набираем новых. Соответственно, ЯП и технологии выбираем такие, которые эти студенты почти наверняка знают.»
Очередной яркий пример программиста, который не занимается эксплуатацией своих продуктов. Отдавать на 100% поддержку на откуп производителю - плохо, очень плохо. У местных кадров должна быть возможность хотя бы примерно понять, что там внутри системы происходит, а не на каждый чих открывать problem management request за многотыщбаксов.
Админы/эксплуатационники которые смотрят в код купленной системы - это пиздец от входа. Не говоря уже о том, чтобы его править. Должны быть логи, удобные ручки для админов и прочее. Но не код.
Дело заказчика - описать требования, дать денег и получить продукт. Затем он должен платить абонентскую плату, за поддержу и некоторые изменения. Чтобы получить исходники - он вообще должен дать охулиард денег. И уж точно не его дело, на чем будет написан продукт. Есть граничные условия - где и в каких условиях сделланое должно работать, и не более.
>problem management request за многотыщбаксов Не обеднеют.
Непонятно, почему такой подход применяется только к ЯП.
Например, при выборе процессора для девайса можно: "ну и что, что батареек не хватит и надо 2 вентилятора? Зато можно на дельфах программировать!" При выборе авто: "Прожорливая? Медленная? Часто ломается? Зато водитель сам сможет карбюратор прочистить!" Критерий выбора жены предлагать не буду :)
no subject
no subject
no subject
no subject
no subject
python
очень отлично обрабатывают текст
(no subject)
(no subject)
(no subject)
(no subject)
(no subject)
(no subject)
(no subject)
(no subject)
(no subject)
(no subject)
(no subject)
(no subject)
(no subject)
(no subject)
(no subject)
(no subject)
(no subject)
(no subject)
(no subject)
no subject
(no subject)
(no subject)
(no subject)
(no subject)
(no subject)
(no subject)
(no subject)
no subject
no subject
no subject
(no subject)
(no subject)
(no subject)
no subject
no subject
А в том, что система сдается в эксплуатацию, и "вы" пропадаете (по разным причинам). А "нам" - бегай по Беларуси и ищи знатоков F#.
no subject
По той причине, что вопросы "кто и как будет поддерживать" нужно задавать и закладывать в ТЗ/договоры до внедрения, а не давать это на откуп начальству.
(no subject)
no subject
Сначала не хотят платить за поддержку или аутичные админы не хотят общаться с поставщиками системы на тему "внятно описать новые требования", а вместо этого лезут делать чернь своими пхпшными ручонками.
Или сразу экономят, заказывая говнище, в котором нужно копаться и допиливать, вместо того, чтобы обратится к нормальным подрядчикам.
no subject
no subject
no subject
no subject
(no subject)
no subject
(no subject)
no subject
no subject
no subject
(no subject)
(no subject)
no subject
Должны быть логи, удобные ручки для админов и прочее. Но не код.
(no subject)
(no subject)
no subject
Дело заказчика - описать требования, дать денег и получить продукт. Затем он должен платить абонентскую плату, за поддержу и некоторые изменения. Чтобы получить исходники - он вообще должен дать охулиард денег. И уж точно не его дело, на чем будет написан продукт. Есть граничные условия - где и в каких условиях сделланое должно работать, и не более.
>problem management request за многотыщбаксов
Не обеднеют.
(no subject)
(no subject)
(no subject)
(no subject)
no subject
Например, при выборе процессора для девайса можно: "ну и что, что батареек не хватит и надо 2 вентилятора? Зато можно на дельфах программировать!"
При выборе авто: "Прожорливая? Медленная? Часто ломается? Зато водитель сам сможет карбюратор прочистить!"
Критерий выбора жены предлагать не буду :)
no subject