Здравствуйте, vdimas, Вы писали:
V>А вообще, мейнстрим не зря все время ругают. Мейнстрим — это средний и мелкий бизнес.
В IT весь бизнес мелкий, даже в крупных компаниях. Небольшие команды, каждая со своими правилами и стандартами.
V>Это потребность получить максимум отдачи при минимум вложениях. "Минимум вложения" — это ключевое слово, это как таковое условие существования мелкого бизнеса, и оно все объясняет.
Нет такой потребности. У менеджера есть потребность выполнить задание. Если это задание — "минимум вложения", то это становится потребностью.
V>Менеджеры набирают минимально грамотный личный состав, достаточный для выполнения какого-либо проекта (уже акцентировал внимание на этом) ввиду экономии на ЗП. Давным-давно никто не пытается набрать самых лучших и сделать что-либо действительно хорошее.
Тебе просто не повезло, не обобщай и по скорее меняй работу.
V>Сегодня рулят решения по-месту, и блин, это при том, что классов задач до смешного мало. Такое распыление сил, такая непроизводительная потеря человекочасов программистким сообществом на изготовление сотен тысяч одинаковых по-сути софтин (и одинаково слабых, разумеется, при таком распылении усилий). В общем, такой подход, ИМХО, тормозит развитие выч.области как таковой.
Классов задач действительно не много. Но насчёт одинаковых софтин ты загнул. Софтины не могут быть одинкавыми, потому что они обслуживают разный бизнес. У каждого бизнеса свои требования. Там где требования сходятся появляются ширпотребовские решения. Остальное — индпошив.
V>Взять буквально еще 15-20 лет назад, программистов было на 2 порядка меньше, но они умудрялись двигать IT ничуть не медленнее чем сейчас (если не быстрее).
20 лет назад большая часть программистов в нерушимой занималась расчётом зарплаты на ЕС ЭВМ. Чуть меньшая часть протирала штаны в НИИ. Оставшаяся на той же ЭВМ рассчитывала траектории баллистических ракет. IT никто ни куда не двигал, по крайней мере в необъятной.
V>И окупаемость была гораздо выше.
Знаешь сколько стоил в те времена один компьютер. А сколько была зарплата программиста? Хочешь обратно?
V>Почти все очень грамотные IT-люди того времени сейчас весьма состоятельные люди.
Грамотные IT-люди того времени сидят и заполняют таможенные декларации, т.к в своё время им не хватило сил на переход с ЕС ЭВМ на писюки. Правда, другие, чуть менее грамотные, но более ушлые сейчас командуют первыми.
V>А сегодня грамотные IT-люди чуствуют себя лишними на этом празднике жизни. Ибо сегодня творцу не надо уметь готовить невообразимые уникальные блюда для честного и большого заработка. Напротив, необходимо демонстрировать умение быстрее всех чистить картошку.
Уменее быстро и качественно чистить картошку — неотъемлемый скил любого выдающегося шеф повора. Шеф повора, не умеющие чистить картошку очень быстро превращаются из поворов в зав. столовкой.
V>Если будут оставаться силы и время, то по ночам еще можно мастерить автомат для чистки картошки, но опять же, блин, не особо разгуляешься, ибо платят только за картошку, и чистить ее надо очень много, чтобы содержать себя и семью. Так и лежат у каждого в сарае недоделанные близкие сердцу картофелерезки. А через очередные 5 лет полностью меняется формат картошки, она теперь квадратная, требует еще меньше уникальных навыков даже для этого нехитрого действа по ее очистке. Но спроектированный автомат уже явно не стольо эффективен для квадратных картошек. Для них, квадратных, автомат можно построить на совсем других принципах. Засада, как всегда, приходит не с той стороны.
О как тебя колбасит сегодня!
V>Взять еще, например, дотнет. Кто мешал сделать раньше подобную компонентную модель? Что, блин, байт-код медлено выполнялся на том железе? А он вообще нужен был ранее?
Какая связь между компонентной моделью и байт-кодом? Я понимаю ещё, если бы был упомянут рефлекшин. А компонентную модель делали. Хотя бы в той же Дельфе. Не так универсально, но что-то было.
V>Почему-то есть твердая уверенность, что Nemerle никогда не станет мейнстримом, ибо он не отвечает требованию: "дешевый личный состав".
Если и не станет, то по другим причинам, а не по этой. "Дешевый личный состав" перешёл с C на C++. Потом с DOS на Windows и на COM, потом с Windows и с C++ на .NET, с COM+ и VB на C#. Переход на Немерле гораздо проще всего вышеперечисленного. Для C# программиста это часы.
... << RSDN@Home 1.2.0 alpha rev. 0>>
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, pavel74, Вы писали:
P>Ну вот тогда и пример метода ( в двойных апострофах коменты)
Зачем столько коментов? Код ведь тривиальнейший.
P>тоже, но без коментов P>checkCondition P> |a| P> a := self взятьОткудаТоМассив. P> a do: [ :each | (each isBitSet: 3 ) еслиДа: [^true] ]. P> ^false P>
P>Да обязательное условие, метод-итератор массива принимает блок кода.
Нет никаких блоков кода, в Nemerle есть функции, в C# делегаты. В данном случае "блок кода" выполняет как раз роль анонимной функции, поэтому в моем примере "метод-итератор" как раз будет принимать такую функцию. Так же нет никакого "метода-итератора", есть ряд функций высшего порядка, которые работают с массивами/коллекциями. В библиотеке Nemerle, и даже в .NET BCL, их несколько и каждая выполняет свою роль. В частности в Nemerle есть и аналог do:, метод Iter, но его применять здесь не имеет никакого смысла(да и это будет ближе к императивному стилю, функциональный в Nemerle предпочтительнее), лучше применить специализированный метод.
Если выяснять установлен ли бит в нужно часто, то можно сделать так:
module IsBitSetExt
// в Nemerle есть ограниченное неявное приведение целочисленных типов
// поэтому определяем только две перегрузки - для типов со знаком и безpublic IsBitSet(this val : ulong, n : int) : bool
val & (1u << n) != 0
public IsBitSet(this val : long, n : int) : bool
val & (1 << n) != 0
Тогда вышеприведенный фрагмент будет выглядеть так:
checkCondition() : bool
def a = this.взятьОткудаТоМассив
a.Exists(_.IsBitSet(3))
P>PS. Хотелось бы увидеть также аналог и на C#
C# 2.0:
Здравствуйте, VladD2, Вы писали:
VD>Здравствуйте, vdimas, Вы писали:
V>>У скриптового языка должна быть возможность легкой интеграции с высокооптимизированным бинарным кодом. Технология Лисп-машин это позволяет. Безглючное VBA (мощная альтернатива на том же поле) появилось только ближе к 5-й версии Internet Explorer.
VD>Ради спроведливости... VBA это Офис... Ворд, Эксель... но никак не Internet Explorer.
Здравствуйте, Геннадий Васильев, Вы писали:
VD>>Задумывался. Когда ты к нему прибегал.
ГВ>Ну так почему же этот приём считается некорректным? ГВ>[/q]
Знаешь, Геннадий, а просто потому, что он здесь — главный. Я ни в коем случае не признаю его правоту, но понимаешь ли в чем дело — кто создал эху, тот и хозяин в ней. Так исторически сложилось и поддеживается на RSDN. И это правильно, как бы ты к этому ни относился. И ты должен это учитывать, несмотря на всякие "преведы" уважаемого Влада (извини, Влад, но слово "отвичаю" я приравниваю к слову "превед" в твоей лексике — пожалуйста, избегай впредь падонковщины, иначе я буду причислять тебя к неуважаемым мною падонкам). Такие дела.
McSeem
Я жертва цепи несчастных случайностей. Как и все мы.
Здравствуйте, VladD2, Вы писали:
VD>Здравствуйте, vdimas, Вы писали:
V>>У скриптового языка должна быть возможность легкой интеграции с высокооптимизированным бинарным кодом. Технология Лисп-машин это позволяет. Безглючное VBA (мощная альтернатива на том же поле) появилось только ближе к 5-й версии Internet Explorer.
VD>Ради спроведливости... VBA это Офис... Ворд, Эксель... но никак не Internet Explorer.
Ради справедливости, они это все называют как-то вроде MS Visual Basic Scripting Technologies, там и VBScript и VBA и все остальное. IE для прогона скриптов хостит VBA, выставляет VBA-машинке объект верхнего уровня (HTML DOM) и запускает в его контексте VB-выражения. Просто сам термин VBA выделился где-то начиная с 7-го офиса, когда они снабдили эту хрень GUI интерфейсом для редактирования макросов (VBE), отделили от офиса и стали продавать как отдельный продукт.
IT>Знаешь сколько стоил в те времена один компьютер. А сколько была зарплата программиста? Хочешь обратно?
Я имел ввиду не нашу уродскую систему, а "их", разумеется. И под отдачей имел ввиду сумарную долговременную отдачу от вложенных усилий.
V>>А сегодня грамотные IT-люди чуствуют себя лишними на этом празднике жизни. Ибо сегодня творцу не надо уметь готовить невообразимые уникальные блюда для честного и большого заработка. Напротив, необходимо демонстрировать умение быстрее всех чистить картошку.
IT>Уменее быстро и качественно чистить картошку — неотъемлемый скил любого выдающегося шеф повора. Шеф повора, не умеющие чистить картошку очень быстро превращаются из поворов в зав. столовкой.
Да. Однако, практикант, который непрерывно чистит картошку уже месяц, будет делать это быстрее меня.
IT>О как тебя колбасит сегодня!
Угу, надо было прочесть перед отправкой, снес быв мусор, ибо во-первых толку... а во-вторых — сто раз об одном и том же...
V>>Взять еще, например, дотнет. Кто мешал сделать раньше подобную компонентную модель? Что, блин, байт-код медлено выполнялся на том железе? А он вообще нужен был ранее?
IT>Какая связь между компонентной моделью и байт-кодом?
И я про то, непонятно до сих пор. Сдается мне, они придумают, как все это заставить работать без байт-кода к какой-нить 5-й версии.
Ибо, блин, даже мощнейший механизм маппинга сегментов кода DLL нифига не работает в дотнете. Ну или еще альтернатива — "плоская" общая память и прочие "поясы надежности" из Сингулярити... Тоже весьма спорно, из-за того, что надо будет всю IT-промышленность с 0-ля переписать. Да и учебники по системному ПО тоже.
IT>Я понимаю ещё, если бы был упомянут рефлекшин.
Считай, упомянут, т.к. полноценная компонентная модель без метаинформации невозможна. Кстати, если бы не надо было из байт-кода динамически делать нативный, то можно было бы нехило сэкономить на упрощении приватной для сборки метаинформации (оставить минимум инфы для GC)
D движется в этом направлении. Но без вливания миллиардов денег — как-то весьма небыстро. Будет как со Схемой. Вменяемый стандарт появится значительно позже морального устаревания.
IT>А компонентную модель делали. Хотя бы в той же Дельфе. Не так универсально, но что-то было.
Мало мета-инфы, и отвратительное качество исполнения. Ведь развивались параллельно с Java, однако наработали фактического материала на порядки меньше (речь о фреймворках и стандартах). Да и язык был взят, не то чтобы очень.
V>>Почему-то есть твердая уверенность, что Nemerle никогда не станет мейнстримом, ибо он не отвечает требованию: "дешевый личный состав".
IT>Если и не станет, то по другим причинам, а не по этой. "Дешевый личный состав" перешёл с C на C++. Потом с DOS на Windows и на COM, потом с Windows и с C++ на .NET, с COM+ и VB на C#. Переход на Немерле гораздо проще всего вышеперечисленного. Для C# программиста это часы.
Там подводные камни весьма глубокие. Не представляя дсконально, как он работает, можно одним легким движением (подключением не той либы) сломать программу. И для поиска причины потребуется определенного уровня профи. Возвратилисть к начальным условиям.
Java и VB получили популярность когда-то из-за простого и детерминированного синтаксиса и семантики. Разве на VB проще писать чем на C++? Да какой там, в разы сложнее! (пришлось очень много колбасить на VB) Элементарные вещи делать запаришься (разве что IDispatch::Invoke часто рулил). Однако, выучить С++ оказывается мало, надо еще научиться писать на нем так, чтобы программа не валилась на каждой второй строчке. А это уже навыки как бы несколько иного характера. Это плата за гибкость, удобство и еще тысячи возможностей. Вот так и с Немерле в сравнении с C#: в C# можно поставить подпись и печать под каждой строкой кода, ибо эта строка правдива и очевидна. А в Немерле 80% кода будет оптическим обманом, типа как в современной С++ программе. Так что, не в изучении базового синтаксиса будет камень преткновения, разумеется. Тут снова напрашивается пример про С++: в нем синтаксических оборотов даже меньше, чем в C#, однако их всевозможные контекстно-зависимые комбинации порождают чудовищную размерность семантики.
P>>Ну вот тогда и пример метода ( в двойных апострофах коменты) VK>Зачем столько коментов? Код ведь тривиальнейший.
Ну некотрые считают что ST, это нечитабельные "шифрограммы".
P>>Да обязательное условие, метод-итератор массива принимает блок кода.
"Блок кода", лямбда, анонимная функция, делегаты — это по сути одно и тоже. способ передать функцию и вызвать ее из другого места. Хорошо буду называть это лямбдой. Ну да не будем спорить о терминологии — суть то понятна.
ок, чуть уточняем и изменяем пример.
a. в массиве числа, но могут быть целые, даблы и большие целые (неограниченного размера, в ST тип LargeInteger).
b. массив данных по прежнему может быть разных типов, главное есть итератор do: , принимающий лямбду.
c. условие проверки такое: все хорошо если в массиве есть 2 смежных элемента , из которых второй равен первый*2. Обращаю внимание что типы чисел в массиве данных разные.
check
|a prevItem|
a:= self getDataArray.
a do: [ :each|
(prevItem<>nil) ifTrue: [
(prevItem*2=each) ifTrue: [^true]. "условие выполнилось прерываем обход и выходим из функции"
].
prevItem:=each.
].
^false
А как сейчас будет на Nemerle, C# 2.0 C# 3.0 Все предыдущие примеры полностью неподходят под немного изменившиеся условия, и позвольте обратить внимание что при изменении требований мне пришлось чуть-чуть поправить код (фактически только логическую часть) передаваемый методу обхода массива.
Здравствуйте, pavel74, Вы писали:
VK>>Зачем столько коментов? Код ведь тривиальнейший. P>Ну некотрые считают что ST, это нечитабельные "шифрограммы".
Ну значит для них примерно так оно и есть, а может я просто привык читать "шифрограммы".
P>>>Да обязательное условие, метод-итератор массива принимает блок кода. P>"Блок кода", лямбда, анонимная функция, делегаты — это по сути одно и тоже. способ передать функцию и вызвать ее из другого места. Хорошо буду называть это лямбдой. Ну да не будем спорить о терминологии — суть то понятна.
Суть в том, что блоки кода в ST и значения функциональных типов в Nemerle это совершенно разные вещи. А то, что и те, и другие можно использовать для передачи некой функции и вызова из другого места это всего лишь досадное недоразумение.
Блок кода это строительный блок языка, и именно для этого он существует в ST. Но дело в том, что в Nemerle строительным блоком является любое выражение. Просто в отличие от ST этими строительными блоками оперируют макросы во время компиляции, а не методы во время исполнения. И блоки кода в число этих строительных блоков тоже входят, но семантика их совершенно иная.
Простой рабочий пример:
def x = { true };
Здесь не будет создано никакой лямбды, значение x просто проинициализируется в true и его тип будет выведен как bool. Но этот же блок кода может быть аргументом макроса(впрочем как и любое другое выражение), такого как например if, while, for, foreach, который в свою очередь может использовать его в генерации кода как посчитает нужным.
P>a. в массиве числа, но могут быть целые, даблы и большие целые (неограниченного размера, в ST тип LargeInteger). P>b. массив данных по прежнему может быть разных типов, главное есть итератор do: , принимающий лямбду. P>c. условие проверки такое: все хорошо если в массиве есть 2 смежных элемента , из которых второй равен первый*2.
Нда, очень странные условия. С трудом могу представить себе ситуацию, когда задача может стоять именно таким образом. Тут явно что-то не так с дизайном.
P>А как сейчас будет на Nemerle, C# 2.0 C# 3.0
Вообще-то по хорошему никак не должно быть, так как постановка задачи какая-то очень странная(тут надо срочно что-то делать с архитектурой самого приложения, а не решать эту задачу). Но я в последний раз поддамся на провокацию и напишу пример. Хочешь с минимальными изменениями, будет тебе с минимальными изменениями. Только никакого LargeInteger не будет, потому что в .NET он не предусмотрен(да и полезен он бывает только в очень незначительном количестве задач).
Писать примеры для C# 2/3 мне лень, будет примерно тоже самое, просто не так кратко.
P>Все предыдущие примеры полностью неподходят под немного изменившиеся условия, и позвольте обратить внимание что при изменении требований мне пришлось чуть-чуть поправить код (фактически только логическую часть) передаваемый методу обхода массива.
Как видно из примера выше прекрасно подходят. Пример на Nemerle короче и достаточно читабелен. Кстати обрати внимание, что в этих и предыдущем примерах на Nemerle нет ни одного return(в отличие от твоих примеров на ST, которые просто кишат "крышечками").
А если бы Nemerle был динамическим языком, то вообще можно было бы записать в одну коротенькую строчку:
Но это не так, и слава богу. И кстати если не гнаться за краткостью и твоим "немного подправить", то на Nemerle гораздо идеологически правильней написать этот пример так(но понятное дело для человека, который ничего не знает о паттерн-мэтчинге этот пример будет темным лесом):
check() : bool
def chk(_l)
| x :: y :: _ when ToDouble(y) == ToDouble(x) * 2.0 => true
| _ :: rest => chk(rest)
| [] => false
chk(DataArray.ToList())
А еще лучше, чтобы типы чисел были одинаковыми, и данные передавались функции check в качестве параметра:
check(data : list[double]) : bool
| x :: y :: _ when x == y * 2.0 => true
| _ :: rest => check(rest)
| [] => false
А в таком случае вообще лучше написать обобщенную функцию, которая бы проверяла есть ли в списке два, три, n последовательных значений, которые объединяет некое условие:
module ExistsSeqExt
// для двух значенийpublic ExistsSeq[T](this a : list[T], f : T*T->bool) : bool
match(a)
| x :: y :: _ when f(x,y) => true
| _ :: rest => ExistsSeq(rest, f)
| _ => false// для трех значенийpublic ExistsSeq[T](this a : list[T], f : T*T*T->bool) : bool
match(a)
| x :: y :: z :: _ when f(x,y,z) => true
| _ :: rest => ExistsSeq(rest, f)
| _ => false
А вот и пример использования этих функций:
[1.0,2.0,3.0].ExistsSeq((x,y) => y == x * 2.0) // true
[1,2,3].ExistsSeq((x,y) => x == y) // false
[2,6,5,4,1].ExistsSeq((x,y,z) => z == y-1 && y == x-1) // true
Здравствуйте, VladD2, Вы писали:
FDS>>Не видел ещё не одного вопроса по C#, на который нельзя было бы ответить после внимательного чтения спецификации (на это, правда, не все способны). Форумные вопросы в принципе должны возникать только от нестандартной реализации и багов (по крайней мере, что касается C#).
VD>Значит плохо смотрел. Я сам иногда нахожу интересные ответы хотя казалось бы многие спецификации дотнета знаю чуть ли на изусть.
По C# есть? Можно ссылку? Интересно посмотреть... (если не трудно, конечно)
Да, я не часто туда захожу.
По поводу ответов и вопросов — они действительно интересные, не спорю, но, скажем, конкретно по C# у меня ещё не возникало ни одного вопроса, на который бы мне нужно было обращаться в форум: это огромный плюс для этого языка в моих глазах (и в форуме не видел такого, что бы вообще нельзя было понять самостоятельно). А по Nemerle у меня уже десяток вопросов (на которые я сам не знаю ответа), которые возникли просто после написания простейших функций. [я бы сказал, что на уровне простейших функций Scheme гораздо легче для изучения, чем Nemerle ]
VD>У меня большое ощущение, что ты читал статью или по диагонали, или просто не вдумывался. VD>Попробуй еще раз прочесть раздел: Локальные функции
Хм, может я и не вчитывался (кое-где честно говоря действительно по диагонали), но этот раздел я раза три или четыре прочитал (включая файлы на самом сайте), и вот ну не вижу отличий: чем в Delphi функции — не замыкания! (см. пример ниже)
VD>У функций Немерла два основных отличий. VD>1. Их функции являются полноценными лексическими замыканиями. Так что ты можешь использовать напрямую все переменные и функции объявленные выше данной. Например: VD>
VD>usung System.Console;
VD>mutable x = 5;
VD>def add(a, b) { a + b }
VD>def addX(c) { add(c, x); }
VD>WriteLine(addX(2));
VD>
Но чем Delphi в данном случае уступает [кроме отсутствия type inference]?
program Sample;
{$APPTYPE CONSOLE}procedure Main;
var
x : integer;
tmpString : ANSIString;
function add(const a, b: integer): integer;
begin
Result := a + b;
end;
function addX(const c : integer): integer;
begin
Result := add(c, x);
end;
const Cx = 5;
begin
x := Cx;
WriteLn(addX(2));
ReadLn(tmpString);
end;
begin
Main;
end.
Выводит в консоль число "7", так же как и ваш пример.
Этот код фактически аналогичен приведённому выше, кроме того, что внутренняя функция может быть использована в Delphi только в области её объявления (в пределах main, включая вложения).
VD>2. Функции в Немерле являются значениями. Над ними можно совершать преобразования. В общем-то пример выше как раз это показал, но не очень явно. А вот как можно: VD>
VD>usung System.Console;
VD>mutable x = 5;
VD>def add(a, b) { a + b }
VD>def addX = add(x, _);
// Я думаю, надо def addX = add(_, x); ?
VD>WriteLine(addX(2));
VD>
Да, с этим согласен — это круто, не считая замечания, так как несвязанный параметр, как мне кажется, тут первый, а не второй, как вы написали. Но это, собственно, уже не к локальным функциям относится, а к созданию новых функций из старых.
FDS>> Опять же, в каком документе это описано? Этот язык, наверное, в несколько раз круче, чем я о нём думаю, и всё только потому, что документация чёрт знает как оформлена. Эх, ну почему они не из Microsoft?! VD>Статья сделана по их сайту. Там конечно есть не все, но очень многое. Да и в статье есть многое и в одном месте.
Конечно, как мне вчитываться, когда я на первом же своём тесте получил ошибку, которую не могу исправить, потому что не понимаю.
(пожалуй первый раз в жизни у меня т а к и е проблемы с синктасисом )
Компилируется:
...
class C
{
public static Method(i : ref int) : int
{
i = i + 1;
i
}
}
mutable x = 5;
WriteLine(C.Method(ref x));
_ = ReadLine();
Некомпилируется:
...
class C
{
public static Method(i : ref int) : int
{
i = i + 1;
i
}
}
def MM(i : ref int) : int
{
i = i + 1;
i
}
mutable x = 5;
WriteLine(C.Method(ref x));
WriteLine(MM(ref x));
_ = ReadLine();
Ошибки:
nested ref/out type found E:\Prg\temp\070906\ConsoleApplication3\Main.n 22 1 ConsoleApplication3
needed a writable location for assignment target, got a reference to local symbol `a function parameter i', which is read-only E:\Prg\temp\070906\ConsoleApplication3\Main.n 24 1 ConsoleApplication3
in argument #1 of +.s, needed a int, got void: void is not a subtype of int E:\Prg\temp\070906\ConsoleApplication3\Main.n 24 5 ConsoleApplication3
expected int, got void in function return type: void is not a subtype of int E:\Prg\temp\070906\ConsoleApplication3\Main.n 22 1 ConsoleApplication3
wrong number of parameters in call, needed 0, got 1 E:\Prg\temp\070906\ConsoleApplication3\Main.n 31 11 ConsoleApplication3
Просто скопировал метод и он перестал компилироваться
Что я должен думать о вменяемости компилятора? Естественно у меня чисто познавательные вопросы: потому что язык мне всё-таки интересен для практических целей. Если я использую язык, я должен быть уверен, что по крайней мере элементарные операции я на нём умею делать.
Может я плохо искал, но что-то не в вашей статье, ни на сайте не нашёл объяснения данному явлению (впрочем, я очень быстро путаюсь в разрозненных фактах). А ведь сделал совершенно элементарную вещь
FDS>>С вашей интеграцией не так, что нужна последняя версия VSIP SDK. Насколько я понимаю, по Dial-Up её не скачать. VD>Скоро все будет ОК. У нас уже есть так называемый PLK который позволит сделать инсталлятор. Но надо кое что доделать.
Вот это было бы круто
P.S. Можно самый важный вопрос: вы знаете о Nemerle довольно много: это вы исходники разбирали или всё из примеров вывели?
Вообще, там есть в исходниках какой-нибудь отдельный файл описания синтаксиса (вкл. макросы)?
Здравствуйте, pavel74, Вы писали:
P>ок, чуть уточняем и изменяем пример. P>a. в массиве числа, но могут быть целые, даблы и большие целые (неограниченного размера, в ST тип LargeInteger). P>b. массив данных по прежнему может быть разных типов, главное есть итератор do: , принимающий лямбду. P>c. условие проверки такое: все хорошо если в массиве есть 2 смежных элемента , из которых второй равен первый*2. Обращаю внимание что типы чисел в массиве данных разные.
P>
P>А как сейчас будет на Nemerle, C# 2.0 C# 3.0 Все предыдущие примеры полностью неподходят под немного изменившиеся условия, и позвольте обратить внимание что при изменении требований мне пришлось чуть-чуть поправить код (фактически только логическую часть) передаваемый методу обхода массива.
Дополнение: Vermicious Knid преобразовывал их к double, я опишу, как это сделать строго.
P>a. в массиве числа, но могут быть целые, даблы и большие целые (неограниченного размера, в ST тип LargeInteger).
В принципе, в массиве можно положить абсолютно любые объекты, если положить условие, что они возвращают интерфейс, в котором определена операция умножения. Это усложнение, конечно, но не на много
P>b. массив данных по прежнему может быть разных типов, главное есть итератор do: , принимающий лямбду.
Ерунда, это без разницы, если все типы поддерживают один и тот же интерфейс. Это сделать не сложно. Другое дело, что придётся писать небольшой класс-обёртку (один) для стандартных типов, что бы они то же поддерживали этот интерфейс.
P>c. условие проверки такое: все хорошо если в массиве есть 2 смежных элемента , из которых второй равен первый*2. Обращаю внимание что типы чисел в массиве данных разные.
Без проблем, если есть интерфейсы. Просто без проблем...
Здравствуйте, vdimas, Вы писали:
V>Здравствуйте, FDSC, Вы писали:
К>>>Ты не с той стороны смотришь, тебе как пользователю автокада глубоко пофигу на чём там что написано — лишь бы работало, а вот если бы ты был автором — было бы совсем иначе
FDS>>Это вы не поняли: ведь AutoCAD не на лисп написан. Это скрипты для AutoCAD пишутся на ЛИСП и мне, как пользователю это не всё равно, потому что скриптовый язык я должен знать.
V>У скриптового языка должна быть возможность легкой интеграции с высокооптимизированным бинарным кодом. Технология Лисп-машин это позволяет. Безглючное VBA (мощная альтернатива на том же поле) появилось только ближе к 5-й версии Internet Explorer.
Ну и? А для программистов, которые пишут на Лиспе разве важно, как было писать этот ЛИСП другим программистам. Нет, им важно удобство. Покажите мне удобство для программистов, которые используют язык, а не пишут для него компилятор. Я могу за день написать простой компилятор языка assembler для Intel 8080, например, или Siemens не помню каких, но пользоваться то этим компилятором не мне. Понимаете о чём речь? Вы мне доказыватете, что для ЛИСПа удобно писать компилятор, а нужно доказывать что НА ЛИСПе удобно писать.
Re[25]: Не нужность super return (нелок. возврата) [рассм. п
FDS>>и уже ошибка
P>ну дак обложить обработкой ошибок, тем более если передан внешний блок кода, то существует вероятность что там может возникнуть эксепшн. А нелокальный возврат это фактически "особый" эксепшен.
Причём этот super return должен вызываться в том же контексте, что и в переданном блоке.
Да посмотрите же, что это?! Да ведь наш super return превратился в обыкновенный return, возвращающий управление ВЫЗЫВАЮЩЕЙ функции! Ну и зачем он тогда нужен? Не проще и быстрее его реализовать как return?
public static ResultAction ForEach<T>(T root, Action<T> action)
where T: IRecursible<T>
{
ResultAction RA = action(root);
if (RA.isExecuted)
return RA;
CRT Child = root.LoadFromDataBaseChildAndLock();
foreach(T Child in root)
{
RA = ForEach(Child, action);
if (RA.isExecuted)
break;
}
Child.Unlock();
return RA;
}
И что, это намного хуже и сложнее? И наверняка быстрее работает, чем перехват повторно вызывающихся нелокальных возвратов.
Здравствуйте, vdimas, Вы писали:
V>А в Немерле 80% кода будет оптическим обманом, типа как в современной С++ программе.
Откуда такая уверенность? Опять макросы? Зря переживаешь. Я вот за месяц интенсивной и плодотворной работы с N не написал ещё ни одного. Но зато вижу, что те задачи которые я решаю на C# решались бы на порядок сложнее и соответственно привели бы к более сложному, непонятному и запутанному коду.
... << RSDN@Home 1.2.0 alpha rev. 0>>
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, vdimas, Вы писали:
V>Ибо, блин, даже мощнейший механизм маппинга сегментов кода DLL нифига не работает в дотнете. Ну или еще альтернатива — "плоская" общая память и прочие "поясы надежности" из Сингулярити... Тоже весьма спорно, из-за того, что надо будет всю IT-промышленность с 0-ля переписать. Да и учебники по системному ПО тоже.
Прямо так? Вы что-то не понимаете. Не могут они так делать... давно бы уже с другими процами ходили и тому подобноее. В таком случае у Сингулярити только один путь — ждать, пока старые компьтеры не заработают
IT>>А компонентную модель делали. Хотя бы в той же Дельфе. Не так универсально, но что-то было.
V>Мало мета-инфы, и отвратительное качество исполнения. Ведь развивались параллельно с Java, однако наработали фактического материала на порядки меньше (речь о фреймворках и стандартах). Да и язык был взят, не то чтобы очень.
Кто тут на Delphi наезжает? А??? Что значит "не то что бы очень", да я тебя:
Ты посмотри, половина фич в C# уже давно были в Дельфи, причём некоторых не было в Яве :o)
V>>>Почему-то есть твердая уверенность, что Nemerle никогда не станет мейнстримом, ибо он не отвечает требованию: "дешевый личный состав".
IT>>Если и не станет, то по другим причинам, а не по этой. "Дешевый личный состав" перешёл с C на C++. Потом с DOS на Windows и на COM, потом с Windows и с C++ на .NET, с COM+ и VB на C#. Переход на Немерле гораздо проще всего вышеперечисленного. Для C# программиста это часы.
V>Там подводные камни весьма глубокие. Не представляя дсконально, как он работает, можно одним легким движением (подключением не той либы) сломать программу. И для поиска причины потребуется определенного уровня профи. Возвратилисть к начальным условиям.
Вот это правильно.
V>Java и VB получили популярность когда-то из-за простого и детерминированного синтаксиса и семантики. Разве на VB проще писать чем на C++? Да какой там, в разы сложнее! (пришлось очень много колбасить на VB) Элементарные вещи делать запаришься (разве что IDispatch::Invoke часто рулил). Однако, выучить С++ оказывается мало, надо еще научиться писать на нем так, чтобы программа не валилась на каждой второй строчке. А это уже навыки как бы несколько иного характера. Это плата за гибкость, удобство и еще тысячи возможностей. Вот так и с Немерле в сравнении с C#: в C# можно поставить подпись и печать под каждой строкой кода, ибо эта строка правдива и очевидна. А в Немерле 80% кода будет оптическим обманом, типа как в современной С++ программе. Так что, не в изучении базового синтаксиса будет камень преткновения, разумеется. Тут снова напрашивается пример про С++: в нем синтаксических оборотов даже меньше, чем в C#, однако их всевозможные контекстно-зависимые комбинации порождают чудовищную размерность семантики.
Покажите синтаксические конструкции Nemerle, под которыми нельзя поставить "подпись и печать". Очень интересно. Я вот как раз сейчас думаю, не попробовать ли помучиться и перейти на него.
Здравствуйте, IT, Вы писали:
IT>Здравствуйте, vdimas, Вы писали:
V>>А вообще, мейнстрим не зря все время ругают. Мейнстрим — это средний и мелкий бизнес.
IT>В IT весь бизнес мелкий, даже в крупных компаниях. Небольшие команды, каждая со своими правилами и стандартами.
Но крупные компании могут в любом случае позволить себе инвестировать в IT гораздо больше, чем мелкий бизнес.
V>>Это потребность получить максимум отдачи при минимум вложениях. "Минимум вложения" — это ключевое слово, это как таковое условие существования мелкого бизнеса, и оно все объясняет.
IT>Нет такой потребности. У менеджера есть потребность выполнить задание. Если это задание — "минимум вложения", то это становится потребностью.
У мелкого бизнеса есть такая потребность, так как он испытывает недостаток в финансировании. Могу даже сказать больше: когда нам читали лекции по экономике, лектор жаловался, что его "стартапу" (человек 15 программистов ) не хватает финансирования уже второй год, несмотря на то, что они получают гранты от государтсва (инвесторы ставят абсолютно неприемлимые условия).
V>>Менеджеры набирают минимально грамотный личный состав, достаточный для выполнения какого-либо проекта (уже акцентировал внимание на этом) ввиду экономии на ЗП. Давным-давно никто не пытается набрать самых лучших и сделать что-либо действительно хорошее.
IT>Тебе просто не повезло, не обобщай и по скорее меняй работу.
Таких "неповезло" у нас в стране не так мало, лично я знаю как минимум 3 фирмы лично (при том, что не видел фирмы, где точно берут и классных специалистов и выпускников).
V>>Сегодня рулят решения по-месту, и блин, это при том, что классов задач до смешного мало. Такое распыление сил, такая непроизводительная потеря человекочасов программистким сообществом на изготовление сотен тысяч одинаковых по-сути софтин (и одинаково слабых, разумеется, при таком распылении усилий). В общем, такой подход, ИМХО, тормозит развитие выч.области как таковой.
IT>Классов задач действительно не много. Но насчёт одинаковых софтин ты загнул. Софтины не могут быть одинкавыми, потому что они обслуживают разный бизнес. У каждого бизнеса свои требования. Там где требования сходятся появляются ширпотребовские решения. Остальное — индпошив.
Ну, этот инд. пошив всё-таки друг на друга часто похож. Хотя не настолько, что бы он встречался в сотнях фирм.
V>>Взять буквально еще 15-20 лет назад, программистов было на 2 порядка меньше, но они умудрялись двигать IT ничуть не медленнее чем сейчас (если не быстрее).
IT>20 лет назад большая часть программистов в нерушимой занималась расчётом зарплаты на ЕС ЭВМ. Чуть меньшая часть протирала штаны в НИИ. Оставшаяся на той же ЭВМ рассчитывала траектории баллистических ракет. IT никто ни куда не двигал, по крайней мере в необъятной.
Точнее двигали пару лабораторий в одном НИИ . Вы, кстати, забыли, что сложные задачи вычислительной физики до сих пор часто решаются в индивидуальном порядке — это то же тема, смежная с IT.
V>>И окупаемость была гораздо выше.
IT>Знаешь сколько стоил в те времена один компьютер. А сколько была зарплата программиста? Хочешь обратно?
+
V>>Почти все очень грамотные IT-люди того времени сейчас весьма состоятельные люди.
IT>Грамотные IT-люди того времени сидят и заполняют таможенные декларации, т.к в своё время им не хватило сил на переход с ЕС ЭВМ на писюки. Правда, другие, чуть менее грамотные, но более ушлые сейчас командуют первыми.
Имеются ввиду, видимо, западные специалисты. Хотя, лично моё мнение: есть куча очень талантливых людей, которые сейчас не обладают существенными материальными средствами. Так что, согласен.
V>>А сегодня грамотные IT-люди чуствуют себя лишними на этом празднике жизни. Ибо сегодня творцу не надо уметь готовить невообразимые уникальные блюда для честного и большого заработка. Напротив, необходимо демонстрировать умение быстрее всех чистить картошку.
IT>Уменее быстро и качественно чистить картошку — неотъемлемый скил любого выдающегося шеф повора. Шеф повора, не умеющие чистить картошку очень быстро превращаются из поворов в зав. столовкой.
А вы видели как зав. столовой чистят сардельки
Но шеф повар всё-таки обычно картошку не чистит. Да?
V>>Почему-то есть твердая уверенность, что Nemerle никогда не станет мейнстримом, ибо он не отвечает требованию: "дешевый личный состав".
IT>Если и не станет, то по другим причинам, а не по этой. "Дешевый личный состав" перешёл с C на C++. Потом с DOS на Windows и на COM, потом с Windows и с C++ на .NET, с COM+ и VB на C#. Переход на Немерле гораздо проще всего вышеперечисленного. Для C# программиста это часы.
Почему же я до сих пор так и не смог написать даже простую работающую программу на Nemerle. Я уже даже на Scheme стал писать (в процессе спора на форуме), а вот на Nemerle — ну никак, ну не получается!
V>>Если будут оставаться силы и время, то по ночам еще можно мастерить автомат для чистки картошки, но опять же, блин, не особо разгуляешься, ибо платят только за картошку, и чистить ее надо очень много, чтобы содержать себя и семью. Так и лежат у каждого в сарае недоделанные близкие сердцу картофелерезки. А через очередные 5 лет полностью меняется формат картошки, она теперь квадратная, требует еще меньше уникальных навыков даже для этого нехитрого действа по ее очистке. Но спроектированный автомат уже явно не стольо эффективен для квадратных картошек. Для них, квадратных, автомат можно построить на совсем других принципах. Засада, как всегда, приходит не с той стороны.
IT>О как тебя колбасит сегодня!
А сегодня грамотные IT-люди чуствуют себя лишними на этом празднике жизни. Ибо сегодня творцу не надо уметь готовить невообразимые уникальные блюда для честного и большого заработка. Напротив, необходимо демонстрировать умение быстрее всех чистить картошку. Если будут оставаться силы и время, то по ночам еще можно мастерить автомат для чистки картошки, но опять же, блин, не особо разгуляешься, ибо платят только за картошку, и чистить ее надо очень много, чтобы содержать себя и семью. Так и лежат у каждого в сарае недоделанные близкие сердцу картофелерезки. А через очередные 5 лет полностью меняется формат картошки, она теперь квадратная, требует еще меньше уникальных навыков даже для этого нехитрого действа по ее очистке. Но спроектированный автомат уже явно не стольо эффективен для квадратных картошек. Для них, квадратных, автомат можно построить на совсем других принципах. Засада, как всегда, приходит не с той стороны.
V>-------
Почему-то есть твердая уверенность, что Nemerle никогда не станет мейнстримом, ибо он не отвечает требованию: "дешевый личный состав". В лучшем случае станет мощным инструментом для профессионалов и то, не ранее, чем обрастет вменяемым и неглючным окружением для разработки (не камень ни в чей огород, просто озвучка "мнения зала").
А С++ что, отвечает требованию дешёвый личный состав? Я знаю только самые основы C++, но могу завалить по нему многих студентов профильных специальностей своего машиностроительного [ ] ВУЗа. Есть люди, которые по сравнению со мной хорошо знают C++, но есть люди, которые могут завалить их на стандартных библиотеках. Ну и где же тут дешёвый личный состав? В Nemerle не нужно знать, что такое указатель. И, кстати, скажем макросы фактически являются прозрачной функциональностью Nemerle, следовательно, на нём можно программировать и без их знания. Я уже не говорю, что с помощью макросов Nemerle можно классно механизировать для чистки картошки, надо только нормальные книжки по нему написать ещё. И документацию для тех, кто с неё свои книжки будет списывать. Так что Nemerle вполне может впасть в (нет, не маразм) MainStream.
Здравствуйте, FDSC, Вы писали:
IT>>В IT весь бизнес мелкий, даже в крупных компаниях. Небольшие команды, каждая со своими правилами и стандартами. FDS>Но крупные компании могут в любом случае позволить себе инвестировать в IT гораздо больше, чем мелкий бизнес.
Это правда. Именно поэтому в больших компаниях полно зомби проектов, которые уже умерли, но ещё ходят и пугают окружающих.
FDS>У мелкого бизнеса есть такая потребность, так как он испытывает недостаток в финансировании. Могу даже сказать больше: когда нам читали лекции по экономике, лектор жаловался, что его "стартапу" (человек 15 программистов ) не хватает финансирования уже второй год, несмотря на то, что они получают гранты от государтсва (инвесторы ставят абсолютно неприемлимые условия).
Может главная цель бизнеса твоего лектора как раз получение грантов, а не получение прибыли?
IT>>Тебе просто не повезло, не обобщай и по скорее меняй работу. FDS>Таких "неповезло" у нас в стране не так мало, лично я знаю как минимум 3 фирмы лично (при том, что не видел фирмы, где точно берут и классных специалистов и выпускников).
Ну так и в чём проблема? Не нравится — уходи.
IT>>Классов задач действительно не много. Но насчёт одинаковых софтин ты загнул. Софтины не могут быть одинкавыми, потому что они обслуживают разный бизнес. У каждого бизнеса свои требования. Там где требования сходятся появляются ширпотребовские решения. Остальное — индпошив.
FDS>Ну, этот инд. пошив всё-таки друг на друга часто похож. Хотя не настолько, что бы он встречался в сотнях фирм.
В том то и дело, что похож, но не идентичен, а значит не взаимозаменяем.
IT>>Грамотные IT-люди того времени сидят и заполняют таможенные декларации, т.к в своё время им не хватило сил на переход с ЕС ЭВМ на писюки. Правда, другие, чуть менее грамотные, но более ушлые сейчас командуют первыми.
FDS>Имеются ввиду, видимо, западные специалисты.
Нет. Западные специалисты как раз очень быстро пересели с мейнфреймов на бэйсик. У них тогда компании под этого дело бесплатные курсы повсеместно устраивали.
IT>>Если и не станет, то по другим причинам, а не по этой. "Дешевый личный состав" перешёл с C на C++. Потом с DOS на Windows и на COM, потом с Windows и с C++ на .NET, с COM+ и VB на C#. Переход на Немерле гораздо проще всего вышеперечисленного. Для C# программиста это часы.
FDS>Почему же я до сих пор так и не смог написать даже простую работающую программу на Nemerle. Я уже даже на Scheme стал писать (в процессе спора на форуме), а вот на Nemerle — ну никак, ну не получается!
А что именно не получается?
... << RSDN@Home 1.2.0 alpha rev. 0>>
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, IT, Вы писали:
IT>Здравствуйте, FDSC, Вы писали:
IT>>>В IT весь бизнес мелкий, даже в крупных компаниях. Небольшие команды, каждая со своими правилами и стандартами. FDS>>Но крупные компании могут в любом случае позволить себе инвестировать в IT гораздо больше, чем мелкий бизнес.
IT>Это правда. Именно поэтому в больших компаниях полно зомби проектов, которые уже умерли, но ещё ходят и пугают окружающих.
Но это не значит, что мелкая фирма сможет себе позволить инвестировать во все нужные проекты.
FDS>>У мелкого бизнеса есть такая потребность, так как он испытывает недостаток в финансировании. Могу даже сказать больше: когда нам читали лекции по экономике, лектор жаловался, что его "стартапу" (человек 15 программистов ) не хватает финансирования уже второй год, несмотря на то, что они получают гранты от государтсва (инвесторы ставят абсолютно неприемлимые условия).
IT>Может главная цель бизнеса твоего лектора как раз получение грантов, а не получение прибыли?
Нет, я довольно хорошо знаю как они работают и потом, там гранты не такие крупные — они сами то же не хило вкладываются из прибыли.
IT>>>Тебе просто не повезло, не обобщай и по скорее меняй работу. FDS>>Таких "неповезло" у нас в стране не так мало, лично я знаю как минимум 3 фирмы лично (при том, что не видел фирмы, где точно берут и классных специалистов и выпускников).
IT>Ну так и в чём проблема? Не нравится — уходи.
Гы, а если туда, где нравиться не возьмут?
А вы уверены, что лично мне где-нибудь понравиться вообще?
Ну ладно, пусть такое место существует: как его найти? Я не знаю ни одного, которое точно устраивает
IT>>>Классов задач действительно не много. Но насчёт одинаковых софтин ты загнул. Софтины не могут быть одинкавыми, потому что они обслуживают разный бизнес. У каждого бизнеса свои требования. Там где требования сходятся появляются ширпотребовские решения. Остальное — индпошив.
FDS>>Ну, этот инд. пошив всё-таки друг на друга часто похож. Хотя не настолько, что бы он встречался в сотнях фирм.
IT>В том то и дело, что похож, но не идентичен, а значит не взаимозаменяем.
Там можно было бы сделать и взаимозаменяемость. Другой вопрос, что не так много на дублирование ресурсов идёт.
IT>>>Грамотные IT-люди того времени сидят и заполняют таможенные декларации, т.к в своё время им не хватило сил на переход с ЕС ЭВМ на писюки. Правда, другие, чуть менее грамотные, но более ушлые сейчас командуют первыми.
FDS>>Имеются ввиду, видимо, западные специалисты.
IT>Нет. Западные специалисты как раз очень быстро пересели с мейнфреймов на бэйсик. У них тогда компании под этого дело бесплатные курсы повсеместно устраивали.
И где они сейчас, те кто программировали на Бейсик.... (исключить: "Билл Гейтс" )
Всё таки даже у них, что бы что-то заработать надо быть довольно грамотным.
IT>>>Если и не станет, то по другим причинам, а не по этой. "Дешевый личный состав" перешёл с C на C++. Потом с DOS на Windows и на COM, потом с Windows и с C++ на .NET, с COM+ и VB на C#. Переход на Немерле гораздо проще всего вышеперечисленного. Для C# программиста это часы.
FDS>>Почему же я до сих пор так и не смог написать даже простую работающую программу на Nemerle. Я уже даже на Scheme стал писать (в процессе спора на форуме), а вот на Nemerle — ну никак, ну не получается!
IT>А что именно не получается?
в рамках этого форума частично обсуждаем.
Не получается понять синтаксис языка: что ни напишу, компилятор всё время ругается . Подожду пока выйдет какая-нибудь нормальная документация...
Здравствуйте, VladD2, Вы писали:
VD>Тут уже было приведено два случая с неструктурной передачей управления. Один с выходом управления из свражения, другой с метдом не возращающим значение. Причем первый пример был приведен в качестве аргумента о том как красиво и кратно можно писать на смолтоке.
Я открыл статью Nemerle в Wikipedia, и я увидел, что та проблема, значение который Вы так пытаетесь преувеличить (незавершение работы метода, в который передан BlockClosure с возвратом), имеется и у Nemerle в макросах. Вот выдержка из этой статьи
Database accessibility
For example, using Nemerle macros for SQL you can write:
ExecuteReaderLoop ("SELECT firstname, lastname FROM employee WHERE firstname = $myparm", dbcon,
{
System.Console.WriteLine ("Name: {0} {1}", firstname, lastname)
});
Допустим есть у нас такой макрос. Что произойдет если использовать его так:
ExecuteReaderLoop ("SELECT firstname, lastname FROM employee WHERE firstname = $myparm", dbcon,
{
System.Console.WriteLine ("Name: {0} {1}", firstname, lastname);
return;
});
Я добавил слово return. Очевидно, что измененный код будет подставлен в макрос и, как следствие, весь макрос не будет выполнен до конца. А значить функциональность программы будет нарушена (не будет освобождены ресурсы). Судя по Вашим словам теперь Вы откажетесь от использования макросов в Nemerle, т.к. "их использование может быть небезопасно". Или у Вас имеются какие-то правила, позволяющие избегать данных проблем?
P.S. Считаю, что в данном случае сравнение макросов Nemerle и блоков Smalltalk абсолютно корректно, т.к. семантика их использования одинакова: должен быть выполнен какой-то код (который написан в макросе/блоке), и при его выполнении в некоторых местах будет вызываться/подставляться внешний код (переданный в качестве параметра)
Здравствуйте, FDSC, Вы писали:
FDS>А по Nemerle у меня уже десяток вопросов (на которые я сам не знаю ответа), которые возникли просто после написания простейших функций. [я бы сказал, что на уровне простейших функций Scheme гораздо легче для изучения, чем Nemerle ]
Вполне естественно. Scheme и Lisp вообще очень простые для изучения языки(сложно только научиться пользоваться ими эффективно). Пожалуй даже проще чем C# 2.0, а Nemerle все таки C# 2.0 + ML + макро-система. Но для эффективного использования досконального знания Nemerle совсем не нужно.
FDS>Хм, может я и не вчитывался (кое-где честно говоря действительно по диагонали), но этот раздел я раза три или четыре прочитал (включая файлы на самом сайте), и вот ну не вижу отличий: чем в Delphi функции — не замыкания! (см. пример ниже)
Есть мысль, что это не замыкания потому, что переменная x, которую захватывает функция addX живет только тогда, когда живет процедура Main(я слабо знаю Delphi и с паскалем последний раз имел дело почти десять лет назад, но что-то мне подсказывает, что x находится на стеке и с него убирается при выходе из процедуры). Что будет если функция addX будет возвращаться из другой функции? Смысл замыканий как раз в том, что захваченные значения/переменные сохраняются пока жив функциональный объект, вне зависимости от срока жизни объекта/функции в которых он был создан.
Вот такой пример на Delphi сможешь повторить?
#pragma indent
using System.Console
module Main
Foo(f : void->int) : void
WriteLine(f())
Bar() : void->int
mutable x : int
def closure() { x++; x }
WriteLine(closure())
Foo(closure)
WriteLine(x)
closure
Main() : void
mutable closure = Bar()
def foo() { WriteLine(closure()) }
foo()
closure = Bar()
foo()
Вот тебе еще один примерчик для осознания разницы между Nemerle и Delphi:
using System.Console;
using System.Collections.Generic;
module Main
{
Strashilka[A,R](dump : A*A*(A->A)->R) : A->(A->((A->A)->R))
{
x => y => f => dump(x,y,f)
}
Main() : void
{
def ops = List();
foreach(i in [1..3])
ops.Add(_ * i);
def dump(x, y, f) { WriteLine($"$x * $y == $(f(x))") }
def data = $[(x,f(1),f) | x in [1..4], f in ops];
data.Iter(dump);
def xdump = (x,y,f) => $"$x * $y == $(f(x))";
data.Iter((x,y,f) => WriteLine(Strashilka(xdump)(x)(y)(f)));
}
}
FDS>// Я думаю, надо def addX = add(_, x); ? FDS>Да, с этим согласен — это круто, не считая замечания, так как несвязанный параметр, как мне кажется, тут первый, а не второй, как вы написали.
А это абсолютно неважно первый или второй, особенно в данном случае.
FDS>Просто скопировал метод и он перестал компилироваться
Потому что локальная функция(да и вообще функция) это и не метод вовсе, это объект(хотя реальный объект зачастую не создается, у функции все равно семантика объекта), причем вполне конкретного generic типа. ref и out параметры у локальных функций не поддерживаются потому, что generic типы нельзя параметризовать так, чтобы учесть ref или out.
Может разработчикам компилятора и стоит попытаться найти обходной путь для этой проблемы, но я не думаю что это действительно нужная фича(зачем вообще локальным функциям out и ref параметры, особенно учитывая их возможность замыкаться на внешний контекст). Но исправить сообщение об ошибке определенно стоит.
FDS>Если я использую язык, я должен быть уверен, что по крайней мере элементарные операции я на нём умею делать.
На Nemerle уже написаны далеко не только элементарные вещи(компилятор Nemerle элементарной вещью трудно назвать). Если что-то "элементарное" сделать не получается стоит задуматься о целесообразности этой "элементарной" вещи. Я довольно много кода уже написал на Nemerle(все таки пару лет назад я впервые попытался его освоить и применить), ни разу не пришло в голову сделать такую вот "элементарную" вещь. Хотя может дело в том, что ref и out параметры я в принципе крайне редко использую.
FDS>P.S. Можно самый важный вопрос: вы знаете о Nemerle довольно много: это вы исходники разбирали или всё из примеров вывели?
Исходники компилятора это в первую очередь неплохой пример использования Nemerle, ну и для написания более-менее сложных макросов очень полезно туда заглядывать. Но конечно для изучения именно синтаксиса и всяких экзотических возможностей особую ценность представляют тесты — см.ncc/testsuite/positive. Ну и в конце концов документация на сайте не так уж и плоха, особенно если в ней покопаться.