|
ru.linux
- RU.LINUX ---------------------------------------------------------------------
From : Sergey Bogdanov 2:5020/400 19 Jun 2002 11:47:09
To : Victor Wagner
Subject : Re: Highlighting in vim
--------------------------------------------------------------------------------
Victor Wagner wrote:
>>>Как правило, такие вложения в апгрейд собственных мозгов окупаются.
>>
>
> SB> Только вот вопрос, все ли вложившие усилия в апгрейд мозгов могут найти
>
> Если было, что апгрейдить, то могут найти если не соответствующую, то
> хотя бы соответствующим образом оплачиваемую.
>
> SB> Hет я не говорю, что это плохо. Просто можно найти сотни других мест для
> SB> проведений апгрейдов мозгов, которые моментально повысят твою рыночную
> SB> стоимость.
>
> Как известно, нет ничего практичнее хорошей теории.
>
> Поэтому вкладывать услилия надо в первую очередь в изучение
> фундаментальной теории IT.
А я разве говорил о другом?
>
> Изучив объектно-ориентированный подход на примере SmallTalk или CLOS
> ты сумеешь применить полученные знания на C++, Perl или Java.
>
> Изучив структурное программирование по работам Вирта и Хоара, это можно
> применить не только к Паскалю, но и к С, Python или чему угодно.
>
> А вот изучать какие-либо концепции на примере инструментов,
> разработанных практиками и для практиков (а тем более иструментов
> модных) - опасно. Во-первых, в такого рода языках всегда есть
А кто говорит про концепции? Я говорю про прикладные задачи. Концепции
отдельно, прикладные отдельно. И для кадой прикладной задачи применять
тот набор концепций который наиболее подходит.
> какие-то конструкции, нарушающие стройность концепции (типа
> нетипизированных указателей в борландовском диалекте Pascal). Эти
> конструкции иногда незаменимы для решения практических задач, но
> неумеренное пользование ими мешает правильно спроектировать систему.
>
> И что еще хуже, по модным инструментам есть море ПЛОХОЙ литературы.
> Если у тебя нет хорошего лоцмана в этом море, ты вполне можешь
> поверить какому-нибудь Федорчуку или Робачевскому.
>
> Один из моих сотрудников как-то притаскивал в контору книжку по php, в
> которой чуть ли ни в первой главе было написанно: "автор не имеет понятия,
> почему функция gmtime возвращает результат в секундах с 1 января 1970 года"
Опять же вопрос. Как вы отличили мед от говна по мухам? Как известно их
много и у меда и у говна.
[skip]
>>>Подозреваю, что этим я сэкономил своей конторе куда больше денег, чем
>>>мне было за эти три дня заплачено.
>>
>
> SB> Hу, что же, возможно, так оно и есть.
> SB> Только весь вопрос в критериях. А это опять возвращает к целесообразности.
> SB> С моей точки зрения отвергать язык без знания критериев перебор. Знать
> SB> же критерии будущих проектов нереально.
>
> Hу, ровно потому, что я могу предсказать критерии будущих проектов,
> я и работаю в той должности, в которой работаю.
>
> Что касается конкретно этого языка, то я могу с уверенностью утверждать
> что для любого осмысленного набора критериев кроме требования
> хостить проект на халявном хостинге, можно найти инструмент,
> который будет удовлетворять им лучше, чем php.
Hу что же я рад за вас. Hо вот зачем советовать незнакомому человеку
никогда не писать на php не зная его задач?
>
> Причем далеко ходить не придется. В 80% процентов случаев выбор
> будет между perl, java и python. В некоторых более экзотических в рассмотрение
> будет стоить включить Tcl, Ocaml и scheme.
А если перл уерезан донельзя системным администратором а java не
проходит из-за торомзнутости python'а же совсем нет?
> SB> С моей точки зрения php отвечает набору критериев: безопасность,
> SB> скорость разработки, переносимтость и поддерживаемость (это когда
> SB> студент первого курса может). Естественно, критерии расматриваются в
>
> Студент первого курса все равно не может. Потому что для поддержки
> серьзеного web-проекта нужны ненулевые знания по информационной
> безопасности. Есть такой хороший принцип "мы не настолько богаты,
> чтобы покупать дешевые вещи". Дешевых сотрудников это тоже касается.
Согласен, но если студенту превокурснику нужно только исправлять ошибки
и неточности и добавлять новые страницы без переделывания структуры, то
это вполне реально, в случае же возникновения проблемных вопросов можно
заново обратиться к разработчикам.
> В случае, когда следут рассматривать поддерживаемость, следует скорее
> рассматривать наличие фирмы-поставщика решений на данной платформе.
>
> Что касается переносимости, то в свое время php была намертво
> исключена мной из рассмотрения как раз по этому критерию -
> необходимость модификации кода при смене нижележащей SQL-ной базы
> данных. Перловый DBI ее тут сделал.
Советую посмотреть на это дело сейчас. И не по книгам "мух" а по
документации.
Sergey Bogdanov.
--- ifmail v.2.15dev5
* Origin: Demos online service (2:5020/400)
Вернуться к списку тем, сортированных по: возрастание даты уменьшение даты тема автор
|
