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

XC>Не совсем. Нужен качественно новый подход к написанию кода, а не подсказки. См. ответ на второй вопрос.

Цитирую:

Не сотни. А скажем 15. Умножьте на ~50 классов. Я не хочу и НЕ БУДУ дословно запоминать имена методов. Я предпочитаю начать писать его имя скажем, из серидины, пусть ассист сам найдет где такое встречается.

"ассист" — это, как я понимаю, речь идет о Tamato Visual Assist — т.е. продвинутом комплите для VC++.

VD>>Есть кикие-то идеи по замене ООП и ФП на что-то другое? Или это просто слова в воздух?
XC>ФП — замечательный подход, я часто жалею что ничего подобного нет в С++.

Кое что все же есть в бусте. Но это конечно убогость.

XC>В общих словах — я хочу чтобы IDE понимала семантику и логику программы и как-то отражала это.

Семантика и так отображается. Только на для С++ конечно. А для C#/Java очень даже. Для Немерла тоже, только мы еще не закончили.

XC> Чтобы была некоторая "многослойность" и "многомерность" при разработке.

Это неопределенные понятия.

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

Вот в современные языки и внедряются некторые паттерны или добавляются возможности позволяющие внедрить их.

XC>Возможно, такие концепции как "контейнер" и "итератор" стоит ввести в язык программирования.

Так и делается. C# и осбенно Nemerle поддерживают специальный сахар для работы с контейнерами, точнее со списками. Есть yield для легкой реализации итераторов. Есть встроенная поддержка list[T] в Nemerle. Есть foreach. Много чего есть. Но сами контейнеры выгодно все же иметь в виде типов написаннаых на самом языке.

XC>Как-то на более высоком уровне реализовать идею объектов и связей между ними (не методы и указатели на интерфейсы)

Опять что-то оморфное.

XC>Сделать прямой гейт "UML-язык программирования", а не те кривые реализации которые есть сейчас.

Ты открывал дизайнер классов в VS 2005? Или все представление основано на UML в сочетании с С++?

Много мечтаний далекий от жизни поскипаны.
Хочу подитожить следующим. Многое из того что ты описываешь уже реализовано. Не так правда как видиш это именно ты, но за-то работает на практике. Так что советую поглядеть на мир за пределами С++, так как это все недоступно в основном именно миру С++ в следствии того, что язык плохо подходит для этого.

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

L>Как насчёт guards? Не всегда нужно сравнивать только на равенство. Есть ли возможность написать что то вроде

L>

L>sign n | n < 0     = -1
L>       | n > 0     =  1
L>             | otherwise =  0
L>

Украл отсюда

public Contains (e : int) : bool
  {
    match (this) {
      | Tree.Node (l, cur, _) when e < cur => 
        l.Contains (e)
 
      | Tree.Node (_, cur, r) when e > cur => 
        r.Contains (e)
 
      | Tree.Node => true
      | Tree.Null => false
    }
  }

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

VD>Это может занять слишком много времени и места. Если попытаться описать их кратко, то это ЯП поддерживающий/отвечающий требованию:

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

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

VD>Это может занять слишком много времени и места. Если попытаться описать их кратко, то это ЯП поддерживающий/отвечающий требованию:

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

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



VD>Проблема в том, что это могут с уверенностью сказать только продвинутые Хаскелисты. Лично я знаю только одно — Хаскель очень агрессивно использует композицию фукнций и по умолчанию он все рассматривает как композицию однопараметровых функйи. Так что казалось бы невинная запись "factorial n — 1" может превратиться в черт знает что. Причем в иногда это будет давать тот же результат как ты можешь интуитивно предполжить, а иногда получается такое, что ты даже выполнив код не сможешь понять, что же произошло.

Не, Влад, тут всё прозрачно. Применение функции имеет больший приоритет, чем любой оператор, поэтому в "factorial n — 1" сначала применится функция, а потом произойдёт вычитание. Другое дело, что из-за нетерминированной рекурсии получается, что должно вычисляться (n*(n*(n*(...)-1)-1)-1) — типичная экспансия Y-комбинатора.

А вот внешние скобки в примере — действительно лишние, из тех же самых соображений приоритета применения функции перед оператором (умножения). Так что версия факториала от Another junior Haskell programmer без лишних скобок такова

fac 0 = 1
fac n = n * fac (n-1)

Вообще, в Хаскелле круглые скобки используются в выражениях по своему прямому математическому назначению — для группировки операций (и лишние не возбраняются, но и не вносят никакого дополнительного смысла). Ну и для кортежей, конечно, поскольку этот случай легко выделить по запятым, разделяющим элементы.

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

L>>

L>>sign n | n < 0     = -1
L>>       | n > 0     =  1
L>>             | otherwise =  0
L>>

M>Украл отсюда

Т.е. мой пример распишется как

sign(n : int) : int
    | _ when n < 0 => -1
    | _ when n > 0 =>  1
    | _            =>  0

так?

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

E>

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

E>(Крематорий, Винные Мемуары).

Мне больше нравится другая классика

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

БГ, Электрический пес

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

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

J>>Я понимаю, что это все может показаться надуманным, но все-таки ... Одно дело plain-text code, который не больше чем код, а совсем другое — зверь, который во время компиляции может приконнектиться куда нужно и сдать нахрен все номера моих кредитных карточек

A>Хмм. А ведь интересная мысль!

а есть такая класная программа как янус

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

EC>Ты о триках в духе C++ template metaprogramming говоришь? Если да, то не согласен — где тут побочные эффекты?

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

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

VD>Это ты о чем?

Я о том, что пока всё просто, такая запись выглядит неплохо. Но, боюсь, что в реальном коде перегрузка метода не только по типу, но ещё и по значению не добавит простоты и понятности.

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

D>fac 0 = 1
D>fac n = n * fac (n-1)

То есть все-таки так, как оно и должно быть.

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

I>То есть все-таки так, как оно и должно быть.

Конечно. А зачем по-другому?

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

VD>Это может занять слишком много времени и места. Если попытаться описать их кратко, то это ЯП поддерживающий/отвечающий требованию:
VD>...

И параллельность. Чуть ли не половина глюков вылазит при многопоточности.

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

L>Да там внешние скобки не нужны, честно говоря.

Интуитивно обе пары совершенно лишнии. Вот люди и лепят их на всякий пожарный.

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

L>VladD2 показал более лаконичный вариант на Nemerle. Правда, он использует локальные функции. Если тот же вариант возможен без этого ограничения, то это просто замечательно.

L>Кстати (вопрос к VladD2) — чем вызвано это ограничение? Не положить в байткод в общем виде?

Какое еще ограничение?

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

L>>Да там внешние скобки не нужны, честно говоря.

VD>Интуитивно обе пары совершенно лишнии.

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

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

L>>Кстати (вопрос к VladD2) — чем вызвано это ограничение? Не положить в байткод в общем виде?

VD>Какое еще ограничение?

Ты написал

или даже так:

factorial(n)
  | 0 => 1
  | _ => n * Factorial(n - 1)

если использовать локальные фукнции и их вывод типов.

т.е. такая запись возможна только если factorial — локальная функция? или я тебя неверно понял?

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

VD>Интуитивно обе пары совершенно лишнии. Вот люди и лепят их на всякий пожарный.

Внутренние-то почему лишние? Возможно моя интуиция слишком "математизирована", но в

x * sin x — 1
vs.
x * sin (x — 1)

по-моему всё однозначно и понятно

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

S>Здравствуйте, fmiracle, Вы писали:
F>>Еще интереснее узнать про преценденты отправки модератора в бан самим сабой. Этакое харакири по-модераторски.
S>Это закрытая информация. Всё, что я могу сказать: сейчас на RSDN нет форума, в историю которого входит такой прецедент. И для вашего же благополучия — оставьте эти расспросы.

хоть webarchive ищи какой нить
заинтриговали

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

N>И параллельность. Чуть ли не половина глюков вылазит при многопоточности.

Это пока (лично для меня) вопрос будущего. Пока что параллельность была практически ненужна. Но конечно в будущем это стаенет одной из самых актуальных тем.

Вот только лино я хотел бы чтобы язык позволял бы добавить нужную поддержку имеющимися срествами (в виде фрэйморка).