Добро пожаловать,
Свежие материалы
Обсуждения
Микропроцессор "Эверест" (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 ... 15 [16] 17 | |
|
Модераторы: Roman I Khimov, Wanderer, Dron
|
| Автор | Добавил | ||
| Dron |
| ||
   ID пользователя #13 Зарегистрирован: Понедельник 05.07.2004 11:16Местонахождение: Москва Сообщений: 651 | Если у вас мания преследования, это еще не значит, что за вами не следят...  В том то и проблема, что я наверное не хочу ограничивать возможности разработчиков одним языком... Вавилонскую башню так и не смогли построить... Одну из двух вечных российских проблем можно, в принципе, решить с помощью асфальтоукладчиков и катков. А вот с дорогами, конечно, будет труднее... Андрей Валяев | ||
| Наверх |
| ||
| Chizh |
| ||
 ID пользователя #90 Зарегистрирован: Понедельник 13.09.2004 18:42Сообщений: 170 | Dron, типобезопасных языков много. Они могут быть и автономными, и надстройками над безопасным рантаймом системы. А виртуальную Вавилонскую башню наверно легче построить, тем реальную | ||
| Наверх |
| ||
| ossadchy |
| ||
| ID пользователя #941 Зарегистрирован: Среда 10.10.2007 22:55Местонахождение: Украина, Николаевская обл., г. Первомайск Сообщений: 181 | Chizh написал(а) ... типобезопасных языков много скажу больше -- в рамкай той же Java можно достаточно успешно эмулировать x86... или еще одно: спокойно можно реализовать для платформы Java бэкэнд для GCC... и даже больше и то и другое уже сделано )) [ Редактирование Четверг 22.11.2007 00:34 ] | ||
| Наверх |
| ||
| drinian |
| ||
 ID пользователя #966 Зарегистрирован: Четверг 13.12.2007 03:09Сообщений: 3 | Весьма интересная и поучительная дискуссия. Добавлю 5 копеек) 1. Насколько понял противопоставляются "типобезопасные" языки (Smalltalk, Obj-C, Java, C#) и "нетипобозопасные" (C++, C). Немного не ясно, что вкладывается в термин. Если понимать буквально, т.е. дополнительный контроль ошибок на этапе компиляции за счет информации о типах, то все, кроме Smalltalk и Objective-C являются типобезопасными (хотя C конечно клинический случай;)) 2. ОО-парадигма конечно интересная и плодотворная, но кто сказал, что она абсолютна? При чтении иногда возникало ощущение "назад в 90-е", когда венцом творения считалась гомоморфная иерархия с одним предком. Сейчас мы имеем интерфейсы, делегаты, микс-ины, дженерики, дискуссии inheritance vs composition и еще не знаю что. Тесно реальному миру в прокрустовом ложе "идеального ООП" (читать "Smalltalk"). А например, функциональщики вообще спокойно все эти годы обходятся без наследования и полиморфизма;) 3. Если продолжать тему "типобезопасности", то из представленных языков на мой взгляд лидирует как раз C++ с его мощной системой шаблонов и перегрузок, позволяющей избавиться от динамического полиморфизма и перенести большинство ошибок времени выполнения в ошибки компиляции. Это хорошо, потому что многие программы должны работать и при отсутствии программиста;) 4. Кроме того C++ лидирует и в плане гибкости. Нужен костыль в виде метаинформации о типах? Используйте RTTI или статические списки типов. Нужно безопасное/быстрое выделение памяти? Используйте сборщик мусора, умные указатели, аллокаторы и т.д. Хотите быть ближе к телу - ассемблерные вставки. Не верите в цветной телевизор в виде ООП - можете писать функции без классов (ужас!;)) В сравнении с этим имеем тоталитарные (ну или по крайней мере авторитарные) песочницы, где повторяются мантры: "все есть объект", "сборщик мусора - хорошо", "промежуточный код - хорошо" и т.д. По-моему действительно хорошо в прикладном программировании, но никак не в системном. (Дабы не заподозрили в плюсизме сообщу, что по роду работы приходится иметь дело в основном с шарпом). 5. Пугает общий тренд: выпускаем процессоры с какой-то системой команд, потом придумываем всякие полезные расширения к ней, потом говорим, что он "плохой" и придумываем "хороший" - стековый. Потом пишем универсальный замедлитель позволяющий притворяться, что "плохой" на самом деле "хороший" и уже для "хорошего" пишем программы. What's the catch? (больше даже пугает не сама тенденция, а количество людей, которые считают, что это нормально;)) Все высказывания расценивать как имхо случайного прохожего, со своим логически не обоснованным мировоззрением, а не попытку развязать лингвистические войны:) | ||
| Наверх | | ||
| ossadchy |
| ||
| ID пользователя #941 Зарегистрирован: Среда 10.10.2007 22:55Местонахождение: Украина, Николаевская обл., г. Первомайск Сообщений: 181 | 1. имеется в виду(уже где-то писал) что ни одна операция не приводит к нарушению структуры объекта.. не путаем с строгой типизацией.. 2. все это мы имеем от того что софтверные гиганты выбрали строго типизированные языки... все это(ну или аналогичные вещи) конечно приходится использовать когда пишем на C++, Java, C#... 3. не путаем с строгой типизацией.. 4. скажем так... это мнение традиционное, еще слишком мало было сделано чтоб доказать обратное: что все хорошее в прикладном программировании хорошо и в системном.. не скажу что это действительно так, но есть проекты подающие надежды 5. ну наслоение виртуальных машин -- это общая практика построения столь сложных систем как ЭВМ... и этот подход стар как мир компьютеров... | ||
| Наверх |
| ||
| drinian |
| ||
| ID пользователя #966 Зарегистрирован: Четверг 13.12.2007 03:09Сообщений: 3 | 1. По-моему как раз напротив: при отсутствии строгой типизации просто невозможно контролировать нарушения структуры объектов. Механизмы ее реализации (статическая, динамическая) могут быть разные, но присутствовать она должна. 2. Судя по набору языков, имеется ввиду, что софтверные гиганты выбрали языки со статической типизацией и поэтому нам приходится использовать подобные "костыли". Возьмем языки с динамической типизацией: Self напичкан делегатами, Ruby поддерживает mixin'ы, в Objective-C наличествуют интерфейсы (хотя и называются протоколами). Имхо, методы проектирования слабо зависят от конкретного языка, а то, что эти методы вообще возникли показывает наличие проблем "чистого" наследования. 3. Не путаем со статической типизацией. Т.е. контроль типов может осуществляться и на этапе компиляции и на этапе выполнения. 4. На мой взгляд у них разные приоритеты: для системного ПО более важны надежность и эффективность использования имеющегося оборудования, для прикладного на первый план выходит скорость разработки. Различные цели требуют различных инструментов и методов. 5. Никоим образом не отрицал полезность введения уровней абстракции. Я имел ввиду: нет ли лишнего звена в существующей цепочке: вычислительное ядро -> эмулятор x86 -> эмулятор виртуальной машины -> байт-код? Мне эта ситуация напоминает параллельные измерения. В одном измерении мы оптимизируем схемотехнику, технологические процессы, разгоняем, инкрементируем число ядер и кеш, добавляем MMX/SSE. Можем мы теперь написать программу для этого замечательного процессора? Нет, а то посадят в "песочницу" (sandbox). Программы мы можем писать для совершенно другой машины, другой архитектуры, другой компании. Если стековая машина более высокоуровневая и безопасная (сложно с этим спорить), так давайте ее и впаяем в матплату, а не будем играть в раздвоение сознания. | ||
| Наверх | | ||
| ossadchy |
| ||
| ID пользователя #941 Зарегистрирован: Среда 10.10.2007 22:55Местонахождение: Украина, Николаевская обл., г. Первомайск Сообщений: 181 | drinian написал(а) ... 1. По-моему как раз напротив: при отсутствии строгой типизации просто невозможно контролировать нарушения структуры объектов. Механизмы ее реализации (статическая, динамическая) могут быть разные, но присутствовать она должна. Не правда ваша. Эти 2 вещи с собой не связаны, как раз C++ позволяет нарушить внутреннюю структуру объекта, хотя он строго типизирован... По поводу надежности: около 90% заводов по производству микропроцессоров используют управляющее ПО на Smalltalk. drinian написал(а) ... 2. Судя по набору языков, имеется ввиду, что софтверные гиганты выбрали языки со статической типизацией и поэтому нам приходится использовать подобные "костыли". Возьмем языки с динамической типизацией: Self напичкан делегатами, Ruby поддерживает mixin'ы, в Objective-C наличествуют интерфейсы (хотя и называются протоколами). Имхо, методы проектирования слабо зависят от конкретного языка, а то, что эти методы вообще возникли показывает наличие проблем "чистого" наследования. Для Self - делегаты, вообще единственный подход реализации наследования. Objective-C - в него ввели и статическую типизацию и протоколы(интерфейсы), но если копнуться глубже, то это все результат "сращивания" Smalltalk и С - естественно "на стыке" появились проблемы, которые решали именно введением деления на ИНТЕРФЕЙС и РЕАЛИЗАЦИЮ, ПРОТОКОЛОВ и пр. drinian написал(а) ... 3. Не путаем со статической типизацией. Т.е. контроль типов может осуществляться и на этапе компиляции и на этапе выполнения. При чем есть еще такое понятие как duck-typing. drinian написал(а) ... 4. На мой взгляд у них разные приоритеты: для системного ПО более важны надежность и эффективность использования имеющегося оборудования, для прикладного на первый план выходит скорость разработки. Различные цели требуют различных инструментов и методов. Ну результаты исследований показывают что можно достичь практически той же производительности системы, увеличив производительность труда программиста. drinian написал(а) ... 5. Никоим образом не отрицал полезность введения уровней абстракции. Я имел ввиду: нет ли лишнего звена в существующей цепочке: вычислительное ядро -> эмулятор x86 -> эмулятор виртуальной машины -> байт-код? Мне эта ситуация напоминает параллельные измерения. В одном измерении мы оптимизируем схемотехнику, технологические процессы, разгоняем, инкрементируем число ядер и кеш, добавляем MMX/SSE. Можем мы теперь написать программу для этого замечательного процессора? Нет, а то посадят в "песочницу" (sandbox). Программы мы можем писать для совершенно другой машины, другой архитектуры, другой компании. Если стековая машина более высокоуровневая и безопасная (сложно с этим спорить), так давайте ее и впаяем в матплату, а не будем играть в раздвоение сознания. Ну инструкции виртуальной машины не обязательно должны быть интерпретированы, а возможна и трансляция в код целевой машины, как "на лету" так единожды. | ||
| Наверх |
| ||
| drinian |
| ||
| ID пользователя #966 Зарегистрирован: Четверг 13.12.2007 03:09Сообщений: 3 | Эти 2 вещи с собой не связаны, как раз C++ позволяет нарушить внутреннюю структуру объекта, хотя он строго типизирован Если в C++ сознательно были введены механизмы обхода типизации, то это нисколько не противоречит идее о том, что для контроля обращений к объектам нам необходимо иметь информацию об их типах: на этапе компиляции и/или выполнения. около 90% заводов по производству микропроцессоров используют управляющее ПО на Smalltalk Можно приводить разные отрасли/ниши, где доминирует тот или иной язык. Само по себе это ничего не доказывает. Для Self - делегаты, вообще единственный подход реализации наследования. Именно об этом я и говорил: набор выразительных средств в современных языках не исчерпывается классическим наследованием а-ля Smalltalk. это все результат "сращивания" Smalltalk и С - естественно "на стыке" появились проблемы, которые решали именно введением деления на ИНТЕРФЕЙС и РЕАЛИЗАЦИЮ, ПРОТОКОЛОВ и пр. На мой взгляд интерфейс + реализация в Obj-C вполне соответствуют понятию класса в Smalltalk. Какие проблемы "на стыке" привели к введению протоколов? duck-typing Валидность посылки сообщения/вызова метода определяется в момент этой самой посылки/вызова => контроль осуществляется на этапе выполнения => динамическая типизация можно достичь практически той же производительности системы, увеличив производительность труда программиста Немного не понял, как это коррелирует. Увеличив производительность труда программиста, мы сократим сроки создания системы, но почему она сама должна стать быстрее? инструкции виртуальной машины не обязательно должны быть интерпретированы, а возможна и трансляция в код целевой машины, как "на лету" так единожды Под эмулятором не имелся ввиду интерпретатор в обязательном порядке. Это аполитично в эпоху JIT-компиляции;) Но и с JIT не все так радужно в плане эффективности. Так не проще ли откомпилировать программу под ту машину, на которой она реально будет выполняться вместо введения дополнительной виртуальной машины? | ||
| Наверх | | ||
| ossadchy |
| ||
| ID пользователя #941 Зарегистрирован: Среда 10.10.2007 22:55Местонахождение: Украина, Николаевская обл., г. Первомайск Сообщений: 181 | Для начала к вопросу о повышении производительности. Что дает нам разработка системы на типобезопасном языке(в который не включены операции непосредственного обращения к произвольным областям памяти): 1. возможность размещения всех компонент в одном адресном пространстве. - отсутствие необходимости перезагрузки TLB -- одной из самых медленных и часто выполняющихся операций 2. отсутствие необходимости переключения в режим супервизора -- тоже очень частая операция 3. отсутствие необходимости тратить дополнительные ресурсы на локальный IPC -- также, прошу заметить, немаловажно Теперь к вопросу о JIT. Увы но архитектура современных процессоров сильно отстает от задач которые надо решать повседневно. Отсюда и необходимость создания дополнительных прослоек. Можно строить Java и MSIL процессоры, но это дорого, да и технологии все еще развиваются. С другой стороны, объектно-ориентированный, типобезопасный язык не обязан быть интерпретируемым. Пример -- компилятор Java GCJ. Да и напомню я написал "как "на лету" так и единожды"  К вопросу о Self - в данном языке единственный способ создавать иерархии прототипов -- наличие слота parent в каждом объекте, и так сделано лишь для того чтоб ИМИТИРОВАТЬ наследование в Smalltalk, и используя лишь простое наследование можно строить сколь угодно сложные системы. VCL, думаю, неплохой показатель. Ну и на закуску о C++ -- если я могу сделать с любым объектом все что хочу, хоть и заполнить случайными данными, это не есть (типо)безопасный язык. И хотелось бы подвести итоги -- против чего и за что Вы | ||
| Наверх |
| ||
| ossadchy |
| ||
| ID пользователя #941 Зарегистрирован: Среда 10.10.2007 22:55Местонахождение: Украина, Николаевская обл., г. Первомайск Сообщений: 181 | Тесно реальному миру в прокрустовом ложе "идеального ООП" (читать "Smalltalk"). или наоборот? | ||
| Наверх |
| ||
| Переход на страницу 1 2 3 ... 15 [16] 17 | |
Powered by e107 Forum System