Оберон-технология: особенности и перспективы |
Тематика обсуждения: Оберон-технология. Особенности, перспективы, практическое применение.
Всего в теме 6256 сообщений
Добавить свое сообщение
Отслеживать это обсуждение Обсуждение из раздела Школа ОБЕРОНА
№ 4836 06-06-2007 05:40 | |
Ответ на »сообщение 4827« (Илья Ермаков)
___________________________
Времена временами, а отрасль системного программирования никуда не денется - и не рубике с ФП вы будете ОС-ы писать...
Да и не в системном - еще учтите, что с 40-летней давности Це народ перевести на Паскали не удается, а Вы - Хаскель :-) Они до сих пор от BREAK в цикле отказываться не хотят, а Вы им - отказаться от присваивания :-)
В последнее время, со всё большим распространением многоядерных архитектур, всё болше начинает распространяться и мнение, что Си - уже устарел и не позволяет достаточно легко и просто использовать все возможности множества ядер...
Так что хочешь-не хочешь, а придётся постепенно перебираться на более высокоуровневые языки...
Не то, что бы Хаскелл в этом плане был лучше всех, но всё же... Время Си, Паскаля, Оберона постепенно проходит... Наступает время Ерланга, Data Parallel Haskell, Зонона, в конце концов...
Хотя Майкрософт тоже не дремлет - уже делают версии .NET'а для DSP-процессоров. Дальше - больше...
№ 4835 06-06-2007 05:37 | |
Ответ на »сообщение 4834« (___)
___________________________
Nemerle смотрели?
Да, некоторое время назад смотрел. Разработка поляков с участием наших. Вроцлавский университет. Руководит проф. Leszek Pacholski. Разработка под .NET (можно под Linux, если используется Mono). Активно используют механизм макросов. Вплоть до изменения синтаксиса языка. Сделан как надстройка над C#, в которой много всяких "вкусностей". Смесь ООП и ФП (C#+ML). ФП больше на уровне реализации методов. Предпосылки для скриптового программирования. На уровне модулей наследует костыли C# (пространства имен и иже с ними). В общем, гибок, как гусеница. Но я предпочитаю более жесткие, шарнирные конструкции. Вроде людей.
№ 4834 06-06-2007 05:06 | |
Ответ на »сообщение 4833« (Руслан Богатырев)
___________________________
Наверное, идеал в том, чтобы на фон-неймановской архитектуре фундамент был императивный. Какая-то часть может быть надстроена на ФЯ, другая на ИЯ. А в прикладном -- жонглировать этими подходами сам Бог велел. Только я не уверен, что впихивать столь разные миры в один язык -- разумно. Наверное, лучше все же обеспечивать их сосуществование и взаимодействие. Да и вообще -- зачем нужны гибриды? Чуток от того, чуток от этого... Недоделанное одно, недоделанное другое, да замешанные в одном тесте. Гибриды возникли из потребности разработчиков языков объять необъятное. Чтобы все можно было делать в их родном и любимом языке. Только нам, потребителям, от этого какая польза? Учить один язык вместо нескольких? По-моенму, это чисто обывательский подход.
Nemerle смотрели?
№ 4833 06-06-2007 02:09 | |
Ответ на »сообщение 4832« (FR)
___________________________
А преимущества у ФЯ и перед паскалем и си в том что для написанных функционально кусков гораздо легче вывести формальные спецификации и доказательства корректности.
А недостатки у ФЯ перед тем же Обероном в том, что в ФЯ прячется императив вовнутрь, чтобы работать с ним через заднее крыльцо. Не стоит переоценивать доказательства корректности. Доказательное программирование имеет ограниченную сферу применения. Доказывать корректность надо не постфактум, а изначально строить корректный код, к чему должен стимулировать язык. В программировании (теоретическом) немало проблем. Достаточно упомянуть проблему "мертвого кода": та часть программы, которая ни при каких условиях не выполняется. В соответствии с теоремами Райса и Успенского, доказанными в 1950-е годы, это задача теоретически неразрешима. Системное программирование -- это та сфера, где с одной стороны нужна максимальная надежность (а значит, доказательное программирование), а с другой -- эффективность и недетерминированность (real-time). Как-то эти вещи между собой не очень дружат.
Императивное программирование -- это ручное управление с возможностью перехода в автопилот (когда внутри него применяются формальные модели: конечные автоматы, сети Петри и др.). Функциональное программирование -- это автопилот с переходом на ручное управление. Сам переход на ручное управление в ФП весьма лукав. Сказать, где можно уже напрочь забыть о корректности -- непросто.
Наверное, идеал в том, чтобы на фон-неймановской архитектуре фундамент был императивный. Какая-то часть может быть надстроена на ФЯ, другая на ИЯ. А в прикладном -- жонглировать этими подходами сам Бог велел. Только я не уверен, что впихивать столь разные миры в один язык -- разумно. Наверное, лучше все же обеспечивать их сосуществование и взаимодействие. Да и вообще -- зачем нужны гибриды? Чуток от того, чуток от этого... Недоделанное одно, недоделанное другое, да замешанные в одном тесте. Гибриды возникли из потребности разработчиков языков объять необъятное. Чтобы все можно было делать в их родном и любимом языке. Только нам, потребителям, от этого какая польза? Учить один язык вместо нескольких? По-моенму, это чисто обывательский подход.
№ 4832 06-06-2007 01:31 | |
Ответ на »сообщение 4831« (Илья Ермаков)
___________________________
Да я в курсе! :-) Подробно изучал труды ФП-истов в этом направлении.
Читал длинные списки преимуществ "почему лучше писать ОС на ФП".
Подпишусь под каждым словом. Но ФП там можно вполне успешно заменить на Паскаль. Суть всех этих аргументов сводится к одному простому тезису - "так, как на Це, дальше жить нельзя, нужны высокоуровневые подходы". Про оптимальный на сегодняшний день язык системного программирования Оберон в США практически не знают, поэтому ломят сразу и без альтернатив в набирающий обороты и входящий в моду ФП. Но это не от хорошей жизни, ибо системное программирование на ФП противоестественно. Есть разделение программных систем на вычисляющие (которые занимаются преобразованиями данных, в самом широком смысле) и управляющие (которые занимаются переходами из состояния в состояние с полезным побочным эффектом). ФП для первой категории систем в ряде случаев идеален (а иногда - нет, наши и европейские ядерщики это знают). А для второй категории естественен императив, т.к. глупо отказываться от явного управления состоянием, чтобы потом все равно эмулировать его поверх функциональной машины...
Полно гибридных языков подерживающих как функциональщину так и императив например Ocaml (кстати и компилятор у него очень эффективный). А преимущества у ФЯ и перед паскалем и си в том что для написанных функционально кусков гораздо легче вывести формальные спецификации и доказательства корректности.
№ 4831 05-06-2007 15:42 | |
Ответ на »сообщение 4830« (FR)
___________________________
Ответ на »сообщение 4827« (Илья Ермаков)
___________________________
Ну на некторых ФЯ вполне возможно и OS написать.
Но для народа на самом деле лучше тот же D например.
Да я в курсе! :-) Подробно изучал труды ФП-истов в этом направлении.
Читал длинные списки преимуществ "почему лучше писать ОС на ФП".
Подпишусь под каждым словом. Но ФП там можно вполне успешно заменить на Паскаль. Суть всех этих аргументов сводится к одному простому тезису - "так, как на Це, дальше жить нельзя, нужны высокоуровневые подходы". Про оптимальный на сегодняшний день язык системного программирования Оберон в США практически не знают, поэтому ломят сразу и без альтернатив в набирающий обороты и входящий в моду ФП. Но это не от хорошей жизни, ибо системное программирование на ФП противоестественно. Есть разделение программных систем на вычисляющие (которые занимаются преобразованиями данных, в самом широком смысле) и управляющие (которые занимаются переходами из состояния в состояние с полезным побочным эффектом). ФП для первой категории систем в ряде случаев идеален (а иногда - нет, наши и европейские ядерщики это знают). А для второй категории естественен императив, т.к. глупо отказываться от явного управления состоянием, чтобы потом все равно эмулировать его поверх функциональной машины...
№ 4830 05-06-2007 15:14 | |
Ответ на »сообщение 4827« (Илья Ермаков)
___________________________
Ответ на »сообщение 4824« (FR)
___________________________
Ответ на »сообщение 4823« (Руслан Богатырев)
___________________________
По моему наиболее близки сейчас к этому современные динамические (питон, руби, и т. п.) и функциональные (хаскель, окамл, и т. п.) языки.
Вирт молодец и для своего времени создал очень хорошую вещь. Но сейчас другие времена.
Времена временами, а отрасль системного программирования никуда не денется - и не рубике с ФП вы будете ОС-ы писать...
Да и не в системном - еще учтите, что с 40-летней давности Це народ перевести на Паскали не удается, а Вы - Хаскель :-) Они до сих пор от BREAK в цикле отказываться не хотят, а Вы им - отказаться от присваивания :-)
Ну на некторых ФЯ вполне возможно и OS написать.
Но для народа на самом деле лучше тот же D например.
№ 4829 05-06-2007 15:11 | |
Ответ на »сообщение 4825« (Сергей Перовский)
___________________________
Ответ на »сообщение 4824« (FR)
___________________________
>>>Кстати из этого не следует что язык должен быть простым, наоборот он должен быть мощным (то есть позволять кратко и красиво выражать сложные абстракции)и как следствие из этого достаточно сложным.
Вот с этим тут вряд ли кто-нибудь согласится.
В смысле, что сложность позволяет просто выражаться :)
Мы постоянно спорим, что удобнее, огромная связка ключей или отмычка.
Истина, как всегда, посередине: удобнее всего небольшой набор деталей, позволяющий быстро собрать нужный ключ.
То ли у Вас понятие сложности языка экзотическое, то ли абстракции не как у всех.
Чем Вы меряете сложность языка?
Под сложностью имелось в виду в первую очередь реализация, то есть компилятор современного языка вряд ли может быть простым (как я понимаю по Вирту наооборот).
Во вторых сложность на самом деле позволяет более просто выражатся, многие абстракции в той же функциональщине сложнее и для понимания и по реализации и по теоритеческой базе большинства императивных конструкций, но они же позволяют делать код более кратким и понятным.
№ 4828 05-06-2007 14:46 | |
Ответ на »сообщение 4826« (Geniepro)
___________________________
Откуда у Вас столько злости, обиды и недовольства накопилось на нынешний софтверный рынок?
Что поделать, базар - есть базар, не академии какие-то там... Кто успел, тот и съел! :о)
Это не злость. Просто пора называть вещи своими именами. Без всяких там славословий. Молодое поколение смотрит на "новации" лидеров рынка и равняется на них. В результате все катится вниз по наклонной.
ИТ-рынок -- это не базар. Закон базара: если можешь продать дороже -- продавай! Базар превращается в рынок тогда, когда рядом с аукционом предметов потребления появляется аукцион идей и замыслов, которые подталкивают отдельных функционеров базара улучшать КАЧЕСТВО своих товаров. По сути, рынок -- это не продажа товара, а продажа качества товара. Должны быть сдерживающие факторы, которые содействует совершенствованию. Государство и наука. И не только у нас в стране. Должны быть ученые, которые будут прилюдно называть чушью то, что делают те или иные лидеры. Должны быть политики, которые поставят на место те или иные зарвавшиеся компании. И которые будут остаивать не свои шкурные интересы, а интересы граждан своей страны, интересы своего государства. Это они вполне могут сделать.
№ 4827 05-06-2007 14:38 | |
Ответ на »сообщение 4824« (FR)
___________________________
Ответ на »сообщение 4823« (Руслан Богатырев)
___________________________
По моему наиболее близки сейчас к этому современные динамические (питон, руби, и т. п.) и функциональные (хаскель, окамл, и т. п.) языки.
Вирт молодец и для своего времени создал очень хорошую вещь. Но сейчас другие времена.
Времена временами, а отрасль системного программирования никуда не денется - и не рубике с ФП вы будете ОС-ы писать...
Да и не в системном - еще учтите, что с 40-летней давности Це народ перевести на Паскали не удается, а Вы - Хаскель :-) Они до сих пор от BREAK в цикле отказываться не хотят, а Вы им - отказаться от присваивания :-)
Добавить свое сообщение
Отслеживать это обсуждение
Дополнительная навигация: |
|