Delphi vs C++ vs C# , ну и Java немножко, где-то ближе к старшему байту номеров страниц

Цитата kanes @ 01.10.10, 18:37

а причем тут мышкатыкание?

Вообще не причем, просто в холиварах Delphi vs C++, некоторые задачи сводились к мышкотыканью в делфях, а так вообще ничего, я просто условие поставил, если будет задача, то без мышкотыканья, в остальном я ничего против не имею... Я даже наверно в этомй теме скорее на стороне C# буду... в свое время я его учил, писал на нем и все такое, правда патом забыл, сейчас в планах освоить C# и Haskel... даже уже все есть

Ну из последнего, вот ради интереса, может потестим распараллеливание например при работе с коллекцией?
хотя это не фича языка, а скорее фича .NET

Цитата korvin @ 01.10.10, 18:57

лямбды без сборки мусора -- полулямбды.

угу. рекурсивные лямбы в дельфи по идее к мемлику приводят..

Цитата korvin @ 01.10.10, 18:57

а без вывода типов так ещё и неудобны =)

ну.. чем богаты..

Цитата kanes @ 01.10.10, 18:58

jack128, а как лямбды выглядят в Delphi? Можно пример кода, пожалуйста.

убого.

function CreateIncrementor(a: Integer): Func<Integer, Integer>;
begin
  Exit(function (i: integer) : Integer
  begin
    Exit(i + a);
  end);
end;

Цитата jack128 @ 01.10.10, 19:04

убого.

мда, и правда

Цитата korvin @ 01.10.10, 18:53

Цитата D_KEY @ 01.10.10, 18:42

Была бы сборка опциональной(и вообще отключаемой) - была бы преимуществом. А так...

Цитата

Последний вопрос, который следует упомянуть, прежде чем мы перейдем к формальному опре-
делению ссылок — освобождение памяти. Мы не вводим в язык никаких элементарных операций для
освобождения ненужных ссылочных ячеек. Вместо этого, как во многих современных языках (включая
ML и Java), мы полагаемся на то, что среда исполнения программ проводит сборку мусора, собирая и
освобождая ячейки, которые перестали быть доступными из программы. Это не просто вопрос вкуса
в проектировании языков: если в языке имеется явная операция освобождения памяти, то достижение
типовой безопасности становится крайне сложной задачей. Причина этому кроется в широко известной
проблеме висячих ссылок : мы выделяем память под ячейку, содержащую число, сохраняем ссылку на нее в некоторой структуре данных, какое-то время ей пользуемся, затем освобождаем ее и выделяем
новую ячейку, содержащую булевское значение. При этом, возможно, используется то же самое место
в памяти. Теперь у нас может оказаться два имени для одной и той же ячейки памяти — одна с типом
Ref Nat, а другая с типом Ref Bool.

(TAPL)

Все правильно. Только ты забыл выделить еще:

Цитата

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

Так вот, если ты используешь другие механизмы автоматического контроля за ресурсами, то этой проблемы ты избегаешь. Остается лишь проблема "ручной" заботы о времени жизни объекта. Опциональный сборщик эту проблему решает. И не будем забывать, что нет в программировании универсальных приемов. В тех же системах реального времени сборка мусора будет смотрется несколько странно.

Добавлено 01.10.10, 19:08

Цитата korvin @ 01.10.10, 18:57

лямбды без сборки мусора -- полулямбды.

Согласен.

Цитата

а без вывода типов так ещё и неудобны =)

Цитата D_KEY @ 01.10.10, 19:07

В тех же системах реального времени сборка мусора будет смотрется несколько странно.

Вот не могу вспомнить, что была за книга, но как раз там был пример про то, что не стоит писать код, например для аппарата искусственной вентиляции легких, на языке со сборкой мусора

Цитата kanes @ 01.10.10, 19:09

Цитата D_KEY @ 01.10.10, 19:07

В тех же системах реального времени сборка мусора будет смотрется несколько странно.

Вот не могу вспомнить, что была за книга, но как раз там был пример про то, что не стоит писать код, например для аппарата искусственной вентиляции легких, на языке со сборкой мусора

Тоже знакомый пример... Буч?

Цитата kanes @ 01.10.10, 19:09

В тех же системах реального времени сборка мусора будет смотрется несколько странно.

сам не смотрел, но говорят в erlang'e _очень_ быстрый сборщик. но там идут закладки на функциональность языка.

Цитата kanes @ 01.10.10, 19:09

Вот не могу вспомнить, что была за книга, но как раз там был пример про то, что не стоит писать код, например для аппарата искусственной вентиляции легких, на языке со сборкой мусора

Можно аргументы пожалуйста, я видно такую книгу не читал, хотя в этой теме вращаюсь...

Цитата D_KEY @ 01.10.10, 19:10

Тоже знакомый пример... Буч?

хм, да, вроде как Буч

Цитата jack128 @ 01.10.10, 19:13

Цитата kanes @ 01.10.10, 19:09

В тех же системах реального времени сборка мусора будет смотрется несколько странно.

сам не смотрел, но говорят в erlang'e _очень_ быстрый сборщик. но там идут закладки на функциональность языка.

Erlang вообще красавчик
Хотя о сборке мусора я не думал, когда его изучал. На практике так и не довелось как следует использовать.

Цитата KILLER @ 01.10.10, 19:14

Можно аргументы пожалуйста, я видно такую книгу не читал, хотя в этой теме вращаюсь...

если только сильно попозже.
ушел пить пиво

Цитата kanes @ 01.10.10, 19:15

если только сильно попозже.

только не сильно позже(в течении недели этой хотябы...)

Цитата KILLER @ 01.10.10, 19:14

Цитата kanes @ 01.10.10, 19:09

Вот не могу вспомнить, что была за книга, но как раз там был пример про то, что не стоит писать код, например для аппарата искусственной вентиляции легких, на языке со сборкой мусора

Можно аргументы пожалуйста, я видно такую книгу не читал, хотя в этой теме вращаюсь...

Ник у тебя, надеюсь, не отражает результаты твоей работы?

D_KEY, может ты объяснишь ?