Так я уже писал о том, что не вижу ключевой разницы между этими языками...
Andron'у: когда месье "практик" закончит учебу и напишет хотя бы одну работающую программу, тогда появятся разумные аргументы... переход на оскорбления случается всегда, когда сказать нечего, а очень хочется.
Andron'у: когда месье "практик" закончит учебу и напишет хотя бы одну работающую программу, тогда появятся разумные аргументы... переход на оскорбления случается всегда, когда сказать нечего, а очень хочется.
диагнозы по фотографии?
эт я люблю!
чтобы начать вообще хоть немного понимать, что же за зверь такой - разработка ПО, рекомендую почитать книгу С. Макконела "Совершенный код".
эт я люблю!
чтобы начать вообще хоть немного понимать, что же за зверь такой - разработка ПО, рекомендую почитать книгу С. Макконела "Совершенный код".
Metal kыnG
veteran
диагнозы по фотографии?для начала нужно написать пару среднеразмерных проектов чтобы наступить на все возможные грабли. А после этого для нетривиальных алгоритмов рука тянется начать с блок-схемы
эт я люблю!
чтобы начать вообще хоть немного понимать, что же за зверь такой - разработка ПО, рекомендую почитать книгу С. Макконела "Совершенный код".
Petrovichalt
activist
Извините, что не в тему, возможно кому-нибудь пригодится данная книга
kotjarko
member
(ответ на изначальный вопрос)
Вообще сейчас у нас ассемблер применяется больше при разработке устройств на МК:
http://rabota.ngs.ru/vacancies/10354595/
http://rabota.ngs.ru/vacancies/10368123/
http://rabota.ngs.ru/vacancies/10368864/
http://rabota.ngs.ru/vacancies/10366893/
Хотя на мой взгляд Сишник тоже должен знать основы (для лучшего понимания своих действий)
:)Это РНРшнику пофиг как и зачем работает компьютер ;-)
PS (да-да студент, в будущем специалист по МК/ПЛИС/Электронике, да-да реального опыта почти нет).
Вообще сейчас у нас ассемблер применяется больше при разработке устройств на МК:
http://rabota.ngs.ru/vacancies/10354595/
http://rabota.ngs.ru/vacancies/10368123/
http://rabota.ngs.ru/vacancies/10368864/
http://rabota.ngs.ru/vacancies/10366893/
Хотя на мой взгляд Сишник тоже должен знать основы (для лучшего понимания своих действий)
:)Это РНРшнику пофиг как и зачем работает компьютер ;-)PS (да-да студент, в будущем специалист по МК/ПЛИС/Электронике, да-да реального опыта почти нет).
А теперь сравни зп в вакансии, и зп пхп-шника. Зп пхп-шника получится больше в два раза. Какой из этого вывод?
Сейчас читают
Приветы ВЕСНЫ 2013!!!
412922
1000
Просчет или рассчет?
59389
460
Лечение зубов под общим наркозом
4981
13
Вывод: все-все-все переквалифицируемся в РНРшников, остальные не нужны:)
А если серьезно - РНРшники тоже в среднем 15-25т, больше - это крупные компании с очень серьезными требованиями (Parallels, etc)
:)А если серьезно - РНРшники тоже в среднем 15-25т, больше - это крупные компании с очень серьезными требованиями (Parallels, etc)
15-25 Это все таки не особо опытные пхп-шники, а для ассемблерщиков это фактически потолок.
А теперь сравни з/п пхпшника и один-эсника. Похоже программированием у нас зарабатывать только на 1-ass можно
15 тыр — это даже для HTML-верстальщика маловато, для пхписта явно мало. Для нормального тем более.
BWhite, я сделал эти цифры так же как и раньше - поиском по вакансиям ))
Реально для специалиста по МК/Эмбеддед это тоже очень мало
Реально для специалиста по МК/Эмбеддед это тоже очень мало
Да я и не спорю, что мало. У меня образование ближе как раз к железякам и Ассемблеру. Только работа по специальности только как по этим ссылкам — с весьма приличным опытом да зачастую на сомнительную зарплату.
15-25 Это все таки не особо опытные пхп-шники, а для ассемблерщиков это фактически потолок.Да к сожалению это так, но как мне кажется все дело из-за накладных расходов (ну и естественно жадности руководства), как правило низкоуровневое программирование для микроконтроллеров, DSP, сопровождается разработками, плат, испытаниями, а если к примеру разработка идет в области силовой электроники, например система управления инвертором, для асинхронного двигателя (сама задача достаточно интересная и сложная), то неизбежны неудачные испытания, когда все горит и взрывается. И соответственно для выпуска изделия нужны, программист, электронщик, конструктор, снабженец, монтажник/наладчик, инженер по ТБ.
А если разрабатывать, какое ни будь дестопное приложение, то нужен программист, компьютер и тестер, и в случае ошибки в программе, максимум она упадет и в самом тяжелом случае придется переставить ОС.
А теперь сравни з/п пхпшника и один-эсника. Похоже программированием у нас зарабатывать только на 1-ass можноесли пхп-шник толковый то зарплаты сравнимы.
Хмм... Думаю всё же не совсем так. Программы разные бывают. Какая-то упадёт — не беда. А падение какой-то чревато катастрофой или потерей огромной кучи денег. Что ж вы так под одну гребёнку?
Скорее тут дело в строго экономической стороне вопроса. Как там... Кривые спроса и предложения? Чем больше спрос на товар, тем больше за него цена. На 1С-ников спрос большой, поэтому и платят им много. На джедаев, знающих Ассемблер, если верить сайтам с вакансиями, спроса кот наплакал — работодателям незачем заманивать специалистов именно к себе большими зарплатами. Предложение же очевидно спрос превышает, отсюда и суровые требования к опыту имхо.
Скорее тут дело в строго экономической стороне вопроса. Как там... Кривые спроса и предложения? Чем больше спрос на товар, тем больше за него цена. На 1С-ников спрос большой, поэтому и платят им много. На джедаев, знающих Ассемблер, если верить сайтам с вакансиями, спроса кот наплакал — работодателям незачем заманивать специалистов именно к себе большими зарплатами. Предложение же очевидно спрос превышает, отсюда и суровые требования к опыту имхо.
Отсюда возникает забавная ситуация - знаю людей, которые пишут программы для важных объектов. Программа если не сработает правильно может нанести многомиллионный ущерб. Однако зп у них много ниже обычных пхп-ников.
Вот и людям этим в итоге приходиться переквалифицироваться :), а работодатели потом удивляются, но зп не повышают.
Но это я так офтоп , про то что мир не справедлив.
Вот и людям этим в итоге приходиться переквалифицироваться :), а работодатели потом удивляются, но зп не повышают.
Но это я так офтоп , про то что мир не справедлив.
Хмм... Думаю всё же не совсем так. Программы разные бывают. Какая-то упадёт — не беда. А падение какой-то чревато катастрофой или потерей огромной кучи денег. Что ж вы так под одну гребёнку?Я имел ввиду стадию разработки и отладки, а не эксплуатации.
Скорее тут дело в строго экономической стороне вопроса. Как там... Кривые спроса и предложения? Чем больше спрос на товар, тем больше за него цена. На 1С-ников спрос большой, поэтому и платят им много. На джедаев, знающих Ассемблер, если верить сайтам с вакансиями, спроса кот наплакал — работодателям незачем заманивать специалистов именно к себе большими зарплатами. Предложение же очевидно спрос превышает, отсюда и суровые требования к опыту имхо.
А насчет спроса, по идеи и джедаев которые знают совершенстве asm, несколько архитектур, различных низкоуровневых фишек, с опытом, к примеру написания BSP для какой ни будь RTOS тоже должно быть мало.
Согласен. Ужасно несправедлив, к сожалению.
Насчет 1С тут не совсем правы. Одно только разбирательство идиотского кода самих разработчиков 1С для исправления их же ошибок - стоит хороших денег, особенно когда у клиента горит отчетность. А они кстати ошибки свои исправлять не сильно торопятся 
Ну а спецы по асму по моему в обиду себя не дают. Если задаться вопросом кто больше всех пишет вирусы, взламывает банки и сети и тому подобное.. Насколько я понимаю без асма в этом деле далеко не уедешь.
Ну а спецы по асму по моему в обиду себя не дают. Если задаться вопросом кто больше всех пишет вирусы, взламывает банки и сети и тому подобное.. Насколько я понимаю без асма в этом деле далеко не уедешь.
Насколько я понимаю без асма в этом деле далеко не уедешь.Очень даже уедешь... Абсолютное большинство вирусов написано на языках высокого уровня.
А касабельно 1С - сейчас типовые конфиги более-менее вылизаны.
В последнем обновлении ЗУП было исправлено 148 ошибок. Вопрос: сколько они ЕЩЕ не исправили и сколько они ЕЩЕ сделали этих самых ошибок?
Хорошая вылизанность!!!
На счет языков высокого уровня - конечно можно написать вирус и на них, но результат на Ассемблере будет намного выше, а что касается взлома, то на Ассемблере можно вообще делать все, на языках высокого уровня лишь частично.
Хорошая вылизанность!!!
На счет языков высокого уровня - конечно можно написать вирус и на них, но результат на Ассемблере будет намного выше, а что касается взлома, то на Ассемблере можно вообще делать все, на языках высокого уровня лишь частично.
Про ЗУП в курсе. Но ошибки там не критические были и в основном не влияли на работу пользователей.
А ассемблер хорошо использовать в виде кусков программы, критичных по времени и ресурсам. Весь проект на асме ваять - это застрелиццо.
А ассемблер хорошо использовать в виде кусков программы, критичных по времени и ресурсам. Весь проект на асме ваять - это застрелиццо.
Metal kыnG
veteran
На счет языков высокого уровня - конечно можно написать вирус и на них, но результат на Ассемблере будет намного выше, а что касается взлома, то на Ассемблере можно вообще делать все, на языках высокого уровня лишь частично.... имел счастье поиграться с исходником одного распространенного трояна... для винды вы будете не столько писать красивый полиморфный код ... сколько через разные OLE DDE тырить пароли и номера из сессий эксплорера. асм используется но очень мало и в ядре.
craxx
рыжий котэ
что за троян и на чем написан, если не секрет?
Про ЗУП в курсе. Но ошибки там не критические были и в основном не влияли на работу пользователей.Они там не были они до сих пор есть! И что значит не критические когда летит полностью отчетность, или в вдруг начинают всплывать договорники аж с 2007 года.
Вообще такое впечатление, что это есть антикризисная программа для франчей. Сколько бабла срубят на всякие вызовы и консультации.
На счет языков высокого уровня - конечно можно написать вирус и на них, но результат на Ассемблере будет намного выше, а что касается взлома, то на Ассемблере можно вообще делать все, на языках высокого уровня лишь частично.Что можно сделать на ассемблере, чего нельзя сделать на Си ?
Насчет вирусов не знаю (поскольку не интересно), но вот всякие классические алгоритмы (сортировки, хеши, RSA)реализованные на Си, компилятором qcc, под ARM9 для ОС Linux, и MVS2005 для WinCE, а потом дизассемблированные, выглядели очень нормально(просто был спор на работе, и даже решалось на чем писать именно алгоритмы)
Если сравнивать производительность сгенерированного кода С++ и написанного в ручную на ассемблере, грамотным программистом, да пожалуй тут я бы поставил на ассемблер, а вот с чистым Си, будет примерно одинаково.
если отключить в компиляторе фичи С++ типа RTTI, то результат по скорости будет аналогичен С.
если отключить в компиляторе фичи С++ типа RTTI, то результат по скорости будет аналогичен С.Если не использовать полиморфизм, не вызывать виртуальные функции.
Еще прикинуть, а нужен ли этот мифический выигрыш в скорости. И каков он. Т.е насколько часто и долго в исполнении кода используются фишки того же c++, ну и что что вызываются виртуальные функции, если вызов функции по сравнению со временем ее исполнения меньше на 2 порядка. А то получится, что отказываясь от тех же плюсов выигрыш по скорости будет к примеру меньше 5% и в абсолютном выражении время исполнения запроса будет например на менее чем 1мс быстрее. А реально надо ли это кому-нибудь?
В устройствах реального времени за каждую микросекунду все же сражаются.
Я могу ошибаться, так как не спец в программировании таких устройств и вообще ассемблер изучал только будучи студентом. Но наверное изначально все таки ставится некоторое требование к устройству (кол-во запросов в сек, пропускная способность и проч.) а уж потом эта задача решается, а там уже становится понятно биться ли за каждую микросекунду (возможно и биться - чем проще/медленней железо, тем более серьезные требования к оптимизации софта). Может проще и дешевле железо помощнее купить. Просто из любви к искусству мало кто будет биться за быстродействие.
Еще прикинуть, а нужен ли этот мифический выигрыш в скорости. И каков он. Т.е насколько часто и долго в исполнении кода используются фишки того же c++, ну и что что вызываются виртуальные функции, если вызов функции по сравнению со временем ее исполнения меньше на 2 порядка. А то получится, что отказываясь от тех же плюсов выигрыш по скорости будет к примеру меньше 5% и в абсолютном выражении время исполнения запроса будет например на менее чем 1мс быстрее. А реально надо ли это кому-нибудь?Ну понятно, что к примеру функционал который выполняет запрос к БД, вообще нет смысла писать на ассемблере, да и на чистом Си. Кстати что характерно, и само ядро СУБД в принципе тоже нет смысла писать на ассемблере и Си (у нас на работе идет разработка СУБД для gis-систем).
Ну тут вроде как товарищи за каждую микросекунду сражаются. Хотя когда я закончил НГТУ, немного занимался силовой электроникой в частности писал программу для системы управления инвертором, так там в основном на 99 % использовался чистый Си, и как раз борьба шла за каждую микросекунду, и алгоритмы, и математика там были достаточно сложные, но вроде все справлялось и работало.
Как мне кажется если уж разговор идет об RTOS, в целом Си- шный код вполне предсказуемый в плане генерирования ассемблера. Плюс оптимизаторы с ним неплохо справляются.
само ядро СУБД в принципе тоже нет смысла писать на ассемблере и СиА на чём пишете? Думаю не особо тайно
Если нужна обработка данных в реальном времени, то субд вполне себе используют, например, объектные, написанные на С.
На C++само ядро СУБД в принципе тоже нет смысла писать на ассемблере и СиА на чём пишете? Думаю не особо тайно
Случайно набрел на ссылку:
http://ru.wikipedia.org/wiki/NOD32
Ключевые слова:
Большая часть кода антивируса NOD32 написана на языке ассемблера, поэтому для него характерно малое использование системных ресурсов и высокая скорость проверки с настройками по умолчанию.
Так сказать БЕЗ КОММЕНТАРИЕВ!
http://ru.wikipedia.org/wiki/NOD32
Ключевые слова:
Большая часть кода антивируса NOD32 написана на языке ассемблера, поэтому для него характерно малое использование системных ресурсов и высокая скорость проверки с настройками по умолчанию.
Так сказать БЕЗ КОММЕНТАРИЕВ!
Ну понаписали... Да понятно оно, что когда знаешь и умеешь - оно всё "несложно", а когда забыл, да еще и не знал, а только слышал - то точно "труба". Народ, который писал, если Ассемблером и пользовался, то только на этапе обучения и в порядке ознакомления, да и то, что надо - списал у старших товарисчей. Отсюдова и мнение "что что-то писать - это мрак. Только для драйверов". Язык - как язык. Уж всяко лучше PHP.
В свое время 100% диплома (интерфейс с пользователем к расчету оптических систем) писался на этом языке... да еще и с использованием собственно-писанного Ассемблера в автокодах...
В свое время 100% диплома (интерфейс с пользователем к расчету оптических систем) писался на этом языке... да еще и с использованием собственно-писанного Ассемблера в автокодах...
Metal kыnG
veteran
Ну понаписали... Да понятно оно, что когда знаешь и умеешь - оно всё "несложно", а когда забыл, да еще и не знал, а только слышал - то точно "труба". Народ, который писал, если Ассемблером и пользовался, то только на этапе обучения и в порядке ознакомления, да и то, что надо - списал у старших товарисчей. Отсюдова и мнение "что что-то писать - это мрак. Только для драйверов". Язык - как язык. Уж всяко лучше PHP.Вернемся к нашим баранам .... ассемблерам.
В свое время 100% диплома (интерфейс с пользователем к расчету оптических систем) писался на этом языке... да еще и с использованием собственно-писанного Ассемблера в автокодах...
плюсы (и альтернативы):
ручной код быстрее - да (НО если интель то можно юзать интелевские оптимизированные библиотеки и компилятор С ... в серьезных задачах можно рассчитывать на топовый проц)
- микроконтроллеры - да заточить это круто (вспоминаем С-- и думаем о том как устроены фирменные компиляторы С и визуальные средства разработки, не забываем при этом что для более критичных по времени или надежности задач бюджет на железо сильно не ограничен)
- профилировка кода - да на асме можно заточить на скорость .... или покурить старого дядюшку Кнута и выбрать/адаптировать другой алгоритм.
- да АСМ приятнее ПХП .... до тех пор пока не начнете отдавать интерфейс железяки по HTTP .... тут более важна ОСРВ
- дизассемблируйте средний код полученный хорошим компилятором С (та же вата версии 10.хх) ... да подключив ММХ и т.п. вы выиграете немного ... но если этот компилер от производителя микроконтроллера - опять хороший пример С-- ... получите достаточно неплохой код где выжать можно десяток байт со страницы кода и тот же десяток тактов.
- имеет смысл писать на асме для минимизации требования к железу, но если ваша контора не продает 90000 стиральных машинок в месяц то зарплата будет небольшой
ЗЫ у меня были студенты (девушки что самое странное) которые писали на асме численный методы .... красиво, быстро, но запустив свою прогу на ксеноне (в век селеронов) я просто офигел от скорости ... запуск на селероне, но под QNX ... секунды уменшились на пару порядков относительно ксенона... далее под микроскопом выяснил что подготовка жрет больше чем расчет . Можно заточить и потерять универсальность.
Metal kыnG
veteran
В устройствах реального времени за каждую микросекунду все же сражаются.неее не сражаются. сражаются только в тех кусочках где это нужно. а там десяток строк на асме сделает любой общеобразованный программист. большая проблема это атомарные операции типа выставления флага готовности данных. хотя в нормальных юниксах есть пипискомерялка при старте определяющая наиболее быстрый для стдлиба способ пересылки данных
tolstopuz
v.i.p.
Всё верно.
Когда-то получали такой же эффект: детские игры, писанные на С с использованием графики на Асм (а-ля Спектрумосвские), на 286 железяке давали 12-16кадров в секунду, что было вполне достаточно для игрушки... но на хорошем Apple, Dos-эмуляторе потактовка вылетала за 80кадров... играть было просто невозможно... Хорошо помню жалобы американческих друзей: "...там типа чего-то мелькнуло и фсё-ё...game over."
Я же почему и выразил ИМХО: писать - можно... и не хуже чем на ... . Но не востребован... Думаю, если грамотно переписать код тех же виндов - работать станет просто невозможно... слишком мощны сегодняшние "бытовые" компы...
С другой стороны Асм, в нормальном объеме - ваще мало кто знает. А без опыта работы на Асм - нормального программиста - не получается. Потому как отсутствие понимания процессов в железяке - приводит к непониманию "чего оно всё тормозит так"...
Ну и по С--. Когда-то пришлось реассемблировать код для микроконтроллера, писанный американческими коллегами для одной медицинской железяки... так вот "индусский" код - цветочки... Особо понравилось место, где результат датчика (16-и разрядный АЦП ! ) просто обрезался до 2-х(!) старших разрядов с целью устранения "дрожания" результата... А на вопрос "Нельзя было накапливать и проводить экспоненциальное усреднение" получили ответ "Ага, можно. Только скажите что такое экспонента".
П.С. кстати, именно на этой железяке (переписав контроллер) получил доказательства 100% гипнотического воздействия экрана любого телевизора на всех опробованных зрителях... всего на 7-15минут. Скачок в характере получаемых данных был просто ошеломляющий.
Когда-то получали такой же эффект: детские игры, писанные на С с использованием графики на Асм (а-ля Спектрумосвские), на 286 железяке давали 12-16кадров в секунду, что было вполне достаточно для игрушки... но на хорошем Apple, Dos-эмуляторе потактовка вылетала за 80кадров... играть было просто невозможно... Хорошо помню жалобы американческих друзей: "...там типа чего-то мелькнуло и фсё-ё...game over."
Я же почему и выразил ИМХО: писать - можно... и не хуже чем на ... . Но не востребован... Думаю, если грамотно переписать код тех же виндов - работать станет просто невозможно... слишком мощны сегодняшние "бытовые" компы...
С другой стороны Асм, в нормальном объеме - ваще мало кто знает. А без опыта работы на Асм - нормального программиста - не получается. Потому как отсутствие понимания процессов в железяке - приводит к непониманию "чего оно всё тормозит так"...
Ну и по С--. Когда-то пришлось реассемблировать код для микроконтроллера, писанный американческими коллегами для одной медицинской железяки... так вот "индусский" код - цветочки... Особо понравилось место, где результат датчика (16-и разрядный АЦП ! ) просто обрезался до 2-х(!) старших разрядов с целью устранения "дрожания" результата... А на вопрос "Нельзя было накапливать и проводить экспоненциальное усреднение" получили ответ "Ага, можно. Только скажите что такое экспонента".
П.С. кстати, именно на этой железяке (переписав контроллер) получил доказательства 100% гипнотического воздействия экрана любого телевизора на всех опробованных зрителях... всего на 7-15минут. Скачок в характере получаемых данных был просто ошеломляющий.
Всё верно.Эхх, сразу видно зубров
Внесу-ка, пожалуй, и я свою лептуВо-первых, считаю, что язык программирования _практически_ не оказывает влияние на скорость разработки программ. Не будем рассматривать хеллоу ворлд. Это я насчет убогости ассемблера для сложных применений.Во-вторых, считаю, что на асме критические участки кода обычно пишутся более оптимизированно. Если нет - пусть программист идет пирожками торговать.
В третьих. Да, считаю, что ассемблерный код спортировать куда-то.. мягко говоря, сложно
Ээээ.. что не умаляет ео достоинств :)... (Внутренний голос) - да и не сложно вовсе, если в начале думать о возможности портирования
Какие будут мнения?Во-первых, считаю, что язык программирования _практически_ не оказывает влияние на скорость разработки программ. Не будем рассматривать хеллоу ворлд. Это я насчет убогости ассемблера для сложных применений."а мужЫки то не знают..." понапридумывали всяких дурацких, никому вообще совершенно не нужных, языков программирования... начиная с Си и заканчивая C# с его фичами типа автоматического управлением памятью...
"а мужЫки то не знают..." понапридумывали всяких дурацких, никому вообще совершенно не нужных, языков программирования... начиная с Си и заканчивая C# с его фичами типа автоматического управлением памятью...Честно говоря, я и в самом деле не знаю, чем занимаются тамошние мужЫки. Последний пример - србос памяти на ихней хваленой DS Tini (пошукуйте на максиме). Копание в их хваленых исходниках ни к чему не привели - проще оказалось написать свою файлОвую сЫстему. Кстати, на ассемблере.
P.S. это, так сказать, только что касается темы разговора. Примеров насчет с Си с диезиком, и заканчивая Нет с точкой у меня много. Пишите
да можно сколько угодно приводить примеров, но никто не докажет, что время разработки на ассемблере и языке высокого уровня равны. Никто лично специально никаких исследований не проводил. Тем не менее, люди, изучавшие этот вопрос утверждают - время разработки на языке высокого уровня меньше. И спорить с их цифрами своими голословными утверждениями, основанными на своем опыте - несостоятельно.
Можно спорить, что Сишный код один-в-один практически транслируется в ассемблер, да это так... Что-нибудь еще... но не про время разработки.
Ассемблер удобней применять, когда нужны инструкции перехода. На Си/С++ тоже можно использовать, но не комильфо.
Да, бывают ошибки в предоставляемых фреймворках, библиотеках и прочем. Но кто может поручиться, что нет не выявленных ошибок в собственном коде? И причем здесь время разработки...
Можно спорить, что Сишный код один-в-один практически транслируется в ассемблер, да это так... Что-нибудь еще... но не про время разработки.
Ассемблер удобней применять, когда нужны инструкции перехода. На Си/С++ тоже можно использовать, но не комильфо.
Да, бывают ошибки в предоставляемых фреймворках, библиотеках и прочем. Но кто может поручиться, что нет не выявленных ошибок в собственном коде? И причем здесь время разработки...
люди, изучавшие этот вопрос утверждают...
Сплетни - это конечно интересно, но лучше "ссылки в студию" (с)... народная мудрость.
В отличии от Вас, я таки привел сцылку на соответствующий научный труд. Там, как раз, утверждается ОБРАТНОЕ.
П.С. и еще для более полного понимания:
но никто не докажет, что время разработки на ассемблере и языке высокого уровня равны.
Никто и не утверждает полное РАВЕНСТВО. Утверждается СОИЗМЕРИМОСТЬ сроков.Которая, кстати, полностью ПОДТВЕРЖДАЕТСЯ стоимостью разработки конкретных серъезных приложений. Она также СОИЗМЕРИМА, т.е. одного порядка. Иначе бы сейчас (когда используются средства автоматизированного проектирования, программирования, кодирования, тестирования, версионирования и проч...) разработка софта стоила бы КОПЕЙКИ. А это почему-то все еще - не так.
По-поводу ошибок: Ну я когда-то поручался за отсутствие ошибок в сданном коде. В т.ч. и для военпредов - т.е. ответственность могла наступить и уголовная... так, с тех пор, ни разу никто и не обращался за сопровождением или исправлением чего-либо... писАть надо сразу грамотно, а не пИсать... и фсё.
Сплетни - это конечно интересно, но лучше "ссылки в студию" (с)... народная мудрость.
В отличии от Вас, я таки привел сцылку на соответствующий научный труд. Там, как раз, утверждается ОБРАТНОЕ.
П.С. и еще для более полного понимания:
но никто не докажет, что время разработки на ассемблере и языке высокого уровня равны.
Никто и не утверждает полное РАВЕНСТВО. Утверждается СОИЗМЕРИМОСТЬ сроков.
Которая, кстати, полностью ПОДТВЕРЖДАЕТСЯ стоимостью разработки конкретных серъезных приложений. Она также СОИЗМЕРИМА, т.е. одного порядка. Иначе бы сейчас (когда используются средства автоматизированного проектирования, программирования, кодирования, тестирования, версионирования и проч...) разработка софта стоила бы КОПЕЙКИ. А это почему-то все еще - не так.По-поводу ошибок: Ну я когда-то поручался за отсутствие ошибок в сданном коде. В т.ч. и для военпредов - т.е. ответственность могла наступить и уголовная... так, с тех пор, ни разу никто и не обращался за сопровождением или исправлением чего-либо... писАть надо сразу грамотно, а не пИсать... и фсё.
ссылаться на труд по технологиям программирования начала 80-х 
оригинально, да.
Но ссылки я приведу...
оригинально, да.Но ссылки я приведу...
А как же труды Галилея? Что тоже уже устарели? 
Научный труд - он потому и научный, что воспроизводится независимо от времени и места. По определению того, что есть НАУКА.
Научный труд - он потому и научный, что воспроизводится независимо от времени и места. По определению того, что есть НАУКА.
Вдогонку.
Скажу более жесткую фразу:
Платное сопровождение софта - (в части исправления ошибок) - это разводилово Заказчика или Покупателя на дополнительные бабки, которые к трате - не предусматривались в момент покупки (или заказа). По идее - такое должно рассматриваться как нарушение закона о защите прав потребителя (продажа артефакта с неверным функционалом - типа пылесоса, который не работает) и с автора надо брать бабки в размере принесенных убытков и/или недополученной прибыли...
Тогда писать начнут "как надо". Сразу и все.
Недаром же, даже в платных лицензиях это место тщательно оговаривается... "за барахло - ответственности НЕ несем..." т.е. мы Вам это продадим, а потом еще будем доить вечно.
Скажу более жесткую фразу:
Платное сопровождение софта - (в части исправления ошибок) - это разводилово Заказчика или Покупателя на дополнительные бабки, которые к трате - не предусматривались в момент покупки (или заказа). По идее - такое должно рассматриваться как нарушение закона о защите прав потребителя (продажа артефакта с неверным функционалом - типа пылесоса, который не работает) и с автора надо брать бабки в размере принесенных убытков и/или недополученной прибыли...
Тогда писать начнут "как надо". Сразу и все.
Недаром же, даже в платных лицензиях это место тщательно оговаривается... "за барахло - ответственности НЕ несем..." т.е. мы Вам это продадим, а потом еще будем доить вечно.
ТОП 5
1
2
3
4