Здравствуйте Слава, Вы писали:
С>... А что касается нового языка, то его необходимо с самого старта снабжать очень удобной средой разработки ( иначе не получится быстрого программирования ) и целым ворохом принципиально новых библиотек ( иначе конечный продукт сможет конкурировать разве что с приложениями из-под VB 6-й версии).
Как раз это совсем не нужно. .NET Framework прекрасно демонстрирует как несколько языков могут ужиться в одной среде и использовать одни и те же библиотеки. Если новый язык будет поддерживать CLR, то всё это он получит бесплатно.
Кстати, весь этот разговор не имел бы смысла, если бы не этот факт. Не исключено, что в скорости появятся клоны и усовершенсвтвования того же C#, именно по той причине, что можно сконцетрироваться только на языке и разрабатывать его в условиях уже готового и отлаженного окружения.
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте IT, Вы писали:
IT>Как раз это совсем не нужно. .NET Framework прекрасно демонстрирует как несколько языков могут ужиться в одной среде и использовать одни и те же библиотеки. Если новый язык будет поддерживать CLR, то всё это он получит бесплатно.
IT>Кстати, весь этот разговор не имел бы смысла, если бы не этот факт. Не исключено, что в скорости появятся клоны и усовершенсвтвования того же C#, именно по той причине, что можно сконцетрироваться только на языке и разрабатывать его в условиях уже готового и отлаженного окружения.
Я немного не понял. Здесь идёт обсуждение создания принципиально новой концепции языка или новой надстройки над новой, ещё не до конца развитой технолигией.
Здравствуйте Слава, Вы писали:
IT>>Кстати, весь этот разговор не имел бы смысла, если бы не этот факт. Не исключено, что в скорости появятся клоны и усовершенсвтвования того же C#, именно по той причине, что можно сконцетрироваться только на языке и разрабатывать его в условиях уже готового и отлаженного окружения.
С>Я немного не понял. Здесь идёт обсуждение создания принципиально новой концепции языка или новой надстройки над новой, ещё не до конца развитой технолигией.
Говорил бы уже сразу "недоразвитой" зачем стесняться.
Т.е. по твоему все языки поддерживающие CLR это не языки, а надстройки? Очень интересно. По твоей логике, поддержка любым языком CLR тут же переводит его из категории "язык" в категорию "надстройка".
Если нам не помогут, то мы тоже никого не пощадим.
IT>Говорил бы уже сразу "недоразвитой" зачем стесняться. IT>Т.е. по твоему все языки поддерживающие CLR это не языки, а надстройки? Очень интересно. По твоей логике, поддержка любым языком CLR тут же переводит его из категории "язык" в категорию "надстройка".
Ни в коем случае. Но пока что ни один из языков, поддерживающих CLR нельзя назвать принципиально новым.
Здравствуйте Слава, Вы писали:
IT>>Т.е. по твоему все языки поддерживающие CLR это не языки, а надстройки? Очень интересно. По твоей логике, поддержка любым языком CLR тут же переводит его из категории "язык" в категорию "надстройка".
С>Ни в коем случае. Но пока что ни один из языков, поддерживающих CLR нельзя назвать принципиально новым.
А их никто так и не называет. Речь о том, что как бы нов не был язык ему понадобится окружение, хотя бы для того чтобы сказать первое "Hello, world!". А следовательно это окружение необходимо будет разрабатывать вместе с языком. Кроме того необходимо будет реализовать генерацию нативного кода, хорошо бы сделать оптимизатор и т.д. CLR даёт это всё на халяву и можно сконцентрироваться собственно на самом языке. Вот и всё что я хотел сказать.
Если нам не помогут, то мы тоже никого не пощадим.
Теперь уже я буду выглядеть оглядывающимся на C++ & co, но мутные типы и объектность Python'а меня не привлекают. Какжется, Python только лишь объектный, а не объектно-ориентированный, или я устарел? В общем-то я говорил не о "фишках", а об использовании... ммм... о поддержке. Как там Бъерн говорил: "бывают языки, поддерживающие определенную парадигму". А бывает, что и нет.
Конечно же, большинство проектных решений можно реализовать при помощи наследования и кучи виртуальных функций, однако часто приходится ставить кучу невнятных скобок
((..)((((()..)....).), вызывая пару функций там, где обошлись бы и точкой (была б она перегружена).
Улучшения нужны, маленькие и большие. Любые, позволяющие ускорить процесс написания программ. То есть именно написания. Может будущее и за мышками + Drag&Drop, только не шибко верится, что это будет быстрее.
Да, на C# писать одно удовольствие, хотя и приходится иногда материться из-за отсутствия friend, множественного наследования и шаблонов. Зато веера коллекций в каждом классе позволяют быстро найти и использовать, что нужно.
Вот простой пример: немного странно, что коллекция возвращает object, точнее, что приходится помещать в класс свойство, являющееся интерфейсом коллекции (как бы теперь уже с типом). Встает вопрос, что нужно такое ввести в язык, чтобы такой частый прием (и любые другие) поместить в элегантную оберточку, обрастить суффиксами и пользовать в одну строчку. Впоминаю что-то про паттерны (AndrewVK).
Здравствуйте Слава, Вы писали:
IT>>...... CLR даёт это всё на халяву и можно сконцентрироваться собственно на самом языке. Вот и всё что я хотел сказать.
С>В таком случае на халяву есть огромный выбор уже готовых языков. И можно сосредоточиться на написании програмных продуктов.
Да и программных продуктов уже не мало, так что можно сконцентрироваться на их использовании
Если нам не помогут, то мы тоже никого не пощадим.
IT>Да и программных продуктов уже не мало, так что можно сконцентрироваться на их использовании
На новые програмные продукты спрос намного выше, чем на новые языки. Так что пока мы будем сидет и придумывать СамиНеЗнаемЧто, другие завоюют весь рынок програмных продуктов, а языки пусть Маэстро(MS) придумывает.
Здравствуйте Poudy, Вы писали:
P>Угу... Хмм. Ага.
P>Теперь уже я буду выглядеть оглядывающимся на C++ & co, но мутные типы и объектность Python'а меня не привлекают. Какжется, Python только лишь объектный, а не объектно-ориентированный, или я устарел?
Устарел.
Любая проблема дизайна может быть решена введением дополнительного абстрактного слоя, за исключением проблемы слишком большого количества дополнительных абстрактных слоев
Прошу прощения за то, что оставил на некоторое время обсуждение.
Попрошу всех посмотреть, с чего все началось — http://delphi.mastak.ru/cgi-bin/forum.pl?look=1&id=1028039858&n=3
Особенно мои посты (Igorek)
Там, где про конструкции восприятия, а также близость языка к прикладной области, машине, программисту одновременно.
Мда. Впечатление такое, будто люди с пивком в руке развлекались после трудового дня.
.давайте по существу.
Меня просто бесит C++. Мрак. Еще больше бесят компилеры.
Кстати, тот пример, что я приводил в конфе "C/C++.Компиляторы" многими компилится, покуда все собрано в одном файле. Стоит только разнести на два и !
Как мне кааца, необходимость в той или иной возможности языка нужно стараться доказывать как можно строже. Поближе к математике. К примеру:
В случае отсутствия публичных членов, как предлагалось в форуме мастеров Дельфи, возникает необходимость описывать свойства. Наличие публичных членов действительно вызывает неприятное ощущение. Не всегда создаваемый проект является "вещью в себе", когда из конструкторских соображений можно сказать: "Если это поле будет приватным, то ничего не случится, поскольку мы намерено ничего не портим".
Таким образом, на каждое такое поле у нас накладных расходов — одна:три строки на описание свойства. Помимо того, что это еще одно место для потенциальных ошибок, создавать мелкие обслуживающие классы становится неудобно.
Под "обслуживающими" я понимаю обертки для сохранения объектов в файл, для языков без шаблонов — удобные массивы нового класса, а также скрепки, позволяющие привязываться к отдельным полям нового класса, для тех языков, в которых такой встроенной возможности нет. Код подобных вещей сразу возрастает раза в три-четыре (в основном, за счет правильно стоящих скобок).
Встает вопрос: для чего чаще всего необходимо использовать свойства?
Ответ номер один: для предотвращения несанкционированной записи в поле.
Если мы, пытаясь реализовать сами свойства как можно эффективнее, будем заменять вызов функции на код ее тела, то мы не решим продлему косвенного доступа. Косвенный доступ — это прямо запись по указателю.
С одной стороны, можно окиваться: "мол, мы предоставляем средства для стректурирования, а не для предотвращения вредного использования", а про себя отложить эту проблему, пока в голову не придет приемлемое решение (C++).
С другой, можно изничтожить нафиг все указатели и их проявления. Но указатели — это язык машины, и, собственно, очень дешевая и понятная концепция связи, без которой очень неуютно. Неуютно не из-за невозможности писать *q++, а по причине обнищания возможностей. Тогда мы начинаем вводить кипу ключевых слов, вроде ref-out-of-sub, оставляя возможность косвенного связывания без обхода вызова свойтсва (C#).
Напрашиваемое решение — ключевое слово readonly, которое также есть в C# (там вообще много всего есть).
В этом случае мы просто запрещаем использовать присваивание (статическая проверка) или же записываем в тело объекта адрес виртуальной таблицы обработчиков свойств и в указателе(ссылке) явно указываем, что доступ к полю идет по свойству (ссылка гуляет по программе, непременно сохраняя свой флажок — все должен правильно откомпилить компилер, так чтобы дальше шла динамическая проверка).
При этом, опасность обхода функций для свойства (когда прямо пишут в поле) чаще всего связана с какими-то необходимыми побочными действиями, рассылкой сообщений и т.д. Можно сказать: "***, да это же дорого. А как же 'не пользую не плачу'!!! Да ну вас нафиг, я тут в переменную записал, а там шорох пошел на полсекунды!". А можно сказать: "Так и должно быть! В противном случае пришлось бы ручками прописать вызов этих самых функций".
Т.е. Ответ номер два: для слежением за изменением переменной, причем из нескольких мест.
В этом случае, простые свойства не работают, если мы используем чужую библиотеку. Если разработчик оказался предусмотрительным и позволяет подписаться на сообщение, рассылаемое его недосягаемым уже свойством, то все хорошо. Если нет — все плохо (Ну, почти все | хотя наследование тоже не поможет, если использовать нашего нового ребенка будет тоже библиотечный код, а свойство не виртуальное).
Начинает казаться, что либо за записями в переменные должен следить фреймворк (дорого и надежно), либо нужно идти по пути из http://ответа номер один, используя шибко умные ссылки (тогда либо фреймворк делает прозрачным/неразличимым использование ссылок и самих переменных, либо так изначально компилится код).
Есть еще вариант: отложить все рассылки до конца выполнения функции, выполняющей модификацию. Тогда внутри тела идет работа с переменной и, где необходимо, проставление флага "использовано", а после всего, в том случае, если переменная оказалась ссылкой, вызвать функцию, требующую информацию о факте модификации. В таком случае, это уже будет не свойство, а функция ожидания.
Вот таким путем.
Советы и пожелания кладите тут ниже.
IT>Т.е. можно говорить только о проблеме потребления ресурсов, но никак не о быстродействии. В конце концов оптимизаторы и для C# и для C++ писались одной и той же конторой
Не для Ц++, а для Вижуал Ц++...
есть реализации Ц++, которыые к Ц#и близко не стояли по быстродействию
Если при компиляции и исполнении вашей программы не происходит ни одной ошибки — это ошибка компилятора :)))
Здравствуйте Слава, Вы писали:
С>Здравствуйте IT, Вы писали:
а почему тока MS??? Borland тоже чаво-то умеет... да и SUN, близок к тому
так что давайте просто писать что-то на чем-то и тратить свободное время на разговоры в РСДН, а не на попывтки придумать "ват такую фитюльку" для того "чтобы они от зависти лопнули"
Если при компиляции и исполнении вашей программы не происходит ни одной ошибки — это ошибка компилятора :)))
Здравствуйте Poudy, Вы писали:
P>Конечно же, программируя на C++ я могу гордиться, мол моя программа будет даже на Sparc работать. Только будет это слишком самонадеяно, а самое главное: кто из нас Спарк хотя бы раз видел и трогал в живую?
Я трогал!!!
я на ем даже программировал... одно могу сказать: OpenGL тама и правда быстрый... а все остальное — сплошной отстой (я про скорость, правда у меня не самфый крутой Спарк был — всего лишь UltraStation 10 (512 RAM, а проц — не помню.. по моему 75, не уверен) так что вот )
Если при компиляции и исполнении вашей программы не происходит ни одной ошибки — это ошибка компилятора :)))
Здравствуйте henson, Вы писали:
H>Существует большое количество языков программирования, но наиболее популярны сейчас диалекты C/C++. Реально удобный язык, в меру переносимый, короче всем хорош. Даже UNIX на нем от и до написан. На каком еще языке есть реализованные операционные системы?
Вот только вчера прочел BYTE #3'2000 — обзор языков программирования.
Хотя общая идея там была "Си/Си++ сакс" — неважно, по сравнению с Фортом или Обероном. Но это не суть.
Любой язык, обладающий достаточной выразительностью, может послужить базисом для ОС.
Есть примеры систем на Форте (преимущественно — микроконтроллерные), Лиспе, Смолтоке (микроядро содержит форт-, лисп- или смолток-процессор, а все остальное — образ памяти).
Никлас Вирт экспериментировал с Паскалем (проект USCD Pascal, затем Modula, Component Pascal, Oberon). Все это доводилось до уровня операционной системы.
Кстати, вы не задумывались, почему в Windows 3.1 некоторые функции API имеют спецификацию PASCAL? Шютка.
Здравствуйте Hacker_Delphi, Вы писали:
IT>>Т.е. можно говорить только о проблеме потребления ресурсов, но никак не о быстродействии. В конце концов оптимизаторы и для C# и для C++ писались одной и той же конторой HD>Не для Ц++, а для Вижуал Ц++... HD>есть реализации Ц++, которыые к Ц#и близко не стояли по быстродействию
Глословный треп. Один из самых быстрых компиляторов VC7. Даже он не так далек от шарпа. А современем (когда у MS найдется время на вылизывание оптимизатора для .NET-рантайм и MS добавит в Шарп шаблоны) Шарп вооб может начать создавать самый быстрый код.
Если нам не помогут, то мы тоже никого не пощадим.
зачем стесняться.
(я про скорость, правда у меня не самфый крутой Спарк был — всего лишь UltraStation 10 (512 RAM, а проц — не помню.. по моему 75, не уверен) так что вот ) 
Перекуём баги на фичи!
