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

MTD>>Ну вот кто нибудь в состоянии привести внятный пример?

DR>Например, аргумент требуется внутри функции в других еденицах. Чтобы случайно не использовать изначальное значение, заводим локальную переменную с тем же именем.

DR>

DR>ComputeKDE(points : array[double], x : double, window : double) : double
DR>{
DR>    def window = HoursToTicks(window);
DR>    // ...
DR>}
DR>

Типичный WTF, теперь когда я в коде увижу window, мне придется подумать, что же это за window

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

VD>Ох-ох-ох. Так как категорично, столь неверное утверждение...

Покури пример

VD>Ты читаешь не внимательно. Я же тебе сказал, что одна из проблем, что не видно промежуточных результатов.

А это ты для отладки такой жуткий код написал? Тогда понятно, ибо в продакшн код такой ужас вряд ли кто в своем уме писать будет.

VD>Приведенный же тобой пример это пример мышления импративщика, потому как в ФП принято просто соединять выхлоп одной функции со входом другой (или вообще соединять сами функции). Фильтрацию я для примера пример. Сами запросы бывают куда хитрее и на все сочетания функций не наделаешь.

[VladD2 mode on]
Если бы ты был знаком с Unix, то знал что это Unix-way соединять вывод одного процесса с входом другого. Это используют даже сишники с незапятных времен.
[VladD2 mode off]

VD>Ладно. Я мог бы с тобой поспорить очень долго и развенчать каждый из твоих домыслов, но вижу что в этом нет смысла. Свое Имею Мнение Хрен Оспоришь ты имеешь. Опыта в обсуждаемом вопросе у тебя явно — ноль. Учиться на чужом опыте это не для тебя. Могу сказать только одно. Попробуй то что критикуешь, тогда сам все поймешь.

Ок. Засчитано.

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

ARK>
ARK>Жесть. Похоже, что при добавлении этой фичи авторы думали не головой, а задом. Что странно, т.к. другие решения выглядят разумными.

Да не такое уж и плохое решение. Как минимум позволяет не вводить лишних имен без надобности. Типичный пример при работе с задачами, когда с одинм потоком будут работать несколько задач и Chan надо конвертировать в SharedChan.:

let (out,in): (Port<int>, Chan<int>) = stream();
let in = SharedChan(in);

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

MTD>Покури пример

Вот аналог на OCaml

(*
  аналог reinterpret_cast<int> из C++ для ссылочных типов 
  выдаст физический адрес объекта.
*)
let reinterpret_cast x : int = Obj.magic (Obj.repr x)


let x = ref 0

let _ = Printf.printf "%d\n" (reinterpret_cast x)


let x = "test"

let _ = Printf.printf "%d\n" (reinterpret_cast x)

результат

>./get_addr
69987975547676
69987974498292

то есть как и в C++ эти объекты физически расположены в разных участках памяти.
По сути в ML языках let в сишных терминах просто неявно вводит скопе.
Ну и учитывая что let выражения в этих языках как раз и есть замена сишных
скопе через {} все логично и не вызывает никаких неоднозначностей и неудобств.
Про удобство выше уже писали.

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

FR>то есть как и в C++ эти объекты физически расположены в разных участках памяти.

Это не главное.

FR>По сути в ML языках let в сишных терминах просто неявно вводит скопе.
FR>Ну и учитывая что let выражения в этих языках как раз и есть замена сишных
FR>скопе через {} все логично и не вызывает никаких неоднозначностей и неудобств.

Во-первых сишных или плюсовых? Это два очень разных языка.
Во-вторых, с точки зрения С++ пример вообще о другом. Вот поведение в стиле С++: пример

FR>Про удобство выше уже писали.

Но не привели не одного убедительного примера, только пару wtf

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

MTD>Во-первых сишных или плюсовых? Это два очень разных языка.

Большой разницы нет, вроде поведение в этом почти одинаковое, учитывая
конечно большую ограниченность си.

MTD>Во-вторых, с точки зрения С++ пример вообще о другом. Вот поведение в стиле С++: пример

Понятно что в С++ соблюдается вложенность, в ML этого нет, новое объявление полностью
отменяет старое.

FR>>Про удобство выше уже писали.

MTD>Но не привели не одного убедительного примера, только пару wtf

Для языков с си образным синтаксисом + эта фича (типа немерли или руста) я к сожалению
ничего привести не могу ни писал на подобных.
let же из OCaml или F# это все же не объявление переменной в смысле сиобразных
языков это просто привязка (у нее и полное название соответствующее let binding)
имени к выражению и соответственно и семантика и проблемы у него другие.

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

KP>Да не такое уж и плохое решение. Как минимум позволяет не вводить лишних имен без надобности. Типичный пример при работе с задачами, когда с одинм потоком будут работать несколько задач и Chan надо конвертировать в SharedChan.:

Фиг знает. В данном вопросе я солидарен с коллегой MTD — на мой взгляд эта фича скорее ведет к путанице, чем к ясности кода.

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

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

VD>Такой язык сразу идет в топку, в наше время. Надеюсь, что авторы передумают через некоторое время.

Приятно прочесть и принять к сведению мнение специалиста по языкам, сразу идущим в топку...
Спасибо, что предупредил, не буду даже и смотреть на этот ...раст!

А ничего так, быстро развивают язык. Сегодня вышел Rust 0.7. Революционных изменений я не заметил, просто идет хорошая такая эволюция.

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

FR>Во времена когда космические корабли даже компиляторы С++ легко
FR>откручивают хвост околофункциональный язык курит в сторонке .

У них lifetime анализ для borrowed указателей неслабо так увеличивает сложность реализации хвостовых вызовов, так что неудивительно.

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

L>У них lifetime анализ для borrowed указателей неслабо так увеличивает сложность реализации хвостовых вызовов, так что неудивительно.

Зачем там вообще какой-то анализ? Концевая рекурсия переписывается в цикл. Все параметры тупо становятся переменными.

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

VD>Зачем там вообще какой-то анализ? Концевая рекурсия переписывается в цикл. Все параметры тупо становятся переменными.

А как же указатели? Не все так просто, если функция получает или возвращает указатели, но тут еще нужно обеспечить, чтобы результат не менял время их жизни. В Си и С++ TCO реализуется далеко не тривиально а здесь должно быть еще сложноей.

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

VD>>Зачем там вообще какой-то анализ? Концевая рекурсия переписывается в цикл. Все параметры тупо становятся переменными.

L>А как же указатели?

Точно так же. Там без разницы какое значение. Просто была функция, стал цикл.

L>Не все так просто, если функция получает или возвращает указатели, но тут еще нужно обеспечить, чтобы результат не менял время их жизни. В Си и С++ TCO реализуется далеко не тривиально а здесь должно быть еще сложноей.

Сложности возникают только в случае когда рекурсия устраняется на не одной функции, а на множестве. На одной — это элементарное занятие.

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

L>>У них lifetime анализ для borrowed указателей неслабо так увеличивает сложность реализации хвостовых вызовов, так что неудивительно.
VD>Зачем там вообще какой-то анализ? Концевая рекурсия переписывается в цикл. Все параметры тупо становятся переменными.

Borrowed-check анализ обеспечивает compile-time memory safety указателей без использования GC, абстракций и любых прочих накладных расходов, в чем и заключается главная фишка и инновационность всего языка. Разумеется это важнее чем какой-то минорный фетиш из функционального программирования, поэтому если концевая рекурсия его усложняет — на нее тупо забили.

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

KP>>Вышла новая версия языка Rust с номером 0.3.
IT>Кто придумал такое название для языка?

Название дикое, но запоминающееся. Надо будет попробовать.

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

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

KP>>>Вышла новая версия языка Rust с номером 0.3.
IT>>Кто придумал такое название для языка?

MS>Название дикое, но запоминающееся. Надо будет попробовать.

Мне нравится -- Руст.

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

VD>Если тебе интересует пример того когда это удобно, то таких примеров масса. Например, нам нужно произвести ряд фильтраций некоторого списка. Чтобы не городить одну длинную строчку и меть возможность посмотреть в отладчике на промежуточные результаты я разбиваю одно выражение на несколько:
VD>

VD>def result = source.Filter(некоторое длинное условие фильтрации);
VD>def result = result.Filter(некоторое длинное условие фильтрации);
VD>def result = result.Filter(некоторое длинное условие фильтрации);
VD>def result = result.Filter(некоторое длинное условие фильтрации);
VD>result
VD>

VD>Это позволяет и код записать довольно красиво и в отладчике видеть промежуточные результаты.

Выглядит как использование изменяемой переменной. А в каких случаях удобно менять тип такой переменной? (Без изменения типа проще иметь возможность указать, что переменная изменяемая, а не делать такие переопределения).

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

MS>>Название дикое, но запоминающееся. Надо будет попробовать.
G>Мне нравится -- Руст.

Однажды, в эмоциональной беседе на работе я высказал такую метафору, что эта софта напоминает ржавые шестеренки (rusty gears), они еще как-то вертятся, но с такими диким скрежетом и в таком диком data binding скоро станут совсем неуправляемыми (язык C#). Но тот программист погиб и спросить уже не с кого. Даже и не знаю, что делать — переделывать или так и продолжать копаться. Переделать — очень большой объем работы, а копаться — тошно.

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

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

KP>А ничего так, быстро развивают язык. Сегодня вышел Rust 0.7. Революционных изменений я не заметил, просто идет хорошая такая эволюция.

Вот еще немного печальной правды о новой версии:
http://cmr.github.io/blog/2013/07/05/the-state-of-rust/

“basically, any question of the form ‘is there a reason for this stupid and terrible thing’ is ‘no, sorry, we’re working on it’ ”.
...
The compiler is still buggy and inefficient. Lots of things work, but lots of things don’t.
...
It would be silly to use Rust for something important

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

DM>Вот еще немного печальной правды о новой версии:

Мне кажется, ожидать большего от языка с версией 0.7 очень странно