[Прохожий]

vIv, http://forum.nag.ru/forum/index.php?showto...st&p=579522 :)

 

Судя по твоим постам - ты из девяти. Огорчил...

[jab]

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

Завалишин в интервью хорошо говорил про managed code.

Не буду спорить, ибо сам не специалист в этом, не это ли следующий шаг после ООП?

:-)) Особенно весело это читать на фоне давешних плачей о тяжелой судьбе супер-пупер ООП херня-маркета после ухода dz в шоферы икс-трейлов.

 

Надо флейм затеять из разряда: Scala vs. Forth.

 

Как-раз автоматическое управление памятью - именно меняет всю парадигму: ты делаешь то, что нужно делать для дела, а не то, чтобы "эта фигня вообще работала". Была целая отрасль отсмотра кода на предмет утечки памяти, на эту тему фолианты писались! А само ООП как тянуло за собой в первых реализациях тулуп

Гггг... 15 лет писал на perl'е из-за автоматического управления памятью... теперь оказалось, что он ООП. ;-)))))))))))))

[vIv]

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

 

Из аналогичных событий: изобретение чесальной машины и ткацкого станка, парового двигателя, управления качеством, автоматизация обработки фидбэка и т.п. Это событие, которое облегчило работу того, кто делает основную работу. В отличие от art of OOP.

 

Вот примерно о том же: http://www.google.com/buzz/A.Bogorodsky/Qf...%82%D1%80%D1%83

[s.lobanov]

ООП тоже ничего принципиально не изменило.

Что еще раз подтверждает тот унылый факт, что саму суть ООП понимает в лучшем случае один программер из десяти :( Потому что ООП - это принципиально иная организация МЫШЛЕНИЯ. По моим же наблюдениям большинство граждан как учились на процедурном подходе - так и не научились чему-то иному :( А выделить-освободить память - это технический момент...

Ну зря Вы так про память. Откройте release notes к прошивкам, например, для L2-свитчей и почитайте описания багов. Сплошь и рядом memory leaks, memory corruption и т.д. и т.п. Тоже самое когда читаю всякие security-рассылки, гигантская часть проблем это из-за ручных malloc'ов без free и new без delete. А ведь выбор языка это тоже задача архитектора и если он не в курсе этих "технических моментов", то все его красивые схемы и изящные решения превратятся в очердное глюкалово.

 

Лично я сам и за ООП и за managed code(если это не задача, где нужно учитывать каждый такт процессора, но такие задачи нужно изолировать и решать их отдельно)

[vIv]

Как-раз автоматическое управление памятью - именно меняет всю парадигму: ты делаешь то, что нужно делать для дела, а не то, чтобы "эта фигня вообще работала". Была целая отрасль отсмотра кода на предмет утечки памяти, на эту тему фолианты писались! А само ООП как тянуло за собой в первых реализациях тулуп

Гггг... 15 лет писал на perl'е из-за автоматического управления памятью... теперь оказалось, что он ООП. ;-)))))))))))))

Напомнить про чудеса управления памятью в mod_perl? ;-)

Кстати, ОО перл таки есть, причём ровно в том самом перле, который у тебя в руках. Там надо только хитрые краказябры расставить, и получится ООПерл ;-)

 

Кстати, я реально не понимаю, как в mod_php проблемы памяти нет, а в mod_perl есть. При том, что делают одно и то же в одном и том же окружении. Правда, не слежу уже особо, может быть и починили, но мне оказалось проще забить на mod_perl. С другой стороны, у меня и highload нет =)

Тут чувак рассказывал про чудо-юдо эрланг. Он на нём какие-то фантастические закидоны монстрячит =)

[Картуччо]

принесло мощное увеличение производительности труда.

Увеличение КПД, снижение накладных расходов в программировании, - повысило маржинальность программирования, снизило себестоимость и/или ускорило выход новых версий.

То же самое в свое время писали про ООП.

[vIv]

Лично я сам и за ООП и за managed code(если это не задача, где нужно учитывать каждый такт процессора, но такие задачи нужно изолировать и решать их отдельно)

Сейчас Интел засунет FPGA в процессоры, - получим просто чудеснейшие программы, которые будут себе процессор под задачу на-ходу собирать ;-)

 

принесло мощное увеличение производительности труда.

Увеличение КПД, снижение накладных расходов в программировании, - повысило маржинальность программирования, снизило себестоимость и/или ускорило выход новых версий.

То же самое в свое время писали про ООП.

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

[jab]

Напомнить про чудеса управления памятью в mod_perl? ;-)

Кстати, ОО перл таки есть, причём ровно в том самом перле, который у тебя в руках. Там надо только хитрые краказябры расставить, и получится ООПерл ;-)

Еще почитай мне 12-ую главу "Camel book" на ночь. :-))) То, что на перле можно писать объектно, не делает его ООП языком. На ассемблере вон тоже объектами пишут.

[s.lobanov]

Для той же Явы есть автоматическая чистка памяти, но по окончании работы.

Вы вообще в курсе как gc работает?

[vIv]

Конкретно gc - нет, а что в нём есть интересного?

Аа... этот!

И что с ним? Вы хотите рассказать про хип? Так бывают не только системы, которые изредка работают, а ещё и постоянно нагруженные.

[s.lobanov]

мда... и этот человек рассуждает о памяти и java, не имея представления как работатет garbage collector. вот, почитайте http://www.oracle.com/technetwork/java/gc-...g-5-138395.html

[vIv]

Чистку хипа я знал ещё прошлом веке. Как и "почему своп в винде надо сразу сделать таким, какой он нужен".

Я просто задумался, при чём тут gnu c и чего в нём такого нового появилось.

 

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

 

Unless you have problems with pauses, try granting as much memory as possible to the virtual machine. The default size (64MB) is often too small.

 

Setting -Xms and -Xmx to the same value increases predictability by removing the most important sizing decision from the virtual machine. On the other hand, the virtual machine can't compensate if you make a poor choice.

 

Be sure to increase the memory as you increase the number of processors, since allocation can be parallelized.

[vIv]

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

 

А уж эпические периодические споры, как правильно делать vacuum clean без останова сервера... 8-)

[ingress]

Тьфу дерьмо сказали вояки... :)

нету православных аппаратных закладок? ;)

[zoro]

Я так понимаю что Прохожий очередной раз хочет вытащить наше отечественное на должный уровень...

 

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

 

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

 

[Прохожий]

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

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

 

А по поводу memoty leaks, по ходу, тебя таки уели :)

 

Скорость выхода софта - повысилась, качество - понизилось. Функций стало больше, только они нихера не работают :) Копроэкономика в действии.

[vIv]

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

 

Скорость выхода софта - повысилась, качество - понизилось. Функций стало больше, только они нихера не работают :) Копроэкономика в действии.

Этот мир не даёт нам такой роскоши, как неизменность целей на протяжении всего проекта, ты знаешь это как практик. Чем больше, длиннее проект, тем больше изменений по-живому произойдут в пути. Поэтому ООП стало большим шагом вперёд, но не революцией. Повторяю: это была достаточно успешная попытка решить имеющиеся проблемы. Решить, а не избавиться от них в принципе. Возможность "потерять" память осталась, а, значит, сама проблема также осталась. Получаем бассейн с двумя трубами и непрерывную борьбу бобра со злом ;-(

 

В общем, окончательным аргументом тут стоит считать матюки самих явистов, да поведение JVM на наших компах :-)

 

А по поводу memoty leaks, по ходу, тебя таки уели :)

Ссылку же привели, - с чего бы вдруг таким материалам появляться? Just for fun? ;-)

[s.lobanov]

vIv

А с чего Вы вообще решили, что задача ООП это решение каких-то проблем с памятью? managed code и ООП это разные "фишки" и нет смысла их сравнивать вообще.

[vIv]

Я не говорил, что одно и то же. Мы тут решаем, которое из двух прорывных улучшений является наиболее революционным. Хотя они и из разных областей, но шишки, набитые при рождении ООП, в итоге подтолкнули рождение managed code в части разгребания кучи и упрощения синтаксиса, да и вообще логики работы кода :-)

 

Типа, кто сильнее: слон или кит? ;-)

[Janus]

А работать на Кого-то к сожалению всегда переходит на "Начальник Сказал" так- и пускай это будет неправильно, зато бабла попилим...

Это ты про свой личный опыт, коллег или кого?! Особенно в части "лишь бы попилить".

 

Может ты просто не пробовал аргументированно бороться за свою позицию?

Или у вас на югах чуть что не так сказал, так то Кущевская получается, то Хан? :(

 

--------------------------

Братья, ваши разборки о методах программирования, боюсь не дадут вам дополнительного шанса попасть на заметку Прохожему :)))

Те, кто пишет ему в личку, вас точно на кривой козе объедут! ;)

[Voicemaster]

BTW, работа архитектора вообще порой весьма грустна.. Не знаешь ты ли дурак или окружающие балбесы.

Не поверишь, я бы за одну эту фразу на работу взял :))))))

Поверю :-)), но это было бы несколько эмоциональным решением :-)

 

Вот только надо ли оное в этоху IMS & MPLS ? К вопросу об адекватности.

Смотря что делать :) Для чего, для кого и куда :)

Вот тут уже несколько серьезнее, если речь идет о Деле. Дело - интересно.

 

Прохожий, вы производите впечатление человека не сильно проржавевшего корпоративным цинизмом и маразмом. Это ценно.

 

Контакты у Вас в личке, будет время/желания пообщаться - URW.

 

P.S

В железках не очень силен..

[Voicemaster]

Как-раз автоматическое управление памятью - именно меняет всю парадигму: ты делаешь то, что нужно делать для дела, а не то, чтобы "эта фигня вообще работала". Была целая отрасль отсмотра кода на предмет утечки памяти, на эту тему фолианты писались! А само ООП как тянуло за собой в первых реализациях тулуп

 

{

new a;

| тут пишем, то, ради чего все эти пляски

memfree a;

}

vIv, ты реально чудесатый :-)

 

Разницу между

{
    Clazz * instance = new Clazz(...);
    instance->doSomething(...);
    ...
    delete instance;
}

и

 

{
    Clazz instance;
    instance.doSomething(...)
    ...
}

 

понимаешь ?

 

так до примерно 1.0.2 Явы и осталось. И несмотря ни на что, Ява-машины до сих пор пухнут при долгой работе. Остаётся, остаётся беда! Неудивительно, что РНР взрывно захватил самый востребованный рынок "быстро набросать", а потом вообще стал стандартом де-факто. Где сейчас small-talk? ;-)

Ога, да :-)

 

Дорогой, ты не поленись написать хоть на bash'e вычисление среднего арифметического списка "1 2 3 4 5" методом хвостовой рекурсии и подумай о соответствии инструментов задачам.

 

Контрольный вопрос: откуда взялась Scala ?

 

 

.

 

[Mikler]

ну Элтех как-то живет и производит. что они не так делают? чипы оттуда везут, паяют здесь. софт пишут опять же здесь.

С уровнем Элтекса в Новосибирске есть 7 контор. Ещё в Новосибирске есть дизайн ателье на 90 нм только шшш, а то тут набегут и будут плакать нет в России электроники.

Такие люди есть которые нужны автору но как правило они глубоко в своей теме и не нужно им что то менять их и так всё устраивает. Мне повезло я у них учился и дальше учусь :) .

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

 

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

[vIv]

Разницу между

{

Clazz * instance = new Clazz(...);

instance->doSomething(...);

...

delete instance;

}

и

 

{

Clazz instance;

instance.doSomething(...)

...

}

понимаешь ?

Я-то да, понимаю. И как то сказывается на занятости пограммистов - тоже. Выделенное жирненьким - финтифлюшечки, не сказывается. А вот подчёркнутое - сказывается.

 

Контрольный вопрос: откуда взялась Scala ?

Контрольный вопрос: куда, а не откуда. Я ж привёл пример эрланга, причём на нём реально пишут, и много. И сильно, кстати, пишут. На tcl тоже пишут, причём много.

[Mikler]

Контрольный вопрос: куда, а не откуда. Я ж привёл пример эрланга, причём на нём реально пишут, и много. И сильно, кстати, пишут. На tcl тоже пишут, причём много.

Не поминай Эрланг в суе :) Одново вон ужа садят за Эрланг :)

Прорыв это методы обработки информации, и способность адаптации компиляции под архитектуру параллельной системы. Эрланг это один из инструментов но он ресурсо жоркий аж пиндец.