Добро пожаловать,
Свежие материалы
Обсуждения
Микропроцессор "Эверест" (1)
Запрет регистрации на osrc.info (1)
Ответ Javе и Flash'у (70)
Новая программа поддержки от Microsoft (2)
Solaris будет портирован на Itanium и POWER? (3)
9 декабря вышла новая сборка Xameleon (9)
рассылка (2)
ЗРОС (3)
Новый стиль OSRC.info (2)
Обсуждение статьи "Взгляд на развитие YellowTAB" (124)В Сети
Гостей: 5, Пользователей: 0 ...
рекорд он-лайн: 2015
(Пользователей: 1, Гостей: 2014) в 29.03.2010 00:07
Пользователей: 1007
Новичок: alicemokas
рекорд он-лайн: 2015
(Пользователей: 1, Гостей: 2014) в 29.03.2010 00:07
Пользователей: 1007
Новичок: alicemokas
| Центр информации по операционным системам :: Форумы :: Общие :: Разное |
|
<< Предыдущая тема | Следующая тема >> |
| Язык как основа операционной системы | ||
| Переход на страницу 1 2 3 [4] 5 ... 15 16 17 | |
|
Модераторы: Roman I Khimov, Wanderer, Dron
|
| Автор | Добавил | ||
| Chizh |
| ||
 ID пользователя #90 Зарегистрирован: Понедельник 13.09.2004 18:42Сообщений: 170 | Dron написал(а) ... В .Net есть и C++, называется "Managed C++", потому что с автоматическим менеджером памяти.Мне кажется что писать на одном языке - недемократично... В этом плане среди всех вариантов выделяется многоязыковая NET. НО лично меня душит жаба тратить свои мегагерцы на эмуляцию...  Поэтому я всетаки голосую за C++. и за реальный код!Dron написал(а) ... С какой точки зрения неудобнее? Типобезопасные языки гарантируют безошибочную работу программы на 90% даже по факту безошибочной компиляции. Т.е. если произошло чудо, что прога скомпилировалась Но чем надежнее и безопаснее система - тем неудобнее ею пользоваться... закон жизни блин... это уже 90% уверенности, что ошибок нет. Это же круто | ||
| Наверх |
| ||
| Dron |
| ||
   ID пользователя #13 Зарегистрирован: Понедельник 05.07.2004 11:16Местонахождение: Москва Сообщений: 651 | Alexander написал(а) ... Dron написал(а) ... С какой точки зрения неудобнее? Типобезопасные языки гарантируют безошибочную работу программы на 90% даже по факту безошибочной компиляции. Т.е. если произошло чудо, что прога скомпилировалась Но чем надежнее и безопаснее система - тем неудобнее ею пользоваться... закон жизни блин... это уже 90% уверенности, что ошибок нет. Это же круто Я говорю не про программистов... мы же не для программистов пишем... Неудобнее в частности тем, что медленнее. Типобезопасные языки существуют и для реальных платформ... Я согласен, что осознание того факта, что ты не можешь непреднамеренно порушить память - оно облегчает и упрощает процесс программирования. Но это вовсе не означает, что в противном случае (на типоопасном языке) ты непременно ее порушишь... Поэтому это не панацея. К тому же не только нарушениями памяти страдают современные программы. Одну из двух вечных российских проблем можно, в принципе, решить с помощью асфальтоукладчиков и катков. А вот с дорогами, конечно, будет труднее... Андрей Валяев | ||
| Наверх |
| ||
| ossadchy |
| ||
| ID пользователя #941 Зарегистрирован: Среда 10.10.2007 22:55Местонахождение: Украина, Николаевская обл., г. Первомайск Сообщений: 181 | Dron написал(а) ... Я говорю не про программистов... мы же не для программистов пишем... Неудобнее в частности тем, что медленнее. 1. Даже Smalltalk может быть быстрей C++, с Self та же история 2. Чем удобней платформа для разработки приложений тем больше шансов что для нее будет в скором времени написанов все необходимое Dron написал(а) ... Типобезопасные языки существуют и для реальных платформ... Я согласен, что осознание того факта, что ты не можешь непреднамеренно порушить память - оно облегчает и упрощает процесс программирования. Но это вовсе не означает, что в противном случае (на типоопасном языке) ты непременно ее порушишь... Поэтому это не панацея. К тому же не только нарушениями памяти страдают современные программы. 1. Утечки памяти, некорректные указатели -- самые распространенные ошибки и самые труднообнаруживаемые 2. Надо всегда держать в голове законы Мерфи -- 1. Любая ошибка, которая может вкрасться в любой расчет, вкрадется в него. -- 2. Любая ошибка в любом расчете будет нацелена на причинение наибольшего вреда. P.S. А вообще все очень сильно напоминает спор 2х летней давности  [ Редактирование Понедельник 15.10.2007 13:01 ] | ||
| Наверх |
| ||
| Dron |
| ||
| ID пользователя #13 Зарегистрирован: Понедельник 05.07.2004 11:16Местонахождение: Москва Сообщений: 651 | ossadchy написал(а) ... Dron написал(а) ... Я говорю не про программистов... мы же не для программистов пишем... Неудобнее в частности тем, что медленнее. 1. Даже Smalltalk может быть быстрей C++, с Self та же история 2. Чем удобней платформа для разработки приложений тем больше шансов что для нее будет в скором времени написанов все необходимое Утвеждение, что smalltalk быстрее C++, как бы это сказать - несколько некорректно. Или вот (Значения с ~ - это превосходство оппонента, а данном случае это gcc c). Возможно в некоторых аспектах Smalltalk и впереди... но в большинстве случаев он проигрывает. Я вообще очень уважаю smalltalk всяческий... только вот времени никак не хватает им заняться. И я кстати вовсе не отрицаю эмуляцию (если кто мог подумать). Я просто не вижу смысла пихaть ее куда не попадя. А так же не вижу смысла отрицать более эффективные решения. Я вообще не люблю что-то отрицать... Насильно всех под C# не посадишь... и под Smalltalk не посадишь... А вот если дать людям возможность выражать свои мысли в виде программ на том, на чем они хотят, то люди к тебе потянутся. Никакой ограниченный проект не станет общепризнанным. В лучшем случае останется уделом горстки энтузиастов... как в частности Bluebottle (вернее обероновские системы вообще). Их нету, они никому не нужны, и нигде не используются. Жалкая горстка энтузиастов - не в счет. Одну из двух вечных российских проблем можно, в принципе, решить с помощью асфальтоукладчиков и катков. А вот с дорогами, конечно, будет труднее... Андрей Валяев | ||
| Наверх |
| ||
| Chizh |
| ||
| ID пользователя #90 Зарегистрирован: Понедельник 13.09.2004 18:42Сообщений: 170 | Dron написал(а) ... Я говорю не про программистов... мы же не для программистов пишем... Неудобнее в частности тем, что медленнее. Как раз с точки зрения пользователя не будет заметно ни маллейшей разницы, потому что 50% времени занимают не процессорные рассчёты, а работа с аппаратурой (ввод с клавы, загрузка с диска/сети, печать на принтер...). Впрочем моя точка зрения такова, что для пользователя основным неудобством (если можно так сказать) являются всё-же глюки. Для большинства задач вообще современные мощности процессоров являются избыточными, поэтому оптимизация уже отошла на второй план. | ||
| Наверх |
| ||
| Dron |
| ||
| ID пользователя #13 Зарегистрирован: Понедельник 05.07.2004 11:16Местонахождение: Москва Сообщений: 651 | Alexander написал(а) ... Как раз с точки зрения пользователя не будет заметно ни маллейшей разницы, потому что 50% времени занимают не процессорные рассчёты, а работа с аппаратурой (ввод с клавы, загрузка с диска/сети, печать на принтер...). Это так, если работа с аппаратурой не будет написана на типабезопасном языке... То есть все сводится к тому что всяк сверчок, знай свой шесток... или микроскопом гвозди не забивают... Да и кроме того писать драйвера на типобезопасном языке - не очень то удобно... примитивов не хватает. Одну из двух вечных российских проблем можно, в принципе, решить с помощью асфальтоукладчиков и катков. А вот с дорогами, конечно, будет труднее... Андрей Валяев | ||
| Наверх |
| ||
| Hmmm |
| ||
  ID пользователя #719 Зарегистрирован: Среда 09.08.2006 11:29Местонахождение: Москва Сообщений: 108 | Alexander написал(а) ... Dron написал(а) ... В .Net есть и C++, называется "Managed C++", потому что с автоматическим менеджером памяти.Мне кажется что писать на одном языке - недемократично... В этом плане среди всех вариантов выделяется многоязыковая NET. НО лично меня душит жаба тратить свои мегагерцы на эмуляцию... Поэтому я всетаки голосую за C++. и за реальный код!Dron написал(а) ... С какой точки зрения неудобнее? Типобезопасные языки гарантируют безошибочную работу программы на 90% даже по факту безошибочной компиляции. Т.е. если произошло чудо, что прога скомпилировалась Но чем надежнее и безопаснее система - тем неудобнее ею пользоваться... закон жизни блин... это уже 90% уверенности, что ошибок нет. Это же круто Это не круто, это удобно для задачек уровня "Hello, World!" Типобезопасный язык всего нвсего гарантирует правильность диапазонов значений, но никак не может гарантировать правильность расчетов. Банальнейшая ошибка с порядком скобок в логическом выражении может привести к странным последствиям. Да и 90% ошибок, как известно, находятся за 10% времени. Так что оптимизация дебаггинга на 10% это не существенно. Самая большая головная боль начинается при отладке многопоточных приложений, а тут никакая типизация не спасет. Можно конечно на каждую разделяемую переменную тупо вешать mutex, но это либо преведет к dead locks либо катастрофически замедлит программу. Про сборщики мусора я уже высказывался, они не избавляют от ошибок в проектировании, они позволяют вам считать что ошибок нет. Чувствуете разницу? Негодный продукт можно начинать продавать сразу, понадеявшись исправить его потом. Но кто будет этим заниматься, когда деньги уже пошли? Думаете что в новой версии избежите ошибок? Не надейтесь, потому что опыта исправления прежних у вас нет, а сборщик мусора позволяет забить на отлов очень неприятных багов. Считаете отладку неприятным занятием не приносящим ничего кроме головной боли? Тогда не занимайтесь программированием, это не для вас. (Разумеется я не лично Вас Alexander имею в виду) Только исправление ошибок позволяет вам научиться замечать их еще при проектировании, тем более что дебаггинг это улучшение программы, а не наоборот. | ||
| Наверх | | ||
| cmp |
| ||
| ID пользователя #279 Зарегистрирован: Понедельник 18.04.2005 15:35Сообщений: 131 | ossadchy написал(а) ... 1. Утечки памяти, некорректные указатели -- самые распространенные ошибки и самые труднообнаруживаемые просто нужно мозгом пользоваться, и писать по нормальному,это приходит после одного двух раз когда понескольку часов тупишь в код, зато потом программы становятся куда более понятными Alexander написал(а) ... Как раз с точки зрения пользователя не будет заметно ни маллейшей разницы, потому что 50% времени занимают не процессорные рассчёты, а работа с аппаратурой (ввод с клавы, загрузка с диска/сети, печать на принтер...). Задача в удовлетворении большенства не стоит, работа программиста в том и заключается чтобы отработать все варианты и если уж не выполнить задачу с успехом, то покрайней мере сообщить о причине ошибки.. Большенство компов именно под завязку нагруженны всякими антивирами, майл агентами, неро бурнинг ромами, так что трей на пол экрана, и каждая подобная хрень пытается использовать мега стилизованное окно со всякой всплывающей лабудой, все знают прикол про то с какой частотой мс должен обновлять ос, чтобы юзеры не заметили удвоение производительности, поэтому не думаю, что стоит вот так легко прыгать из огня в полымя. В мире проблемы подобного характера решаются при помощи простых и понятных формул, и делают это экономисты, оперитуя понятиями затрат человеко-часов на разработку, простоя оборудования при не занятости и повышением энергопотребления при вторичных расчетах (как то имеет или не имеет право процесс лезть вон в тот сегмент памяти), а еще частота использования, период пока что-нить на замену не напишут и тд. | ||
| Наверх | | ||
| ossadchy |
| ||
| ID пользователя #941 Зарегистрирован: Среда 10.10.2007 22:55Местонахождение: Украина, Николаевская обл., г. Первомайск Сообщений: 181 | Dron написал(а) ... Это так, если работа с аппаратурой не будет написана на типабезопасном языке... То есть все сводится к тому что всяк сверчок, знай свой шесток... или микроскопом гвозди не забивают... Да и кроме того писать драйвера на типобезопасном языке - не очень то удобно... примитивов не хватает. 1. Есть примеры, которые показывают что как раз УДОБНО писать драйвера на типобезопасны языках, а учитывая что баги в драйверах -- причина нестабильности ОС(см. статьи о Minix 3), то это еще и делает систему стабильней 2. Примитивы можно оформить в виде классов и все получается очень стройно 3. Типобезопасный язык -- не обязательно ограниченный в своих возможностях и интерпретируемый 4. При обмене данными с большинством внешних устройств скорость этого обмена ограничивается характеристиками устройств | ||
| Наверх |
| ||
| ossadchy |
| ||
| ID пользователя #941 Зарегистрирован: Среда 10.10.2007 22:55Местонахождение: Украина, Николаевская обл., г. Первомайск Сообщений: 181 | cmp написал(а) ... ossadchy написал(а) ... 1. Утечки памяти, некорректные указатели -- самые распространенные ошибки и самые труднообнаруживаемые просто нужно мозгом пользоваться, и писать по нормальному,это приходит после одного двух раз когда понескольку часов тупишь в код, зато потом программы становятся куда более понятными 1. см. законы Мерфи 2. Вы пишете без багов? Значит вы пишете только приложения класса: Hello World. Ошибки в коде были есть и будут -- особенно в серьезных проектах, и языковые средства позволяют избежать НЕ ВСЕХ но ЧАСТИ этих ошибок, при чем не малой части. 3. Не думаю что кто-то из присутствующих здесь не пользуется мозгом cmp написал(а) ... Задача в удовлетворении большенства не стоит, работа программиста в том и заключается чтобы отработать все варианты и если уж не выполнить задачу с успехом, то покрайней мере сообщить о причине ошибки.. Большенство компов именно под завязку нагруженны всякими антивирами, майл агентами, неро бурнинг ромами, так что трей на пол экрана, и каждая подобная хрень пытается использовать мега стилизованное окно со всякой всплывающей лабудой, все знают прикол про то с какой частотой мс должен обновлять ос, чтобы юзеры не заметили удвоение производительности, поэтому не думаю, что стоит вот так легко прыгать из огня в полымя. В мире проблемы подобного характера решаются при помощи простых и понятных формул, и делают это экономисты, оперитуя понятиями затрат человеко-часов на разработку, простоя оборудования при не занятости и повышением энергопотребления при вторичных расчетах (как то имеет или не имеет право процесс лезть вон в тот сегмент памяти), а еще частота использования, период пока что-нить на замену не напишут и тд. и какой вывод? | ||
| Наверх |
| ||
| Переход на страницу 1 2 3 [4] 5 ... 15 16 17 | |
Powered by e107 Forum System