О программировании, C*, linux, и не только об этом...
Добавлено: 31 июл 2003, 19:42
Прошу прощения, что несколько сумбуроно - много всяких мыслей на эту тему в голове накопилось...
0) В последнее время (раньше просто не сталкивалс) я часто встречаюсь с высказываними некоторых товарищей являющихся жертвами или создателяси определенной мифологии. Я попытаюсь эти мифы несколько систематизировать и рассеять.
1) Для того, чтобы знать linux нужно знать C
Для понимания принципов работу операцинной системы (пофиг какой) в том виде, в котором это нужно подавляющему большинству пользователей и не-C програмистов, знать C не надо Достаточно читать документаци по это конкретной системе и весма желательно что-то общее на это тему - книг хватает - например Олифер "Операционные системы" или Танненбаум с таким же кажется названием. Применительно к linux, рекомендуется любая толковая книга по Unix. Книги, которая бы описывала общие принципы функционирования (процессы, потоки, коцепция файловой системы, и т.п. ) *nix (в том числе и самого linux) на примере linux я не видел. Я видел только всячиские руководства сисадмина, зачастую заточеные под дистрибутив. Для желающих разобраться на общеобразовательно уровне (не для написания модулей сдра) существует гугл, где можно найти русскоязычные описания некотрых частей ядра - например VFS, sheduler, virtual memory. Также рекомендуется читать серую мягкую книгу Linux TCP/IP (название точно не помню) - она поможет осазнать принцимы работы linux в сетях TCP/IP. Ессно, вещи типа BGP/OSPF и т.п. там не описаны - для ознакомления с ними рекомендуется Олифер "Компьютерные сети" - вполне хороший учебник
2) C* - универсальный язык программировани, программы написаные на нем работают быстрее всего (не считая ассемблер), он широко распространен, другие языки похожи на него и вообще его знать надо полюбому, если хочешь программировать
Да C* универсален - но ассемблер универсальнее и быстрее. В современных условиях железо дешевеет значительно быстрее мозгов (даже с учетом индусов). Ключевыми моментами в значительной части становятся скорость создания продукта, простота его поддержки (возможно сторонними разработчиками), стоимось его использования (лицензии на ОС, БД, компоненты сторнних разработчиков - например, можно написать продукт, который будет маленьким и простым, но бля своей работы ему потребуется MS Office) Вообще, на сегодняшний день главным показателем становится не те деньги, которые будут заплачены разработчику разово, а TCO. Тем не менне, для ряда задач C* оказывается не оптимальным - например слабать средней размерности e-shop на java, perl, python или php будет быстрее, чем на C*. С развитием сетей и распространением архитектуры клиент-сервер, особенно web-based решение ниша C* будет сокращаться - а простых и "некрасивых " языков типа python, ruby, perl или того же Visual Basic будет расти. Поэтому стоит подумать о том, как бы не оказаться зажатым в специфичной нише.
3) Надо стремиться изучить язык в совершенстве, а то работы не найдешь.
Эффективный код - вещь хорошая, но...
Стоит помнить, что каждый человек может совершать ошибки, а исправлять их будете не всегда вы. Можно написать "крутой" код, о котором профи скажут "О!", но поддерживать проще код написаный без лишних наворотов и с хорошими коментариями. Вменяемый коментарий важнее короткого "крутого" кода.
Изучить синтаксис и приемы работы с высокоуровневыми языками можно достаточно быстро, важнее иметь представление о технологиях, иначе мы часто получаем на выходе БГУИР или БГУ людей, которые могут писать на C*/Delphi вроде бы как и все, но в тоже врем и ничего - сведения о проектировании программ часто проходят сквозь уши навылет, кодингу уделяется больше внимания. А уж чем отличается XP от RUP, где какие приимущества, элементырные представления о том, как стоит и как не стоит общаться с заказчиком - этому практически не уделяют внимания! Конечно, простому программеру в большой команде не дадут напрямую общаться с заказчиком, но повлиять на выбор приемов совместной работы он вполне в состоянии, если захочет.
0) В последнее время (раньше просто не сталкивалс) я часто встречаюсь с высказываними некоторых товарищей являющихся жертвами или создателяси определенной мифологии. Я попытаюсь эти мифы несколько систематизировать и рассеять.
1) Для того, чтобы знать linux нужно знать C
Для понимания принципов работу операцинной системы (пофиг какой) в том виде, в котором это нужно подавляющему большинству пользователей и не-C програмистов, знать C не надо Достаточно читать документаци по это конкретной системе и весма желательно что-то общее на это тему - книг хватает - например Олифер "Операционные системы" или Танненбаум с таким же кажется названием. Применительно к linux, рекомендуется любая толковая книга по Unix. Книги, которая бы описывала общие принципы функционирования (процессы, потоки, коцепция файловой системы, и т.п. ) *nix (в том числе и самого linux) на примере linux я не видел. Я видел только всячиские руководства сисадмина, зачастую заточеные под дистрибутив. Для желающих разобраться на общеобразовательно уровне (не для написания модулей сдра) существует гугл, где можно найти русскоязычные описания некотрых частей ядра - например VFS, sheduler, virtual memory. Также рекомендуется читать серую мягкую книгу Linux TCP/IP (название точно не помню) - она поможет осазнать принцимы работы linux в сетях TCP/IP. Ессно, вещи типа BGP/OSPF и т.п. там не описаны - для ознакомления с ними рекомендуется Олифер "Компьютерные сети" - вполне хороший учебник
2) C* - универсальный язык программировани, программы написаные на нем работают быстрее всего (не считая ассемблер), он широко распространен, другие языки похожи на него и вообще его знать надо полюбому, если хочешь программировать
Да C* универсален - но ассемблер универсальнее и быстрее. В современных условиях железо дешевеет значительно быстрее мозгов (даже с учетом индусов). Ключевыми моментами в значительной части становятся скорость создания продукта, простота его поддержки (возможно сторонними разработчиками), стоимось его использования (лицензии на ОС, БД, компоненты сторнних разработчиков - например, можно написать продукт, который будет маленьким и простым, но бля своей работы ему потребуется MS Office) Вообще, на сегодняшний день главным показателем становится не те деньги, которые будут заплачены разработчику разово, а TCO. Тем не менне, для ряда задач C* оказывается не оптимальным - например слабать средней размерности e-shop на java, perl, python или php будет быстрее, чем на C*. С развитием сетей и распространением архитектуры клиент-сервер, особенно web-based решение ниша C* будет сокращаться - а простых и "некрасивых " языков типа python, ruby, perl или того же Visual Basic будет расти. Поэтому стоит подумать о том, как бы не оказаться зажатым в специфичной нише.
3) Надо стремиться изучить язык в совершенстве, а то работы не найдешь.
Эффективный код - вещь хорошая, но...
Стоит помнить, что каждый человек может совершать ошибки, а исправлять их будете не всегда вы. Можно написать "крутой" код, о котором профи скажут "О!", но поддерживать проще код написаный без лишних наворотов и с хорошими коментариями. Вменяемый коментарий важнее короткого "крутого" кода.
Изучить синтаксис и приемы работы с высокоуровневыми языками можно достаточно быстро, важнее иметь представление о технологиях, иначе мы часто получаем на выходе БГУИР или БГУ людей, которые могут писать на C*/Delphi вроде бы как и все, но в тоже врем и ничего - сведения о проектировании программ часто проходят сквозь уши навылет, кодингу уделяется больше внимания. А уж чем отличается XP от RUP, где какие приимущества, элементырные представления о том, как стоит и как не стоит общаться с заказчиком - этому практически не уделяют внимания! Конечно, простому программеру в большой команде не дадут напрямую общаться с заказчиком, но повлиять на выбор приемов совместной работы он вполне в состоянии, если захочет.