Сам все время писал на венде, но временами по работе приходится сталкиваться с прогерами пишущими под линукс, а также с прогерами, которые до этого писали под никсы и лишь недавно перешли на винду. Сложилось впечатление, что кол-го говнокода у линуксойдов вразы больше чем у виндовых прогеров. Причем в большенстве своем линуксойды вообще не способны писать на плюсах. Пишущи на плюсах, выдают жудкий спагети код в сишном стиле с прикрученными не к месту классами, с методами на сотни строк и отсутсвием сколь-либо вминяемой структурированности кода и архитектуры. Можно сказать что просто совпадение, но я наблюдал такую ситуация во всех компаниях где встречал линуксойдов — среднее качество кода, выдаваемое линуксойдом, заметно хуже чем у прогера, писавщего большую часть жизни под винду.
Как у других с этим, есть ли похожие наблюдления? Действительно ли написание кода под линукс приводит к развитию плохого стиля кодирования?

Здравствуйте, midl, Вы писали:

M>Сам все время писал на венде, но временами по работе приходится сталкиваться с прогерами пишущими под линукс, а также с прогерами, которые до этого писали под никсы и лишь недавно перешли на винду. Сложилось впечатление, что кол-го говнокода у линуксойдов вразы больше чем у виндовых прогеров. Причем в большенстве своем линуксойды вообще не способны писать на плюсах. Пишущи на плюсах, выдают жудкий спагети код в сишном стиле с прикрученными не к месту классами, с методами на сотни строк и отсутсвием сколь-либо вминяемой структурированности кода и архитектуры. Можно сказать что просто совпадение, но я наблюдал такую ситуация во всех компаниях где встречал линуксойдов — среднее качество кода, выдаваемое линуксойдом, заметно хуже чем у прогера, писавщего большую часть жизни под винду.
M>Как у других с этим, есть ли похожие наблюдления? Действительно ли написание кода под линукс приводит к развитию плохого стиля кодирования?

Все относительно.
Наблюдение про размер классов и методов не подтверждаю.
Пришедший с Винды программист норовит написать одну очень большую программу, вместо того, чтобы написать несколько взаимодействующих мелких.

Здравствуйте, midl, Вы писали:

Видел двоих людей, которые, имея опыт программирования на С под линукс, писали программы под винду и iOS. Везде получалось так — ядро, написанное как им нравится, плюс небольшой интерфейсный слой, изолюрующий ядро от ОС.
Единственный известный мне виндовый программер, пытавшийся написать программу для линукса, долго изучал GTK, но с требованием сделать две версии — с интерфейсом командной строки и GUI — он не справился.

Здравствуйте, midl, Вы писали:

M>Пишущи на плюсах, выдают жудкий спагети код в сишном стиле с прикрученными не к месту классами, с методами на сотни строк и отсутсвием сколь-либо вминяемой структурированности кода и архитектуры. Можно сказать что просто совпадение, но я наблюдал такую ситуация во всех компаниях где встречал линуксойдов — среднее качество кода, выдаваемое линуксойдом, заметно хуже чем у прогера, писавщего большую часть жизни под винду.

В силу того, что для чистки кода нужны инструменты, получается следующиее
1. нормальных инструментов для с++ нет
2. нормальный инструментов для лялиха нет

В итоге наблюдается закономерный хаос особенно в случае с лялиховыми проектами. Есть деятели который утверждают "мы сразу пишем вменяемо". Обычно такое проходит в небольших проектах когда работать приходится только со своим кодом, т.е. фактически одна команда работает этим кодом. Когда к фиксам подключается большое кол.во людей, хаос наступает быстрее, чем вменяемо-пишущие успевают заметить.

Здравствуйте, alpha21264, Вы писали:

A>Все относительно.
A>Наблюдение про размер классов и методов не подтверждаю.
A>Пришедший с Винды программист норовит написать одну очень большую программу, вместо того, чтобы написать несколько взаимодействующих мелких.
A>

Луноход который приходит на винду начинает писать целую пачку взаимодействующих программ вместо одно и в конечном итоге сам же запутывается в этом взаимодействии.

Здравствуйте, Ikemefula, Вы писали:

I>Здравствуйте, alpha21264, Вы писали:

A>>Все относительно.
A>>Наблюдение про размер классов и методов не подтверждаю.
A>>Пришедший с Винды программист норовит написать одну очень большую программу, вместо того, чтобы написать несколько взаимодействующих мелких.
A>>

I>Луноход который приходит на винду начинает писать целую пачку взаимодействующих программ вместо одно и в конечном итоге сам же запутывается в этом взаимодействии.

Ну типа да. Только не запутывается.
Но поскольку запуск процесса в Винде дОрог, то случается всякие эффекты.
Например кто-то тут жаловался, что make в Винде как-то долго работает.
Ну а че ты хотел? Система-то не родная

Здравствуйте, Ikemefula, Вы писали:

I>В силу того, что для чистки кода нужны инструменты, получается следующиее
I>1. нормальных инструментов для с++ нет
I>2. нормальный инструментов для лялиха нет

Ну не надо размахивать своими комплексами.
Понимание того, что такое "нормально", у каждого своё.

Здравствуйте, alpha21264, Вы писали:

A>Здравствуйте, Ikemefula, Вы писали:

I>>Здравствуйте, alpha21264, Вы писали:

A>>>Все относительно.
A>>>Наблюдение про размер классов и методов не подтверждаю.
A>>>Пришедший с Винды программист норовит написать одну очень большую программу, вместо того, чтобы написать несколько взаимодействующих мелких.
A>>>

I>>Луноход который приходит на винду начинает писать целую пачку взаимодействующих программ вместо одно и в конечном итоге сам же запутывается в этом взаимодействии.

A>Ну типа да. Только не запутывается.

Запутывается.

A>Но поскольку запуск процесса в Винде дОрог, то случается всякие эффекты.

Ну да, начинаются сказки: "Это не я виноват, это винда такая"

A>Например кто-то тут жаловался, что make в Винде как-то долго работает.

Правильно. При переходе на другую систему нужно использовать родной инструент, а не тащить за сообой привычный хлам.

A>Ну а че ты хотел? Система-то не родная

Отмазка как дырка в заднице есть у всех.

Здравствуйте, alpha21264, Вы писали:

I>>В силу того, что для чистки кода нужны инструменты, получается следующиее
I>>1. нормальных инструментов для с++ нет
I>>2. нормальный инструментов для лялиха нет

A>Ну не надо размахивать своими комплексами.
A>Понимание того, что такое "нормально", у каждого своё.

Это мягко говоря заблуждение. Инструмент или соответствует уровню решаемых задач или нет. Поскольку код низкоуровневый, то инструменты намного более важны, чем для менджед, а реально получается наоборот — инструменты почти ничего не умеют

Здравствуйте, midl, Вы писали:

M>Как у других с этим, есть ли похожие наблюдления? Действительно ли написание кода под линукс приводит к развитию плохого стиля кодирования?

* Там, где виндузятнику нужно 10000 строк и иерархия классов, линуксоид напишет 1000 строк простого кода
* Все виндовсные драйвера сделаны напильником из DDK-ных экзамплов
* Все виндовсные программы сделаны из примеров, скачанных из интернета
* Виндовсные программеры способны писать только на Visual Basic'е. Чтобы им было менее обидно, Микрософт изобрел C# — Бейсик с синтаксисом, напоминающим C++
* Виндовсные программеры путают право и лево, а особо выдающиеся — верх и низ. Поэтому виндовсная гуйня программируется в абсолютных размерах и координатах, в то время как гуйня на любой другой системе — в терминах взаимного расположения элементов, а размеры и координаты рассчитываются автоматически
* В локализованных Windows нет англоязычной расшифровки кодов ошибок, потому что никто из виндузятников не читает на иностранных языках, и даже алфавита не знают
* 80% того, что есть в Windows, украдено из UNIX, где оно появилось 20 лет назад
* Остальные 20% того, что есть в Windows, украдено из предшественника UNIX'а MULTICS, написанного 40 лет назад, и кое-чего по-мелочи украдено из прочих, столь же древних, разработок
* Виндовсные программеры гордятся знанием технологий, которые всем прочим известны как минимум 20 лет, пусть и под другими именами
* Любая виндовсная технология выходит из моды через 5 лет после ее появления — как раз столько времени надо самым продвинутым виндовсным программерам, чтобы запомнить самые красивые ключевые слова (остальные в 5 лет не укладываются)
* В разработке пользовательского интерфейса Windows участвовали специалисты по работе с пациентами, страдающими синдомом Дауна.
* Как показали исследования британских ученых, если операционная система грузится слишком быстро, не все пользователи осознают, что она загрузилась, и начинают перезагружать ее снова и снова. В Windows эта проблема решена на уровне операционной системы
* ...
* ..
* .

Здравствуйте, Ikemefula, Вы писали:

I>Это мягко говоря заблуждение. Инструмент или соответствует уровню решаемых задач или нет. Поскольку код низкоуровневый, то инструменты намного более важны, чем для менджед, а реально получается наоборот — инструменты почти ничего не умеют

Глупость от повторения умнее не становится. Ваш КО. Аргументы будут? Ну хоть какие-то?

Здравствуйте, midl, Вы писали:

M>Сам все время писал на венде, но временами по работе приходится сталкиваться с прогерами пишущими под линукс, а также с прогерами, которые до этого писали под никсы и лишь недавно перешли на винду. Сложилось впечатление, что кол-го говнокода у линуксойдов вразы больше чем у виндовых прогеров. Причем в большенстве своем линуксойды вообще не способны писать на плюсах. Пишущи на плюсах, выдают жудкий спагети код в сишном стиле с прикрученными не к месту классами, с методами на сотни строк и отсутсвием сколь-либо вминяемой структурированности кода и архитектуры. Можно сказать что просто совпадение, но я наблюдал такую ситуация во всех компаниях где встречал линуксойдов — среднее качество кода, выдаваемое линуксойдом, заметно хуже чем у прогера, писавщего большую часть жизни под винду.

Лично у меня прямо противоположное наблюдение

M>Как у других с этим, есть ли похожие наблюдления? Действительно ли написание кода под линукс приводит к развитию плохого стиля кодирования?

Ну соответственно последний вопрос уже не имеют смысла.

Здравствуйте, Ikemefula, Вы писали:

I>1. нормальных инструментов для с++ нет
I>2. нормальный инструментов для лялиха нет

А есть ли под виндой аналог Valgrind'a?

Здравствуйте, Mazay, Вы писали:

M>А есть ли под виндой аналог Valgrind'a?

Опередил

Здравствуйте, alpha21264, Вы писали:

I>>1. нормальных инструментов для с++ нет

A>Ну не надо размахивать своими комплексами.
A>Понимание того, что такое "нормально", у каждого своё.

Начать можно с того, что под линухом вполне нормально писать программы не на C++.

Здравствуйте, Pzz, Вы писали:

Pzz>* 80% того, что есть в Windows, украдено из UNIX, где оно появилось 20 лет назад
Pzz>* Остальные 20% того, что есть в Windows, украдено из предшественника UNIX'а MULTICS, написанного 40 лет назад, и кое-чего по-мелочи украдено из прочих, столь же древних, разработок

Итого 146%?

Здравствуйте, Mazay, Вы писали:

M>А есть ли под виндой аналог Valgrind'a?

Есть VCC: A Verifier for Concurrent C. Вроде как вовсю используется самим Мелкософтом для разработки драйверов в Windows7. И вроде как именно благодаря VCC Семёрка весьма и весьма надёжна.

Здравствуйте, koodeer, Вы писали:

Pzz>>* 80% того, что есть в Windows, украдено из UNIX, где оно появилось 20 лет назад
Pzz>>* Остальные 20% того, что есть в Windows, украдено из предшественника UNIX'а MULTICS, написанного 40 лет назад, и кое-чего по-мелочи украдено из прочих, столь же древних, разработок

K>Итого 146%?

Точно!

Здравствуйте, koodeer, Вы писали:

M>>А есть ли под виндой аналог Valgrind'a?
K>Есть VCC: A Verifier for Concurrent C. Вроде как вовсю используется самим Мелкософтом для разработки драйверов в Windows7. И вроде как именно благодаря VCC Семёрка весьма и весьма надёжна.
Это статический верификатор, а Valgrind — динамический.

Аналогом Valgrind'а является Purify, но она дорогая и менее мощная.

Здравствуйте, Ikemefula, Вы писали:

I>В силу того, что для чистки кода нужны инструменты, получается следующиее
I>1. нормальных инструментов для с++ нет
Qtcreator, vim, emacs.

I>2. нормальный инструментов для лялиха нет
Есть, причём о некоторых из них Винде даже мечтать нельзя: perf, oprofile (профилирование ВСЕЙ системы), valgrind. Синэргетика, однако.

Здравствуйте, midl, Вы писали:

M>Как у других с этим, есть ли похожие наблюдления? Действительно ли написание кода под линукс приводит к развитию плохого стиля кодирования?
Нет, это скорее просто травма от использования MFC и Windows.

В Линуксе, к примеру, ядро — великолепно написаный код. Халтуру туда просто не пропускают, Линус за халтурный код зарежет, обезглавит и закопает. Особенно это заметно на драйверах — все виденные мной драйверы в Винде представляют собой полное УГ.

Что прикольно, драйверы Hyper-V от Microsoft для Линукса перепиливали до кондиции более полутора лет. Настолько уродливы они были.

Здравствуйте, Cyberax, Вы писали:

C>Здравствуйте, midl, Вы писали:

M>>Как у других с этим, есть ли похожие наблюдления? Действительно ли написание кода под линукс приводит к развитию плохого стиля кодирования?
C>Нет, это скорее просто травма от использования MFC и Windows.

C>В Линуксе, к примеру, ядро — великолепно написаный код. Халтуру туда просто не пропускают, Линус за халтурный код зарежет, обезглавит и закопает. Особенно это заметно на драйверах — все виденные мной драйверы в Винде представляют собой полное УГ.

Я имею ввиду не разработчиков ядра самого линукса, а тех кто пишет ПО под линукс. Да и большое кол-го проблем в коде я вижу именно при написании на плюсах, а не на сях. Т.е. сложилось впечатление, что писать на плюсах большенство пришедших из линукса разработчиков вообще не умеют.

Здравствуйте, midl, Вы писали:

C>>В Линуксе, к примеру, ядро — великолепно написаный код. Халтуру туда просто не пропускают, Линус за халтурный код зарежет, обезглавит и закопает. Особенно это заметно на драйверах — все виденные мной драйверы в Винде представляют собой полное УГ.
M>Я имею ввиду не разработчиков ядра самого линукса, а тех кто пишет ПО под линукс. Да и большое кол-го проблем в коде я вижу именно при написании на плюсах, а не на сях. Т.е. сложилось впечатление, что писать на плюсах большенство пришедших из линукса разработчиков вообще не умеют.
Чистый С очень популярен. Но и С++ вполне нормален, к примеру в KDE/QT.

Самый отстойный С++ я видел у программистов на MFC (с CString'ами и прочей гадостью)

Здравствуйте, Ikemefula, Вы писали:

I>В силу того, что для чистки кода нужны инструменты, получается следующиее
I>1. нормальных инструментов для с++ нет
I>2. нормальный инструментов для лялиха нет

В твоей реальности? Более чем возможно.

Здравствуйте, Mazay, Вы писали:

I>>1. нормальных инструментов для с++ нет
I>>2. нормальный инструментов для лялиха нет

M>А есть ли под виндой аналог Valgrind'a?

Есть.

Здравствуйте, Cyberax, Вы писали:

I>>В силу того, что для чистки кода нужны инструменты, получается следующиее
I>>1. нормальных инструментов для с++ нет
C>Qtcreator, vim, emacs.

И что там для чистки кода, текстовый редактор ? Или вим с емаксом научились самостоятельно делать рефакторинг ?

I>>2. нормальный инструментов для лялиха нет
C>Есть, причём о некоторых из них Винде даже мечтать нельзя: perf, oprofile (профилирование ВСЕЙ системы), valgrind. Синэргетика, однако.

Вообще то речь была про чистку кода.

Здравствуйте, ambel-vlad, Вы писали:

I>>В силу того, что для чистки кода нужны инструменты, получается следующиее
I>>1. нормальных инструментов для с++ нет
I>>2. нормальный инструментов для лялиха нет

AV>В твоей реальности? Более чем возможно.

Ну ка, покажи свой классный опенсорсный код

Здравствуйте, Ikemefula, Вы писали:

I>>>В силу того, что для чистки кода нужны инструменты, получается следующиее
I>>>1. нормальных инструментов для с++ нет
C>>Qtcreator, vim, emacs.
I>И что там для чистки кода, текстовый редактор ?
В QTCreator'е — редактор + рефакторинги.

I>Или вим с емаксом научились самостоятельно делать рефакторинг ?
QTCreator умеет, Emacs с CEdet тоже.

I>>>2. нормальный инструментов для лялиха нет
C>>Есть, причём о некоторых из них Винде даже мечтать нельзя: perf, oprofile (профилирование ВСЕЙ системы), valgrind. Синэргетика, однако.
I>Вообще то речь была про чистку кода.
Они в этом тоже помогают.

Надо руки отрыват тем кто везде лепит vim (мало места занимает? да у меня терабайт его свободно на диске!).

Здравствуйте, vpchelko, Вы писали:

V>Надо руки отрыват тем кто везде лепит vim (мало места занимает? да у меня терабайт его свободно на диске!).
Место — пофиг. Но он удобен для мелких правок и динамических языков (где один фиг автокомплит нормальный невозможен), я в нём пишу проекты на Питоне.

Для С++ мне удобнее QTCreator.

Здравствуйте, alpha21264, Вы писали:

I>>Это мягко говоря заблуждение. Инструмент или соответствует уровню решаемых задач или нет. Поскольку код низкоуровневый, то инструменты намного более важны, чем для менджед, а реально получается наоборот — инструменты почти ничего не умеют

A>Глупость от повторения умнее не становится. Ваш КО. Аргументы будут? Ну хоть какие-то?

Необходимо изменение дизайна программы при изменении требований и интеграция с компонентами другого приложения. Нужен инструмент, который сделает это изменение максимально безопасным.

Решение — рефакторинг + интеграция. Net/Java умеют это на раз. В С++ вылазит сразу всё
— долгая компиляция == нельзя пускать тесты настолько часто, насколько это требует задача
— хреновый синтаксис == инспекторы слабые, автоматические рефакторинги слабые
— слабые языковые возможности (нет фп, рефлексии и тд) == простейшие вещи вынуждают на ровном месте городить ахинею в виде хаков
— вагоны "стандартных" либ мешают сконцентрироваться на задаче

Вот небольшая заметка на похожую тему: http://blog.objectmentor.com/articles/2007/07/03/observations-on-tdd-in-c-long
Что характерно, была написана 5 лет тем самым Дядей Бобом, чья бригада написала чуть не все книги по ООП

Здравствуйте, Cyberax, Вы писали:

I>>И что там для чистки кода, текстовый редактор ?
C>В QTCreator'е — редактор + рефакторинги.

Что он умеет из того, что умеет решарпер или Idea ?

I>>Или вим с емаксом научились самостоятельно делать рефакторинг ?
C>QTCreator умеет, Emacs с CEdet тоже.

Самостоятельно ? ну и дела см выше

C>>>Есть, причём о некоторых из них Винде даже мечтать нельзя: perf, oprofile (профилирование ВСЕЙ системы), valgrind. Синэргетика, однако.
I>>Вообще то речь была про чистку кода.
C>Они в этом тоже помогают.

Да, наковальня тоже помогает зуб выдрать.

Здравствуйте, Ikemefula, Вы писали:

I>>>И что там для чистки кода, текстовый редактор ?
C>>В QTCreator'е — редактор + рефакторинги.
I>Что он умеет из того, что умеет решарпер или Idea ?
Конечно, нет.

I>>>Или вим с емаксом научились самостоятельно делать рефакторинг ?
C>>QTCreator умеет, Emacs с CEdet тоже.
I>Самостоятельно ? ну и дела см выше
Да, самостоятельно. Рефакторинги типа переименований и перемещений (самое стандартное) делают без проблем.

Здравствуйте, Cyberax, Вы писали:

C>>>В QTCreator'е — редактор + рефакторинги.
I>>Что он умеет из того, что умеет решарпер или Idea ?
C>Конечно, нет.

Значит не умеет.

I>>>>Или вим с емаксом научились самостоятельно делать рефакторинг ?
C>>>QTCreator умеет, Emacs с CEdet тоже.
I>>Самостоятельно ? ну и дела см выше
C>Да, самостоятельно. Рефакторинги типа переименований и перемещений (самое стандартное) делают без проблем.

Этого недостаточно.

Здравствуйте, Ikemefula, Вы писали:

I>>>>>Или вим с емаксом научились самостоятельно делать рефакторинг ?
C>>>>QTCreator умеет, Emacs с CEdet тоже.
I>>>Самостоятельно ? ну и дела см выше
C>>Да, самостоятельно. Рефакторинги типа переименований и перемещений (самое стандартное) делают без проблем.
I>Этого недостаточно.
Ну и что дальше-то? В Linux'е можно писать и на Java (собственно, вот прямо сейчас это делаю). Можно писать на С++.

В обоих разные стили, разные ограничения и возможности. Как это влияет на качество программистов?

Здравствуйте, Mazay, Вы писали:

M>А есть ли под виндой аналог Valgrind'a?
BoundsChecker, Intel Thread Checker, VTune
Тут скорее вопрос есть ли под линухом аналоги этих тулов, по обеспечиваемому функционалу разумеется.

Здравствуйте, Cyberax, Вы писали:

I>>2. нормальный инструментов для лялиха нет
C>Есть, причём о некоторых из них Винде даже мечтать нельзя: perf, oprofile (профилирование ВСЕЙ системы), valgrind. Синэргетика, однако.

До VTune и Intel Inspector им срать и срать

Здравствуйте, Cyberax, Вы писали:

C>>>Да, самостоятельно. Рефакторинги типа переименований и перемещений (самое стандартное) делают без проблем.
I>>Этого недостаточно.
C>Ну и что дальше-то? В Linux'е можно писать и на Java (собственно, вот прямо сейчас это делаю). Можно писать на С++.

Можно писать даже на С#

C>В обоих разные стили, разные ограничения и возможности. Как это влияет на качество программистов?

Вероятно джава-код будет покачественней кода на с++ на том же линуксе. Правильно ? Джава-программист будет прокачиваться в самых разных скилах, а лялих-с++ станет мастером нахождения багов с указателями потому что ни на что другое времени не хватит(особенно если уже не джуниор — придется за другими подчищать). Какой из них качественнее как программист ?

Здравствуйте, Ikemefula, Вы писали:

C>>Ну и что дальше-то? В Linux'е можно писать и на Java (собственно, вот прямо сейчас это делаю). Можно писать на С++.
I>Можно писать даже на С#
Да, есть несознательные элементы, пишущие на Mono.

C>>В обоих разные стили, разные ограничения и возможности. Как это влияет на качество программистов?
I>Вероятно джава-код будет покачественней кода на с++ на том же линуксе. Правильно ?
Неправильно.

I>Джава-программист будет прокачиваться в самых разных скилах, а лялих-с++ станет мастером нахождения багов с указателями потому что ни на что другое времени не хватит(особенно если уже не джуниор — придется за другими подчищать). Какой из них качественнее как программист ?
Зато хороший С++-ник с большим внимание будет относится к таким вещам, как инварианты и гарантии.

Здравствуйте, Cyberax, Вы писали:

C>>>В обоих разные стили, разные ограничения и возможности. Как это влияет на качество программистов?
I>>Вероятно джава-код будет покачественней кода на с++ на том же линуксе. Правильно ?
C>Неправильно.

Ого. Если не считать самый низкий уровень, код на джаве можно читать как литературу.

I>>Джава-программист будет прокачиваться в самых разных скилах, а лялих-с++ станет мастером нахождения багов с указателями потому что ни на что другое времени не хватит(особенно если уже не джуниор — придется за другими подчищать). Какой из них качественнее как программист ?
C>Зато хороший С++-ник с большим внимание будет относится к таким вещам, как инварианты и гарантии.

Это не самые главные навыки у программиста.

Здравствуйте, Ikemefula, Вы писали:

C>>>>В обоих разные стили, разные ограничения и возможности. Как это влияет на качество программистов?
I>>>Вероятно джава-код будет покачественней кода на с++ на том же линуксе. Правильно ?
C>>Неправильно.
I>Ого. Если не считать самый низкий уровень, код на джаве можно читать как литературу.
Ой да ладно. Я с Java и С++ (а так же с Python и прочей скриптовкой) работаю ежедневно. В Java только кажется, что код всегда простой и хороший.

I>>>Джава-программист будет прокачиваться в самых разных скилах, а лялих-с++ станет мастером нахождения багов с указателями потому что ни на что другое времени не хватит(особенно если уже не джуниор — придется за другими подчищать). Какой из них качественнее как программист ?
C>>Зато хороший С++-ник с большим внимание будет относится к таким вещам, как инварианты и гарантии.
I>Это не самые главные навыки у программиста.
Это одни из главных навыков для написания надёжного кода.

Здравствуйте, Cyberax, Вы писали:

C>Здравствуйте, Ikemefula, Вы писали:

C>>>>>В обоих разные стили, разные ограничения и возможности. Как это влияет на качество программистов?
I>>>>Вероятно джава-код будет покачественней кода на с++ на том же линуксе. Правильно ?
C>>>Неправильно.
I>>Ого. Если не считать самый низкий уровень, код на джаве можно читать как литературу.
C>Ой да ладно. Я с Java и С++ (а так же с Python и прочей скриптовкой) работаю ежедневно. В Java только кажется, что код всегда простой и хороший.

Конечно не всегда. Зато его гораздо легче чистить, чем сиплюсный.

C>>>Зато хороший С++-ник с большим внимание будет относится к таким вещам, как инварианты и гарантии.
I>>Это не самые главные навыки у программиста.
C>Это одни из главных навыков для написания надёжного кода.

А решение задачи кто будет придумывать ?

Здравствуйте, midl, Вы писали:

M>Как у других с этим, есть ли похожие наблюдления? Действительно ли написание кода под линукс приводит к развитию плохого стиля кодирования?

Я немного пописал под UNIX, и меня теперь не утащишь на винду, работа в Visual Studio стала мазохизмом. Так что возможно это масса людей, которая так и не постигла дао Linux мигрирует в поисках...

Здравствуйте, Ikemefula, Вы писали:

I>>>Ого. Если не считать самый низкий уровень, код на джаве можно читать как литературу.
C>>Ой да ладно. Я с Java и С++ (а так же с Python и прочей скриптовкой) работаю ежедневно. В Java только кажется, что код всегда простой и хороший.
I>Конечно не всегда. Зато его гораздо легче чистить, чем сиплюсный.
В целом да, но С++ обычно пишут сразу более тщательно.

C>>>>Зато хороший С++-ник с большим внимание будет относится к таким вещам, как инварианты и гарантии.
I>>>Это не самые главные навыки у программиста.
C>>Это одни из главных навыков для написания надёжного кода.
I>А решение задачи кто будет придумывать ?
Программист, конечно. При этом, желательно придумывать её из гарантировано работающих кусков, выдерживая инварианты.

Здравствуйте, Cyberax, Вы писали:

I>>>>Ого. Если не считать самый низкий уровень, код на джаве можно читать как литературу.
C>>>Ой да ладно. Я с Java и С++ (а так же с Python и прочей скриптовкой) работаю ежедневно. В Java только кажется, что код всегда простой и хороший.
I>>Конечно не всегда. Зато его гораздо легче чистить, чем сиплюсный.
C>В целом да, но С++ обычно пишут сразу более тщательно.

То есть, тратят лишнее время в то время когда выхлоп один и тот же.

C>>>Это одни из главных навыков для написания надёжного кода.
I>>А решение задачи кто будет придумывать ?
C>Программист, конечно. При этом, желательно придумывать её из гарантировано работающих кусков, выдерживая инварианты.

Когда же он успеет это освоить, если все время будет уходить то на указатели, то на компиляцию, то на отладку ? А в джаве взял да и накидал тестов — опаньки, все работает само.

Здравствуйте, Banned by IT, Вы писали:

I>>>2. нормальный инструментов для лялиха нет
C>>Есть, причём о некоторых из них Винде даже мечтать нельзя: perf, oprofile (профилирование ВСЕЙ системы), valgrind. Синэргетика, однако.
BBI>До VTune и Intel Inspector им срать и срать
Мимо.
1) VTune есть и для Линукса (ага, от Интела)
2) Это не то, о чём я говорю.

С oprofile я могу запустить программу и посмотреть профиль всей системы. Т.е. вообще всей, вплоть до ядра. К примеру, для моей (графической) программы я как-то с удивлением обнаружил, что bottleneck оказался в X-сервере, а не там, где я его искал в своём коде.

Сюда добавляем ещё latencytop (поиск причин латентности) и perf (профилирование и трассировка ядра).

Ничего близкого в Винде нет и не будет никогда.

Здравствуйте, Ikemefula, Вы писали:

I>Вероятно джава-код будет покачественней кода на с++ на том же линуксе. Правильно ? Джава-программист будет прокачиваться в самых разных скилах, а лялих-с++ станет мастером нахождения багов с указателями потому что ни на что другое времени не хватит(особенно если уже не джуниор — придется за другими подчищать). Какой из них качественнее как программист ?

Проблемы с указателями сильно преувеличены

C>Сюда добавляем ещё latencytop (поиск причин латентности) и perf (профилирование и трассировка ядра).
C>Ничего близкого в Винде нет и не будет никогда.

да даже банальный strace. Недавно искал аналог для виндоуз -- нашел какие-то неподдерживаемые поделки, которые не смог запустить.

Здравствуйте, Cyberax, Вы писали:

C>С oprofile я могу запустить программу и посмотреть профиль всей системы. Т.е. вообще всей, вплоть до ядра. К примеру, для моей (графической) программы я как-то с удивлением обнаружил, что bottleneck оказался в X-сервере, а не там, где я его искал в своём коде.
Это давно умеет VTune.

C>Сюда добавляем ещё latencytop (поиск причин латентности) и perf (профилирование и трассировка ядра).
Интеловские тулы это всё умеют. Причём ещё для этого юзают встроенные возможности интеловских процов.

C>Ничего близкого в Винде нет и не будет никогда.
Даааааа. Канееееешна.

Здравствуйте, Banned by IT, Вы писали:

C>>Сюда добавляем ещё latencytop (поиск причин латентности) и perf (профилирование и трассировка ядра).
BBI>Интеловские тулы это всё умеют. Причём ещё для этого юзают встроенные возможности интеловских процов.
И резко теряют в функциональности на неинтеловских камнях.

C>>Ничего близкого в Винде нет и не будет никогда.
BBI>Даааааа. Канееееешна.
Будет потребность — сделают. Только не скоро она будет.

Здравствуйте, Cyberax, Вы писали:

C>Самый отстойный С++ я видел у программистов на MFC (с CString'ами и прочей гадостью)

а что, собственно, плохого в CString?

Здравствуйте, Banned by IT, Вы писали:

C>>С oprofile я могу запустить программу и посмотреть профиль всей системы. Т.е. вообще всей, вплоть до ядра. К примеру, для моей (графической) программы я как-то с удивлением обнаружил, что bottleneck оказался в X-сервере, а не там, где я его искал в своём коде.
BBI>Это давно умеет VTune.
ВСЕЙ системы? Т.е. одновременно ВСЕХ процессов, работающих в ней со всеми символами? И как оно мне поможет — у меня разве есть отладочные символы для csrss.exe или какого-нибудь сервиса, я уж не говорю про исходники?

Кстати, OProfile умеет заглядывать даже внутрь ядра. Винда нервно курит в сторонке.

C>>Сюда добавляем ещё latencytop (поиск причин латентности) и perf (профилирование и трассировка ядра).
BBI>Интеловские тулы это всё умеют. Причём ещё для этого юзают встроенные возможности интеловских процов.
С помощью Perf и SystemTap я могу отслеживать вещи типа распределения времени между Апачем и Postgres'ом, в зависимости от URL'а запроса. С использованием аппаратны performance counter'ов (в том числе на ARM и AMD'шных процессорах). С разбивкой на время ожидания кэш-промахов, обновлений TLB и т.п.

C>>Ничего близкого в Винде нет и не будет никогда.
BBI>Даааааа. Канееееешна.
Не будет. Ты реально не знаешь насколько Винда отстала в удобстве разработки системного софта, так как дальше неё ничего не видел.

Здравствуйте, Mazay, Вы писали:

C>>>Сюда добавляем ещё latencytop (поиск причин латентности) и perf (профилирование и трассировка ядра).
BBI>>Интеловские тулы это всё умеют. Причём ещё для этого юзают встроенные возможности интеловских процов.
M>И резко теряют в функциональности на неинтеловских камнях.
Ну извините. Если АМД мышей не ловит и аппаратную поддержку с софтварной не обеспечивает то кто в этом виноват?
Вот и выходит: лучший проц от Intel-а, лучший компилер от Intel-а, лучшие тулы для профайлинга от Intel-а, лучшая поддержка разработчиков от Intel-а...
Какой проц я выберу для разработки и буду настоятельно рекомендовать заказчику? Ответ очевиден.
Вот и получается совершенно банальный ответ на то, почему Intel "заняла такую долю рынка, и что виноват в этом только капитализм" (C)

In 3Q11, Intel earned 80.2% overall worldwide unit market share, a gain of 0.9% compared to 2Q11. In 3Q11, AMD earned 19.7%, a loss of 0.7% compared to 2Q11

Ну и какое мне вообще дело в таком контексте что на не-интеловских камнях этой функциональности нет?

C>>>Ничего близкого в Винде нет и не будет никогда.
BBI>>Даааааа. Канееееешна.
M>Будет потребность — сделают. Только не скоро она будет.
Давным давно уже есть.

Здравствуйте, Deprivator, Вы писали:

C>>Самый отстойный С++ я видел у программистов на MFC (с CString'ами и прочей гадостью)
D>а что, собственно, плохого в CString?
Если кратко, то весь CString.

Здравствуйте, Cyberax, Вы писали:

C>>>Самый отстойный С++ я видел у программистов на MFC (с CString'ами и прочей гадостью)
D>>а что, собственно, плохого в CString?
C>Если кратко, то весь CString.

что именно не так? весьма эффективная и удобная реализация строк.

Здравствуйте, Cyberax, Вы писали:

C>>>С oprofile я могу запустить программу и посмотреть профиль всей системы. Т.е. вообще всей, вплоть до ядра. К примеру, для моей (графической) программы я как-то с удивлением обнаружил, что bottleneck оказался в X-сервере, а не там, где я его искал в своём коде.
BBI>>Это давно умеет VTune.
C>ВСЕЙ системы? Т.е. одновременно ВСЕХ процессов, работающих в ней со всеми символами?
В VTune есть несколько режимов работы. Есть режим сэмплинга через processor events. В том режиме нет различия твоя программа или не твоя. Event может прилететь во время выполнения драйвера или любого другого процесса.
Жаль у меня лицухи нет на последний VTune. Тот что есть уже прилично старый и под х64 не работает. Я б тебе скринов наделал.

C>И как оно мне поможет — у меня разве есть отладочные символы для csrss.exe или какого-нибудь сервиса
Сразу видно что с виндой ты дела толком не имел. Прописываешь куда надо http://msdl.microsoft.com/download/symbols и вот у тебя уже есть символы ваще от всего микрософтовского.

C>я уж не говорю про исходники?
Ну, сурсы МС зажала, это да.

C>Кстати, OProfile умеет заглядывать даже внутрь ядра. Винда нервно курит в сторонке.
[зевает]да, да, конечно.

C>С использованием аппаратны performance counter'ов (в том числе на ARM и AMD'шных процессорах). С разбивкой на время ожидания кэш-промахов, обновлений TLB и т.п.
VTune это умел ещё со времён Pentium M, если не раньше.

C>>>Ничего близкого в Винде нет и не будет никогда.
BBI>>Даааааа. Канееееешна.
C>Не будет.
Да есть уже, тебе говорят.

C> Ты реально не знаешь насколько Винда отстала в удобстве разработки системного софта, так как дальше неё ничего не видел.
У нас проект под win и lin. Системный.

Здравствуйте, Cyberax, Вы писали:

C>С oprofile я могу запустить программу и посмотреть профиль всей системы. Т.е. вообще всей, вплоть до ядра. К примеру, для моей (графической) программы я как-то с удивлением обнаружил, что bottleneck оказался в X-сервере, а не там, где я его искал в своём коде.
C>Сюда добавляем ещё latencytop (поиск причин латентности) и perf (профилирование и трассировка ядра).

см kernrate, часть Windows Server 2003 Resource Kit Tools:
годная консольная тулза как для драйвер девелопмента, так и для user mode, понимает символы, может показывать общесистемную статистику, user/kernel mode, статистику по процессам, по модулям.

что еще можно предложить:
— vs profiler — честно говоря, не знаю, не юзал
— perfmonance counters(perfmon) — довольно серьезный инструмент "из коробки"
— procmon/procexp — тоже неслабо помогает понять что же происходит в системе, procexp умеет показывать стеки и CPU usage потоков, это вообще бомба

C>Ничего близкого в Винде нет и не будет никогда.
сильно категоричное высказывание, как для инженера. если занесет попрограммить под windows рекомендую глянуть:
Windows Driver Kit
Debugging Tools
Windows Server 2003 Resource Kit Tools
Sysinternals Tools
содержимое данных тулкитов помогает бедным несчастным системным программистам под windows диагностировать довольно широкий круг проблем, в т.ч. проблемы с производительностью

Здравствуйте, Ikemefula, Вы писали:

I>Здравствуйте, alpha21264, Вы писали:

I>>>Это мягко говоря заблуждение. Инструмент или соответствует уровню решаемых задач или нет. Поскольку код низкоуровневый, то инструменты намного более важны, чем для менджед, а реально получается наоборот — инструменты почти ничего не умеют

A>>Глупость от повторения умнее не становится. Ваш КО. Аргументы будут? Ну хоть какие-то?

I>Необходимо изменение дизайна программы при изменении требований и интеграция с компонентами другого приложения. Нужен инструмент, который сделает это изменение максимально безопасным.

I>Решение — рефакторинг + интеграция. Net/Java умеют это на раз. В С++ вылазит сразу всё
I>- долгая компиляция == нельзя пускать тесты настолько часто, насколько это требует задача
Может лучше просто сразу писать хорошо, чем после каждой срочки запуск?

I>- хреновый синтаксис == инспекторы слабые, автоматические рефакторинги слабые
Как синтаксис языка имеет отношение к инструментам — я хз.

I>- слабые языковые возможности (нет фп, рефлексии и тд) == простейшие вещи вынуждают на ровном месте городить ахинею в виде хаков
Ну, давеча 11 стандарт вышел. Чегойто там появилось.

I>- вагоны "стандартных" либ мешают сконцентрироваться на задаче
А нахрена тебе вагоны? Берешь например, qt, и ложишь на остальное, ибо в ней все есть. Ну, почти все.

Здравствуйте, Ikemefula, Вы писали:

I>>>И что там для чистки кода, текстовый редактор ?
C>>В QTCreator'е — редактор + рефакторинги.
I>Что он умеет из того, что умеет решарпер или Idea ?
$0 он умеет например

Здравствуйте, Ikemefula, Вы писали:

I>То есть, тратят лишнее время в то время когда выхлоп один и тот же.
Да нет, не один и тот же. Выхлоп ц++ может и несколько попозже будет (зависит от программиста и только от него), зато выхлоп софта на плюсах несколько побыстрее в силу нативности кода.

Здравствуйте, Banned by IT, Вы писали:

BBI>Жаль у меня лицухи нет на последний VTune.
Ой, а что такое — "лицуха"?

Здравствуйте, Banned by IT, Вы писали:

C>>ВСЕЙ системы? Т.е. одновременно ВСЕХ процессов, работающих в ней со всеми символами?
BBI>В VTune есть несколько режимов работы. Есть режим сэмплинга через processor events. В том режиме нет различия твоя программа или не твоя. Event может прилететь во время выполнения драйвера или любого другого процесса.
BBI>Жаль у меня лицухи нет на последний VTune. Тот что есть уже прилично старый и под х64 не работает. Я б тебе скринов наделал.
Я им пользовался где-то пару лет назад. Всю систему отладить он ниасилил. Особенно няшно он падал в NVidia'вском драйвере.

C>>И как оно мне поможет — у меня разве есть отладочные символы для csrss.exe или какого-нибудь сервиса
BBI>Сразу видно что с виндой ты дела толком не имел. Прописываешь куда надо http://msdl.microsoft.com/download/symbols и вот у тебя уже есть символы ваще от всего микрософтовского.
Я вижу, что ты с VTune мало работал. Там символы есть далеко не для всего. Про серверы символов я прекрасно и сам знаю.

C>>Кстати, OProfile умеет заглядывать даже внутрь ядра. Винда нервно курит в сторонке.
BBI>[зевает]да, да, конечно.
Да, да. С отладочными символами и без необходимости заниматься сексом с checked-версиями.

C>>С использованием аппаратны performance counter'ов (в том числе на ARM и AMD'шных процессорах). С разбивкой на время ожидания кэш-промахов, обновлений TLB и т.п.
BBI>VTune это умел ещё со времён Pentium M, если не раньше.
На ARM'ах??

BBI>>>Даааааа. Канееееешна.
C>>Не будет.
BBI>Да есть уже, тебе говорят.
Нет, и не будет.

C>> Ты реально не знаешь насколько Винда отстала в удобстве разработки системного софта, так как дальше неё ничего не видел.
BBI>У нас проект под win и lin. Системный.
Ну значит, мало современный Линукс знаете.

Здравствуйте, Ligen, Вы писали:

C>>Сюда добавляем ещё latencytop (поиск причин латентности) и perf (профилирование и трассировка ядра).
L>см kernrate, часть Windows Server 2003 Resource Kit Tools:
L>годная консольная тулза как для драйвер девелопмента, так и для user mode, понимает символы, может показывать общесистемную статистику, user/kernel mode, статистику по процессам, по модулям.
Теперь к ней прикрутить ещё кастомные замеры (по tracepoint'ам внутри функций), возможность сбора аппаратной статистики и будет слегка похоже на oprofile + perf.

perf/SystemTap — это вообще звери. Они позволяют динамически расставлять пробы внутри ядра. Причём пробы устроены так, что в обычном режиме они имеют нулевой оверхед (совсем нулевой — пробы вставляются с помощью code patching). Можно из пробы привязать на поток метку и потом смотреть куда она заведёт. Суперкруто — можно буквально смотреть как сетевой пакет движется по всему стеку.

C>>Ничего близкого в Винде нет и не будет никогда.
L>сильно категоричное высказывание, как для инженера. если занесет попрограммить под windows рекомендую глянуть:
Ну я как бы драйверы писал. И прекрасно помню секс с checked-версиями и отладочными символами.

Здравствуйте, Ikemefula, Вы писали:

I>>>В силу того, что для чистки кода нужны инструменты, получается следующиее
I>>>1. нормальных инструментов для с++ нет
I>>>2. нормальный инструментов для лялиха нет

AV>>В твоей реальности? Более чем возможно.

I>Ну ка, покажи свой классный опенсорсный код

Моего опенсоурс кода нет. А что касается линухового кода, то он ничем не отличается от виндового

Здравствуйте, midl, Вы писали:

А я заметил, что дибилы и быдлокодеры чаще всего жалуются на то что все вокруг ламеры, и только они Д'Артоньяны.

Здравствуйте, VladD2, Вы писали:

VD> А я заметил, что дибилы и быдлокодеры чаще всего жалуются на то что все вокруг ламеры, и только они Д'Артоньяны.

Эпический срыв покровов!

	Скрытый текст
	Блабы, блабы... Кругом одни блабы... Эй, блабы, куда вы меня тащите

Здравствуйте, midl, Вы писали:

M>Как у других с этим, есть ли похожие наблюдления? Действительно ли написание кода под линукс приводит к развитию плохого стиля кодирования?

"Разруха не в клозетах, разруха — в головах" (с). Если человек выдает на гора говнокод под одной платформой, как-то странно ожидать от него жемчужин на другой. Проблема не в платформе, а в конкретном программере.

Здравствуйте, VladD2, Вы писали:

VD>Здравствуйте, midl, Вы писали:

VD>А я заметил, что дибилы и быдлокодеры чаще всего жалуются на то что все вокруг ламеры, и только они Д'Артоньяны.
Требую бан влада за оскорбление!

Здравствуйте, kochetkov.vladimir, Вы писали:

KV>Здравствуйте, midl, Вы писали:

M>>Как у других с этим, есть ли похожие наблюдления? Действительно ли написание кода под линукс приводит к развитию плохого стиля кодирования?

KV>"Разруха не в клозетах, разруха — в головах" (с). Если человек выдает на гора говнокод под одной платформой, как-то странно ожидать от него жемчужин на другой. Проблема не в платформе, а в конкретном программере.
Тут дело в причинах такой статистики. Почему процент пишуших говнокод, пришедших с линукса, вразу больше, чем у пришедших с винды.

Здравствуйте, Mystic, Вы писали:

I>>Вероятно джава-код будет покачественней кода на с++ на том же линуксе. Правильно ? Джава-программист будет прокачиваться в самых разных скилах, а лялих-с++ станет мастером нахождения багов с указателями потому что ни на что другое времени не хватит(особенно если уже не джуниор — придется за другими подчищать). Какой из них качественнее как программист ?

M>Проблемы с указателями сильно преувеличены

Ага, чуть не каждый первй проект на С++ содержит косяки с ними.

Здравствуйте, Ikemefula, Вы писали:

I>Здравствуйте, Mystic, Вы писали:

I>>>Вероятно джава-код будет покачественней кода на с++ на том же линуксе. Правильно ? Джава-программист будет прокачиваться в самых разных скилах, а лялих-с++ станет мастером нахождения багов с указателями потому что ни на что другое времени не хватит(особенно если уже не джуниор — придется за другими подчищать). Какой из них качественнее как программист ?

M>>Проблемы с указателями сильно преувеличены

I>Ага, чуть не каждый первй проект на С++ содержит косяки с ними.
Дык чуть не каждый первый проект содержит и другие баги, не связанные с указателями Такова жизнь, с этим ничего не поделать

Здравствуйте, Cyberax, Вы писали:


C>>>С oprofile я могу запустить программу и посмотреть профиль всей системы. Т.е. вообще всей, вплоть до ядра. К примеру, для моей (графической) программы я как-то с удивлением обнаружил, что bottleneck оказался в X-сервере, а не там, где я его искал в своём коде.
BBI>>Это давно умеет VTune.
C>ВСЕЙ системы? Т.е. одновременно ВСЕХ процессов, работающих в ней со всеми символами? И как оно мне поможет — у меня разве есть отладочные символы для csrss.exe или какого-нибудь сервиса

kd > .symfix

глянул у себя в sym:
csrss.pdb — 107K
csrsrv.pdb — 75K

??
ты точно драйвера писал под windows?

C>>>я уж не говорю про исходники?
wrk

Здравствуйте, midl, Вы писали:

KV>>"Разруха не в клозетах, разруха — в головах" (с). Если человек выдает на гора говнокод под одной платформой, как-то странно ожидать от него жемчужин на другой. Проблема не в платформе, а в конкретном программере.
M>Тут дело в причинах такой статистики. Почему процент пишуших говнокод, пришедших с линукса, вразу больше, чем у пришедших с винды.

может потому, что им там места не нашлось, вот они и пришли на виндовс

Здравствуйте, Sheridan, Вы писали:

I>>- долгая компиляция == нельзя пускать тесты настолько часто, насколько это требует задача
S>Может лучше просто сразу писать хорошо, чем после каждой срочки запуск?

Помню, как на предыдущей работе один из боссов выдал такое же откровение — тестеров нанимать не надо, пусть разработчики пишут сразу и без ошибок.
Ну, хорошо хоть технический директор объяснил ему, что к чему.

I>>- хреновый синтаксис == инспекторы слабые, автоматические рефакторинги слабые
S>Как синтаксис языка имеет отношение к инструментам — я хз.

Это неудивительно, ты же не специалист.

Здравствуйте, Ligen, Вы писали:

C>>ВСЕЙ системы? Т.е. одновременно ВСЕХ процессов, работающих в ней со всеми символами? И как оно мне поможет — у меня разве есть отладочные символы для csrss.exe или какого-нибудь сервиса
L>kd > .symfix
L>глянул у себя в sym:
L>csrss.pdb — 107K
L>csrsrv.pdb — 75K
L>??
L>ты точно драйвера писал под windows?
Абсолютно. И конкретно с csrss долго сексом занимался почему оно виснет.

Здравствуйте, dilmah, Вы писали:

C>>Сюда добавляем ещё latencytop (поиск причин латентности) и perf (профилирование и трассировка ядра).
C>>Ничего близкого в Винде нет и не будет никогда.

D>да даже банальный strace. Недавно искал аналог для виндоуз -- нашел какие-то неподдерживаемые поделки, которые не смог запустить.

1) sysinternals debugwiew?
2) TraceView?
3) sysinternals procmon, diskmon, tokenmon?

для чего нужно было?

Здравствуйте, Ikemefula, Вы писали:

I>Ага, чуть не каждый первй проект на С++ содержит косяки с ними.

Вот я активно юзаю bash, gcc, TeX, vim, valgrind, autotools, nginx, bzip2, tar, ... И как-то не натыкался еще на косяки. Может они и есть, но для меня, как для юзера, они некритичны.

Здравствуйте, Sheridan, Вы писали:

I>>Решение — рефакторинг + интеграция. Net/Java умеют это на раз. В С++ вылазит сразу всё
I>>- долгая компиляция == нельзя пускать тесты настолько часто, насколько это требует задача
S>Может лучше просто сразу писать хорошо, чем после каждой срочки запуск?

Достаточно если:
1 ты один на проекте
2 требования не меняются
3 нет срочных релизов
4 проект до ~10 тыс строк
5 ты крут аки господь бог и можешь написать код на все случаи жизни


I>>- хреновый синтаксис == инспекторы слабые, автоматические рефакторинги слабые
S>Как синтаксис языка имеет отношение к инструментам — я хз.

Сложный синтаксис — сложный парсер. Соответсвенно инструменты будут кривыми.

I>>- слабые языковые возможности (нет фп, рефлексии и тд) == простейшие вещи вынуждают на ровном месте городить ахинею в виде хаков
S>Ну, давеча 11 стандарт вышел. Чегойто там появилось.

И это резко сделает имеющийся код качественным ?

I>>- вагоны "стандартных" либ мешают сконцентрироваться на задаче
S>А нахрена тебе вагоны? Берешь например, qt, и ложишь на остальное, ибо в ней все есть. Ну, почти все.

Обычное дело — берешь готовые компоненты и оказывается, что один чисто на Си, другой втл, третий мфц, четвертый — qt...

Здравствуйте, Sheridan, Вы писали:

I>>>>И что там для чистки кода, текстовый редактор ?
C>>>В QTCreator'е — редактор + рефакторинги.
I>>Что он умеет из того, что умеет решарпер или Idea ?
S>$0 он умеет например

А что это такое ?

Здравствуйте, Sheridan, Вы писали:

I>>То есть, тратят лишнее время в то время когда выхлоп один и тот же.
S>Да нет, не один и тот же. Выхлоп ц++ может и несколько попозже будет (зависит от программиста и только от него), зато выхлоп софта на плюсах несколько побыстрее в силу нативности кода.

Если нет низкоуровневых ограничений, то профит больше там, где больше возможностей заюзать высокоуровневые оптимизации.

Здравствуйте, ambel-vlad, Вы писали:

I>>Ну ка, покажи свой классный опенсорсный код

AV>Моего опенсоурс кода нет.

Ыть. Это что же, ты про опенсорс рассказывал сказки не распробовав его ?

>А что касается линухового кода, то он ничем не отличается от виндового

Не замечал.

Здравствуйте, midl, Вы писали:

M>Сам все время писал на венде, но временами по работе приходится сталкиваться с прогерами пишущими под линукс, а также с прогерами, которые до этого писали под никсы и лишь недавно перешли на винду. Сложилось впечатление, что кол-го говнокода у линуксойдов вразы больше чем у виндовых прогеров. Причем в большенстве своем линуксойды вообще не способны писать на плюсах. Пишущи на плюсах, выдают жудкий спагети код в сишном стиле с прикрученными не к месту классами, с методами на сотни строк и отсутсвием сколь-либо вминяемой структурированности кода и архитектуры. Можно сказать что просто совпадение, но я наблюдал такую ситуация во всех компаниях где встречал линуксойдов — среднее качество кода, выдаваемое линуксойдом, заметно хуже чем у прогера, писавщего большую часть жизни под винду.
M>Как у других с этим, есть ли похожие наблюдления? Действительно ли написание кода под линукс приводит к развитию плохого стиля кодирования?

Поскольку там писать проще, то у них развивается стиль кодирования, в котором писать требуется меньше. Заодно остается больше времени на изучение русского языка.

Здравствуйте, Mystic, Вы писали:

M>Вот я активно юзаю bash, gcc, TeX, vim, valgrind, autotools, nginx, bzip2, tar, ... И как-то не натыкался еще на косяки. Может они и есть, но для меня, как для юзера, они некритичны.

nginx:

http://www.securityfocus.com/bid/36384

Здравствуйте, Ikemefula, Вы писали:

M>>Вот я активно юзаю bash, gcc, TeX, vim, valgrind, autotools, nginx, bzip2, tar, ... И как-то не натыкался еще на косяки. Может они и есть, но для меня, как для юзера, они некритичны.

I>http://www.securityfocus.com/bid/36384
I>

Можно подумать, что программы на Java и C# волшебным образом избавлены от багов...

Здравствуйте, Ikemefula, Вы писали:

I>- вагоны "стандартных" либ мешают сконцентрироваться на задаче
а не в Java-ли тысячи разных "либ"? Как не глянешь на CV Java спеца, одни аббревиатуры. Давно известно, что крутой программер на Java дольше выбирает фреймворки, чем пишет код.

Здравствуйте, Sheridan, Вы писали:

S>Здравствуйте, Ikemefula, Вы писали:

I>>Здравствуйте, alpha21264, Вы писали:

I>>>>Это мягко говоря заблуждение. Инструмент или соответствует уровню решаемых задач или нет. Поскольку код низкоуровневый, то инструменты намного более важны, чем для менджед, а реально получается наоборот — инструменты почти ничего не умеют

A>>>Глупость от повторения умнее не становится. Ваш КО. Аргументы будут? Ну хоть какие-то?

I>>Необходимо изменение дизайна программы при изменении требований и интеграция с компонентами другого приложения. Нужен инструмент, который сделает это изменение максимально безопасным.

I>>Решение — рефакторинг + интеграция. Net/Java умеют это на раз. В С++ вылазит сразу всё
I>>- долгая компиляция == нельзя пускать тесты настолько часто, насколько это требует задача
S>Может лучше просто сразу писать хорошо, чем после каждой срочки запуск?
Да, опыт прёт из всех щелей.
Помнится, ты утверждал, что можно и без полного прогона тестов выдавать билды, если ты уверен, что ничего своим фиксом не сломал.

I>>- хреновый синтаксис == инспекторы слабые, автоматические рефакторинги слабые
S>Как синтаксис языка имеет отношение к инструментам — я хз.
Прямое.
Тебе не очень ясно почему, это тоже не удивительно.

I>>- слабые языковые возможности (нет фп, рефлексии и тд) == простейшие вещи вынуждают на ровном месте городить ахинею в виде хаков
S>Ну, давеча 11 стандарт вышел. Чегойто там появилось.
А это к чему? Какой компилятор реализует его?

I>>- вагоны "стандартных" либ мешают сконцентрироваться на задаче
S>А нахрена тебе вагоны? Берешь например, qt, и ложишь на остальное, ибо в ней все есть. Ну, почти все.
Шеридан, тебе снова объяснять что такое работа в команде над большой системой не будут.
Твоя сконцентрированность на QT поражает.

Здравствуйте, Ikemefula, Вы писали:

I>Здравствуйте, Mystic, Вы писали:

M>>Вот я активно юзаю bash, gcc, TeX, vim, valgrind, autotools, nginx, bzip2, tar, ... И как-то не натыкался еще на косяки. Может они и есть, но для меня, как для юзера, они некритичны.

I>nginx:

I>http://www.securityfocus.com/bid/36384

I>

Ага, 1 человек писал — это, конечно, пример.

Здравствуйте, blackhearted, Вы писали:

B>Здравствуйте, Ikemefula, Вы писали:

I>>- вагоны "стандартных" либ мешают сконцентрироваться на задаче
B>а не в Java-ли тысячи разных "либ"? Как не глянешь на CV Java спеца, одни аббревиатуры. Давно известно, что крутой программер на Java дольше выбирает фреймворки, чем пишет код.
B>

Ты так говоришь как будто это что-то плохое

Здравствуйте, Mystic, Вы писали:

M>>>Вот я активно юзаю bash, gcc, TeX, vim, valgrind, autotools, nginx, bzip2, tar, ... И как-то не натыкался еще на косяки. Может они и есть, но для меня, как для юзера, они некритичны.

I>>http://www.securityfocus.com/bid/36384
I>>

M>Можно подумать, что программы на Java и C# волшебным образом избавлены от багов...

Баги с указателями отсутствуют как класс. Это высвобождает время девелоперов.

Здравствуйте, blackhearted, Вы писали:

B>Здравствуйте, Ikemefula, Вы писали:

I>>- вагоны "стандартных" либ мешают сконцентрироваться на задаче
B>а не в Java-ли тысячи разных "либ"? Как не глянешь на CV Java спеца, одни аббревиатуры. Давно известно, что крутой программер на Java дольше выбирает фреймворки, чем пишет код.
B>

В джаве много либ, но стандартная только одна. И в дотнете тож самое. В с++ стандартных вагоны, а унифицирована только CRT.

Пример — сколько классов строк в типичной программе на с++ ?

Здравствуйте, blackhearted, Вы писали:

M>>>Вот я активно юзаю bash, gcc, TeX, vim, valgrind, autotools, nginx, bzip2, tar, ... И как-то не натыкался еще на косяки. Может они и есть, но для меня, как для юзера, они некритичны.

I>>nginx:

I>>http://www.securityfocus.com/bid/36384

I>>

B>Ага, 1 человек писал — это, конечно, пример.

Я чет не понял что ты хотел сказать.

Здравствуйте, Ikemefula, Вы писали:

I>Здравствуйте, blackhearted, Вы писали:

B>>Здравствуйте, Ikemefula, Вы писали:

I>>>- вагоны "стандартных" либ мешают сконцентрироваться на задаче
B>>а не в Java-ли тысячи разных "либ"? Как не глянешь на CV Java спеца, одни аббревиатуры. Давно известно, что крутой программер на Java дольше выбирает фреймворки, чем пишет код.
B>>

I>В джаве много либ, но стандартная только одна. И в дотнете тож самое. В с++ стандартных вагоны, а унифицирована только CRT.
Это какие?
CRT — это, вообще, сишный рантайм.

I>Пример — сколько классов строк в типичной программе на с++ ?
Если ничего не нужно сверхестественного — std::string.
Ты считаешь, что в java всегда хватает реализаций из utils.* ?

Здравствуйте, blackhearted, Вы писали:

I>>В джаве много либ, но стандартная только одна. И в дотнете тож самое. В с++ стандартных вагоны, а унифицирована только CRT.
B>Это какие?
B>CRT — это, вообще, сишный рантайм.

Вот-вот. Все остальное в нескольких вариантах.

I>>Пример — сколько классов строк в типичной программе на с++ ?
B>Если ничего не нужно сверхестественного — std::string.

Скучный аргумент.Как быть с программами где это не так ?

Здравствуйте, Ikemefula, Вы писали:

I>>>Пример — сколько классов строк в типичной программе на с++ ?
B>>Если ничего не нужно сверхестественного — std::string.

I>Скучный аргумент.Как быть с программами где это не так ?
Скучный вброс.

Я еще раз спрошу.
В java всегда хватает utils.*?

Здравствуйте, midl, Вы писали:

M>Требую бан влада за оскорбление!

За одно потребуй там, чтобы тепла дали. А то холодно очень!

Здравствуйте, Ikemefula, Вы писали:

I>Здравствуйте, Mystic, Вы писали:

M>>>>Вот я активно юзаю bash, gcc, TeX, vim, valgrind, autotools, nginx, bzip2, tar, ... И как-то не натыкался еще на косяки. Может они и есть, но для меня, как для юзера, они некритичны.

I>>>http://www.securityfocus.com/bid/36384
I>>>

M>>Можно подумать, что программы на Java и C# волшебным образом избавлены от багов...

I>Баги с указателями отсутствуют как класс. Это высвобождает время девелоперов.

За 3 года не было ни одного бага с указателями.
Только плюсы, 10M+ LOC.

Здравствуйте, Ikemefula, Вы писали:

I>Здравствуйте, blackhearted, Вы писали:

I>>>В джаве много либ, но стандартная только одна. И в дотнете тож самое. В с++ стандартных вагоны, а унифицирована только CRT.
B>>Это какие?
B>>CRT — это, вообще, сишный рантайм.

I>Вот-вот. Все остальное в нескольких вариантах.

еще раз внимательно прочитай выделенно Мы тут вообщето с++ обсуждаем. И таки да, в плюсах есть всего одни стандартные строки, и это далеко не CString

Здравствуйте, Ikemefula, Вы писали:

I>Необходимо изменение дизайна программы при изменении требований и интеграция с компонентами другого приложения. Нужен инструмент, который сделает это изменение максимально безопасным.

I>Решение — рефакторинг + интеграция. Net/Java умеют это на раз. В С++ вылазит сразу всё
I>- долгая компиляция == нельзя пускать тесты настолько часто, насколько это требует задача
I>- хреновый синтаксис == инспекторы слабые, автоматические рефакторинги слабые
I>- слабые языковые возможности (нет фп, рефлексии и тд) == простейшие вещи вынуждают на ровном месте городить ахинею в виде хаков
I>- вагоны "стандартных" либ мешают сконцентрироваться на задаче

I>Вот небольшая заметка на похожую тему: http://blog.objectmentor.com/articles/2007/07/03/observations-on-tdd-in-c-long
I>Что характерно, была написана 5 лет тем самым Дядей Бобом, чья бригада написала чуть не все книги по ООП

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

Итак что бы сделал Юниксоид в этой ситуации.
1) Если нужна интергация с компонентами другого приложения, то нужен не рефакторинг, а прокладка.
Это прокладка может быть фасадом, враппером, адаптером и тд.
Классический Юниксоид написал бы ОТДЕЛЬНУЮ программу, которая транслировала бы что-то во что-то.
Хотя и на С++ можно было бы изобразить какой-нибудь из этих паттернов, но это хуже.
2) Не знаю, чего у тебя там за долгая компиляция. Я такие вещи (прокладки) пишу сразу на баше.
Фаза компиляции вообще отсутствует. Но выбор bash/C++/другой_язык зависит от многих условий.
В Юниксе принят Юникс-вей, когда программы разговаривают друг с другом через текстовые файлы.
И запуск программы — дешев.
3) Хреновый синтаксис — плохому танцору всегда чего-нибудь мешает.
4) Слабые языковые возможности — в Юниксе язык можно выбирать.
5) Вагоны стандартных либ — кто же тот злодей, который заставляет использовать тебя весь вагон?
6) Нормальные люди для изменения требования заказчиков делают какой-нибудь слой скриптинга.
Язык макросов, который позволяет вносить изменения в проект прямо на лету. Без перекомпиляции.
Даже Микрософт сделал для своего Ворда нечто подобное (Бейсик что ли).

Вот что сделал бы в этой ситуации правоверный Юниксоид.

Здравствуйте, Ikemefula, Вы писали:

I>Здравствуйте, Mystic, Вы писали:

M>>Можно подумать, что программы на Java и C# волшебным образом избавлены от багов...

I>Баги с указателями отсутствуют как класс. Это высвобождает время девелоперов.

Это конечно большой плюс. Но давайте вернемся к нашим баранам.

Здравствуйте, Sheridan, Вы писали:

S>Может лучше просто сразу писать хорошо, чем после каждой срочки запуск?

Может и лучше.

Автор: ДимДимыч
Дата: 24.01.12

Здравствуйте, Ikemefula, Вы писали:

I>Здравствуйте, Mystic, Вы писали:

M>>>>Вот я активно юзаю bash, gcc, TeX, vim, valgrind, autotools, nginx, bzip2, tar, ... И как-то не натыкался еще на косяки. Может они и есть, но для меня, как для юзера, они некритичны.

I>>>http://www.securityfocus.com/bid/36384
I>>>

M>>Можно подумать, что программы на Java и C# волшебным образом избавлены от багов...
I>Баги с указателями отсутствуют как класс. Это высвобождает время девелоперов.

null dereference?

Здравствуйте, Mystic, Вы писали:

M>Здравствуйте, Ikemefula, Вы писали:

I>>Здравствуйте, Mystic, Вы писали:

M>>>>>Вот я активно юзаю bash, gcc, TeX, vim, valgrind, autotools, nginx, bzip2, tar, ... И как-то не натыкался еще на косяки. Может они и есть, но для меня, как для юзера, они некритичны.

I>>>>http://www.securityfocus.com/bid/36384
I>>>>

M>>>Можно подумать, что программы на Java и C# волшебным образом избавлены от багов...
I>>Баги с указателями отсутствуют как класс. Это высвобождает время девелоперов.

M>null dereference?
Дык на жаве одни чакнорисы пишут! Им и ноль разыменовать не проблема

Здравствуйте, midl, Вы писали:

M>>null dereference?
M>Дык на жаве одни чакнорисы пишут! Им и ноль разыменовать не проблема

   try
   {
     // много кода
   }
   catch (Exception e) {}

и всего делов.

Здравствуйте, blackhearted, Вы писали:

B>Здравствуйте, Ikemefula, Вы писали:

I>>>>Пример — сколько классов строк в типичной программе на с++ ?
B>>>Если ничего не нужно сверхестественного — std::string.

I>>Скучный аргумент.Как быть с программами где это не так ?
B>Скучный вброс.

B>Я еще раз спрошу.
B>В java всегда хватает utils.*?

А при чем здесь java.utils ?

Куда делся java.lang ? Java.text ? java.io ?

куда ни ткни, то для с++ будет по десятку вариантов

Здравствуйте, blackhearted, Вы писали:

M>>>Можно подумать, что программы на Java и C# волшебным образом избавлены от багов...

I>>Баги с указателями отсутствуют как класс. Это высвобождает время девелоперов.

B>За 3 года не было ни одного бага с указателями.
B>Только плюсы, 10M+ LOC.

А тестеры есть ?

Здравствуйте, Mystic, Вы писали:

M>>>Можно подумать, что программы на Java и C# волшебным образом избавлены от багов...
I>>Баги с указателями отсутствуют как класс. Это высвобождает время девелоперов.

M>null dereference?

Фиксится примерно за 5 минут по первому обнаружению. Баги с указателями проявляют себя _годами_.

Здравствуйте, Ikemefula, Вы писали:

I>Здравствуйте, blackhearted, Вы писали:

B>>Здравствуйте, Ikemefula, Вы писали:

I>>>>>Пример — сколько классов строк в типичной программе на с++ ?
B>>>>Если ничего не нужно сверхестественного — std::string.

I>>>Скучный аргумент.Как быть с программами где это не так ?
B>>Скучный вброс.

B>>Я еще раз спрошу.
B>>В java всегда хватает utils.*?

I>А при чем здесь java.utils ?

I>Куда делся java.lang ? Java.text ? java.io ?
Вас всегда устраивает производительность дефолтных сущностей из java.lang/utils/io.*?

I>куда ни ткни, то для с++ будет по десятку вариантов
Ну-ну, ткни куда-нибудь в широко используемое, где есть больше 5 вариантов хотя-бы.
Рассмотрми стандартные контейнеры типа map/list/vector + string.
Что-то кроме реализаций из STL/boost, QT ничего не вспоминается широко используемого.

Или мы про специфические задачи, когда пишется свой велосипед по какой-то причине?
Тогда и в java будет точно так же.
Я тоже видел, когда в java-проектах даже стринги меняли на свои реализации — это показатель?

Здравствуйте, Ikemefula, Вы писали:

I>В джаве много либ, но стандартная только одна. И в дотнете тож самое. В с++ стандартных вагоны, а унифицирована только CRT.
Стандартная одна Standard Library, в языке пространство имен std, описана международном стандартом языка. Где ты вагоны увидел?

I>Пример — сколько классов строк в типичной программе на с++ ?
Зависит от программистов... У нормальных обычно встречается от одного до N. N зависит от используемых библиотек, которые в большинстве своем начали свое развитие до того как у С++ вообще появились стандарт и стандартная библиотека.
Еще на С++ довольно часто пишут программы, для которых неприемлемо использовать классы общего назначения, а нужны классы строго специализированные под задачу, например по требованием производительности, потребления памяти, избавленности от ошибок и т.п.

Здравствуйте, Ikemefula, Вы писали:

I>Здравствуйте, blackhearted, Вы писали:

M>>>>Можно подумать, что программы на Java и C# волшебным образом избавлены от багов...

I>>>Баги с указателями отсутствуют как класс. Это высвобождает время девелоперов.

B>>За 3 года не было ни одного бага с указателями.
B>>Только плюсы, 10M+ LOC.

I>А тестеры есть ?

Представь себе, и внутренние и на стороне заказчика.
В логике баги есть, в архитектуре просчёты, но с указателями нет.

Здравствуйте, blackhearted, Вы писали:

B>Ну-ну, ткни куда-нибудь в широко используемое, где есть больше 5 вариантов хотя-бы.
B>Рассмотрми стандартные контейнеры типа map/list/vector + string.
B>Что-то кроме реализаций из STL/boost, QT ничего не вспоминается широко используемого.

wxWidgets ещё есть. В С++ классы, скажем, для строк приходят от различных сред разработки с их библиотеками классов: TString(builder), CString(VS). Но всё это относится скорее к виндовым вещам.

Здравствуйте, blackhearted, Вы писали:

B>>>Я еще раз спрошу.
B>>>В java всегда хватает utils.*?

I>>А при чем здесь java.utils ?

I>>Куда делся java.lang ? Java.text ? java.io ?
B>Вас всегда устраивает производительность дефолтных сущностей из java.lang/utils/io.*?

Да.

B>Рассмотрми стандартные контейнеры типа map/list/vector + string.
B>Что-то кроме реализаций из STL/boost, QT ничего не вспоминается широко используемого.

Опаньки, уже три штуки

Здравствуйте, blackhearted, Вы писали:

I>>А тестеры есть ?

B>Представь себе, и внутренние и на стороне заказчика.
B>В логике баги есть, в архитектуре просчёты, но с указателями нет.

Верится с большим трудом

Здравствуйте, Ikemefula, Вы писали:

I>Здравствуйте, blackhearted, Вы писали:

B>>>>Я еще раз спрошу.
B>>>>В java всегда хватает utils.*?

I>>>А при чем здесь java.utils ?

I>>>Куда делся java.lang ? Java.text ? java.io ?
B>>Вас всегда устраивает производительность дефолтных сущностей из java.lang/utils/io.*?

I>Да.

Дальше можно не продолжать, спасибо.

B>>Рассмотрми стандартные контейнеры типа map/list/vector + string.
B>>Что-то кроме реализаций из STL/boost, QT ничего не вспоминается широко используемого.

I>Опаньки, уже три штуки

Где десятки, знаток ты наш?

Здравствуйте, Ikemefula, Вы писали:

I>Здравствуйте, blackhearted, Вы писали:

I>>>А тестеры есть ?

B>>Представь себе, и внутренние и на стороне заказчика.
B>>В логике баги есть, в архитектуре просчёты, но с указателями нет.

I>Верится с большим трудом

Видать, просто не дано.
Ничего, это нормально. Есть люди, которые не могут понять адресную арифметику, и указатели кажутся им какой-то очень сложной вещью.

Здравствуйте, Ikemefula, Вы писали:

I>Здравствуйте, Mystic, Вы писали:

M>>null dereference?
I>Фиксится примерно за 5 минут по первому обнаружению. Баги с указателями проявляют себя _годами_.

У меня ощущения с точностью до наоборот: без указателей как-то очень некомфортно. Баги с указателями достаточно редки.

Здравствуйте, midl, Вы писали:

M>Как у других с этим, есть ли похожие наблюдления? Действительно ли написание кода под линукс приводит к развитию плохого стиля кодирования?

На линаксе пишут много кода для конкретного железа. (Не зря упоминаются драйвера и ядро) А кто всё это пишет? Обычно тот, кто больше любит железки, чем символы. А это накладывает отпечаток на стиль мышления и программирования (или наоборот, стиль мышления приводит к любви к конкретным вещам). Всё это в целом приводит к меньшему уровню абстракций и к более алгоритмичному кодированию. Что порождает простой и работающий, но совершенно неинтересный код.

Здравствуйте, Ikemefula, Вы писали:

I>В с++ стандартных вагоны, а унифицирована только CRT.
Ну и какие стандартные либы ты знаешь из C++?

I>Пример — сколько классов строк в типичной программе на с++ ?
Смотря что считать типичными программами. В моих — один.

Здравствуйте, blackhearted, Вы писали:

I>>Опаньки, уже три штуки
B>Где десятки, знаток ты наш?
Не мешай ему верить!
Он давно живёт в своей реальности, как и шеридан.

Здравствуйте, Ikemefula, Вы писали:

I>>>Ну ка, покажи свой классный опенсорсный код
AV>>Моего опенсоурс кода нет.

I>Ыть. Это что же, ты про опенсорс рассказывал сказки не распробовав его ?
Он опенсурсный код читал и юзал. Но не писал.
Что не так?

Здравствуйте, Ikemefula, Вы писали:

I>>>Что он умеет из того, что умеет решарпер или Idea ?
S>>$0 он умеет например
I>А что это такое ?
Знаки это.

Здравствуйте, Banned by IT, Вы писали:

BBI>Он давно живёт в своей реальности, как и шеридан.

Шеридан живе очень даже в реальной реальности.

Здравствуйте, Sheridan, Вы писали:

BBI>>Он давно живёт в своей реальности, как и шеридан.

S>Шеридан живе очень даже в реальной реальности.
Не всегда, увы, не всегда.

Здравствуйте, Ikemefula, Вы писали:

I>>>Ну ка, покажи свой классный опенсорсный код

AV>>Моего опенсоурс кода нет.

I>Ыть. Это что же, ты про опенсорс рассказывал сказки не распробовав его ?

Ыть не ыть, но один фикс в десяток строк я не считаю большим свои достижением. А насчет нераспробовав, то ты опять протелепал мимо.

>>А что касается линухового кода, то он ничем не отличается от виндового

I>Не замечал.

Чего ты не замечал?

Здравствуйте, Banned by IT, Вы писали:

I>>>>Ну ка, покажи свой классный опенсорсный код
AV>>>Моего опенсоурс кода нет.

I>>Ыть. Это что же, ты про опенсорс рассказывал сказки не распробовав его ?
BBI>Он опенсурсный код читал и юзал. Но не писал.
BBI>Что не так?

Ты до сих так и не понял что у него не так?

Здравствуйте, midl, Вы писали:

VD>>А я заметил, что дибилы и быдлокодеры чаще всего жалуются на то что все вокруг ламеры, и только они Д'Артоньяны.
M>Требую бан влада за оскорбление!

Где? Он никого не оскорблял. А если кто-то примерил сказанное на самого себя, то надо этого кого-то банить, а не Влада.