Здравствуйте, AlexRK, Вы писали:
ARK>Не придирки ради, а токмо интереса для: какие, например, исключения и ограничения в паскале (а в Rust/Go их нет)? Определения переменных в секции "var"?
Совершенно странный ввод-вывод, который нельзя выразить в виде обычных функций/процедур, например.
C>>Но даже если на это закрыть глаза, то в стандартном Паскале нет проверки численных переполнений, хотя есть ограниченные типы. В некоторых реализациях эти проверки таки добавили. ARK>По-моему, это было только в самой первой версии.
Это в ИСО-шном стандарте так.
ARK>ИМХО, когда сейчас говорят о паскале, имеют в виду что-то более современное (хотя бы трубопаскаль, или фри).
Но они все значительно сложнее.
Здравствуйте, AlexRK, Вы писали:
N>>Не завели новый тип, воспользовались при определении переменной просто массивом — получили совместимость. ARK>Совместимость, идущую вразрез с духом golang, ибо алиаса в явном виде нет.
У него как раз определено, что если не сказано явно о несовместимости — то есть совместимость.
Можно плакаться в целом на такой подход, но он тут реализован достаточно неплохо.
ARK>>> Не уверен, что эти фичи являются показателем строгости типизации. ИМХО, строгая типизация — это когда нет неявных преобразований между типами разной структуры. И паскаль этому определению вполне соответствует. N>>Непрактично. N>>Лучше так: строгая типизация — это когда нет неявных преобразований, которые явно запрещены, могут потерять данные или принципиально изменить семантику операций со значениями. ARK>Не вижу, чем это определение лучше. Точнее, оно гораздо хуже, потому что добавляет еще несколько связанных трудноформализуемых (если вообще формализуемых) определений.
Зато полезнее, потому что определяет важность именно сохранности данных и корректности операций с ними.
А ваше определение противоречит вашему же подходу с примерами: два типа array[1..9] of integer, очевидно, одной структуры — значит, неявное преобразование возможно и желательно.
N>>Например, в нём нет запрета неявной конверсии int во float (по Borland; real — по Вирту), хотя она может дать потерю данных.
ARK>https://ideone.com/Vctxcc
ARK>program ideone; ARK>var ARK> A: Real; ARK> B: Integer; ARK>begin ARK> A := 33; ARK> B := A; ARK> Write(B); ARK>end.
Вы уже второй раз в этом треде читаете полностью противоположное тому, что я писал, и приводите пример на это противоположное прочтение.
Вы уже запланировали отпуск? По-моему, пора.
Здравствуйте, AlexRK, Вы писали:
ARK>Здравствуйте, Cyberax, Вы писали:
C>>Нужно наоборот — присвоить integer к float'y. При этом возможна потеря точности, если integer достаточно большой.
ARK>А! Пардон, я неправильно прочел. Да, наоборот можно. Но это почти везде можно.
Go — нельзя.
package main
func main() {
var a int = 33
var b float32
b = a
}
не скомпилируется.
(Исключение — для констант.)
Там даже конверсия int32->int неявная недопустима, хотя они одного размера.
(С другой стороны, сделав этот запрет, они не озаботились качественными операторами/функциями конверсии с контролем переполнений и потерь точности, выбором режима округления и т.п.
Увы, реализация только половинная. Но направление в целом — взято правильно.)
LVV>В российских школах — как второй. LVV>Или параллельно с русскоязычным.
А есть хоть один нормальный русскоязычный ЯП?
LVV>Даже Константин Поляков, который преподает в родной питерской школе в профильном классе, высказался у себя на сайте, что первый язык должен быть русский.
Даже! Кто такой, почему мы должны ему безоговорочно верить?
LVV>В своем учебнике по информатике для профильных классов он так и написал — параллельно. LVV>Слева — КуМир, справа — Паскаль.
Это тот самый кумир, который алг нач цел вещ все кон? За что?
алг qSort(аргрез целтаб A[1:5], арг цел iStart, iEnd)
нач
цел L, R, c, X
если iStart >= iEnd то выход все
L:= iStart; R:= iEnd;
X:= A[div(L+R,2)]
нц пока L <= R
нц пока A[L] < X; L:= L+1 кц
нц пока A[R] > X; R:= R-1 кц
если L <= R то
c:= A[L]; A[L]:= A[R]; A[R]:= c
L:= L+1; R:= R-1
все
кц
qSort(A, iStart, R)
qSort(A, L, iEnd)
кон
За что вы так ненавидите детей?
LVV>Если кто скажет, что они развиваются, а паскаль — нет, то это ерунда. LVV>Смотрите Оберон и Зоннон.
Здесь мы на них смотрели. Много раз.
LVV>Фактически — нет конторы, которая поддерживала бы паскаль на рынке.
«Паскаль не развивается — это ерунда», но одновременно «нет конторы, которая поддерживала бы паскаль»
Здравствуйте, netch80, Вы писали:
ARK>>>> Не уверен, что эти фичи являются показателем строгости типизации. ИМХО, строгая типизация — это когда нет неявных преобразований между типами разной структуры. И паскаль этому определению вполне соответствует. N>>>Лучше так: строгая типизация — это когда нет неявных преобразований, которые явно запрещены, могут потерять данные или принципиально изменить семантику операций со значениями. ARK>>Не вижу, чем это определение лучше. Точнее, оно гораздо хуже, потому что добавляет еще несколько связанных трудноформализуемых (если вообще формализуемых) определений. N>Зато полезнее, потому что определяет важность именно сохранности данных и корректности операций с ними.
Опять отсылки к малоформализуемым вещам — "сохранность данных", "корректность операций".
У меня четкое формальное определение, а у вас что-то аморфное, что и на определение, ИМХО, не особо тянет. Интересно, для чего ваш вариант полезнее, для победы в форумных спорах?
N>А ваше определение противоречит вашему же подходу с примерами: два типа array[1..9] of integer, очевидно, одной структуры — значит, неявное преобразование возможно и желательно.
1) Мое определение ничему не противоречит.
2) Пример с массивами не мой.
3) Да, неявное преобразование в данном случае возможно, и это не противоречит сильной типизации. Не стоит путать теплое с жидким, то есть сильную типизацию с номинативной.
N>Вы уже второй раз в этом треде читаете полностью противоположное тому, что я писал, и приводите пример на это противоположное прочтение.
А где первый раз был?
N>Вы уже запланировали отпуск? По-моему, пора.
Здравствуйте, AlexRK, Вы писали:
ARK>Опять отсылки к малоформализуемым вещам — "сохранность данных", "корректность операций".
Это как раз в разы формализуемее.
Сохранность данных: у типа A есть множество значений V(A), у B есть множество значений V(B).
Если ∃a: a∈V(A) ∧ a∉V(B), то конверсия A -> B может давать потерю данных, и должна быть запрещена в неявном виде.
Банальный пример: int32 и int16. +32768 входит в множество значений int32, но не int16. Преобразование возможно, но явной операцией, для которой желательно задание, что делать в случае реального выхода за границы (варианты: проигнорировать с оставлением младших разрядов, выбрать ближайшее представимое значение, сгенерировать исключение, выставить заданную флаговую переменную в 1...)
Более хитрый пример: 16777216 и 16777218 входят в множество значений int32 и float32, но 16777217 входит в int32, но не во float32 (и при преобразовании будет округлено до одного из двух соседей). Преобразование возможно, но явной операцией (для которой желательно иметь возможность задать режим округления).
Сохранение семантики: если A(), B() это конверсии к соотв. типам, и A(B(x) op B(y)) != x op y для некоторой op и некоторых a, b ∈ A, то автоконверсия A->B недопустима. (Аналогичное может быть для операций любой арности и разных типов, но облом всё расписывать.)
Простейший пример: если "+" складывает числа, но конкатенирует строки, то нельзя допускать автоконверсии числа в строку, если может получиться, что 3+5 == 8, но '3'+5 == 3+'5' == '35'.
(В Perl этой ловушки избежали: там "." для конкатенации. В JavaScript — наступили с разгону.)
Для встроенных типов всё это должен обеспечивать язык. Для определяемых программистом — задача на этом программисте, но язык должен не мешать этому.
ARK>У меня четкое формальное определение, а у вас что-то аморфное, что и на определение, ИМХО, не особо тянет. Интересно, для чего ваш вариант полезнее, для победы в форумных спорах?
Моё — для практики применения в языках.
Это ваше — для форумных споров: чОткая формальность с исчезающе малой практической применимостью.
N>>А ваше определение противоречит вашему же подходу с примерами: два типа array[1..9] of integer, очевидно, одной структуры — значит, неявное преобразование возможно и желательно.
ARK>1) Мое определение ничему не противоречит. ARK>2) Пример с массивами не мой.
.
ARK>3) Да, неявное преобразование в данном случае возможно, и это не противоречит сильной типизации. Не стоит путать теплое с жидким, то есть сильную типизацию с номинативной.
Я и не путаю. Это вы меня с кем-то путаете.
N>>Вы уже второй раз в этом треде читаете полностью противоположное тому, что я писал, и приводите пример на это противоположное прочтение. ARK>А где первый раз был?
Здравствуйте, netch80, Вы писали:
N>Сохранность данных: у типа A есть множество значений V(A), у B есть множество значений V(B). N>Если ∃a: a∈V(A) ∧ a∉V(B), то конверсия A -> B может давать потерю данных, и должна быть запрещена в неявном виде. N>Сохранение семантики: если A(), B() это конверсии к соотв. типам, и A(B(x) op B(y)) != x op y для некоторой op и некоторых a, b ∈ A, то автоконверсия A->B недопустима. (Аналогичное может быть для операций любой арности и разных типов, но облом всё расписывать.)
По-моему, это все покрывается одним моим определением — типы с разной структурой не могут быть присвоены друг другу. ИМХО, этого достаточно.
ARK>>У меня четкое формальное определение, а у вас что-то аморфное, что и на определение, ИМХО, не особо тянет. Интересно, для чего ваш вариант полезнее, для победы в форумных спорах? N>Моё — для практики применения в языках. N>Это ваше — для форумных споров: чОткая формальность с исчезающе малой практической применимостью.
N>>>Вы уже второй раз в этом треде читаете полностью противоположное тому, что я писал, и приводите пример на это противоположное прочтение. ARK>>А где первый раз был? N>В 7475483.
ARK>>А то, понимаешь, "читаете полностью противоположное тому, что я писал, и приводите пример на это противоположное прочтение" (с) N>Там было рядом с нужным, а вы полностью противоположное находите.
Понял. Когда специально написано БОЛЬШИМИ буквами "можно ли присвоить НАПРЯМУЮ" и при этом дан ответ на какой-то совершенно иной вопрос — это "рядом с нужным". Ясно.
Паскаль устарел еще в конце 90ых, потому что оставался 16тибитным
когда его сделали 32битным, то почему-то решили, что это среда для гуя
гуй вяло поделали для десктопа некоторое время, потом забили, перешли на веб
в итоге остался паскаль ни для high performance, ни для гуя, ни для чего
ну, можно ему в универе учить. а зачем? потом все равно что-то другое учить придется
Здравствуйте, AlexRK, Вы писали:
N>>Сохранность данных: у типа A есть множество значений V(A), у B есть множество значений V(B). N>>Если ∃a: a∈V(A) ∧ a∉V(B), то конверсия A -> B может давать потерю данных, и должна быть запрещена в неявном виде. N>>Сохранение семантики: если A(), B() это конверсии к соотв. типам, и A(B(x) op B(y)) != x op y для некоторой op и некоторых a, b ∈ A, то автоконверсия A->B недопустима. (Аналогичное может быть для операций любой арности и разных типов, но облом всё расписывать.)
ARK>По-моему, это все покрывается одним моим определением — типы с разной структурой не могут быть присвоены друг другу. ИМХО, этого достаточно.
Нет, конечно. Вот я возьму и разложу float на части:
и определю конверсию между ними. Соответствие 1:1. Структура разная. Набор представимых значений один и тот же (множества значений взаимно изоморфны, при одинаковой целевой интерпретации).
Надо запрещать имплицитные преобразования? Очевидно, нет.
А если я ограничу набор значений в порядке и мантиссе, то смогу и с родным float обеспечить взаимозаменяемость (а иначе ограничу — с double). И тоже можно обеспечить это через конструкторы и операторы типа (для C++).
N>>>>Вы уже второй раз в этом треде читаете полностью противоположное тому, что я писал, и приводите пример на это противоположное прочтение. ARK>>>А где первый раз был? N>>В 7475483. ARK>Я там просто привел пример того, что есть еще и неявные присваивания без алиасов.
Вы там не определили новый тип, а применили существующий — вот вам и результат.
Объявление переменной не вводит новый тип, это естественно, иначе бы написав
var a int
var b int
нельзя было бы их друг другу присвоить. Это уже запредельный эффект, и его правильно не допустили.
ARK>Понял. Когда специально написано БОЛЬШИМИ буквами "можно ли присвоить НАПРЯМУЮ" и при этом дан ответ на какой-то совершенно иной вопрос — это "рядом с нужным". Ясно.
Нет, вы ничего не поняли. Но рекомендую на этом не циклиться, а вернуться к более актуальной части.
Здравствуйте, netch80, Вы писали:
N>Нет, конечно. Вот я возьму и разложу float на части: N>и определю конверсию между ними. Соответствие 1:1. Структура разная. Набор представимых значений один и тот же (множества значений взаимно изоморфны, при одинаковой целевой интерпретации). N>Надо запрещать имплицитные преобразования? Очевидно, нет.
Надо.
N>А если я ограничу набор значений в порядке и мантиссе, то смогу и с родным float обеспечить взаимозаменяемость (а иначе ограничу — с double). И тоже можно обеспечить это через конструкторы и операторы типа (для C++).
Это уже не сильная типизация.
Кстати, а если я объявлю два типа — meter и kilometer, у обоих в базе int, «операций» в текущем модуле нет. Всё, можно присваивать друг другу?
ARK>>Понял. Когда специально написано БОЛЬШИМИ буквами "можно ли присвоить НАПРЯМУЮ" и при этом дан ответ на какой-то совершенно иной вопрос — это "рядом с нужным". Ясно. N>Нет, вы ничего не поняли. Но рекомендую на этом не циклиться, а вернуться к более актуальной части.
Здравствуйте, __kot2, Вы писали:
__>ну, можно ему в универе учить. а зачем? потом все равно что-то другое учить придется
Так любое другое учить будет проще, а это "другое" может оказаться очень разным.
Здравствуйте, AlexRK, Вы писали:
N>>Нет, конечно. Вот я возьму и разложу float на части: N>>и определю конверсию между ними. Соответствие 1:1. Структура разная. Набор представимых значений один и тот же (множества значений взаимно изоморфны, при одинаковой целевой интерпретации). N>>Надо запрещать имплицитные преобразования? Очевидно, нет.
ARK>Надо.
Ну, если вы хотите поиграться в кривые теории и поспорить на форуме, то да, надо.
Если же нужен практически полезный результат — то не надо.
N>>А если я ограничу набор значений в порядке и мантиссе, то смогу и с родным float обеспечить взаимозаменяемость (а иначе ограничу — с double). И тоже можно обеспечить это через конструкторы и операторы типа (для C++). ARK>Это уже не сильная типизация.
Только в ваших фантазиях.
ARK>Кстати, а если я объявлю два типа — meter и kilometer, у обоих в базе int, «операций» в текущем модуле нет. Всё, можно присваивать друг другу?
Не понимаю, что такое "<операции> в текущем модуле", но я объяснял в предыдущих примерах.
type meter = new int;
type kilometer = new int;
всё, прямая конверсия запрещена.
Если не сделали такого — сами себе буратино, контролируйте операции вручную.
OK, такого в языке нет — берём C++:
struct meter {
int value;
explicit meter(int nv) { value = nv; }
};
struct kilometer {
int value;
explicit kilometer(int nv) { value = nv; }
};
конверсии нет.
Но можно попросить:
struct kilometer {
int value;
explicit kilometer(int nv) { value = nv; }
operator meter() const {
int r;
if (__builtin_mul_overflow(value, 1000, &r)) {
throw overflow_exception();
}
return meter(r);
}
bool to_meter_checked(meter& target) const {
return __builtin_mul_overflow(value, 1000, &target);
}
};
struct meter {
int value;
explicit meter(int nv) { value = nv; }
operator kilometer() const {
div_t rd = div(value, 1000);
if (rd.rem != 0) {
throw inexact_exception();
}
return kilometer(rd.quot);
}
bool to_kilometer_checked(kilometer& target) const {
// true if inexact
div_t rd = div(value, 1000);
target.value = rd.quot;
return rd.rem != 0;
}
kilometer to_kilometer_round() const {
return kilometer((int) round(value/1000.0));
}
};
Всё, прямая конверсия (раз уж попросили) сделана безопасной (увы, в рантайме; но если компилятор знает, что путь исключения не выполняется, то он просто выкинет соответствующие проверки).
А кто не хочет — может добавить слово explicit к конвертерам, или пользуется другими методами классов.
ARK>>>Понял. Когда специально написано БОЛЬШИМИ буквами "можно ли присвоить НАПРЯМУЮ" и при этом дан ответ на какой-то совершенно иной вопрос — это "рядом с нужным". Ясно. N>>Нет, вы ничего не поняли. Но рекомендую на этом не циклиться, а вернуться к более актуальной части.
ARK>Я все понял. Что кто-то виляет.
Здравствуйте, netch80, Вы писали:
N>Только в ваших фантазиях.
Что ж, разберем ваши фантазии.
Вот вторая часть вашего определения:
Сохранение семантики: если A(), B() это конверсии к соотв. типам, и A(B(x) op B(y)) != x op y для некоторой op и некоторых a, b ∈ A, то автоконверсия A->B недопустима. (Аналогичное может быть для операций любой арности и разных типов, но облом всё расписывать.)
Если автоконверсия из некоторого типа в некоторый тип _существует_ в любом виде (или встроена, или определена пользователем), то эта часть вашего определения бессмысленна, т.к. пользователь в какой-то момент и в каком-то месте определит такой "op" (а это любая функция), который приведет к инвалидации вашего правила. И мы получим, что "A(B(x) op B(y)) != x op y для некоторой op и некоторых a, b ∈ A, и автоконверсия A->B ЕСТЬ". То бишь любой язык, в котором есть неявное преобразование типов, согласно вашему определению, НЕ будет сильнотипизированным.
Таким образом, автоконверсии с "сохранением семантики" быть не может в принципе.
Если же рассмотреть варианты БЕЗ автоконверсии — ими могут быть "язык с номинативной типизацией" и "язык со структурной типизацией и два типа с разной структурой" — то эти варианты покрываются моим определением "два типа с разной структурой не могут быть присвоены друг другу".
Таким образом, та часть вашего определения, которая "про сохранение семантики", бессмысленна в любом случае — либо она входит в мое гораздо более простое определение, либо она просто не работает.
Здравствуйте, Sharowarsheg, Вы писали:
S>Нет. Они не пишут скриптов. Никаких и никогда. Они пишут в ворде по шаблонам, а иногда в экселе, если в диссертацию надо. S>Разговор про них надо заводить потому, что обсуждается школьная программа, а они тоже учатся в школе.
А вот некоторые анестезиологи пишут. И не три строчки скриптов, а планировщики задания для ядра ОС и программы для майнинга криптовалют.
LVV>>В российских школах — как второй. LVV>>Или параллельно с русскоязычным. MAG>А есть хоть один нормальный русскоязычный ЯП?
И КуМир, и Рапира — нормальные языки для обучения. Рапира — ЛУЧШЕ бейсика, которому обучали студентов в Америке.
О чем высказался недвусмысленно Дейкстра. LVV>>Даже Константин Поляков, который преподает в родной питерской школе в профильном классе, высказался у себя на сайте, что первый язык должен быть русский. MAG>Даже! Кто такой, почему мы должны ему безоговорочно верить?
Если хотите иметь качественных программистов (о бестолковости которых вы здесь постоянно пишете) — читайте Константина Полякова.
О том, как и готовить.
Константин Поляков — лучший учитель России какого-то там года.
Он написал лучший учебник информатики для профильных классов.
И он по-любому больше вас знает, как готовить программистов.
Еще и доктор наук. Но школу родную не бросает и учит пацанов. LVV>>В своем учебнике по информатике для профильных классов он так и написал — параллельно. LVV>>Слева — КуМир, справа — Паскаль. MAG>Это тот самый кумир, который алг нач цел вещ все кон? За что? MAG>За что вы так ненавидите детей?
Ваше воиствующее невежество лезет из все щелей вашего организма... LVV>>Если кто скажет, что они развиваются, а паскаль — нет, то это ерунда. LVV>>Смотрите Оберон и Зоннон. MAG>Здесь мы на них смотрели. Много раз.
Как говорится, смотрите в книгу, а видите фигу. LVV>>Фактически — нет конторы, которая поддерживала бы паскаль на рынке. MAG>«Паскаль не развивается — это ерунда», но одновременно «нет конторы, которая поддерживала бы паскаль»
О, Боже! Опять вы демонстрируете свое невежество.
Отсутствие прибыли — не есть отсутствие развития...
Развитием паскалевского направления занимается Вирт до сих пор и Гуткнехт, который приезжал в Россию в октябре 2018 года на День Оберона и рассказывал много интересного.
Хочешь быть счастливым — будь им!
Без булдырабыз!!!
Сохранение семантики: если A(), B() это конверсии к соотв. типам, и A(B(x) op B(y)) != x op y для некоторой op и некоторых a, b ∈ A, то автоконверсия A->B недопустима. (Аналогичное может быть для операций любой арности и разных типов, но облом всё расписывать.)
ARK>Если автоконверсия из некоторого типа в некоторый тип _существует_ в любом виде (или встроена, или определена пользователем), то эта часть вашего определения бессмысленна, т.к. пользователь в какой-то момент и в каком-то месте определит такой "op" (а это любая функция), который приведет к инвалидации вашего правила.
Да, пользователь может что угодно определить. И тогда будет виноват, что он так определил.
Это пользовательские типы => это его забота делать так, чтобы не создавать нелепостей в определениях.
Задача языка не в том, чтобы запретить это пользователю, а в том, чтобы
1) не создавать таких проблем в своей базе;
2) предоставить пользователю средства создания нужных типов и их конверсии;
3) ещё лучше — предоставить пользователю средства контроля за проблемами типизации;
4) совсем хорошо — предупреждать о таких проблемах.
ARK>Таким образом, автоконверсии с "сохранением семантики" быть не может в принципе.
Может. Если подходить с умом, здравым смыслом и правилом "tools, not policy".
А ваш подход — лучшая в этой сфере иллюстрация к "дай дураку стеклянный фаллос, он его разобьёт и порежется".
ARK>Если же рассмотреть варианты БЕЗ автоконверсии — ими могут быть "язык с номинативной типизацией" и "язык со структурной типизацией и два типа с разной структурой" — то эти варианты покрываются моим определением "два типа с разной структурой не могут быть присвоены друг другу".
Ну вот и получаются беззубые языки, которые только для обучения подходам 50-летней давности.
Отличное доказательство $subj всей темы, спасибо.
LVV>И КуМир, и Рапира — нормальные языки для обучения. Рапира — ЛУЧШЕ бейсика, которому обучали студентов в Америке.
Человек, который что-то вещает про невежество, предлагает сравнивать с бейскиом, которому студентов в Америке не обучают уже лет тридцать, как. На дворе был 2019 год...
MAG>>Это тот самый кумир, который алг нач цел вещ все кон? За что? MAG>>За что вы так ненавидите детей? LVV>Ваше воиствующее невежество лезет из все щелей вашего организма...
Отличная аргументация, сразил наповал, да.
LVV>>>Если кто скажет, что они развиваются, а паскаль — нет, то это ерунда. LVV>>>Смотрите Оберон и Зоннон. MAG>>Здесь мы на них смотрели. Много раз. LVV>Как говорится, смотрите в книгу, а видите фигу.
Мы видели одно сплошное говно, которое мало друг от друга отличается. Кстати, какой из Оберонов имеется в виду, из много разных.
LVV>>>Фактически — нет конторы, которая поддерживала бы паскаль на рынке. MAG>>«Паскаль не развивается — это ерунда», но одновременно «нет конторы, которая поддерживала бы паскаль» LVV>О, Боже! Опять вы демонстрируете свое невежество. LVV>Отсутствие прибыли — не есть отсутствие развития...
В каком месте кто-то хоть что-то сказал про прибыль? Никто. Кто из нас видит в книге фигу?
LVV>Развитием паскалевского направления занимается Вирт до сих пор и Гуткнехт, который приезжал в Россию в октябре 2018 года на День Оберона и рассказывал много интересного.
Языком молоть не мешки таскать. Развития в паскалевском направлении нет. Есть унылое топтание на месте.
LVV>>И КуМир, и Рапира — нормальные языки для обучения. Рапира — ЛУЧШЕ бейсика, которому обучали студентов в Америке. MAG>Человек, который что-то вещает про невежество, предлагает сравнивать с бейскиом, которому студентов в Америке не обучают уже лет тридцать, как. На дворе был 2019 год... MAG>>>Это тот самый кумир, который алг нач цел вещ все кон? За что? MAG>>>За что вы так ненавидите детей? LVV>>Ваше воинствующее невежество лезет из все щелей вашего организма... MAG>Отличная аргументация, сразил наповал, да.
Не менее отличная, чем предположение о ненависти к детям.
За сим откланиваюсь — вы тоже воинствующий, хотя, возможно, не такой невежественный.
Хочешь быть счастливым — будь им!
Без булдырабыз!!!
Здравствуйте, Michael7, Вы писали:
S>>Нет. Они не пишут скриптов. Никаких и никогда. Они пишут в ворде по шаблонам, а иногда в экселе, если в диссертацию надо. S>>Разговор про них надо заводить потому, что обсуждается школьная программа, а они тоже учатся в школе.
M>А вот некоторые анестезиологи пишут. И не три строчки скриптов, а планировщики задания для ядра ОС и программы для майнинга криптовалют.
Это очень хорошо. Но если мы сделаем умение писать планировщики требованием для анестезиологов, большинство хирургических операций придётся делать без анестезии. Будущие же выдающиеся анестезиологи могут в школе заниматься факультативно.
Здравствуйте, pagid, Вы писали: __>>ну, можно ему в универе учить. а зачем? потом все равно что-то другое учить придется P>Так любое другое учить будет проще, а это "другое" может оказаться очень разным.
дело во временных затратах.
нужен например тебе для работы, русский язык. а тебе говорят — ты сначала изучи болгарский, украинский и белорусский и тогда, когда будешь русский, наконец учить, будет проще и будешь глубже его понимать. так-то оно так, но все-таки это просто сильно дольше получается
Но это почти везде можно. 
Ясно.
