OberonCore

Библиотека  Wiki  Форум  BlackBox  Компоненты  Проекты
Текущее время: Воскресенье, 22 Июнь, 2025 08:03

Часовой пояс: UTC + 3 часа




Начать новую тему Ответить на тему  [ Сообщений: 321 ]  На страницу Пред.  1, 2, 3, 4, 5, 6, 7 ... 17  След.
Автор Сообщение
 Заголовок сообщения: Re: Обратная сторона мейнстрима...
СообщениеДобавлено: Суббота, 02 Август, 2008 10:25 

Зарегистрирован: Четверг, 12 Июль, 2007 23:18
Сообщения: 1982
Откуда: Узбекистан, Чирчик
Иван Кузьмицкий писал(а):
Vlad писал(а):
Это ж какие там запрятанные нюансы? Что у базового типа можно вызвать ToString()? В чем загадка-то?
Загадка - зачем целочисленному типу иметь метод преобразования в строку? Ну объясните, почему целое число (число - сущность некоторой природы) надо рассматривать как объект (структура совершенно другой природы)? Почему число (число - которое от 0 до MAX(INT)) должно иметь метод (ну это бред сивой кобылы) преобразования этого числа в строку?

Вы никогда не печатали числа в консоль или в GUI-виджет?
Ну тогда я даже не представляю себе, какими задачами Вы занимаетесь, что можете обходиться без чисел... :о)

Для меня загадка с методом ToSring() в .NET'е в другом.

Я вот привык, что в том же Хаскелле функция show (метод класса типов Show) выдаёт строку с каким-нибудь вменяемым представлением того значения, к которому она представляется. Скажем, так:
Код:
Hugs> show 1                 -- целое число
"1"

Hugs> show 3.14              -- вещественное число
"3.14"

Hugs> show True              -- булево значение
"True"

Hugs> show [1, 2, 3]         -- список целых чисел
"[1,2,3]"

Hugs> show (1, False, "abc") -- кортёж из целого числа, булева значения и строки
"(1,False,\"abc\")"

Конечно, для новых пользовательских типов этот метод может быть определён как угодно, это зависит от конкретного аффтара, но всё-таки принято эту функцию заставлять выдавать внутреннее представление значения во логически обоснованном виде.

А что мы видим в .NET'е? (смотрим в интерпретаторе F#)
Код:
> 1.ToString();;

  1.ToString();; // ну хорошо, понятно, тут я лажанулся...
  ^^^^^^^^^^^

stdin(1,0): error FS0191: This is not a valid numeric literal. Sample formats include 4, 0x4, 0b0100, 4L, 4UL, 4u, 4s, 4us, 4y, 4uy, 4.0, 4.0f, 4N, 4I.
> val it : unit = ()

> (1).ToString();;        -- целое число
val it : string = "1"

> (3.14).ToString();;     -- вещественное число
val it : string = "3,14"

> true.ToString();;       -- булево значение
val it : string = "True"

> [1; 2; 3].ToString();;  -- список целых чисел
val it : string = "Microsoft.FSharp.Collections.List`1+_Cons[System.Int32]"

// опаньки! это что ещё за фигня? Мне не нужно имя типа этого списка, мне нужно его самого! 8-o

> (1, false, "abc").ToString();;
val it : string = "Microsoft.FSharp.Core.Tuple`3[System.Int32,System.Boolean,System.String]"

В C# такая же история
Код:
int[] arr = new int[] { 1, 2, 3};
textBox.Text = arr.ToString();

В textBox.Text помещается строка "System.Int32[]"

Допустим, определяем мы в Хаскелле такой тип-запись:
Код:
data Rec = Rec { str :: String, num :: Integer, flag :: Bool}
     deriving (Show)

Затем в интерпретаторе с удовольствием наблюдаем, что автоматически сгенерированный для нашего типа метод show (эту генерацию мы указали описанием deriving (Show)) выдаёт более-менее разумную строку:
Код:
Main> show Rec { str = "abc", num = 1, flag = True }
"Rec {str = \"abc\", num = 1, flag = True}"

В F# классов типов, к сожалению, нет, система типов там -- жуткий гибрид традиционного для ML-семейства системы Хиндли-Милнера + OCaml'евский ООП + .NET'овский ООП.

Вообще, F# переусложнённый язык -- он включает в себя OCaml как своё подмножество, плюс к этому автор F# решид сжелать его полноценным языком для .NET'a, а это значит, что должна быть поддержка всего, что есть в С# -- дженерики, анонимные делегаты (это вообще песня! но необходимо для полноценного интеропа с C#), LINQ, COM-интерфейсы, вопщем, всё эти тихие ужасы...
Если бы Дон Сайм (Don Syme) не стал разрабатывать F#, а всю эту энергию направил бы на доделку GHC.NET, у него наверняка всё получилось бы... :о)

Для приведённого выше кода на Хаскелле на C# придётся делать такое:
Код:
    class Rec : Object
    {
        public string str;
        public int    num;
        public bool   flag;

        public Rec(string s, int n, bool f)
        {
            this.str  = s;
            this.num  = n;
            this.flag = f;
        }

        public string ToString()
        {
            return "Rec { str = \"" + str + "\", num = " + num.ToString() +
                   ", flag = " + flag.ToString() + " }";
        }
    }

На F# и то покрасивше:
Код:
type Rec = { str : string; num : int; flag : bool }
    with
        override x.ToString() =
            "Rec { str = \"" + x.str + "\", num = " +
            x.num.ToString() + ", flag = " + x.flag.ToString() + " }"
    end;;

без ООП, правда, всё равно не обошлось (перегрузка метода ToString())...
Код:
> { str = "abc"; num = 1; flag = true }.ToString();;
val it : string = "Rec { str = \"abc\", num = 1, flag = True }"


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Обратная сторона мейнстрима...
СообщениеДобавлено: Суббота, 02 Август, 2008 10:33 
Аватара пользователя

Зарегистрирован: Суббота, 29 Март, 2008 19:27
Сообщения: 1053
Откуда: Россия, Чебоксары
Илья Ермаков писал(а):
Метод, по идеологии ООП, это "навык", "умение" некоторого объекта. Его внутренняя активность. i.ToString() предполагает, что число - оно объект, оно активное, оно знает про существование строк и оно умеет себя преобразовывать в строки. Нонсенс. Нормальная логика: должна быть какая-то то служба, которая умеет преобразовывать числа в строки.
Вынужден категорически не согласиться. Комбинаторика. Число сочетаний всех возможных связей. Задача поставлена некорректно.

Задача явно несимметричная. Поэтому корректной постановкой будет что-то клиент-серверное. В данном случае "сервером" должно выступать "строковое представление". Почему? Да просто потому, что строка гораздо более фундаментальна (и, если хотите, общеупотребительна), чем, к примеру, комплексное число.

Вариант наличия специальной службы преобразования данных супернерационален. Комбинаторика. Данный вариант исходит из неверной предпосылки одноранговости двух рассматриваемых сущностей, но это отнюдь не так. Завтра тысяча пользователей напишут десять тысяч новых программных сущностей, которые будут использовать в качестве интерфейса с внешним миром строковое представление. И вряд ли хотя бы одна новая сущность появится в дополнение или на замену строке.

Итак, что делает сервер? Он предоставляет, в данном случае, абстракцию типа данных и набор операций. Должен он знать о десятках тысяч потенциальных клиентов? Отнюдь, это было бы супернерационально.

Что делает клиент? Он использует сервисы, предоставляемые сервером. Поэтому он должен знать о сервере и его интерфейсе.

Поэтому вполне логично, что клиент, оформленный в виде класса (хотя это и необязательно), будет иметь метод ToString и FromString. Детали реализации этого метода будут сколь угодно сложными, и знать о них должен только сам клиент, а отнюдь не какая-то левая служба.


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Обратная сторона мейнстрима...
СообщениеДобавлено: Суббота, 02 Август, 2008 10:41 

Зарегистрирован: Четверг, 12 Июль, 2007 23:18
Сообщения: 1982
Откуда: Узбекистан, Чирчик
Иван Кузьмицкий писал(а):
Вы имеете в виду тождество или операцию присваивания? Оберон настолько негибкий, что подмял мой мозг и заставил воспринимать мир как он есть. Тождество - это, извините, никак не преобразование.
(я намеренно утрирую, т.к. Вы сказали, что "вам так удобнее". Вероятно, не менее удобно, чем принимать знак тождества за операцию присваивания).

декларация тождества двух сущностей и операция проверки равенства двух значений -- всё-таки разные вещи. Может быть, они и обозначаться должны разными символами?


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Обратная сторона мейнстрима...
СообщениеДобавлено: Суббота, 02 Август, 2008 10:52 

Зарегистрирован: Четверг, 12 Июль, 2007 23:18
Сообщения: 1982
Откуда: Узбекистан, Чирчик
Иван Кузьмицкий писал(а):
... индусский код в обероне, я так утверждаю, в принципе невозможен. ...

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


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Обратная сторона мейнстрима...
СообщениеДобавлено: Суббота, 02 Август, 2008 10:56 

Зарегистрирован: Четверг, 17 Ноябрь, 2005 11:51
Сообщения: 2935
Откуда: г. Ярославль
Geniepro писал(а):
Иван Кузьмицкий писал(а):
Vlad писал(а):
Это ж какие там запрятанные нюансы? Что у базового типа можно вызвать ToString()? В чем загадка-то?
Загадка - зачем целочисленному типу иметь метод преобразования в строку? Ну объясните, почему целое число (число - сущность некоторой природы) надо рассматривать как объект (структура совершенно другой природы)? Почему число (число - которое от 0 до MAX(INT)) должно иметь метод (ну это бред сивой кобылы) преобразования этого числа в строку?

Вы никогда не печатали числа в консоль или в GUI-виджет?
[/code]


С 1991 года, представьте себе, печатаю то в консоль, то в гуй, то в журнал. Вам нравится писать загадочно? Мне - нет. Я люблю, когда число - это число, а не корова с пропеллером.


Последний раз редактировалось Иван Кузьмицкий Суббота, 02 Август, 2008 11:01, всего редактировалось 1 раз.

Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Обратная сторона мейнстрима...
СообщениеДобавлено: Суббота, 02 Август, 2008 10:57 

Зарегистрирован: Четверг, 17 Ноябрь, 2005 11:51
Сообщения: 2935
Откуда: г. Ярославль
Geniepro писал(а):
Иван Кузьмицкий писал(а):
Вы имеете в виду тождество или операцию присваивания? Оберон настолько негибкий, что подмял мой мозг и заставил воспринимать мир как он есть. Тождество - это, извините, никак не преобразование.
(я намеренно утрирую, т.к. Вы сказали, что "вам так удобнее". Вероятно, не менее удобно, чем принимать знак тождества за операцию присваивания).

декларация тождества двух сущностей и операция проверки равенства двух значений -- всё-таки разные вещи. Может быть, они и обозначаться должны разными символами?


Различие всё-же минимально, в отличие от операции переноса данных с правой стороны выражения в левую.


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Обратная сторона мейнстрима...
СообщениеДобавлено: Суббота, 02 Август, 2008 10:58 

Зарегистрирован: Четверг, 17 Ноябрь, 2005 11:51
Сообщения: 2935
Откуда: г. Ярославль
Geniepro писал(а):
Иван Кузьмицкий писал(а):
... индусский код в обероне, я так утверждаю, в принципе невозможен. ...

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


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


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Обратная сторона мейнстрима...
СообщениеДобавлено: Суббота, 02 Август, 2008 11:03 
Аватара пользователя

Зарегистрирован: Понедельник, 14 Ноябрь, 2005 18:39
Сообщения: 9459
Откуда: Россия, Орёл
Alexey_Donskoy писал(а):
Илья Ермаков писал(а):
Метод, по идеологии ООП, это "навык", "умение" некоторого объекта. Его внутренняя активность. i.ToString() предполагает, что число - оно объект, оно активное, оно знает про существование строк и оно умеет себя преобразовывать в строки. Нонсенс. Нормальная логика: должна быть какая-то то служба, которая умеет преобразовывать числа в строки.
Вынужден категорически не согласиться. Комбинаторика. Число сочетаний всех возможных связей. Задача поставлена некорректно.
...


Алексей, я с Вами согласен относительно Вашего решения. Но Ваше решение приведено для задачи "вывод на печать объектов". Т.е. тех сущностей, которые что-то уже умеют. Почему бы их не научить ещё и называть своё текстовое представление?

Я же вёл речь о простых сущностях. Если это атомарный тип, или тот тип, который нерасширяем (не использует виртуализацию), то чем плохо решение с отдельной процедурой? Да, действительно, эта процедура должна быть на стороне клиента, т.е. той сущности, который выводим. Но если эта сущность не полиморфна (человек явно её использует из конкретного модуля, без посредничества фабрик/абстрактных интерфейсов), то что мешает размещать в этом модуле ещё и процедуру ToString?

Речь-то о чём: виртуализация - это уже приём более высокого порядка. На него надо переключаться тогда, когда он нужен (пусть и нужен он в сложных проектах очень и очень часто, для большинства служб). Но должен быть в языке и твёрдый уровень более приземлённого мышления. Модные же мейнстримовые кунштюки лишают человека этого уровня, навязывают ему "постмодернистский" стиль мышления "виртуально всё и всегда. Виртуаль сам, навиртуаливай других и жди, где навиртуалят тебя" :-) Для обучения новичков это вообще смерти подобно - это значит, что они не могут, бедные, понять ничего из того, что вообще происходит, а просто комбинаторно заучивают, что и где надо написать... Вот и для индусов тоже - короткое образование их типового программиста + особенности мировоззрения, о чём Кузьмицкий и говорил тут несколько раз!


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Обратная сторона мейнстрима...
СообщениеДобавлено: Суббота, 02 Август, 2008 11:05 

Зарегистрирован: Четверг, 12 Июль, 2007 23:18
Сообщения: 1982
Откуда: Узбекистан, Чирчик
Илья Ермаков писал(а):
Нормальная логика: должна быть какая-то то служба, которая умеет преобразовывать числа в строки. Или, может быть, основная служба, отвечающая за работу со строками, умеет их создавать сразу из элементарного численного значения.

почему это вдруг? Кто сказал, что так правильно? Здравый смысл?

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

Да и опять же, не является ли ситуация с числами, строками, массивами в Обероне именно тем, что можно назвать "проще"? Не нарушили ли оберонщики завет Эйнштейна? Не слишком ли "проще" они всё сделали?


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Обратная сторона мейнстрима...
СообщениеДобавлено: Суббота, 02 Август, 2008 11:16 

Зарегистрирован: Вторник, 29 Август, 2006 12:32
Сообщения: 2662
Откуда: Россия, Ярославль
Geniepro писал(а):
Вы никогда не печатали числа в консоль или в GUI-виджет?Ну тогда я даже не представляю себе, какими задачами Вы занимаетесь, что можете обходиться без чисел...

Интересные выводы. То есть, если я правильно понял, вы считаете что без наличия у типа INTEGER(или любого другого базового) метода ToString() работать с типом нельзя? Это уже патология, имхо.
Вам так "удобнее"? А с каких пор логичность жертвуется в угоду сомнительной удобности? Или в майнстриме это обычное явление?

Geniepro писал(а):
на сегодняшний день это безосновательное утверждение. Вот когда (и если) начнут на Обероне работать "индусы", вот тогда и посмотрим, можно ли будет их код назвать индусским или нет...

Куда ж он с подводной лодки денется? Индус просто не сможет сделать что-то криво на уровне языка в силу его строгости.

Alexey_Donskoy писал(а):
Должен он знать о десятках тысяч потенциальных клиентов?

Какие тысячи? Какие десятки тысяч? Базовых, базовых типов всего ничего... Их представления в строковом виде всем давно известны. Методы представления уже готовы. Все последующие "клиенты" будут построены из этих базовых типов, что позволит использовать уже существующие методы представления в виде строк для всех составляющих этой сущности.

X базовых типов, X - 1(ну, плюс вариации, типа экспоненциальный, десятичный и прочее) метод "перевода в строку" (строка ведь тоже базовый тип). X порядка 10, X постоянно, зависит от реализации языка.
Y "клиентов", Y методов перевода в строку(минимум, потому что неизвестно, подойдёт ли текущее представление в следующий раз). Даже порядок Y не определён.


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Обратная сторона мейнстрима...
СообщениеДобавлено: Суббота, 02 Август, 2008 11:19 
Аватара пользователя

Зарегистрирован: Понедельник, 14 Ноябрь, 2005 18:39
Сообщения: 9459
Откуда: Россия, Орёл
Здравый смысл - слишком перегруженное понятие.
Тот здравый смысл, по которому земля - диск, а Солнце вокруг нас ходит - это скорее "обывательский смысл". Не смысл вообще, а набор устоявшихся предрассудков. Ещё - способ передачи/восприятия коллективного опыта, "набитого шишками". Между прочим, далеко не всегда вредный. И уж всегда стоящий того, чтобы его изучить и поразмыслить, а просто ли так он возник? (бывает, что некоторые вещи, которые охаиваются и отбрасываются с точки зрения сиюминутного умствования, в итоге оказываются действующими долгосрочно - и потом N лет спустя, когда и спросить уже не с кого, начинают кусать локти...)

А совсем другое - "здравость мышления". Как стремление быть как можно ближе к реальному миру, к тому, как оно там есть на самом деле (кто ж знает до конца? но стремиться и приближаться можно и нужно). Это как раз то, про отсутствие чего Эйнштейн говорил - "Математика может становиться лучшим способом водить самого себя за нос" :-)

Ещё раз позволю себе напомнить Вам, Евгений, о диалектике. И о понятии меры.

Касательно Оберона. Его (реальные) некоторые неудобства не поддаются лёгкой ликвидации, без выпрыгивания по другим критериям далеко от того оптимума, в котором он находится. Это не значит, что нельзя сделать лучше, чем в Обероне. Просто пока ещё не придумано :-) Думать не возбраняется. А вот кидаться с шашкой наголо "вот это надо вот так вот", бездумно комбинируя чужие кунштюки - лучше не надо. Ничего хорошего не получаецца.


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Обратная сторона мейнстрима...
СообщениеДобавлено: Суббота, 02 Август, 2008 11:24 

Зарегистрирован: Четверг, 12 Июль, 2007 23:18
Сообщения: 1982
Откуда: Узбекистан, Чирчик
Иван Кузьмицкий писал(а):
Я так понял, в приведённом примере необходимо проинициализировать поля уже созданной структуры, а не создавать новую. Поэтому использовать функцию нет смысла, и old_function производит, с точки зрения языка, совершенно легальные действия.

От такого никак не защититься, кроме как воспитанием строгого мышления у программиста.

Способ защититься есть. Правда, он радикальный, и потому у императивных программистов вызывает отторжение. Но времена постепенно меняются, появляется всё больше программистов, у которых ещё не наработан императивный здравый смысл...

ЗЫ. Вспомнил старинный анекдот:

Докладывает миссионер папе Римскому, что каждый день в Китае обращаются в христианскую веру сотни людей, и делается вывод, что очень скоро Китай станет христианским миром.
Вот только о том, что каждый же день в Китае рождаются деятки тысяч людей, он почему-то забывает упомянуть... :о)


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Обратная сторона мейнстрима...
СообщениеДобавлено: Суббота, 02 Август, 2008 11:36 

Зарегистрирован: Вторник, 29 Август, 2006 12:32
Сообщения: 2662
Откуда: Россия, Ярославль
Geniepro писал(а):
Способ защититься есть. Правда, он радикальный, и потому у императивных программистов вызывает отторжение.


Просвятите пожалуйста, что за способ?


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Обратная сторона мейнстрима...
СообщениеДобавлено: Суббота, 02 Август, 2008 11:42 

Зарегистрирован: Четверг, 12 Июль, 2007 23:18
Сообщения: 1982
Откуда: Узбекистан, Чирчик
Alexey_Donskoy писал(а):
... Завтра тысяча пользователей напишут десять тысяч новых программных сущностей, которые будут использовать в качестве интерфейса с внешним миром строковое представление. И вряд ли хотя бы одна новая сущность появится в дополнение или на замену строке.

Итак, что делает сервер? Он предоставляет, в данном случае, абстракцию типа данных и набор операций. Должен он знать о десятках тысяч потенциальных клиентов? Отнюдь, это было бы супернерационально.

Что делает клиент? Он использует сервисы, предоставляемые сервером. Поэтому он должен знать о сервере и его интерфейсе.

Поэтому вполне логично, что клиент, оформленный в виде класса (хотя это и необязательно), будет иметь метод ToString и FromString. Детали реализации этого метода будут сколь угодно сложными, и знать о них должен только сам клиент, а отнюдь не какая-то левая служба.

О! Ваши слова прямо как бальзам на душу!

Именно так и сделано в Хаскелле -- для любого нового или не нового типа можно определить экземпляр какого-нибудь класса типов, в данном случае -- классов типов Show и Read.
У этих классов есть такие методы, как show (показать значение этого типа в виде строки) и read (прочесть значение этого типа из строки), их и должен определять автор нового типа для этого своего типа...
Интерфейс -- един для всех типов, для которых указано, что они поддерживают этот интерфейс, перегрузочный полиморфизм в красивом, и более мощном и удобном, чем в ООП, виде...


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Обратная сторона мейнстрима...
СообщениеДобавлено: Суббота, 02 Август, 2008 11:43 
Аватара пользователя

Зарегистрирован: Понедельник, 14 Ноябрь, 2005 18:39
Сообщения: 9459
Откуда: Россия, Орёл
Geniepro писал(а):
Правда, он радикальный, и потому у императивных программистов вызывает отторжение. Но времена постепенно меняются, появляется всё больше программистов, у которых ещё не наработан императивный здравый смысл...


Jack of Shadows Вам на уши сладкую лапшу вешает, а Вы - другим? :-) Правда за вами с Джеком, конечно, есть, но только при определённых ограничениях.

Я не раз уже пытался заставить активистов ветки ФП задуматься над тем, что как бы не "менялись времена", но классы задач никуда не деваются. И разделение на программы, представляющими собой определение преобразования на данных или определение поведения, никуда не исчезнет. Функция - это средство описания вычислений. Алгоритм (императив) - это средство описания (моделирования) поведения систем. И не надо втирать очки, что первое более высокоуровнево, чем второе. С точки зрения задач первого класса - да (возможность не описывать порядок действий для достижения результата). С точки зрения системного анализа сложных систем - наоборот. Алгоритм моделирует динамику системы (а система живёт только в динамике). Функциональные соотношения могут выразить только частный простой срез. (речь не о вычислительной эквивалентности. Речь о выразительности абстракций. Естественно, для действительно сложных систем нереальна полная формализация ни в каких терминах.) Кстати, дейкстровский анализ алгоритмов ещё очень сильно недооценён. С точки зрения анализа систем он должен стать для алгоритмов (поведения) аналогом классического анализа для функций (мат. соотношений). Таким же средством для анализа динамики кибернетических систем, как дифф. исчисление - для физических.


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Обратная сторона мейнстрима...
СообщениеДобавлено: Суббота, 02 Август, 2008 11:48 

Зарегистрирован: Вторник, 29 Август, 2006 12:32
Сообщения: 2662
Откуда: Россия, Ярославль
Geniepro писал(а):
появляется всё больше программистов, у которых ещё не наработан императивный здравый смысл...


Конечно, они ведь тоже программисты. Ничего, что посредственные, важно, что они яркие индивидуальности, у нас ведь есть свободы.
После размышлений сложилось мнение: мейнстрим - это демократия: "делай что хошь, пеняй на себя". обероны - это тоталитаризм: "откажись от некоторых свобод, делай по правилам, но получи стабильное развитие и перспективы". Теперь очень моё имхо: что получается при демократии можно понять, окинув взглядом 17 лет новейшей истории России. Тоталитализм, диктатура - империи всех мастей, СССР 30-50 годов(тоже суть империя). Выводы не привожу, решайте сами.


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Обратная сторона мейнстрима...
СообщениеДобавлено: Суббота, 02 Август, 2008 12:11 

Зарегистрирован: Четверг, 12 Июль, 2007 23:18
Сообщения: 1982
Откуда: Узбекистан, Чирчик
Пётр Кушнир писал(а):
То есть, если я правильно понял, вы считаете что без наличия у типа INTEGER(или любого другого базового) метода ToString() работать с типом нельзя? Это уже патология, имхо.
Вам так "удобнее"? А с каких пор логичность жертвуется в угоду сомнительной удобности? Или в майнстриме это обычное явление?

логичность? А с чего вот конкретно Вы решили, что логичнее так, как Вам лично привычнее и удобнее, а не так, как принято в мэйнстриме? :о)
Можете обосновать Вашу личную уверенность в этой логичности?

Пётр Кушнир писал(а):
Geniepro писал(а):
на сегодняшний день это безосновательное утверждение. Вот когда (и если) начнут на Обероне работать "индусы", вот тогда и посмотрим, можно ли будет их код назвать индусским или нет...

Куда ж он с подводной лодки денется? Индус просто не сможет сделать что-то криво на уровне языка в силу его строгости.

Слова, которые пока ещё ничем и никем не подтверждены...

Пётр Кушнир писал(а):
Какие тысячи? Какие десятки тысяч? Базовых, базовых типов всего ничего...

...строка ведь тоже базовый тип...

А почему Вы так решили, что это правильно -- разделять типы на "базовые" и "небазовые"?

Строка -- базовый тип, или массив символов -- базовый тип? Кто из них более базовый? :о)


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Обратная сторона мейнстрима...
СообщениеДобавлено: Суббота, 02 Август, 2008 12:20 

Зарегистрирован: Четверг, 12 Июль, 2007 23:18
Сообщения: 1982
Откуда: Узбекистан, Чирчик
Илья Ермаков писал(а):
Ещё - способ передачи/восприятия коллективного опыта, "набитого шишками". Между прочим, далеко не всегда вредный. И уж всегда стоящий того, чтобы его изучить и поразмыслить, а просто ли так он возник? (бывает, что некоторые вещи, которые охаиваются и отбрасываются с точки зрения сиюминутного умствования, в итоге оказываются действующими долгосрочно - и потом N лет спустя, когда и спросить уже не с кого, начинают кусать локти...)

Предлагаю обдумать эту фразу в контексте постоянных наездов оберонщиков на мэйнстрим... :о)
Не кажется ли Вам, что охаивая мэйнстримные подходы и методы, Вы выплёскиваете с водой и ребёнка?

Ведь мэйнстрим -- это тоже коллективный опыт, "набитый шишками". Между прочим, далеко не всегда вредный... :о)


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Обратная сторона мейнстрима...
СообщениеДобавлено: Суббота, 02 Август, 2008 12:25 

Зарегистрирован: Четверг, 12 Июль, 2007 23:18
Сообщения: 1982
Откуда: Узбекистан, Чирчик
Иван Кузьмицкий писал(а):
Различие всё-же минимально, в отличие от операции переноса данных с правой стороны выражения в левую.

Если Вы продекларировали, что две сущности тождественны (идентичны), то проверять их на равенство нет никакого смысла -- они не просто равны по определению, они суть одно и тоже значение.
Если Вы указываете, что f(x) = x^2+x+1, то Вы везде, где встречается выражение вида z^2+z+1 можете безбоязненно заменить это выражение на f(z). И наоборот. Это называется "ссылочная прозрачность (referential transparency)".

А если же Вы записываете формулу более сложную, например, такую:
Код:
factorial(x) = if x = 0 then 1 else x*factorial(x-1)

то тут значок "=" приобретает два совершенно разных смысла -- в первом случае он декларирует тождество между выражением factorial(x) и выражением if x = 0 then 1 else x*factorial(x-1), а во втором случае Вы пытаетесь узнать, равен ли входной параметр x числу 0.
Какие-то языки (F#, например), не подчёркивают этого различия, в Хаскелле же оно есть, и операция проверки на равенство имеет написание "==", а не "="...


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Обратная сторона мейнстрима...
СообщениеДобавлено: Суббота, 02 Август, 2008 12:29 

Зарегистрирован: Четверг, 12 Июль, 2007 23:18
Сообщения: 1982
Откуда: Узбекистан, Чирчик
Пётр Кушнир писал(а):
Geniepro писал(а):
Способ защититься есть. Правда, он радикальный, и потому у императивных программистов вызывает отторжение.


Просвятите пожалуйста, что за способ?

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


Вернуться к началу
 Профиль  
 
Показать сообщения за:  Поле сортировки  
Начать новую тему Ответить на тему  [ Сообщений: 321 ]  На страницу Пред.  1, 2, 3, 4, 5, 6, 7 ... 17  След.

Часовой пояс: UTC + 3 часа


Кто сейчас на конференции

Сейчас этот форум просматривают: Bing [Bot] и гости: 5


Вы не можете начинать темы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете добавлять вложения

Найти:
cron
Вся информация, размещаемая участниками на конференции (тексты сообщений, вложения и пр.) © 2005-2025, участники конференции «OberonCore», если специально не оговорено иное.
Администрация не несет ответственности за мнения, стиль и достоверность высказываний участников, равно как и за безопасность материалов, предоставляемых участниками во вложениях.
Без разрешения участников и ссылки на конференцию «OberonCore» любое воспроизведение и/или копирование высказываний полностью и/или по частям запрещено.
Powered by phpBB® Forum Software © phpBB Group
Русская поддержка phpBB