Pull to refresh

Comments 53

Нууу, это спорно. Вот пример из жизни: можно быть прекрасным программистом, легко понимать и запоминать длинные алгоритмы, с ветвлениями и прочим. То есть, фундаментальная логика развита. Но при этом быть полностью неспособным запомнить мелодию из пары десятков нот. Хотя они такая же логическая последовательность из следующих друг за другом атомарных элементов (даже короче большинства программ!). Присутствуют даже пара простых циклов в виде припевов.

А значит дело тупо в тренировке и опыте. А не в фундаментальной логике. Она конечно помогает в задачах, родственных алгоритмам. Но есть подозрение, что это тоже дело тренировки. Например, для аргументированного спора надо знать критерий фальсифицируемости и другие подобные логические приемы, которые в программировании вообще никак не встречаются. Другая область, другие «фундаментальные логики», как они описаны в статье. Так что универсальный язык вряд ли получится. Просто все существующие языки программирования очень похожи, что облегчает переход между ними.
И песочница, где можно попробовать знания теоретические в рисовании практическом forthsalon.appspot.com
Ну это не форт, это просто какое-то примитивное постфиксное нерасширяемое говно.

Очень нагляные неправильные примеры. Я понимаю, что учительница хотела показать как сложно программировать компьютеры, но истинная сложность — она не в чрезмерной подробности. С этим люди давно справились. Истинная сложность — в том, что для того, чтобы справиться с избыточной подробностью нижних слоёв, верхние используют абстракции. Очень абстрактные абстракции, которые абстрагируют понятие абстракции в отношении абстрактных понятий. Это очень сильные механизмы, но их понимание требует перестройки мозга.


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

Истинная сложность — в том, что для того, чтобы справиться с избыточной подробностью нижних слоёв, верхние используют абстракции. Очень абстрактные абстракции, которые абстрагируют понятие абстракции в отношении абстрактных понятий.
Значит вместо «возьми ложку» надо будет приказывать «возьми столовый прибор, подходящий для зачерпывания жидкой пищи».
А вообще, пример с мороженным действительно не совсем верный, ибо учительница не дала список предметов, которыми можно манипулировать и список возможных действий над ними. Если бы студенты видели перед собой эти списки, было бы намного проще понять, насколько точным надо быть, без выдумывания.
UFO just landed and posted this here
UFO just landed and posted this here
Однако почему-то почти первокурсники, которые писали на делфи, у меня посыпались на «обломись» is not an integer и делении на ноль.
Истинная сложность — в том, что для того, чтобы справиться с избыточной подробностью нижних слоёв, верхние используют абстракции. Очень абстрактные абстракции, которые абстрагируют понятие абстракции в отношении абстрактных понятий.

Это справедливо для базовых типов, подмена чего-то трудно произносимого на более простое — в этом вся суть абстракции. Теперь вам нужно помнить две вещи: новое название, и его старый вариант. При этом новая абстракция не описывает возможности применения, а всего-лишь ограничивает возможные действия. Когда таких переименований становится ощутимое количество — теряется сам смысл в новых изобретениях.
Использовать абстракции для нижних слоёв — означает продолжение работы с нижним слоем под новыми именами. Это не эффективно и глупо. Все алгоритмы нижнего слоя должны оставаться там-же, на нижнем слое. А вот для верхнего слоя можно уже и своё придумать. В идеале — замена нижнего слоя не должна ломать систему. Таких слоёв может быть множество, и каждый из них можно заменить на аналогичный по функционалу.
При этом нижний слой должен терять видимость, также как и слой выше. А абстракции — это просто оправдания для написания новых фреймворков.

А что такое фундаментальная логика — базовых (то есть фундаментальных) подходов к логике множество.

Думаю для европейских народов, фундаментальной верно будет считать аристотелевскую логику.

Это вы так думаете, Твардовский и Лукасевич имели противоположные точки зрения на понятие фундаментальной логики

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

Понял — не обратил внимание, что это перевод. иначе пропустил бы это сауронство

Что это перевод было понятно, когда на информатике оказалось мороженое :)
Это слишком хорошо для наших школ, да и, наверное, не по ТБ

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

Спасибо.
Долго пытался сформулировать чего не хватает людям (менеджерам, операционисткам, начальникам), которые проходят курсы SQL, VBA или ещё чего то, а потом… понимают, что не понимают как этим пользоваться.
Урок интересный, а потом пошла лабуда, фундаментальные знания конечно важны, но это далеко не только про асимптотическую сложность, это скорее про теорию категорий, лямбда исчисление, методы формальной спецификации и верификации и много чего ещё, что делает программиста-кодера программистом-инженером. А знание паттернов это просто ремесленный опыт, а не наука.
И, кроме этого, надо ещё знать область, в которой разрабатывается продукт. Бухгалтерию, сопромат или биологию, например.
Конечно, ещё мат. статистику и всякие методы машинного обучения, но статья именно про универсальные программерские знания.
такое наглядное объяснение логики на мороженом — восхитительно!
Алгоритмизацию можно ещё на примере задачи «спуститься на лифте на первый этаж» с полной проверкой входных данных объяснять.
UFO just landed and posted this here
Это один из вариантов выхода с segmentation fault =)
Ещё есть «убило током — не освоил»
Фундаментальная логика — это интуитивистская?
Моей первой книжкой по программированию тогда можно считать «Энциклопедию профессора фортрана», там была
похожая на мороженое задачка, но про картошку
image

Я правильно начал обучение программированию в 1995 году?
p.s. Статью нужно экспортировать в Африку, у них больше никогда не будет проблем с водой.
Будучи американцем, автор не догадался добавить про важность английского языка.
Проблема инструкций в том, что невозможно точно и полно описать явление текстом.
В этом отличие программирования от феноменологии… )))
Какие-то очевидные вещи поясняет автор.
У меня в самой обычной школе были алгоритмы на уроках информатики и только после уже немного кодинга в бейсике. Не раз сталкивался с утверждением что программирование — описание инструкций, которые выполнит компьютер.
Может конечно ситуация в странах очень отличается, но я учился в Казахстане, в России обучают в школах еще лучше программированию, по моим наблюдениям.
Англоязычные сайты кишат подобным контентом. Несколько произвольно выбранных утверждений на тему предметной области — статья готова. Не знаю кто и зачем их пишет.
Зачем понятно. Любая статья это рекламные деньги, строчка в резюме и т.д. Если сложную техническую статью можно несколько месяцев писать, да и интересна она будет десятку человек в мире, то такое можно строгать сотнями за неделю, а начинающих всегда больше, чем экспертов. Просто такой бизнес, на грани поискового спама, ничего личного.
Последний пункт был особенно важен, так как без него, в предпоследний раз учительница просто начала есть моё мороженое.

На это моменте я очень долго и громко смеялся. Хорошо никого дома не было.

Учительница, видимо, подустала играть в компьютер, поскольку итоговый алгоритм всё ещё никуда не годится )))


Возьми ложку для мороженого и один за другим положи три шарика малинового мороженого в миску.

Что-то непонятно… А где взять шарики малинового мороженого? Где фабричный метод их создания?


Возьми банку с шоколадным соусом, зачерпни соус и вылей в миску содержимое столовой ложки.

Зачерпни соус чем?


Возьми и переверни вверх ногами упаковку взбитых сливок и, держа её над миской, поливай ими мороженое 3 секунды, после чего верни упаковку на место.

Прям вот так вот вверх ногами и вернуть упаковку на место?

Прочитав про мороженое вспомнил анекдот «как математик решает задачи»:
Первая задача.
Дано: чайник, вода, плита.
Нужно: вскипятить воду.
Решение: налить воду в чайник, включить плиту, поставить на нее чайник, когда вода закипит — выключить плиту.

Вторая задача.
Дано: что и в первой задаче, но в чайник уже налита вода.
Нужно: вскипятить воду.
Решение: вылить воду из чайника, тогда мы приходим к задаче, которую уже знаем, как решать.
хороший анекдот, но наш препод по физике рассказывал его смешнее)
Всё правильно автор пишет — иначе получается полный позор! Парни, 217 Mb на страницу, в которой нифига функций, вы серьёзно? И всё, что они посоветовали — юзать Chrome, а не Firefox!



Не совсем понятно при чём тут логика, и зачем её нужно думать. Весь программный код пишется с одной целью — скрыть ту самую логику как можно глубже, чтобы сверху осталось простое и понятное действие.
Вы пишите новый код с использованием имеющихся библиотек, и ваш алгоритм уже уникальный. Для уменьшения ошибок все внешние действия с вашим кодом должны быть простыми и понятными. Так можно продолжать почти бесконечно, вот только жирность от этого растёт…

Средство для уменьшения жира существует, и это не абстракции — как может показаться на первый взгляд. Это описание типов данных с помощью перекрёстных ссылок. Может это иначе называется, но применяется именно так.
Смысл в том, что в стандартном варианте например возраст человека имеет одно ограничение — число должно быть целым без знака. Можно написать 0, можно написать 1000, в структуру эти числа запишутся без каких либо проблем.
Тип с перекрестными ссылками сначала проверит существование имени, опа — вариант «неизвестно», потом проверит даты рождения и смерти, и если человек ещё жив — то автоматом считает местное время и пропечатает возраст. При этом перекрестные ссылки — это ограничения и список возможных действий с выбранным типом, которые выполняются автоматически, без лишнего кода со стороны пользователя.

И это не абстракции!!!
Это чуть сложнее, для понимания можно заглянуть в описание типов чисел с фиксированной точкой.
Самый полезный язык для программирования это английский — все документации пишут на инглише, почти все ридми пишут на инглише, комментарии к коду обычно пишут на инглише, да и сам код почти любого языка программирования состоит из английских слов, самый полезный контент по разработке на инглише ну и тд.

Можно сколько угодно играть с абстрациями, но если вы не можете просто взять и прочитать что умеет делать эта библиотека с гитхаба — то вы так себе разработчик.
А можно ссылку на библиотеки для MS SQL с гитхаба, пожалуйста?
С удовольствием почитал бы.
А объясните балбесу, почему поиск по хэш-таблице имеет сложность О(1)?

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

Только нужно помнить про очень грустный момент с памятью. Пусть у нас 100 элементов в массиве, и хэш таблица на 200 элементов, в которую мы запихнули те же 100 элементов. Первично получается 15-17 коллизий, которые ведут к цепочкам вторичных. Если мы пишем не просто в следующую свободную ячейку, а устраиваем какой-то «рандом», то при чтении нужно еще и помнить все номера ячеек, которые мы просмотрели, чтобы не выпасть в цикл.
Хэш таблица размером в 100 кажется будет по скорости почти массив уже.
В общем, это конечно не линейно, но и не 1. Вот сколько — посчитать я затрудняюсь.
Маленькие хэш-таблицы в любом случае медленнее маленьких массивов из-за накладных расходов.

Ещё тут важно отношение количества данных к числу ячеек хэша. В Джаве по умолчанию хэш-таблица увеличивается и пересчитывается, как только это отношение достигает 0.75 — это считается оптимальным балансом скорости и занимаемой памяти для большинства задач.
Не совсем понял, что вы хотите сказать. Если у нас есть 200 ботинок, а хеш-таблица только на 100 значений, очевидно вы никак не сможем извернуться и дать каждому ботинку отдельную строчку в хеш-таблице, но если хеш функция достаточно равномерная, то в каждому хешу будет соотвествовать 2-3 коробки с обувью. Просмотреть 3 коробки последовательно конечно медленее, чем одну, но все-таки достаточно быстро. Тут главное, чтобы хеш функции были хорошие и объем хеш-таблицы был все-таки достаточно большой для наших данных.

Сложность алгоритма будет все равно O(1), потому что все что не зависит от кол-ва элементов будет иметь константную сложность (хотя с практической точки зрения два алгоритма с одинаковым O(сколько-то) могут выполняться за очень разное время, иногда в десятки и сотни раз отличающееся).
Я привел цифры для 100 ботинок и 200 коробок. Если у нас 100 ботинок и 100 коробок, то уже после первой смены сезона в «зимние коричневые» лежат босоножки.
Сложность алгоритма будет зависеть от N — числа размещенных элементов и M — числа строк в таблице. Если размер таблицы неограничен, хэш идеальный (без коллизий), то будет О(1), мы сразу получаем правильную ячейку, расплачиваясь кучей пустого места. Если таблица ограничена (в пределе М=N), а хэш идеален только в смысле того, что для каждого элемента даёт равномерное распределение адреса от 1 до М, то единичка начинает расти, характеристика роста зависит от среднего числа коллизий, которое зависит от соотношения M и N, но скорее всего не пропорционально M/N а по более сложному закону.
Ну и писать становится все сложнее — в пределе так же сложно, как и искать. Так как каждая запись это поиск пустого места.

Я, конечно, совсем вообще не програмист и не алгоритмист, но мне кажется, что сложность описанной вами реализации будет линейная вида O(n/N), где N — количетво строк в хеш таблице. То есть поиск по трём коробкам-то всё равно линейный?

То есть поиск по трём коробкам-то всё равно линейный?

Если мы увеличивая N соответвенно увеличиваем хеш-таблицу, то поиск не будет зависить от N, следовательно сложность O(1), но требования по памяти будет O(N). Тут надо понимать, что O(...) говорит о том зависит функция от кол-ва элементов, но не говорит о практической сложности самого поиска.
Потому что это неправда :-)
И вы скорее всего подразумеваете не поиск, а извлечение элемента по его id.
Это идеализированный случай, в котором речь скорее про enum — вопрос изменения мы не рассматриваем, а хэш-функция идеальна. Реальная хэш-таблица обычно имеет коллизии. И в самом неудачном случае всё возвращается к обычному поиску.
Самым первым языком программирования в институте у нас был язык С. На практических занятиях препод давал задания и заставлял сначала писать псевдокод для представления алгоритма. Так было два семестра. Точно помню, что в первые разы у нашей команды из двух человек не получалось это выполнить за два-три подхода. Студенты негодовали, говорили, что в этом нет смысла. Если честно, я тоже разделяла их мнение. Оценила этот подход только под конец учебы в институте, когда обащась на работе с другими студентами, и у многих из них действительно были проблемы с составлением алгоритмов и учетом в них очевидных вещей. Так что все было не зря.

А использование мороженки для обучающих целей это интересно ))
Я так и матёрого программиста могу затролить. Сделай HTTP запрос. А ты сокет открыл? А URL распарсил? А откуда я знал что порт по умолчанию 80-й? А HTTP-протокол надо сначала завернуть в Ethernet протокол. А MAC-адрес ты узнал свой сначала? А куда ответ придёт? А откуда я знаю куда посылать байты, надо драйвер сетевой карты написать. И так далее, пока не опишем браузер, ОС, сервер, драйвера, ассемблер, процессор, все протоколы, кодирование в оптоволокне и не опустимся до электоронов.
Рынок настолько насыщен выпускниками институтов и курсов, что позиция джуниора практически перестала существовать

а можно узнать это в какой стране? говнокодеров после универа да полно, но из них хороших программистов лет через 5 останется очень мало, а остальные либо перейдут чем-то другим заниматься или так и остануться говнокодерами

а про логику отдельный разговор, это как сказать что инженеры должны учить только физику и химию, кроме этого есть дохера опыта разработок которые тоже надо изучить и без них зная только физику и химию такой инженер никому не нужен, потому что он будет изобратаь колесо не зная что уже всё зделано до него, разве что изначально талантлив и интуитивно будет придумывать только хорошие решения которые лучше имеющихся
Sign up to leave a comment.

Articles