Здравствуйте, Don Reba, Вы писали:
DR>Здравствуйте, fin_81, Вы писали:
_>>А если это не опечатка? Если так и было задумано. [ dict2 = Dictionary() ] это просто забытый и не используемый код. А значения из dict будут использоваться в зависимости от типа: или дергаться функция или использоваться значение.
DR>Если так и было задумано, то придётся явно указать, что тип значения — object. Это иногда требуется, но редко.
Объект? То есть вся информация о типе только в рантайме. А компилятор зачем нужен? Чем Javascript хуже? Я то думал мне не придется писать многоэтажные типы при объявлении переменных, а с простыми и так проблем нет.
Здравствуйте, fin_81, Вы писали:
_>Объект? То есть вся информация о типе только в рантайме. А компилятор зачем нужен? Чем Javascript хуже? Я то думал мне не придется писать многоэтажные типы при объявлении переменных, а с простыми и так проблем нет.
Это единственный общий предок у string и Func<int, string>. Если бы у них был общий предок кроме object, то он был бы выведен.
using System.Collections.Generic;
using System.Console;
using System;
variant V
{
| Str { s : string }
| Fun { f : Func[int, string] }
}
def dict = Dictionary();
dict[0] = V.Str("Hello World");
dict[1] = V.Fun(x => x.ToString());
foreach (pair in dict)
{
match (pair.Value)
{
| V.Str(s) => WriteLine(s)
| V.Fun(f) => WriteLine(f(pair.Key))
}
}
Здравствуйте, fin_81, Вы писали:
_>dict = new Dictionary[Variant[int, int->int]] _>неужели немерле не сможет вывести такой тип?
Если бы он такое выводил, то он был бы, по сути, языком с динамической типизацией (внутри методов) — любой переменной в любой момент можно присвоить значение произвольного типа:
mutable x = 42;
x = "42";
x = 3.14;
Для вариантов делается примерно так:
variant Either[T1, T2]
{
| Value1 { value: T1; }
| Value2 { value: T2; }
}
def f(x) { x.ToString() }
def dict = Dictionary();
def dict2 = Dictionary();
foreach (i in [1 .. 10])
{
dict.Add(i, Either.Value1(f(i)));
dict.Add(i, Either.Value2(f)); // возможно имелось в виду dict2?
}
Да, возможно, что имелось dict2, а возможно не имелось. Но чем тут нам может помочь явное указание типов? Тем более, что dict и dict2 не просто так создаются и заполняются значениями (иначе нафиг они нужны), а используются ниже в том же методе и неправильно выведенный тип, почти всегда, приведет к ошибке компиляции (не, я могу придумать пример когда не приведет, но вероятность того, что такое случится на практике стремится к нулю, а отсутствие мусора в коде намного эффективней способствует отсутствию в нем багов).
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>Совершенно безотносительно к N могу лишь отметить, что успех или неудача языка определяется далеко не только тем, насколько он хорош или плох, а еще и массой иных факторов. PD>Ну а применительно к N неудача была вполне очевидна (по крайней мере мне) еще 7 лет назад. Просто я хорошо знаю историю языков программирования.
А почему взлетела Scala?
Откуда же его [независимый суд] взять, если в нем такие же как мы? (c) VladD2
Здравствуйте, artelk, Вы писали:
A>Здравствуйте, fin_81, Вы писали:
_>>dict = new Dictionary[Variant[int, int->int]] _>>неужели немерле не сможет вывести такой тип? A>Если бы он такое выводил, то он был бы, по сути, языком с динамической типизацией (внутри методов) — любой переменной в любой момент можно присвоить значение произвольного типа.
Пусть присваивает любые типы и выводит. Пусть не мешает программировать/прототипировать. Если нужен конкретный тип (контракт, ограничение), программист сам напишет, так как это требование к программе. Не надо ограничивать полет мысли програмиста ошибками компиляции. Потому наверно динамические языки пропулярны в проектах с коротким сроком сдачи.
Но это все философия, хотелки, которые очень сложно реализовать в императивщине (по моему мнению).
Здравствуйте, fin_81, Вы писали:
_>Пусть присваивает любые типы и выводит. Пусть не мешает программировать/прототипировать. Если нужен конкретный тип (контракт, ограничение), программист сам напишет, так как это требование к программе. Не надо ограничивать полет мысли програмиста ошибками компиляции.
Не надо ограничивать полет мысли програмиста компиляцией. А тем паче запуском программы.
FIXED.
Откуда же его [независимый суд] взять, если в нем такие же как мы? (c) VladD2
Z>Ну некоторым и крутой язык ни разу не фича. От того и негатив, что фича нужна такая, что все сразу, чтобы мир в труху. А иначе и не фича ни разу. Вот квазицитаты это фича или нет? А генератор парсеров на котором парсер C# с компиляцией в немрл делается за месяц?
За пять-семь лет, что здесь про Немерле говорят, этот парсер так и остался единственной фичей. Ситуация похожа на Руби, который появился в 95-м году, и не был не нужен никому, пока не появился RoR (10 лет спустя). Или похожа на D, который как был никому не нужен, так и остался, потому что авторы что-то там пилят, а что — никому неизвестно. Но зато там фичи!
Пиар + киллер-приложения — это наше все. До тех пор, пока весь пиар упирается в «у меня на компьютере я наблюдаю десяток DSL в день» и «вы тупые, надо пользоваться правильными языками со стат. типизацией, только такой язык мы только пилим и когда допилим, неизвестно», Nemerle как был никому, кроме очень маленькой кучки энтузиастов, не нужен, так и останется.
Елки палки, на невероятно скучной и невыразительной Java за семь лет появилась просто тонна невероятно интересных проектов (из интересующих лично меня — Neo4J и Akka). У Nemerle это как был «ах, у нас есть парсер, вот ссылка», так и остался.
F>База моя RSDN сдохла как-то пару раз за десяток лет... Хотелось бы узнать, когда Немерля была в первый раз упомянута?
F>Годовщину вспомнить И ху.ву тучу проектов на ней реализованных...
Здравствуйте, ins-omnia, Вы писали:
IO>Здравствуйте, fin_81, Вы писали:
_>>Пусть присваивает любые типы и выводит. Пусть не мешает программировать/прототипировать. Если нужен конкретный тип (контракт, ограничение), программист сам напишет, так как это требование к программе. Не надо ограничивать полет мысли програмиста ошибками компиляции.
IO>Не надо ограничивать полет мысли програмиста компиляцией. А тем паче запуском программы. IO>FIXED.
Компиляция (вывод типов) нужна чтобы проверить непротиворечивость утверждений программиста, в последнее время еще для оптимизации. Если ни то, ни другое не нужно то можно упустить этап компиляции.
Говорю почти серьезно
Здравствуйте, fin_81, Вы писали:
_>Компиляция (вывод типов) нужна чтобы проверить непротиворечивость утверждений программиста, в последнее время еще для оптимизации. Если ни то, ни другое не нужно то можно упустить этап компиляции. _>Говорю почти серьезно
Так и есть. Проблема в том, что программисты думают будто это не требуется гораздо чаще, чем это на самом деле не требуется.
Откуда же его [независимый суд] взять, если в нем такие же как мы? (c) VladD2
Здравствуйте, Ziaw, Вы писали:
Z>1) В целом IT оказался совершенно прав. C# вбирает в себя основные фичи немерла.
Списочек фич можно?
Z>2) Команду Nemerle купили. Хоть и не майкрософт. К сожалению купили не для развития Nemerle, а для своих целей. Но Nemerle в этих целях не последную роль играет.
Ты, скажем так, неверно трактуешь ситуацию.
... << RSDN@Home 1.2.0 alpha 5 rev. 66 on Windows 8 6.2.9200.0>>
Здравствуйте, Mamut, Вы писали:
M>За пять-семь лет, что здесь про Немерле говорят, этот парсер так и остался единственной фичей.
К тому же, когда IT попытался портировать на этот собственный компилятор C# BLT, оказалось что там есть фатальные и неустранимые быстро проблемы.
M>Пиар + киллер-приложения — это наше все.
Пиар от немерлевцев, увы, только в минус — они с какой то странной стойкостью быстро переходят на оскорбления оппонентов. Что же касается киллер-апп, то Влад ясно сказал, что считает что Немерле оно не нужно.
... << RSDN@Home 1.2.0 alpha 5 rev. 66 on Windows 8 6.2.9200.0>>
Здравствуйте, kaa.python, Вы писали:
KP>Воот. о чем я и говорил выше. Не на ту аудиторию нацелились, для очередной опердени вся эта мощь в никуда
У меня регулярно возникают довольно сложные задачи, в частности по построению DSL. Тем не менее Nemerle совершенно непригоден для реального применения. Так что твои теории не стыкуются с фактами.
... << RSDN@Home 1.2.0 alpha 5 rev. 66 on Windows 8 6.2.9200.0>>
Здравствуйте, ins-omnia, Вы писали:
IO>Здравствуйте, fin_81, Вы писали:
_>>Компиляция (вывод типов) нужна чтобы проверить непротиворечивость утверждений программиста, в последнее время еще для оптимизации. Если ни то, ни другое не нужно то можно упустить этап компиляции. _>>Говорю почти серьезно
IO>Так и есть. Проблема в том, что программисты думают будто это не требуется гораздо чаще, чем это на самом деле не требуется.
Программист — не тестер. Пусть тестеры компилируют свои тесты. И багфиксеры. Дешево и сердито.
_>>в последнее время еще для оптимизации
D>еще создатели фортрана (какой там это год?) писали, что для них основной проблемой, которую они решали была оптимизация (в противовес парсингу и т.п.)
Да врядли они думали о оптимизации прям с начала разрабтки. Оптимизация скорее всего появилась около в 2000-го года, и то как попытка максимально загрузить суперскалярные процессоры низкоуровневой оптимизацией. А высокоуровневая с выбором способов предствавления матриц (разреженных и тп) скорее всего лежала на плечах программиста. Тыкнул палцем в небо, интересно угадал нет
Здравствуйте, Ziaw, Вы писали:
Z>Здравствуйте, a_g_99, Вы писали:
__>>Давайте step by step: __>>Что есть по вашему "хороший вывод типов"?
Z>Например это: Z>Типы указывать не надо, компилятор их выведет.
Здравствуйте, fin_81, Вы писали:
_>Пусть присваивает любые типы и выводит. Пусть не мешает программировать/прототипировать. Если нужен конкретный тип (контракт, ограничение), программист сам напишет, так как это требование к программе. Не надо ограничивать полет мысли програмиста ошибками компиляции. Потому наверно динамические языки пропулярны в проектах с коротким сроком сдачи. _>Но это все философия, хотелки, которые очень сложно реализовать в императивщине (по моему мнению).
static vs dynamic сто раз обсуждали. На всякий случай, напомню, что в конце концов все согласились, что статика лучше.
