-
Сергей-4030: Все сообщения за 2 Марта 2007 года
| Пн | Вт | Ср | Чт | Пт | Сб | Вс |
|---|---|---|---|---|---|---|
| 1 | 2 | 3 | 4 | |||
| 5 | 6 | 7 | 8 | 9 | 10 | 11 |
| 12 | 13 | 14 | 15 | 16 | 17 | 18 |
| 19 | 20 | 21 | 22 | 23 | 24 | 25 |
| 26 | 27 | 28 | 29 | 30 | 31 |
Как часто это уже слыхано... "Раньше вода была гораздо мокрее." "Мне этих ваших новомодных штучек не надобно, я все на ассемблере запрограммирую". Типично, кстати. И объяснимо - нынешнее программирование предполагает непрерывное обучение. Специалист в области программирования обязан постоянно учиться, без отрыва от производства.
инфо
инструменты
Или, как заметил еще дедушка Ленин, империализьмь загнивает.
Правда, дедушка Ленин давно в Мавзолее, а империализьмь все еще загнивает.
au> MIB determined that there was an inadequate, system-level integration process
au> MIB report clearly indicated that inadequate systems engineering (including a lack of implementation of software requirements, configuration control, validation of math models and testing) was a significant causal factor in the mishap
au> was a failure to implement existing (NASA) engineering requirements, standards and practices
au> NASA Report: Overview of the DART Mishap Investigation Results - For Public Release | SpaceRef - Your Space Reference
au> Мало?
Чего мало? Даже если допустить, что в процессе детерминирования все было гладко - что следует из вашей цитаты? Я как-то ни грамма не вижу, как из нее следует обязательность ассемблера. Inadequate systems engineering - это, извините, имхо как раз предполагает, что нужно использовать нормальные методы разработки, а не ковыряние в ассемблере, которое и есть - неадекватно в 99.9% случаях.
Мы не отказываемся. Это вы отказываетесь понимать, что "железный софт", как правило, решает задачи очень хорошо определенные и частные. А вот это уже значит, что тестировать такое ПО безусловно много легче, чем сложные "нежелезные" ПП.
au> *It's not a lot of work unless you have to do it.*©
Еще раз, резюмируем вашу точку зрения. Злые софтверщики заставляют хардверщиков сто раз переделывать сложную работу потому, что софтверщикам лень пальцем пошевелить. Вроде, я ничего не упустил, да? При этом, разумеется (без этого такой ситуации просто не получилось бы) софтверщики всего мира в преступном сепаратном сговоре.
Есть такая машина Тьюринга, которая, в принципе, может решить любую существующую компьютерную задачу. Вы типа имеете в виду, что изготовить и отладить машину Тьюринга сложнее, чем написать для нее WinXP?
Впрочем, похоже, и вы и au действительно так думаете. Странно даже, ведь неглупые же люди.
Естественно. Это именно частная, тривиальная и хорошо определенная задача. Разумеется, ее оптимизация может быть достаточно сложно задачей, но остается хорошо определенной. Это не значит, что проектировщики железа - дураки. Это значит, что у проектировщиков железа их (безусловно сложные) задачи просто имеют другие акценты этой сложности, не алгоритмические.
au> au>> MIB determined that there was an inadequate, system-level integration process
au> au>> MIB report clearly indicated that inadequate systems engineering (including a lack of implementation of software requirements, configuration control, validation of math models and testing) was a significant causal factor in the mishap
au> au>> was a failure to implement existing (NASA) engineering requirements, standards and practices
au> au>> NASA Report: Overview of the DART Mishap Investigation Results - For Public Release | SpaceRef - Your Space Reference
au> au>> Мало?
Сергей-4030>> Чего мало? Даже если допустить, что в процессе детерминирования все было гладко - что следует из вашей цитаты? Я как-то ни грамма не вижу, как из нее следует обязательность ассемблера. Inadequate systems engineering - это, извините, имхо как раз предполагает, что нужно использовать нормальные методы разработки, а не ковыряние в ассемблере, которое и есть - неадекватно в 99.9% случаях.
au> Знаете, это уже просто смешно. Я специально оставлю полную цитату как памятник всей этой мучительной и безысходной дискуссии.
au> И оставьте резюмирование моей точки зрения мне самому.
А вы объясните, что смешно - посмеемся вместе. Вы имеете в виду, что inadequate, system-level integration process значит - ассемблера маловато, так?
Неужели кто-то где-то запрещает вам искать подобное равноправие?! Неужели вы серьезно полагаете, что имеется в виду неравноправие? Вы что, правда думаете, что затраты на отладку/тестирование больших пакетов больше затрат на отладку-тестирование "железных" проектов из-за чьей-то злой воли?
Неужели вы думаете, что производители ПО, коли им так легко проводить отладку, не согласились бы взять ее (и соответствуещее вознаграждение, разумеется), если б это для них было легче? Ведь эта цена все равно снимается с клиента! Рассмотрим пример: делается кристалл, делается ПО в котором используется кристалл. Условно, работа по отладке кристалла - мильон долларей. Работа по адаптации ПО к неотлаженному кристаллу много дешевле (по вашей версии ) - скажем, 10000. Клиент готов платить мильон (т.е. по факту платит, ибо работа все равно должна быть проделана). Разработчик софта, по вашему, такой гадкий, что поступится мильоном прибыли, только чтоб подгадить производителю кристалла? Вам самому-то не смешно?
Да какая же она воздушно-идеальная, ее вам реализовать - проще пареной репы. И вообще - что за стрелки? Вы говорили:
Программа опирается на тот набор инструкций, который предоставляет ей процессор. Какой бы она сложной не была, она разбивается на элементарные команды. А вот при усложнении она начинает задействовать то самое "всего лишь", и начинается валится куча багов. Железных! Которые фиг отладишь, когда у тебя операционка валится с плавающей ошибкой через сутки работы.
Это все применимо к машине Тьюринга ничуть не хуже, чем к любому другому процессору. Значит, саму машину Тьюринга отлаживать тоже не проще, чем любое ПО, которое на ней выполняется. Это - прямое следствие из ваших слов. Поскольку мы явно видим, что следствие неверно, то значит и рассуждать более нечего - вы неправы.
Серокой> Вы опять мне приписываете то, что я не говорил. Ещё раз: отладить железо так же сложно, как и ПО. То, что ПО делается больше по объёму кода, не говорит о том, что оно сложнее в отладке! Один программный пакет по трудности отладить так же, как и одну микросхему!
Ваши рассуждения, извините, общи до полной потери смысла. Один программный пакет одной сложности с вашей микросхемой отладить так же - вот это гораздо более аккуратное определение. Очень сложную микросхему отладить труднее, чем простой пакет. Очень-очень-очень сложный пакет отладить много труднее, чем очень сложную микросхему. Относительно свободная конкуренция дает нам примерное отражение той или другой сложности в цене, в среднем запрашиваемой за разработку того и этого.
Серокой> Нет. Машина Тьюринга не подразумевает того, что находится вутри современного процессора, все эти улучшалки, убыстрялки и прочие 3dNow!.
Понятно. А то, что вне современного процессора - сотни гигабайт сложного кода ваш подход подразумевает? И еще раз (третий), вы написали следующее:
Программа опирается на тот набор инструкций, который предоставляет ей процессор. Какой бы она сложной не была, она разбивается на элементарные команды. А вот при усложнении она начинает задействовать то самое "всего лишь", и начинается валится куча багов. Железных! Которые фиг отладишь, когда у тебя операционка валится с плавающей ошибкой через сутки работы.
Еще раз, медленно (извините уж) - все, что вы написали, применимо к машине Тьюринга. И мы уже доказали, что это неверно. Если вы хотите дискутировать далее, вам стоило бы наложить некоторые ограничения на ваше исходное заявление, вам не кажется?
au> То что годится для второй страницы учебника по компьютерной архитектуре, уже не является актуальным для разработки современной техники. Эти вещи надо знать и отличать.
Ну вы тогда нас, горе-программистов, просветите, что качественно изменилось со времен машины Тьюринга. А заодно объясните, зачем, коли нынешние программно-архитектурные методы не дают никакого выигрыша в эффективности и качестве кода по сравнению с ассемблерописанием, вообще огород городить с ПО? Напоследок желательно было бы дать какой-нибудь серьезный проект, использующий ваши подходы, в сравнении с обычными горе-программистскими поделками.
Очень распространенная точка зрения, особенно когда очень хочется монополии (впрочем, ее всегда хочется). Если бы я был производителем гвоздей, я бы сказал так: "проектирование дома - это часть системы гвоздерасположения, нравится это кому-то или нет".
Да верю, конечно, что за проблема? Есть они, очень-очень-очень сложные микросхемы. Но из того, что я вижу в реальном мире (стоимость разработки среднего пакета ПП много выше разработки средней микросхемы) я делаю вывод, что в среднем сложность микросхемы ниже. Что за проблема-то? Я ж не делаю из этого вывод, что разработчики микросхем в среднем глупее, правильно?
Серокой> Не применимо, современный процессор - не машина тьюринга. Как минимум, тем, что у Тьюринга за такт рассматривается одна ячейка памяти, в суперскалярных процессорах это не так.
Современный процессор, конечно, не машина Тьюринга, ну и что с того? Это параллельно. Важно то, что ваши рассуждения применимы точно так же для машины Тьюринга. И если бы ваши рассуждения были бы верны, то они бы давали верные следствия хоть для процессоров, хоть для машины Тьюринга. Явно показано, что ваши рассуждения для машины Тьюринга дают неверные следствия, значит рассуждения - неверны и никого уже не интересуют, какие следствия дают ваши рассуждения применительно к современным процессорам.
Татарин> ...но сейчас Вы - программист, откуда следует - ...
- то, что я пристрастен. Конечно. Но, к счастью, есть вполне приличный индикатор реальной стоимости того или другого труда - рынок. А вот рынок говорит, что стоимость гвоздей - копейки за десяток, а стоимость разработки ПО в среднем выше стоимости разработки харда.
Нет, не путаю. Сколько там стоимость разработки Виста?
мужественный> Потому, что некоторые единоплеменные никак не могут залечить баг в собственной памяти, то есть не помнят, что это такое - быть русским да и бегут на запад + вполне логичная политика государства. Отдать противнику на откуп наиболее важное направление науки и техники - это уже не кретинизм, это нечто иное.
мужественный> В прочем, и это переживём, А.И.Покрышкин летал на Bell P-39 и ничего, много нибелунгов с небес на землю спустил. Меж тем сами американцы на этих "кобрах" погеройствовали не очень то здорово, знать кишка то тонка у них самих была.
мужественный> Кстати, когда некто пытается сбагрить вам некачественный продукт общей стоимостью (за n рабочих мест) этак в 20000000...30000000$ то иначе чем мошенничеством в особо крупных размерах это назвать трудно, разве что вспомнить про понятие "линия огня".
Тяжко, наверное, вам жить, сэр мужественный.
Всюду враги, всех надо убить или как минимум заставить жить так, как вам кажется правильным. А что самое обидное - враги вас совершенно не замечают, делают то, что им кажется правильным даже и не в смысле вас позлить и навредить, а просто - плевать они, враги, хотели на ваше существование. Тяжело вам.
Copyright © Balancer 1997..2024
Связь с владельцами и администрацией сайта: anonisimov@gmail.com, rwasp1957@yandex.ru и admin@balancer.ru.
Связь с владельцами и администрацией сайта: anonisimov@gmail.com, rwasp1957@yandex.ru и admin@balancer.ru.
