Сообщение Re[9]: Никогда не недооценивайте силу по умолчанию от 16.09.2022 6:24
Изменено 16.09.2022 6:29 vsb
Re[9]: Никогда не недооценивайте силу по умолчанию
Здравствуйте, netch80, Вы писали:
vsb>>Можно делить на ошибки и предупреждения, но в релизном коде не должно быть ни тех, ни других. Хотя я бы вообще предложил кардинальный подход — не делить на ошибки и предупреждения, а генерировать в отладочном режиме бинарник, даже если встречаются ошибки, которые можно локализовать. Я давным давно писал на жава в эклипсе, вот там такая фича была. И это было очень удобно. Не дописал функцию, и ладно. Если туда управление придёт, то вместо недокомпилированного кода вылетит ошибка.
N>Прикольно. Для этого требовался особый JDK, или Eclipse внутри себя это делал?
У эклипса был свой компилятор. Ну и сейчас есть, наверное. Вроде как его даже к идее можно как-то присобачить, но я не пробовал.
vsb>>Что касается автоматической генерации кода, на мой взгляд правильно требовать от генератора генерировать нормальный код, а не подстраивать язык под него.
N>Вот в том, что такое "нормальный" код, тут и есть засада. Go не пропускает, например, код с неприменённым импортом. Генератор должен следить за тем, вызвал он что-то по этому импорту или нет? Я думаю, что не должен. Даже если по умолчанию это полезно (Go рассчитывался на написание кода низкоуровневыми ширнармассами, и жёсткий контроль имеет смысл), опция компиляции для убирания этого (вписанная в исходник) была бы очень полезна.
Я согласен, что во время разработки можно пропускать максимально много ошибок, пока компилятор уверен, что программа остаётся адекватной. И эта особенность го мне тоже не нравится. Лишь бы была внятная
N>Не обязательно для функций.
N>r = 0;
N>... какие-то действия в цикле... {
N> ++r;
N>}
N>Если оно умеет подсчитать, что r достигает 2000, и 1 байта мало, нужно два — это и есть второй вариант.
Это интересный вопрос, что делать с int-ами. В целом я бы хотел, чтобы по умолчанию оно работало автоматически, сначала 4 байта (по-моему меньше — смысла нет), если переполнились, то автоматически превращало в 8, потом в безразмерное целое. Но надо подумать над этим вопросом. Понятно, что если язык претендует на хоть какую-то производительность, такое может быть не реализуемо.
vsb>>>>Все типы локальных переменных выводятся и это не опционально.
N>>>Ну да, ещё скажи, что ты не можешь сказать "int x" для локальной переменной, только "var x"
N>>>Непонятно, что ты имел в виду на самом деле, но сказано безнадёжно коряво. Перефразируй.
vsb>>Не очень понял, что не понятно. У нас ведь в гипотетическом языке нет ни var ни int. У нас есть только x = 1 или x = get_int_value(). Иными словами типы всех локальных переменных выводятся автоматически и отказаться от этого нельзя. Максимум — добавить каст в инициализирующее выражение, чтобы привести его к нужному типу.
N>Значит, таки типы есть, раз касты есть. Но зачем тогда запрещать тип для переменной?
Типы есть, в том числе типы по текущей концепции обязательны у функций. Зачем запрещать? Потому, что два способа написать одно и то же это плохо. И когда нет формального способа решать, какой способ лучше, это плохо. Любая отсылка к какому-нибудь эстетическому чувству программиста, мол он сам выберет — ставить тип или нет, это плохо, это ненадёжно. Можно считать эту концепцию антиподом философии Perl ("всегда есть более одного способа написать это").
Я эту концепцию беру не с потолка, а с весьма распространённой практики использования стилей кодирования, линтеров и тд, которые порой бывают весьма строги. И как раз приводят исходный язык в подобное состояние, запрещая в нём все вольности, причём запрещая в максимально формальном стиле, линтер ведь штука механическая.
Если вернуться к int-ам в этой концепции, то можно добавить для них возможность указания нестандартного размера. К примеру по умолчанию int32, но если это умолчание не подходит, то можно указать другой размер (при этом int32 указать нельзя). Хотя я бы предпочёл для этого юз-кейса синтаксис вроде x = (int8) 0, от кастов-то всяко никуда не деться.
vsb>>Можно делить на ошибки и предупреждения, но в релизном коде не должно быть ни тех, ни других. Хотя я бы вообще предложил кардинальный подход — не делить на ошибки и предупреждения, а генерировать в отладочном режиме бинарник, даже если встречаются ошибки, которые можно локализовать. Я давным давно писал на жава в эклипсе, вот там такая фича была. И это было очень удобно. Не дописал функцию, и ладно. Если туда управление придёт, то вместо недокомпилированного кода вылетит ошибка.
N>Прикольно. Для этого требовался особый JDK, или Eclipse внутри себя это делал?
У эклипса был свой компилятор. Ну и сейчас есть, наверное. Вроде как его даже к идее можно как-то присобачить, но я не пробовал.
vsb>>Что касается автоматической генерации кода, на мой взгляд правильно требовать от генератора генерировать нормальный код, а не подстраивать язык под него.
N>Вот в том, что такое "нормальный" код, тут и есть засада. Go не пропускает, например, код с неприменённым импортом. Генератор должен следить за тем, вызвал он что-то по этому импорту или нет? Я думаю, что не должен. Даже если по умолчанию это полезно (Go рассчитывался на написание кода низкоуровневыми ширнармассами, и жёсткий контроль имеет смысл), опция компиляции для убирания этого (вписанная в исходник) была бы очень полезна.
Я согласен, что во время разработки можно пропускать максимально много ошибок, пока компилятор уверен, что программа остаётся адекватной. И эта особенность го мне тоже не нравится. Лишь бы была внятная
N>Не обязательно для функций.
N>r = 0;
N>... какие-то действия в цикле... {
N> ++r;
N>}
N>Если оно умеет подсчитать, что r достигает 2000, и 1 байта мало, нужно два — это и есть второй вариант.
Это интересный вопрос, что делать с int-ами. В целом я бы хотел, чтобы по умолчанию оно работало автоматически, сначала 4 байта (по-моему меньше — смысла нет), если переполнились, то автоматически превращало в 8, потом в безразмерное целое. Но надо подумать над этим вопросом. Понятно, что если язык претендует на хоть какую-то производительность, такое может быть не реализуемо.
vsb>>>>Все типы локальных переменных выводятся и это не опционально.
N>>>Ну да, ещё скажи, что ты не можешь сказать "int x" для локальной переменной, только "var x"
N>>>Непонятно, что ты имел в виду на самом деле, но сказано безнадёжно коряво. Перефразируй.
vsb>>Не очень понял, что не понятно. У нас ведь в гипотетическом языке нет ни var ни int. У нас есть только x = 1 или x = get_int_value(). Иными словами типы всех локальных переменных выводятся автоматически и отказаться от этого нельзя. Максимум — добавить каст в инициализирующее выражение, чтобы привести его к нужному типу.
N>Значит, таки типы есть, раз касты есть. Но зачем тогда запрещать тип для переменной?
Типы есть, в том числе типы по текущей концепции обязательны у функций. Зачем запрещать? Потому, что два способа написать одно и то же это плохо. И когда нет формального способа решать, какой способ лучше, это плохо. Любая отсылка к какому-нибудь эстетическому чувству программиста, мол он сам выберет — ставить тип или нет, это плохо, это ненадёжно. Можно считать эту концепцию антиподом философии Perl ("всегда есть более одного способа написать это").
Я эту концепцию беру не с потолка, а с весьма распространённой практики использования стилей кодирования, линтеров и тд, которые порой бывают весьма строги. И как раз приводят исходный язык в подобное состояние, запрещая в нём все вольности, причём запрещая в максимально формальном стиле, линтер ведь штука механическая.
Если вернуться к int-ам в этой концепции, то можно добавить для них возможность указания нестандартного размера. К примеру по умолчанию int32, но если это умолчание не подходит, то можно указать другой размер (при этом int32 указать нельзя). Хотя я бы предпочёл для этого юз-кейса синтаксис вроде x = (int8) 0, от кастов-то всяко никуда не деться.
Re[9]: Никогда не недооценивайте силу по умолчанию
Здравствуйте, netch80, Вы писали:
vsb>>Можно делить на ошибки и предупреждения, но в релизном коде не должно быть ни тех, ни других. Хотя я бы вообще предложил кардинальный подход — не делить на ошибки и предупреждения, а генерировать в отладочном режиме бинарник, даже если встречаются ошибки, которые можно локализовать. Я давным давно писал на жава в эклипсе, вот там такая фича была. И это было очень удобно. Не дописал функцию, и ладно. Если туда управление придёт, то вместо недокомпилированного кода вылетит ошибка.
N>Прикольно. Для этого требовался особый JDK, или Eclipse внутри себя это делал?
У эклипса был свой компилятор. Ну и сейчас есть, наверное. Вроде как его даже к идее можно как-то присобачить, но я не пробовал.
vsb>>Что касается автоматической генерации кода, на мой взгляд правильно требовать от генератора генерировать нормальный код, а не подстраивать язык под него.
N>Вот в том, что такое "нормальный" код, тут и есть засада. Go не пропускает, например, код с неприменённым импортом. Генератор должен следить за тем, вызвал он что-то по этому импорту или нет? Я думаю, что не должен. Даже если по умолчанию это полезно (Go рассчитывался на написание кода низкоуровневыми ширнармассами, и жёсткий контроль имеет смысл), опция компиляции для убирания этого (вписанная в исходник) была бы очень полезна.
Я согласен, что во время разработки можно пропускать максимально много ошибок, пока компилятор уверен, что программа остаётся адекватной. И эта особенность го мне тоже не нравится.
N>Не обязательно для функций.
N>r = 0;
N>... какие-то действия в цикле... {
N> ++r;
N>}
N>Если оно умеет подсчитать, что r достигает 2000, и 1 байта мало, нужно два — это и есть второй вариант.
Это интересный вопрос, что делать с int-ами. В целом я бы хотел, чтобы по умолчанию оно работало автоматически, сначала 4 байта (по-моему меньше — смысла нет), если переполнились, то автоматически превращало в 8, потом в безразмерное целое. Но надо подумать над этим вопросом. Понятно, что если язык претендует на хоть какую-то производительность, такое может быть не реализуемо.
vsb>>>>Все типы локальных переменных выводятся и это не опционально.
N>>>Ну да, ещё скажи, что ты не можешь сказать "int x" для локальной переменной, только "var x"
N>>>Непонятно, что ты имел в виду на самом деле, но сказано безнадёжно коряво. Перефразируй.
vsb>>Не очень понял, что не понятно. У нас ведь в гипотетическом языке нет ни var ни int. У нас есть только x = 1 или x = get_int_value(). Иными словами типы всех локальных переменных выводятся автоматически и отказаться от этого нельзя. Максимум — добавить каст в инициализирующее выражение, чтобы привести его к нужному типу.
N>Значит, таки типы есть, раз касты есть. Но зачем тогда запрещать тип для переменной?
Типы есть, в том числе типы по текущей концепции обязательны у функций. Зачем запрещать? Потому, что два способа написать одно и то же это плохо. И когда нет формального способа решать, какой способ лучше, это плохо. Любая отсылка к какому-нибудь эстетическому чувству программиста, мол он сам выберет — ставить тип или нет, это плохо, это ненадёжно. Можно считать эту концепцию антиподом философии Perl ("всегда есть более одного способа написать это").
Я эту концепцию беру не с потолка, а с весьма распространённой практики использования стилей кодирования, линтеров и тд, которые порой бывают весьма строги. И как раз приводят исходный язык в подобное состояние, запрещая в нём все вольности, причём запрещая в максимально формальном стиле, линтер ведь штука механическая.
Если вернуться к int-ам в этой концепции, то можно добавить для них возможность указания нестандартного размера. К примеру по умолчанию int32, но если это умолчание не подходит, то можно указать другой размер (при этом int32 указать нельзя). Хотя я бы предпочёл для этого юз-кейса синтаксис вроде x = (int8) 0, от кастов-то всяко никуда не деться.
vsb>>Можно делить на ошибки и предупреждения, но в релизном коде не должно быть ни тех, ни других. Хотя я бы вообще предложил кардинальный подход — не делить на ошибки и предупреждения, а генерировать в отладочном режиме бинарник, даже если встречаются ошибки, которые можно локализовать. Я давным давно писал на жава в эклипсе, вот там такая фича была. И это было очень удобно. Не дописал функцию, и ладно. Если туда управление придёт, то вместо недокомпилированного кода вылетит ошибка.
N>Прикольно. Для этого требовался особый JDK, или Eclipse внутри себя это делал?
У эклипса был свой компилятор. Ну и сейчас есть, наверное. Вроде как его даже к идее можно как-то присобачить, но я не пробовал.
vsb>>Что касается автоматической генерации кода, на мой взгляд правильно требовать от генератора генерировать нормальный код, а не подстраивать язык под него.
N>Вот в том, что такое "нормальный" код, тут и есть засада. Go не пропускает, например, код с неприменённым импортом. Генератор должен следить за тем, вызвал он что-то по этому импорту или нет? Я думаю, что не должен. Даже если по умолчанию это полезно (Go рассчитывался на написание кода низкоуровневыми ширнармассами, и жёсткий контроль имеет смысл), опция компиляции для убирания этого (вписанная в исходник) была бы очень полезна.
Я согласен, что во время разработки можно пропускать максимально много ошибок, пока компилятор уверен, что программа остаётся адекватной. И эта особенность го мне тоже не нравится.
N>Не обязательно для функций.
N>r = 0;
N>... какие-то действия в цикле... {
N> ++r;
N>}
N>Если оно умеет подсчитать, что r достигает 2000, и 1 байта мало, нужно два — это и есть второй вариант.
Это интересный вопрос, что делать с int-ами. В целом я бы хотел, чтобы по умолчанию оно работало автоматически, сначала 4 байта (по-моему меньше — смысла нет), если переполнились, то автоматически превращало в 8, потом в безразмерное целое. Но надо подумать над этим вопросом. Понятно, что если язык претендует на хоть какую-то производительность, такое может быть не реализуемо.
vsb>>>>Все типы локальных переменных выводятся и это не опционально.
N>>>Ну да, ещё скажи, что ты не можешь сказать "int x" для локальной переменной, только "var x"
N>>>Непонятно, что ты имел в виду на самом деле, но сказано безнадёжно коряво. Перефразируй.
vsb>>Не очень понял, что не понятно. У нас ведь в гипотетическом языке нет ни var ни int. У нас есть только x = 1 или x = get_int_value(). Иными словами типы всех локальных переменных выводятся автоматически и отказаться от этого нельзя. Максимум — добавить каст в инициализирующее выражение, чтобы привести его к нужному типу.
N>Значит, таки типы есть, раз касты есть. Но зачем тогда запрещать тип для переменной?
Типы есть, в том числе типы по текущей концепции обязательны у функций. Зачем запрещать? Потому, что два способа написать одно и то же это плохо. И когда нет формального способа решать, какой способ лучше, это плохо. Любая отсылка к какому-нибудь эстетическому чувству программиста, мол он сам выберет — ставить тип или нет, это плохо, это ненадёжно. Можно считать эту концепцию антиподом философии Perl ("всегда есть более одного способа написать это").
Я эту концепцию беру не с потолка, а с весьма распространённой практики использования стилей кодирования, линтеров и тд, которые порой бывают весьма строги. И как раз приводят исходный язык в подобное состояние, запрещая в нём все вольности, причём запрещая в максимально формальном стиле, линтер ведь штука механическая.
Если вернуться к int-ам в этой концепции, то можно добавить для них возможность указания нестандартного размера. К примеру по умолчанию int32, но если это умолчание не подходит, то можно указать другой размер (при этом int32 указать нельзя). Хотя я бы предпочёл для этого юз-кейса синтаксис вроде x = (int8) 0, от кастов-то всяко никуда не деться.