Здравствуйте, Dyoma, Вы писали:
D>Привычен для тех, кто вообще никогда ни на чем не программировал, а вот математика в школе была. Для таких начинающих, x=2 — это утверждение, а не действие.
С чего ты это взял? Это можно трактовать по разному. В том числе и присвоение значений можно трактовать как декларацию равенства.
D> А понятия присваивания в курсе математики вообще нет. Логично, что для этого нового понятия новый значок использовать.
Все эти рассуждения притнуты за уши. Их приводя чтобы обосновать утверждения которые подругму никак обосновать нельзя. А между тем факт в том, что у программистов нет проблем в восприятии символа = как присвоения. И не нужно делать из этого религию. Язык не станет хуже или лучше если в нем будет исползоваться := вместо = или наоборот. У языков есть масса других особенностей действительно влияющих на удобство, простоту и понятность. Но "это"...
D>А в BNF ::= это не присваивание и не равенство, это разделитель. Он отделяет нетерминал слева от правила справа.
Не, батенька, именно что равенство. В чистейшем математическом смысле этого слова. Этот оператор задает тождество между правилом и его телом. После этого любое упоминание имени правила и тела становятся эквивалентны и взаимозаменимы.
... << RSDN@Home 1.2.0 alpha rev. 618>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Павел Кузнецов, Вы писали:
>> Кстаит, Паш, а ты смотрел ОКамл и другие МЛ-подобные языки?
ПК>Потихоньку.
И какие выводы?
>> Ведь то что тебе нравится в С++ там реализовано несравннено лучше.
ПК>Интересно, что же это?
Ну, более логичная и мощьная система типо. Более естественный параметрический полиморфизм (статический). Наличие таких вещей как паттерн-матчинг. Наличие первоклассных средств метапрограммирования. Вроде бы как именно эти вщи тебе нравятся в С++, и именно они в МЛ-языках реализованы несравнимо лучше.
>> По скорости некоторые компиляторы ОКамла не хуже VC7.
ПК>Это для меня имеет косвенное значение.
Луквиш. Ну, да тем более...
>> Что мешает перейти?
ПК>Вопрос (пока?) так вообще не стоит. Главного возможного мотива, существенной неудовлетворенности использованием C++, в нашей команде незаметно; пока, скорее, наоборот. Таким образом, речь о переходе на другой язык могла бы идти в основном в случае, если бы этот переход сулил бы нам какие-то существенные преимущества. Соответственно, прежде, чем задавать вопрос в таком виде, нужно очень хорошо себе представить, что именно это нам может дать, и чего это нам будет стоить. Этого анализа никто пока не делал.
Ну, что же вы себе враги?
... << RSDN@Home 1.2.0 alpha rev. 618>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
VD>Здравствуйте, Dyoma, Вы писали:
D>>Привычен для тех, кто вообще никогда ни на чем не программировал, а вот математика в школе была. Для таких начинающих, x=2 — это утверждение, а не действие. VD>С чего ты это взял? Это можно трактовать по разному. В том числе и присвоение значений можно трактовать как декларацию равенства.
Вот примеры из математики:
x^2-3x+2=0, x^2 = 3x-2
Ни однин из них нельзя трактовать как присваивание, это именно утверждения. А вот еще пример: x1=1, x2=2 (или x=1;2) — корни того уравнения, но это тоже не присваивание, а утверждения. Бывает варинт типа "Пусть x=3 ..." — и опять имеем дело не с присваивание, а утверждением, которое временно считаем верным, в частности абсолютно корректно было бы рассуждение начинающееся "Пусть sin x = 0.5 ..." — а с позиции присваивания такое вообще аналогов не имеет. Так что хотя "Пусть x=3 ..." еще можно считать присваиванием (в некоторых языках даже было let x=3), но все же надо понимать, что это очень ограниченная аналогия...
D>> А понятия присваивания в курсе математики вообще нет. Логично, что для этого нового понятия новый значок использовать.
VD>Все эти рассуждения притнуты за уши. Их приводя чтобы обосновать утверждения которые подругму никак обосновать нельзя. А между тем факт в том, что у программистов нет проблем в восприятии символа = как присвоения. И не нужно делать из этого религию. Язык не станет хуже или лучше если в нем будет исползоваться := вместо = или наоборот. У языков есть масса других особенностей действительно влияющих на удобство, простоту и понятность. Но "это"...
Лично на мой взгял == это гораздо большая шлупость, чем :=. Зачем вместо всем известного мат. значка =, которой означает имеено то что нужно вводить новый?
Но все становится понятным если если вспомнить о духе C: оптимизация нажатий на кнопки в первую очередь, с желательно небольшым вредом для читаемости. Присваивание гораздо более распостранненое действие, чем сравнение на равенство, а программист, который 8 (и более) часов в сутки пишет эти самые значки — не свинья, ко всему привыкнет
D>>А в BNF ::= это не присваивание и не равенство, это разделитель. Он отделяет нетерминал слева от правила справа.
VD>Не, батенька, именно что равенство. В чистейшем математическом смысле этого слова. Этот оператор задает тождество между правилом и его телом. После этого любое упоминание имени правила и тела становятся эквивалентны и взаимозаменимы.
Неправда твоя. Возьмем для определенности какое-нить определение равенства, пусть такое:
Исчисление-с-равенством это исчисление в котором введен двухместный предикатный символ =, называемый равенство, (ok, обозначить его можно и подругому — не суть), а так же аксиомы: \all x. x = x; \all x y. x=y => y=x; ну и транзитивность.
Теперь к BNF. грамматика:
var ::= a|b|...
expr ::= var
expr ::= expr + expr
Дважды применяем транитивность и получаем: a|b|... ::= expr + expr.
Так что ::= это не более чем часть синтаксиса, не наделенная никаким самостоятельным смыслом.
Здравствуйте, 1115, Вы писали:
1>>>>а может можно придумать высокоуровневый язык для описания доказательств теорем и вообще любых математических утверждений? GZ>>>И назовем его SML!!!! (или кто-то уже делал такой?)
Т>>SML — не для "описания доказательств теорем", а для "программироваия систем доказательств". 1>Собственно HOL и Coq , ровно также как и LCF (ради которого был создан ML) ---- написаны на ML. 1>не думаю что это будет верх эволюции.
А что, собственно, ты называешь "высокоуровневый язык"?
Например, C++ это высокоуровневый язык? Или это такой же ассемблер как HOL. Собственно в чем разница между C++ и ассеблером. Разница в том, что к C++ прилагается компилятор, который кострукции языка умеет отображать в ассемблер. Тогда, по аналогии, HOL — не ассемблер (ассемлер в чистом виде это определение доказательства, как последовательности из формул, в которой каждая следующая получается применением правил вывода к предыдущим). И хотя идеологически HOL внутри это именно это определение и есть, то для пользователя, HOL идет вместе со свякими политиками применения правил вывода т.е. средством отобраения твоих "высокоуровневых идей" в "доказательство по определению". Так же к HOL прилагается ML, на котором ты можешь написать свои собственные патерны, и способы "отображения идей". И получается, что HOL, идет вместе с тем, что программисты называют мета-программированием.
Или под "высокоуровневым языком" ты понимаешь что-нить типа managed? Т.е. язык который, кроме отображения в ассемблер предлагает, что-то новое, не существующее на уровне процессорных команд. Я тут говорю о, например, сборке мусора и механизма эксепшенов. Если так то возникает вопрос "Нафига оно надо или как это привязать к определению?". Дело тут в том, что в программировании цель — решение задачи пользователя, а комп, процессорный код, интерпретатор, ... это всего лишь средства достижения этой цели. По-этому пользователю не важно произвел ли ты код для процессора его компа или будет работать интерпретатор, ему важно решает ли результат твоей работы его проблему. С доказательствами все не так, а наоборот. Ценность не в ответе да/нет (эта теорема верна/неверна), а именно в этой самой цепочке формул, которая доказывает ответ да/нет. Т.е. по програмерской аналогии, ценность имеет только ассемблерный код, и соотвественно ценность имеет только компилируемый язык.
alexeiz wrote:
> То бишь узаконим существующую практику. То же удобство, что и в > Boost'е, только поддерживаемое языком напрямую. Возможности здесь, > конечно, гораздо превосходят Boost'овские. Такие вещи, как occur[_1]++ > или _1.first с помощью Boost.Lambda сделать нельзя.
Здравствуйте, Cyberax, Вы писали:
C>alexeiz wrote:
>> То бишь узаконим существующую практику. То же удобство, что и в >> Boost'е, только поддерживаемое языком напрямую. Возможности здесь, >> конечно, гораздо превосходят Boost'овские. Такие вещи, как occur[_1]++ >> или _1.first с помощью Boost.Lambda сделать нельзя.
C>Делается: C>
C>var(occur)[_1]++ //occur[_1]++
C>
Это конгениально!
C>Пример с _1.first лень смотреть
После многочисленных попыток я нашёл
&_1 ->* &val_t::first
Не знаю есть ли способ сделать это более естественно.
Собственно, пришёл я к этому следующим образом:
struct A { int d; };
A * aa = new A();
(_1 ->* &A::d)(aa); // это из help'а
map_t::iterator it = begin(occur);
val_t * v = &*it;
(_1 ->* &val_t::first)(v); // работает
(_1 ->* &val_t::first)(&*it); // хм... не работает
(&_1 ->* &val_t::first)(*it); // опять работает
(&*_1 ->* &val_t::first)(it); // снова работает!
Здравствуйте, DarkGray, Вы писали:
DG>Сейчас программа обычно представляет из себя один большой листинг без разделения:
А вот мне почему-то кажется, что такие части, как
DG>на оптимизационный код, DG>на код, который служит для защиты от дурака, DG>на трассировочный код, DG>на код диагностики и самодиагностики,
уже можно запихать в язык (конечно, с поддержкой ide).
Здравствуйте, Dyoma, Вы писали:
D>Здравствуйте, 1115, Вы писали:
D>А что, собственно, ты называешь "высокоуровневый язык"? D>Например, C++ это высокоуровневый язык? Или это такой же ассемблер как HOL. Собственно в чем разница между C++ и ассеблером. Разница в том, что к C++ прилагается компилятор, который кострукции языка умеет отображать в ассемблер. Тогда, по аналогии, HOL — не ассемблер (ассемлер в чистом виде это определение доказательства, как последовательности из формул, в которой каждая следующая получается применением правил вывода к предыдущим). И хотя идеологически HOL внутри это именно это определение и есть, то для пользователя, HOL идет вместе со свякими политиками применения правил вывода т.е. средством отобраения твоих "высокоуровневых идей" в "доказательство по определению".
"доказательство по определению": должен быть уровень "ассемблерный" , но переносимый (между hol , coq и тп). чтоб теоремы можно было скачивать из интернета и легко с помощью компа проверять правильность выкладок.
"высокоуровневых идей": а тут всё должно быть удобнее чем C# и дебагер в visual studio 2005.
иногда хочется видеть(понимать) всё вместе —
не хватает аналога uml ( в придачу можно написать книгу "рефакторинг: улучшение существующи матем теорий" )
> Так же к HOL прилагается ML, на котором ты можешь написать свои собственные патерны, и способы "отображения идей". И получается, что HOL, идет вместе с тем, что программисты называют мета-программированием.
D>Или под "высокоуровневым языком" ты понимаешь что-нить типа managed? Т.е. язык который, кроме отображения в ассемблер предлагает, что-то новое, не существующее на уровне процессорных команд.
когда я читаю книгу по матану, но я много о чём не думаю. хотя вроде теже самые процессорные команды.
> [....]
Здравствуйте, VladD2, Вы писали:
VD>Хм. Надеюсь изменится. Все же та задница которая существует с шаблонами сейчас, когда одна опечатка может привести к натуральному словестному поносу компилятора из которого ровным счетом ничего нельзя понять, надеюсь исчезнет.
Ну... MS C++ 7.1 уже производит свертку сообщений об ошибках в шаблонах через подставные обозначения. Весьма удобно и наглядно позволяется визуально проследить схему образования типа и помогает в поиске уровня, на котором ошибка возникает.
Здравствуйте, Зверёк Харьковский, Вы писали:
ЗХ>BTW, идеальной "записью намерений" для этого случая мне кажется что-то в этом роде: ЗХ>
ЗХ>int sum = 0;
ЗХ>sum += each(array); //ну или each(array.begin, array.end);
ЗХ>
Ага, типа функциональный стиль...
Показать, как эти две записи на С++ сделать или и так понятно?
(т.е. реализацию each)
для такого использования:
v1
int sum = 0;
sum += each(array);
v2
int sum = 0;
sum += each(array.begin(), array.end());
Причем, специализации each для варианта 1 можно сделать как для STL-коллекций, так и для вообще любых коллекций.
(у меня куча аналогичных биндеров для макроса_шаблона for_each(), для STL, MFC и обычных массивов)
---------------
В любом случае +3 за удачный синтаксис!
Здравствуйте, Павел Кузнецов, Вы писали:
ПК>alexeiz,
>> Фиг его знает, какие lambda предложат в C++0x. <...>
ПК>К сожалению, скорее всего, никакие: deadline для языковых предложений уже позади, а предложений lambda так и не было видно. Теперь надежда на разработчиков компиляторов...
Может быть ещё и будет. STL тоже в самый последний момент ввели. Если ты знаешь, у Саттера есть такой проект, Concur. Там используется некоторый вариант lambda. Когда это дело обсуждали на C++ Connections, Страутсруп сказал, что если у Саттера что либо выйдет к 2007 году, и это будет хорошо и очень полезно, то может быть что-нибудь в стандарт и войдёт.
Хотя сам Страуструп не имеет на счёт lambda никаких предпочтений. Единственный его аргумент, который я помню сейчас, это то, что простые вещи должны записываться просто с помощью lambda. Как конкретно это будет реализовано, ему не интересно.
Ещё помню один момент, когда Страуструп рассказывал, как он решил посмотреть Boost.Lambda, а потом решил сделать всё тоже самое сам, и у него получилось и заработало даже быстрее Boost’а. После чего он сделал вывод, что код Boost.Lambda слишком сложен (сложнее, чем у него вышло) и несколько сырой (так как работает медленнее).
Здравствуйте, vdimas, Вы писали:
V>Ну... MS C++ 7.1 уже производит свертку сообщений об ошибках в шаблонах через подставные обозначения. Весьма удобно и наглядно позволяется визуально проследить схему образования типа и помогает в поиске уровня, на котором ошибка возникает.
Ага. Удобство просто офигительное. Подставь в "итераторы" stl-я целое значение и подивись что из этого выйдет.
... << RSDN@Home 1.2.0 alpha rev. 618>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, vdimas, Вы писали:
V>Здравствуйте, Зверёк Харьковский, Вы писали:
ЗХ>>BTW, идеальной "записью намерений" для этого случая мне кажется что-то в этом роде: ЗХ>>
ЗХ>>int sum = 0;
ЗХ>>sum += each(array); //ну или each(array.begin, array.end);
ЗХ>>
V>Ага, типа функциональный стиль...
V>Показать, как эти две записи на С++ сделать или и так понятно? V>(т.е. реализацию each)
//Чтобы можно было сделать и так:
sum += each(array);
//и так:if(any(array) > 5) ...
//и вот эдак:
select(array, _1 < 2).method(); //method - это метод элемента массива
нужна либо поддержка языка, либо очень нехилых размеров библиотека (причем последний пример на C++ не реализовать, увы).
Здравствуйте, Dyoma, Вы писали:
VD>>1. Для "любого" средства банально может быть недоступен профайлер. Или доступен, но такой, что считай, что его нет.
D>В данном случае ответ на вопрос "Что делать?" отсутствует и такой подход не применим . Это правда не повод отказаться от любимого языка, но повод подумать еще раз и поискать другие пути к отсутплнию...
Здравствуйте, eao197, Вы писали:
E>А ты можешь предложить встроенный DSL a-la Makefile для Java или C++? Или хотя бы Smalltalk. Как он будет выглядеть?
Не уверен, что правильно понимаю, что такое DSL, но посмотрите сюда — это оно?
Здравствуйте, Eugene Beschastnov, Вы писали:
E>>А ты можешь предложить встроенный DSL a-la Makefile для Java или C++? Или хотя бы Smalltalk. Как он будет выглядеть?
EB>Не уверен, что правильно понимаю, что такое DSL, но посмотрите сюда — это оно?
ЗХ>И последнее: лично мне наиболее современным и "впередсмотрящими" языками представляются не тяжеловесные "все-в-одном + своя платформа + вообще-все-что-вам-может-понадобиться-когда-либо" Java и C#, а более легковесные, без груза "обратной совместимости по парадигме", приспособленные к сегодняшнему миру Python
Насчёт Python к сожалению тоже есть проблемы. Есть желание создать следующую версию языка, но наибольшая проблеми для CPython в C-API который задокументирован и сейчас серйозно ограничивает какое-либо усовершенствование(по сути большинство проектов по оптимизации машыны исполнения упираются в потребность совместимости с C-API), очевидно придётся рубить по жывому. ЗХ>и Ruby.
ЗХ>Такие дела.
Здравствуйте, VladD2, Вы писали:
VD>Здравствуйте, Зверёк Харьковский, Вы писали:
ЗХ>>Ты просил — вероятность принятия индустрией нового языка, за которым не стоят монстры ЗХ>>Я ответил
VD>Тут вот иногда народ спрашивает сколько приложений на вашем компьютере менеджед и расстраивается когда народ называет 1-3 приложения. А сколько у тебя приложений на Руби, Питоне или не дай бог на ПХП с Перлом?
Во первых сейчас вроде бы провозглашают переход к веб-центрическому миру. А во вторых Питон встроен у достаточно большое количество приложений, так что не факт что его у вас нет, он просто может быть встроен.
VD>Боюсь столько же скольсо у меня. Максимум где-нить в каталоге скриптик заволялся.
Ну, да тем более...
. Это правда не повод отказаться от любимого языка, но повод подумать еще раз и поискать другие пути к отсутплнию...
