Здравствуйте, TimurSPB, Вы писали:
TSP>Часто пишут о грядущей смерти C/С++ и о том что Java + .NET будущее программирования на долгие годы вперед. TSP>Я считаю, что Java и .NET просто шаг вперед к языкам и платформам которые дадут возможности управления всеми доступными ресурсами сразу на разных уровнях. От регистров процессоров до бизнес логики. Язык будущего должен давать возможность определять классы и создавать их экземпляры так, что бы можно было определять уровни доступа к ресурсам на разных уровнях.
В будущем будут писать программы сразу на смеси языков. Скажем, C/C++ для мест, узких в плане производительности или требующих интимных отношений с операционной системой, на Ерланге, Окамле или Хаскелле в "умных" местах, на Питоне в "гибких", на Яве в местах, требующих интеграции с legacy, на дотнете там, где код пишут 1000 индусов. Однополярный мир закончился
Здравствуйте, Геннадий Васильев, Вы писали:
ГВ>От текста к визуальным образам с произвольным профилированием визуализации в зависимости от текущих задач. Но, правда, мощности даже современных компьютеров на это слегка не очень хватает. Визуализируй-ка мне boost в реалтайме... В процессе разработки.
Вся эволюция культуры заключается как раз в движении от визуальных образов к тексту (не только в программировании). Думаете, тенденция к распаду нашей цивилизации таки победит?
ГВ>Задача 0: наследование имеющегося ПО. До хрена процентов которого написана на C, C++, Shell language, Perl, Visual Basic, SQL. Пока что об эту задачу обламывают зубы все без исключения.
Тут уже наметился общепринятый подход: оставляем legacy как есть, и делаем к нему интерфейс из нового кода. Новый код может быть написан на совершенно другом языке, и даже жить в другой коробке с другой операционной системой.
Здравствуйте, TimurSPB, Вы писали:
TSP>А как вы видите развитие средств разработки программ?
Как избавление 99% программистов от мыслей о низкоуровневой работе.
Не нужно быть гением-провидцем, чтобы понять, что все развитие компьютеров идет в сторону улучшения асбрагирования от железа. Вот очевидные этапы развития:
1. 40-ые года прошлого века — программирование на уровне переключения проводочков и перепаивания ламп.
2. 50-ые — программирование на уровне машинных инструкций.
3. 60-ые — переход к ассемблерам.
4. 60-70-ые — переход к "языкам высокого уровня" аля Алгол и Фртран (в последствие С, Паскаль).
5. 70-ые — переход к ООП и ФП.
6. 90-ые переход к типобезопасным и управляемым языкам. Переход к компонентным технологиям.
7. (будущее) Очевидно развитие будет идти в ту же сторону. Будет повышаться уровень языков, мощность библиотек. В программировании будет все больше цениться декларативность (причем достигаемая не обязательно с помощью ФП, а любая). Языки начнут предоставлять возможности верификации программ.
Тоже самое на уровне ОС:
1. ОС нет как класс.
2. ОС без защиты памяти и вообще почти без ничего. Есть только базовые сервисы.
3. ОС предоставляют основные сервисы. Программам не надо общаться с железом напрямую.
4. ОС с защитой памяти процессов, сменные драйверы.
5. (будущее) Управляемые и верефицируемые ОС.
Конечно исследования и пробные работы были и раньше. И, вообще, все года довольно услонвые, но общая тенденция именно такова.
Так что требовать от языков каких-то переходов на более низкий уровень — это просто смешно. В том же C# на сегодня есть конструкция unsafe. Вот только на практике ее используют крайне редко. Большей части для интеграции со "старым миром".
Самое смешное, что с точки зрения оптимизации скорости выполнения ПО высокоуровенвость и декларативность кода — это благо, а не недостаток. Пока что оптимизация находится на очень низком уровне и преимущество это скорее гипотетическое. Но со временем оно обязательно перейдет в практическую плоскость. И тогда вороченье битами станет таким же моветоном как сегодня программирование на ассемблере.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>Эх... Чует мое сердце, что скорости работы Visual Studio 6.0 уже никогда не будет
У меня она тормозила безбожно, потому как компьютер был слабенький, а писал я на С++ с использованием Томато (как его там?).
А 2008-ая студия у меня сейчас запускается весьма шустро. Я ее запускаю очень часто, так как отлаживаю интеграцию для нее же. Компьютер конечно другой. 4-х ядерный и намного более быстрый. Но и возможности стали намного большими. Да и языки сильно мощнее.
Конечно VS 2010 по началу будет казаться дико медленной. Но со временем железо догонит и перегонит. Так что и она окажется вполне шустрой. Ну, а возможности в очередной раз расширятся.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Pzz, Вы писали:
ГВ>>От текста к визуальным образам [...] Pzz>Вся эволюция культуры заключается как раз в движении от визуальных образов к тексту (не только в программировании). Думаете, тенденция к распаду нашей цивилизации таки победит?
Вот знаешь, о том же задумался. Может, идея визуализации и не совсем правильная.
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Здравствуйте, LaptevVV, Вы писали:
PD>>Эх... Чует мое сердце, что скорости работы Visual Studio 6.0 уже никогда не будет LVV>Не... Блэк-бокс вполне себе шустро работает...
Мне кажется, что его среда даже VS 6 по функциональности уступает.
Там хоть комплит есть?
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
T>Если серьёзно, то иди читай про зависимые типы.
Интересно, языки, поддерживающие зависимые типы, заставляют ли программиста описывать типы максимально точно? А то ведь можно например описать бОльшую область возращаемого значения функции, чем её реальная область значения. И какой тогда от них смысл будет, если программистам будет влом их писать.
А если функция короткая (простая), программист вообще будет считать излишним описывать. и тд.
Возможно ли в языках, поддерживающих ЗТ, подставлять уже описанную функцию (например из библиотеки) в преобразование типа? То есть программирование частично сведется к преобразованию типов.
Здравствуйте, Aleх, Вы писали:
A>Здравствуйте, thesz, Вы писали:
T>>Если серьёзно, то иди читай про зависимые типы. A>Интересно, языки, поддерживающие зависимые типы, заставляют ли программиста описывать типы максимально точно? А то ведь можно например описать бОльшую область возращаемого значения функции, чем её реальная область значения. И какой тогда от них смысл будет, если программистам будет влом их писать.
В декларативном программировании это всё расписали. Там есть ветка про зависимые типы.
A>А если функция короткая (простая), программист вообще будет считать излишним описывать. и тд.
Нет.
Функция две строки и строка типа.
Обычно — функция пять-семь строк и тип в одну строку.
Здравствуйте, LaptevVV, Вы писали:
LVV>Среды такой пока нет. Ибо существующие промышленные ПРОФЕССИОНАЛЬНЫЕ среды заточены под текстовый редактор (от уж маразм, так маразм!). Когда будут заточны под семантические модели — тогда будет тебе счастье!
Маразм — это рассматривать визуальную модель через замочную скважину, коей является любой даже 30" монитор. Для работы со средненькой моделью нужен монитор размером со стену. Вот тогда может быть и будет счастье.
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, thesz, Вы писали:
T>Здравствуйте, Aleх, Вы писали:
A>>Здравствуйте, thesz, Вы писали:
T>>>Если серьёзно, то иди читай про зависимые типы. A>>Интересно, языки, поддерживающие зависимые типы, заставляют ли программиста описывать типы максимально точно? А то ведь можно например описать бОльшую область возращаемого значения функции, чем её реальная область значения. И какой тогда от них смысл будет, если программистам будет влом их писать.
T>В декларативном программировании это всё расписали. Там есть ветка про зависимые типы.
A>>А если функция короткая (простая), программист вообще будет считать излишним описывать. и тд.
T>Нет.
T>Функция две строки и строка типа.
T>Обычно — функция пять-семь строк и тип в одну строку.
T>http://www.cs.swan.ac.uk/~csetzer/lectures/intertheo/07/interactiveTheoremProvingForAgdaUsers.html T>http://www.cs.chalmers.se/~peterd/papers/DependentTypesAtWork.pdf
A>>Возможно ли в языках, поддерживающих ЗТ, подставлять уже описанную функцию (например из библиотеки) в преобразование типа? То есть программирование частично сведется к преобразованию типов.
T>Что такое "подставлять функцию из библиотеки в преобразование типа"?
Это значит, пусть описана функция (например сортировка) описан тип аргумента(просто список) и тип результата (отсортированный список). Программист пишет преобразование типа (список => отсортированный список), и вместо преобразования компилятор подставляет функцию.
А ещё лучше так. В библиотеке описаны множество функций, работающих с одинаковыми парами тип аргумента и тип возвращаемого значения (например сортировки, но разные алгоритмы, имеющие разные характеристики, например вычислительную сложность), и компилятор на месте преобразования типа подставляет наиболее оптимальную с точки зрения производительности функцию в зависимости от того, от некоторых характеристик данных, например их размера (длины в случае списка).
Было бы вообще замечательно, если бы компилятор мог генерировать некоторые классы функций. Разумеется задача не разрешима в общем виде, но всё же в некоторых простых случаях было бы удобно, и я полагаю это возможно реализовать.
Так вот, что нибудь похожее где нибудь реализовано, или ЗТ позволяют только верифицировать код?
Здравствуйте, Pzz, Вы писали:
Pzz>Вся эволюция культуры заключается как раз в движении от визуальных образов к тексту (не только в программировании). Думаете, тенденция к распаду нашей цивилизации таки победит?
Вся _предшествующая_ эволюция культуры. Это диалектическая спираль: от визуальных образов к тексту и далее снова к визуальным образам. Не думаешь же ты, что текст и есть квинт-эссенция культуры?
А про визуализацию boost: auto_ptr — черненький параллелепипед, share_ptr — красненький.
Здравствуйте, любой, Вы писали:
Л>Здравствуйте, VoidEx, Вы писали:
Л>>>В естественном языке десятки тысяч слов (не считая научных терминов). Но общаться на нём можно, имея словарный запас в несколько десятков слов. Язык программирования должен быть таким же. VE>>Почему?
Л>Язык — это единое культурное пространство, в котором люди с разным уровнем подкованности способны понимать друг друга, не затрагивая какие-то глубокие проблемы.
Неправда. Пока не было обильного обмена информацией, люди в разных городах могли друг друга не понимать. Боюсь, что даже сейчас люди из разных поколений будут понимать друг друга крайне смутно.
Вот математика — это единое культурное пространство, правда, там нужно иметь достаточно высокий уровень подкованности.
Здравствуйте, Aleх, Вы писали:
A>>>Возможно ли в языках, поддерживающих ЗТ, подставлять уже описанную функцию (например из библиотеки) в преобразование типа? То есть программирование частично сведется к преобразованию типов.
T>>Что такое "подставлять функцию из библиотеки в преобразование типа"? A>Это значит, пусть описана функция (например сортировка) описан тип аргумента(просто список) и тип результата (отсортированный список). Программист пишет преобразование типа (список => отсортированный список), и вместо преобразования компилятор подставляет функцию.
Уже есть.
A>А ещё лучше так. В библиотеке описаны множество функций, работающих с одинаковыми парами тип аргумента и тип возвращаемого значения (например сортировки, но разные алгоритмы, имеющие разные характеристики, например вычислительную сложность), и компилятор на месте преобразования типа подставляет наиболее оптимальную с точки зрения производительности функцию в зависимости от того, от некоторых характеристик данных, например их размера (длины в случае списка).
Задайте требуемую сложность в типе — а [yrl=http://okmij.org/ftp/Haskell/number-parameterized-types.html]это уже возможно[/url], — получите требуемую функцию по выбору сложности.
A>Было бы вообще замечательно, если бы компилятор мог генерировать некоторые классы функций. Разумеется задача не разрешима в общем виде, но всё же в некоторых простых случаях было бы удобно, и я полагаю это возможно реализовать.
Значит, надо реализовать, если возможно.
A>Так вот, что нибудь похожее где нибудь реализовано, или ЗТ позволяют только верифицировать код?
Скрестите вон те две ссылки, что выше, и будет вам счастие.
Yours truly, Serguey Zefirov (thesz NA mail TOCHKA ru)
Здравствуйте, Геннадий Васильев, Вы писали:
Pzz>>Вся эволюция культуры заключается как раз в движении от визуальных образов к тексту (не только в программировании). Думаете, тенденция к распаду нашей цивилизации таки победит?
ГВ>Вот знаешь, о том же задумался. Может, идея визуализации и не совсем правильная.
Она, по-моему, сродни комиксам. С одной стороны, сложную вещь так не скажешь, т.е. уровень падает. С другой, комиксы проще для восприятия, чем текст, т.е. культура становится более массовой.
Здравствуйте, Vi2, Вы писали:
Pzz>>Вся эволюция культуры заключается как раз в движении от визуальных образов к тексту (не только в программировании). Думаете, тенденция к распаду нашей цивилизации таки победит?
Vi2>Вся _предшествующая_ эволюция культуры. Это диалектическая спираль: от визуальных образов к тексту и далее снова к визуальным образам.
Ну в принципе да, время от времени цивилизация приходит в состояние упадка. Старые достижения забываются, мир завоёвывают варвары. Потом проходит сколько-то веков, и цивилизация возрождается. Не исключено, что сейчас мы наблюдаем именно процесс упадка. Надеюсь не дожить до его завершения
Vi2>Не думаешь же ты, что текст и есть квинт-эссенция культуры?
VE>Вот математика — это единое культурное пространство, правда, там нужно иметь достаточно высокий уровень подкованности.
Чёрта с два. Одну и ту же сложную задачу обычно можно решить совершенно разными способами. Применяя разные подходы. В зависимости от того, к какой научной школе ты ближе.
Простой пример: если ты знаешь, что такое вариация функционала, ты можешь решить определённую задачу немного проще, чем просто с применением в лоб дифференциального исчисления. Но это не обязательно значит, что ты её не решишь без применения вариаций.
(Сравните: http://www.cneat.ru/lex3.html
и http://www.ispa-soft.ru/statxi/statxq2.htm)
То же касается и операционного исчисления.
Уверен, что есть ещё много областей математики, знание которых в принципе является не точным признаком квалифицированности, а только отношением к определённому разделу математики.
Pzz>В будущем будут писать программы сразу на смеси языков. Скажем, C/C++ для мест, узких в плане производительности или требующих интимных отношений с операционной системой, на Ерланге, Окамле или Хаскелле в "умных" местах, на Питоне в "гибких", на Яве в местах, требующих интеграции с legacy, на дотнете там, где код пишут 1000 индусов. Однополярный мир закончился
Врядли. Из соображений безопасности выгоднее обособить такой функционал в отдельные модули, за интеграцией/доступом к которым следить по отдельности.
ЕМНИП, это несложно. 
Если нам не помогут, то мы тоже никого не пощадим.
