Индустрия программного обеспечения постоянно учится, и это одна из причин, почему программное обеспечение является одновременно моей работой и моим хобби. Многие из нас, профессионалов, пришли к этому как к хобби, многие пришли к этому из-за необходимости другой работы (манипулирование сложными таблицами Excel), а есть те, кто пришел к этому через академические круги. Поскольку наша профессия так молода (менее века), мы все еще учимся друг у друга в разном опыте. Это дает нам преимущество и проклятие в том, что мы можем заново хэшировать старые идеи, выделяя «лучшие» части и повторно используя их совершенно по-новому.
Однако некоторые вещи остаются неизменными. Именование сложно. Обработка исключений сложна. Кеширование сложно. Решение проблемы (особенно до того, как вы ее узнаете) сложно. Прочитать код другого разработчика (или свой собственный через год) может быть сложно.
Проблема, которая была у меня в голове в последнее время, заключалась в именовании, и мне нравится решать ее с помощью предметно-ориентированного дизайна. К сожалению, я давно не читал книгу Эрика Эванса, поэтому я не слежу за ней так внимательно, как мог бы когда-то. Я также много размышлял о функциональных и объектно-ориентированных языках, так как взаимозависимость между ними, кажется, существует почти с самого начала вычислений.
Многие из одних и тех же терминов используются немного по-разному в разных языках и даже в разных языковых типах. Так почему это так? Что ж, что интересно, все сводится к языку ... и я действительно имею в виду разговорный язык, а не кодированный язык.
Что на языке?
Лично мне нравится, что мое программное обеспечение действительно может читать как список инструкций, которые можно прочитать вслух и которые имеют смысл:
if (system.hasErred()) {
system.recover();
} else {
system.handle(command);
}
В этом совершенно произвольном примере вам все равно нужно понимать, что синтаксис подразумевает слово «затем», но мы часто делаем это, когда программисты все равно разговаривают с программистами. (Я, по крайней мере, не произносю каждую скобку.) Вы также заметите, что вызовы подпрограмм, не имеющие побочных эффектов, имеют в именах глаголы связывания («имеет», «есть» и т. Д.); он очень ясно дает понять, что у вас не будет побочного эффекта, поскольку в противном случае это глагол, который имеет тенденцию подразумевать, что действие имеет место.
Моя первая борьба с функциональными языками заключалась в том, что я чувствовал, что говорю как Йода, когда я читал это вслух:
if(hasErred(system), recover(system), handle(command, system))
Но потом я вспомнил кое-что из моего языкового фона за пределами информатики, и что не все языки ориентированы как субъект-глагол-объект. Фактически, сама природа объектно-ориентированных языков проистекает из того факта, что мы пытаемся сделать их предшественников более естественными для наших англоговорящих ушей. Иногда мне кажется, что мы еще не достигли цели, особенно когда английский в основном предметно-ориентированный, потому что актер идет первым; объект - это то, на что воздействуют.
В английском есть такой тип утверждений, в которых субъект берет задний план, а объект получает больше внимания: это императивные утверждения. Оказывается, еще одно название процедурных языков - «императивные» языки. В «императивных» утверждениях на английском языке подразумеваемое подлежащее: «вы» не учитывается. В этом случае «вы» относится к процессору, программе или системе в целом, поскольку мы инструктируем компьютер.
if (hasErred(system)) {
recover(system);
} else {
handle(command, /*on:*/ system);
}
Это впечатляюще похоже на наш пример функционального языка. Оглядываясь назад, можно сказать, что «функциональные» языки можно было бы назвать «ориентированными на глаголы», если бы мы не убрали название «функция» из математики. С другой стороны, «глагол» подразумевает нечто очень отличное от «функции», поскольку глаголы имеют побочные эффекты, тогда как в математике функции никогда не имеют.
Вывод
После того, как вы уберете реорганизацию из-за грамматики, языки станут намного более похожими, и вы сможете начать говорить о других основных функциях (таких как неизменяемость, исключения, асинхронность, нулевые значения, операторы как выражения ...) и обо всех преимуществах и боль, которую они могут причинить. Однако хотя бы потому, что вы по-другому ориентируете свой ум, проблемы могут стать легче или сложнее. Я считаю, что можно взять принципы, изученные в одном типе языковой грамматики, и использовать их в других языках с другой грамматикой.
В наши дни хорошо быть программистом-полиглотом, так как в конечном итоге вы создадите лучший код в целом. И не ограничивайтесь одной рамкой; Во всех них есть хорошие вещи, будь то Java, Node, .Net или многие другие, и различия в базовой структуре действительно могут помочь вам в обучении!
