Скрытый под слоем кода томится язык, жаждущий быть выученным.
На момент написания этой статьи запрос «программирование какой язык изучать первым» выдаёт 517 миллионов поисковых результатов. Каждый из этих сайтов будет нахваливать один определённый язык, и 90% из них, в конечном итоге, порекомендуют Python или JavaScript.
Без долгих прелюдий я хотел бы официально декларировать, что все эти 517 миллионов сайтов неправы и заявить, что язык, который надо изучать первым — фундаментальная логика.
Просто знать как кодить ещё не достаточно. Рынок настолько насыщен выпускниками институтов и курсов, что позиция джуниора практически перестала существовать*. Чтобы преуспеть в сегодняшнем мире, вы должны и кодить, и иметь продвинутое фундаментальное логическое мышление.
* здесь и далее, пожалуйста, помните, что это перевод, и ситуация на рынке труда у автора и в вашей стране может быть различной (как и другие нюансы), что, однако, само по себе не делает оригинальную статью хуже — прим. перев.
Мой первый урок информатики
Моё первое знакомство с информатикой было факультативом, который я взял в 10 классе. В первый же день, зайдя в аудиторию, я был восхищён, увидев перед собой большое количество ведёрок мороженого и разнообразных топпингов. После того как все расселись, учительница провозгласила:
«Сегодня мы будем дегустировать самостоятельно приготовленные пломбиры. Но с одним условием: вы должны составить список конкретных инструкций, как приготовить десерт, а я — буду им следовать»
«Без проблем, — подумал я, — этот урок не будет долгим». Где-то через минуту я набросал отличный рецепт для мороженого моей мечты:
- Зачерпнуть и положить три шарика малинового мороженого в миску
- Открыть шоколадный соус и добавить две столовые ложки в эту же миску
- Добавить взбитые сливки в миску
- Посыпать всё это сахарными палочками и положить вишенку сверху
Моя учительница — «компьютер» в этой милой метафоре — разыграла более саркастично-буквальное, чем я видел когда-либо раньше, представление. Она стала рьяно тыкать ведёрко мороженого ложкой для шариков, даже не прикоснувшись к крышке.
«Хорошо-хорошо, но сначала нужно его открыть!» — воскликнул я, пытаясь получить угощение поскорее.
«Ты не написал этого в инструкции, а я не смогла приготовить тебе мороженое. СЛЕДУЮЩИЙ!»
Промотаем время до попытки №2
- Открыть малиновое мороженое, убрав крышку
- Зачерпнуть и положить три шарика малинового мороженого в миску
- Открыть шоколадный соус и добавить две столовые ложки в эту же миску
- Добавить взбитые сливки в миску
- Посыпать всё это сахарными палочками и полжить вишенку сверху
Ну сейчас-то точно проблем не должно быть. Я даже на всякий случай убедился, что все ингредиенты для изготовления моего кулинарного шедевра открыты.
Учительница убрала крышку, зачерпнула и положила три шарика мороженого в миску. «Наконец-то мой прекрасный пломбир начал воплощаться в реальности!» Затем она открыла шоколадный соус и добавила две столовые ложки в миску. Не «добавила шоколадный соус из двух столовых ложек» — вы не подумайте — она, конечно же, положила в миску сами ложки. Без соуса в них. Опять я не удосужился расписать всё точно. После того, как остальное было исполнено в том же духе, я получил на руки миску с мороженым и двумя столовыми ложками, еле заметными под морем взбитых сливок. Сверху была пара сахарных палочек.
Кажется, в этот момент до меня наконец-то дошло: компьютер — логика в вакууме. Он не знает об окружающих обстоятельствах и не делает предположений. Он выполняет только чётко сформулированные инструкции и следует им слово в слово.
Мой конечный результат был итогом длинной, но необходимой череды проб и ошибок:
- Открой, если этого ещё не сделано, каждую из следующих упаковок: малиновое мороженое, шоколадный соус, взбитые сливки, сахарные палочки.
- Достань миску и поставь перед собой
- Возьми ложку для мороженого и один за другим положи три шарика малинового мороженого в миску. Положи ложку для мороженого на место.
- Возьми банку с шоколадным соусом, зачерпни соус и вылей в миску содержимое столовой ложки. Повтори действие с зачёрпыванием и выливанием соуса ещё один раз. Положи ложку и банку на место.
- Возьми и переверни вверх ногами упаковку взбитых сливок и, держа её над миской, поливай ими мороженое 3 секунды, после чего верни упаковку на место.
- Возьми банку сахарных палочек, высыпь около сорока палочек в миску и положи банку на место.
- Возьми одну вишенку из миски с вишенками и положи её сверху на мороженое.
- Передай ученику миску с готовым пломбиром и ложку.
Последний пункт был особенно важен, так как без него, в предпоследний раз учительница просто начала есть моё мороженое.
Но это и есть программирование. Напряжённое создание тщательного набора инструкций для компьютера. По существу, это то к чему сводится каждый язык программирования — к составлению инструкций.
Карьера в программировании
Программирование достигло той точки, когда его сложно обсуждать как единую индустрию, так же как сложно использовать единственное слово «программист» в качестве описания вакансии. Два разработчика могут быть одинаково востребованными рынком, зная абсолютно разные языки, а значит, умение разрабатывать важнее знания конкретного языка. Универсальный атрибут, присущий всем успешным разработчикам — фундаментальная логика.
Лучший программист — способный посмотреть на код под новым углом. И это принципиально важно, потому что большинство программных продуктов — набор из недокументированных осколков плохого кода. Их постоянно нужно собирать вместе, заделывая бреши по мере необходимости. Людям, не способным соединить разрозненные точки единой линией, придётся вечно быть на вторых ролях.
Всё это подводит меня к ещё одной декларации, на этот раз болдом: фундаментальные знания всегда были и будут первостепенны для программиста.
Языки приходят и уходят. Фреймворки устаревают, а компании реагируют на спрос, меняя стек используемых технологий. Есть ли вещь, которая никогда не изменится? Да — фундаментальные знания, которые потому и называются фундаментальными, что лежат в основе всего!
Как улучшить фундаментальные знания
Если ищете отправную точку для улучшения фундаментального логического мышления, попробуйте начать отсюда:
Знай сложность своей программы
Так же именуемую Big O «сложностью алгоритма» называют зависимость времени на выполнение программы от размера её входных данных (n). Держать руку на пульсе используемых алгоритмов — важный шаг.
Знай свои структуры данных
Структуры данных лежат в основе любой современной программы. Знание того, какую структуру использовать в каком случае, является самостоятельной дисциплиной. Структуры данных напрямую связаны со сложностью рантайма и выбор неправильной структуры может привести к фундаментальным проблемам с производительностью. Поиск элемента в массиве равен O(n), что говорит о дороговизне использования массивов в качестве входных данных. Поиск по хэш-таблице — O(1), а значит, в этом случае время поиска значения не зависит от количества элементов.
Ко мне на собеседование приходили люди, утверждавшие, что по массиву искать быстрее, чем по хэш-таблице. Это был вернейший признак, что нанимать их не стоит — знай свои структуры данных.
Читай / смотри / слушай
Такие сайты, как Udemy, Pluralsight и CodeAcademy — отличный выбор для изучения новых языков программирования. Но для основ обратитесь к книгам по общим принципам, практикам и стилям кодирования. Наиболее рекомендуемые книги — это «Паттерны Проектирования», «Рефакторинг. Улучшение существующего кода», «Совершенный Код», «Чистый код» и «Программист Прагматик». Наконец, каждый разработчик должен держать копию «Алгоритмов» под рукой.
Практикуйся!
Не получится приготовить яичницу, не разбив яиц. Такие сайты, как HackerRank, CodeWars, CoderByte, TopCoder и LeetCode предлагают тысячи интересных задачек для проверки знаний о структурах данных и алгоритмах. Попытайте счастья в решении приглянувшейся проблемы, выложите свой вариант на Github, а после посмотрите, как к ней подступились другие. Что подводит нас к последнему пункту:
Читай чужой код
Самая большая ошибка, которую только можно сделать идя по пути разработки — совершать этот путь в одиночку. Разработка программного обеспечения — это в значительной степени командная работа. Мы вместе создаём стандарты, вместе делаем ошибки и, наперекор всем неудачам, вместе становимся лучше. Время потраченное на чтение чужого кода окупится сторицей. Только убедитесь, что это хороший код.
Ну а лучший совет, который я могу дать — никогда не стыдитесь, что чего-то пока не знаете. Как уже было сказано, наша отрасль огромна, а количество технологий необъятно. Требуется много времени и усилий, чтобы выстроить общую картину, ещё больше, чтобы стать профессионалом в чём-то конкретном, и на порядок больше, чтобы отточить мастерство в своей области. Я дам вам знать, когда сам добьюсь этого.
Комментарии (53)
FForth
18.06.2019 11:58Нестареющие основы понимания базиса программирования.
«Cпособ мышления — Форт язык и философия для решения задач» (автор Броуди) -1984гBookvarenko
19.06.2019 01:12И песочница, где можно попробовать знания теоретические в рисовании практическом forthsalon.appspot.com
assembled
19.06.2019 15:30Ну это не форт, это просто какое-то примитивное постфиксное нерасширяемое говно.
amarao
18.06.2019 12:07Очень нагляные неправильные примеры. Я понимаю, что учительница хотела показать как сложно программировать компьютеры, но истинная сложность — она не в чрезмерной подробности. С этим люди давно справились. Истинная сложность — в том, что для того, чтобы справиться с избыточной подробностью нижних слоёв, верхние используют абстракции. Очень абстрактные абстракции, которые абстрагируют понятие абстракции в отношении абстрактных понятий. Это очень сильные механизмы, но их понимание требует перестройки мозга.
Потому что простому обывателю очень трудно объяснить, что такое обобщённый ассоциированный срок жизни для обобщённого типажа, и какая невероятная от него польза при реализации обобщённых типажей для итерируемых типов с внутренней мутабельностью.
Revertis
18.06.2019 14:01Истинная сложность — в том, что для того, чтобы справиться с избыточной подробностью нижних слоёв, верхние используют абстракции. Очень абстрактные абстракции, которые абстрагируют понятие абстракции в отношении абстрактных понятий.
Значит вместо «возьми ложку» надо будет приказывать «возьми столовый прибор, подходящий для зачерпывания жидкой пищи».
А вообще, пример с мороженным действительно не совсем верный, ибо учительница не дала список предметов, которыми можно манипулировать и список возможных действий над ними. Если бы студенты видели перед собой эти списки, было бы намного проще понять, насколько точным надо быть, без выдумывания.
0xd34df00d
18.06.2019 16:15Так что на самом деле нужно изучать алгебру.
Потому что простому обывателю очень трудно объяснить, что такое обобщённый ассоциированный срок жизни для обобщённого типажа, и какая невероятная от него польза при реализации обобщённых типажей для итерируемых типов с внутренней мутабельностью.
Или простую рекурсию.
vlreshet
18.06.2019 18:33Абсолютно согласен. Учитель не объяснила насколько низкоуровневой должна быть «программа». Может нужно было вообще указывать в стиле «напрячь мышцу руки номер 1, держать в напряжённом состоянии 4 секунды, ослабить напряжение», вместо «взять ложку». Лучше было бы показать этим примером что при достаточно подробной инструкции, любой из учеников может теперь приготовить точно такое же мороженное, используя эту инструкцию. Что показало бы одну из основных целей программирования — автоматизация процессов.
JerleShannara
18.06.2019 18:37Однако почему-то почти первокурсники, которые писали на делфи, у меня посыпались на «обломись» is not an integer и делении на ноль.
AVI-crak
19.06.2019 00:32Истинная сложность — в том, что для того, чтобы справиться с избыточной подробностью нижних слоёв, верхние используют абстракции. Очень абстрактные абстракции, которые абстрагируют понятие абстракции в отношении абстрактных понятий.
Это справедливо для базовых типов, подмена чего-то трудно произносимого на более простое — в этом вся суть абстракции. Теперь вам нужно помнить две вещи: новое название, и его старый вариант. При этом новая абстракция не описывает возможности применения, а всего-лишь ограничивает возможные действия. Когда таких переименований становится ощутимое количество — теряется сам смысл в новых изобретениях.
Использовать абстракции для нижних слоёв — означает продолжение работы с нижним слоем под новыми именами. Это не эффективно и глупо. Все алгоритмы нижнего слоя должны оставаться там-же, на нижнем слое. А вот для верхнего слоя можно уже и своё придумать. В идеале — замена нижнего слоя не должна ломать систему. Таких слоёв может быть множество, и каждый из них можно заменить на аналогичный по функционалу.
При этом нижний слой должен терять видимость, также как и слой выше. А абстракции — это просто оправдания для написания новых фреймворков.
sbnur
18.06.2019 12:11А что такое фундаментальная логика — базовых (то есть фундаментальных) подходов к логике множество.
movl
18.06.2019 15:25Думаю для европейских народов, фундаментальной верно будет считать аристотелевскую логику.
sbnur
18.06.2019 15:55Это вы так думаете, Твардовский и Лукасевич имели противоположные точки зрения на понятие фундаментальной логики
movl
18.06.2019 19:11Я Вас услышал. Но попытался обозначить критерием фундаментальности не смысл, а происхождение, в таком случае не требуются философские обоснования для подобного словосочетания. Это словосочетание является допущением переводчика, в оригинале автор ограничился просто логикой. И мне видится, что автор не претендует на какой-то глубокий анализ в вопросах мышления, а таким приемом просто эпатирует читателей.
sbnur
18.06.2019 19:54+1Понял — не обратил внимание, что это перевод. иначе пропустил бы это сауронство
SPAHI4
19.06.2019 00:30Что это перевод было понятно, когда на информатике оказалось мороженое :)
Это слишком хорошо для наших школ, да и, наверное, не по ТБsbnur
19.06.2019 00:40Ну почему же — нас в первом классе на первой перемене поили горячим молоком, на второй какой-то полезный сироп, а на третьей рыбий жир
dss_kalika
18.06.2019 13:58Спасибо.
Долго пытался сформулировать чего не хватает людям (менеджерам, операционисткам, начальникам), которые проходят курсы SQL, VBA или ещё чего то, а потом… понимают, что не понимают как этим пользоваться.
worldmind
18.06.2019 14:44Урок интересный, а потом пошла лабуда, фундаментальные знания конечно важны, но это далеко не только про асимптотическую сложность, это скорее про теорию категорий, лямбда исчисление, методы формальной спецификации и верификации и много чего ещё, что делает программиста-кодера программистом-инженером. А знание паттернов это просто ремесленный опыт, а не наука.
MockBeard
18.06.2019 16:49такое наглядное объяснение логики на мороженом — восхитительно!
JerleShannara
18.06.2019 18:49Алгоритмизацию можно ещё на примере задачи «спуститься на лифте на первый этаж» с полной проверкой входных данных объяснять.
vlreshet
18.06.2019 19:05Упал в шахту лифта — значит не освоил?)
JerleShannara
18.06.2019 19:21Это один из вариантов выхода с segmentation fault =)
Ещё есть «убило током — не освоил»
iago
18.06.2019 17:43+1Моей первой книжкой по программированию тогда можно считать «Энциклопедию профессора фортрана», там была
похожая на мороженое задачка, но про картошку
Fedorkov
18.06.2019 18:43Будучи американцем, автор не догадался добавить про важность английского языка.
Ermit
18.06.2019 18:53Проблема инструкций в том, что невозможно точно и полно описать явление текстом.
В этом отличие программирования от феноменологии… )))
ehots
18.06.2019 20:09Какие-то очевидные вещи поясняет автор.
У меня в самой обычной школе были алгоритмы на уроках информатики и только после уже немного кодинга в бейсике. Не раз сталкивался с утверждением что программирование — описание инструкций, которые выполнит компьютер.
Может конечно ситуация в странах очень отличается, но я учился в Казахстане, в России обучают в школах еще лучше программированию, по моим наблюдениям.
funca
18.06.2019 23:06Англоязычные сайты кишат подобным контентом. Несколько произвольно выбранных утверждений на тему предметной области — статья готова. Не знаю кто и зачем их пишет.
vedenin1980
19.06.2019 11:00Зачем понятно. Любая статья это рекламные деньги, строчка в резюме и т.д. Если сложную техническую статью можно несколько месяцев писать, да и интересна она будет десятку человек в мире, то такое можно строгать сотнями за неделю, а начинающих всегда больше, чем экспертов. Просто такой бизнес, на грани поискового спама, ничего личного.
411
18.06.2019 21:11Последний пункт был особенно важен, так как без него, в предпоследний раз учительница просто начала есть моё мороженое.
На это моменте я очень долго и громко смеялся. Хорошо никого дома не было.
Source
18.06.2019 22:13Учительница, видимо, подустала играть в компьютер, поскольку итоговый алгоритм всё ещё никуда не годится )))
Возьми ложку для мороженого и один за другим положи три шарика малинового мороженого в миску.
Что-то непонятно… А где взять шарики малинового мороженого? Где фабричный метод их создания?
Возьми банку с шоколадным соусом, зачерпни соус и вылей в миску содержимое столовой ложки.
Зачерпни соус чем?
Возьми и переверни вверх ногами упаковку взбитых сливок и, держа её над миской, поливай ими мороженое 3 секунды, после чего верни упаковку на место.
Прям вот так вот вверх ногами и вернуть упаковку на место?
third112
18.06.2019 22:28+1Прочитав про мороженое вспомнил анекдот «как математик решает задачи»:
Первая задача.
Дано: чайник, вода, плита.
Нужно: вскипятить воду.
Решение: налить воду в чайник, включить плиту, поставить на нее чайник, когда вода закипит — выключить плиту.
Вторая задача.
Дано: что и в первой задаче, но в чайник уже налита вода.
Нужно: вскипятить воду.
Решение: вылить воду из чайника, тогда мы приходим к задаче, которую уже знаем, как решать.
arielf
19.06.2019 00:42Всё правильно автор пишет — иначе получается полный позор! Парни, 217 Mb на страницу, в которой нифига функций, вы серьёзно? И всё, что они посоветовали — юзать Chrome, а не Firefox!
AVI-crak
19.06.2019 01:06-1Не совсем понятно при чём тут логика, и зачем её нужно думать. Весь программный код пишется с одной целью — скрыть ту самую логику как можно глубже, чтобы сверху осталось простое и понятное действие.
Вы пишите новый код с использованием имеющихся библиотек, и ваш алгоритм уже уникальный. Для уменьшения ошибок все внешние действия с вашим кодом должны быть простыми и понятными. Так можно продолжать почти бесконечно, вот только жирность от этого растёт…
Средство для уменьшения жира существует, и это не абстракции — как может показаться на первый взгляд. Это описание типов данных с помощью перекрёстных ссылок. Может это иначе называется, но применяется именно так.
Смысл в том, что в стандартном варианте например возраст человека имеет одно ограничение — число должно быть целым без знака. Можно написать 0, можно написать 1000, в структуру эти числа запишутся без каких либо проблем.
Тип с перекрестными ссылками сначала проверит существование имени, опа — вариант «неизвестно», потом проверит даты рождения и смерти, и если человек ещё жив — то автоматом считает местное время и пропечатает возраст. При этом перекрестные ссылки — это ограничения и список возможных действий с выбранным типом, которые выполняются автоматически, без лишнего кода со стороны пользователя.
И это не абстракции!!!
Это чуть сложнее, для понимания можно заглянуть в описание типов чисел с фиксированной точкой.
IvanGanev
19.06.2019 05:17Самый полезный язык для программирования это английский — все документации пишут на инглише, почти все ридми пишут на инглише, комментарии к коду обычно пишут на инглише, да и сам код почти любого языка программирования состоит из английских слов, самый полезный контент по разработке на инглише ну и тд.
Можно сколько угодно играть с абстрациями, но если вы не можете просто взять и прочитать что умеет делать эта библиотека с гитхаба — то вы так себе разработчик.dss_kalika
19.06.2019 12:13А можно ссылку на библиотеки для MS SQL с гитхаба, пожалуйста?
С удовольствием почитал бы.
IkaR49
19.06.2019 08:52А объясните балбесу, почему поиск по хэш-таблице имеет сложность О(1)?
me21
19.06.2019 09:16Ну смотрите. Поиск в массиве — это когда вы ищете, например, ботинки, последовательно открывая обувные коробки. А в хэш-таблице — это когда вы заранее прикинули, что ботинки зимние, коричневого цвета (то есть на основе самого искомого объекта вычислили его хэш — какую-то его краткую характеристику), а значит, они лежат вон в той коробке, где написано "зимние коричневые", в остальных искать не надо.
Программный хэш может и не иметь какого-то осмысленного значения, но поиск он ускоряет точно так же.Ndochp
19.06.2019 10:02Только нужно помнить про очень грустный момент с памятью. Пусть у нас 100 элементов в массиве, и хэш таблица на 200 элементов, в которую мы запихнули те же 100 элементов. Первично получается 15-17 коллизий, которые ведут к цепочкам вторичных. Если мы пишем не просто в следующую свободную ячейку, а устраиваем какой-то «рандом», то при чтении нужно еще и помнить все номера ячеек, которые мы просмотрели, чтобы не выпасть в цикл.
Хэш таблица размером в 100 кажется будет по скорости почти массив уже.
В общем, это конечно не линейно, но и не 1. Вот сколько — посчитать я затрудняюсь.Fedorkov
19.06.2019 11:09Маленькие хэш-таблицы в любом случае медленнее маленьких массивов из-за накладных расходов.
Ещё тут важно отношение количества данных к числу ячеек хэша. В Джаве по умолчанию хэш-таблица увеличивается и пересчитывается, как только это отношение достигает 0.75 — это считается оптимальным балансом скорости и занимаемой памяти для большинства задач.
vedenin1980
19.06.2019 11:16Не совсем понял, что вы хотите сказать. Если у нас есть 200 ботинок, а хеш-таблица только на 100 значений, очевидно вы никак не сможем извернуться и дать каждому ботинку отдельную строчку в хеш-таблице, но если хеш функция достаточно равномерная, то в каждому хешу будет соотвествовать 2-3 коробки с обувью. Просмотреть 3 коробки последовательно конечно медленее, чем одну, но все-таки достаточно быстро. Тут главное, чтобы хеш функции были хорошие и объем хеш-таблицы был все-таки достаточно большой для наших данных.
Сложность алгоритма будет все равно O(1), потому что все что не зависит от кол-ва элементов будет иметь константную сложность (хотя с практической точки зрения два алгоритма с одинаковым O(сколько-то) могут выполняться за очень разное время, иногда в десятки и сотни раз отличающееся).Ndochp
19.06.2019 11:49Я привел цифры для 100 ботинок и 200 коробок. Если у нас 100 ботинок и 100 коробок, то уже после первой смены сезона в «зимние коричневые» лежат босоножки.
Сложность алгоритма будет зависеть от N — числа размещенных элементов и M — числа строк в таблице. Если размер таблицы неограничен, хэш идеальный (без коллизий), то будет О(1), мы сразу получаем правильную ячейку, расплачиваясь кучей пустого места. Если таблица ограничена (в пределе М=N), а хэш идеален только в смысле того, что для каждого элемента даёт равномерное распределение адреса от 1 до М, то единичка начинает расти, характеристика роста зависит от среднего числа коллизий, которое зависит от соотношения M и N, но скорее всего не пропорционально M/N а по более сложному закону.
Ну и писать становится все сложнее — в пределе так же сложно, как и искать. Так как каждая запись это поиск пустого места.
Arastas
19.06.2019 12:01Я, конечно, совсем вообще не програмист и не алгоритмист, но мне кажется, что сложность описанной вами реализации будет линейная вида O(n/N), где N — количетво строк в хеш таблице. То есть поиск по трём коробкам-то всё равно линейный?
vedenin1980
19.06.2019 12:55То есть поиск по трём коробкам-то всё равно линейный?
Если мы увеличивая N соответвенно увеличиваем хеш-таблицу, то поиск не будет зависить от N, следовательно сложность O(1), но требования по памяти будет O(N). Тут надо понимать, что O(...) говорит о том зависит функция от кол-ва элементов, но не говорит о практической сложности самого поиска.
Busla
19.06.2019 11:15Потому что это неправда :-)
И вы скорее всего подразумеваете не поиск, а извлечение элемента по его id.
Это идеализированный случай, в котором речь скорее про enum — вопрос изменения мы не рассматриваем, а хэш-функция идеальна. Реальная хэш-таблица обычно имеет коллизии. И в самом неудачном случае всё возвращается к обычному поиску.
AnROm
19.06.2019 11:35Самым первым языком программирования в институте у нас был язык С. На практических занятиях препод давал задания и заставлял сначала писать псевдокод для представления алгоритма. Так было два семестра. Точно помню, что в первые разы у нашей команды из двух человек не получалось это выполнить за два-три подхода. Студенты негодовали, говорили, что в этом нет смысла. Если честно, я тоже разделяла их мнение. Оценила этот подход только под конец учебы в институте, когда обащась на работе с другими студентами, и у многих из них действительно были проблемы с составлением алгоритмов и учетом в них очевидных вещей. Так что все было не зря.
А использование мороженки для обучающих целей это интересно ))
mamont80
19.06.2019 17:40Я так и матёрого программиста могу затролить. Сделай HTTP запрос. А ты сокет открыл? А URL распарсил? А откуда я знал что порт по умолчанию 80-й? А HTTP-протокол надо сначала завернуть в Ethernet протокол. А MAC-адрес ты узнал свой сначала? А куда ответ придёт? А откуда я знаю куда посылать байты, надо драйвер сетевой карты написать. И так далее, пока не опишем браузер, ОС, сервер, драйвера, ассемблер, процессор, все протоколы, кодирование в оптоволокне и не опустимся до электоронов.
jetcar
20.06.2019 08:46Рынок настолько насыщен выпускниками институтов и курсов, что позиция джуниора практически перестала существовать
а можно узнать это в какой стране? говнокодеров после универа да полно, но из них хороших программистов лет через 5 останется очень мало, а остальные либо перейдут чем-то другим заниматься или так и остануться говнокодерами
а про логику отдельный разговор, это как сказать что инженеры должны учить только физику и химию, кроме этого есть дохера опыта разработок которые тоже надо изучить и без них зная только физику и химию такой инженер никому не нужен, потому что он будет изобратаь колесо не зная что уже всё зделано до него, разве что изначально талантлив и интуитивно будет придумывать только хорошие решения которые лучше имеющихся
DesertFlow
Нууу, это спорно. Вот пример из жизни: можно быть прекрасным программистом, легко понимать и запоминать длинные алгоритмы, с ветвлениями и прочим. То есть, фундаментальная логика развита. Но при этом быть полностью неспособным запомнить мелодию из пары десятков нот. Хотя они такая же логическая последовательность из следующих друг за другом атомарных элементов (даже короче большинства программ!). Присутствуют даже пара простых циклов в виде припевов.
А значит дело тупо в тренировке и опыте. А не в фундаментальной логике. Она конечно помогает в задачах, родственных алгоритмам. Но есть подозрение, что это тоже дело тренировки. Например, для аргументированного спора надо знать критерий фальсифицируемости и другие подобные логические приемы, которые в программировании вообще никак не встречаются. Другая область, другие «фундаментальные логики», как они описаны в статье. Так что универсальный язык вряд ли получится. Просто все существующие языки программирования очень похожи, что облегчает переход между ними.