Как по мне, то на мат-факе очень много времени в процессе обучения уходит на доказательство теорем (матанализ и ТФКП, а также "аналитическая геометрия" и "алгебра и теория чисел"). Может быть стоит убрать доказательства из обязательной программы, сделав их факультативными?
Я нередко слышал от людей (далёких от IT) что-то типа "чтобы быть хорошим программистом нужно хорошо знать математику". Это может быть и верно для тех программистов, которые создают основополагающие алгоритмы (сортировка, поиск и всё такое ...), для тех кто разрабатывает операционные системы, драйверы, графические движки, системы управления базами данных.
Но ведь подавляющее большинство программистов - это прикладники, решающие бизнес-задачи и пользующиеся готовыми библиотеками и фреймворками, и в этой области есть большой простор для деятельности, для которой школьного курса математики будет вполне достаточно.
Это всё таки весьма субъективно, насчёт убогости интерфейса. Один и тот же интерфейс кому-то может показаться убогим, а кому-то и вполне себе приемлемым. На моей практике самый убогий интерфейс (с моей точки зрения, естественно) рисовали как раз те, кто был силён в математике, а удобный и продуманный интерфейс делали те, кто был от математики далёк.
Уважаемый автор, ваши эмоции более-менее ясны, но над текстом всё же надо поработать - ведь это не так-то и просто - понятно и доходчиво излагать свои мысли.
В русском например нет того богатства времен, как у типичных романо-германских, английского, датского и прочих ...
Это не богатство времён, это всего лишь "временнЫе конструкции для глаголов" = языковые костыли, вынужденно используемые, потому что нет других средств в данном языке.
А в русском языке для выражения примерно тех же мыслей существуют гораздо более изящные конструкции. Вот хороший комментарий по данной теме:
Меня всегда интересовало, как там в древности (и в средние века) в домах (особенно в многоэтажных, в замках, в дворцах) обстояло дело с туалетами, ваннами, водопроводом, канализацией, т.е. так называемый санитарно-гигиенический комплекс. Вы не могли бы подробнее осветить этот вопрос ?
Я знаете чего подумал? А зачем вообще в явном виде "мягко" удалять сущность, зависимую только от родительской сущности? Ведь если родительская сущность удалена "мягко", то по сути в БД уже имеется информация о том, что все сущности, зависящие только от мягко удалённой родительской, могут считаться мягко удалёнными, а в случае восстановления родительской сущности, они автоматом считаются восстановленными. То есть зависимая сущность пользуется столбцом deleted_at родительской сущности (с помощью операции соединения по ключевому столбцу).
Без внешних ключей можно удалить клиента, но забыть удалить его накладные, оставив потерянные накладные, ссылающиеся на отсутствующего клиента.
А вот это очень странная претензия. Неужели автор не понимает, что для того и придумали "мягкое удаление" чтобы ни сам объект, ни ссылающиеся на него объекты не были физически удалены из таблиц.
Вот было бы веселье, если бы клиента удалили "мягко", а все его накладные удалили бы "жёстко". В таком случае при восстановлении ошибочно удалённого клиента командой update, мы были бы неприятно удивлены тем, что клиента мы восстановили, а его накладные куда-то безвозвратно пропали :-(
Как по мне, то на мат-факе очень много времени в процессе обучения уходит на доказательство теорем (матанализ и ТФКП, а также "аналитическая геометрия" и "алгебра и теория чисел"). Может быть стоит убрать доказательства из обязательной программы, сделав их факультативными?
Я нередко слышал от людей (далёких от IT) что-то типа "чтобы быть хорошим программистом нужно хорошо знать математику". Это может быть и верно для тех программистов, которые создают основополагающие алгоритмы (сортировка, поиск и всё такое ...), для тех кто разрабатывает операционные системы, драйверы, графические движки, системы управления базами данных.
Но ведь подавляющее большинство программистов - это прикладники, решающие бизнес-задачи и пользующиеся готовыми библиотеками и фреймворками, и в этой области есть большой простор для деятельности, для которой школьного курса математики будет вполне достаточно.
Это всё таки весьма субъективно, насчёт убогости интерфейса. Один и тот же интерфейс кому-то может показаться убогим, а кому-то и вполне себе приемлемым. На моей практике самый убогий интерфейс (с моей точки зрения, естественно) рисовали как раз те, кто был силён в математике, а удобный и продуманный интерфейс делали те, кто был от математики далёк.
Ну а как оно может справиться, если даже правописание глаголов, оканчивающихся на -тся, -ться представляет для него огромную проблему.
А как вообще можно по имени и фамилии установить цвет кожи ? Вот, например, человека зовут Mike Wilson. Он чёрный или белый ?
Странно, что никто не догадался своровать полиграф.
del
Уважаемый автор, ваши эмоции более-менее ясны, но над текстом всё же надо поработать - ведь это не так-то и просто - понятно и доходчиво излагать свои мысли.
Стесняюсь даже спросить, а этот Гейдель - это кто ?
Есть Гегель, есть Гёдель, а вот Гейдель - кто он ?
Это не богатство времён, это всего лишь "временнЫе конструкции для глаголов" = языковые костыли, вынужденно используемые, потому что нет других средств в данном языке.
А в русском языке для выражения примерно тех же мыслей существуют гораздо более изящные конструкции. Вот хороший комментарий по данной теме:
https://habr.com/ru/company/timeweb/blog/681828/#comment_24629606
а там порт, случайно, не 9150 ?
А у меня от долгого сидения спина затекает в районе поясницы. Делаю приседания и наклоны вперед стоя с выпрямленными коленями.
Спасибо за интересную статью.
Меня всегда интересовало, как там в древности (и в средние века) в домах (особенно в многоэтажных, в замках, в дворцах) обстояло дело с туалетами, ваннами, водопроводом, канализацией, т.е. так называемый санитарно-гигиенический комплекс. Вы не могли бы подробнее осветить этот вопрос ?
Я знаете чего подумал? А зачем вообще в явном виде "мягко" удалять сущность, зависимую только от родительской сущности? Ведь если родительская сущность удалена "мягко", то по сути в БД уже имеется информация о том, что все сущности, зависящие только от мягко удалённой родительской, могут считаться мягко удалёнными, а в случае восстановления родительской сущности, они автоматом считаются восстановленными. То есть зависимая сущность пользуется столбцом deleted_at родительской сущности (с помощью операции соединения по ключевому столбцу).
А вот это очень странная претензия. Неужели автор не понимает, что для того и придумали "мягкое удаление" чтобы ни сам объект, ни ссылающиеся на него объекты не были физически удалены из таблиц.
Вот было бы веселье, если бы клиента удалили "мягко", а все его накладные удалили бы "жёстко". В таком случае при восстановлении ошибочно удалённого клиента командой update, мы были бы неприятно удивлены тем, что клиента мы восстановили, а его накладные куда-то безвозвратно пропали :-(
Логика может и не "растекаться", если вы создадите представление, например
create view v_active_customer asSELECT * FROM customer WHERE deleted_at IS NULL;и в дальнейшем использовать это представление в запросах на выборку вместо таблицы customer.
Не все преобразования приводят к эквивалентному уравнению. Занимаясь "избавлением" от радикалов, вы можете получить вовсе не эквивалентное уравнение.
От радикала можно "избавиться", но это будет уже другое уравнение, а не то, которое вам задали.
Ностальгия автора по перфокартам и магнитным лентам - это, конечно, очень важно и интересно.
То есть, по-вашему, Красная Армия завоёвывала территории, забрасывая врагов шапками и парт-билетами ?
В лаптях и с одной винтовкой на десятерых ?