| 1 2 3 4 5 6 7 8 9 |
| Re[59]: Динамические языки и переменные | |
 | От: | Temoto | |
| Дата: | 18.03.10 04:15 |
| ВВ>>>Ну так как это сделать? Какие юникодные символы разрешать, а какие — нет? Явно прописывать? T>>Откуда вообще потребность что-то запрещать? ВВ>Говорили же выше, такую грамматику при которой в identifier будет возможны вообще любые символы просто нельзя написать. Будут постоянные конфликты. Если я не ошибаюсь, в юникоде есть понятие "буква". И регекспы с поддержкой юникода понимают, что \w это буква любого алфавита. Если хочется вообще любые символы, то тоже есть решение. Зарезервировать пробел (разделитель идентификаторов) и ещё буквально несколько служебных символов, всё остальное — идентификатор. В Agda так и сделано. Но ВВ>Мой вопрос аналогичен — есть ли у зеленых бегемотов какие-то возможности, которые я проглядел. Василий, нету разницы между туплами и списками. Нету.  Ты можешь создать эти возможности и эту разницу или не создавать. Например, сделать тупл индексным массивом (но тогда, на мой взгляд, его лучше так и назвать — array), а список — связанным списком (без операции доступа по индексу). ВВ>>>Мне кажется, что "чисто математический" синтаксис тут плохо масштабируется. Т.е. SQL-подобный легче "наворачивать". Вот даже если просто сортировку добавить к хаскелевскому варианту, уже будет неочевидно как ее писать — третей по счету, четвертой и пр. T>>Всё верно. T>>Но, мне кажется, что нужно просто не добавлять туда сортировку. Сортировку можно сделать обычным вызовом функции снаружи от компрехеншона. ВВ>Можно, но учитывая то, что ты можешь сортировать по нескольким полям типа order by x desc, y asc, z desc с помощью отдельных функций получится уже не так красиво и удобно. Тебе для каждого из этих выражений придется описывать отдельную функцию-компаратор. А для стабилизации сортировки компараторы надо комбинировать. Можно написать одну функцию, которая возвращает (потенциально составной) ключ сортировки. И по этому ключу всегда сортировать ascending. ВВ>К примеру, как записать на Хаскеле: (даже не хочу думать, как это записать на хаскеле но)Подумай, как бы ты решил эту задачу на LINQ, если б orderby мог принимать только одно значение. Что-то типа orderby (x, char.Max — y). Я не говорю, что это красиво, но комбинация есть. Может быть в хаскеле есть более удобное средство для сортировки по нескольким ключам, а может и нет. Когда мне надо было отсортировать по нескольким ключам — сортировка по туплу была вполне удобна. ВВ>Пока мне не кажется разумным урезать возможности только для того, чтобы "вписаться" в хаскелевский синтаксис. Само собой. ВВ>получается уже короче, чем в питоне. Ты не мог бы написать два законченных выражения, а то я не понял мысль. x in list в питоне проверяет есть ли элемент x в списке list. T>>Неявно передаётся значит? Ты же вроде не любитель неявностей? ВВ>Вообще так практически везде, даже в C#. Первый параметр инстансной функции — неявно переданный this. Другого решения я просто не придумал. Особенного такого, которое позволяло бы осуществлять "позднее связывание" с этим this. Т.е. функцию можешь описать отдельно, а потом добавить ее в качестве поля к разным объектам, и она начнет работать по-разному. Как ещё можно — при определении метода явно объявлять его аргумент. В Python2 так: class A(object): def __init__(self): self.who = "John Smith" def bar(self): return 10 obj = A() A.foo = lambda self: len(self.who) + 1 но obj.foo = lambda: len(obj.who) + 2 # этот метод есть только у инстанса obj. меньше 5 раз за 2 года мне такая явность пригодилась. Остальное время бесполезно не мешала. В Ruby, я считаю, просто шикарный синтаксис для этого дела. class A attr_accessor :m # это генерит getter и setter для поля A.m def foo(a1, a2) @m, @n = a1, a2 # это this.m = a1; this.n = a2; и this.n как-бы приватный, потому что к нему нет геттера. Но можно потом добавить. end def n @n # return this.n; И вот добавили геттер к n. end end Настолько охрененский синтаксис, что просто хочется сидеть и писать классы целый день. |
| Re[60]: Динамические языки и переменные | |
 | От: | Воронков Василий | |
| Дата: | 18.03.10 11:15 |
| Здравствуйте, Temoto, Вы писали: ВВ>>Говорили же выше, такую грамматику при которой в identifier будет возможны вообще любые символы просто нельзя написать. Будут постоянные конфликты. T>Если я не ошибаюсь, в юникоде есть понятие "буква". И регекспы с поддержкой юникода понимают, что \w это буква любого алфавита. Что-то мне кажется, в юникоде нет понятия "буква". (Кстати, иероглиф — это буква? А символ катаканы? )Да и парсер все же не на регекспах  T>Если хочется вообще любые символы, то тоже есть решение. Зарезервировать пробел (разделитель идентификаторов) и ещё буквально несколько служебных символов, всё остальное — идентификатор. В Agda так и сделано. Но Хз в общем. Честно говоря, мне такая задача особо приоритетной не кажется. Никогда не видел, чтобы люди использовали русские идентификаторы, к примеру. Да и во многих языках это попросту не поддерживается. T>(даже не хочу думать, как это записать на хаскеле но)T>Подумай, как бы ты решил эту задачу на LINQ, если б orderby мог принимать только одно значение. Вообще-то при условии того, что "инфраструктура" сортировки в .NET есть и можно любой объект отсортировать любым образом решение было бы весьма геморойным. Во-первых пришлось бы вместо анонимного типа описать тип явно и реализовать в нем интерфейс IComparable — собственно реализация и представляла бы комбинированный компаратор, сделанный вручную. Потом пришлось бы переделывать запрос — ведь мы выбираем ровно то же выражение, по которому и сортируем. Выглядел бы новый запрос примерно так:
Честно, мне не нравится вариант с одним значением для orderby.  T>Что-то типа orderby (x, char.Max — y). Я не говорю, что это красиво, но комбинация есть. Может быть в хаскеле есть более удобное средство для сортировки по нескольким ключам, а может и нет. Когда мне надо было отсортировать по нескольким ключам — сортировка по туплу была вполне удобна. Сортировка по туплу тебе не поможет ведь никто же не знает, как именно надо рассматривать элементы твоего тупла — какой первичный, какой вторичный, какой ascending, какой descending и пр. ВВ>>получается уже короче, чем в питоне. T>Ты не мог бы написать два законченных выражения, а то я не понял мысль. x in list в питоне проверяет есть ли элемент x в списке list. Имелось в виде убрать let и заменить ключевые слова на более короткие вместо длинных where/from/select. Собственно, основная экономия в питоне идет за счет более лаконичных ключевых слов. T>>>Неявно передаётся значит? Ты же вроде не любитель неявностей? T>class A(object): T> def __init__(self): T> self.who = "John Smith" T> def bar(self): return 10 T>obj = A() T>A.foo = lambda self: len(self.who) + 1 T>но T>obj.foo = lambda: len(obj.who) + 2 # этот метод есть только у инстанса obj. T>меньше 5 раз за 2 года мне такая явность пригодилась. Остальное время бесполезно не мешала. Брр, функция объявляется с одной сигнатурой, а вызывается с другой. ИМХО это ахтунг. T>В Ruby, я считаю, просто шикарный синтаксис для этого дела. T>class A T> attr_accessor :m # это генерит getter и setter для поля A.m T> def foo(a1, a2) T> @m, @n = a1, a2 # это this.m = a1; this.n = a2; и this.n как-бы приватный, потому что к нему нет геттера. Но можно потом добавить. T> end T> def n T> @n # return this.n; И вот добавили геттер к n. T> end T>end T>Настолько охрененский синтаксис, что просто хочется сидеть и писать классы целый день. Ага, тоже решение интересное. Вводим префиксы для переменных. Теперь у нас будут $x, @x и обязательно @@x. Причем знаешь, что самое забавное? Префикс префиксом, но this-то все равно передавать надо  Ela 0.9 Dynamic, functional, strict and lazy |
| Re[61]: Динамические языки и переменные | |
| От: | Temoto | |
| Дата: | 18.03.10 12:38 |
| ВВ>Что-то мне кажется, в юникоде нет понятия "буква". (Кстати, иероглиф — это буква? А символ катаканы? ) Я бы ожидал, что всё, что входит в любой алфавит, включая катакану, заматчится на \w. ВВ>Да и парсер все же не на регекспах Но лексер-то на регекспах? T>>Если хочется вообще любые символы, то тоже есть решение. Зарезервировать пробел (разделитель идентификаторов) и ещё буквально несколько служебных символов, всё остальное — идентификатор. В Agda так и сделано. Но ВВ>Хз в общем. Честно говоря, мне такая задача особо приоритетной не кажется. Никогда не видел, чтобы люди использовали русские идентификаторы, к примеру. Да и во многих языках это попросту не поддерживается. Конечно, какой уж тут приоритет. Просто прикольно. T>>Что-то типа orderby (x, char.Max — y). Я не говорю, что это красиво, но комбинация есть. Может быть в хаскеле есть более удобное средство для сортировки по нескольким ключам, а может и нет. Когда мне надо было отсортировать по нескольким ключам — сортировка по туплу была вполне удобна. ВВ>Сортировка по туплу тебе не поможет ведь никто же не знает, как именно надо рассматривать элементы твоего тупла — какой первичный, какой вторичный, какой ascending, какой descending и пр. Я тебе говорю, что это есть и работает, что я так делал и добивался целей, а ты говоришь, что не получится. Во-первых, у туплов есть порядок. Во-вторых, всё сортируется в одну сторону. Если какой-то элемент нужно отсортировать в обратном порядке, употребляется патерн Max — x. Вот этот момент уродлив, но это работает. ВВ>>>получается уже короче, чем в питоне. T>>Ты не мог бы написать два законченных выражения, а то я не понял мысль. x in list в питоне проверяет есть ли элемент x в списке list. ВВ>Имелось в виде убрать let и заменить ключевые слова на более короткие вместо длинных where/from/select. Собственно, основная экономия в питоне идет за счет более лаконичных ключевых слов. На какие? w f и s? Экономия отнюдь не на длине ключевых слов. В основном, экономия на том, что ты не пишешь типы. Про ключевые слова, да есть приятная экономия на их отсутствии, например public, protected, private, static, var, virtual, override, abstract, out, operator, ref, readonly, new, enum, explicit, implicit переименованы в более лаконичное ключевое слово "". Остальные ключевые слова если и лаконичнее, то это совершенно незаметно. ВВ>Ага, тоже решение интересное. Вводим префиксы для переменных. Теперь у нас будут $x, @x и обязательно @@x. ВВ>Причем знаешь, что самое забавное? Префикс префиксом, но this-то все равно передавать надо В Ruby, насколько мне известно, два префикса. Это @foo как сахар к this.foo и :foo синтаксис возвращающий атом (приблизительно const foo = "foo"). Ну и как-то не Perl, нормально с двумя префиксами. Но ладно, я понял, тебе не нравится. |
| Re[62]: Динамические языки и переменные | |
| От: | Воронков Василий | |
| Дата: | 18.03.10 12:55 |
| Здравствуйте, Temoto, Вы писали: ВВ>>Что-то мне кажется, в юникоде нет понятия "буква". (Кстати, иероглиф — это буква? А символ катаканы? )T>Я бы ожидал, что всё, что входит в любой алфавит, включая катакану, заматчится на \w. ВВ>>Да и парсер все же не на регекспах T>Но лексер-то на регекспах? Нет, конечно. А что есть генераторы парсеров, у которых сканеры на регекспах? Регекспы штука небыстрая вообще. T>>>Что-то типа orderby (x, char.Max — y). Я не говорю, что это красиво, но комбинация есть. Может быть в хаскеле есть более удобное средство для сортировки по нескольким ключам, а может и нет. Когда мне надо было отсортировать по нескольким ключам — сортировка по туплу была вполне удобна. ВВ>>Сортировка по туплу тебе не поможет ведь никто же не знает, как именно надо рассматривать элементы твоего тупла — какой первичный, какой вторичный, какой ascending, какой descending и пр. T>Я тебе говорю, что это есть и работает, что я так делал и добивался целей, а ты говоришь, что не получится. T>Во-первых, у туплов есть порядок. T>Во-вторых, всё сортируется в одну сторону. Если какой-то элемент нужно отсортировать в обратном порядке, употребляется патерн Max — x. Вот этот момент уродлив, но это работает. Т.е. все-таки туплы нужны Особенно, если нет возможности сортировать по нескольким полям.А ведь еще можно вспомнить, что сортировать можно по одному выражению, а выбирать по другому. T>Экономия отнюдь не на длине ключевых слов. В основном, экономия на том, что ты не пишешь типы. T>Про ключевые слова, да есть приятная экономия на их отсутствии, например public, protected, private, static, var, virtual, override, abstract, out, operator, ref, readonly, new, enum, explicit, implicit переименованы в более лаконичное ключевое слово "". T>Остальные ключевые слова если и лаконичнее, то это совершенно незаметно. Я про синтаксис питона, он короче моего просто потому что ключевые слова короче. А общий подход — тот же. Все равно нужны ключевые слова, и общие компоненты выражения совпадают. А ты приводил его как образец лучшего синтаксиса ВВ>>Ага, тоже решение интересное. Вводим префиксы для переменных. Теперь у нас будут $x, @x и обязательно @@x. ВВ>>Причем знаешь, что самое забавное? Префикс префиксом, но this-то все равно передавать надо T>В Ruby, насколько мне известно, два префикса. Это @foo как сахар к this.foo и :foo синтаксис возвращающий атом (приблизительно const foo = "foo"). Ну и как-то не Perl, нормально с двумя префиксами. Вообще там же есть и "@@" префикс тоже. Хотя уже не помню, зачем он. T>Но ладно, я понял, тебе не нравится. Дело не в том, нравится или нет. Префикс никак не избавляет от необходимости неявно передавать this. Префикс альтернатива самой записи — вместо this.x пишем @x. Лучше это или хуже — неважно, ибо это вообще совсем другой вопрос. this-то все равно нужен, и его надо как-то передавать. Ты привел две альтернативы: 1. Питон. this передается неявно, но при этом указывается в сигнатуре, благодаря чему функция вызывается с одной сигнатурой, а описывается с другой. У меня есть серьезные сомнения в том, что это лучше. К тому же проблема неявной передачи this не решена. 2. Руби. Вместо this используется сигма. Но this все равно передается неявно (а откуда еще ему взяться?). Т.е. ты просто предложил альтернативный синтаксис вместо this. А разговор начинался именно с того, что неявная передача this — это плохо и с ней нужно как-то бороться. Ela 0.9 Dynamic, functional, strict and lazy |
| Re[63]: Динамические языки и переменные | |
| От: | Temoto | |
| Дата: | 18.03.10 13:35 |
| ВВ>Нет, конечно. А что есть генераторы парсеров, у которых сканеры на регекспах? Регекспы штука небыстрая вообще. Тааакк... какой самый известный лексер в мире?ВВ>Т.е. все-таки туплы нужны Особенно, если нет возможности сортировать по нескольким полям.Можно сказать, что списки нужны и ничего не изменится, если ты об этом. ВВ>А ведь еще можно вспомнить, что сортировать можно по одному выражению, а выбирать по другому. Да, потому что выборка и сортировка это разные вещи. Они совмещены в SQL и LINQ. Я не хочу сказать, что это плохо, что они совмещены. Я хочу сказать, что там где они не совмещены, тоже всё нормально и те же задачи решаются так же легко. T>>Но ладно, я понял, тебе не нравится. ВВ>Дело не в том, нравится или нет. Префикс никак не избавляет от необходимости неявно передавать this. Префикс альтернатива самой записи — вместо this.x пишем @x. Лучше это или хуже — неважно, ибо это вообще совсем другой вопрос. this-то все равно нужен, и его надо как-то передавать. ВВ>Ты привел две альтернативы: ВВ>1. Питон. this передается неявно, но при этом указывается в сигнатуре, благодаря чему функция вызывается с одной сигнатурой, а описывается с другой. У меня есть серьезные сомнения в том, что это лучше. К тому же проблема неявной передачи this не решена. ВВ>2. Руби. Вместо this используется сигма. Но this все равно передается неявно (а откуда еще ему взяться?). Т.е. ты просто предложил альтернативный синтаксис вместо this. ВВ>А разговор начинался именно с того, что неявная передача this — это плохо и с ней нужно как-то бороться. obj.GetEven = let x from this.Items where x % 2 == 0; Вот с чего начинался разговор. И меня немного смущает, что ты можешь obj.GetEven сунуть функцию, в теле которой используется this и функцию, в теле которой this не используется. То есть где-то там, в километре строк отсюда, объявлена функция, в теле которой используется this. И к какому объекту будет применён этот this — никто не знает. Лично меня это очень сильно расстраивает в жаваскрипте. И я привел пример с Python2, где есть функции и методы (уже привязанные к конкретному объекту (bound) и ещё непривязанные (unbound), но это довольно хитрая система, в Python3 только функции во всех случаях). И конечно, я тебя запутал сравнением двух видов методов. Давай сначала, с акцентом на нужном. obj = TheClass() def normal_function(): # явно работаем с конкретным объектом. Никаких this в этом скопе нет. # Фактически, это обыкновенная функция обычным образом замкнутая на obj. return obj.y + obj.z obj.GetEven = normal_function Чтобы прострелить себе ногу и всё-таки создать метод ада, который будет иметь доступ сам не знает к чьим полям, нужно прицепить его не к объекту, а к классу этого объекта. def function_that_wants_to_be_your_method(this): return 100500 + this.2 # километры кода # .. # ... # .. # километры кода obj.__class__.GetEven = function_that_wants_to_be_your_method или TheClass.GetEven = function_that_wants_to_be_your_method Видишь теперь какая тут опасность таится? В C# эта проблема решена тем, что методы нельзя объявлять вне скопа класса, поэтому всем понятно что значит this. А тут будет непонятно. Как в жаваскрипте. |
| Re[64]: Динамические языки и переменные | |
| От: | Воронков Василий | |
| Дата: | 18.03.10 17:09 |
| Здравствуйте, Temoto, Вы писали: ВВ>>Нет, конечно. А что есть генераторы парсеров, у которых сканеры на регекспах? Регекспы штука небыстрая вообще. T>Тааакк... какой самый известный лексер в мире?Какой? И почему "лексер"? ВВ>>А ведь еще можно вспомнить, что сортировать можно по одному выражению, а выбирать по другому. T>Да, потому что выборка и сортировка это разные вещи. Они совмещены в SQL и LINQ. Я не хочу сказать, что это плохо, что они совмещены. Я хочу сказать, что там где они не совмещены, тоже всё нормально и те же задачи решаются так же легко. Может быть. Но как написать аналогичный код на Хаскеле ты так и не показал. T>И меня немного смущает, что ты можешь obj.GetEven сунуть функцию, в теле которой используется this и функцию, в теле которой this не используется. То есть где-то там, в километре строк отсюда, объявлена функция, в теле которой используется this. И к какому объекту будет применён этот this — никто не знает. Лично меня это очень сильно расстраивает в жаваскрипте. Мне вообще казалось, что эта фича. Ты одну и ту же функцию можешь использовать как член различных объектов и она будет работать по-разному. А какие могут быть с этим проблемы? Неочевидно?Ну так вроде динамика же, "позднее связывание" c this, так сказать. T>В C# эта проблема решена тем, что методы нельзя объявлять вне скопа класса, поэтому всем понятно что значит this. А тут будет непонятно. Как в жаваскрипте. Нельзя, но смысл "this" все равно может отличаться. Объектно-ориентированный же язык. При желании можно даже извернуться, что this будет null. У меня если ф-ция не вызывается как член объекта, то this == null. В ДжаваСкрипте же все совсем по-другому, там другой this. this — это просто создание/обращение к особой переменной внутри замыкания, к которой можно обращаться в извне. Вообще любой объект в ДжаваСкрипте — это функция.
ЗЫ. Кстати, я тут переделал грамматику, теперь все является expression. Можно писать всякую хрень вида:
Ela 0.9 Dynamic, functional, strict and lazy |
| Re[65]: Динамические языки и переменные | |
| От: | Temoto | |
| Дата: | 18.03.10 17:29 |
| ВВ>>>Нет, конечно. А что есть генераторы парсеров, у которых сканеры на регекспах? Регекспы штука небыстрая вообще. T>>Тааакк... какой самый известный лексер в мире?ВВ>Какой? И почему "лексер"? Это я тебя спрашиваю. Лексер, потому что он занимается тем, что бьёт входной поток байтов на лексемы. lex/Flex ничего не напоминает? ВВ>>>А ведь еще можно вспомнить, что сортировать можно по одному выражению, а выбирать по другому. T>>Да, потому что выборка и сортировка это разные вещи. Они совмещены в SQL и LINQ. Я не хочу сказать, что это плохо, что они совмещены. Я хочу сказать, что там где они не совмещены, тоже всё нормально и те же задачи решаются так же легко. ВВ>Может быть. Но как написать аналогичный код на Хаскеле ты так и не показал. А тебе это правда интересно? Список будет окружён вызовом sortBy, никакой фантастики. А потом к нему будет применена выборка. И может быть это не самый лучший способ. T>>И меня немного смущает, что ты можешь obj.GetEven сунуть функцию, в теле которой используется this и функцию, в теле которой this не используется. То есть где-то там, в километре строк отсюда, объявлена функция, в теле которой используется this. И к какому объекту будет применён этот this — никто не знает. Лично меня это очень сильно расстраивает в жаваскрипте. ВВ>Мне вообще казалось, что эта фича. Ты одну и ту же функцию можешь использовать как член различных объектов и она будет работать по-разному. А какие могут быть с этим проблемы? Неочевидно?ВВ>Ну так вроде динамика же, "позднее связывание" c this, так сказать. Вот я тебе точно скажу, из опыта с Javascript, что "позднее связывание с this" может только мешать. ВВ>ЗЫ. Кстати, я тут переделал грамматику, теперь все является expression. Можно писать всякую хрень вида: ВВ>
Круто Поздравляю. По такому поводу, наверное и else стал обязательным, как это часто бывает в языках без statement? |
| Re[66]: Динамические языки и переменные | |
| От: | Воронков Василий | |
| Дата: | 18.03.10 18:15 |
| Здравствуйте, Temoto, Вы писали: T>Это я тебя спрашиваю. Лексер, потому что он занимается тем, что бьёт входной поток байтов на лексемы. T>lex/Flex ничего не напоминает? Я как-то не задавался вопросом, какой самый популярный. ВВ>>Может быть. Но как написать аналогичный код на Хаскеле ты так и не показал. T>А тебе это правда интересно? Список будет окружён вызовом sortBy, никакой фантастики. А потом к нему будет применена выборка. И может быть это не самый лучший способ. Если бы не было интересно, то не спрашивал бы. T>>>И меня немного смущает, что ты можешь obj.GetEven сунуть функцию, в теле которой используется this и функцию, в теле которой this не используется. То есть где-то там, в километре строк отсюда, объявлена функция, в теле которой используется this. И к какому объекту будет применён этот this — никто не знает. Лично меня это очень сильно расстраивает в жаваскрипте. ВВ>>Мне вообще казалось, что эта фича. Ты одну и ту же функцию можешь использовать как член различных объектов и она будет работать по-разному. А какие могут быть с этим проблемы? Неочевидно?ВВ>>Ну так вроде динамика же, "позднее связывание" c this, так сказать. T>Вот я тебе точно скажу, из опыта с Javascript, что "позднее связывание с this" может только мешать. А без позднего связывания функцию с this можно создать только при описании самого объекта. Серьезное ограничение ИМХО. Получается, что функции прибиваются к объектам. T>Круто T>Поздравляю. T>По такому поводу, наверное и else стал обязательным, как это часто бывает в языках без statement? Нет, сейчас выражение без else равносильно if (x) something else null; Ela 0.9 Dynamic, functional, strict and lazy |
| Re[67]: Динамические языки и переменные | |
| От: | Temoto | |
| Дата: | 18.03.10 18:33 |
| Здравствуйте, Воронков Василий, Вы писали: ВВ>Здравствуйте, Temoto, Вы писали: T>>Это я тебя спрашиваю. Лексер, потому что он занимается тем, что бьёт входной поток байтов на лексемы. T>>lex/Flex ничего не напоминает? ВВ>Я как-то не задавался вопросом, какой самый популярный. Ну это как бы классика. Это как знать про язык программирования Си. Популярный и известный, на мой взгляд, разные вещи. ВВ>>>Мне вообще казалось, что эта фича. Ты одну и ту же функцию можешь использовать как член различных объектов и она будет работать по-разному. А какие могут быть с этим проблемы? Неочевидно?ВВ>>>Ну так вроде динамика же, "позднее связывание" c this, так сказать. T>>Вот я тебе точно скажу, из опыта с Javascript, что "позднее связывание с this" может только мешать. ВВ>А без позднего связывания функцию с this можно создать только при описании самого объекта. Серьезное ограничение ИМХО. Получается, что функции прибиваются к объектам. Да, действительно, я не точно выразился. Конкретно такое неявное позднее связывание с this, как в жаваскрипте — источник многих головных болей. T>>Круто T>>Поздравляю. T>>По такому поводу, наверное и else стал обязательным, как это часто бывает в языках без statement? ВВ>Нет, сейчас выражение без else равносильно if (x) something else null; В общем, null по-умолчанию везде, из-за чего его практическая ценность несколько занижается. А if (null) это ошибка типов или как false? |
| Re[68]: Динамические языки и переменные | |
| От: | Воронков Василий | |
| Дата: | 18.03.10 18:49 |
| Здравствуйте, Temoto, Вы писали: ВВ>>Я как-то не задавался вопросом, какой самый популярный. T>Ну это как бы классика. Это как знать про язык программирования Си. Популярный и известный, на мой взгляд, разные вещи. А, Лекс. А то я его без Yacc-a то и не узнал. ВВ>>А без позднего связывания функцию с this можно создать только при описании самого объекта. Серьезное ограничение ИМХО. Получается, что функции прибиваются к объектам. T>Да, действительно, я не точно выразился. Конкретно такое неявное позднее связывание с this, как в жаваскрипте — источник многих головных болей. Например? ВВ>>Нет, сейчас выражение без else равносильно if (x) something else null; T>В общем, null по-умолчанию везде, из-за чего его практическая ценность несколько занижается. Это я не понял. T>А if (null) это ошибка типов или как false? Ошибка типов это круто Нет, конечно, ошибок не будет, все спокойно приводится. null, он же 0, он же false. Для строгих проверок есть операторы === и !==:
Выведет только "null == 0". Сие не я придумал, вроде как известная фишка. Ela 0.9 Dynamic, functional, strict and lazy |
| Re[69]: Динамические языки и переменные | |
| От: | Temoto | |
| Дата: | 18.03.10 19:22 |
| ВВ>>>Я как-то не задавался вопросом, какой самый популярный. T>>Ну это как бы классика. Это как знать про язык программирования Си. Популярный и известный, на мой взгляд, разные вещи. ВВ>А, Лекс. А то я его без Yacc-a то и не узнал. Так вот, лекс токенизирует по регекспам. ВВ>>>А без позднего связывания функцию с this можно создать только при описании самого объекта. Серьезное ограничение ИМХО. Получается, что функции прибиваются к объектам. T>>Да, действительно, я не точно выразился. Конкретно такое неявное позднее связывание с this, как в жаваскрипте — источник многих головных болей. ВВ>Например? Например, определение метода объекта внутри метода другого объекта. ВВ>>>Нет, сейчас выражение без else равносильно if (x) something else null; T>>В общем, null по-умолчанию везде, из-за чего его практическая ценность несколько занижается. ВВ>Это я не понял. Меньше известно почему сработала проверка if (что-то == null): это кодомен (потому что оно равно/вернуло null) или это дефолтное значение. T>>А if (null) это ошибка типов или как false? ВВ>Ошибка типов это круто ВВ>Нет, конечно, ошибок не будет, все спокойно приводится. null, он же 0, он же false. Это делает проверку if (func()) или if (obj.attr) ещё менее полезной. Причина выше. ВВ>Для строгих проверок есть операторы === и !==: И строка "19" в число автоматом приведётся? |
| Re[70]: Динамические языки и переменные | |
| От: | Воронков Василий | |
| Дата: | 18.03.10 19:35 |
| Здравствуйте, Temoto, Вы писали: ВВ>>>>Я как-то не задавался вопросом, какой самый популярный. T>>>Ну это как бы классика. Это как знать про язык программирования Си. Популярный и известный, на мой взгляд, разные вещи. ВВ>>А, Лекс. А то я его без Yacc-a то и не узнал. T>Так вот, лекс токенизирует по регекспам. ОК. А код на C# он умеет генерить? ВВ>>>>А без позднего связывания функцию с this можно создать только при описании самого объекта. Серьезное ограничение ИМХО. Получается, что функции прибиваются к объектам. T>>>Да, действительно, я не точно выразился. Конкретно такое неявное позднее связывание с this, как в жаваскрипте — источник многих головных болей. ВВ>>Например? T>Например, определение метода объекта внутри метода другого объекта. А какие проблемы вызывает данная ситуация? this же не замыкается, на то и он this, то бишь тут. Конфликта между this-ами тоже не будет. Захвачен this не может — это не настоящая переменная, и у нее на самом деле нет имени. T>>>А if (null) это ошибка типов или как false? ВВ>>Ошибка типов это круто ВВ>>Нет, конечно, ошибок не будет, все спокойно приводится. null, он же 0, он же false. T>Это делает проверку if (func()) или if (obj.attr) ещё менее полезной. Причина выше. Делать булевые операции строгими на фоне остальной динамики нелогично. К тому же вышепоказанное тобой поведение вряд ли кого-то удивит, многие языки со статической типизацией этим грешат. А так мы постепенно приходим к тому, что динамика вообще постепенно вытравляется Это ты ведь к примеру с bool обратился, а возьми любые другие типы — там ситуация будет аналогичной. Куча неявных приведений. Так на то это и динамика, блин. ВВ>>Для строгих проверок есть операторы === и !==: T>И строка "19" в число автоматом приведётся? Нет, число автоматом приведется к строке: "19" + 1 == "191" int("19") + 1 == 20 Ela 0.9 Dynamic, functional, strict and lazy |
| Re[66]: Динамические языки и переменные | |
| От: | Воронков Василий | |
| Дата: | 18.03.10 19:41 |
| Здравствуйте, Temoto, Вы писали: T>По такому поводу, наверное и else стал обязательным, как это часто бывает в языках без statement? Кстати говоря, я вообще могу сделать так, что else будет обязательным когда if/else используется как expression, а когда как statement — не будет:
Ela 0.9 Dynamic, functional, strict and lazy |
| Re[71]: Динамические языки и переменные | |
| От: | Temoto | |
| Дата: | 18.03.10 19:52 |
| ВВ>>>А, Лекс. А то я его без Yacc-a то и не узнал. T>>Так вот, лекс токенизирует по регекспам. ВВ>ОК. А код на C# он умеет генерить? По-моему, токенизация и генерация кода это какие-то ну никак не связанные задачи. Как чтение файла и умножение целых чисел.T>>Например, определение метода объекта внутри метода другого объекта. ВВ>А какие проблемы вызывает данная ситуация? this же не замыкается, на то и он this, то бишь тут. Конфликта между this-ами тоже не будет. Захвачен this не может — это не настоящая переменная, и у нее на самом деле нет имени. Я не про проблемы компилятора. Я про проблемы человека, который это читает. У него скопы действия разных this разными цветами не подсвечены. T>>Это делает проверку if (func()) или if (obj.attr) ещё менее полезной. Причина выше. ВВ>Делать булевые операции строгими на фоне остальной динамики нелогично. К тому же вышепоказанное тобой поведение вряд ли кого-то удивит, многие языки со статической типизацией этим грешат. ВВ>А так мы постепенно приходим к тому, что динамика вообще постепенно вытравляется Динамика и строгость — ортогональные вещи. Ты можешь привести пример, где динамика мешает строгости или наоборот? ВВ>Это ты ведь к примеру с bool обратился, а возьми любые другие типы — там ситуация будет аналогичной. Куча неявных приведений. Так на то это и динамика, блин. Ты путаешь PHP и динамику. Динамическая типизация это когда тип неизвестен на этапе компиляции. Всё. Строгая типизация, это когда число неявно не приводится к строкам и наоборот. Когда компиляция или рантайм вообще различает типы. Может быть компилируемый язык с нестрогой типизацией (и много сегфолтов) и динамический со строгой (например, Python, особенно в третьей версии, там строки с байтами не сравниваются и None ни с чем кроме себя не сравнивается). ВВ>>>Для строгих проверок есть операторы === и !==: T>>И строка "19" в число автоматом приведётся? ВВ>Нет, число автоматом приведется к строке: ВВ>"19" + 1 == "191" ВВ>int("19") + 1 == 20 О боги. Тогда уже точно в предложении "Сие не я придумал, вроде как известная фишка." ты пропустил слово PHP. |
| Re[67]: Динамические языки и переменные | |
| От: | Temoto | |
| Дата: | 18.03.10 19:57 |
| T>>По такому поводу, наверное и else стал обязательным, как это часто бывает в языках без statement? ВВ>Кстати говоря, я вообще могу сделать так, что else будет обязательным когда if/else используется как expression, а когда как statement — не будет: ВВ>
Конечно можешь мне так понравится. А должно понравиться не мне. |
| Re[72]: Динамические языки и переменные | |
| От: | Воронков Василий | |
| Дата: | 18.03.10 20:25 |
| Здравствуйте, Temoto, Вы писали: ВВ>>>>А, Лекс. А то я его без Yacc-a то и не узнал. T>>>Так вот, лекс токенизирует по регекспам. ВВ>>ОК. А код на C# он умеет генерить? T> По-моему, токенизация и генерация кода это какие-то ну никак не связанные задачи. Как чтение файла и умножение целых чисел.Ну абстрактная токенизация мне мало поможет. Мне как бы код нужен, на C#. Причем желательно быстрый. T>>>Например, определение метода объекта внутри метода другого объекта. ВВ>>А какие проблемы вызывает данная ситуация? this же не замыкается, на то и он this, то бишь тут. Конфликта между this-ами тоже не будет. Захвачен this не может — это не настоящая переменная, и у нее на самом деле нет имени. T>Я не про проблемы компилятора. Я про проблемы человека, который это читает. У него скопы действия разных this разными цветами не подсвечены. Ну пока мне кажется, что это надуманная проблема. Так можно и вложенным классам придраться. Там тоже "скопы действия this" разными цветами не подсвечиваются. T>>>Это делает проверку if (func()) или if (obj.attr) ещё менее полезной. Причина выше. ВВ>>Делать булевые операции строгими на фоне остальной динамики нелогично. К тому же вышепоказанное тобой поведение вряд ли кого-то удивит, многие языки со статической типизацией этим грешат. ВВ>>А так мы постепенно приходим к тому, что динамика вообще постепенно вытравляется T>Динамика и строгость — ортогональные вещи. Ты можешь привести пример, где динамика мешает строгости или наоборот? Мне кажется странным, что не указывая типы при объявлении переменных мы потом начинаем их указывать постоянно при совершении практически любых операций. Т.е. занимаемся приведением типов. Бенефиты динамики при этом уплывают далеко и надолго. ВВ>>Это ты ведь к примеру с bool обратился, а возьми любые другие типы — там ситуация будет аналогичной. Куча неявных приведений. Так на то это и динамика, блин. T>Ты путаешь PHP и динамику. В любом языке есть неявные привидения. Причем тут PHP? Операторы === и !== есть, кстати, и в ДжаваСкрипте. T>Динамическая типизация это когда тип неизвестен на этапе компиляции. Всё. T>Строгая типизация, это когда число неявно не приводится к строкам и наоборот. Когда компиляция или рантайм вообще различает типы. T>Может быть компилируемый язык с нестрогой типизацией (и много сегфолтов) и динамический со строгой (например, Python, особенно в третьей версии, там строки с байтами не сравниваются и None ни с чем кроме себя не сравнивается). T>О боги. Тогда уже точно в предложении "Сие не я придумал, вроде как известная фишка." ты пропустил слово PHP. Что, тебя поражает то, что в результате "19" + 1 = "191"? Вообще это не PHP, это утипизированный по самое не могу C#:
Абсолютно корректный код. В С/C++ можно спокойно использовать небулевые выражения в if-ах. Все это строго-типизированные языки. Ela 0.9 Dynamic, functional, strict and lazy |
| Re[73]: Динамические языки и переменные | |
| От: | Temoto | |
| Дата: | 18.03.10 22:05 |
| ВВ>>>ОК. А код на C# он умеет генерить? T>> По-моему, токенизация и генерация кода это какие-то ну никак не связанные задачи. Как чтение файла и умножение целых чисел.ВВ>Ну абстрактная токенизация мне мало поможет. Мне как бы код нужен, на C#. Причем желательно быстрый. Я понял, что твоя прога генерит код на C# (что для меня странно, кстати, у вас же там MSIL специально для этого есть). И видимо ты используешь какую-то библиотеку, которая сразу парсит и генерит код. Но это совсем не очевидно. Библиотека могла бы брать на вход поток токенов, сосканить которые из байтов — твоя задача. Или ещё какой-нибудь другой интерфейс иметь. T>>Я не про проблемы компилятора. Я про проблемы человека, который это читает. У него скопы действия разных this разными цветами не подсвечены. ВВ>Ну пока мне кажется, что это надуманная проблема. Так можно и вложенным классам придраться. Там тоже "скопы действия this" разными цветами не подсвечиваются. Я видел не надуманный код на жаваскрипте, в котором эта проблема была не надумана. T>>Динамика и строгость — ортогональные вещи. Ты можешь привести пример, где динамика мешает строгости или наоборот? ВВ>Мне кажется странным, что не указывая типы при объявлении переменных мы потом начинаем их указывать постоянно при совершении практически любых операций. Т.е. занимаемся приведением типов. ВВ>Бенефиты динамики при этом уплывают далеко и надолго. Не указание типов при объявлении переменных тоже ортогонально динамике. В C# есть var. Но типизация статическая. ВВ>>>Это ты ведь к примеру с bool обратился, а возьми любые другие типы — там ситуация будет аналогичной. Куча неявных приведений. Так на то это и динамика, блин. T>>Ты путаешь PHP и динамику. ВВ>В любом языке есть неявные привидения. Причем тут PHP? Операторы === и !== есть, кстати, и в ДжаваСкрипте. При том, что PHP, пожалуй, — король неявных приведений, нестрогой типизации. И действительно, ты правильно сказал, что в любом (ну, не в любом конечно, есть полностью строго типизированные, без неявных приведений, но не суть) языке есть какая-то доля неявных приведений. И эта доля, конечно отличается от языка к языку. Но ты этим ведь только подтвердил, что ты путаешь строгость типизации и динамику. Вот в шарпе динамики нет, а неявных приведений до жопы. У тебя язык полностью динамический, неявных приведений до жопы. Вывод: строгость типизации ортогональна динамике. ВВ>Что, тебя поражает то, что в результате "19" + 1 = "191"? Вообще это не PHP, это утипизированный по самое не могу C#: Да, я уже забыл как это в шарпе и поэтому меня это поражает. В PHP точно так же будет произведено неявное приведение, только в другую сторону. Этот код даст число 20.Понимаешь теперь чем плохо неявное приведение? Есть три языка. * "19" + 1 == "191" * "19" + 1 == 20 * "19" + 1 <- Type error: incompatible values for operator '+': String and Integer. Какой из них интуитивно понятнее? Думаю, что все одинаково. Понятность приведений, наверное, субъективна. Какой помогает не допустить ошибок? Думаю, что третий. Только у него непредвзятое мнение о твоих намерениях, без предположений. ВВ>Абсолютно корректный код. В С/C++ можно спокойно использовать небулевые выражения в if-ах. Все это строго-типизированные языки. В С нельзя использовать небулевые выражения в if-ах. Потому что в C89 булевых типов просто нет, вместо них очень конкретное правило: 0 это ложь, а любое другое число — истина. И почти многие типы неявно приводятся к числам, да. Поэтому кажется, что можно проверять на истинность любое выражение. На самом деле ты проверяешь выражение != 0. Например, вот такое выражение if (struct s) {...} будет ошибочным, потому что структуры к числам неявно не приводятся. И конкретно в Си это по-своему логично. Потому что Си это кросплатформенный ассемблер, он оперирует только числами (ну структуры ещё). То есть, в каком-то странном смысле в си два типа: числа (с тегами int, char, указатель — для проверки совместимости разных видов чисел) и структуры. if в спецификации объявлен как работающий только с числами. И он работает только с числами. Ты неправильно напал на си. Он именно в плане if как раз самый чистый. Там есть куча других приведений, "", например, приводится к числу — адресу этой строки. Ну плохо, да. Но вот с if ты как раз промахнулся. За плюсы не буду говорить, я их не знаю. Множество неявных приведений конкретно в шарпе не раз ругали именно в этих форумах, кстати. Но в общем, смысл такой, что ты взял логику приведения типов из шарпа. Ну хакей, раз так удобнее пользователям, значит всё хорошо. Я просто посоветую в будущем посмотреть на более строго типизированные языки. |
| Re[74]: Динамические языки и переменные | |
| От: | Воронков Василий | |
| Дата: | 18.03.10 22:23 |
| Здравствуйте, Temoto, Вы писали: ВВ>>Ну абстрактная токенизация мне мало поможет. Мне как бы код нужен, на C#. Причем желательно быстрый. T>Я понял, что твоя прога генерит код на C# (что для меня странно, кстати, у вас же там MSIL специально для этого есть). Какая прога? Я вообще не понял — ты хочешь генератор парсеров, который бинарник сразу генерит? Это жесть какая-то T>И видимо ты используешь какую-то библиотеку, которая сразу парсит и генерит код. Но это совсем не очевидно. Библиотека могла бы брать на вход поток токенов, сосканить которые из байтов — твоя задача. Или ещё какой-нибудь другой интерфейс иметь. Тоже ничего не понял. Я генерю парсер. Тот же твой Лекс генерирует парсер на С, просто код парсера. Я генерирую парсер на C#. Исходный код на Ela сначала транслируется в AST, затем компилируется в промежуточный байт-код, который потом исполняется на виртуальной машине. T>>>Я не про проблемы компилятора. Я про проблемы человека, который это читает. У него скопы действия разных this разными цветами не подсвечены. ВВ>>Ну пока мне кажется, что это надуманная проблема. Так можно и вложенным классам придраться. Там тоже "скопы действия this" разными цветами не подсвечиваются. T>Я видел не надуманный код на жаваскрипте, в котором эта проблема была не надумана. Пример? T>>>Динамика и строгость — ортогональные вещи. Ты можешь привести пример, где динамика мешает строгости или наоборот? ВВ>>Мне кажется странным, что не указывая типы при объявлении переменных мы потом начинаем их указывать постоянно при совершении практически любых операций. Т.е. занимаемся приведением типов. ВВ>>Бенефиты динамики при этом уплывают далеко и надолго. T>Не указание типов при объявлении переменных тоже ортогонально динамике. В C# есть var. Но типизация статическая. Вот у тебя и получается, что динамика — это вывод типов для бедных. ВВ>>>>Это ты ведь к примеру с bool обратился, а возьми любые другие типы — там ситуация будет аналогичной. Куча неявных приведений. Так на то это и динамика, блин. T>>>Ты путаешь PHP и динамику. ВВ>>В любом языке есть неявные привидения. Причем тут PHP? Операторы === и !== есть, кстати, и в ДжаваСкрипте. T>При том, что PHP, пожалуй, — король неявных приведений, нестрогой типизации. Почему PHP-то именно? ДжаваСкрипт чем хуже? T>Есть три языка. T>* "19" + 1 == "191" T>* "19" + 1 == 20 T>* "19" + 1 <- Type error: incompatible values for operator '+': String and Integer. T>Какой из них интуитивно понятнее? Думаю, что все одинаково. Понятность приведений, наверное, субъективна. T>Какой помогает не допустить ошибок? Думаю, что третий. Только у него непредвзятое мнение о твоих намерениях, без предположений. Я на том же шарпе уже лет восемь пишу, естественно, мне первый вариант понятнее. ВВ>>Абсолютно корректный код. В С/C++ можно спокойно использовать небулевые выражения в if-ах. Все это строго-типизированные языки. T>В С нельзя использовать небулевые выражения в if-ах. Потому что в C89 булевых типов просто нет, вместо них очень конкретное правило: 0 это ложь, а любое другое число — истина. Причем тут С89? Возьми стандарт хотя бы десятилетней давности, там все есть T>И почти многие типы неявно приводятся к числам, да. Поэтому кажется, что можно проверять на истинность любое выражение. На самом деле ты проверяешь выражение != 0. Например, вот такое выражение if (struct s) {...} будет ошибочным, потому что структуры к числам неявно не приводятся. И конкретно в Си это по-своему логично. Потому что Си это кросплатформенный ассемблер, он оперирует только числами (ну структуры ещё). То есть, в каком-то странном смысле в си два типа: числа (с тегами int, char, указатель — для проверки совместимости разных видов чисел) и структуры. if в спецификации объявлен как работающий только с числами. И он работает только с числами. Ты неправильно напал на си. Он именно в плане if как раз самый чистый. Там есть куча других приведений, "", например, приводится к числу — адресу этой строки. Ну плохо, да. Но вот с if ты как раз промахнулся. Ни с чем я не промахнулся. bool в С есть. А какое там этот bool на самом деле имеет представление вопрос десятый. У меня тоже bool имеет представление I4. T>За плюсы не буду говорить, я их не знаю. T>Множество неявных приведений конкретно в шарпе не раз ругали именно в этих форумах, кстати. Но в общем, смысл такой, что ты взял логику приведения типов из шарпа. Ну хакей, раз так удобнее пользователям, значит всё хорошо. Я просто посоветую в будущем посмотреть на более строго типизированные языки. Ela 0.9 Dynamic, functional, strict and lazy |
| Re[75]: Динамические языки и переменные | |
| От: | Temoto | |
| Дата: | 18.03.10 23:35 |
| Здравствуйте, Воронков Василий, Вы писали: ВВ>Здравствуйте, Temoto, Вы писали: ВВ>>>Ну абстрактная токенизация мне мало поможет. Мне как бы код нужен, на C#. Причем желательно быстрый. T>>Я понял, что твоя прога генерит код на C# (что для меня странно, кстати, у вас же там MSIL специально для этого есть). ВВ>Какая прога? Я вообще не понял — ты хочешь генератор парсеров, который бинарник сразу генерит? Это жесть какая-то Ela. И я не хочу никаких генераторов. Мы твой язык обсуждаем. T>>И видимо ты используешь какую-то библиотеку, которая сразу парсит и генерит код. Но это совсем не очевидно. Библиотека могла бы брать на вход поток токенов, сосканить которые из байтов — твоя задача. Или ещё какой-нибудь другой интерфейс иметь. ВВ>Тоже ничего не понял. Я генерю парсер. Тот же твой Лекс генерирует парсер на С, просто код парсера. Я генерирую парсер на C#. Исходный код на Ela сначала транслируется в AST, затем компилируется в промежуточный байт-код, который потом исполняется на виртуальной машине. То, что ты *генеришь* парсер тоже не очевидно. Он мог бы быть у тебя статично записан уже рабочим кодом. Это не подходит для всех грамматик, но и не само собой подразумевается. Но хакей, теперь всё ясно. T>>Я видел не надуманный код на жаваскрипте, в котором эта проблема была не надумана. ВВ>Пример?
ВВ>>>Мне кажется странным, что не указывая типы при объявлении переменных мы потом начинаем их указывать постоянно при совершении практически любых операций. Т.е. занимаемся приведением типов. ВВ>>>Бенефиты динамики при этом уплывают далеко и надолго. T>>Не указание типов при объявлении переменных тоже ортогонально динамике. В C# есть var. Но типизация статическая. ВВ>Вот у тебя и получается, что динамика — это вывод типов для бедных. Это утверждение, на мой взгляд, алогично. Честно, пытался понять как ты это вывел, но не смог. Если объяснишь — спасибо. (я не подкалываю) Википедия: http://ru.wikipedia.org/wiki/Динамическая_типизация
1. Причём тут объявление и вывод типов? (на это можно не отвечать, это у нас просто разговор в сторону ушёл) 2. Каким образом более строгая типизация мешает впоследствии присваивать переменной значения других типов? (вот это ты утверждал, что строгость убивает динамику. Будь добр обоснуй) ВВ>>>В любом языке есть неявные привидения. Причем тут PHP? Операторы === и !== есть, кстати, и в ДжаваСкрипте. T>>При том, что PHP, пожалуй, — король неявных приведений, нестрогой типизации. ВВ>Почему PHP-то именно? ДжаваСкрипт чем хуже? Потому что PHP обиднее. T>>Есть три языка. T>>* "19" + 1 == "191" T>>* "19" + 1 == 20 T>>* "19" + 1 <- Type error: incompatible values for operator '+': String and Integer. T>>Какой из них интуитивно понятнее? Думаю, что все одинаково. Понятность приведений, наверное, субъективна. T>>Какой помогает не допустить ошибок? Думаю, что третий. Только у него непредвзятое мнение о твоих намерениях, без предположений. ВВ>Я на том же шарпе уже лет восемь пишу, естественно, мне первый вариант понятнее. Щас сначала почему именно эти два вопроса... есть мнение, что язык должен а) быть понятным б) помогать не допускать ошибок. Если ты согласен с этим мнением, то мне интересно считаешь ли ты что третий язык помогает не допустить больше ошибок, чем первые два. Если ты не считаешь, что язык должен помогать не допускать ошибки, то на нет и суда нет. ВВ>Ни с чем я не промахнулся. bool в С есть. А какое там этот bool на самом деле имеет представление вопрос десятый. У меня тоже bool имеет представление I4. Хорошо, ты всех победил. bool не имеет отношения к if до тех пор, пока в спецификации не будет написано, что в if (expr) expr должно быть bool. И я не поленился заглянуть в спеку C99 и нашёл там вот что: 1. "An object declared as type _Bool is large enough to store the values 0 and 1." То есть bool это подвид числа. 2. (про if statement) "In both forms, the first substatement is executed if the expression compares unequal to 0." То есть if всё ещё не работает конкретно с типом bool. Он работает с числами. Так что в плане if Си всё-таки именно полностью строго типизирован. Я ничего не говорил о внутреннем представлении (и bool — подвид числа тоже не про внутреннее представление. Потому что можно . Я говорил, что у Си, как у кросплатформенного ассемблера относительно гармонично приведение всех типов к числу. Насколько в шарпе, который весь такой объектно-ориентированный, гармонично приведение числа к строке — прямой логики я не вижу. Может быть, она есть конечно. Вот если б язык был про обработку строк. Например, в баше или awk приведение всех типов к строке вполне гармонично и понятно. Понимаешь? Я хочу сказать, что у языка должна быть идея. И все решения, типа там вводить ли туплы, приводить ли строки к числам или другие типы или вообще не приводить ничего, явно ли передавать this, лениво вычислять или энергично, какой скоп, динамика или статика, всё это должно исходить из (или логично объясняться в рамках) идеи. А если просто пытаться понабирать "хороших фич", то ничего хорошего не получится. Получится ещё один шарп, то есть каша без идеи. Это не потому что фичи плохие или заимплементили плохо. Это потому что фичи хороши в рамках какой-то целостной картины. И когда их "выдирают из контекста", получается уже не то. |
| Re[76]: Динамические языки и переменные | |
| От: | Воронков Василий | |
| Дата: | 19.03.10 20:30 |
| Здравствуйте, Temoto, Вы писали: T>То, что ты *генеришь* парсер тоже не очевидно. Он мог бы быть у тебя статично записан уже рабочим кодом. Это не подходит для всех грамматик, но и не само собой подразумевается. Ну мне казалось, что очевидно. Сам же про Як с Лексом речь завел. Генерируемый парсер, конечно, не для всех грамматик подходит , но по крайней мере синтаксис можно легко менять.T>
Это мне напоминает пример из области, как же плохо что в неком языке (что за язык, кстати?) нет base. Вопрос был — покажи, где пользователь может запутаться в this-ах. Ты показал, где пользователь не может обратиться к родительскому скопу из-за отсутствия base. Я твою мысль, конечно, понимаю, но вся твоя критика — деструктивная. Т.е. альтернативной идеи попросту нет. Везде, где мне известно, this передается неявно как аргумент функции. Возможность писать this в функции, которая "не привязана" к объекту естественным образом проистекает из того, что "классов" вообще-то нет и "привязать" функцию к объекту нельзя в принципе. Может быть, "неявный" this это и зло, но брать язык с клонированием объектов и вкорячивать туда статический this мне кажется еще большим злом. ВВ>>Вот у тебя и получается, что динамика — это вывод типов для бедных. T>Это утверждение, на мой взгляд, алогично. Честно, пытался понять как ты это вывел, но не смог. Если объяснишь — спасибо. (я не подкалываю) Вывожу это из твоих слов. Не больше и не меньше. Ты уже не в первый раз говоришь, что динамика означает, что тип становится известен только в рантайме. Хорошо, все правильно. Но *кому* этот тип становится известен? Среде исполнения? Программист должен знать этот тип, когда пишет код? Сам попробуй ответить на этот вопрос. Если должен, то получается, что динамика ему никак не помогает. Он все равно работает с конкретными типами, и это просто среда исполнения такая тупая, что может типы вычислить только в рантайме. Интеллектуальная альтернатива — вывод типов. А если не должен, то тогда навязывать ему писать на каждом шагу аннотации для типов, бесконечные преобразования и тайп-касты это несколько неправильно. В статическом языке a + b это операция над конкретными типами данных, в динамическом — это абстрактная операция с именами, если хочешь, это мета-код, что в нек-х языках достигается с помощью, к примеру, шаблонов — возможность писать код, абстрагировавшись от типов. Естественно, это имеет свою цену. ВВ>>Почему PHP-то именно? ДжаваСкрипт чем хуже? T>Потому что PHP обиднее. А, так ты обзываешься? Ну ОК. В следующий раз предупреждай хоть. ВВ>>Я на том же шарпе уже лет восемь пишу, естественно, мне первый вариант понятнее. T>Щас сначала почему именно эти два вопроса... есть мнение, что язык должен а) быть понятным б) помогать не допускать ошибок. Если ты согласен с этим мнением, то мне интересно считаешь ли ты что третий язык помогает не допустить больше ошибок, чем первые два. Если ты не считаешь, что язык должен помогать не допускать ошибки, то на нет и суда нет. Речь о конкретном языке или о чем? Что такое третий язык? В шарпе преобразование типов, которое производит оператор + для строк ни разу проблем у меня не вызвало за весьма долгое время использования данного языка. Ибо типизация статическая, и я всегда знаю, с какими типами я работаю. В каком-то другом языке — может вызовет, может нет. Я не знаю. Вообще, если ты не знаешь, даже в шарпе можно перегружать операторы, к примеру. Т.е. написать свои типы и определить для них базовые арифметические операции, в результате которых будет происходить вообще что-то ортогональное. По твоей логике — это зло, ибо ведет к неочевидному коду. Что, нам теперь урезать возможности языка ради дурако-устойчивости? В твоем любимом Хаскеле, кстати (на сей-то раз не промахнулся? ), можно таких дров наломать, что перегрузка операторов шарпе покажется по сравнению с этим детской забавой.T>bool не имеет отношения к if до тех пор, пока в спецификации не будет написано, что в if (expr) expr должно быть bool. T>И я не поленился заглянуть в спеку C99 и нашёл там вот что: T>1. "An object declared as type _Bool is large enough to store the values 0 and 1." То есть bool это подвид числа. bool — подвид числа, которое может принимать значения 0 и 1. А в остальном обычный интегральный тип. Отличное определение для bool. Я бы не сказал лучше. Непонимаю, что тебе не нравится? T>2. (про if statement) "In both forms, the first substatement is executed if the expression compares unequal to 0." То есть if всё ещё не работает конкретно с типом bool. Он работает с числами. T>Так что в плане if Си всё-таки именно полностью строго типизирован. Вообще конечно С неудачный пример, но вспомнилось. Никто конечно не будет там нарушать совместимость, какие бы новые типы не вводились. T>Понимаешь? Я хочу сказать, что у языка должна быть идея. И все решения, типа там вводить ли туплы, приводить ли строки к числам или другие типы или вообще не приводить ничего, явно ли передавать this, лениво вычислять или энергично, какой скоп, динамика или статика, всё это должно исходить из (или логично объясняться в рамках) идеи. А если просто пытаться понабирать "хороших фич", то ничего хорошего не получится. Получится ещё один шарп, то есть каша без идеи. Это не потому что фичи плохие или заимплементили плохо. Это потому что фичи хороши в рамках какой-то целостной картины. И когда их "выдирают из контекста", получается уже не то. А расскажи-ка лучше, что такое в "Своем Языке" и какая у тебя самого на самом деле идея Ela 0.9 Dynamic, functional, strict and lazy |
| 1 2 3 4 5 6 7 8 9 |