IT в России и мире в реалиях мирового кризиса

Цитата: Superwad от 17.01.2017 10:30:56Я просто привел пример, что даже в мире С/С++ не все так однозначно. Ведь идет пропаганда того, что С++ - это улучшенный С.

С мире C и C++ все однозначно. Более однозначно, чем в мире С и С++, только в мире АДА. Есть стандарт как на С, так и на С++. Стандарты эти реализованы чуть менее, чем полностью, в отличи от остального зоопарка. Просто нужно понимать, что C и C++ -- языки, основой которых вляются выражения. В этом их главное отличие от таких операторных языков, как АДА, фортран, паскаль и даже бейсик. Это различие является формирующим базовое мышление программиста.
Я знаю достаточно людей, которые начинали с операторных языков, типа фортрана, паскаля, клариона и даже PL/1. Знаю и тех, кто начинал с основаных на выражения Си и лиспа. Причем начинали программистскую деятельность не методом бродячей мысли у себя под кроватью, а целенаправленно, на профессиональных курсах с отрывом от производства под существующие на тот момент реальные задачи. В результате все программисты разбились на две группы -- наСИльники и неоСИляторы. Вне зависимости от того, на чем им нравится писать больше всего. Однако, замечено, что те, кому по долгу службы пришлось писать на лиспе (разную фигню для автокада, например), в конце концов переползли с "любимого" трубопаскаля на си. Сначала на борланд, потом на нормальный. Обратного процесса наблюадть не пришлось.

Цитата: adolfus от 20.01.2017 13:59:27С мире C и C++ все однозначно. Более однозначно, чем в мире С и С++, только в мире АДА. Есть стандарт как на С, так и на С++. Стандарты эти реализованы чуть менее, чем полностью, в отличи от остального зоопарка. Просто нужно понимать, что C и C++ -- языки, основой которых вляются выражения. В этом их главное отличие от таких операторных языков, как АДА, фортран, паскаль и даже бейсик. Это различие является формирующим базовое мышление программиста.
Я знаю достаточно людей, которые начинали с операторных языков, типа фортрана, паскаля, клариона и даже PL/1. Знаю и тех, кто начинал с основаных на выражения Си и лиспа. Причем начинали программистскую деятельность не методом бродячей мысли у себя под кроватью, а целенаправленно, на профессиональных курсах с отрывом от производства под существующие на тот момент реальные задачи. В результате все программисты разбились на две группы -- наСИльники и неоСИляторы. Вне зависимости от того, на чем им нравится писать больше всего. Однако, замечено, что те, кому по долгу службы пришлось писать на лиспе (разную фигню для автокада, например), в конце концов переползли с "любимого" трубопаскаля на си. Сначала на борланд, потом на нормальный. Обратного процесса наблюадть не пришлось.

Вы извините, что я вмешиваюсь в ваш разговор...не то, что я против вашей точки зрения, но хочу уточнить.

Об однозначности "в мире С" давайте говорить после ответа на вопрос: "Какое максимальное число можно записать в переменную int?" (сколько бит?) А потом поговорим о поддерживаемых операциях с плавающей запятой (есть даже Floating-point paranoia - программа, позволяющая проверить всю связку от "компилятора до железа" на предмет соответствия стандарту IEEE 754 представления и результатов разных операций для этих чисел). Так что, "не всё так однозначно. Поверьте - я сама дочь компилятора и процессора"

Единственная (или "одна из" - я не полиглот программирования) платформа, на которой действительно можно написать программу и запускать её на разных архитектурах процессоров и разных устройствах - Java. Но даже с ней там столько ньюансов, что всё равно неопытный программист не сможет написать программу, которая одинаково ведет себя во всех поддерживаемых средах (я про реальную программу, а не про hello world).

Цитата: ping от 22.05.2008 20:28:49Впечатление от статьи ниже среднего. То, что в России одна из лучших школ программирования (что бы под этим ни понимали) - без вопросов. Но называть ВСЕ приведенные автором компании российскими?\n\n
Рейтинг IAOP:
http://www.outsourci…/184/1197/

EPAM Systems. http://www.epam-grou…ations.htm
Штаб-квартира в Штатах. Интервью президента EPAM, в т.ч. на счет аутсорсинга. http://epam.by/about…2-2007.htm

Luxoft. http://www.luxoft.co…sheet.html
Штаб-квартира в Москве.

Auriga. http://www.auriga.co…auriga.php
"Headquartered in USA since 1993
5 Engineering centers in Russia (3 in Moscow, 1 in Kazan & 1 in Nizhny Novgorod)" Штаб-квартира в Штатах.

Reksoft в списках не значится.

Mera NN. http://www.meranetwo…_group.php
На самом деле "Группа компаний MERA".
Штаб-квартира в Нижнем Новгороде.

DataArt. http://www.dataart.com/company/dataart/
"DataArt Fact Sheet
Years in business - since 1997 (Date of incorporation Apr-30)
Shareholders - active managers
Ownership/legal form - C-Corporation (Headquarters - New York, US)"
Штаб-квартира в Нью-Йорке.

Хоть и не спорю, что все эти компании имеют офисы, в том числе разработчиков, в России. В общем, статья - низачот..

В Украине есть SerfCompany, в которой работают квалифицированные, талантливые программисты  http://serfcompany.com/

Цитата: DarkRaider от 20.01.2017 22:07:53Для хорошего программиста - это пустышка, так как хорошо усвоив принципы программирования - уже не важно на чём писать, будь то язык, процессор, платформа. Не более чем "+неделя на чтение спецификации".

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

Цитата: Oleg K. от 20.01.2017 15:10:57Об однозначности "в мире С" давайте говорить после ответа на вопрос: "Какое максимальное число можно записать в переменную int?" (сколько бит?) А потом поговорим о поддерживаемых операциях с плавающей запятой (есть даже Floating-point paranoia - программа, позволяющая проверить всю связку от "компилятора до железа" на предмет соответствия стандарту IEEE 754 представления и результатов разных операций для этих чисел). Так что, "не всё так однозначно. Поверьте - я сама дочь компилятора и процессора"

Единственная (или "одна из" - я не полиглот программирования) платформа, на которой действительно можно написать программу и запускать её на разных архитектурах процессоров и разных устройствах - Java. Но даже с ней там столько ньюансов, что всё равно неопытный программист не сможет написать программу, которая одинаково ведет себя во всех поддерживаемых средах (я про реальную программу, а не про hello world).

А ничего, что и процессоров, которые оперировали байтами, не кратными 8 было вполне товарное количество. И порядок следования битов в байте... До сих пор в каждом стеке TCP/IP есть функции преобразования. А уж форматов плавающей точки было разработано по 4-8 вариантов на каждую архитектуру процессора. Это потом их уже попытались стандартизировать.
Ну а теперь попытаемся прикинуть, какова цена Жавы и прочего Дотнета (список немалый). Мой древний наладонник на PalmOs (Еще на древнем 68ххх) работает порой быстрее, чем смартфон на Андроиде с ДВУМЯ ГИГАМИ памяти. И за счет черно-белого экрана готов был работать от одного комплекта батареек недели. Мой древний Гармин 60CSx от двух "пальчиков" работает 18 часов в режиме непрерывной навигации без выключения цветного экрана. Правда, без подсветки. Именно цветной экран без подсветки (и водозащита IPX7). Какой смарт это сможет?
"Облачные" клиенты, типа Гугл Диск занимают мегабайты, хотя клиент Novell Netware в свое время занимал килобайты... А функциональность слишком увеличилась? Судя по всему, современные смартфоны-флагманы должны бы уже кофе в постель подавать. А вот нет, Жава, предназначенная для утилизации избыточной мощности процессора и объема памяти.
И какие перспективы с таким подходом? Я не вижу значительного улучшения при переходе с Pentium Dual Core (2 GB) на i5 (8GB). А у меня еще комп есть с 512 MB... По крайней мере, пропорционально цене. Сразу замечу, что в игрушки не играю. Впрочем, производители игрушек остались в рядах немногих, кто оптимизацией приложений как раз занимается.

Цитата: Oleg K. от 20.01.2017 15:10:57Об однозначности "в мире С" давайте говорить после ответа на вопрос: "Какое максимальное число можно записать в переменную int?" (сколько бит?)

Ваш вопрос свидетельствует о том, что Вы просто не в курсе относительно интегральных типов языка си.
Точный ответ на Ваш вопрос, согласно стандарта, содержится в файле &ltclimits&gt(limits.h). Число это равно MAX_INT и зависит от платформы.
Наряду с "широкоизвестными" со времен k&r интегральными типами int, short и long в си стандартно поддерживаются типы с точной длиной (exact_width integral types). Описаны они в стандартном заголовке  &ltcstdint&gt(stdint.h). Вводятся они как typedef от встроенных типов соответствующей длины для конкретной платформы, поэтому ничем не отличаются от встроенных по функциональности и эффективности -- они все всегда поддержаны максимально аппаратно.
Насчет поддержки IEEE754 курим  &ltcfenv&gt(fenv.h), &ltcfloat&gt(float.h), &ltcmath&gt(math.h).
Насчет законов Мерфи -- если есть хоть какой-нибудь способ налететь на грабли, всегда найдется тот, кто на них наступит. Так что все защиты от дурака, типа сборщиков мусора и ран-таймовой проверки границ и типов, на самом деле ни от чего не гарантируют -- они просто позволяют побыстрее выкатить на суд заказчика прототип. Не продукт, а прототип. Продукт, если это не хелловорлд, с таким подходом будет едва шевелиться или упадет по нехватке памяти.

Цитата: adolfus от 21.01.2017 03:26:08P.S. Какая-то фигня с угловыми скобками -- они и все, что внутри них, съедается.

< и > проходит нормально: <текст>

Цитата: adolfus от 21.01.2017 03:26:08Насчет законов Мерфи -- если есть хоть какой-нибудь способ налететь на грабли, всегда найдется тот, кто на них наступит. Так что все защиты от дурака, типа сборщиков мусора и ран-таймовой проверки границ и типов, на самом деле ни от чего не гарантируют -- они просто позволяют побыстрее выкатить на суд заказчика прототип. Не продукт, а прототип. Продукт, если это не хелловорлд, с таким подходом будет едва шевелиться или упадет по нехватке памяти.

Тут недавно приводили пример с двигателем на капремонт Боинга. Сертифицированный завод, опытные специалисты - умудрились сделать ремонт. обкатать и почти отгрузить потребителю, если бы не зоркий менеджер не обнаружил СЛУЧАЙНО на складе лишние трубки, снятые при разборке и отправленные на склад для хранения.
Так что закон Мерфи никто не отменял, он только подтверждается жизнью, как для начинающих, так и для новичков.
Насчет С++ уже сказал, все красиво на бумаге. да забыли про овраги (с). Почему в жизни так хреново с С++? Почему сей процесс перешел кто в лес, кто по дрова? Получается, что гайка, произведенная у одного производителя на одном оборудовании не стыкуется с болтом произведенным на другом заводе, хотя стандарт один?
Повторяется история ВМВ, когда двигатели из Англии для самолетов в Америке не стыковались - хотя стандарт был один, но оказалось, что у каждого свой размер дюймов

Цитата: Superwad от 21.01.2017 10:13:59Тут недавно приводили пример с двигателем на капремонт Боинга. Сертифицированный завод, опытные специалисты - умудрились сделать ремонт. обкатать и почти отгрузить потребителю, если бы не зоркий менеджер не обнаружил СЛУЧАЙНО на складе лишние трубки, снятые при разборке и отправленные на склад для хранения.
Так что закон Мерфи никто не отменял, он только подтверждается жизнью, как для начинающих, так и для новичков.
Насчет С++ уже сказал, все красиво на бумаге. да забыли про овраги (с). Почему в жизни так хреново с С++? Почему сей процесс перешел кто в лес, кто по дрова? Получается, что гайка, произведенная у одного производителя на одном оборудовании не стыкуется с болтом произведенным на другом заводе, хотя стандарт один?
Повторяется история ВМВ, когда двигатели из Англии для самолетов в Америке не стыковались - хотя стандарт был один, но оказалось, что у каждого свой размер дюймов

Надо заметить что мало кто пишет на каком-либо языке с чистого листа. Все пишут используя библиотеки ( libs, ddl, mfc и прочие framework ) тем самым наследуя их производительность, а заодно и блохастость. Неумеренный рост памяти и прочих ресурсов обусловлен в первую очередь использованием универсальных библиотек, стремящихся объять всё им слегка известное. В немалой степени этому способствуют многоуровневые зависимости объектных классов написанных по принципу: нужна "лягушка" - загружай все "джунгли".

Цитата: adolfus от 21.01.2017 03:26:08Ваш вопрос свидетельствует о том, что Вы просто не в курсе относительно интегральных типов языка си.
Точный ответ на Ваш вопрос, согласно стандарта, содержится в файле (limits.h).

Ну так ответьте мне, "сколько вешать в граммах" Чему равно максимально возможное число, которое можно записать в int ? Вот мне нужно считать суммы до 10 миллиардов. int-а хватит? А long-а?

В Java это значение равно +2 147 483 647 (хоть на Windows CE запускайте, хоть на sparc-ах). А в C сколько?

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

Цитата: Valery от 20.01.2017 23:37:52А ничего, что и процессоров, которые оперировали байтами, не кратными 8 было вполне товарное количество. И порядок следования битов в байте... До сих пор в каждом стеке TCP/IP есть функции преобразования. А уж форматов плавающей точки было разработано по 4-8 вариантов на каждую архитектуру процессора. Это потом их уже попытались стандартизировать.
Ну а теперь попытаемся прикинуть, какова цена Жавы и прочего Дотнета (список немалый). Мой древний наладонник на PalmOs (Еще на древнем 68ххх) работает порой быстрее, чем смартфон на Андроиде с ДВУМЯ ГИГАМИ памяти. И за счет черно-белого экрана готов был работать от одного комплекта батареек недели. Мой древний Гармин 60CSx от двух "пальчиков" работает 18 часов в режиме непрерывной навигации без выключения цветного экрана. Правда, без подсветки. Именно цветной экран без подсветки (и водозащита IPX7). Какой смарт это сможет?
"Облачные" клиенты, типа Гугл Диск занимают мегабайты, хотя клиент Novell Netware в свое время занимал килобайты... А функциональность слишком увеличилась? Судя по всему, современные смартфоны-флагманы должны бы уже кофе в постель подавать. А вот нет, Жава, предназначенная для утилизации избыточной мощности процессора и объема памяти.
И какие перспективы с таким подходом? Я не вижу значительного улучшения при переходе с Pentium Dual Core (2 GB) на i5 (8GB). А у меня еще комп есть с 512 MB... По крайней мере, пропорционально цене. Сразу замечу, что в игрушки не играю. Впрочем, производители игрушек остались в рядах немногих, кто оптимизацией приложений как раз занимается.

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

Я уже писал тут, что хороших программистов, которые смогут писать на языке С под разные архитектуры хотя бы под одну архитектуру - чтобы приложение не сегфолтилось, нет в достаточном количестве. А бизнес-задач от "сделайте мне кнопку василькового цвета" до "сводный отчет должен выгружаться с текущими настройками фильтров в форматах xls, pdf, html, csv" - крайне много. Так что получилось то, что получилось.

С андройдом - да вы посмотрите, скольких разработчиков "загнали" на эту платформу. Ради этой массовости они и взяли Java. В итоге - тормозит, просто ужас (по сравнению с нативным исполняемым кодом). Зато гибкость использования - на очень высоком уровне (ни на одном другом телефоне я бы не смог реализовать всё то, что сейчас у меня есть). Думаю, что если бы надо было писать на С - андроид не стал бы таким простым в установке на разные телефоны (а аппаратный зоопарк там - просто тихий ужас, если вы вдруг не в курсе) и не обрел популярности, потому что просто в мире команды разработчиков не смогли бы написать столько приложений для всех этих Х-маркетов.

Цитата: Oleg K. от 21.01.2017 22:03:40По выделенному - я про то самое и говорю. Аппаратная часть очень сложная и разнообразная - поэтому писать портируемые программы крайне непросто - надо быть хорошим программистом.

Ну, тут нужны очень хорошие программисты, которые напишут ядро операционной системы так, что HAL будет работать адекватно. И вот с этим уже начинаются проблемы... Дефицит. И Линукс тоже является подтверждением тому. Да и не только...
Уважаемая мной OpenVMS писалась с использованием Macro-32/64 и BLISS-32/64. При портировании на Itanium стали использовать C++. В результате RX8640 значительно отстает по вводу-выводу от устаревшей GS1280(Alpha). Минимальные требования к памяти в два раза меньше, чем для HP/UX или Линукс  при любой архитектуре. Мой древнющий AlphaServer с 256 MB памяти вполне живет с последней версией VMS (там и 64 хватило бы в притирку). Кстати, модель написания драйверов почти не менялась со времен VAX...
На счет Андроида - сейчас есть ARM и x86/64. Скомпилировать два проекта на С - невелика проблема. Ленятся люди руками и головой писать программы... Все больше ногами и ягодицами... И сей подход стимулируется кошельком.

Цитата: Oleg K. от 21.01.2017 21:49:24Ну так ответьте мне, "сколько вешать в граммах" Чему равно максимально возможное число, которое можно записать в int ? Вот мне нужно считать суммы до 10 миллиардов. int-а хватит? А long-а?

Еще раз повторю -- точное значение того, "сколько помещается в int" приведено в limits.h.
Второе -- Вам нужно более внимательно читать посты, прежде чем рефлексировать. Никто не пользуется встроенными интегральными типами  для хранения "чтобы поместилось 10 миллиардов". Не для этого они в языке. Даже коза знает, что для того, чтобы "поместилось 10 миллиардов" нужно использовать типы данных из stdint.h. Например, uint_least64_t. Переменная этого типа гарантировано удержит 2^{64}-1. Это больше, чем 10 миллиардов миллиардов. И это СТАНДАРТ.

Цитата: Valery от 22.01.2017 00:57:40Ленятся люди руками и головой писать программы... Все больше ногами и ягодицами... И сей подход стимулируется кошельком.

Так всегда было три источника марксизма: цена железа, цена черного кодера, и цена Программиста.

В начале 90-х, был явный недостаток вычислительных мощностей - люди читали Кнута. Потом ситуация изменилась, стали читать Брукса.
Сейчас уже и не знаю, что читают.

Цитата: Hadan от 22.01.2017 11:55:32В начале 90-х, был явный недостаток вычислительных мощностей - люди читали Кнута.

У нас, причём достаточно недолго. Тогда валом пошли с Запада старые 286-е, и ситуация "XT c EGA за $1000" сменилась на "AT c VGA за $100". Но трёшки-четвёрки оставались ещё далеко за пределами возможного.
К середине 90-х перешли в сферу доступных 486-е, а к концу мы вообще с остальным миром по персоналкам выровнялись.

Цитата: Oleg K. от 21.01.2017 22:03:40Я уже писал тут, что хороших программистов, которые смогут писать на языке С под разные архитектуры хотя бы под одну архитектуру - чтобы приложение не сегфолтилось, нет в достаточном количестве.

Сегфолт -- это позор для программиста. Это как на людях обосраться, что аж в ботинки затекло. Идешь, и чавкаешь с каждым шагом, оставляя желтые и вонючие следы.
Чтобы не сегфолтилось, достаточно использовать valgrind или аналог под винды, если софт пишется под MSVC. Собственно, все, что с памятью не так, отлично отлавливается. Просто нужно не лениться.

Цитата: DarkRaider от 22.01.2017 11:28:25Уважаемый, Oleg_K, Вы, просто подменяете понятия. Назначение JAVA-машины  - реализация универсальной программы на текущей платформе. В случае JAVA-машины "платформа"="операционная система", так как аппаратными ресурсами заведует ОС. Посему жаба в данном случае не более чем прокладка. А единообразность исполнения программы обязана обеспечивать целевая операционная система (в обсуждаемом случае - Андроид). Другой вопрос, как говённо она это делает, кроме "качества" кода это ни о чём не говорит. Поэтому если бы вы писали нативный код под Андроид на C он должен бы был исправно работать на любом аппаратном железе, если на нём нормально встаёт этот Андроид.

К слову, про "размер int'а"  Вы тоже зря беспокоитесь. Совершенно не обязательно, что "максимальное целое число" которое аппаратно поддерживает железная основа (то есть разрядность процессора)  обязательно равно максимальному числу, которым может оперировать программист.   Int64 уже давным давно есть во всех современных языках, как и беззнаковый тип (cardinal, uint64)  и как то с такими числами работают даже 32битные "платформы"...   просто им на загрузку данных такого числа нужно 2 такта вместо 1го.   К слову, когда программист не знает границ данных, он сам ДОЛЖЕН использовать максимально доступный тип и в данном случае, сокращение типа до int32 - будет оптимизацией (меньше выделенной памяти)  если в процессе работы он понимает, что диапазон избыточен.

К сожалению, не понял, где вы углядели подмену...
1. Язык Java и разработка на нем намного проще, чем C. Поэтому порог вхождения и стоимость подготовки специалиста - ниже (и требования тоже ниже). И это востребованно рынком.
2. Про размер int-а я написал только для того, чтобы обратить внимание на сложность переноса программ, написанных на C, на разные платформы. Порядок байт, работа с float и прочее - там много всего появляется... "Максимальное число" - отсюда же. Конечно, я знаю, что можно использовать библиотеки и структуры, которые будут работать с нужной мне точностью (хоть до квинтиллионов, хоть больше). В Java проблем с переносом возникает намного меньше.

P.S. В первом абзаце про андроид - там совсем всё не так, как вы написали. Ну или термины просто неудачные подобрали и я не понял вашей мысли.

Цитата: adolfus от 22.01.2017 09:37:12Еще раз повторю -- точное значение того, "сколько помещается в int" приведено в limits.h.
Второе -- Вам нужно более внимательно читать посты, прежде чем рефлексировать. Никто не пользуется встроенными интегральными типами  для хранения "чтобы поместилось 10 миллиардов". Не для этого они в языке. Даже коза знает, что для того, чтобы "поместилось 10 миллиардов" нужно использовать типы данных из stdint.h. Например, uint_least64_t. Переменная этого типа гарантировано удержит 2^{64}-1. Это больше, чем 10 миллиардов миллиардов. И это СТАНДАРТ.

Вот в том числе и поэтому "вхождение" в С сложнее и дольше, чем в Java - типов данных больше, в голове держать данных нужно больше (указатели, арифметика с ними, не забыть освободить память, не выйти за границы массива). Где я вам таких найду при ограниченном бюджете?
Вы почему-то доказываете, что на С можно писать переносимые программы - с этим я и не спорю. Я лишь уточняю, что получить достаточный уровень навыков для этого намного сложнее, чем в случае Java.

Цитата: Oleg K. от 22.01.2017 22:50:39Вы почему-то доказываете, что на С можно писать переносимые программы - с этим я и не спорю. Я лишь уточняю, что получить достаточный уровень навыков для этого намного сложнее, чем в случае Java.

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

Владение языком -- незначительная часть тех навыков, котороые необходимы, чтобы писать программы вообще, а не только переносимые. Можно освоить несколько языков и при этом не научиться программировать. Язык -- это всего лишь инструмент. Чтобы научиться его применять эффективно и с пользой нужно на порядок более знаний и умений, чем просто освоить язык. Немногим выше был упомянут Брукс. На сегодня его тезис о том, что в программной индустрии нет серебряной пули, остается в полной мере справедливым.

Цитата: folk от 23.01.2017 09:11:52А как надо чтобы не переписывать? Очень интересно - полностью отказаться от ООП? Тогда это камень и в сторону C++. Развейте идею пожалуйста.

Самому садиться на winmain )))

Это же так весело, вместо обработки нажатия на объект кнопка таскаться по кейсам )