Часто пишут о грядущей смерти C/С++ и о том что Java + .NET будущее программирования на долгие годы вперед.
Я считаю, что Java и .NET просто шаг вперед к языкам и платформам которые дадут возможности управления всеми доступными ресурсами сразу на разных уровнях. От регистров процессоров до бизнес логики. Язык будущего должен давать возможность определять классы и создавать их экземпляры так, что бы можно было определять уровни доступа к ресурсам на разных уровнях.

Например:
class TRenderDevice:
level {hardware}
{
.... //Тут функции с указателями, с кусками на асме и прочими произведениями суровых бородатых разработчиков
}

class TCreditCardsReader
level {high_secure}
{
.... //Тут высокоуровневые конструкции, выполняемые в управляемом окружении, написанные Java/.NET гуру
}

Спор о management/unmanagement сегодня лишен практического смысла. Интересно будет решение которое даст эффективное слияние этих подходов.
А как вы видите развитие средств разработки программ?
Вопрос скорее из области прикладной науки, чем программирования. Как должна выглядеть сама модель построения конструкций такого языка?

Здравствуйте, TimurSPB, Вы писали:

TSP>Часто пишут о грядущей смерти C/С++ и о том что Java + .NET будущее программирования на долгие годы вперед.
TSP>Я считаю, что Java и .NET просто шаг вперед к языкам и платформам которые дадут возможности управления всеми доступными ресурсами сразу на разных уровнях. От регистров процессоров до бизнес логики. Язык будущего должен давать возможность определять классы и создавать их экземпляры так, что бы можно было определять уровни доступа к ресурсам на разных уровнях.

TSP>Например:
TSP>class TRenderDevice:
TSP>level {hardware}
TSP>{
TSP>.... //Тут функции с указателями, с кусками на асме и прочими произведениями суровых бородатых разработчиков
TSP>}

TSP>class TCreditCardsReader
TSP>level {high_secure}
TSP>{
TSP>.... //Тут высокоуровневые конструкции, выполняемые в управляемом окружении, написанные Java/.NET гуру
TSP>}

TSP>Спор о management/unmanagement сегодня лишен практического смысла. Интересно будет решение которое даст эффективное слияние этих подходов.
TSP>А как вы видите развитие средств разработки программ?
TSP>Вопрос скорее из области прикладной науки, чем программирования. Как должна выглядеть сама модель построения конструкций такого языка?

Сейчас, сейчас...

I think that The Language Of The Future (TLOTF) will Facilitate Workflow Integration for E-Business. It will, Basically, Grow an Exposure of Call To Action through all Phases of и тут я устал.

Если серьёзно, то иди читай про зависимые типы.

То, что ты выдал на поверхность, лишь показывает, что ни с чем ты толком не работал. Ни про железо не знаешь, ни про драйвера, ни про разработку от железа и вверх.

Здравствуйте, TimurSPB, Вы писали:

TSP>А как вы видите развитие средств разработки программ?

От текста к визуальным образам с произвольным профилированием визуализации в зависимости от текущих задач. Но, правда, мощности даже современных компьютеров на это слегка не очень хватает. Визуализируй-ка мне boost в реалтайме... В процессе разработки.

В прочем, это породит новый язык. Текстовый. Для описания предпочтений.

TSP>Вопрос скорее из области прикладной науки, чем программирования. Как должна выглядеть сама модель построения конструкций такого языка?

Задача 0: наследование имеющегося ПО. До хрена процентов которого написана на C, C++, Shell language, Perl, Visual Basic, SQL. Пока что об эту задачу обламывают зубы все без исключения.

Здравствуйте, TimurSPB, Вы писали:

TSP> возможности управления всеми доступными ресурсами сразу на разных уровнях. От регистров процессоров до бизнес логики.

Какую проблему/проблемы это решает?

TSP> Язык будущего должен давать возможность определять классы и создавать их экземпляры так, что бы можно было определять уровни доступа к ресурсам на разных уровнях.

Тот же вопрос.

TSP>Спор о management/unmanagement

managed/unmanaged

TSP> сегодня лишен практического смысла.

Почему?

TSP> Интересно будет решение которое даст эффективное слияние этих подходов.

Слияние в каком плане? Интеграция кусков кодя разных типов и сейчас возможна, чуть хуже в джаве, чуть лучше в дотнете.

TSP>А как вы видите развитие средств разработки программ?

Каких конкретно средств?

TSP> Как должна выглядеть сама модель построения конструкций такого языка?

Что такое "модель построения конструкций такого языка"?

Здравствуйте, Геннадий Васильев, Вы писали:


ГВ>Задача 0: наследование имеющегося ПО. До хрена процентов которого написана на C, C++, Shell language, Perl, Visual Basic, SQL. Пока что об эту задачу обламывают зубы все без исключения.

Вообще-то любопытный момент. В 1980 году я бы сказал то же самое про Фортран.
Мне лет десять назад понадобилась хорошая библиотека по теории вероятности. Искал долго, попадалось большое количество всякого и разного, все на Фортране. Наконец нашел на С, вполне приличная библиотека, как оказалось, в исходниках. Чтение этих исходников сразу показало , откуда уши растут — это был фортрановский код, переведенный на С почти 1:1, в том числе с GOTO. Впрочем, это и не скрывалось — в readme было сказано, что работа по переводу была выполнена по какому-то гранту.

Здравствуйте, TimurSPB, Вы писали:

TSP>Спор о management/unmanagement сегодня лишен практического смысла. Интересно будет решение которое даст эффективное слияние этих подходов.
TSP>А как вы видите развитие средств разработки программ?
TSP>Вопрос скорее из области прикладной науки, чем программирования. Как должна выглядеть сама модель построения конструкций такого языка?

Надоело проектировать снизу вверх. Сейчас, чтобы написать более-менее крупную программу, нужно писать тонны "мелкого" кода, сразу погружаться в реализацию кучи всевозможных деталей... Бывает, еще даже толком не представляешь, что именно должно получиться, а уже приходится писать код реализации
Я хочу язык, позволяющий проектировать сверху вниз. Т.е. я создаю какую-то конструкцию, называю ее "программа", затем детализирую ее — создаю подконструкции, например, "интерфейс", "бизнес-логика", затем детализирую их и т.д., и только через несколько уровней дохожу до классов и функций. По сути, это что-то вроде расширенных UML-конструкций, включенных в синтаксис языка. Чтобы эти высокоуровневые конструкции задавали какие-то ограничения на код (вроде в VS2010 сделали какую-то фичу, с помощью которой можно ограничивать связность разных частей программы... хочу нечто подобное, но на уровне языка и с бОльшим количеством возможностей)
На любом этапе разработки программа должна как минимум компилироваться с диагностикой ошибок уровня проектирования.

Средства разработки... хочу IDE, по функционалу превосходящее Visual Studio 2010, а по скорости работы — превосходящее Visual Studio 6.0.
Хочу, чтобы IDE были рассчитаны не только для написания нового кода, но и для исследования существующего. В среду разработки, да и в язык, должен быть встроен по сути "аутлайнер" с возможностью организовывать деревья, с навигацией по тегам и т.п. фичами. Чтобы можно было без проблем одному человеку разбираться в сверхбольших проектах, написаных множеством людей.

Здравствуйте, x-code, Вы писали:

XC>Надоело проектировать снизу вверх.

Проектируй сверху вниз.

XC> Сейчас, чтобы написать более-менее крупную программу, нужно писать тонны "мелкого" кода

От этого тебя никакой язык не спасет. Если мы, конечно, об универсальных языках.

XC>, сразу погружаться в реализацию кучи всевозможных деталей...

А сразу и не надо. Банальный ООП без всяких изысков спокойно это позволяет.

XC> Бывает, еще даже толком не представляешь, что именно должно получиться

Бывает.

XC>, а уже приходится писать код реализации

Совсем не обязательно.

XC>Я хочу язык, позволяющий проектировать сверху вниз.

Современные языки обычно это позволяют

XC> Т.е. я создаю какую-то конструкцию, называю ее "программа"

class Program {}

XC>, затем детализирую ее — создаю подконструкции, например, "интерфейс", "бизнес-логика"

class UI {}
class BizLogic {}

XC>, затем детализирую их и т.д.,

Ну да

XC> и только через несколько уровней дохожу до классов и функций.

А что изменится, если вместо ключевого слова class будет написано entity, а вместо метода слово operation?

XC> По сути, это что-то вроде расширенных UML-конструкций

UML тоже штука весьма низкоуровневая, несмотря на свои притензии.

XC> Чтобы эти высокоуровневые конструкции задавали какие-то ограничения на код (вроде в VS2010 сделали какую-то фичу, с помощью которой можно ограничивать связность разных частей программы... хочу нечто подобное, но на уровне языка и с бОльшим количеством возможностей)

Code contracts имеют весьма опосредованное отношение к проектированию. Это средство контроля корректности реализации. Пока у тебя нет того самого мелкого кода, контракты не нужны.

XC>На любом этапе разработки программа должна как минимум компилироваться с диагностикой ошибок уровня проектирования.

Что такое "ошибки уровня проектирования"? Пример можно?

XC>Средства разработки... хочу IDE, по функционалу превосходящее Visual Studio 2010, а по скорости работы — превосходящее Visual Studio 6.0.

Хочу быть здоровым и богатым

XC>Хочу, чтобы IDE были рассчитаны не только для написания нового кода, но и для исследования существующего.

Большинство современных больших IDE уже.

XC> В среду разработки, да и в язык, должен быть встроен по сути "аутлайнер" с возможностью организовывать деревья, с навигацией по тегам и т.п. фичами. Чтобы можно было без проблем одному человеку разбираться в сверхбольших проектах, написаных множеством людей.

Чорт в деталях, т.е. в том, что это за фичи. Да, для VS2010 кое что уже есть из твоего списка, многое умеет решарпер.

Здравствуйте, x-code, Вы писали:

XC>Я хочу язык, позволяющий проектировать сверху вниз. Т.е. я создаю какую-то конструкцию, называю ее "программа", затем детализирую ее — создаю подконструкции, например, "интерфейс", "бизнес-логика", затем детализирую их и т.д., и только через несколько уровней дохожу до классов и функций.

http://fprog.ru/2009/issue1/dmitry-astapov-checkers/

XC>Средства разработки... хочу IDE, по функционалу превосходящее Visual Studio 2010, а по скорости работы — превосходящее Visual Studio 6.0.
XC>Хочу, чтобы IDE были рассчитаны не только для написания нового кода, но и для исследования существующего. В среду разработки, да и в язык, должен быть встроен по сути "аутлайнер" с возможностью организовывать деревья, с навигацией по тегам и т.п. фичами. Чтобы можно было без проблем одному человеку разбираться в сверхбольших проектах, написаных множеством людей.

Среда разработки и язык — разные вещи.

XC>> Чтобы эти высокоуровневые конструкции задавали какие-то ограничения на код (вроде в VS2010 сделали какую-то фичу, с помощью которой можно ограничивать связность разных частей программы... хочу нечто подобное, но на уровне языка и с бОльшим количеством возможностей)

AVK>Code contracts имеют весьма опосредованное отношение к проектированию. Это средство контроля корректности реализации. Пока у тебя нет того самого мелкого кода, контракты не нужны.

Не исключено, что x-code имеет ввиду MEF. Но это тоже далеко не панацея от всех бед

XC>> В среду разработки, да и в язык, должен быть встроен по сути "аутлайнер" с возможностью организовывать деревья, с навигацией по тегам и т.п. фичами. Чтобы можно было без проблем одному человеку разбираться в сверхбольших проектах, написаных множеством людей.

AVK>Чорт в деталях, т.е. в том, что это за фичи. Да, для VS2010 кое что уже есть из твоего списка, многое умеет решарпер.

Можно ещё на DSL посмотреть, недавнего Фаулера покурить. IntentSoft IP, JetBrains MPS, Oslo, M. Дело к тому идёт, просто пока ещё не научились это толково делать.

Здравствуйте, x-code, Вы писали:

XC>Я хочу язык, позволяющий проектировать сверху вниз.
См. язык Дракон на оберонском форуме
http://forum.oberoncore.ru/index.php
XC>Хочу, чтобы IDE были рассчитаны не только для написания нового кода, но и для исследования существующего. В среду разработки, да и в язык, должен быть встроен по сути "аутлайнер" с возможностью организовывать деревья, с навигацией по тегам и т.п. фичами. Чтобы можно было без проблем одному человеку разбираться в сверхбольших проектах, написаных множеством людей.
Среды такой пока нет. Ибо существующие промышленные ПРОФЕССИОНАЛЬНЫЕ среды заточены под текстовый редактор (от уж маразм, так маразм!). Когда будут заточны под семантические модели — тогда будет тебе счастье!
А то и сам попробуй написать...

Кстати, Дракон — это самое оно — семантические модели...

Здравствуйте, TimurSPB, Вы писали:

TSP>Часто пишут о грядущей смерти C/С++ и о том что Java + .NET будущее программирования на долгие годы вперед.
TSP>Я считаю, что Java и .NET просто шаг вперед к языкам и платформам которые дадут возможности управления всеми доступными ресурсами сразу на разных уровнях. От регистров процессоров до бизнес логики. Язык будущего должен давать возможность определять классы и создавать их экземпляры так, что бы можно было определять уровни доступа к ресурсам на разных уровнях.

TSP>Например:
TSP>class TRenderDevice:
TSP>level {hardware}
TSP>{
TSP>.... //Тут функции с указателями, с кусками на асме и прочими произведениями суровых бородатых разработчиков
TSP>}

TSP>class TCreditCardsReader
TSP>level {high_secure}
TSP>{
TSP>.... //Тут высокоуровневые конструкции, выполняемые в управляемом окружении, написанные Java/.NET гуру
TSP>}

TSP>Спор о management/unmanagement сегодня лишен практического смысла. Интересно будет решение которое даст эффективное слияние этих подходов.
TSP>А как вы видите развитие средств разработки программ?
TSP>Вопрос скорее из области прикладной науки, чем программирования. Как должна выглядеть сама модель построения конструкций такого языка?

От регистров процессора до бизнес-логики? Это ещё пол дела. Желательно чтоб это было удобно.

Здравствуйте, x-code, Вы писали:

XC>Средства разработки... хочу IDE, по функционалу превосходящее Visual Studio 2010, а по скорости работы — превосходящее Visual Studio 6.0.

Эх... Чует мое сердце, что скорости работы Visual Studio 6.0 уже никогда не будет

Здравствуйте, Pavel Dvorkin, Вы писали:

PD>Здравствуйте, x-code, Вы писали:

XC>>Средства разработки... хочу IDE, по функционалу превосходящее Visual Studio 2010, а по скорости работы — превосходящее Visual Studio 6.0.

PD>Эх... Чует мое сердце, что скорости работы Visual Studio 6.0 уже никогда не будет
Не... Блэк-бокс вполне себе шустро работает...

Здравствуйте, TimurSPB, Вы писали:

...

Надо сказать, что такой язык программирования, каким ему следовало бы быть, никогда не будет использоваться, даже если кто-нибудь сподобился бы его придумать. Естественные языки тоже несовершенны. Однако на эспиранто что-то нет желающих общаться. Люди привыкли мелочно ковыряться с КПД в 10% в своей песочнице. И их оттуда вытащить необычайно тяжело.

Здравствуйте, TimurSPB, Вы писали:

TSP>Как должна выглядеть сама модель построения конструкций такого языка?

В естественном языке десятки тысяч слов (не считая научных терминов). Но общаться на нём можно, имея словарный запас в несколько десятков слов. Язык программирования должен быть таким же. При этом он должен охватывать все области программирования, позволять описывать DSL'и (domain-specific language). Он должен быть отделён от каких-то обязательных библиотек. Также, он должен обеспечивать полный контроль над получаемым исполняемым кодом.

Здравствуйте, любой, Вы писали:

Л>В естественном языке десятки тысяч слов (не считая научных терминов). Но общаться на нём можно, имея словарный запас в несколько десятков слов. Язык программирования должен быть таким же.
Почему?

Здравствуйте, любой, Вы писали:
Л>В естественном языке десятки тысяч слов (не считая научных терминов). Но общаться на нём можно, имея словарный запас в несколько десятков слов.

Словарь Вильяма Шекспира, по подсчету исследователей, составляет 12000 слов. Словарь негра из людоедского племени «Мумбо-Юмбо» составляет 300 слов. Эллочка Щукина легко и свободно обходилась тридцатью. Вот слова, фразы и междометия, придирчиво выбранные ею из всего великого, многословного и могучего русского языка:

1. Хамите.
2. Хо-хо! (Выражает, в зависимости от обстоятельств, иронию, удивление, восторг, ненависть, радость, презрение и удовлетворенность.)
3. Знаменито.
4. Мрачный. (По отношению ко всему. Например: «мрачный Петя пришел», «мрачная погода», «мрачный случай», «мрачный кот» и т. д.)
5. Мрак.
6. Жуть. (Жуткий. Например, при встрече с доброй знакомой: «жуткая встреча»).
7. Парниша. (По отношению ко всем знакомым мужчинам, независимо от возраста и общественного положения).
8. Не учите меня жить.
9. Как ребёнка. («Я его бью, как ребенка» — при игре в карты. «Я его срезала, как ребенка» — как видно, в разговоре с ответственным съемщиком).
10. Кр-р-расота!
11. Толстый и красивый. (Употребляется как характеристика неодушевленных и одушевленных предметов).
12. Поедем на извозчике. (Говорится мужу).
13. Поедем на таксо. (Знакомым мужского пола).
14. У вас вся спина белая (шутка).
15. Подумаешь!
16. Уля. (Ласкательное окончание имен. Например: Мишуля, Зинуля).
17. Ого! (Ирония, удивление, восторг, ненависть, радость, презрение и удовлетворенность).

Оставшиеся в крайне незначительном количестве слова служили передаточным звеном между Эллочкой и приказчиками универсальных магазинов.

Здравствуйте, Pavel Dvorkin, Вы писали:

PD>Здравствуйте, x-code, Вы писали:

XC>>Средства разработки... хочу IDE, по функционалу превосходящее Visual Studio 2010, а по скорости работы — превосходящее Visual Studio 6.0.

PD>Эх... Чует мое сердце, что скорости работы Visual Studio 6.0 уже никогда не будет

Смотри следующую версию Notepad. И по функциональности не сильно уступает.

Здравствуйте, VoidEx, Вы писали:

Л>>В естественном языке десятки тысяч слов (не считая научных терминов). Но общаться на нём можно, имея словарный запас в несколько десятков слов. Язык программирования должен быть таким же.
VE>Почему?

Язык — это единое культурное пространство, в котором люди с разным уровнем подкованности способны понимать друг друга, не затрагивая какие-то глубокие проблемы. Кроме того, наиболее употребительные вещи должны излагаться в более краткой форме. Чтоб тратить меньше времени на чтение и набор.

Здравствуйте, Pavel Dvorkin, Вы писали:

PD>Мне лет десять назад понадобилась хорошая библиотека по теории вероятности. Искал долго, попадалось большое количество всякого и разного, все на Фортране. Наконец нашел на С, вполне приличная библиотека, как оказалось, в исходниках. Чтение этих исходников сразу показало , откуда уши растут — это был фортрановский код, переведенный на С почти 1:1, в том числе с GOTO. Впрочем, это и не скрывалось — в readme было сказано, что работа по переводу была выполнена по какому-то гранту.

А напрямую фортрановские библиотеки нельзя было использовать? ЕМНИП, это несложно. Правда, загвоздка была: Borland C++ с MS Fortran в среде MS DOS не состыковывался, кроме простейших случаев.