Извините :). Я, кстати, не согласен с принципом «Явное лучше неявного». Мне вот кажется, что хорошие умолчания лучше. Если явно обозначать все, то труднее отличить необычные ситуации.
Давайте обсудим почему вы считаете это лапшой. Поясните в чем тут лапшистость? Статический контроль типов на месте, за использованием переменной больше контроля.
плохо сочетается с выводимыми или неявными типами.
Предсказываю, что выводимые и неявные типы для оберонщиков, это злостная ересь: все переменные должны быть описаны в отдельном списочке, все типы должны быть явно продекларированы, все ENDы должны снабжаться указанием на соответствующие BEGINы и вообще порядок учета требует.
Еще можно тип объявить посреди вызовов. И тут же его реализовать.
Да, смотрите как это легко делается:
var productQuery =
from prod in products
select new { prod.Color, prod.Price };
foreach (var v in productQuery)
{
Console.WriteLine("Color={0}, Price={1}", v.Color, v.Price);
}
Ограниченный скоп означает, что у вас в коде кандидат на вынос в отдельный метод или хотя бы замыкание. А там свой скоуп.
Я с этим согласен, но практически так никто не делает — я думаю можно взять любой достаточно большой код и там будет практически всегда логический скоуп переменной меньше чем вся функция.
Когда мы захотим этот кусок кода вынести в отдельную функцию нам будет легче копировать непрерывный кусок, чем два несвязанных.
То есть, если Вы все-таки меняете изначальный вопрос про внутренний счетчик цикла на вопрос про скоупы вообще, то желательно хотя бы предупредить об этом всех собеседников.
Посмотрите эту ветку комментариев повнимательнее (начиная с ответа habrahabr.ru/users/asm0dey). Она вообще не относится к счетчикам циклов, а относится к скоупам. Мое сообщение содержит слово скоуп в самом начале.
Я думаю, просто непривычно — для меня такой код вполне читаем. + еще я обычно использую вывод типов:
var navigator = GetComponent ();
navigator.enabled = false;
var force = GetComponent ();
force.enabled = false;
var death = GetComponent ();
death.Play ();
В данном кокретном аспекте совершенно все равно какая кокретно конструкция используется, главное что есть ограниченный скоп и меньше вероятности сделать некоторые виды ошибок.
Циклы дейкстры совершеено пофиг в разрезе того, где декларировать переменную.
Почему обход массива два раза — тупой? Между этими бзодами вполне может быть код модифицирующий массив?
// какой-то код
// здесь нельзя ошибочно использовать переменную I
for(var i in myArray1)
{
// здесь можно использовать i
}
// здесь нельзя по ошибке использовать I
for(var i in myArray1)
{
// здесь можно использовать i
}
// здесь нельзя по ошибке использовать I
+ чем более эксотичный язык, тем меньше вероятность что будет нормальная IDE. Например автоматический инструмент рефакторинга который перенесет кусок кода с использованными переменными другое место. А в случае локального декларирования это сделать проще.
Я понимаю, поэтому сформулировал задачу не в терминах коллекций, а в терминах предметной области «Телефонная книжка». Давайте рассмотрим код, который это реализует на Обероне с помощью чего угодно и изучим его свойства.
> Прежде всего меня волнует не код, а коррекные формулировки
Вам описана задача. Сформулируйте ее решение на языке Оберон в любых удобных для вас терминах, а мы посчитаем лексемы и посмотрим соблюдается ли разделение между логикой и представлением.
Почему бы всесто этих слов не написать код? Слова-то вы пишете? Вот тестовая задача, я написал на C#, yuuri написал на Haskell, напишите на Оберон и мы поймем какой он.
Итак, мы приходим к выводу, что приближение к предметной области могут позволить себе только большие западные компании с оборотом в миллиарды долларов
Кстати, несогласен. Если посмотреть на языки очень много сделно не корпорациями — ruby, python, nemerle. У нас тоже была какая-то мелкая конторка, котоаря писала компилятор C++ — читал историю в PC Magazine, кажется.
Далее, есть же Open Source — причем все куски стека и генераторы парсеров и виртуальные машины.
цена разработки и поддержки компилятора сильно возрастает. Может ли сообщество хабра поднять собственный компилятор такого масштаба — думаю, ответ очевиден — конечно же, не может, ведь для этого нужны серьёзные деньги. Импортозамещение сразу же проседает.
Согласен сложный компилятор сделать сложнее чем простой. Компилятор, как мне кажется, не самое сложное. Самое сложное — экосистема.
стоимость обучения специалиста растёт, хотя можно сказать, что пусть учится вечерами, в промежутке между курсовыми и заработками в макдональдсе.
Не согласен, как правило, чем более высокий уровень языка тем проще научаиться писать на нем программы. Форт проще чем C# но найчиться писать на нем программы сложнее. Написать foreach проще чем каждый раз писать while.
ответственность, вы не имеете права на ошибку, ведь на ваш ЯП как средство производства будут завязано много задач.
Если у вас гетерогенная структура построена на шине сообщений, то коллекции вам просто не нужны, посылайте агентам сообщения.
Никаких гетерогенных структур и шин. Просто в предметной области есть что-то содержащие в себе элементы. Например вы пишете приложение адресную книжку и вам надо выполнят различные действия с ее элементами.
Мне кажется тут есть некое фнудаментальное различие в подходах типа mappers vs packers: я вижу программу как реализаию некоторой модели придметной области, вы составляете ее из программных деталей типа «шин» и «агентов».
Например модель предметной области телефонная книжка:
// запись телефонной книжки это имя и номер телефона
class PhoneBookRecord {
string Name;
string Phone;
}
// Телефонная книжка содержит в себе записи
class PhoneBook {
List<PhoneBookRecord> Records = new List<PhoneBookRecord>();
}
А теперь какой-нибудь просто агоритм
// преобразование телефонной книжки в HTML
string convertToHtml(PhoneBook phonebook)
{
// это соединенная через тег
последовательность html предствалений записей
return String.Join("
", phonebook.Records.Select(convertToHtml));
}
// преобразование записи в HTML
string convertToHtml(PhoneBookRecord record)
{
// искейпинг опускаем
return String.Format("<b>{0}</b>: {1}", record.Name, record.Phone);
}
Здесь исходник очень близок к описанию задачи — никаких агентов и шин.
Если мне вдруг захочется поменять список на массив или SQL базу данных, я вполне себе смогу переделать эту деталь без переделки остальных частей.
Хотелось бы в качестве примера решение на Обероне.
Предсказываю, что выводимые и неявные типы для оберонщиков, это злостная ересь: все переменные должны быть описаны в отдельном списочке, все типы должны быть явно продекларированы, все ENDы должны снабжаться указанием на соответствующие BEGINы и вообще порядок учета требует.
Да, смотрите как это легко делается:
Я с этим согласен, но практически так никто не делает — я думаю можно взять любой достаточно большой код и там будет практически всегда логический скоуп переменной меньше чем вся функция.
Когда мы захотим этот кусок кода вынести в отдельную функцию нам будет легче копировать непрерывный кусок, чем два несвязанных.
Оберон, как я понял, не поддерживает замыканий en.wikipedia.org/wiki/First-class_function#Language_support
Посмотрите эту ветку комментариев повнимательнее (начиная с ответа habrahabr.ru/users/asm0dey). Она вообще не относится к счетчикам циклов, а относится к скоупам. Мое сообщение содержит слово скоуп в самом начале.
Циклы дейкстры совершеено пофиг в разрезе того, где декларировать переменную.
Почему обход массива два раза — тупой? Между этими бзодами вполне может быть код модифицирующий массив?
В кратце — более осмысленный скоп.
+ чем более эксотичный язык, тем меньше вероятность что будет нормальная IDE. Например автоматический инструмент рефакторинга который перенесет кусок кода с использованными переменными другое место. А в случае локального декларирования это сделать проще.
Вам описана задача. Сформулируйте ее решение на языке Оберон в любых удобных для вас терминах, а мы посчитаем лексемы и посмотрим соблюдается ли разделение между логикой и представлением.
Кстати, несогласен. Если посмотреть на языки очень много сделно не корпорациями — ruby, python, nemerle. У нас тоже была какая-то мелкая конторка, котоаря писала компилятор C++ — читал историю в PC Magazine, кажется.
Далее, есть же Open Source — причем все куски стека и генераторы парсеров и виртуальные машины.
Согласен сложный компилятор сделать сложнее чем простой. Компилятор, как мне кажется, не самое сложное. Самое сложное — экосистема.
Не согласен, как правило, чем более высокий уровень языка тем проще научаиться писать на нем программы. Форт проще чем C# но найчиться писать на нем программы сложнее. Написать foreach проще чем каждый раз писать while.
Вот это я не понял.
Никаких гетерогенных структур и шин. Просто в предметной области есть что-то содержащие в себе элементы. Например вы пишете приложение адресную книжку и вам надо выполнят различные действия с ее элементами.
Мне кажется тут есть некое фнудаментальное различие в подходах типа mappers vs packers: я вижу программу как реализаию некоторой модели придметной области, вы составляете ее из программных деталей типа «шин» и «агентов».
Например модель предметной области телефонная книжка:
А теперь какой-нибудь просто агоритм
Здесь исходник очень близок к описанию задачи — никаких агентов и шин.
Если мне вдруг захочется поменять список на массив или SQL базу данных, я вполне себе смогу переделать эту деталь без переделки остальных частей.
Хотелось бы в качестве примера решение на Обероне.