Здравствуйте Poudy, Вы писали:
P>Быстро как-то заглохло ваше обсуждение. P>Нарвусь на оскорбления, но по-моему было высказано много чужих мыслей не своими же словами.
P>Никто, к примеру, не возмущается тому, что появляются новые ассемлеры, то бишь расширяется набор инструкций. Возможно, производителям компиляторов это и доставляет головную боль, но там люди работают постоянно. P>В сообществе же обычных программистов обыкновенно не любят расширения и новые ключевые слова — какие уж там новые, когда про все старые-то лень прочитесть.
P>И потом — реплики об эффективности и специализации выражают устаревший взгляд. Как сорок лет назад считалось, что сборка мусора это плохо и дорого, так до сих пор многие в этом остаются уверены.
P>А насчет while(*++q = *++p) , так ведь чаще проблема не в том, что не нравится стиль. Часто программист просит, дайте мне хоть #/./s.p-/.i. , лишь бы работало и решало мою задачу.
P>Конечно же, программируя на C++ я могу гордиться, мол моя программа будет даже на Sparc работать. Только будет это слишком самонадеяно, а самое главное: кто из нас Спарк хотя бы раз видел и трогал в живую?
P>Предлагаю продолжить обсуждения, а то как-то даже немного обидно.
Если так хочешь — пожалуста — давай излагай свои идеи по реализации, будем спорить, а потом посмотрим что получится
Взойти на гору можно разными путями, но само восхождение остается неизменным.
С>Может быть .Net и быстрее, чем Java, но вот только точно медленее, чем C/C++. Так зачем более универсальный, но и более медленный язык?
Ты наверное, хотел сказать — МЕНЕЕ универсальный?
И что — неужели не можешь себе представить, чем БОЛЕЕ МЕДЛЕННЫЙ и МЕНЕЕ УНИВЕРСАЛЬНЫЙ язык может быть лучше более быстрого и более универсального?
Здравствуйте Слава, Вы писали:
С>Может быть .Net и быстрее, чем Java, но вот только точно медленее, чем C/C++. Так зачем более универсальный, но и более медленный язык?
Неужели? Интересно, чем вызвана такая уверенность
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте Слава, Вы писали:
С>Может быть .Net и быстрее, чем Java, но вот только точно медленее, чем C/C++.
На основании чего ты сделал такие выводы?
С> Так зачем более универсальный, но и более медленный язык?
На данный момент быстрота не самый важный критерий компилятора.
Здравствуйте IT, Вы писали:
IT>Здравствуйте Слава, Вы писали:
С>>Может быть .Net и быстрее, чем Java, но вот только точно медленее, чем C/C++. Так зачем более универсальный, но и более медленный язык?
IT>Неужели? Интересно, чем вызвана такая уверенность
Не могу привести сейчас ссылки, но я читал, что исполняемый модуль программы, написанной с использованием С.# вырастает по сравнению с программой, написсаной на С/С++, и скорость выполнения падает. Кроме того всякие механизмы типа сборки мусора не могут быть всегда эффективными, потому как один раз написаны и изменению не подлежат.
Здравствуйте AndrewVK, Вы писали:
AVK>Здравствуйте Слава, Вы писали:
С>>Может быть .Net и быстрее, чем Java, но вот только точно медленее, чем C/C++. AVK>На основании чего ты сделал такие выводы?
С>> Так зачем более универсальный, но и более медленный язык? AVK>На данный момент быстрота не самый важный критерий компилятора.
Я имею ввиду не работу компилятора, а работу готовой программы. Так вот весь мир стремится убыстрить свое производство, а на производстве, связанном с обработкой больших обемов информации нужны программы, работающие чем быстрее, тем луче. Вот так.
Здравствуйте Слава, Вы писали:
С>Не могу привести сейчас ссылки, но я читал, что исполняемый модуль программы, написанной с использованием С.# вырастает по сравнению с программой, написсаной на С/С++,
Вырастает в смысле размера файла? Ну это полный бред. С> и скорость выполнения падает.
Как показывают тесты, не особо она и падает, а кое где возрастает.
С> Кроме того всякие механизмы типа сборки мусора не могут быть всегда эффективными, потому как один раз написаны и изменению не подлежат.
Неээфективность GC сказыватся только на объеме потребляемой памяти. Падать быстродействие будет только при нехватке памяти.
Здравствуйте Слава, Вы писали:
С>>> Так зачем более универсальный, но и более медленный язык? AVK>>На данный момент быстрота не самый важный критерий компилятора.
С>Я имею ввиду не работу компилятора, а работу готовой программы.
Так и я про скорость работы готовой программы.
С> Так вот весь мир стремится убыстрить свое производство,
И производство софта в том числе, заметь.
С> а на производстве, связанном с обработкой больших обемов информации нужны программы, работающие чем быстрее, тем луче. Вот так.
Во первых — железка дешевле. Во вторых — все равно как правило скорость работы тех самых систем с большими объемами информации зависит совсем не от скорости выполнения программ.
Здравствуйте Слава, Вы писали:
С>Не могу привести сейчас ссылки, но я читал, что исполняемый модуль программы, написанной с использованием С.# вырастает по сравнению с программой, написсаной на С/С++, и скорость выполнения падает. Кроме того всякие механизмы типа сборки мусора не могут быть всегда эффективными, потому как один раз написаны и изменению не подлежат.
Я не буду утверждать, что быстродействие программ написанных на C# намного больше чем у C++, для этого нужно делать серьёзный комплексный тест, ставя в равные условия обе среды выполнения, что практически невозможно. Но я могу тебя заверить, что быстродействие C# не меньше чем в C++, для этого просто нет причин.
За GC я могу точно сказать, что эта схема работает быстрее чем C++ и Windows хипы в несколько раз для 95% задач. Это дело я это долго и нудно проверял.
Скорее всего ты это сказал не подумав или почитав не очень компетентный источник. У CLR есть следующие недостатки в плане ресурсоёмкости, которые, если на них посмотреть с другой стороны, являются большими достоинтсвами:
JIT-компиляция. Проблема в том что программа в памяти занимает место дважды, первый раз p-код, второй раз откомпилированный native-код. К тому же, так как компиляция каждой функции производится в момент её первого вызова, то программа заметно тормозит при старте. Обе проблемы устраняются путём предварительной компиляции программы при установки или с помощью ngen.exe.
Весь runtime программы грузится вместе с ней, в отличии от Windows программ, для которых большинство необходимых библиотек грузится ещё во время старта операционки.
Т.е. можно говорить только о проблеме потребления ресурсов, но никак не о быстродействии. В конце концов оптимизаторы и для C# и для C++ писались одной и той же конторой
Если нам не помогут, то мы тоже никого не пощадим.
[skipped], но все очень грамотно оспорено.
P>Если так хочешь — пожалуста — давай излагай свои идеи по реализации, будем спорить, а потом посмотрим что получится
Вот это другое дело.
Тогда сначала скажу о том, что я жду от языка програмимрования, чтобы сразу стали понятны некоторые будущие разногласия (а они, уверен, будут).
Много и часто говорится о том, что язык должен предоставлять средства для удобного и по возможности непротиворичивого описания той предметной области, в которой он используется. В естественном языке приближение к предмету достигается за счет подмены понятий, манипулирования определениями и контекста использования терминов. Также часто используют псевдонимы многословных или не вполне четко определенных понятий.
Конечно, язык программирования по мощности и избыточности с естесственным и рядом не валялся, но некоторые ключевые идеи использования оборотной речи могут быть перенесены в язык машин.
Я сейчас не имею ввиду утопическую мечту по поводу программ, вроде: "А вот сделай-ка мне, компьютер, так, чтобы ....". Дело в другом. Дело в том, что человеку своиственно вводить краткие синонимы не только понятиям и действиям (операциям над понятиями), но и стратегиям поведения понятий в контексте других понятий Что-то там есть такое про мультиметоды, только вот это всего лишь методы, хочется также и полиморфизм данных иметь.
Я, конечно, понимаю, что уже со множественным наследованием при размещении объекта с памятью ералаш творится, но кто ж спорит, что все должно быть просто на уровне байт. Главное, чтоб концептуально было проще.
Совершенно очевидно, что часть нововведений, вроде свойств или интерфейсов (которые многие могут назвать "мишурой", которую и так можно эмулировать), а часть будет есть непредсказуемо много ресурсов. Сортировку x86 пока что аппаратно не делает, выборку тоже, но много чего уже можно получить "бесплатно". Поэтому новые средства (с частыми обращениями к памяти) можно пытаться реализовать с других позиций, когда обращение идет уже не за три-восемь тактов, как десять лет назад (и алгоритмы ориентировались на это).
Собственно, чего хочется:
+ иметь в свойствах аттрибуты, функции и вложенные свойства;
+ уметь добавлять аттрибуты в существующий объект, как в дерево, перенеся удобство иерархических структур из области проектирования, в область исполнения;
+ уметь быстро этот объект вынуть;
+ позволять классам инстанцировать объекты по-разному, в зависимости от того, где будет определен объект, и уметь прозрачно конвертить разные варианты друг в друга;
+ позволить себе навводить кучу собственных именованных операторов (еще Страуструп хотел);
+ разрешить себе, наконец, дополнять библиотечные классы новыми возможностями без использования наследования (с целью обмана дочерних программ и для дополнения функциональности различных контейнеров и потоков, незаметно для них самих и других библиотек);
+ из верхнего вытекает: разрешить программе работать со старыми (или неожиданно слишком новыми) версиями библиотек, жонглируя адресами аттрибутов при старте программы;
+ само собой теперь уже нужен Reflection;
+ после всего верхнего, никак не обойтись без разграничения, все-таки, семантик владения и использования;
+ еще кое-чего совсем бредового...
Здравствуйте Poudy, Вы писали:
P>продолжаем разговор
Я бы предложил ввести паттерны как элементы языка. Эдакие супер-шаблоны. Т.е. есть средства описания паттерна похожие на средства описания шаблона. Есть механизмы задания их параметров. И есть библиотека стандартных паттернов. В общем в итоге можно будет писать жутко лаконичные программы.
Если вдуматься то 95 процентов ручного программного кода можно классифицировать на небольшое количество классов. И думается что теоретически возможно по небольшому описанию раскручивать эти классы кода до реального кода.
Еще интересна была бы встроенная в язык кодогенерация (код имеется ввиду исходный). Т.е. такие супер-макросы, завязанные на синтаксис и семантику языка и на его рантайм.
P>Собственно, чего хочется: P>+ иметь в свойствах аттрибуты, функции и вложенные свойства; P>+ уметь добавлять аттрибуты в существующий объект, как в дерево, перенеся удобство иерархических структур из области проектирования, в область исполнения;
Эти два пункта позволяет реализовать Python
P>+ уметь быстро этот объект вынуть;
Вот тут надо уточнить, кто будет отвечать за уничтожение объектов — сами объекты или же некоторый поток типа сборщика муссора, либо отдельный контроллер.
P>+ позволять классам инстанцировать объекты по-разному, в зависимости от того, где будет определен объект, и уметь прозрачно конвертить разные варианты друг в друга;
Ну уж это точно Python позволяет делать
P>+ позволить себе навводить кучу собственных именованных операторов (еще Страуструп хотел);
Хотел — это помню
P>+ разрешить себе, наконец, дополнять библиотечные классы новыми возможностями без использования наследования (с целью обмана дочерних программ и для дополнения функциональности различных контейнеров и потоков, незаметно для них самих и других библиотек); P>+ из верхнего вытекает: разрешить программе работать со старыми (или неожиданно слишком новыми) версиями библиотек, жонглируя адресами аттрибутов при старте программы;
Ну чтож — это то нетрудно, но вот как быть с моделью безопасности
P>+ само собой теперь уже нужен Reflection; P>+ после всего верхнего, никак не обойтись без разграничения, все-таки, семантик владения и использования; P>+ еще кое-чего совсем бредового...
Ну чтож могу сказать — мне кажется, что по поводу удобства использования синтаксиса — надо выбрать единый стиль кодирования, по крайней мере внутрикорпоротивный. А поповоду большинства изложенных фичей — очень советую посмотреть на Python
P>продолжаем разговор
поехали
Взойти на гору можно разными путями, но само восхождение остается неизменным.
Очень жаль, но я почти ничего не понял про паттерны. Ну то есть, в целом мечта понятна, а вот в частностях нет. На ум приходят паттерны Rational XDE. И потом, не вполне ясно различие между кодогенерацией и паттернами. С кодогенерацией, по-моему, нужно подумать отдельно. Нагружать систему невнятными спецификациями особых регулярных выражений будет, вроде, неправильно совсем. А если попользовать шаблоны, то в них очень не хватает перегруженного оператора . , который бы в качестве аргументов принимал параметры аттрибута или метода и, искорежив их, разворачивался нужное кол-во раз внутри тела класса.
Здравствуйте IT, Вы писали:
IT>Хочу такой паттерн, который бы не позволял постить сообшения в форум, если в оном сообщении новый текст не отбит пробельной строкой от квотируемого
Вы хоть определитесь в конце концов. А то один говорит что пробельные строки удалять надо, другой что ставить. У тебя что, квотирование не подствечивается?
Здравствуйте Poudy, Вы писали:
P>Здравствуйте AndrewVK.
P>Ну то есть, в целом мечта понятна, а вот в частностях нет.
Какие частности? Может сразу спецификацию писать?
Смысл такой — это фактически те же шаблоны, но позволяющие генерить целый набор классов и управляемых не только входными типами но еще и кучей параметров — например количество линков, оптимизация под разный объем данных, варианты реализации и т.д.
P> И потом, не вполне ясно различие между кодогенерацией и паттернами.
Можно сказать так — кодогенерация это более общий случай. Вполне возможно что паттерны можно реализовать на основе кодогенерации.
P> С кодогенерацией, по-моему, нужно подумать отдельно. Нагружать систему невнятными спецификациями особых регулярных выражений будет, вроде, неправильно совсем. А если попользовать шаблоны, то в них очень не хватает перегруженного оператора . , который бы в качестве аргументов принимал параметры аттрибута или метода и, искорежив их, разворачивался нужное кол-во раз внутри тела класса.
Не, немножко не так. Кодогенерация — быстрый и удобный способ создавать классы на лету, с поддержкой со стороны языка. Шаблоны же живут исключительно в компайл-тайм.
AVK>Не, немножко не так. Кодогенерация — быстрый и удобный способ создавать классы на лету, с поддержкой со стороны языка. Шаблоны же живут исключительно в компайл-тайм.
Глупости, простите-извините. Никто не мешает нам использовать Reflection для run-time инстанцирования
И вообще, давайте смотреть на вопросы ширше, не оборачиваясь каждый раз на то, как та или иная идея реализована в C++. А вот насчет поддержки — давайте предлагать варианты синтаксиса и четких механизмов функционирования.
Здравствуйте Слава, Вы писали:
С>>>Может быть .Net и быстрее, чем Java, но вот только точно медленее, чем C/C++. AVK>>На основании чего ты сделал такие выводы?
С>Я имею ввиду не работу компилятора, а работу готовой программы. Так вот весь мир стремится убыстрить свое производство, а на производстве, связанном с обработкой больших обемов информации нужны программы, работающие чем быстрее, тем луче.
Вот именно, программисты тоже хотят убыстрить свою работу. На C# скорость разработки увеличивается в разы по сравнению с C++, на значительном большинстве современных задач.
Здравствуйте Silver_s, Вы писали:
SS>Вот именно, программисты тоже хотят убыстрить свою работу. На C# скорость разработки увеличивается в разы по сравнению с C++, на значительном большинстве современных задач.
Полностью с этим согласен, но не думаю, что для этого необходим новый универсальный язык, на котором новенький "программист" после полугодового курса сможет писать дешёвый софт, внешне похожий на профессиональные программы. Достаточно вспомнить Visual Basic, на котором фантастически быстро можно собрать что-либо вроде копировщика файлов, с интерфейсом, как у Visual Studio. Ничего не имею против VB или C.#, а также новых технологий. Просто моё мнение, что новый супер универсальный язык подойдёт разве что системным администраторам для быстрого сляпывания простых приложений.
Я также внимательно прочитал все ответы на моё высказывание относительно С.#. Признаю свою ошибку, доказательства довольно весские. Но при этом сабже дискуссия уходит в сторону. А что касается нового языка, то его необходимо с самого старта снабжать очень удобной средой разработки ( иначе не получится быстрого программирования ) и целым ворохом принципиально новых библиотек ( иначе конечный продукт сможет конкурировать разве что с приложениями из-под VB 6-й версии).
Так что если господа разработчики располагают достаточным количеством времени, то возможно оно того и стоит.
Если нам не помогут, то мы тоже никого не пощадим.
Что-то там есть такое про мультиметоды, только вот это всего лишь методы, хочется также и полиморфизм данных иметь.
