Совсем глупый? Их место - крайне незавидное. Они горбатятся за очень жалкие копеечки (чем, собственно, и победили). Штрейкбрехеры хреновы...
Надо просто убедить именно потребителя, что лучше ДОРОЖЕ И КАЧЕСТВЕННЕЕ, чем дешевое массовое говно. Создать конкуренцию - сейчас ведь практически отсутствует такая категория софта, как дорогие профессиональные решения. Или совсем-совсем high end, или попс - без серединки.
За копеечки? Ну не все, далеко не все. Это я тебе говорю как человек, проработавший в штатах 3 года. Многие, конечно, начинают с малого. Но это естественно - сходу тебе все блага никто не даст. Надо самому встать на ноги, зарекомендовать себя.
А если, как ты говоришь, убедить, что "лучше дороже и качественнее", то те, кто делают дорого, совсем распоясаются и будут делать тот же shit, что можно найти во многих других местах.
Факт в том, что ниша сначала занимается, а потом идет качественный рост. И выходцы из Индии очень неплохие программеры и математики, а не штрейкбрехеры.
>Обоснуй необходимость поддержки ошибок выделения памяти в современных языках программирования. Мне очень интересно.
Причем тут поддержка ошибок? =) Я говорю о том что не вижу ничего плохого в том что программист управляет памятью- размещением и высвобождением это вполне удобно, не всегда конечно, согласен что для написания всякой мелочи можно обойтись скриптовыми языками, но все же зачем полностью полагаться на сборщиков мусора?
Ошибки все равно будут - хотя бы в самом сборщике мустора - его то надо как то писать тоже =))
Alan - utopist :)
Vy, tovarischi developery, soft pisat' nikogda pravil'no ne nauchites'. Bugi byli, oni vsegda est' i vsegda budut. I nikakimi novymi yazykami programmirovaniya eto delo ne ispravish' - tut chelovecheskiy factor.
I k nikakim sovetam `kak pisat' pravil'nee` ne budete prislushivat'sya, schitaya vash kodyarnik samym pravil'nym.
I tol'ko kachestvennoe testirovanie privedet k zhelaemomu rezul'tatu.
Главное, готов ли ты _писать_правильно_. Правильный язык зависит от целей. Это может быть и Asm, и C, и Python, и Lisp, и sh, и много чего ещё.
> Зарплаты нужна от $1800.
Иди в банк писать на Жабе.
Гон маразматика, прости, но это так. Программист-проститутка. Сколько заплатят за столько и отсосет. Если в твоем городе уровень жизни выше чем в других городах и ты сосешь за большие деньги, то это не повод говорить обо всех так. Поехали. Хочу зарабатывать $1 миллимон в час. Буду писать хорошо. Выучу все. Буду ошибки отслеживать сутками...
Ах да добавить хочу. Ты конечно можешь быдь гордым и не сосать за то что тебе дадут, но тогда ты будешь в реале посасывать по мелочам. Деградируешь как программист. И я почему то думаю, что если сейчас со всего мира полезут конкуренты на твое рабочее место-где ты зарабатываешь немерянно, то ты не совсем будешь рад этому. Обратишься к мэру города с соплями что типа перебежцы заполонили все и вся. Шагу не ступить-везде конкуренты. Нужно что то делать что бы этих конкурентов было меньше, уважаемый мэр. Так что каждый зарабатывает столько СКОЛЬКО ЕМУ ДАЮТ! А не столько СКОЛЬКО ОН ХОТЕЛ БЫ! Ради такого как ты и я никто не будет зарплату увеличивать до необъятных размеров.
2anonymous (*) (09.10.2004 21:45:16)
>Я готов писать на правильном языке.
Пиши на русском ... детективы или женские романы :-)
>Зарплаты нужна от $1800.
Гонорар - процент с продаж.
>Посоветуйте что-нибудь, please!!!
Меняй работу.
2anonymous (*) (10.10.2004 12:36:56)
>Это не конструктивно
Зат%^&&хай себя до смерти :-)
>А что он там такого качественного и правильного написал?
А ты?
>А ты?
Спасибо за интерес конечно. Если дашь почту, я отвечу что я такого написал. Не хочу хвастаться на форуме.
Меня интересует что написал человек, который знает, как надо писать правильно и получает $250000. Мне это нужно, чтобы знать, можно ли принимать эту статью всерьёз или нет.
2anonymous (*) (10.10.2004 13:14:38)
>Не могу. Не хочу обижать свою подружку.
Ну так ее и попроси :-)
>Если дашь почту, я отвечу что я такого написал. Не хочу хвастаться на форуме.
>Меня интересует что написал человек, который знает, как надо писать правильно и получает $250000.
А если тебя интересует, дай свою почту Алану Коксу :-)
>Мне это нужно, чтобы знать, можно ли принимать эту статью всерьёз или нет.
Да, логика железная :-). Тебе нужно, ты и выясняй через почту, а не $%^би мозги нам на форуме :-)
>Меня интересует что написал человек, который знает, как надо писать правильно и получает $250000. Мне это нужно, чтобы знать, можно ли принимать эту статью всерьёз или нет.
М-да, чудны дела твои Господи. Извините, Вы из какого леса сюда пришли ? ;)
"Ручное" распределение памяти - не главная причина наличия ошибок в ПО. Главная причина в том, что человеку свойственно ошибаться. Чтобы эти ошибки устранить, ПО надо очень внимательно выверять и отлаживать (открытость исходников этому способствует). Но часто вместо того, чтобы нормально отладить уже имеющуюся программу, начинают добавлять в неё новые функции, которые вносят ещё больше ошибок.
PS: Сравнение с процессором некорректно. Во-первых, из всез этих транзисторов львиная доля входит в кэш, состоящий из однотипных ячеек памяти. Остальные блоки зачастую тоже однотипны. Никакого реюза кода :). Да и львиная доля работы по проектированию возложена на ПО.
PPS: Кстати, а откуда известно, что в процессорах мало ошибок? Кто видел схему?
>They put over 100 million gates/transistors on a tiny piece of silicon. >On that piece of silicon there are more lines than there are on a roadmap of London - and they work. There are very very few errors in a microprocessor.
Ах.
Ещё б он сравнил стоимость разработки того и другого.
Кроме того, электронные схемы - это логические кирпичи. Их довольно просто (по сравнению с монструозным программным проектом) оттестировать. Я вот вижу, как корпят над проектом наши тестировщики. Тестировать его в нормальном режиме (т.е. каждую сборку полностью) - просто нереально. Всяческие Rational Robot'ы мало помогают.
2anonymous (*) (10.10.2004 13:59:43) aka //Losiki
>Кроме того, электронные схемы - это логические кирпичи. Их довольно просто (по сравнению с монструозным программным проектом) оттестировать.
Легко все, чем занимаются другие, особенно если ты - их руководитель :-)
2Pi * (*) (10.10.2004 14:12:37)
>ох, не скажи. если руководитель талантлевый, трудолюбивый и умный, то...
То он будет стараться набирать в команду таких же, но это ТАААК редко происходит :-(
В процах ошибок немного, потому что дорого их там делать. Из-за каждой ожибки в проце сколько шуму бывает, что было бы если бы интель партию процов выпустили таких же по качеству, как например... Ни одна прога на них бы по естесственным причинам не завершилась бы, покупать такое никто не станет, купленые уже вернут с возмещением, а денюх - тютю, поиздержались на изготовлении/перевозке/прочих накладных. Хреновые проги делать - начальство так велит. Лишь бы поскорее, да подешевле, даже всякими висуал васиками не брезгуют. Потом, как дело до суппорта доходит, за голову хватаются конечно, но видимо им так проще, чем изначально архитектуру программы продумать и нормальный инструментарий подобрать.
Alan Cox ничего нового не написал. Прописные истины лишний раз только повторил.
Неправильно сравнивать вопросы качества при проектировании софта и проектировании микропроцессоров (тоже относится и к прочей электронике). Абсолютно разные темы и подходы.
>"Ручное" распределение памяти - не главная причина наличия ошибок в ПО. Главная причина в том, что человеку свойственно ошибаться. Чтобы эти ошибки устранить, ПО надо очень внимательно выверять и отлаживать (открытость исходников этому способствует). Но часто вместо того, чтобы нормально отладить уже имеющуюся программу, начинают добавлять в неё новые функции, которые вносят ещё больше ошибок.
Вот тут Вы правы, ошибки(они же Bags), возникают от человеческой глупости.
Вот к примеру, если Вы или Ваш коллега, пишет на С++, то кто из них, когда нибудь, при вызове оператора new, предусматривал обработку исключения std::bad_alloc или при использовании read(2), предусматривал обработку, когда errno равен EINTR?
Lisp это просто убожество какое-то, а то что он ещё жив можно объяснить скорее его оригинальностью, чем некой фундаментальной полезностью.
Есть такой анекдот:
ФБР украло несколько килобайт секретной программы, написанной Аль-каидой на лиспе. Кодом были тысячи правых кавычек ;)
Результаты 1 - 20 из примерно 3 300 000 для bill gates
Результаты 1 - 20 из примерно 2 270 000 для alan cox
Результаты 1 - 20 из примерно 593 000 для linus torvalds
удивительно, правда? это конечно не показатель, но кое-какие выводы сделать позволяет. v4l и v4l2 тоже кажется его рук дело. да чего уж там - сделай
grep -r -i 'alan cox' /usr/src/linux/*
и посмотри
ps: хотя ты конечно прославился еще сильнее :)))
Результаты 1 - 20 из примерно 20 100 000 для anonymous
(еще можно погуглить на слова "Deep Space 1", "Remote Agent Experiment", RAX)
Еще можно сходить в раздел "Success Stories" на www.franz.com, там тоже немало
интересного. Еще, кажется, USAF Operation Planner тоже был написан на Лиспе,
вот только ссылок сейчас не найду.
Да, на C/C++/Java проектов в разы (а то и на порядок) больше по
количеству, но тем не менее, лисперам тоже есть что показать.
>Неправильно сравнивать вопросы качества при проектировании софта и проектировании микропроцессоров (тоже относится и к прочей электронике). Абсолютно разные темы и подходы.
Вот это то и плохо. И про это как раз товарищ и написал, что пока в EULA будет написано, что программист ни за что не отвечает, процессоры будут работать, а программы глючить.
Эй, какая такая штаты? Индийские? Я говорю про оффшоры в Индии и Пакистане - оттуда весь самый убогий и самый дешевый код идёт.
О выходцах речи нет. Я таких немало знаю - умные, грамотные, сознательные товарищи. Но их - ничтожно малое количество, в сравнении с миллионами, оффшорящими из Индии.
Это невозможно. Обоснование. Процессоры (любая микросхема) -- это узкоспециализированное устройство с весьма ограниченным количеством функций, которые очень легко формализуются и проверяются. Работает или не работает. АЛУ в процессоре должен сложить числа. Проверили - складывает. А вот команда сдвига должна сдвигать. проверили - работает. И так далее. В программах же в качестве параметров отладки могут быть тысячи и десятки тысяч параметров (взаимосвязанных, завязанных на модули других производителей, операционную систему), начиная от всех особенностей функциональности и заканчивая пользовательским интерфейсом. При таком количестве параметров отладки никакая софтверная контора не даст никаких гарантий, так как пока технологии, кроме человека-тестера (с человеческим же фактором) для отслеживания такого количества не существует.
Кто здесь выше сказал, что при проектировании микросхем нет reusability? Вы жестоко ошибаетесь! Там уровень повторного использования компонентов ошеломляющий! Проектирование начинается с модели (часто на VHDL, Verilog, C), потом симуляция, потом специальные компиляторы преобразуют модель в кристалл. И работают компиляторы не на уровне отдельных транзисторов, а на уровне готовых компонентов (ARM-ядро, порты ввода-вывода, логические элементы, память...). Да пусть даже на уровень gates спускается этот компилятор. Важно то, что проверять надо ограниченное количество параметров.
Второй аспект. Программу можно без труда проапгрейдить. А глючный процессор не проапгрейдишь. Его можно только вернуть. Поэтому ужесточение требований к качеству на процессор не только уместно, но и реально (повышенные требования к ограниченному числу параметров тестирования еще выполняются в разумное время). Если предьявляить такие же требования к конечному продукту софта, то, уверяю вас, этот софтверный продукт никогда не выйдет! Пока можно расчитывать на компромисс между временем и качеством. Может быть в будущем что-то изменится. :)
>Нееет, товарищ, не всяким тестированием можно выловить ВСЕ баги :)
>Это я тебе говорю, как программист, зарабатывающий на кусок хлеба с колбасой, книжки и инет.
>Cobalt * (*) (10.10.2004 4:09:33)
Kogda ya govoril chto kachestvennoe testirovanie privedet k zhelaemomu rezul'tatu, ya imel vvidu chto soft stanet _luchshe_, no ne vozvodil eto delo v absolyut.
V razvitii svoey temy hotel dobavit', chto voprosu testirovaniya softa udelyaetsya malo vnimaniya - ob etom mozhno sudit' po nalichiyu na rynke svobodnogo softa dlya testirovaniya - ego net...
2Zubok * (*) (11.10.2004 0:06:39)
>Второй аспект. Программу можно без труда проапгрейдить. А глючный процессор не проапгрейдишь.
Этаа ... а перепрошить микрокод? Ессесснно, если проц это позволяет :-)
>Кто здесь выше сказал, что при проектировании микросхем нет reusability? Вы жестоко ошибаетесь! Там уровень повторного использования компонентов ошеломляющий!
Вы меня неправильно поняли. Просто процессор похож на автоматически сгенерированную программу, у которой полно повторяющихся блоков кода (ячейки кэша, те же самые ядра). А обусловлено это тем, что логический элемент намного сложнее использовать сразу в нескольких схемах, чем подпрограмму сразу в нескольких программах. Вот и выходит, что сложность процессора выражается числом, намного меньшим, чем количество транзисторов.