9 фактов, которые знают программисты, и не знают все остальные

Цитата (ipv4 @ 9.03.2015 - 16:21)

Цитата (VSC @ 9.03.2015 - 13:13) Цитата (ipv4 @ 9.03.2015 - 01:10) Если мы имеем в виду "дедков", лет так 50+ возрастом на настоящий момент, то в их время особо не было понятия о культуре программирования, технологиях и т.п. - "не стреляйте в пианиста, он играет, как умеет". )) Вот оно как, то-то я смотрю, что пишите вы на языках, придуманных этими дедками, сидите в ОС, разработку которых запустили эти дедки. Раньше из-за ограниченности системных ресурсов хоть думали над алгоритмами. оптимизацией. А сейчас модно на яве или сишарпе забабахать hello, world!, который жрет ресурсов больше, чем первые версии винды - вот удел супер-пупер разработчиков. Зато быстро. Таки я не умаляю ничьих заслуг! Просто в последние скажем лет 10-15 в технологиях программирования как таковых поменялось ну очень много, появились новые технологии, новые высокоуровневые вполне себе формализованные абстракции и т.п. За всем уследить очень сложно. Взять, в качестве примера, мой любимый сиплюсплюс: Страуструп его немножко придумал, а потом сам признался, в том, что обалдел от того, что с помощью его детища начали творить люди, в частности Александреску - сам читал в предисловии к какому-то изданию Страуструпа. А вообще, по поводу сишарпов и всяких-там-жаб - согласен с Вами чуть больше, чем полностью!... Сам не так давно обалдел, один мой хороший знакомый, бывший лид-дев в одной довольно большой лавке заявил мне примерно следующее: "Кто такой Кнут, я не знаю - для меня он не авторитет, потому что это - сорок первый год и сейчас все по-другому". Он меня реально решил дара речи! И что самое интересное, он реально не знает базовых алгоритмов обработки данных, не способен оценить производительность кода и т.п. ("а мне это зачем? сейчас все по-другому, все придумано до нас!"). Сишарп. Для меня это - показатель, ога. P.S. Попытки поставить программирование на поток, возможно, к какому-то результату приводят, однако, имхо, совершенно не к тому, к которому должны: ГЛЮЧИТ ВСЕ - автомобили, телевизоры, телефоны - любая железка, чуть умнее чайника - ГЛЮЧИТБЛЯТЬ!

1. Причем тут сишарп?
2. Уж как говнокодят программисты на С++ ники... и уж что говорить про процедурщиков и Delphi, которых рынок вытолкнул на нормальные ООПшные языки. Там просто расстрелять нахуй
2. Конечно нужно быть грамотным и эрудированным специалистом. Но и объемы знаний и информации сейчас в разы выше, чем были 20-30 лет назад.
3. В реальности базовые алгоритмы действительно нужны только для собеседование 80% программистам. Те, кто пишут обход красно-черных деревьев по совместительству являются теми, кто разрабатывает сами движки баз данных. Сколько баз современных баз данных вы знаете? 5 SQL и 7 NoSQL и примерно 20-30 человек команда. Получаем 12*30 = аж 360 программистам в мире реально нужно знать все эти алгоритмы. Ну хорошо, пусть 3600 программистам, а их миллионы.
4. Вот я знаю кто такой Кнут, читал, знаю и помню. А толку? Это почти не используется в прикладных приложениях и формошлёпании. Я бы сейчас 30% ЗП своей отдал, чтобы участвовать в интересном проекте, где понадобились хотябы бы знания того, как обогнать быструю сортировку хоара при определённых "сахарных" условиях задачи. Да ладно сортировка, хотя бы дерево обойти алгоритмом А*
5. На практике и по сути ваш приятель в чем-то прав. Стоимость 1-2 дней программиста на поиск алгоритма стоит дороже, чем новый камень для сервера. Поэтому улучшать производительность на 2-3% или даже 15% за счет неоправданной оптимизации алгоритмов экономически не обоснована. Опять же, чтобы не писать вложенных циклов нужно получить по рукам от лида, а не прочитать кнута.

Цитата (artivenom @ 10.03.2015 - 12:36)

1. Причем тут сишарп? 2. Уж как говнокодят программисты на С++ ники... и уж что говорить про процедурщиков и Delphi, которых рынок вытолкнул на нормальные ООПшные языки. Там просто расстрелять нахуй 2. Конечно нужно быть грамотным и эрудированным специалистом. Но и объемы знаний и информации сейчас в разы выше, чем были 20-30 лет назад. 3. В реальности базовые алгоритмы действительно нужны только для собеседование 80% программистам. Те, кто пишут обход красно-черных деревьев по совместительству являются теми, кто разрабатывает сами движки баз данных. Сколько баз современных баз данных вы знаете? 5 SQL и 7 NoSQL и примерно 20-30 человек команда. Получаем 12*30 = аж 360 программистам в мире реально нужно знать все эти алгоритмы. Ну хорошо, пусть 3600 программистам, а их миллионы. 4. Вот я знаю кто такой Кнут, читал, знаю и помню. А толку? Это почти не используется в прикладных приложениях и формошлёпании. Я бы сейчас 30% ЗП своей отдал, чтобы участвовать в интересном проекте, где понадобились хотябы бы знания того, как обогнать быструю сортировку хоара при определённых "сахарных" условиях задачи. Да ладно сортировка, хотя бы дерево обойти алгоритмом А* 5. На практике и по сути ваш приятель в чем-то прав. Стоимость 1-2 дней программиста на поиск алгоритма стоит дороже, чем новый камень для сервера. Поэтому улучшать производительность на 2-3% или даже 15% за счет неоправданной оптимизации алгоритмов экономически не обоснована. Опять же, чтобы не писать вложенных циклов нужно получить по рукам от лида, а не прочитать кнута.

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

2. Говнокодить можно на чем угодно - тут ваще не вопрос. ))))

3. Категорически не соглашусь - необходимо понимать что конкретно происходит внутри или хотя бы что может происходить. Реальный пример (его еще вспомним) - чувак СОВЕРШЕННО НЕ ДУМАЯ, берет и реализует довольно тяжелый вычислительный алгоритм, использующий выборку произвольного элемента по индексу. А потом, ТАКЖЕ НЕ ДУМАЯ, засовывает в этот алгоритм СПИСОКБЛЯТЬ! Что получаем - алгоритм с, минимум (а то и больше в порядки), квадратичной стоимостью! Здесь новый камень не поможет ну никак, вообще. Потому что обосрать ЛЮБУЮ производительность таким способом - очень и очень просто.
Поэтому, мое мнение - базовые знания нужны всем! Тем более, что сложность решаемых задач растет, и приходится оперировать более абстрактными понятиями, нежели просто массивы и списки - соответственно, специалист должен на подкорке понимать, к чему может привести то или иное его, на первый взгляд, маленькое и незаметное действие.

4. Это - Ваша личная проблема. Надо, правда, отдать должное, что Вы в этом не одиноки - современное программирование как искусство остается в очень немногих отраслях. В моей - еще да. Однако в мире бизнесс-приложений (как "на заре компьютерной эры" говорили - "информационно-поисковых системах" )))) программирование реально превратили в конвейер - красивые алгоритмы заменили менее квалифицированными специалистами и кучей кода - зато простого - "а как же вопросы поддержки кода другими кодерами? - код должен быть простым!". КОДЕРАМИ, а не программистами. Зато дешево из расчета стоимости отдельного сотрудника. Бюджеты проектов при этом правда один хрен космические получаются, но это почему-то уже мало кого волнует...

5. См пункт 3. Как следствие необдуманных действий, можно получить не 15% снижение производительности, а порядки! И это - без написания вложенных циклов - все очень просто и незамысловато - поставил "[]" после контейнера - получи фашист гранату. А для того, чтобы понимать, что происходит в программе - Кнут обязателен. Имхо. И даже думаю, что Вы, сами того не подозревая, используете Ваши знания не то, чтобы ежесекундно, но гораздо чаще, чем Вы сами об этом думаете.

Цитата (lses @ 9.03.2015 - 01:06)

Цитата Факт 5 Отсчёт начинается с нуля старый стишок вспомнился: 10 программистов продукт решили сделать, Один спросил: "А деньги где?", - и их осталось 9. 9 программистов предстали перед боссом, Один из них не знал FoxPro, и их осталось 8. 8 программистов купили IBM, Один сказал: "Мак лучше!", - и их осталось 7. 7 программистов хотели Help прочесть: У одного накрылся винт и их осталось 6. 6 программистов пытались код понять, Один из них сошел с ума, и их осталось 5. 5 программистов купили CD-Rom, Один принес китайский диск - остались вчетвером. 4 программиста работали на Си, Один из них хвалил Паскаль и их осталось 3. 3 программиста в сети играли в DOOM, Один чуть-чуть замешкался, и счет стал равен двум. 2 программиста набрали дружно: "win". Один устал загрузки ждать - остался лишь 1. 1 программист все взял под свой контроль, Hо встретился с заказчиком и их осталось 0. 0 программистов ругал сердитый шеф, Потом уволил одного, и стало их FF.

Раз уж в конце 0-1 = FF, а не 255, тогда с A надо начинать, ибо до 10 там далеко...

КонецЕсли;

Йоу!

Всё супер, кроме первых двух пунктов.

Цитата

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

Это плохое проектирование. В серьёзных компаниях такого очень мало.

Цитата

Занимает это на деле больше или меньше процентов времени, но каждый раз нам действительно необходимо подумать – а что пользователь может тут сломать. Куда нажмёт, что введёт, и как можно понять то, что мы пытаемся сделать, неправильно. Если бы мы рассчитывали только на себя, у программ было бы слишком много проблем – ведь мы знаем, как программа работает, а пользователь не знает.

Аналогично предыдущему - вопрос продумывания всего на 1 шаг вперёд.

Интервью брали не у того эксперта. Жертвам экстремального программирования надо окунуться в теорию систем и не стесняться смотреть своими глазами коды контакта, фэйсбука.
Не претендую на позицию правильного эксперта, но позволю себе заметить, что проектирование системы (именно системы, а не программы, которую "вот мы быстренько щас напишем") это 80% успеха. На данном этапе можно предусмотреть 95% проблем. Конечно, понимание многих моментов приходит только с опытом... Однако же даже отсутствие опыта не может запретить программисту вовремя и в максимальной мере поставить себя на место пользователя и представить себе как идёт работа. Причём как идёт работа не в программе, а как она идёт без программы.

Цитата (ipv4 @ 10.03.2015 - 15:39)

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

Что конкретно особенно проистекает там такого, о чем не задумываются разработчики на .net, но задумываются други?

Цитата (ipv4 @ 10.03.2015 - 15:39)

3.

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

Цитата (ipv4 @ 10.03.2015 - 15:39)

"а как же вопросы поддержки кода другими кодерами? - код должен быть простым!"

Да, в первую очередь код должен быть простым и понятным, а потом уже быстрым или тем более ебанутым элегантным в одну строку. Поубивал бы за однострочные выражения в 10 действий с помощью всякого синтаксического сахара.
Вероятность ошибки возрастает кратно, простата её поиска при дебаге падает, стоимость исправления бага и поддеркжи кода растёт. Зато красноглазик в свитере из 81 год доволен, что написал самое однострочное или короткое в мире выражение и ускорил работу на 0,000000001 секунды и то на этапе первого запуска (в случае с java или C#)


Это

Цитата

И это - без написания вложенных циклов - все очень просто и незамысловато - поставил "[]"

никогда не приведет к этому или соизмеримому результату:

Цитата

Как следствие необдуманных действий, можно получить не 15% снижение производительности, а порядки!

Это демагогия. А выйгрыш в 0,0001 секунду при первом запуске идёт лесом.

Да, я тоже встречал говнокод в плане производительности или глупый обход. Пару раз может быть. А вот говнокод без потери в производительности, который снижает скорость разработки целой команды и тратить на это 5чел*8*3дня*$20 = $2400 просто потому что кому-то очень не хочется изучать как правильно писать чистый код - это факт.
Это сообщение отредактировал artivenom - 10 мар 2015 в 22:06

Цитата (artivenom @ 10.03.2015 - 21:46)

Цитата (ipv4 @ 10.03.2015 - 15:39) они-то как раз очень мало задумываются об алгоритмах и том, что там внутри проистекает Что конкретно особенно проистекает там такого, о чем не задумываются разработчики на .net, но задумываются други?

№3, например из моего как раз прошлого поста. Это реальный случай из моей практики. Не думают.

Да, и я не говорю за всех, я привожу примеры из своей жизни и сопровождаю своими выводами. Все сказанное - мое сугубое имхо (Имею Мнение Хрен Оспоришь ))))).
Это сообщение отредактировал ipv4 - 10 мар 2015 в 21:51

Цитата (ipv4 @ 10.03.2015 - 22:49)

Цитата (artivenom @ 10.03.2015 - 21:46) Цитата (ipv4 @ 10.03.2015 - 15:39) они-то как раз очень мало задумываются об алгоритмах и том, что там внутри проистекает Что конкретно особенно проистекает там такого, о чем не задумываются разработчики на .net, но задумываются други? №3, например из моего как раз прошлого поста. Это реальный случай из моей практики. Не думают. Да, и я не говорю за всех, я привожу примеры из своей жизни и сопровождаю своими выводами. Все сказанное - мое сугубое имхо (Имею Мнение Хрен Оспоришь ))))).

Из примера нифига не понятно в чем проблема.
Ну реализует алгоритм, выборка, ну суют туда список. И что? Не зная алгоритма как я могу сделать вывод, что он не прав или прав? Может бизнес-логика такова, что без списка никак. Большинство алгоритмов реализуется за время О(n2) и лишь только деревья с рекурсиями за логарифм и обход по индексу за линейное время.

Цитата (artivenom @ 10.03.2015 - 21:46)

Во-первых, квадратичная сложность не есть проблема и ни есть плохой алгоритм.

ААААААААААААААА!!!!!!!!!!!!!! Если квадратичная сложность возникает там, где ее быть не должно (там, где она получилась случайно) - это ооооочень большая проблема, я Вас уверяю! Я сам лично сидел и ждал по 20 (!!!!!) минут загрузки документа на супер-пупер-мощном-компе только из-за того, что какой-то гений организовал квадратичную сложность от количества объектов в документе... Причем сделал это случайно - добавил лишнюю проверку - "а что, оно же надежней!"... После отключения проверки - время сократилось до пары секунд! Вот Вам и "не есть плохой алгоритм"...

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

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

Добавлено в 22:06

Цитата (artivenom @ 10.03.2015 - 21:53)

Большинство алгоритмов реализуется за время О(n2) и лишь только деревья с рекурсиями за логарифм и обход по индексу за линейное время.

Не соглашусь. )) У меня другая практика: большинство алгоритмов можно вывести на логарифмическую стоимость. И только в алгоритмах, связанных с обработкой графов, стоимость колеблется от O(n^2) до O(n!) - но тут уже никуда не деться и, зная это, всегда применяется оценка характеристик графа с последующим "хер с ним - оставляем так", либо применяются методики оптимизации графа - дабы вдруг не получить профак по производительности.

Цитата (ipv4 @ 10.03.2015 - 23:02)

ААААААААААААААА!!!!!!!!!!!!!! Если квадратичная сложность возникает там, где ее быть не должно (там, где она получилась случайно) - это ооооочень большая проблема,

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

Добавлено в 22:09

Цитата (ipv4 @ 10.03.2015 - 23:02)

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

Значит это узкое место и к нему не применимым вышеуказанный подход игнорирования.

Цитата (Evervess @ 9.03.2015 - 00:31)

Цитата (anikifya @ 9.03.2015 - 00:24) Цитата программ, которые вы используете на ежедневной основе (Mac OS X или Facebook) Макось или фейсбук - это программы? Где вы берете говно для своих голов А чем это не программы? Или ЯблОсь создавалась богом в течение 7 дней? А Мордокнигу завезли инопланетяне :)

сам ты яблось

Цитата (ipv4 @ 10.03.2015 - 23:02)

Однако лично я всегда оцениваю потенциальный объем данных, который будет обработан. Оцениваю на этапе проектирования, на основании того, откуда эти данные беруться.

И это уже опыт, а не Кнут. Даже если у кнута в первой главе первой строкой это написано будет.
Что и доказывает утверждение, что кнут хоть и не плох и стоит хотя бы знать кто это и что там есть, но далеко не обязателен. Потому что есть ещё опыт. Чуть дольше чем через Кнута и иногда по пальцем бьют, но результат не сильно отличается при равном старании.
А вот галочка возле "прочитал кнута" ещё ни о чем не говорит.

На хер я это читал.

Цитата (artivenom @ 10.03.2015 - 22:12)

Цитата (ipv4 @ 10.03.2015 - 23:02) Однако лично я всегда оцениваю потенциальный объем данных, который будет обработан. Оцениваю на этапе проектирования, на основании того, откуда эти данные беруться. И это уже опыт, а не Кнут. Даже если у кнута в первой главе первой строкой это написано будет. Что и доказывает утверждение, что кнут хоть и не плох и стоит хотя бы знать кто это и что там есть, но далеко не обязателен. Потому что есть ещё опыт. Чуть дольше чем через Кнута и иногда по пальцем бьют, но результат не сильно отличается при равном старании. А вот галочка возле "прочитал кнута" ещё ни о чем не говорит.

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

Добавлено в 22:23

Цитата (artivenom @ 10.03.2015 - 22:08)

Значит это узкое место и к нему не применимым вышеуказанный подход игнорирования.

А вот оценка того, что является "узким местом", и, как следствие, применимость тех или иных подходов, как раз и требует базовых знаний структур данных и алгоритмов в обязательном порядке. ))))

Цитата (ipv4 @ 10.03.2015 - 23:20)

поскольку необходимо понимать, какие алгоритмы на каких данных какую стоимость будут иметь

Кране редко, только в определённых частях определённых приложений. Конечно, если приходится работать с графами или деревьями, то это помнить надо. А так - нет, не надо. Достаточно помнить примерно что чем и от чего отличается. Я это помню не из кнута, а с лекций.

Цитата

С одной лишь разницей, что я считаю необходимость обладания базовыми знаниями обязательной, а Вы - нет

Я такого не говорил. Я говорил лишь то, что базовые знания нигде кроме как на собеседовании не встречаются. Может, конечно, я не замечал, как они сами применялись и тогда я окажусь не прав. НО 90% времени знания были не нужны и потому знать наизусть их точно не нужно. А когда были нужны - успешно гуглились. И это не тупо формошлёпание.

Это сообщение отредактировал artivenom - 10 мар 2015 в 22:28

Цитата (Кхарн @ 9.03.2015 - 21:57)

ЯВА?! Это ты так Java обозвал? Я чел не местный, но в РФ это так произносят?! Гы, Сэ++! А CSS - СэСэСэ!

Я заметил, что придираются к написанию и произношению Ява вместо Джава те, кто только недавно выучили этот язык :)
Для себя давно решил - я пишу и говорю так, как это исторически принято в русском языке: ява, а не джава, кибернетика, а не сайбернетика, ксерокс, а не зирокс, микроскоп, а не майкроскоп. Ты против? :)
Да и вообще, я там про Языки Высокого Уровня (ЯВУ) писал, а не про язык Ява.
Это сообщение отредактировал VSC - 10 мар 2015 в 22:36

Цитата

Факт 2 25% времени в программировании уходит на размышления о том, что пользователь может сделать не так.

я бы сказал - процентов на 80

Цитата (artivenom @ 10.03.2015 - 22:26)

... Может, конечно, я не замечал, как они сами применялись ...

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

Вообще, есть золотой принцип - "80:20". Имхо, применим практически ко всему, в том числе и к количеству оставшихся (и используемых) после обучения знаний. Однако, если не будет всех знаний, то что останется и будет использоваться? ))

Но это уже - лирика, ога.

P.S. А да... по поводу преждевременной оптимизации и попыток умничать там, где это не является необходимым - своим по рукам регулярно даю, причем усиленно - иногда не понимают и со второго раза. )))))))
Это сообщение отредактировал ipv4 - 10 мар 2015 в 22:40

Цитата (artivenom @ 10.03.2015 - 12:36)

5. На практике и по сути ваш приятель в чем-то прав. Стоимость 1-2 дней программиста на поиск алгоритма стоит дороже, чем новый камень для сервера. Поэтому улучшать производительность на 2-3% или даже 15% за счет неоправданной оптимизации алгоритмов экономически не обоснована.

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

не знаю как facebook, но в мэйл ру и ОК чую одни костыли - комп заметно притормаживается каждый раз

Цитата (Detech @ 9.03.2015 - 13:21)

Цитата (VSC @ 9.03.2015 - 13:18) Неправильно ты рассуждаешь: В исходнике нет ничего про "ЕЩЕ". Что за фантазеры. Там написано "КУПИ 10", а не "КУПИ ЕЩЕ 10"... Это называется "Неправильно прочитали техзадание"

Imho это называется неопределеное условие, поскольку сказано купи 10! 10 чего - колбасы или яиц? С равной вероятностью есть три решения:
1 -1 палка колбасы + 10 яиц
2 -11 палок колбасы
3 - 1 палка колбасы, после чего либо завис, либо аварийный выход

у меня была книга "128 советов программисту" 80х годов выпуска кажись...
при переезде посеял...
так там номера глав были в 16ричном формате и начинались с 0, как и положено...
Это сообщение отредактировал i13th - 11 мар 2015 в 00:14

Цитата (VSC @ 10.03.2015 - 22:28)

Я заметил, что придираются к написанию и произношению Ява вместо Джава те, кто только недавно выучили этот язык :) Для себя давно решил - я пишу и говорю так, как это исторически принято в русском языке: ява, а не джава, кибернетика, а не сайбернетика, ксерокс, а не зирокс, микроскоп, а не майкроскоп. Ты против? :)

Причем тут даты и правильное произношение? Какие-то у тебя странные причинно следственные связи. Я просто в жизни не слышал чтобы Java явой обзывали. Кощунство.
И что за херня с "исторически принятым в русском языке". Всех русскоязычных бесит слово "Борщт", однако сами все коверкают.
Так что там: ("C++" == "Сэ++" || "C++"=="Цэ++")?

Без костылей система стоять не будет, а без велосипедов не поедет ©

Цитата (iskatel2015 @ 9.03.2015 - 00:38)

Цитата (voldimar @ 9.03.2015 - 00:35) Жена посылает программиста в магазин: - Дорогой, купи, пожалуйста, палку колбасы и если будут яйца, тогда купи десяток. Через полчаса программист возвращается с десятью палками колбасы. Жена: - Что это! Зачем ты купил столько колбасы? Программист: — Ну так яйца-то были… Косяк в анекдоте то. Он с 11 палками колбасы должен был прийти.

к следующему релизу баг поправят))а то тестеры нашли)))