Oberon space
General Category => Общий раздел => Тема начата: Berserker от Февраль 26, 2011, 03:28:42 pm
-
Хочу поделиться с записями, сделанными на начало прошлого года и содержащими идеи на тему, какими фичами должен обладать ЯП, условно приближенный к идеальному.
-) Все входные аргументы подпрограмм подлежат обязательной проверке assert-подобным выражением.
procedure WriteChar
(
x: int; Math.InRange(x, 0, WndWidth - 1);
y: int; Math.InRange(y, 0, WndHeight - 1);
col: str; ANY;
)Смысл: координаты должны быть в рамках окна, а строка цвета - любой.
Особенности:
- Объявление одного аргумента - одна строка.
- Аргумент отделяется от охраны символом ";"
- Охрана - обычное логическое выражение. Если оно включает подпрограммы, то те не должны рекурсивно ссылаться на объявляемую подпрограмму.
- Константа ANY = TRUE.
Дополнение:
Так как охрана может быть сложной и писать её полностью может быть затруднительно, неплохим вариантом видится введение соглашений (см. Соглашения).
-) Именованные параметры.
При вызове подпрограммы должны указываться пары: имя параметра ":" значение.
WriteChar(x: 3; y: 4; col: 'black');! Исключение: если переменная/константа имеет то же имя, что и параметр, то может указываться просто имя параметра:
WriteChar(x, y, col: 'red');
-) Опциональные параметры.
Параметры, которые могут быть опущены при вызове. При этом в теле подпрограммы будут находиться проверки компилятора на проинициализированность подобных аргументов.
procedure WriteChar
(
x: ...
y: ...
optional Col: string; ANY; (* охрана типа осуществляется только, если аргумент инициализирован *)
)
{
...
if !IsSet(Col)
{
Col := Console.Col;
}
}IsSet - проверяет, установлен ли аргумент. Прямое присваивание значения аргументу автоматически устанавливает его.
-) Аргументы со значением по умолчанию. Значение должно быть константным выражением!
function Random
(
Min: int = 0; Min >= 0; (* охрана сработает всегда *)
Max: int = 99; Max >= Min; (* охрана сработает всегда *)
): int;
-) Аргументы по ссылке:
- in - после вызова переменная получает статус Unknown (равносильно неинициализированности)
- out - внутри подпрограммы имеет начальный статус Unknown
- inout - аналог var
-) Язык со сборкой мусора.
-) procedure и function для логического разделения подпрограмм. () после имени обязательно.
-) Обязательное присвоение значений переменным при объявлении с необязательной охраной.
VAR
AbsX: int = x + Con.Window.x1; AbsX in [0; Con.Width - 1];-) Записи-константы и записи, создаваемые на лету.
coords := (x: MyX, y); (* Заметьте, "y" не указывается два раза, та как имя переменной совпадает с именем поля в записи *)-) Опциональные поля записей.
Cell = record
optional Opacity: float = 1.0; (* прозрачность ячейки *)
end;-) Обязательное присвоение значений полям записи.
TCoord = record
x: int = -1;
y: int = -1;
end;-) Соглашения.
Служат для точного указания особенностей подпрограмм.
Пусть соглашение - логическая функция.
Пусть часть функций работает с абсолютными координатами консоли, а другая с относительными (относительно границ логически подокна).
convention (Con: TConsole) UsesRelativeCoords ()
(
x: int;
y: int;
)
{
result := Math.InRange(x, Con.WndWidth - 1) and Math.InRange(y, Con.WndHeight - 1);
}
procedure WriteChar
(
x: int; ANY;
y: int; ANY;
Ch: char; ANY;
); UsesRelativeCoords;
{
...
}Те аргументы, которые указанны в соглашении, обзяаны быть и в подпрограммах, использующих эти соглашения.
-
Можно коротко описать "идеал" - что это по вашему?
Надежность , читаемость, производительность, легкость в освоении, реализуемость... что-то еще и(или) в какой пропорции? (чтобы оценить соответствие ваших введений вашему замыслу)?
-
Прежде всего надёжность и, соответственно, эффективность, высвобождаемая за счёт времени, которое потенциально могло было быть потраченным на поиск и исправление ошибок.
-
Но тогда Вы должны начать с фиксации ошибок, которые могли бы быть устранены компилятором языка. Которые возникают на практике.
Вот, например, обзывать параметры процедур в точке вызова мне, на первый взгляд, нравится. Но подумав, я понимаю, что никогда не сталкивался с ошибкой, которую это бы предотвратило. А память, например, у меня плохая - и наизусть сигнатуры я никогда не помню, всегда смотрю :)
-
Но подумав, я понимаю, что никогда не сталкивался с ошибкой, которую это бы предотвратило.
Предполагалось, что повысится читаемость, ясность и исключится возможно путать аргументы. В php не путать параметры без справки просто нереально, но он не типизированный.
P.S Это всего лишь заметки. Я стараюсь делать подобные для размышлений.
-
Но тогда Вы должны начать с фиксации ошибок, которые могли бы быть устранены компилятором языка. Которые возникают на практике.
Вот, например, обзывать параметры процедур в точке вызова мне, на первый взгляд, нравится. Но подумав, я понимаю, что никогда не сталкивался с ошибкой, которую это бы предотвратило. А память, например, у меня плохая - и наизусть сигнатуры я никогда не помню, всегда смотрю :)
В 91-92 году я писал на С++ в среде Турбо С++ первую свою достаточно большую программу. И мечтал об инструменте, который бы снял часть заботы с моей башки именно в смысле сигнатур функций. Функций было сотни две, и изменение одной сигнатуры требовало выявить все вызовы этой функции в паре десятков файлов. Хотя память тогда у меня была "лошадиная", и я помнил, где и зачем я ее вызывал. Но необходимость ВРУЧНУЮ лазить по файлам меня сильно доставала.
Вот тогда я впервые задумался, что инструмент подобные операции должон автоматически выполнять.
-
В 91-92 году я писал на С++ в среде Турбо С++ первую свою достаточно большую программу. И мечтал об инструменте, который бы снял часть заботы с моей башки именно в смысле сигнатур функций. Функций было сотни две, и изменение одной сигнатуры требовало выявить все вызовы этой функции в паре десятков файлов. Хотя память тогда у меня была "лошадиная", и я помнил, где и зачем я ее вызывал. Но необходимость ВРУЧНУЮ лазить по файлам меня сильно доставала.
Вот тогда я впервые задумался, что инструмент подобные операции должон автоматически выполнять.
Ну зато теперь с этим проблем нет -- любая современная среда разработки позволяет делать это автоматически.
-
Ну зато теперь с этим проблем нет -- любая современная среда разработки позволяет делать это автоматически.
Не любая... :) ББ пока не позволяет.
2. Прошло 20 лет! Так и помереть можно, не дождавшись... :)
-
Не любая... :) ББ пока не позволяет.
....
А зачем уродовать ББ -послушайте его адептов... там и так все замечательно... это у вас дефект сознания, который вот уже 20 лет дает о себе знать.. ;)
А у них, благодоря тому что они тренеруются ежедневно с этим, с памятью все в порядке ;D
-
Не... В ряде моментов ББ требует доработки (не подсветка синтаксиса, естественно)...
Я б начал с реализации контекстной помощи.
И далее навешивал бы дополнительные удобства для программиста- чтобы рефакторинг было удобно проводить,
unit-тестирование... далее - более индивидуальные удобства...
-
Не... В ряде моментов ББ требует доработки (не подсветка синтаксиса, естественно)...
Я б начал с реализации контекстной помощи.
И далее навешивал бы дополнительные удобства для программиста- чтобы рефакторинг было удобно проводить,
unit-тестирование... далее - более индивидуальные удобства...
Не... (приведу ultimate аргумент адептов) - "есле бы это было действительно нужно, то это было бы давно сделано". ;)
-
У Вас есть человеко-часы - инвестировать в эти фичи? - инвестируйте. Мне что, людей своих вот нечем больше занять? Со временем попутно может и появиться.
Вот как уйма разрабов под тот же Веб работают в обычных редакторах (типа Gedit в Линуксе) - и как-то тоже не страдают.
А тут понятно, что можно докрутить что угодно, было б время и надобность - чего париться-то?
-
У Вас есть человеко-часы - инвестировать в эти фичи? - инвестируйте. Мне что, людей своих вот нечем больше занять? Со временем попутно может и появиться.
Вот как уйма разрабов под тот же Веб работают в обычных редакторах (типа Gedit в Линуксе) - и как-то тоже не страдают.
А тут понятно, что можно докрутить что угодно, было б время и надобность - чего париться-то?
А уйма людей в сельской местности в выгребную яму ходят (по причине отсутствия канализации), но они в отличии от вас не считают, что это нормально и так и должно быть... ;)
-
У меня есть конкретное понимание, насколько наличие доп. фич увеличит производительность разработки. И соотнесение этого с тратой даже 2-3 человеко-месяцев на разработку. И факт в том, что это неоправдано (хотя было бы приятно это получить когда-нибудь, конечно, но только в удобном виде, в парадигме "текст-как-интерфейс", а не в ужасном и устаревшем стиле оконно-формочных студий).
У Вас - только сотрясания воздуха о том, что нет чего-то, что есть в других системах, и высосанные из пальца предположения о том, что это как-то значительно влияет на производительность труда.
При наличии тысяч разрабов лидеры индустрии могут себе позволить нашпиговать продукт массой мелких примочек, вообще не задумываясь о том, насколько это нужно.
Альтернативным сообществам пытаться гоняться за лидерами в этих мелочах, вместо того, чтобы решать реальные задачи, - пустая трата времени.
-
У меня есть конкретное понимание, насколько наличие доп. фич увеличит производительность разработки. И соотнесение этого с тратой даже 2-3 человеко-месяцев на разработку. И факт в том, что это неоправдано (хотя было бы приятно это получить когда-нибудь, конечно, но только в удобном виде, в парадигме "текст-как-интерфейс", а не в ужасном и устаревшем стиле оконно-формочных студий).
Отсутствие этих проверок конечно не играют решающей роли на маленьких проектах, но начинают больно бить по лбу когда проект становится хотя бы средним. Не от хорошей жизни например Ада такая какая есть, это просто необходимо для обеспечения надежности больших систем.
У вас (т.e. той команды, в которой ты участвуешь) есть четкое представление какими темпами будет расти проект? Когда его размер достигнет той самой черты?
-
У меня есть конкретное понимание, насколько наличие доп. фич увеличит производительность разработки. И соотнесение этого с тратой даже 2-3 человеко-месяцев на разработку. И факт в том, что это неоправдано (хотя было бы приятно это получить когда-нибудь, конечно, но только в удобном виде, в парадигме "текст-как-интерфейс", а не в ужасном и устаревшем стиле оконно-формочных студий).
У Вас - только сотрясания воздуха о том, что нет чего-то, что есть в других системах, и высосанные из пальца предположения о том, что это как-то значительно влияет на производительность труда.
При наличии тысяч разрабов лидеры индустрии могут себе позволить нашпиговать продукт массой мелких примочек, вообще не задумываясь о том, насколько это нужно.
Альтернативным сообществам пытаться гоняться за лидерами в этих мелочах, вместо того, чтобы решать реальные задачи, - пустая трата времени.
Чью производительность труда - проф. программеров ? Клал я на это - поскольку не вижу достаточных оснований использования ББ ими, кроме just for fun. Я говорю про ту часть которую ЗНАЮ - это студенты перваши, которые не обучались программированию..и преподавателей...
-
Собственных впечатлений об особенностях проекта при размере свыше сотни тысяч строк у меня действительно нет.
Но под крупную задачу спокойно можно выделить несколько человеко-месяцев на изготовление любой нужной "оснастки". Там можно вложиться в это.
А делать "от балды" "про запас" - смысл?
-
Собственных впечатлений об особенностях проекта при размере свыше сотни тысяч строк у меня действительно нет.
Но под крупную задачу спокойно можно выделить несколько человеко-месяцев на изготовление любой нужной "оснастки". Там можно вложиться в это.
А делать "от балды" "про запас" - смысл?
Это уже другой разговор.. Даже на форуме у вас появляются люди которые хотят изменить ситуацию...вспомните года полтора назад. id_ler кажется...предлагал свои услуги - у меня после чтения той ветки остался негатив к сообществу и Инфо21, Соломенников, что-то пробовал делать...Роман М....- надо просто для начала четко ставить проблему...
-
Понимаю, что смысла нет не имея соответствующего опыта. Можно только либо нафантазировать, либо сделать слепо по аналогии.
А смысл в том (мог бы быть), что если проект писан в стиле маленького проекта и на соответствующем инструментарии, то он очень и очень плохо масштабируется. Т.e. будут болезни роста, а поскольку в инструменте (языке) не предусмотрены механизмы для проектов реально большого размера, придется по сути проект переписывать. И инструмент (язык) перепроектировать. В несколько итераций. Поэтому если предполагается, что проект будет расти, хорошо бы использовать сразу язык адекватный этому самому росту. Если не будет, то да, тут можно и питон взять какой-нибудь.
-
Понимаю, что смысла нет не имея соответствующего опыта. Можно только либо нафантазировать, либо сделать слепо по аналогии.
А смысл в том (мог бы быть), что если проект писан в стиле маленького проекта и на соответствующем инструментарии, то он очень и очень плохо масштабируется. Т.e. будут болезни роста, а поскольку в инструменте (языке) не предусмотрены механизмы для проектов реально большого размера, придется по сути проект переписывать. И инструмент (язык) перепроектировать. В несколько итераций. Поэтому если предполагается, что проект будет расти, хорошо бы использовать сразу язык адекватный этому самому росту. Если не будет, то да, тут можно и питон взять какой-нибудь.
Вы про что говорите про ББ или Идеальный ЯП?
-
Мы скорее говорим про различие схемы разработки растущего проекта при использовании КП и Идеального ЯП :-)
-
Мы скорее говорим про различие схемы разработки растущего проекта при использовании КП и Идеального ЯП :-)
Предлагаю сообщения связанные с развитием и доводкой ББ развести по новым веткам - таки ББ это не язык и тем более не Идеальный ЯП (что бы не говорили его адепты ИМХО)
-
Это уже другой разговор.. Даже на форуме у вас появляются люди которые хотят изменить ситуацию...вспомните года полтора назад. id_ler кажется...предлагал свои услуги - у меня после чтения той ветки остался негатив к сообществу и Инфо21, Соломенников, что-то пробовал делать...Роман М....- надо просто для начала четко ставить проблему...
Золотые слова - надо чётко ставить проблему. Это не так просто. В правильной постановке, неспроста говорят, большая часть решения :)
Лично я, например, не могу в данный момент поставить задачи такого типа, потому что у меня нет проблемы, на которой я бы представил, что там именно нужно. Просто делать "как у других" - это фуфло. Нужен какой-то "пробный камень", на котором это можно сделать. Чтобы это понять, тоже нужно время; так что просто взять и "поставить задачу" не всегда получается.
У нас внутри коллектива есть набор доп. инструментов работы с кодом, но всё это делалось под реальные нужды и постепенно. Когда возникает понимание - можно сразу поставить задачу.
Могу сказать, что ничего похожего на "Студии" от реальных нужд не возникает даже близко. Возникает другое и другим образом реализуемое.
-
Чью производительность труда - проф. программеров ? Клал я на это - поскольку не вижу достаточных оснований использования ББ ими, кроме just for fun. Я говорю про ту часть которую ЗНАЮ - это студенты перваши, которые не обучались программированию..и преподавателей...
Для первашей нормальный препод - не нытик и понявший "фишку" компонентной расширяемой системы - за день-два слепил бы всё, что нужно именно его первашам. В чём проблема, не было ясно никому, с момента Вашего прихода на ОберонКоре.
(Казалось, что Ваши претензии в том, что "всё не так, как у других", с Вами спорили... - потом выяснилось, что Ваши претензии не в этом.)
-
А смысл в том (мог бы быть), что если проект писан в стиле маленького проекта и на соответствующем инструментарии, то он очень и очень плохо масштабируется. Т.e. будут болезни роста, а поскольку в инструменте (языке) не предусмотрены механизмы для проектов реально большого размера, придется по сути проект переписывать. И инструмент (язык) перепроектировать. В несколько итераций. Поэтому если предполагается, что проект будет расти, хорошо бы использовать сразу язык адекватный этому самому росту. Если не будет, то да, тут можно и питон взять какой-нибудь.
Я сомневаюсь, что стоит доводить габариты отдельного приложения до масштаба больше сотни-двух тысяч строк. Дальше - сильно обособленные подсистемы, распределённо взаимодействующие по сетевым протоколам.
Тот же SOA и опыт интеграционных подходов последних лет направлен именно на решение проблемы таким путём.
-
Поэтому если предполагается, что проект будет расти, хорошо бы использовать сразу язык адекватный этому самому росту. Если не будет, то да, тут можно и питон взять какой-нибудь.
Я сомневаюсь, что стоит доводить габариты отдельного приложения до масштаба больше сотни-двух тысяч строк. Дальше - сильно обособленные подсистемы, распределённо взаимодействующие по сетевым протоколам.
Тот же SOA и опыт интеграционных подходов последних лет направлен именно на решение проблемы таким путём.
Все равно code base будет расти... Проблемы роста те же.
-
Для меня идеальный ЯП - который позволяет описывать исследуемую систему без искажений, т.е. писать программу на нем и разбираться в ней - эквивалентно понятию описывать систему и разбираться с системой.
-
Тогда получается язык под задачу, под каждую задачу/систему (или класс задач) пишется свой DSL. И вот тут то и всплывает призрак лиспа… :-)
-
Тогда получается язык под задачу, под каждую задачу/систему (или класс задач) пишется свой DSL. И вот тут то и всплывает призрак лиспа… :-)
не так сурово... :) я человек скромный и понимаю что весь мир мне не обьять... по мне хватает качественной (близкой к общепринятой) реализации базовых понятий алгоритм, переменная, тип, субалгоритм, ветвление, присваивание, циклический процесс.. поддержка ООП . Почти Оберон.. короче . ;)
-
Тогда получается язык под задачу, под каждую задачу/систему (или класс задач) пишется свой DSL. И вот тут то и всплывает призрак лиспа… :-)
Вот-вот.
Осталось только сделать для него возможность менять синтаксис так, как будет удобно для решаемой задачи, не теряя при этом возможности удобной манипуляций с AST...
-
Тогда получается язык под задачу, под каждую задачу/систему (или класс задач) пишется свой DSL. И вот тут то и всплывает призрак лиспа… :-)
Вот-вот.
Осталось только сделать для него возможность менять синтаксис так, как будет удобно для решаемой задачи, не теряя при этом возможности удобной манипуляций с AST...
Но много систем довольно удобно описываются с помощью сущностей которые я привел выше... о (они взяты ведь не из балды - чисто формальный анализ сущностей возникающих при анализе понятия и свойств алгоритма )
-
Осталось только сделать для него возможность менять синтаксис так, как будет удобно для решаемой задачи, не теряя при этом возможности удобной манипуляций с AST...
И каждый начнёт громоздить свою нотацию. И каждому надо будет разбираться и привыкать к чужой.
Вместо общепринятого не-предметно-ориентированного языка и библиотек.
Да с библиотеками тоже надо разбираться, но это сделать проще, чем с языком. Хотя бы потому, что семантика программы, написанной на базе библиотеки, складывается стандартным образом из элементов библиотеки.
А DSL - это полностью custom-ные и элементы, и правила их композиции.
И так сейчас каждый самоделкин изобретает свой скриптовый язычок. С которым потом мучаться другим. Дать орудие "комбинаторного клепания" - будет опять такая лавина... изобретательства... И опять "тормоз прогресса" - вместо тенденции к унификации компонентов инженерного процесса будет очередной взрыв "кустарной раздробленности".
Для творческой работы над новыми задачами надо унифицировать то, с чем возились на предыдущем этапе развития отрасли. А не запускать обратные процессы.
-
Тогда получается язык под задачу, под каждую задачу/систему (или класс задач) пишется свой DSL. И вот тут то и всплывает призрак лиспа… :-)
Так под каждую задачу/систему (или класс задач) и так пишется свой DSL, с помощью штатных средств языка программирования. В этом сущность программирования.
Маниакальное желание менять синтаксис языка мне тоже непонятно.
-
И каждый начнёт громоздить свою нотацию. И каждому надо будет разбираться и привыкать к чужой.
Естественно, ведь идеала нет, а значит нет и удобной для всех нотации.
Если над проектом работает одиночка или тесная команда единомышленников, то проблемы с таким разнообразием не будет -- договорятся в конце концов.
Ну а если проект большой, то внутрифирменный стандарт будет установлен начальством.
-
Хочу поделиться с записями, сделанными на начало прошлого года и содержащими идеи на тему, какими фичами должен обладать ЯП, условно приближенный к идеальному.
-) Все входные аргументы подпрограмм подлежат обязательной проверке assert-подобным выражением.
Чем это принципиально отличается от просто ASSERT'ов? Ну или если не принципиально, то чем это сильно удобнее, чтобы быть в языке в качестве сахара?
-) Именованные параметры.
При вызове подпрограммы должны указываться пары: имя параметра ":" значение.
Можно показать, какие проблемы решает подобный экстримизм?
-) Опциональные параметры.
Параметры, которые могут быть опущены при вызове. При этом в теле подпрограммы будут находиться проверки компилятора на проинициализированность подобных аргументов.
Это частный случай параметров по умолчанию, если в языке есть OPTIONAL (а он должен быть, если вы хотите optional поля).
-) Обязательное присвоение значений переменным при объявлении с необязательной охраной.
Аналогично - непонятно чем не устраивает ASSERT.
-) Соглашения.
Аналогично - непонятно чем не устраивает обычная функция с ASSERT'ом.
-
Ключевое слово - "обязательный". То же самое, что Ткачев для отступов попросил сделать: обязательные. Иначе - ошибка трансляции.
Простой assert можно просто полениться написать. Особенно, если чел не очень опытный... А обязательный - не пропустишь никак... :)
-
Ключевое слово - "обязательный". То же самое, что Ткачев для отступов попросил сделать: обязательные. Иначе - ошибка трансляции.
Простой assert можно просто полениться написать. Особенно, если чел не очень опытный... А обязательный - не пропустишь никак... :)
Не, мне кажется, что в данном случае это не будет работать. Потому что всегда можно написать "ANY" - проще и короче каких-то там непонятных условий (с точки зрения "не очень опытного"). При том, что таких случаев, когда параметры всегда правильные (ANY) не так уж и мало. Я даже рискну сказать, что таких случаев больше половины - при правильном проектировании и когда аргументы достаточно хорошо типизированы. Так что от "обязательности" тут скорее вред, чем польза. В отличие от "правильных" отступов, которые всегда читабельнее "произвольных".
-
Ключевые слова в верхнем регистре (убежден, что это следствие возрастной дальнозоркости Вирта) народу не нравятся. А кто как видит синтаксис идеального ЯП? На что он должен быть похож, уж наверно не на С. На Аду?
Я, хоть и не люблю сишный синтаксис, открыл в нем и положительные стороны, когда разбирался с этим плагином: http://forum.oberoncore.ru/viewtopic.php?p=51289#p51289
Сильно упрощается разбор текста программы: все, что между { } выделяется скобкой. Сюда, кроме всего прочего относятся секции инициализации и лямбда-выражения.
Какие кому нравятся альтенативы, скажем, для лямбда-выражений?
-
Ключевые слова в верхнем регистре (убежден, что это следствие возрастной дальнозоркости Вирта) народу не нравятся. А кто как видит синтаксис идеального ЯП? На что он должен быть похож, уж наверно не на С. На Аду?
На питон. Однозначно :) Ну допилить, может, немного... Тут еще про хаскель говорили, но по мне - он ближе к птичьему :) Хотя привычка, конечно, сильно влияет. А вот питоновский синтаксис - и без привычки нормально смотрится :)
P.S. Кстати, по поводу капса в обероне. Тут вот от Алексея пробегала интересная ссылка: http://www.ethistory.ethz.ch/rueckblicke/departemente/dinfk/bilder/1981_lilith-windows_EN.jpg?hires
-
Ключевые слова в верхнем регистре (убежден, что это следствие возрастной дальнозоркости Вирта) народу не нравятся. А кто как видит синтаксис идеального ЯП? На что он должен быть похож, уж наверно не на С. На Аду?
Мне очень нравится Ада и стиль кодирования там принятый. В частности там не принято в VAR-секции лепить пачку разнотипных переменных в одну строку, как например это бывает в исходниках ББ:
VAR c: TextControllers.Controller; r: TextModels.Reader; beg, end, i: INTEGER; stat: ARRAY 1024 OF CHAR;
Вообще там не принято в одну строчку много всего лепить. Ну и исходники читабельны, да.
Питон… Не знаю. Может быть и да, может быть и нет. Нужно смотреть. Вообще мне представляется, что например присваивание не должно быть таким:
a := bили таким:
a = bмне таки кажется, что оно должно быть таким:
a ← bТехническая возможность сейчас для этого есть.
-
Не забывайте, что большая часть исходников ББ создавалась в первой половине 90-х.
На те мониторы хотелось вместить побольше строчек на экран. И VAR-ами вполне разумно было жертвовать.
-
Я таки заметил что число строчек кода на мониторе у меня не зависит практически от монитора. Как и лет 15 назад у меня на мониторе порядка 40-50 строк кода. При этом что сейчас монитор 19", а был когда-то 14".
Тут не в мониторах дело, а в наших глазах и восприятии, именно они лимитируют число строк кода на экране.
-
Вообще мне представляется, что например присваивание ... должно быть таким:
a ← bТехническая возможность сейчас для этого есть.
А мне представляется иначе: https://sites.google.com/site/purebuilder/#TOC-24 (https://sites.google.com/site/purebuilder/#TOC-24)
-
Присваивание слева-направо - это естественная математическая запись y = f(x)
-
Присваивание слева-направо - это естественная математическая запись y = f(x)
В математике запись y = f(x) -- это не присваивание.
Доказательство: y = f(x) равносильно f(x) = y.
Если хотите со мной поспорить, то включите в список своих оппонентов и Никлауса Вирта ;) (см. статью "Хорошие идеи, взгляд из зазеркалья")
-
Присваивание слева-направо - это естественная математическая запись y = f(x)
Да, но у нас есть оператор = , так что гораздо лучше y <- выражение - последнее, разумеется, всегда можно рассматривать как неименованную функцию...
-
Если хотите со мной поспорить, то включите в список своих оппонентов и Никлауса Вирта ;) (см. статью "Хорошие идеи, взгляд из зазеркалья")
Спорить с вами нет смысла, поскольку (судя по ответу)- вы из "виртухаев"
-
Спорить с вами нет смысла, поскольку (судя по ответу)- вы из "виртухаев"
Если Вы намекаете на то, что я только "смотрю в рот" Никлаусу Вирту, то глубоко ошибаетесь. Я уважаю Никлауса Вирта, но при этом не согласен с ним по некоторым немногочисленным, но концептуально важным вопросам. Например, я не считаю указатели типом данных.
И будьте поаккуратнее в выражениях, пожалуйста.
-
Если Вы намекаете на то, что я только "смотрю в рот" Никлаусу Вирту, то глубоко ошибаетесь.
Я намекаю на то, что вы рассуждения о сущностах общего порядка сводите его (обсуждение сущности) - к обсуждению цитат (формы) - результат такого обсуждения не имеет смысла. В случае с Виртом - это выглядит просто жутко уродливо... Правильный ответ -в математике - значение значка "=" зависит от контекста В. Лаптев имел ввиду, что правую часть присваивания всегда можно представить как ЗНАЧЕНИЕ возвращаемое некоторой (возможно неименованной) функцией.
Например, я не считаю указатели типом данных.
Все зависит от точки зрения на вещи - в информатике (для строго типизированных языков) тип данных является схемой, по которой строятся переменные и определяет набор операций над значениями (алгебру) - то есть ТИП указатель - имеет смысл ,имеет смысл ПЕРЕМЕННАЯ -указатель, имеет смысл ЗНАЧЕНИЕ -указатель.
И будьте поаккуратнее в выражениях, пожалуйста.
Буду - но сильно рассчитываю на взаимность ;)
-
Буду - но сильно рассчитываю на взаимность ;)
Я никогда не обсуждал Вашу личность. В частности, я не называл Вас "виртухаем" или как-то ещё. Так что Ваши опасения по поводу моей невзаимности необоснованы.
-
Буду - но сильно рассчитываю на взаимность ;)
Я никогда не обсуждал Вашу личность. В частности, я не называл Вас "виртухаем" или как-то ещё. Так что Ваши опасения по поводу моей невзаимности необоснованы.
Я говорю , про то что - если застукаете меня за "виртухайством" - бейте нещадно...Короче, хотите быть профессионалом - будьте ими. Хотите ВЫГЛЯДЕТЬ как профессионал - есть адресок в интернете :) где найдутся близкие по духу..
-
если застукаете меня за "виртухайством" - бейте нещадно...
Что я и делаю. ;)
Короче, хотите быть профессионалом - будьте ими. Хотите ВЫГЛЯДЕТЬ как профессионал - есть адресок в интернете :) где найдутся близкие по духу..
Короче, давайте оставим в покое мою "тёмную" личность, которая чего-то там хочет, и вернёмся к обсуждаемому вопросу.
-
Что я и делаю. ;)
:( Я пока не почувствовал , но буду ЛИЧНО ВАМ благодарен если вы "усилите" аргументы... когда живешь достаточно долго.. есть опасность стать маразматиком...- а не хотелось бы...
[/quote]
Короче, давайте оставим в покое мою "тёмную" личность, которая чего-то там хочет, и вернёмся к обсуждаемому вопросу.
[/quote] Вот так и НАДО ;) вот только текущее обсуждение присваивание свелось к тривиальной вещи -выбора ПРАВИЛЬНОГО значка для обозначения оператора...
-
В математике запись y = f(x) -- это не присваивание.
Доказательство: y = f(x) равносильно f(x) = y.
Если хотите со мной поспорить, то включите в список своих оппонентов и Никлауса Вирта ;) (см. статью "Хорошие идеи, взгляд из зазеркалья")
А теперь по существу "доказательства" ;) в математике значек "=" применяется во многих случаях... например... Пусть i=1 , i принадлежит N (элемент множества целых чисел), разве
это равносильно 1=i ? ;)
-
Если уж на то пошло, то в математике, обычно, '=' это таки не бинарный оператор/функция возвращающая булево значение. То есть, если совсем уж буквоедством заниматься, то Вирт должен был бинарный булевый оператор проверки на равенство обозначить как-нибудь иначе.
-
Но вообще, я не вижу смысла в точной подгонке обозначений, тем более что и в математике, которая большая и обширная, обозначения меняют регулярно. В частности f(x) там далеко не всегда записывается именно так :-)
-
Но вообще, я не вижу смысла в точной подгонке обозначений, тем более что и в математике, которая большая и обширная, обозначения меняют регулярно. В частности f(x) там далеко не всегда записывается именно так :-)
Вот именно по этому я и воспринял сообщение Игоря как очередную ДУРАЦКУЮ PR акцию блэкбоксеров ;)
-
Пусть i=1 , i принадлежит N (элемент множества целых чисел), разве
это равносильно 1=i ? ;)
Да, равносильно. В математике и то и другое называется уравнением и имеет один и тот же смысл.
-
Пусть i=1 , i принадлежит N (элемент множества целых чисел), разве
это равносильно 1=i ? ;)
Да, равносильно. В математике и то и другое называется уравнением и имеет один и тот же смысл.
Вопросов больше не имею.. :)
-
Если уж на то пошло, то в математике, обычно, '=' это таки не бинарный оператор/функция возвращающая булево значение.
В программировании мы привыкли, что предикаты могут принимать как значение ИСТИНА, так и значение ЛОЖЬ. В математике знак "=" (а также другие знаки, обозначающие операции сравнения) устанавливает предикат, который всегда декларируется как ИСТИНА. Если на поверку оказывается, что это не так, то такая ситуация в математике квалифицируется как ошибка.
-
Вопросов больше не имею.. :)
Коллеги, Вы правда не понимаете то, что я говорю, или просто прикалываетесь?
-
Не поленился, открыл справочник по математике для школьников (!).
Читаю: Уравнением с одним неизвестным называется равенство f(x) = g(x), в котором требуется найти неизвестную величину x.
У нас: x = i; f(x) = i; g(x) =1
Читаем далее: Преобразования, приводящие к равносильному уравнению, следующие:
- перенос любого члена уравнения из одной части в другую с заменой его знака на противоположный;
- умножение (деление) обоих часей уравнениня на число, отличное от нуля
и т.д.
В нашем случае преобразования имеют вид:
i = 1
i - 1 = 0
-1 = -i
1 = i
PS: Должен сказать, что мне трудно воздержаться от комментариев, но я всё-таки сдержусь. А вообще, хочется спросить, ну и в чём был прикол? Или ваша математика какая-то другая?
-
Наша математика действительно несколько другая. В частности если a = b, то a - b = 0 не всегда правомочно просто потому, что для a и b может быть не определена операция '-' а 0 может просто не существовать.
Вообще странно искать ответы на подобные вопросы в школьных учебниках. В школьных учебниках лгут. И эта ложь необходима.
-
Вообще странно искать ответы на подобные вопросы в школьных учебниках. В школьных учебниках лгут. И эта ложь необходима.
В том то и дело что они НЕ ЛГУТ - просто любая система знаний (из существующих), описывающих реальность - несовершенна (мы не знаем ВСЕГО), но каждой системе можно сопоставить модель (несколько моделей) , которые в свою очередь несовершенны (и без разницы откуда выбираются понятия из эксперимента (реальности) либо из системы аксиом (от балды или из других моделей)). В нашем случае (создание ЯП) - как минимум НЕОБХОДИМ именно СИНТЕЗ существующих моделей с добавлением НОВЫХ свойств , в ЭТОЙ реальности ГЛУПО вообще идеализировать ОПРЕДЕЛЕНИЯ (тут я говорю о них как о форме нарисованной на бумажке)...
-
Наша математика действительно несколько другая. В частности если a = b, то a - b = 0 не всегда правомочно просто потому, что для a и b может быть не определена операция '-' а 0 может просто не существовать.
(выделение моё)
Ну, теперь моя очередь говорить "вопросов больше не имею" ;D
-
Вопросов больше не имею.. :)
Коллеги, Вы правда не понимаете то, что я говорю, или просто прикалываетесь?
Я говорю про то, что i и 1 РАЗЛИЧНЫЕ СУЩНОСТИ i - "контейнер" которому можно сопоставить любое целое число из некоторого набора (множества целых чисел) , а 1 есть элемент этого множества.. Кроме того, в математике "=" используется как для определения сущности (напр. функций), так и как оператор сравнения (сравнивает значение которое хранит сущность с некоторым элементом из допустимого набора (как в вышеприведенном примере...))... (:-\\ вообщето это проходят во всех вузах на первом курсе).
-
В нашем случае (создание ЯП) - как минимум НЕОБХОДИМ именно СИНТЕЗ существующих моделей с добавлением НОВЫХ свойств , в ЭТОЙ реальности ГЛУПО вообще идеализировать ОПРЕДЕЛЕНИЯ (тут я говорю о них как о форме нарисованной на бумажке)...
Чем бы мы не занимались, математика всегда останется математикой.
-
Я говорю про то, что i и 1 РАЗЛИЧНЫЕ СУЩНОСТИ i - "контейнер" которому можно сопоставить любое целое число из некоторого набора (множества целых чисел) , а 1 есть элемент этого множества..
В математике нет переменных ("контейнеров"), но есть абстрактные величины. Индексы, про которые Вы говорите, в математике не меняются во времени, потому что нет понятия процесса и нет состояния процесса. Индексы могут "пробегать" по строкам или столбцам матрицы, но не во времени. См., например, символ Кронекера-Копелли.
Кроме того, в математике "=" используется как для определения сущности (напр. функций), так и как оператор сравнения (сравнивает значение которое хранит сущность с некоторым элементом из допустимого набора (как в вышеприведенном примере...))...
В математике эти два применения знака "=" не различаются.
-
В математике нет переменных ("контейнеров"), но есть абстрактные величины. Индексы, про которые Вы говорите, в математике не меняются во времени, потому что нет понятия процесса и нет состояния процесса. Индексы могут "пробегать" по строкам или столбцам матрицы, но не во времени. См., например, символ Кронекера-Копелли.
Кто это вам сказал ? с каких это пор математика ограничивалась школьной программой (да ище и в кастрированном виде).
В математике эти два применения знака "=" не различаются.
Это Ваша точка зрения ;), почему бы и нет...
-
Вот именно по этому я и воспринял сообщение Игоря как очередную ДУРАЦКУЮ PR акцию блэкбоксеров ;)
Кто-то треплется по форумам, на досуге плюя в потолок, а кто-то как раз "из окопов". Как тот же Игорь Лоскутов, который просто конкретно работает и исходя из этого что-то высказывает.
Веселовский тоже - "из окопов", хоть и не из Оберона "стреляет".
А кто-то только нос воротит, что ему "системщиной воняет" или "артефактами", или чем ещё. Претензии, видимо, в том, что собеседники не хотят переходить на праздную точку зрения, без "праха бытия". И без кучи сдерживающих, консервативных ограничений этого "праха".
-
Кто-то треплется по форумам, на досуге плюя в потолок, а кто-то как раз "из окопов". Как тот же Игорь Лоскутов, который просто конкретно работает и исходя из этого что-то высказывает.
Веселовский тоже - "из окопов", хоть и не из Оберона "стреляет".
А кто-то только нос воротит, что ему "системщиной воняет" или "артефактами", или чем ещё. Претензии, видимо, в том, что собеседники не хотят переходить на праздную точку зрения, без "праха бытия". И без кучи сдерживающих, консервативных ограничений этого "праха".
Да я не из вашего "окопавшегося" мирка ... Илья -а не кто не против вашей "окопной" деятельности - вы мне напоминаете право же одного генерала из романа Войновича про Чонкина -который не представлял себе солдат не умеющих "окапываться" - кстати тот генерал "окапываться умел и любил" :)
Кстати, а с чего вы взяли что мир это большая траншея? -есть мир и за пределами вашего окопанного бастиона.... и он эту точку зрения не поддерживает (см. педсовет) ;D -
это я про образование, про "реальные" суровые задачи - ну даже смешно сравнивать... ;D
-
Я не вкладывал никакой "военизированной" семантики, на самом деле.
Просто обычную рабочую. (Может быть, я ненормальный трудоголик, конечно, со своим рабочим днём с 8 и до 22-23, это и отразилось в лексике).
Серьёзная работа, в моём понимании, это и есть вот этот "окоп", когда нужно совмещать и стратегию, и борьбу с кучей сваливающихся текущих проблем, и находить баланс между этим.. Просто такая работа очень сильно противоположна праздным размышлениям на досуге.
-
Я не вкладывал никакой "военизированной" семантики, на самом деле.
Просто обычную рабочую. (Может быть, я ненормальный трудоголик, конечно, со своим рабочим днём с 8 и до 22-23, это и отразилось в лексике).
Серьёзная работа, в моём понимании, это и есть вот этот "окоп", когда нужно совмещать и стратегию, и борьбу с кучей сваливающихся текущих проблем, и находить баланс между этим.. Просто такая работа очень сильно противоположна праздным размышлениям на досуге.
Илья :) я прекрасно понял вас - просто я пытаюсь навести мосты между "окопавшимися" и внешним миром...
-
Я не окопался, я в танке! ::)
-
Я не окопался, я в танке! ::)
Тогда это не к вам (господи страшно то как :) )