Comments 53
А значит дело тупо в тренировке и опыте. А не в фундаментальной логике. Она конечно помогает в задачах, родственных алгоритмам. Но есть подозрение, что это тоже дело тренировки. Например, для аргументированного спора надо знать критерий фальсифицируемости и другие подобные логические приемы, которые в программировании вообще никак не встречаются. Другая область, другие «фундаментальные логики», как они описаны в статье. Так что универсальный язык вряд ли получится. Просто все существующие языки программирования очень похожи, что облегчает переход между ними.
«Cпособ мышления — Форт язык и философия для решения задач» (автор Броуди) -1984г
Очень нагляные неправильные примеры. Я понимаю, что учительница хотела показать как сложно программировать компьютеры, но истинная сложность — она не в чрезмерной подробности. С этим люди давно справились. Истинная сложность — в том, что для того, чтобы справиться с избыточной подробностью нижних слоёв, верхние используют абстракции. Очень абстрактные абстракции, которые абстрагируют понятие абстракции в отношении абстрактных понятий. Это очень сильные механизмы, но их понимание требует перестройки мозга.
Потому что простому обывателю очень трудно объяснить, что такое обобщённый ассоциированный срок жизни для обобщённого типажа, и какая невероятная от него польза при реализации обобщённых типажей для итерируемых типов с внутренней мутабельностью.
Истинная сложность — в том, что для того, чтобы справиться с избыточной подробностью нижних слоёв, верхние используют абстракции. Очень абстрактные абстракции, которые абстрагируют понятие абстракции в отношении абстрактных понятий.Значит вместо «возьми ложку» надо будет приказывать «возьми столовый прибор, подходящий для зачерпывания жидкой пищи».
А вообще, пример с мороженным действительно не совсем верный, ибо учительница не дала список предметов, которыми можно манипулировать и список возможных действий над ними. Если бы студенты видели перед собой эти списки, было бы намного проще понять, насколько точным надо быть, без выдумывания.
Истинная сложность — в том, что для того, чтобы справиться с избыточной подробностью нижних слоёв, верхние используют абстракции. Очень абстрактные абстракции, которые абстрагируют понятие абстракции в отношении абстрактных понятий.
Это справедливо для базовых типов, подмена чего-то трудно произносимого на более простое — в этом вся суть абстракции. Теперь вам нужно помнить две вещи: новое название, и его старый вариант. При этом новая абстракция не описывает возможности применения, а всего-лишь ограничивает возможные действия. Когда таких переименований становится ощутимое количество — теряется сам смысл в новых изобретениях.
Использовать абстракции для нижних слоёв — означает продолжение работы с нижним слоем под новыми именами. Это не эффективно и глупо. Все алгоритмы нижнего слоя должны оставаться там-же, на нижнем слое. А вот для верхнего слоя можно уже и своё придумать. В идеале — замена нижнего слоя не должна ломать систему. Таких слоёв может быть множество, и каждый из них можно заменить на аналогичный по функционалу.
При этом нижний слой должен терять видимость, также как и слой выше. А абстракции — это просто оправдания для написания новых фреймворков.
А что такое фундаментальная логика — базовых (то есть фундаментальных) подходов к логике множество.
Думаю для европейских народов, фундаментальной верно будет считать аристотелевскую логику.
Это вы так думаете, Твардовский и Лукасевич имели противоположные точки зрения на понятие фундаментальной логики
Я Вас услышал. Но попытался обозначить критерием фундаментальности не смысл, а происхождение, в таком случае не требуются философские обоснования для подобного словосочетания. Это словосочетание является допущением переводчика, в оригинале автор ограничился просто логикой. И мне видится, что автор не претендует на какой-то глубокий анализ в вопросах мышления, а таким приемом просто эпатирует читателей.
Долго пытался сформулировать чего не хватает людям (менеджерам, операционисткам, начальникам), которые проходят курсы SQL, VBA или ещё чего то, а потом… понимают, что не понимают как этим пользоваться.
Я правильно начал обучение программированию в 1995 году?
p.s. Статью нужно экспортировать в Африку, у них больше никогда не будет проблем с водой.
В этом отличие программирования от феноменологии… )))
У меня в самой обычной школе были алгоритмы на уроках информатики и только после уже немного кодинга в бейсике. Не раз сталкивался с утверждением что программирование — описание инструкций, которые выполнит компьютер.
Может конечно ситуация в странах очень отличается, но я учился в Казахстане, в России обучают в школах еще лучше программированию, по моим наблюдениям.
Последний пункт был особенно важен, так как без него, в предпоследний раз учительница просто начала есть моё мороженое.
На это моменте я очень долго и громко смеялся. Хорошо никого дома не было.
Учительница, видимо, подустала играть в компьютер, поскольку итоговый алгоритм всё ещё никуда не годится )))
Возьми ложку для мороженого и один за другим положи три шарика малинового мороженого в миску.
Что-то непонятно… А где взять шарики малинового мороженого? Где фабричный метод их создания?
Возьми банку с шоколадным соусом, зачерпни соус и вылей в миску содержимое столовой ложки.
Зачерпни соус чем?
Возьми и переверни вверх ногами упаковку взбитых сливок и, держа её над миской, поливай ими мороженое 3 секунды, после чего верни упаковку на место.
Прям вот так вот вверх ногами и вернуть упаковку на место?
Первая задача.
Дано: чайник, вода, плита.
Нужно: вскипятить воду.
Решение: налить воду в чайник, включить плиту, поставить на нее чайник, когда вода закипит — выключить плиту.
Вторая задача.
Дано: что и в первой задаче, но в чайник уже налита вода.
Нужно: вскипятить воду.
Решение: вылить воду из чайника, тогда мы приходим к задаче, которую уже знаем, как решать.
Вы пишите новый код с использованием имеющихся библиотек, и ваш алгоритм уже уникальный. Для уменьшения ошибок все внешние действия с вашим кодом должны быть простыми и понятными. Так можно продолжать почти бесконечно, вот только жирность от этого растёт…
Средство для уменьшения жира существует, и это не абстракции — как может показаться на первый взгляд. Это описание типов данных с помощью перекрёстных ссылок. Может это иначе называется, но применяется именно так.
Смысл в том, что в стандартном варианте например возраст человека имеет одно ограничение — число должно быть целым без знака. Можно написать 0, можно написать 1000, в структуру эти числа запишутся без каких либо проблем.
Тип с перекрестными ссылками сначала проверит существование имени, опа — вариант «неизвестно», потом проверит даты рождения и смерти, и если человек ещё жив — то автоматом считает местное время и пропечатает возраст. При этом перекрестные ссылки — это ограничения и список возможных действий с выбранным типом, которые выполняются автоматически, без лишнего кода со стороны пользователя.
И это не абстракции!!!
Это чуть сложнее, для понимания можно заглянуть в описание типов чисел с фиксированной точкой.
Можно сколько угодно играть с абстрациями, но если вы не можете просто взять и прочитать что умеет делать эта библиотека с гитхаба — то вы так себе разработчик.
Ну смотрите. Поиск в массиве — это когда вы ищете, например, ботинки, последовательно открывая обувные коробки. А в хэш-таблице — это когда вы заранее прикинули, что ботинки зимние, коричневого цвета (то есть на основе самого искомого объекта вычислили его хэш — какую-то его краткую характеристику), а значит, они лежат вон в той коробке, где написано "зимние коричневые", в остальных искать не надо.
Программный хэш может и не иметь какого-то осмысленного значения, но поиск он ускоряет точно так же.
Хэш таблица размером в 100 кажется будет по скорости почти массив уже.
В общем, это конечно не линейно, но и не 1. Вот сколько — посчитать я затрудняюсь.
Ещё тут важно отношение количества данных к числу ячеек хэша. В Джаве по умолчанию хэш-таблица увеличивается и пересчитывается, как только это отношение достигает 0.75 — это считается оптимальным балансом скорости и занимаемой памяти для большинства задач.
Сложность алгоритма будет все равно O(1), потому что все что не зависит от кол-ва элементов будет иметь константную сложность (хотя с практической точки зрения два алгоритма с одинаковым O(сколько-то) могут выполняться за очень разное время, иногда в десятки и сотни раз отличающееся).
Сложность алгоритма будет зависеть от N — числа размещенных элементов и M — числа строк в таблице. Если размер таблицы неограничен, хэш идеальный (без коллизий), то будет О(1), мы сразу получаем правильную ячейку, расплачиваясь кучей пустого места. Если таблица ограничена (в пределе М=N), а хэш идеален только в смысле того, что для каждого элемента даёт равномерное распределение адреса от 1 до М, то единичка начинает расти, характеристика роста зависит от среднего числа коллизий, которое зависит от соотношения M и N, но скорее всего не пропорционально M/N а по более сложному закону.
Ну и писать становится все сложнее — в пределе так же сложно, как и искать. Так как каждая запись это поиск пустого места.
Я, конечно, совсем вообще не програмист и не алгоритмист, но мне кажется, что сложность описанной вами реализации будет линейная вида O(n/N), где N — количетво строк в хеш таблице. То есть поиск по трём коробкам-то всё равно линейный?
То есть поиск по трём коробкам-то всё равно линейный?
Если мы увеличивая N соответвенно увеличиваем хеш-таблицу, то поиск не будет зависить от N, следовательно сложность O(1), но требования по памяти будет O(N). Тут надо понимать, что O(...) говорит о том зависит функция от кол-ва элементов, но не говорит о практической сложности самого поиска.
И вы скорее всего подразумеваете не поиск, а извлечение элемента по его id.
Это идеализированный случай, в котором речь скорее про enum — вопрос изменения мы не рассматриваем, а хэш-функция идеальна. Реальная хэш-таблица обычно имеет коллизии. И в самом неудачном случае всё возвращается к обычному поиску.
А использование мороженки для обучающих целей это интересно ))
Рынок настолько насыщен выпускниками институтов и курсов, что позиция джуниора практически перестала существовать
а можно узнать это в какой стране? говнокодеров после универа да полно, но из них хороших программистов лет через 5 останется очень мало, а остальные либо перейдут чем-то другим заниматься или так и остануться говнокодерами
а про логику отдельный разговор, это как сказать что инженеры должны учить только физику и химию, кроме этого есть дохера опыта разработок которые тоже надо изучить и без них зная только физику и химию такой инженер никому не нужен, потому что он будет изобратаь колесо не зная что уже всё зделано до него, разве что изначально талантлив и интуитивно будет придумывать только хорошие решения которые лучше имеющихся
Один язык чтобы править всеми