Вход:  Пароль:  
FreeSource: НачатыеПроекты/ЗаготовкиСтатей/Программирование?/НаЧёмПрограммировать ...
Free Source | Каталог | Изменения | НовыеКомментарии | Пользователи | Регистрация |
Это старая версия НачатыеПроекты/ЗаготовкиСтатей/Программирование/НаЧёмПрограммировать за 2004-10-25 21:08:25..

Это одно из моих сообщений в рассылках ALTLinux

На чём программировать (заготовка статьи)


AM> Т.е. ваше мнение что на Си нужно (и достаточно безопасно) писать
AM> только системное ПО (модули, ядра, драйвера)? А приложения (и уж 
AM> тем более взаимодействующие с интернет) на чем-то ином?


Именно так.


AM> А на чем тогда


Хоть на Visual Basic. Я абсолютно серьёзно.


Если совсем серьёзно, то при программировании по Windows лучше всего
использовать любой. NET язык, а при портабельном программировании либо
Java (из распространённых), либо, что гораздо лучше, Tcl.


AM> (вроде тотже апач, mysql, squid на Си и писаны)?


Ну и светятся в багтраке с завидной периодичностью. И будут светиться
_всегда_. Просто потому, что при программировании на C нужно иметь очень
высокую квалификацию, и требуемая квалификация растёт экспоненциально с
ростом программы. Притом затраты на организацию совместной разработки тоже
растут нелинейно.


Кстати апач, mysql и squid не совсем прикладные программы всё-таки, и при
их написании вставки кода на си отнюдь не помешают (особенно это касается
апача и сквида).


SQL-сервер можно и нужно писать на языках вроде OCaml, ибо бОльшая часть
нагрузки на процессор это:
– парсер
– оптимизатор
– вычисление функций


Всё это прекрасно оптимизируется. Я не удивлюсь если движок типа SQLite,
написаный на OCaml, окажется:
а) быстрее;
б) надёжнее;
в) менее требовательным к памяти;
г) легче расширяемым;


Но это всё _сейчас_ имеет смысл только в mission critical приложениях.
Просто потому, что хороших программистов на языках отличных от C++ и жабы
за разумные деньги найти сложно, и они _потребуют_ великолепной зарплаты,
соц программ, хорошего менеджмента. Далеко не всегда руководство просто
достаточно квалифицировано, чтобы создать такие тепличные условия (дело не
в деньгах даже, программисты за 2–3k$ реально дешевле программистов за
500–1000$).


Поэтому:


1. делается декомпозиция программы на _модули_ (ООП в жопу)
2. для каждого модуля продумывается на каком языке его стоит писать
3. каждый модуль либо пишется своими силами, либо заказывается у кого-то
сильно более крутого (если модуль критичен по производительности)


интерфейс — пишется на Tcl (превосходная переносимость, элементарно
сам встраивается в программы на других языках, а также в него легко
встраиваются модули).


логика — зависит от её объёмов, в порядке убывания: OCaml, Tcl, Java, C++


вещи, требующие максимальной производительности — OCaml, C++, Java


Ну и далее смотреть и смотреть по ситуации.


Главный принцип программиста — лень.
Второй главный принцип — «разделяй и властвуй»


Если код можно не писать, а лицензировать — он лицензируется. Если код
можно не писать, а взять готовую библиотеку и написать вокруг обёртку --
так и делается. Если код не является тем, ради которого покупается
написаный продукт — код продвигается в виде правок к используемым
библиотекам (пусть другие люди, которые лучше знают эту сферу, занимаются
его поддержкой).


В случае свободных программ не зазорно использовать в качестве
_расширений_ проприетарные библиотеки (IMHO). Например написать патч к
mplayer, который бы использовал Intel'овские примитивы для DSP _если они
есть у пользователя_ было бы полезно (это как пример).


Ну и следует понимать, что написаное выше есть всего лишь результат
_моего_ весьма небольшого опыта в IT — я знаю меньше десятка языков
программирования и практически не владею функциональным программированием,
а значит уже большую часть возможностей попросту не вижу. Посему каждый
раз надо внимательно обследовать сферу, для которой пишется программа, и
искать наилучший инструмент. После чего садиться, и изучать этот
инструмент.


Скажем пример — пишется приложение. Приложение должно быть _очень_
масштабируемых (грубо говоря от сотового телефона до мейнфрейма). Какой
язык будет выбран? Java. Просто потому что это «политика партии» и в этом
случае можно получить больше поддержки, больше кода будет написано
сторонними разработчиками.


Или смотреть что нужно пользователю. Скажем _сейчас_ производительность
находится чуть ли не на последнем месте по важности, а _безопасность_ на
первом. Поэтому выбирая интерпретируемые языки программирования, или
языки вроде OCaml (где написание кривого кода несколько усложняется) можно
получить преимущество на рынке за счёт большей надёжности и более быстрого
добавления новой функциональности.


В любом случае, надо действовать осознанно — где приоритет «плыть туда
же, куда main stream», где «плаву не туда, куда плывёт течение, а туда,
куда я хочу», где ориентироваться на дешивизну разработчиков, а где на
качество результата.


Если же вопрос в плане «чему учиться?» то я рекомендую:


1. Tcl (обязательно)
2. OCaml (мозги несколько сдвигает, всё не могу найти время чтобы
полностью с ним разобраться, но уже даже теоретическое знание изменило
стиль написания кода на других языках)
3. Java (придётся)
4. Perl (знать надо, но лучше стараться на нём не писать, изучать лучше
после вышеперечисленность, мозги портит почти как бейсик, по себе сужу)


Стоит обратить внимание на Lisp — так говорят умные люди, которым я
доверяю. Времени пока не нахожу.

Недостатки C


Самый главный недостаток C — ASCIIZ-строки.


  1. они медленные (операция strlen для ASCIIZ строки означает сканирование всей строки, и сравнение каждого байта с 0, в отличии от строк в Pascal, где хранится длина строки, strcmp требует сравнение не только символов друг-с-другом, но и с 0, и.т.д)
  2. они небезопасные: функции вроде sprintf, вместо snprintf, и также многие другие функции являются потенциально опасными, если не делать специальных проверок на длину строки, об этих проверках и о передаче длины строки должен заботиться программист. Подавляющее количество ошибок безопасности, опубликованых в bugtraq, так или иначе связаны именно с этой проблемой.


Обсудить статью можно здесь


(C) Denis Smirnov 15 Aug 2004
так как статья находится в разработке, её копирование на другие сайты запрещается


 
Файлов нет. [Показать файлы/форму]
Много комментариев (6). [Показать комментарии/форму]