Pull to refresh

Comments 34

*немного душноты*

В JS и TS на первом фото скобки у метода log пропущены, такая конструкция не будет работать

Ну и я побуду душнилой за компанию=)
Про R
Указан метод Cat - с лишними телодвежениями в лице "\n"
По факту можно использовать как print("Hello world") так и отсутствие оных, т.е. "Hello wold" (в кавычках ессно) - отобразится в коде как при том-же принте

Если же говорить о Вашем совете изучать что-то новое - это один из самых частых советов (не только в сфере IT). Попробую изложить как это вижу

Человек, на протяжении своей жизни учится. Любой навык который мы приобретаем может изначально даваться нам не просто, но со временем мы адаптируемся, откладывая некий шаблон в голове, к которому мы обращаемся сталкиваясь с повторной (или аналогичной) ситуацией. Как пример - есть ложкой, мы учимся, роняем, попадаем мимо рта, но со временем доходит до автоматизма. Однако знакомство с еще одним столовом прибором (вилкой например), не приводит к тому, что мы заново ее роняем, попадаем мимо рта и прочее. У нас сохранилась база с ложки, однако если ложкой мы черпали, то вилкой мы уже можем насадить продукт, приобретая новый навык.
Понятно что пример простой, но тут посыл именно того, как расширение кругозора влияет на наши навыки. С ЯП естественно тоже самое. Главное понимать - нужен ли нам навык/опыт или же его можно пропустить (не всегда к слову мы можем понимать что получим, начиная изучать что-то новое)

*еще больше душноты*
Да честно говоря с остальными языками на картинке дела обстоят не лучше. Это что за #include пустота в C и С++, может хотя бы stdio.h или iostream? А еще блоки в несколько раз больше чем на остальных языках. Мне вот как плюсовику обидно сейчас.
А ничего что на java нужен как минимум main() и класс? И о удивительно, тогда бы вдруг по размеру уже бы было сопоставимо с блоками с C и C++. И вы бы уже не смотрели в сторону java будь вы человеком не знакомым с языком, а ориентирующемуся по "меньше писать - значит проще и лаконичнее" в выборе языка.
Короче, ничего не хочу сказать про статью, но такая картинка с "инфографикой" с ошибками и допущениями вводит в заблуждение, ведь дальнейшая статья как раз и рассказывает про выбор языков одних на фоне других.

А если допустить что вид кавычек поменялся от типографики, и в оригинале были обратные апострофы, то работать будет, не очень адекватно, но это уже будет не ошибка синтаксиса...


console.log `Hello` // вывод: ['Hello', raw: ['Hello']]

Это подсветка синтаксиса скобки сравняла с фоном.

У Свифта println давно заменён на просто print. И точка с запятой не нужна.

IMHO: для этого и вставляют картинки с ошибками

Они просто невидимым цветом написаны!

Для расширения кругозора лично я бы посоветовал хотя бы поверхностно попробовать последующее:

  • C

  • Самую малость ассемблера и глянуть во что транслируются простейшие компнды С

  • Глянуть интерфейс С с вашим любимым языком программирования, если это возможно

    Это позволит лучше понять не просто языки, а то, как внутри все устроено и как колесики цепляются друг за друга.

UFO just landed and posted this here

Он написан на Си ведь, операционка написана на Си, Си транслируется в ассемблер и машинные коды. Это не поможет понять сам Хаскель, это поможет понять, как Хаскель взаимодействует с системой и с железом.

UFO just landed and posted this here

Просто это другая часть кругозора.

Есть обратная сторона у этой медали, она называется "работа в команде". Когда ты весь такой прошареный в разных языках и парадигмах и начинаешь применять подходы, не свойственные (а чаще - просто неуместные) для подавляющего большинства кода на каком-то языке, а иначе говоря просто "пишешь не так как остальные", то такой код очень сложно потом поддерживать командно. Иногда и просто невозможно. У любого "нативного" разработчика будет сразу же возникать непреодолимое желание все переписать.

У любого разработчика всегда возникает желание "все переписать". Потому что даже если изначально всё было спроектировано на 100% отлично, то при последующих доработках вся эта стройность, как правила, начинает ломаться. И когда доходит до стадии "всё, это фичу уже хрен вставишь", то всё и переписывают.

Я даже больше скажу, если ты начинаешь писать не так, как это принято в команде по своей инициативе - к тебе ОБЯЗАТЕЛЬНО возникнут вопросы.

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

В C и C++ с картинки выше будет ошибка компиляции.

В Go зачем-то точку с запятой поставили.

Когда-то (очень давно) я как и все начинающие разработчики тоже считал, что мантра "знаю <какой-то> язык программирования" это то, что делает меня профессионалом. Что это именно то, что требуется потенциальным работодателям, и вопрос состоит лишь в том, насколько хорошо я знаю этот <какой-то> язык программирования (лучше или хуже других кандидатов).

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

С течением времени стало очевидно, что знание ЯП не столь уж важно и в какой-то момент начинаешь понимать, что на освоение того или иного ЯП у тебя занимает несколько дней, а после месяца-другого его использования он становится привычным, как будто использовал его много лет (хотя это и не означает, что освоил его в совершенстве. Просто это совершенство как правило никому не нужно). И тогда на первый план выходят другие вопросы:

1) насколько тот или иной ЯП мне нравится?

2) могу ли я его применить, чтобы увеличить свой доход?

Понятное дело, что дла того, чтобы вообще иметь возможность отвечать на эти вопросы надо бегло ознакомиться с предметом оценки. Что на мой взгляд делает любой мой коллега (рано или поздно) в отношении любого ЯП который попадает в его поле зрения - просто бегло знакомится с его основами

Однако любой мой коллека прекрасно понимает, что кроме ЯП существуют заявянные на него фреймворки и библиотеки и значительная доля опыта разработчика относится к их использованию - мало кто ищет просто js/ts разработчика для фронтенда - как правило интересубтся теми кто имеет опыт работы с react/angular/vue итп (ну или хотя-бы тех, кто уверенно скажет, что он готов освоить это в кратчайшиые сроки). Но и это часто не самое гдавное - экспертные знания в той или иной предметной области часто гораздо важнее ЯП и библиотек/фреймворков. А кроме этого различные смежные области знаний тоже могут иметт существенное значение - ну скажем опыт работы с.. назовем это devops (не люблю этот термин ибо он фактически ничего конкретного не означает, но даже написать Jenkins pipeline по моему опыту могут единицы, что делает такой опыт чрезвычайно востребованным) - это не говоря уже об уверенном владении k8s, ansible, terraform, aws/gce/azure - это то, что реально поднимает планку дохода вне зависимости от каки-х то ЯП (а может стать и новой профессией)

Собственно автор пишет примерно о том-же, хотя и не осознает этого - в данном случае имеет значение опыт работы с Unreal Engine в дополнение к общему стажу работы в отрасли в тои числе и в качестве разработчика. Именно Unreal Engine здесь определил востребованность автора а не какой-то там C++. Если бы автору понравилось он бы вошел в gamedev и далее развивался бы там - опять-же не обязательно с C++ или даже с Unreal Engine - посдеднее это лишь специализация в довольно большой предметной области GameDev

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

А можно в двух словах, чем программирование графики не понравилось? Или может геймдев в целом не подошел, как направление развития?

Ну тогда немного душноты и от меня. Delphi: То, что написано на картинке, будет компилироваться, но при запуске будет сразу отрабатывать и закрываться, мгновенно. Чтобы увидеть свой "хелловорлд" нужно хотя бы вот так:

program Cons;
{$APPTYPE CONSOLE}

{$R *.res}
uses
System.SysUtils;
begin
Writeln('Hallo WRLD!!!');
ReadLn;
end.

А вообще Delphi, вроде как изначально для создания GUI использовался. Зачем консоль то мучать?

Нет. Подключение ресурсов не обязательно. AppType тоже не обязательно. writeln и readln доступны без подключения модулей дополнительных функций, это функции-интринсики стандартной библиотеки, можно так сказать.

Блин, снимаю шляпу. Плюсанул бы, но кармы нет.

Program Project1;

begin

  Writeln( ': ');
  ReadLn;

end.

Работает. Спасибо. Тогда только Readln

К слову program XXX тоже не обязательно, насколько я помню.

И правда, я прямо "взорнул" от приятного удивления. Спасибо, мелочи, а приятно знать...

>Существуют десятки языков программирования.
Автор сильно отстал от жизни. Десятки их было примерно в середине 80-х, причем мы как-то составляли список, куда вошли только языки, с которыми мы имели хоть какое-то дело на практике, то есть, у нас был компилятор, мы запустили хотя бы одну программу, и т.п. — вот только таких было под сотню на двоих. И да, там не было 10 штук ассемблеров, минимальное отличие это Fortran-IV и Fortran-77 — а это таки два серьезно различающихся языка.

А на сегодня я думаю языков вполне возможно десятки тысяч.
UFO just landed and posted this here
Да я в общем особо и не претендовал, там «вполне возможно» написано именно поэтому (а лезть искать ответ было лениво). Я скорее про то, что оценка в десятки — ну явная лажа. И да, тут вообще сложно сказать, какой-нибудь DSL — это отдельный язык, или нет? Когда я впервые собирался реализовать LL(1), выбор инструментов был по сути из одного, lex да yacc, сейчас же и инструментов стало столько, что человек со средней квалификацией вполне может свой язык сделать за короткое время. Не напрягаясь особо.

Когда-то я сел подсчитывать, сколько разных языков программирования мне приходилось использовать в жизни. Что-то полезное я писал, кажется, на 15 разных языках, а "потрогать руками" пробовал 20+. И вот что я вам скажу. Языков много, но подходов к программированию, по сути, всего три: функциональное, императивное и другое (тут я смешиваю в одну кучу декларативное и всю экзотику типа verilog/VHDL). Изучив несколько языков, но применяя в них только, например, императивный подход, вы не вырастете ни на миллиметр, развитие, оно не в том, чтобы запомнить новый синтаксис и научиться запускать компилятор. Изучайте не языки, изучайте парадигмы.

Мне кажется, насчет «другое» вы слегка упрощаете — все-таки, парадигм чуть больше трех. В конце концов, лисп и скажем Haskell — это функциональщина и то и то, но вы же не будете всерьез утверждать, что изучив один после другого вы ничего нового не узнаете? Я не думаю, что парадигм сильно больше, но например типизация добавляет второе измерение к этим трем, скорее всего.

Изучать новое всегда полезно, кто бы спорил. Просто в слово "изучать" разными людьми вкладывается разный смысл. В том же Lisp можно такой фортрановский код писать при желании, что ой. Джун, успешно запустивший написавший программу на Scheme и запустивший ее может сказать "я изучил Scheme", но, фактически, может оказаться, что он выучил только синтаксис, а о существовании функционального подхода даже и не догадывается. Изучать надо не Scheme, а SICP, вот что я хотел сказать.

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

Знать другие языки полезно хотя бы для того, чтобы в холиварах выглядеть как человек в теме и со знание дела наезжать на языки, на которых не специализируешься [/sarcasm]

Sign up to leave a comment.

Articles