Здравствуйте, vdimas, Вы писали:
V>А контроллер боженька нам материализует? В этом сегменте тоже конкуренция ого.
Производителей контроллеров куда меньше чем производителей другой электроники (на базе тех же контроллеров в том числе).
CC>>Так как прикажешь применять опыт практик разработки электроники к разработке софта если объём логики в электронике стараются как можно более уменьшить, перекладывая имплементацию этой логики с электроники на софт? V>Пока что развитие процессоров говорит ровно об обратном, все больше делается в железе того, что раньше делал софт.
Ты про добавление новых команд со сложным поведением? Это ж борьба за место под солнцем: а на нашем контроллере ваш софт сможет делать фичу Х быстрее конкурентов. Купите нас!
Ты знаешь какие нибудь примеры где отказались бы от контроллера в пользу реализации логики "в железе" и при этом это не было вызвано внешними факторами (работа в каких либо условиях, где контроллеру пришёл бы трындец)?
CC>>Мне лично это говорит что большие системы делать методом электронщиков — очень геморно, несмотря на мегатулы. V>Из ложной предпосылки ложный вывод.
Поживём увидим.
Спорить тут бесполезно. Только практика покажет что на самом деле хорошо, а что нет.
V>И ты не заметил, что плане аппаратуры я упор делал на надежность.
С надёжностью в электронике серебряной пули тоже нет.
Сколько людей и сколько усилий тратится на выпуск очередного Intel Core? Какова цена исправления ошибки при реализации в железе и в софте для производителя контроллеров?
Что будет с софтом если вложить в него столько бабла и спецов, поставив такие же жёсткие требования к качеству? Полагаю что с надёжностью будет не хуже
Здравствуйте, vdimas, Вы писали: V>Пока что развитие процессоров говорит ровно об обратном, все больше делается в железе того, что раньше делал софт.
Ну по мне так в железе делаются оптимизации типичных софтовых задач, а не полноценные решения. Та же аппаратная поддержка виртуализации. И то, многое до сих пор остается чисто софтовым, та же сборка мусора (хотя ведь были исследования). Не? А то б сидели мы сейчас программировали лисп-машины.
Здравствуйте, alpha21264, Вы писали:
N>>В 2010-й наконец-то сделали поддержку мультимонитора.
A>Чего? Студия не может растянуть окно на два монитора?!!!
У меня на Висте + видеокарта nVidia с последними драйверами режим отображения только nView. При этом окно студии может помещаться только на одном определённом мониторе. В 2010-й студии уже можно взять любую закладку и перетащить её на другой монитор, сделать любого размера.
Здравствуйте, CreatorCray, Вы писали:
CC>Здравствуйте, VladD2, Вы писали:
VD>>Руки быстро устанут. Лучше уж силой мысли... CC>И монитор протирать от пальцев заколебёшься.
Здравствуйте, VladD2, Вы писали:
VD>Здравствуйте, Кэр, Вы писали:
Кэр>>Но вот когда по большому монитору можно будет пальцами елозить aka мультитач интерфейс — вот это будет отвал башки
VD>Руки быстро устанут. Лучше уж силой мысли...
Зависит от того, как монитор расположен. Если под наклоном внизу — наподобие чертежного стола, то я не думаю, что устанут.
Здравствуйте, Nuzhny, Вы писали:
N>Здравствуйте, alpha21264, Вы писали:
N>>>В 2010-й наконец-то сделали поддержку мультимонитора.
A>>Чего? Студия не может растянуть окно на два монитора?!!!
N>У меня на Висте + видеокарта nVidia с последними драйверами режим отображения только nView. При этом окно студии может помещаться только на одном определённом мониторе. В 2010-й студии уже можно взять любую закладку и перетащить её на другой монитор, сделать любого размера.
Я юниксоид, по этому Винду вижу редко.
Просто сравниваю с Юниксом.
А в КДЕ два монитора — это один-единственный рабочий стол.
По этому абсолютно любая программа может быть на одном мониторе, на другом,
и полвовина окна на одном, а другая на другом. И выезжать за пределы мониторов как вправо так и влево.
Здравствуйте, alpha21264, Вы писали:
A>Я юниксоид, по этому Винду вижу редко. A>Просто сравниваю с Юниксом. A>А в КДЕ два монитора — это один-единственный рабочий стол. A>По этому абсолютно любая программа может быть на одном мониторе, на другом, A>и полвовина окна на одном, а другая на другом. И выезжать за пределы мониторов как вправо так и влево. A>
Ох... 2010 студию всего-то научили выдергивать окна с кодом за пределы главного окна студии. Все остальные окошки и так вытаскивались. И растянуть вручную студию на два монитора было тоже конечно же возможно.
Здравствуйте, CreatorCray, Вы писали:
V>>А контроллер боженька нам материализует? В этом сегменте тоже конкуренция ого. CC>Производителей контроллеров куда меньше чем производителей другой электроники (на базе тех же контроллеров в том числе).
Ну да, тех же производителей операционок и системных библиотек меньше, чем прикладных програм, но речь шла не об этом.
CC>Ты про добавление новых команд со сложным поведением? Это ж борьба за место под солнцем: а на нашем контроллере ваш софт сможет делать фичу Х быстрее конкурентов. Купите нас!
Ну да, эта борьба и двигает прогресс. И SSE3 дают на некоторых задачах ускорение в 3-10 раз, что при нынешнем замедлении роста тактовой частоты не такой уж пустяк.
CC>Ты знаешь какие нибудь примеры где отказались бы от контроллера в пользу реализации логики "в железе" и при этом это не было вызвано внешними факторами (работа в каких либо условиях, где контроллеру пришёл бы трындец)?
Да никто же не выступает против здравого смысла, к тому же, лично я так вопрос не ставил. Я предлагал подсмотреть полезности из практик проектирования сложных аппаратных систем, а тебя на священные войны потянуло.
CC>Поживём увидим. CC>Спорить тут бесполезно. Только практика покажет что на самом деле хорошо, а что нет.
Ну вот компонентный подход, который сейчас основной для больших систем, это напрямую подход из железа. Вообще, каких-нибудь 15-20 лет назад программисты не стояли столь далеко от "железячников"... это сейчас, ввиду все большей специализации все более теряется связь, вплоть до того, что программисты не всегда адекватно представляют себе суть происходящих во время работы их программы вещей.
V>>И ты не заметил, что плане аппаратуры я упор делал на надежность. CC>С надёжностью в электронике серебряной пули тоже нет. CC>Сколько людей и сколько усилий тратится на выпуск очередного Intel Core? Какова цена исправления ошибки при реализации в железе и в софте для производителя контроллеров?
Правильно, в железе очень, нет ОЧЕНЬ велика цена каждой ошибки, поэтому инструменты, практики и процессы заточены для достижения максимальной надежности, и здесь сектору ПО еще долго выхлопными газами дышать, ибо сама культура разработки малость другая. Я и не агитирую за тупой перенос методологий (хотя, советские ГОСТЫ на выпуск изделий на выч.технику и ПО были очень похожи), но посмотреть, что происходит — всегда полезно.
CC>Что будет с софтом если вложить в него столько бабла и спецов, поставив такие же жёсткие требования к качеству? Полагаю что с надёжностью будет не хуже
Ну да, уровень спецов чуть выше, чем в среднем в ПО, ибо сейчас в ПО не идут только ленивые. Но и не только в уровне дело. Жесткие требования относительно надежности не достигаются сами по себе, этих спецов, чтобы от них польза была, еще надо поставить в рамки определенного процесса, где будет обязательным и расчет и моделирование (что практически всегда отсутствует в современной разработке ПО). А ведь до 90% потенциальный проблем обнаруживается еще на этом этапе. Да и железячники всячески пользуются автоматизацией верифицирования решений, а у нас программисты даже FxCop не особо пользуют (хотя иснтрумент буквально начального уровня). Профайлинг — так вообще редкость в ПО разработке, что дико для железячников и т.д.
Здравствуйте, alpha21264, Вы писали:
A>Вот почему я не могу перейти с nedit на что-то типа Визуал-студии. A>Nedit позволяет разложить на рабочем столе несколько файлов (одновременно видимых). A>А студия не позволяет. A>И мне в студии "неудобно". A>
Одновременно видимые фалы можно и в студии сделать — расщепить надвое окно редактора. Но что-то одновременно на 2-3 окна кода смотреть желания не возникало. Разве что при отладке.
Здравствуйте, Mr.Cat, Вы писали:
V>>Пока что развитие процессоров говорит ровно об обратном, все больше делается в железе того, что раньше делал софт. MC>Ну по мне так в железе делаются оптимизации типичных софтовых задач, а не полноценные решения. Та же аппаратная поддержка виртуализации. И то, многое до сих пор остается чисто софтовым, та же сборка мусора (хотя ведь были исследования). Не? А то б сидели мы сейчас программировали лисп-машины.
The SEAforth 40C18 is an array of 40 fully functional CPUs operating asynchronously on a monolithic die.
...
Featuring the smallest core size design (0.13 mm2), the SEAforth chip consumes 28 times less power while running 240 times faster than competing architectures.
А другого пути получить больше отдачи на ватт-мощности и нет, потому как специализированные решения (т.е. высокоуровневые команды) всегда будут лучше универсальных.
В любом случае, не волнуйся, ты по-прежнему будешь писать на ЯВУ, какая разница, какой там ассемблер...
Там среднее время на выполнение одной ВЫСОКОУРОВНЕВОЙ команды 1.3нс, да 40 ядер, да это выполнение высокоуровневых команд с примерной частотой 30ГГц за смешные деньги... застрелиться и не жить. БМВ и прочие на его основе делают свою автомобильную электронику.
Здравствуйте, Кэр, Вы писали:
VD>>Руки быстро устанут. Лучше уж силой мысли...
Кэр>Зависит от того, как монитор расположен. Если под наклоном внизу — наподобие чертежного стола, то я не думаю, что устанут.
Здравствуйте, alpha21264, Вы писали:
A>Я юниксоид, по этому Винду вижу редко. A>Просто сравниваю с Юниксом. A>А в КДЕ два монитора — это один-единственный рабочий стол. A>По этому абсолютно любая программа может быть на одном мониторе, на другом, A>и полвовина окна на одном, а другая на другом. И выезжать за пределы мониторов как вправо так и влево.
Это можно. Невозможно было другое: есть один проект (одна IDE для него) с кучей файлов исходников. Нельзя было редактировать в рамках одной IDE каждый файл в произвольном месте произвольного монитора.
P.S. Мне KDE тоже нравится гораздо больше виндовского эксплорера. Но работа такая, что выбора нет.
Здравствуйте, Константин Б., Вы писали:
КБ>И растянуть вручную студию на два монитора было тоже конечно же возможно.
Так неудобно. Выдёргивать окошки — это правильный путь.
Здравствуйте, Silver_s, Вы писали:
S_>Одновременно видимые фалы можно и в студии сделать — расщепить надвое окно редактора. Но что-то одновременно на 2-3 окна кода смотреть желания не возникало. Разве что при отладке.
.h и .cpp файл держать одновременно открытыми намного удобней на двух мониторах. И это как при разработке чего-то своего, так и при изучении сторонних исходников.
Здравствуйте, WolfHound, Вы писали:
DD>>Вопрос собственно говоря следующий — имеет ли подобная технология право на жизнь, или это просто никому не нужное украшательство, за которым приятно наблюдать, но не работать? WH>Для поддержки может быть удобно. WH>Для написания нового кода не думаю.
Здравствуйте, WolfHound, Вы писали:
WH>Тут все хуже чем кажется. WH>Проблема с картинками в том что они работают пока задача маленькая. WH>Но как только задача становится большой тушите свет.
Тебя никто не заставляет открыть вообще все.
В современных ИДЕ много средств для навигации
Логично предположить, что для пузырков кода средства навигации тоже будут богато представлены.
Например, можно развить идею UML и многое писать буквально мышом.
Здравствуйте, AndrewVK, Вы писали:
LVV>>>>3. Для обучения Компонентный паскаль НАМНОГО лучше С++. AVK>>>О да. LVV>>По мне, чем на старом-старом ТурбоПаскале учить, так гораздо лучше учить в школе на Компонентном Паскале в БлэкБоксе.
AVK>А еще лучше использовать для этого Java.
