Здравствуйте, IT, Вы писали:
IT>Здравствуйте, Ziaw, Вы писали:
Z>>Тем не менее. Язык так и остался передовым, просто IT переоценил скорость прогресса в отрасли.
IT>IT переоценил смелость и дальновидность советских учёных. Языком нужно было начинать заниматься серьёзно сразу после того как его забросили поляки, т.е. где-то в 2007-м году. Не фиксить бесконечные баги, а писать всё начисто. Понимание этого пришло только пару лет назад и то с большим скрипом. А что-то начало делаться вообще меньше года назад.
Давным-давно многие люди высказывали совершенно здравые мысли, что язык не взлетит. И расписывали, почему.
Не претендуя на абсолютную истину, выскажу скромное мнение: "языковый фреймворк N2" точно так же не взлетит. По тем же причинам, умноженным на 2. Теперь будем ждать прихода понимания.
Здравствуйте, Ziaw, Вы писали:
PD>>Прочти внимательно, что я написал. Компилятор вывел правильно. Программист предполагал иное. Программист неправ, а не компилятор, но это осталось незамеченным на этапе компиляции и проявилось в рантайме.
Z>Я внимательно прочел. Повторяю, не могу себе представить. Вон arltek может, мне очень интересен пример или, хотя бы, ход мысли.
Что не можешь представить ? Что программист думал одно (неправильно), а получилось другое (правильно) ? Странно. Это у нас сплошь и рядом бывает, в самых разных ситуациях.
Ну вот тебе пример на Scala
trait Container[+T] {
def add[U>:T](x: U) : Container[U]
}
class ContainerImpl[+T] extends Container[T] {
def add[U>:T](x: U) : Container[U] = { // stub onlynew ContainerImpl[T]
}
}
class Fruit
class Apple extends Fruit
class Orange extends Fruit
val containerOrange = new ContainerImpl[Orange]
val container = containerOrange.add(new Apple)
Какого типа будет container ? Уверен ли, что любой начинающий программист правильно ответит без проверки ?
Здравствуйте, Pavel Dvorkin, Вы писали: PD>Что не можешь представить ? Что программист думал одно (неправильно), а получилось другое (правильно) ? Странно. Это у нас сплошь и рядом бывает, в самых разных ситуациях.
Не могу представить, каким боком тут вывод типов.
Ну вот тебе пример на Scala
PD>trait Container[+T] { PD> def add[U>:T](x: U) : Container[U] PD> }
PD> class ContainerImpl[+T] extends Container[T] { PD> def add[U>:T](x: U) : Container[U] = { // stub only PD> new ContainerImpl[T] PD> } PD> }
PD> class Fruit PD> class Apple extends Fruit PD> class Orange extends Fruit
PD> val containerOrange = new ContainerImpl[Orange] PD> val container = containerOrange.add(new Apple)
PD>Какого типа будет container ? Уверен ли, что любой начинающий программист правильно ответит без проверки ?
А разве компилятор тут не ругнется? Я не силен в скале, но [U>:T] очень похож на констрейнт, согласно которому Apple должен быть потомком Orange.
А вообще пример напоминает метод ToString который возвращает double. Такой введет в заблуждение любого программиста.
Здравствуйте, IT, Вы писали:
IT>При чём тут история? Историю всегда делали конкретные люди. А конкретные люди на сегодняшний день полностью отсекли комьюнити от разработки компилятора и молчат как партизаны о своих (не) успехах. Может у них там всё очень хорошо. А может и не очень. Но нам это не известно. Если бы они рассказывали чего они достигли на сегодняшний день, то этого топика вообще бы не было, а все бы дружно истекали слюной, говорили ВАУ и поторапливали разработчиков.
Ну, что не рассказывают понять можно. Тонны "ваше говно все равно не взлетит" демотивируют кого угодно. Хотя, краткие сводки с полей в профильном форуме не помешали бы.
Здравствуйте, Don Reba, Вы писали: DR>static vs dynamic сто раз обсуждали. На всякий случай, напомню, что в конце концов все согласились, что статика лучше.
Не читал но осуждаю.
Что есть статическая и динамическая типизация? Где граница между ними? Какая типизация в этом куске немерле-кода:
dict = new Dictionary; // какого типа dict? Dictionary[Unknown, Unknown]?
dict.add(0,10); // а здесь? тип изменился? а где же статика? Dictionary[Integer, Integer]?
Мне кажется нет статической и динамической типизации, есть просто "вывод типов". Где-то он никакой — js, python и подобные скриптовые языки, где-то более продвинутый — паскаль, с++, немерл, хаскели. Но продвинутость у каждого своя.
Если делить таким образом, то какой-то вывод типов, именуемый в простонародье "статическим", лучше чем никакой "динамический". Но на практике "вывод типов" слишком ограничен и полет мысли разбивается о скалу предопределенных типов диктуемых компилятором языка. И на "помощь" (медвежью) приходит dynamic и типоуничтожающий общий тип object. Вопрос а зачем нужен компилятор, если его везде хотят заткнуть?
Скрытый текст
И здесь остапа понесло. Компилятор, который не компилирует. А если компилирует, то в какой-то промежуточный байт-код. Потом какой-то jit-компилятор этот байт-код пытается компилировать в "машинный код". Естественно плохо получается. Потом этот "машинный сиськ-код" компилируется/транслируется в риск-код, а потом раскидывается по конвеерам процессора. Потом выясняется, что какой-то скриптовый транслируемый язык уделывает компилируемый. Кажись я догадываюсь почему. А нельзя одному и единственному компилятору сразу компилировать в риск-команды и раскидывать по конвеерам. Думаю получилось бы намного лучше
А теперь про "вывод типов".
declare a: Integer
// тип строго Integer, расширение типа запрещено
declare b
// тип Variant[Unspecified]
// возможно уточнение типа
// Unspecified - это указание компилятору, что это неполный тип
// по идее Unspecified надо как-то выкинуть|заменить на что-то более удобное
declare c: Integer|Float|Unspecified
// тип Variant[Unspecified]
// возможно расширение типа
declare dict: Dictionary
// тут программист говорит, что dict это ассоциативный массив, но пока не известно с какими данными он работает
// тип Dictionary[Unspecified, Unspecified]
dict.add(0, 10);
// тут можно предположить что ключ Integer, значение тоже Integer
// тип Dictionary[Variant[Integer|Unspecified], Variant[Integer|Unspecified]]
dict.add(1, "one")
// тут можно предположить, что значением может быть String
// тип Dictionary[Variant[Integer|Unspecified], Variant[Integer|String|Unspecified]]
//В конце единицы компиляции компилятор выкидывает Unspecified и подбирает оптимальный тип-контейнер для переменных
Скорее всего это уже где-то уже сделано и более красиво. На функциональных языках не пишу, там скорее всего это реализуется через паттерн-матчинг.
Z>Не могу представить, каким боком тут вывод типов.
Самым прямым. Компилятор должен вывести тип переменной val container. Ее тип явно не указан.
Z>А разве компилятор тут не ругнется? Я не силен в скале, но [U>:T] очень похож на констрейнт, согласно которому Apple должен быть потомком Orange.
Нет, не ругнется. Тут действительно constraint, только upper bound, поэтому add может принять любой сабкласс от U, но вернет U. Плюс ковариантность. В итоге (поскольку U это Fruit) вернется контейнер из Fruit. Все верно — если в ящик с апельсином добавить яблоко, будет ящик с фруктами.
Z>А вообще пример напоминает метод ToString который возвращает double. Такой введет в заблуждение любого программиста.
Увы, это из Martin Odersky, я лишь заменил его class Queue на Container, чтобы не затемнять суть проблемы.
As an example, suppose there is a class Fruit with two subclasses,
Apple and Orange. With the new definition of class Queue, it is possible to
append an Orange to a Queue[Apple]. The result will be a Queue[Fruit]
А теперь самая фишка. Представь себе, что я просто ошибся. Когда писал вот это
val container = containerOrange.add(new Apple)
я ел яблоко и добавил в контейнер яблоко вместо Orange . Ни о каком добавлении туда яблок и речи в моем замысле не было. Здесь должен быть строго контейнер из Orange, яблоки в это месте вообще не нужны.
Но я ошибся, и не заметил этого. Компиляция прошла. Потом где-то в совсем другом месте для этого контейнера вызывается проход по всем элементам с передачей виртуальной функции элемента. И вызовется виртуальная функция для яблока, и натворит таких дел, что не дай бог. И самое скверное, что натворит она это, может быть, бог знает когда, так как в большинстве случаев она и для апельсинов и для яблок вызывает базовую (из Fruit), а в 0.001% случаев делает что-то иное.
PD>Нет, не ругнется. Тут действительно constraint, только upper bound, поэтому add может принять любой сабкласс от U, но вернет Container[U]. Плюс ковариантность. В итоге (поскольку U это Fruit) вернется контейнер из Fruit. Все верно — если в ящик с апельсином добавить яблоко, будет ящик с фруктами.
Ну это может быть лично в вашей реальности, разве что
Исходя из SO по башу(bash+shell) вопросов 33000, а по виндовз-батникам (cmd+batch+batch-file) в сумме и 15000 не набралось (90% десктопов) — значит ли это, что Windows "не взлетел"?
Здравствуйте, some_user_222, Вы писали:
__>Набрел в гугле на этот любопытнейший тред, в котором повествуется о безмерной крутости, перспективности и эффективности Nemerle, о его большой роли в индустрии и так далее. __>Спустя 7(!!!) лет все осталось на своих местах. На Nemerle все также написан только компилятор Nemerle, количество вопросов на StackOverflow не превышает полусотни(для Go — 1600, Scala — 13500). Смешно, но сегодняшний тон дифирамбов и оптимистический речей все тот же
Немерле — экспериментальный язык, и исследовательский проект. Это нормально, таких языков полно. Идеи, обкатанные на таких языках, потом реализуются в мейнстримовых, чтобы не пришлось выбрасывать отлаженный код для того, чтобы воспользоваться прелестями. Как это происходит? Посмотрите, например, на COBOL 2005.
Поляки делали исследование. Предметом исследования была не возможность метапрограммирования как таковая (старая новость, берем, например, LISP и вперед), а исследование возможностей развития языков .NET. Они его успешно завершили. И занимаются с тех пор дальнейшим развитием .NET в Майкрософт, если не ошибаюсь.
"Советские ученые" обнаружили мощный западный артефакт — результат мелкого исследовательского проекта. Повертели в руках. Клевый, они похожего раньше нигде не видели. И решили, что у них в руках убер-оружие. Непонятно, зачем буржуи его бросили? Вот дураки.
Если бы в наших университетах нормально учили, и кто-нибудь занимался реальными исследованиями, реагировали бы на подобные артефакты не так дико. Вы спрашиваете, почему не взлетел? А что, известен хоть один альтернативный язык не от MS под проприетарную платформу .NET, который "взлетел"?
Ок, теперь семантика понятнее. Это иммутабельный контейнер и add плохое название для метода.
PD>А теперь самая фишка. Представь себе, что я просто ошибся. Когда писал вот это PD>val container = containerOrange.add(new Apple)
Это должно вылезти потом. Когда контейнер ушел в метод которому нужен контейнер с апельсинами.
PD>я ел яблоко и добавил в контейнер яблоко вместо Orange . Ни о каком добавлении туда яблок и речи в моем замысле не было. Здесь должен быть строго контейнер из Orange, яблоки в это месте вообще не нужны.
А в C++ мы можем сделать то же самое. Что если мы добавим потомок апельсина, в тот список в котором собирались хранить только апельсины? Ответ — ничего не должно поломаться, если мы следуем принципам ООП.
PD>Но я ошибся, и не заметил этого. Компиляция прошла. Потом где-то в совсем другом месте для этого контейнера вызывается проход по всем элементам с передачей виртуальной функции элемента. И вызовется виртуальная функция для яблока, и натворит таких дел, что не дай бог. И самое скверное, что натворит она это, может быть, бог знает когда, так как в большинстве случаев она и для апельсинов и для яблок вызывает базовую (из Fruit), а в 0.001% случаев делает что-то иное.
Если функция работает с фруктом, но при передаче туда яблока творит что попало это и без вывода типов косяк дизайна. LSP.
Здравствуйте, AndrewVK, Вы писали:
AVK>Списочек фич можно?
С ходу — дженерики, лямбды, вывод типов, dynamic, лифинг выражений, ко/контрвариантность появились в Nemerle до C#. Это все или практически все фичи C# которые появились в языке. Некоторые из них реализованы как слабое подобие.
Z>>2) Команду Nemerle купили. Хоть и не майкрософт. К сожалению купили не для развития Nemerle, а для своих целей. Но Nemerle в этих целях не последную роль играет.
AVK>Ты, скажем так, неверно трактуешь ситуацию.
Здравствуйте, Ziaw, Вы писали:
Z>Ок, теперь семантика понятнее. Это иммутабельный контейнер и add плохое название для метода.
Согласен.
PD>>А теперь самая фишка. Представь себе, что я просто ошибся. Когда писал вот это PD>>val container = containerOrange.add(new Apple)
Z>А в C++ мы можем сделать то же самое. Что если мы добавим потомок апельсина, в тот список в котором собирались хранить только апельсины?
По-видимому, получим список из наследников апельсина. Но яблок там все же не окажется. И список будет из апельсинов (потомки — модифицированные апельсины, иначе нарушены принципы дизайна .
Почему ты считаешь, что речь идет о том, что что-то может поломаться ? Наверное, я не очень хорошо выразился. Я не имел в виду, что добавление туда яблока и потом вызов его виртуальной функции приведет именно к поломке. Я имел в виду, что вывод типов позволяет это сделать и получить совсем не тот контейнер, который я хотел получить (да, это моя ошибка). Вот это главное. А что потом эта функция сделает — второй вопрос.
Вариант 1. На вход add подается наследник от Fruit, класс контейнера нешаблонный.
PD>>Но я ошибся, и не заметил этого. Компиляция прошла. Потом где-то в совсем другом месте для этого контейнера вызывается проход по всем элементам с передачей виртуальной функции элемента. И вызовется виртуальная функция для яблока, и натворит таких дел, что не дай бог. И самое скверное, что натворит она это, может быть, бог знает когда, так как в большинстве случаев она и для апельсинов и для яблок вызывает базовую (из Fruit), а в 0.001% случаев делает что-то иное.
Z>Если функция работает с фруктом, но при передаче туда яблока творит что попало это и без вывода типов косяк дизайна. LSP.
Я не буду спорить насчет дизайна (хотя мог бы возразить), просто констатирую, что язык такую ошибку позволяет сделать именно из-за вывода типов. В C++/Яве/C# такое не сделаешь, будет ошибка при компиляции.
Какая польза от вывода типов ? Писать меньше, пусть компилятор сам разберется. Так ? Другого я не вижу. В конце концов в Scala никто не запрещает все типы писать явно.
А вред ? Больше возможностей сделать трудноуловимую ошибку. Надеюсь, я смог это показать.
Кстати, заметь, в той же Яве, что, в сущности generic делает ? Да ничего. В рантайме их нет (erasure), при желании я их ограничения смогу обойти. Без них набирать меньше. Зачем они ? А именно затем — чтобы поймать на стадии компиляции добавление строки в список из целых чисел, к примеру.
Между тем набор имен типов — дело чисто автоматическое и на скорость работы программиста не сильно влияет. Мы гораздо больше времени тратим на всякие операторы (их еще и продумать надо), чем на набор всяких там ArrayList<Integer>, особенно если вспомнить про Ctrl-Space.
Ну и the last but not the least. Программу, в которой типы переменных описаны, читать легче. Тут я думаю, спорить ты не будешь.
Здравствуйте, Ziaw, Вы писали:
AVK>>Списочек фич можно?
Z>С ходу — дженерики
Дженерики в MSR проектировали, когда никакого Немерле еще ны было.
Z>лямбды, вывод типов
Это все совсем не из немерля в шарп пришло.
Z>dynamic
Динамики, емнип, в превьюхах шарпа появились раньше немерля.
Z>лифинг выражений
Это чего за зверь?
Z>, ко/контрвариантность появились в Nemerle до C#
Зато в рантайме они появились задолго до немерля.
AVK>>Ты, скажем так, неверно трактуешь ситуацию. Z>Давай без недомолвок. Есть поправки — выкладывай.
Это ты лучше обратись к непосредсвенным участникам. Если они не желают публично этим делиться, зачем это делать мне? Главное — ты попал пальцем в небо.
... << RSDN@Home 1.2.0 alpha 5 rev. 66 on Windows 8 6.2.9200.0>>
Здравствуйте, Pavel Dvorkin, Вы писали:
PD> Программу, в которой типы переменных описаны, читать легче.
Это не проблема. Например, решарпер может заменять в C# явные определения типов на var, где это возможно, и наоборот. То есть пишем мало, потом жмакаем кнопочку в редакторе — получаем явные описания типов.
Ещё пример: RelaxNG — язык описания xml, имеет две формы синтаксиса: в виде xml (похоже на XmlSchema), и лаконичный, в форме Бэкуса-Наура. Из одной формы в другую преобразование проводится без потерь. То есть опять же, можно писать мало, а читать в более многословном виде.
Имхо, так и должно быть в любых языках: краткий синтаксис (аля Перл и регулярки) и полный синтаксис. И редактор должен на лету выдавать тот или иной вид по требованию.
Если память мне не изменяет, тут на форуме некий преподаватель (боюсь ошибиться, поэтому ник не привожу) со своими учениками давно грозится выдать среду разработки именно с подобным поведением.
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>Ну и the last but not the least. Программу, в которой типы переменных описаны, читать легче. Тут я думаю, спорить ты не будешь.
А я бы поспорил. При наличие IDE, которая показывает тип, когда подводишь курсор, необходимость в постоянно торчащем и мозолящим глаза указании типа пропадает.
SomeMethod(int x) {}
SomeMethod(string s) {}
int v = 40 + 2;
// строка кода
// строка кода, использующая v
// строка кода
// строка кода
// строка кода, использующая v
// строка кода
// строка кода
// строка кода, смотря которую забыли тип переменной v
// строка кода
SomeMethod(v);
Не сильно беспокоит, что не сразу видно тип параметра, передаваемого в SomeMethod (и чтобы выяснить это (при отсутствие IDE) нужно пролистнуть код наверх)?
Или ты предпочитаешь в каждой строчке явно все типы указывать:
SomeMethod((int)v);
??
При отсутствие IDE (например, в примерах кода на msdn) да, тип лучше указывать явно. Хотя и в этом случае понятности оно не всегда способствует.
Здравствуйте, koodeer, Вы писали:
K>Это не проблема. Например, решарпер может заменять в C# явные определения типов на var, где это возможно, и наоборот. То есть пишем мало, потом жмакаем кнопочку в редакторе — получаем явные описания типов.
Решарпер, он, конечно, может. Ну а допустим, смотришь ты код в каком-то репозитории, может, и загружать его не станешь... Или просто в книге какой-то.
А во-вторых, пусть у тебя где-то несколько переменных описано. Так и будешь подводить курсор к каждой (или иное действие), чтобы тип посмотреть ? И в уме эти типы держать ? А эти тултипы, мало того, что не самым хорошим шрифтом отображаются, так еще норовят исчезнуть через некоторое время.
Ради чего все это ? Чтобы меньше набирать ? Так потратишь то же время на все эти кнопочки и движения мыши. При этом набрать надо один раз, а тут каждый раз.
A>А я бы поспорил. При наличие IDE, которая показывает тип, когда подводишь курсор, необходимость в постоянно торчащем и мозолящим глаза указании типа пропадает.
A>Не сильно беспокоит, что не сразу видно тип параметра, передаваемого в SomeMethod (и чтобы выяснить это (при отсутствие IDE) нужно пролистнуть код наверх)?
Да я же не против того, чтобы мне IDE все это показывала. Но когда есть еще и просто в тексте, хуже уж никак не будет. А набирается все это почти не думая.
A>Или ты предпочитаешь в каждой строчке явно все типы указывать: A>
A>SomeMethod((int)v);
A>
A>??
Нет, конечно.
A>При отсутствие IDE (например, в примерах кода на msdn) да, тип лучше указывать явно.
Вот именно.
>Хотя и в этом случае понятности оно не всегда способствует.
Ну уж никак хуже не делает. А если код непонятен, тут никто не поможет.
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>А во-вторых, пусть у тебя где-то несколько переменных описано. Так и будешь подводить курсор к каждой (или иное действие), чтобы тип посмотреть ? И в уме эти типы держать ? А эти тултипы, мало того, что не самым хорошим шрифтом отображаются, так еще норовят исчезнуть через некоторое время.
Я имел в виду, что происходит явное преобразование текста, самого исходника. Не в тултипе подсказка, а в самом тексте заменяются слова var на полное определение типа (и наоборот).
PD>Решарпер, он, конечно, может. Ну а допустим, смотришь ты код в каком-то репозитории, может, и загружать его не станешь...
Имхо, давно следует избавиться от хранения и показа исходников в виде простого текста. По сути мы имеем информацию — набор байтов. А в каком виде её показывать — текст, таблица, график — это вопрос визуального представления. То есть в репозитории хранятся байты, а текстовый редактор (роль которого может представлять браузер) показывает нам байты в виде текста (в правильной кодировке). С таким же успехом можно показывать эту же информацию в любом виде: краткий или полный синтаксис, UML-диаграммы или что-то ещё. То, что браузер этого не умеет сейчас — недоработка, которую желательно исправить. Мечты, мечты...
PD> Или просто в книге какой-то.
Тут я в затруднении, что предпринять. Нужно избавляться от такого анахронизма как бумажные книги
PD>Ради чего все это ? Чтобы меньше набирать ? Так потратишь то же время на все эти кнопочки и движения мыши. При этом набрать надо один раз, а тут каждый раз.
Суть в том, что любитель краткого синтаксиса будет всегда набирать в таком виде, и ни разу не нажмёт кнопочку трансформации кода. А любитель полного синтаксиса, получив код от первого коллеги (или из репозитория), лишь один-единственный раз нажмёт эту кнопку, и дальше будет работать с преобразованным исходником.
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>Ну и the last but not the least. Программу, в которой типы переменных описаны, читать легче. Тут я думаю, спорить ты не будешь.
Мне программу без явной аннотации читать легче. Поэтому первое, что я делаю при рефакторинге чужого кода в рабочем проекте — прогоняю решарперовский клинап, который, в том числе, по возможности заменяет все явные декларации на var.
... << RSDN@Home 1.2.0 alpha 5 rev. 66 on Windows 8 6.2.9200.0>>
Давным-давно многие люди высказывали совершенно здравые мысли, что язык не взлетит. И расписывали, почему.
