Comments 310
UFO just landed and posted this here
Представь, ребята выбирают сейчас какой язык программирования учить. А нужно-то совсем не об этом думать :-)
UFO just landed and posted this here
Без знания хоть каких-то языков думать-то будет особо не о чем. Или надо думать как собеседование пройти, что учить — покажут?
Собеседования — отдельная тема. Часто спрашивают отвлеченную ерунду, которая не нужна в реальных проектах.
"Хоть какие-то языки" — это месяц на первый и по неделе на каждый последующий (во всяком случае, в рамках императивной парадигмы). Это если никуда не спешить, конечно.
В php, python, js можно прямо быстро въехать и даже писать что-то полезное очень стремительно. А вот с C++, java там, конечно, месяцы… Но стоит ли оно того?
Не всем надо быть Александреску. А до уровня "C с классами" — та самая неделя, и это покрывает бОльшую часть потребностей (лично мне не хотелось бы разгребать ко за джуниором, увлёкшимся метапрограммированием на темплейтах).
Но в крестиках та же дилемма что в java — куча классов и абстракций, вот пишешь пишешь, тесты пишешь пишешь (если время дают), бац и отвлекся. Потом открываешь — вау, вау, столько кода. Блин, ничего не понятно, страшно запускать. А так открыл скриптик на 1000 строк и в нем вся бизнес-логика с комментариями.
Так абстракции предназначены именно для борьбы со сложностью.
Да. И ООП — методика борьбы со сложностью. Но получается, что… ты как-бы теряешь контроль, контекст, не помнишь что внутри что вызывает. Вот сделал ты объект, определил для него операции, вызываешь их, затем еще и еще. А можно было скриптом и обычным встроенным словарем это решить и более наглядно и читаемо. Пост как раз про это — про то, что никто пока не знает, что делать.
Не нужно смотреть внутрь без острой на то необходимости. Оно просто будет работать. А статические проверки компилятора еще и проверят, что по пути не вкралась гнусная очепятка.
Невероятную ерунду можно сделать и в скрипте. А оправдывать преимущество скриптов меньшим количеством логики — это… достаточно странный аргумент) Мне кажется, тут стоило бы добавить какой-то конкретики.
Невероятную ерунду можно сделать и в скрипте. А оправдывать преимущество скриптов меньшим количеством логики — это… достаточно странный аргумент) Мне кажется, тут стоило бы добавить какой-то конкретики.
UFO just landed and posted this here
Да, и если разобраться — JS при всей своей внутренней и кажущейся внешней (кажущейся — потому что в нём примерно всё не так, как думают новички) простоте позволяет наворотить не меньше сложностей, чем плюсы. Простым он остаётся лишь при соблюдении строгой дисциплины...
Не путайте языки, стандартную библиотеку и всю экосистему.
не понял, что я путаю?
Языки как праивло изучить легко (C++ на уровне С с классами), сложнее со стандартной библиотекой, а ещ' сложнее со всей єкосистемой разобраться, например Spring в Java сложнее самой Java :)
:-) мне с библиотеками обычно проще. А спринг да, это песня
UFO just landed and posted this here
UFO just landed and posted this here
UFO just landed and posted this here
UFO just landed and posted this here
UFO just landed and posted this here
UFO just landed and posted this here
UFO just landed and posted this here
Да, так эволюционирует язык. И то, что в каком-то дремучем легаси используется new и delete и всё работает — это прекрасно, ведь можно прийти и малой кровью это переписать.
В новом коде их использовать почти никогда не надо, за исключением специфических случаев, типа Qt, где другая модель управления памятью, чем в современном C++.
Я учил по 2-му изданию Страуструппа. Кажется сейчас это называется «С с классами».
Не путайте языки, стандартную библиотеку и всю экосистему.Многие так говорят, как будто язык в вакууме существует. Всегда стоит оценивать всю экосистему.
Слишком много теста! Нужно больше картиночек!
Картинки, не критически важные для основного смысла статьи, надо запретить к чертовой матери. Максимум — КПДВ. Ну это же не Пикабу, в самом деле-то, а?
А что я не по теме поставил? :-)
А зачем они? Это-же не комикс.
Статю не читал, решил сразу окунуться в трэш — нажал на комменты. По Вашей подаче поднялся до кдпв и ниже. Вот это трэш. Короче, так нельзя — я не про картинки, а про посыл статьи (я сразу понял что все будет не так или наоборот именно так). Я даже комменты читать не хочу — ну холивар же будет, хотя, захоти я скоротать время отличное чтиво, готов поспорить. Автор ну тролль что-ли, хороший ход, а чё. Столкнуть лбами миллион программистов дорогого стоит.
Да погоди :-) Пост лучше прочитай. Дело не в троллинге — я проблему описал, свое видение отрасли. Никакого холивара, просто трезвый взгляд.
Я вот тоже наткнулся на картинки — и не стал читать, потом почитал коменты и тогда уже и статью =) Дурацкая мода последние годы — пихать картинки куда ни попадя, по теме или нет.
А статья, в целом, нормальная.
А статья, в целом, нормальная.
КДВП КДПВ рознь. Помнится одним моментов, которые отбили желание ходить на почивший Мегамозг, это были абсолютно дурацкие КДПВ, причём в большинстве случаев.
Да пожалуй уже Пикабу.
А как же www.1cpp.ru/index.php/Main — 1С++?
Парни, вы просто не слышали выступления Александра на HL++ и т.д. У него всегда полный зал, картинки на слайдах на самой тонкой грани и огонь-контент. Это очень привлекает аудиторию и позволяет спикеру втолкнуть в голову аудитории сложные вещи в нетрадиционной форме. Здесь та же история — и, конечно, картинки в тему (с поправкой на темный юмор) и сами тезисы заслуживают внимания. Не знаю, как вы, мне по кайфу было прочитать и в офисе обсудить. Мы ставим на бессмертные С++ и Java — зоопарк энтерпрайзных проектов поддерживать и допиливать предстоит ещё оооочень долго. И JavaScript c PHP — на них столько говнокода и годнокода, что жить и жить.
А без смищьных картиночек смысл статьи уже не донести? Человек вроде неглупый, пишет какие-то важные вещи, зачем это петросянство этот цирк с лабутенами и памперсами? Все эти смешнявки только отвлекают от тезисов и вызывают раздражение. Статью тупо неудобно читать. И неприятную ассоциацию с более другим сайтом, где хайрейтовые персонажи творят все, что угодно, не опасаясь быть слитыми.
UFO just landed and posted this here
Ну в хаскеле у нас структурная типизация: typescasses, с «а ля» множественным наследованием, хотя формально так нельзя говорить. Спасут конечно алгебраические типы данных, да. Но представь, сколько лет нужно учить людей писать на haskell? ;-)
UFO just landed and posted this here
Какая жесть! :-)
А в чем проблема в первом примере? Кроме того, что return {} не может вызывать explicit конструкторы
UFO just landed and posted this here
gcc8 для обеих функций жалуется на удаленный конструктор. Должен быть какой-то другой результат?
UFO just landed and posted this here
Да, так не жалуется. Я проверял на таком коде wandbox.org/permlink/opifRXDEydaAqd2i
Это такой способ написать GADT? Ну там как бы этим все не ограничивается.
Но ведь в хаскеле номинальная типизация, это не OCaml и не Elm.
Там ошибка, а приведённый сниппет в хаскеле невозможен. Ну вот же простой пример:
data Foo = Foo Int
data Bar = Bar IntFoo и Bar несовместимы, хотя имеют одинаковую структуру.
Между строк нужно читать, суть
en.wikipedia.org/wiki/Structural_type_system
A distinction exists between structural substitution for inferred and non-inferred polymorphism. Some languages, such as Haskell, do not substitute structurally in the case where an expected type is declared (i.e., not inferred), e.g., only substitute for functions that are signature-based polymorphic via type inference.[1] Then it is not possible to accidentally subtype a non-inferred type, although it may still be possible to provide an explicit conversion to a non-inferred type, which is invoked implicitly.
>Может Rust, с правильными идеями относительно безопасной работы с памятью, повлияет на ситуацию в лучшую сторону, но по уродству синтаксиса и нечитаемости он, похоже, оставил C++ далеко позади.
О, макаронный монстр! Раст и плюсы не похожи синтаксисом на мой любимый динамически типизированный язык программирования со сборщиком мусора! В утиль не думая и не разбираясь!
О, макаронный монстр! Раст и плюсы не похожи синтаксисом на мой любимый динамически типизированный язык программирования со сборщиком мусора! В утиль не думая и не разбираясь!
Ну посмотри на его синтаксис, кошмарный же, в глазах режет.
C++/C Режет глаза больше.
Согласен
Отступы в Python режут глаза! Макросы перерезают горловину, а точки с запятыми бьют в печень. И нет в мире совершенства.
Да не :-) Проблема многословности и нечитаемости языков лишь. Почему питон читается и помещается на экран, а java — гораздо хуже.
Если у тебя хороший отдел тестирования, а не «кликеры без понимания смысла» — то в принципе можно не волноваться. А вот если команда небольшая, а цена ошибки очень высока — то понимать код становится все сложнее
Ну посмотри на ручку этого молотка! Фу, как можно работать с этим чёрным обрезиненным ребристым покрытием? Мне нужна обязательно глянцевая красная ручка в блёстках! Иначе кошмарно! В глазах режет!
Ну погоди, я серьезно. Зачем скобочки и точка с запятой нужны? В питоне и хаскеле их давно нет :-)
Серьёзно??? Точка с запятой для вас «кошмарно» и «глаза вытекают»? На этом в принципе можно было и заканчивать, но так и быть, вот достаточно старая статья, но которая неплохо разжёвывает зачем в Расте точка с запятой:
lucumr.pocoo.org/2012/10/18/such-a-little-thing
lucumr.pocoo.org/2012/10/18/such-a-little-thing
Нет, это было только начало :-) В генериках java аналогичный кошмар с угловыми скобочками и стрелочками творится — это я так, просто под вечер, не воспринимайте близко к сердцу :-) Просто сравните с питоном.
UFO just landed and posted this here
А йелды? Ну блин можно же без них все в ООП сделать через итераторы — нет, придумали их, чтобы было еще покороче.
UFO just landed and posted this here
Итераторы придумали, например, что бы не складывать в память из базы 100500 значений в массив, а обработать и взять следующие данные, при этом минимально кода используется (особенно когда сперва напортачили с пачками и надо рефакторить что бы память всю не съедало, при этом не сломать всё при рефакторинге).
Ещё раз, см. комментарий про ручку молотка…
В Расте по определению нужно сообщать языку больше информации о программе по сравнению с языками имеющими утиную типизацию и сборщик мусора. Жаловаться на синтаксис не потратив хотя бы недельки на изучение языка, а просто поглядев листинги это где-то на уровне «Пастернака не читал, но осуждаю». Плюс стоит понимать, что если не брать совсем патологические случае, то к синтаксису работая на языке очень быстро привыкаешь, так что использовать подобную вкусовщину для оценки языка, мягко говоря странно.
В Расте по определению нужно сообщать языку больше информации о программе по сравнению с языками имеющими утиную типизацию и сборщик мусора. Жаловаться на синтаксис не потратив хотя бы недельки на изучение языка, а просто поглядев листинги это где-то на уровне «Пастернака не читал, но осуждаю». Плюс стоит понимать, что если не брать совсем патологические случае, то к синтаксису работая на языке очень быстро привыкаешь, так что использовать подобную вкусовщину для оценки языка, мягко говоря странно.
Скала выглядит опрятней же, разве нет? Хотя сборщик мусора конечно большое подспорье, соглашусь. Проблема в том, что избыточный синтаксис нужен компилятору, но затрудняет понимание кода — что случилось в java и вот что с этим делать…
Да и хороший код на том же Питоне выглядит опрятней разумеется, но это инструменты совершенно разного уровня и областей применения. И сравнивать «чистоту» их синтаксиса не очень корректно.
Я, как можно догадаться, весьма плотно работаю с Растом, и могу заверить, что лично у меня никаких сложностей с пониманием основной части кода не возникает, как и у множества других людей, которые хоть немного поработали на данном языке.
Я, как можно догадаться, весьма плотно работаю с Растом, и могу заверить, что лично у меня никаких сложностей с пониманием основной части кода не возникает, как и у множества других людей, которые хоть немного поработали на данном языке.
Я через 2 года тоже haskell стал понимать, а кто-то и perl понимает до первого отпуска.
По отзывам, что бы свыкнуться с синтаксисом и borrow checker'ом (последнее вносит наибольший вклад), у людей уходит от 1 до 3 месяцев. Тем не менее, достаточно большое количество людей изучивших Раст приходит из высокоуровневых языков вроде Питона, что говорить в пользу того, что для многих синтаксис не так уж и страшен. Возможно в вашем случае сказываются травматический опыт c Джавой, который и проецируется на Раст.
Сейчас бы сравнивать питон с языками программирования.
Синтаксис-то ещё ладно, а вот с неопределённым поведением в C++ — туши свет.
Я все понять не могу. Вот придумали java, где с синтаксисом попроще и стандарт проще. Пиши на здоровье! И чего написали толкового кроме minecraft и lucene и eclipse?
UFO just landed and posted this here
Это да. Я тоже в основном на java пишу миссиан-критикал код — надежно, ясно, и работает годами потом и спишь спокойно.
UFO just landed and posted this here
Искренне завидую Вам. Хочу лет 20 писать на C что-то для юникса системное и полезное — времени не хватает.
UFO just landed and posted this here
Может Golang вытащит системную разработку таки? Хотя он настолько имхо примитивен и пока еще смущает скорость сборки мусора и может его перестанут развивать.
s/eclipse/IDEA/
Слишком толсто.
Полностью согласен! Основная претензия к автору в том, что он даже не пытается вдаваться в технические подробности, ограничиваясь вкусовщиной (причём весьма похоже услышанной из третьих уст) для обоснования своего Важного Мнения.
Я целый день в течении многих лет в технических деталях с утра и до поздней ночи — давайте хоть тут про них не писать :-)
Может для вас Хабр это хиханьки и хаханьки, но, на мой взгляд, для большинства читателей он интересен в первую очередь качественными техническими постами, к которым вашу статью нельзя отнести даже с натяжкой.
И завязывайте с засильем смайликов, а то возникает ощущение, что переписка ведётся с условной блондинкой в чатике.
И завязывайте с засильем смайликов, а то возникает ощущение, что переписка ведётся с условной блондинкой в чатике.
Понимаете в чем проблема. Погружаясь в технические детали, можно потерять суть, что часто и происходит. Пост про то, как за деревьями лес увидеть.
Как ваша вкусовщина и мимопроходил-мимоглядел подход может каким-то образом помочь в нахождении сути? Вы сейчас пишите с позиции дилетанта в данном вопросе, пытающимся весьма с ограниченным опытом в данной области делать выводы космического масштаба, ну и далее по цитате.
P.S.: Да, этот комментарий практически ad hominem, но по сути дела тут обсуждать, к сожалению, нечего.
P.S.: Да, этот комментарий практически ad hominem, но по сути дела тут обсуждать, к сожалению, нечего.
Вы скажите что в 2019 учить, надо в будущее смотреть а не в настоящем топтаться.
Спасибо, на удивление хороший пост про выбор языка :)
А чего Swift и Objective-C не добавили? Те, кто с самого начала сидел на экосистеме Apple, вполне себе стабильно в шоколаде чувствуют — в отличии от тех же перловодов, например.
Забыл :-)
А чего их учить-то особо? Пересесть на них с C++ (особенно если его используешь в рамках "C с классами") — плёвое дело, а инфраструктура (фреймворки и т.п.) довольно-таки понятна, неплохо спроектирована (после win api, mfc и иже с ними — отдыхаешь душой) и прилично описана (хотя в этом вопросе у меня и к MS претензий нет), так что переход на неё, если уже привык к reference counting (например, использовал COM с его IUnknown или std::shared_ptr) не напряжёт вообще.
Я к тому, что можно со Swift и начать, тем более что у него ещё и playgrounds.
habr.com/post/272681
Swift читается лучше имхо
Swift читается лучше имхо
> Но в Java забыли о вреде null-значений, а в C# — не до конца продумали обратную совместимость.
Так гoвoрите, будтo бы в C# не забыли o вреде null-значений.
(хoтя уже стараются этo исправить)
> O да, чуть не забыл, про способ зарыть себя, проект, клиента и окружающий мир в код и утонуть в нем, вспоминая в агонии 20 уровневую иерархию наследования — про ООП.
20-урoвневая иерархия наследoвания — этo прoблема архитектуры, а не парадигмы прoграммирoвания. Недарoм существует принцип prefer composition over inheritance.
> Не нужно думать, что статическая типизация, особенно строгая, это прямо «must have» — вы провалите сроки и код с удовлетворенной параноидальной мыслью о «возможных ошибках» будет выброшен на помойку.
А между тем в нoвый Python дoбавили аннoтации типoв, IT-гиганты разрабoтали Typescript и Flow и даже PHP не oтстаёт. Дoвoльнo спoрный тезис!
Так гoвoрите, будтo бы в C# не забыли o вреде null-значений.
(хoтя уже стараются этo исправить)
> O да, чуть не забыл, про способ зарыть себя, проект, клиента и окружающий мир в код и утонуть в нем, вспоминая в агонии 20 уровневую иерархию наследования — про ООП.
20-урoвневая иерархия наследoвания — этo прoблема архитектуры, а не парадигмы прoграммирoвания. Недарoм существует принцип prefer composition over inheritance.
> Не нужно думать, что статическая типизация, особенно строгая, это прямо «must have» — вы провалите сроки и код с удовлетворенной параноидальной мыслью о «возможных ошибках» будет выброшен на помойку.
А между тем в нoвый Python дoбавили аннoтации типoв, IT-гиганты разрабoтали Typescript и Flow и даже PHP не oтстаёт. Дoвoльнo спoрный тезис!
Вот не согласен по поводу композиции и наследования. Трейты и AOP же не от хорошей жизни придумали — не все ложиться только в композицию и наследование, есть еще странные проникновения тем друг в друга. В ФП так вообще отказались от этих идей практически и работает же.
Так аннотации типов в python приведут его к… java. Философия питона — утиная типизация: не ограничивать типы, не тратить на это время, принимать все на вход и чекать уже внутри.
В "The Zen of Python" про утиную типизацию ничего нет. Похоже, это еще одна область, в которой Вы не являетесь экспертом.
Правильно, а вы сами давно перечитывали эту поэзию? :-) Зато тут написано: en.wikipedia.org/wiki/Duck_typing. А все потому, что питон язык — любительский, для скриптиков.
Ну так это статья про утиную типизацию, потому там про нее и написано. А Python приведен просто как общеизвестный пример. И еще, Python — это язык для быстрого изготовления прототипов реальных продуктов (почему его и используют всякие ресерчеры в Data Science и ML). «Любительский, для скриптиков» — это Ваше очередное личное безосновательное мнение.
Вы бы написали, что статья опубликована лишь для того, что бы холиваров разжечь. А то вдруг какой-то новичек ее всерьез воспримет.
Какой холивар, зачем? Наоборот дать обзор, максимально объективный, насколько получится. И пусть уже выбирает.
Scala? ;-)
Я так тоже думал, что Scala, пока не прочитал книжку Одерски несколько раз и не увидел особых преимуществ :-)
UFO just landed and posted this here
Ну я думаю что можно еще вспомнить Котлин.
Хорошее продолжение Java, и если все будет хорошо то его ждет разумный успех.
Мне кажется, ТС зарылся в своем любимом ЯП и не хочет познавать другие ЯП т.к. вызывает отторжение.
Имхо — язык это всего лишь инструмент, к которому надо знать подход.
Понял более-менее один язык — поймешь и другие. От языка уже зависит, сколько времени на его изучение придётся потратить.
Имхо — язык это всего лишь инструмент, к которому надо знать подход.
Понял более-менее один язык — поймешь и другие. От языка уже зависит, сколько времени на его изучение придётся потратить.
Этот подход хорошо заметен в питоне, в частности. Если ты будешь пытаться до сути вникать в каждую библиотеку, например в тонкости pandas, то потратишь месяцы. И рекомендуют быстро понять идею, выучить 2-5 сценариев и при необходимости просто гуглить. Аналогично в машинном обучении — схватил и погнали. В вебе тоже аналогично — понял php, принципы верстки и вперед.
Не холивара ради, но про Java ходит множество слухов, которые порождаются от незнания или уходят корнями в древние версии (например что Java медленная, что она жрет тонны памяти и все в таком духе). То же самое можно сказать и про "кровавый-энтерпрайз-простой-веб-вервер-за-5-дней". В текущих реалиях даже самый распространенный Spring Boot позволяет сделать веб сервер за ~10 строк кода, а ведь есть и более минималистичные фреймворки
Что до типизации — я лично считаю, что динамическая типизация замечательно подходит для создания прототипов или небольших проектов в духе "сделал и забыл". Если предполагается продолжительная разработка (а главное поддержка) в команде разработчиков, то лучше выбрать статическую типизацию
Я искренне фанат java, до чертиков и вдоль и поперек ее перелюбил в разных проектах, но для веба много лет использую только php — так кажется быстрее. Да, есть еще утверждение, что динамические языки позволяют много быстро написать и это сложнее в поддержке потом и наоборот — на статически типизированных пишешь медленнее, зато в поддержке проще. Но это касается все больших проектов. А никто в начале не знает какой у тебя проект.
А от чего сложилось впечатление, что статически типизированные языки требуют больше времени на разработку? Для Вас программирование эквивалентно набору бессмысленного текста? Просто лично у меня большая часть времени уходит на мыслительный процесс.
А на каких статически типизированных языках Вы обычно проводите свой мыслительный процесс?
Мыслительный процесс провожу в голове, а из языков больше всего использую C++. Да и какая вообще разница? Думать ведь всегда надо, и не только в программировании.
Согласен, что нужно думать. Статическая типизация кажется очень важной, и я так тоже много лет считал, но… Нужно описать типы, описать функции/методы принимающие типы, возможно абстрактные классы — т.е. принять решение и ограничить этим себя. А можно, в утиной типизации, принять все, что пришло, и дернуть метод у этого нечто. Зачем лишние ограничения? Идем дальше — статическая типизация подразумевает компиляцию. Но всегда ли это нужно если мы делаем прототип и меняем код 10 раз в минуту?
меняем код 10 раз в минуту
Что нужно такого делать с кодом, чтобы иметь ощутимый результат каждые 6 секунд?
UFO just landed and posted this here
А можно, в утиной типизации, принять все, что пришло, и дернуть метод у этого нечто.Ай как замечательно, только вот веселье начинается когда на вход передается объект такого типа, который на вход не ожидали. Хорошо еще, если соответствующего метода у данного типа нет — тогда просто получим ошибку (ну, или не получим), а что, если соответствующий метод вытирает диск или взрывает атомные бомбы? Так что строгая типизация — это не про ограничения, это про дисциплину и быстрое вылавливание элементарных, но неприятных ошибок.
статическая типизация подразумевает компиляциюНет, с чего это вдруг? Чем статическая типизация мешает использовать язык в режиме интерпретации?
Описывать типы нужно и при динамической типизации в том же PHP. Не везде, не всегда, но это может быть требованием к коду.
Ну это же костыль, согласитесь. В питоне тоже аннотации недавно придумали. Компилятор/интерпретатор в этом не поможет, будет хаос. Т.е. никто не понимает что лучше и внедряют идеи методом копирования друг у друга не думая
Разница в том когда будет ошибка — при компиляции или при исполнении.
Еще разница в том, что если жестко задать типы — нужно будет заглянуть в будущее и заведомо усложнить все. А иногда принимать решение заранее — неправильно. Утиная типизация как раз в этом помогает.
Как по мне, то ровно наоборот: описывая только те типы, которые сейчас нужны, мы не заглядываем в будущем с предположениями о том, что будет ожидать кто-то кто вызовет функцию sum(a, b) с текстовыми параметрами или объектами класса Rectangle.
Вот задумайся на секунду — почему живет до сих пор питон с огромным количеством сложных библиотек? Там же нет строгой типизации, как оно ваще может быть и еще активно развиваться?
В Питоне как раз строгая типизация. Попробуйте в нём сложить число со строкой.
Строгая динамическая. Да, строгая и к числу строку не добавишь. Я про «динамическую». Это означает, что проверки типов нет вообще и что в сигнаруре метода ты не укажешь интерфейс и он дернет все, что пришло, в рантайме — и ему пофиг, объект А это или объект Б. Да, они начали сбоку прикручивать метатэги типов и в php тоже начали — но это не тренд.
UFO just landed and posted this here
Полиморфизм в хаскеле просто поражает.
А где тут типы?
a — это тип. Monoid a => a -> a -> a — это тоже тип.
Не знаю хаскеля, но как функция сложения это не выглядит, выглядит как обобщенный интерфейс sumTwo без реализации.
UFO just landed and posted this here
Прочитал в вики про мононид — там говорится об умножении. В целом не понимаю эту запись, не могу понять где имя типа, а где имя аргумента. Специально используете одинаковые имена в разных «неймспейсах»?
В общем мне кажется дискусия зашла куда-то не туда. Я имел в виду, что если я пишу функцию для сложения двух целых чисел(псевдокод): `sum = (int a, int b): int => a + b` то я ни в какое будущее не заглядываю, а если пишу `sum = (int a, any b): int => typeOf(b) === 'int'? a + b: typeOf(b) === 'string'? a + (int)b: typeOf(b) === 'object'? a + (int)b.toString(): undefined;` когда мне только числа надо складывать, то делаю лишнюю работу никому не нужную на данный момент, при этом пытаюсь заглянуть в будущее и угадать что ожидают пользователи передавшие строку или объект в мою функцию для сложния чисел.
В общем мне кажется дискусия зашла куда-то не туда. Я имел в виду, что если я пишу функцию для сложения двух целых чисел(псевдокод): `sum = (int a, int b): int => a + b` то я ни в какое будущее не заглядываю, а если пишу `sum = (int a, any b): int => typeOf(b) === 'int'? a + b: typeOf(b) === 'string'? a + (int)b: typeOf(b) === 'object'? a + (int)b.toString(): undefined;` когда мне только числа надо складывать, то делаю лишнюю работу никому не нужную на данный момент, при этом пытаюсь заглянуть в будущее и угадать что ожидают пользователи передавшие строку или объект в мою функцию для сложния чисел.
Да, я согласен с тобой, если убрать про моноид, то получаем в хаскеле обобщенную функцию. Лучше пока не нырять в детали: моноиды и монады, там пипец. Достаточно на первое время понять алгебраические типы, паттерн-матчинг, caseclasses и базовые методы работы со списками и вводом-выводом.
«Делаешь пандорический захват, лифтишь в монаду, потом строишь рекурсивную схему (здесь подойдёт зигохистоморфный препроморфизм) как монадический трансформер из категории эндофункторов, и метациклически вычисляешь результат. Любой второкурсник справится. А если делать на анафорических лямбдах — так задачка вообще на пять минут.» (С)
UFO just landed and posted this here
UFO just landed and posted this here
UFO just landed and posted this here
Проблема когда нужно сделать не модную поделку, а расширить что-нибудь энтерпрайзное, где версия 16го года (а новее у заказчика нет, хорошо ещё хоть на эту перешли) использует жабу 1.7 со всеми её «особенностями». А ещё (к теме какой язык учить) там могуть быть модули на всё подряд — от Python и js до C и asm разных архитектур и задача «принести то, чаво не может быть». Вот это действительно весело, а не сайтики на php.
А в сайтиках тоже не всегда все просто
на самом деле согласен, иначе не было бы хайлоада и потребности в сеньорах очень высокой квалификации, на всё хватало бы студента, засунувшего на ночь книжку про PHP под подушку. Но там и простыни кода встречаеются не чаще, чем во всяких энтерпрайзах. И это даже если не считать за сайты веб-приложения руления чем-нибудь производственным.
Я часто переключаюсь между js, php, java и python, постоянно сравниваю и поэтому пост и написал — каждый ЯП хорош в своей нише, не нужно микроскопом гвозди забивать, как иногда пытаются.
После забавной критики языков, очень надеялся увидеть в конце статьи выход языка 1С в белом, сыграть на контрасте так сказать…
Название статьи весьма симптоматично:
не достает продолжения:
… чтобы (что?)
Позволю себе продолжить: "… чтобы получить гарантированную работу после окончания ВУЗа и проработать 40 лет после его окончания по специальности"
И ответ мой такой — не такого языка.
Пока то у нас программирование все еще не является ремеслом и с точки зрения IT-менеджеров, я цитирую автора:
Вобщем-то в стародалекие советские времена ходила такая устная памятка абитуриента:
1. Не иди в университет
2. Не или на АСУ.
3. Не оставайся в в институте работать (вариант: не иди в аспирантуру)
Так или иначе, трудовой путь программиста весьма предсказуем. Первый период когда, работу найти не просто а очень просто и зарплата будет на порядок выше чем у сверстников. И пеиод когда начинаешь задумываться что делать дальше а изменить уже ничего не можешь.
Кстати, статистику я не нашел. Но опасаюсь что 99% ВУЗов (кроме узко специалиированных на IT) это как и 30 лет назад все тот же Pascal
Какой язык программирования учить в 2018 году и почему именно его?
не достает продолжения:
… чтобы (что?)
Позволю себе продолжить: "… чтобы получить гарантированную работу после окончания ВУЗа и проработать 40 лет после его окончания по специальности"
И ответ мой такой — не такого языка.
Пока то у нас программирование все еще не является ремеслом и с точки зрения IT-менеджеров, я цитирую автора:
Взрослые отличаются от детей пониманием ключевого принципа IT-менеджмента: «программирование — это привилегия». Среди опытных и успешных коллег-разработчиков наиболее адекватные и кодят хорошо и «двигают компанию вперед» одновременно.
Вобщем-то в стародалекие советские времена ходила такая устная памятка абитуриента:
1. Не иди в университет
2. Не или на АСУ.
3. Не оставайся в в институте работать (вариант: не иди в аспирантуру)
Так или иначе, трудовой путь программиста весьма предсказуем. Первый период когда, работу найти не просто а очень просто и зарплата будет на порядок выше чем у сверстников. И пеиод когда начинаешь задумываться что делать дальше а изменить уже ничего не можешь.
Кстати, статистику я не нашел. Но опасаюсь что 99% ВУЗов (кроме узко специалиированных на IT) это как и 30 лет назад все тот же Pascal
это как и 30 лет назад все тот же PascalОтличный язык, к слову. Я как начал с него + asm лет 25 назад, так и до сих пор верой и правдой служит, исправно и хорошо кормит.
Боюсь что Паскаль (с которого я тоже начинал) очень быстро превратился в Delphi (почему-то сразу и навсегда версии 5.0), который — при этом я не говорю о его достоинствах или недостатках для разработки приложений а для обучения и только для обучения — превратил процесс обучения программированию в рисование форм в визуальной оболочке, что в свою очередь не способствует ничему кроме навыка рисования форм в визуальной оболочке.
Kotlin.
Поэтому забудьте про «какой выучить язык программирования в 2018 году»
Дальше, выберите область задач, которыми вам будет интересно заниматься, например веб или машинное обучение
Задачи в проектах существуют совершенно разные и именно от задач и нужно «плясать»!
Местами я не терял надежду.
UFO just landed and posted this here
С — в чем его фундаментальность? Он примитивен, как примитивно все императивное программирование. Хаскел развивает Ваш мозг прежде всего и позволяет посмотреть на то же ООП с другой стороны и стать более эффективным.
UFO just landed and posted this here
Что значит «развивает»? Любая творческая деятельность как-то развивает мозг.— имею в виду способность мозга формализовывать проблему, разделяя и властвуя дальше над ней.
Я просто совсем не понимаю, как можно программировать более-менее серьезные вещи без знания того, как программа работает вообщем?— я так тоже думал и начинал с C, книжки Таненбаума о архитектуре компьютера, изучил ВСЕ системные вызовы posix, кучу rfc до корки прочитал. Но сейчас вижу, что используя процедурных и функциональный подход, люди пишут неплохой код, взять тот же питон и НЕ ЗАДУМЫВАЮТСЯ и проекты взлетают быстро. Возьмем смартфоны — кто-то задумывается как они работают — нет. Блондинки думают как работает автомобиль? Нет. Но при этом ездят же
UFO just landed and posted this here
Кроме того, язык С не даёт вам понимания тех же регистров. Их там нет. И понимания того, как машина работает, он тоже не даёт.Да, но он является отправной точкой для изучения данных вещей. А как этому, интересно, способствует Хаскел?
Вы понимаете, как работает register renaming в современных процессорах и зачем он нужен, коли мы об этом заговорили? Как процессор выбирает и переупорядочивает инструкции для спекулятивного выполнения? А многопоточный код вы пишете? А протокол синхронизации кэшей в вашей машине знаете?Как минимум не до конца, что свидетельствует о том, что мне есть куда двигаться. Но значит ли это, что стоит отказаться от того, что бы в это все вникать?
«Развивает» — в данном случае значит, что заставляет рассуждать о программах в терминах типов, композиций функций и прочих вещей, позволяющих лучше и эффективнее проектировать большие системы.Не отрицаю, что это очень полезно, но если, как советует автор статьи, «не вникать в технические детали», то получится или быдлокодер, или человек с «энтерпрайсом головного мозга».
UFO just landed and posted this here
-
Ассемблер, серьезно? Много Вы людей знаете, которые могут на нем что-либо с нуля написать? А предлагаете как отправную точку новичку. Для понимания результатов компиляции С он конечно важен, но основной инструмент все же должен позволять выполнять задачи в адекватные сроки.
Функциональщина, хоть и привлекательна мне академически, не заходит дальше математического решения. А что бы положить это на существующие процессоры, нужен С.
Функциональщина, хоть и привлекательна мне академически, не заходит дальше математического решения. А что бы положить это на существующие процессоры, нужен С.
UFO just landed and posted this here
Лучше как-то с алгоритмов начинать, ИМХО.Безусловно, но мы то уже о программировании говорим.
С тоже, ИМХО, не самый хороший выбор.Возможно, но ничего лучше я пока не вижу.
хотя С и позволяет добиваться результатов быстрее, чем ассемблер, он далеко не на вершине эффективности в плане скорости разработки.ИМХО, новичку нужно учиться создавать качественный продукт, а быстрый говнокодинг на чем то вроде Java всегда можно освоить. Насколько я знаю, самый простой инструмент для создания качественного продукта — это С.
Зачем он там нужен?Кто и где?
UFO just landed and posted this here
Я не очень понимаю, почему вы считаете, что С позволяет писать более качественное ПО, чем та же Java.Потому что через С можно выразить практически все возможности процессора, а радужный мирок Java неизбежно влечет ощутимый оверхед на многие элементарный операции.
А наиболее простой, наверное, какой-нибудь Go.Согласен, возможно Go как раз лучший выбор, хотя ИМХО лучше начинать с языка без GC.
UFO just landed and posted this here
Чем Java более корректна чем C?
Типизация более строгая, как минимум.
Например, там невозможна эксплуатация множества ошибок: index out of range, buffer overflow, use after free и т.д., и т.п.
Делфай, к слову, под многое из этого подходит. Java — отличный яп, особенно если бы не было прослоек в виде жава-машины.
Делфай
Как насчет Раби?
Так я ж про php и python написал в посте. Раби почти тоже самое :-)
«Delphi (Де́лфи, произносится /ˈdɘlˌfi:/)» (С)
А Ruby, разумеется, как «Руби». Хотя я встречал и «Раби» на полном серьезе, да.
А Ruby, разумеется, как «Руби». Хотя я встречал и «Раби» на полном серьезе, да.
www.merriam-webster.com/dictionary/Delphi
А ларчик просто открывался. "-фи" — это чисто английский вариант, "-фай" — это вариант, доминирующий в США (опять-таки википедия нам так говорит).
Этого я не знал :(
А ларчик просто открывался. "-фи" — это чисто английский вариант, "-фай" — это вариант, доминирующий в США (опять-таки википедия нам так говорит).
Этого я не знал :(
Делфай, к слову, под многое из этого подходит.Нет, не подходит. Проверка индексов массивов отключается опцией компилятора, и, значит, в release кто-то её выключит ради пары процентов к скорости. Всё остальное — адресная арифметика, безнаказанное приведение указателей одного типа к другому, ручное Create/Destroy, бесконтрольные CopyMemory/MoveMemory — всё как в C.
Ну так эксплуатация ошибок — это Ваша личная проблема. Сам язык этого делать не заставляет.
Не заставляет, но разрешает.
Ну, мне под машины бросаться тоже никто не запрещает, и все же у меня напрочь отсутствует желание жить в клетке для животных, где машина меня точно не достанет. Я к тому что при правильной архитектуре проекта и достаточном использовании run-time assert'ов ошибки, которые Вы перечислили, отлавливаются так же, как и в Java.
Выходит, что больших проектов с правильной архитектурой не существует, раз в таких монстрах, как OpenSSL, Linux, Firefox находят критичные уязвимости си-шной природы.
Статистически невероятно, что в большом проекте не найдется ни одной ошибки, так же как и то, что в проекте на С среди таких ошибок не будет не одной ошибки «С-шной» природы. Но, как и большинство остальных, такие ошибки допускаются по невнимательности программиста (или из-за несоблюдения best practices), и винить в них язык — все равно что винить молоток, которым Вы ударили себя по пальцу.
Конечно, не надо винить молоток.
Однако, не надо брать молоток и зубило, чтобы проковырять дырку в стене. Быстрее, удобнее и надёжнее это сделать дрелью.
Хотя, разумеется, с дрелью все дырки бездушные и однотипные. А вот молотком можно делать уникальные дырки, ковыряние которых надолго запомнится.
Однако, не надо брать молоток и зубило, чтобы проковырять дырку в стене. Быстрее, удобнее и надёжнее это сделать дрелью.
Хотя, разумеется, с дрелью все дырки бездушные и однотипные. А вот молотком можно делать уникальные дырки, ковыряние которых надолго запомнится.
Современные программы — не дырки, современные программы — это мраморные скульптуры. Которые, разумеется, можно быстро, удобно и надежно делать дрелью, вот только то, что при этом получится, с трудом можно будет назвать скульптурой. Разумеется, производители дрелей будут уверять всех, что дрель даже лучше, чем молоток с зубилом, и посмеиваться над гиками, которые в 2018ом пользуются «примитивными» инструментами — но ведь по сути этот хайп ничего не изменит. А вот молотку и зубилу реклама не нужна, так как, в отличие от дрели, они давно уже показали, что с их помощью можно не только сделать скульптуру, но и сделать ее качественно.
Тоже неплохая аналогия. Я люблю пописать на C++ что-нибудь для себя, не спеша, перепроверяя и оптимизируя всё.
Однако, для заказной разработки я возьму что-нибудь более продуктивное, чтобы укладываться в сроки.
Однако, для заказной разработки я возьму что-нибудь более продуктивное, чтобы укладываться в сроки.
К тому, что от скульптуры периодически что-то отваливается (CVE) и приходится ставить заплатки, все уже привыкли, и это считается качеством.
Системные с устаканенной предметной областью — да, соглашусь. Я еще их сравнивал с изделиями из металла. А вот стартапы часто из говна и палок — и потом, может быть, если повезет и проект взлетит, части можно начать переписывать.
Вот именно — ответственность разработчиков компилятора сваливается на программиста. А в «умных» ЯП все наоборот.
Откуда разработчикам компиляторов знать, какая именно мне нужна архитектура проекта и какие именно использование assert'ов? (Если конечно я не использую втупую то, что они мне навязывают.) Мне кажется, это Вы с себя как можно больше ответственности снимаете, лишь бы поменьше думать.
Строгие типы, инкапсуляция внутри объекта, неплохая и мощная модель работы с потоками, нельзя данные в памяти повредить случайно.
В мое время на ассемблере мог писать любой третьекурсник. Собственно, язык фортран — это такой макроассемблер IBM-709, Си — макроассемблер PDP-11 и так далее.
На самом деле очень удобно писать код, понимая, во что он компилируется. Сразу отпадает желание делать что-то тяжелое, вроде присваивания массивов и структур.
На самом деле очень удобно писать код, понимая, во что он компилируется. Сразу отпадает желание делать что-то тяжелое, вроде присваивания массивов и структур.
Что ж, у Вас было замечательное время. Но согласитесь, что сейчас для решения нетривиальной задачи написать код лучше, чем генерирует компилятор C, практически невозможно.
На счет понимания, во что компилируется код — ну так это сама суть C/C++. А вот в ФП это выглядит проблематично.
На счет понимания, во что компилируется код — ну так это сама суть C/C++. А вот в ФП это выглядит проблематично.
UFO just landed and posted this here
Статью видел, мнение и правда неплохое, но я не заметил каких-либо радикально новых предложений по улучшению ситуации.
А на счет понимания — я имел в виду примерное представление того, что сделает процессор, выполняя программу. Программируя на C, я это, хоть и не идеально, но представляю. А если имеем тредпулы с синхронизациями верхом на виртуальных машинах — кто знает, что может случиться.
А на счет понимания — я имел в виду примерное представление того, что сделает процессор, выполняя программу. Программируя на C, я это, хоть и не идеально, но представляю. А если имеем тредпулы с синхронизациями верхом на виртуальных машинах — кто знает, что может случиться.
Как соавтор пары форт-систем — я понимаю, во что они компилируют.
Вместо того, чтобы вертеть большой цикл с кучей if внутри — можно динамически сгенерить код на конкретный набор условий. Выигрыш — порядка сотни раз. Мы так 25 лет назад сделали для поиска строки в сжатом поле базы. Вместо поиска любой строки — динамически генерился код поиска конкретной строки.
сейчас для решения нетривиальной задачи написать код лучше, чем генерирует компилятор C, практически невозможно.Ну что вы! Есть такой трюк — динамическая кодогенерация.
Вместо того, чтобы вертеть большой цикл с кучей if внутри — можно динамически сгенерить код на конкретный набор условий. Выигрыш — порядка сотни раз. Мы так 25 лет назад сделали для поиска строки в сжатом поле базы. Вместо поиска любой строки — динамически генерился код поиска конкретной строки.
Ну если писать большие циклы с кучей if'ов внутри, для которых конкретных наборов условий всего несколько, то кто же Вам виноват. Подразумевалось, что код на С написан качественно.
На счет поиска строки — интересно, а что дает хардкод строки, и при каком конкретно поиске?
На счет поиска строки — интересно, а что дает хардкод строки, и при каком конкретно поиске?
Компилятор — всегда быстрее интерпретатора. И это не зависит от качества кода на Си.
А конкретный пример был такой. Библиотечная СУБД, текстовые поля сжаты при помощи заранее выбранного словаря (гнездо — 12 бит), полнотекстовый поиск. Компилятор брал образец (то, что ищем), выяснял, как он может запаковаться, после чего хардкордил код с поиском нужных последовательностей гнезд.
Ложноположительные срабатывания отбрасывались распаковкой поля.
Скорость поиска — порядка 10 тысяч библиотечных записей в секунду на I386DX40, загрузка процессора — порядка 50% (остальное тратилось на чтение с диска). Время компиляции — порядка 500 мс.
Как видите — от if не ушли, но компиляцией захаркордили только нужные.
P.S. Спецификой проекта было то, что из трех человек было 2.5 компиляторщика. Причем половина — это как раз я.
А конкретный пример был такой. Библиотечная СУБД, текстовые поля сжаты при помощи заранее выбранного словаря (гнездо — 12 бит), полнотекстовый поиск. Компилятор брал образец (то, что ищем), выяснял, как он может запаковаться, после чего хардкордил код с поиском нужных последовательностей гнезд.
Ложноположительные срабатывания отбрасывались распаковкой поля.
Скорость поиска — порядка 10 тысяч библиотечных записей в секунду на I386DX40, загрузка процессора — порядка 50% (остальное тратилось на чтение с диска). Время компиляции — порядка 500 мс.
Как видите — от if не ушли, но компиляцией захаркордили только нужные.
P.S. Спецификой проекта было то, что из трех человек было 2.5 компиляторщика. Причем половина — это как раз я.
Как соавтор пары форт-систем — я понимаю, во что они компилируют.Насколько я знаю, в форт-системах нет оптимизаций. Шитый код соответствует коду программы и конструкция
2 DUP * *никак не превратится в
lea eax, [eax*4]И даже, скорее всего, будет содержать ненужные обращения к памяти (стеку данных Форта).
Ну что вы! Есть такой трюк — динамическая кодогенерация.Код генерился программистом? Структура алгоритма, регистры, инструкции, всё это прописывал программист в кодогенераторе? Такое и на Си делают.
Вместо того, чтобы вертеть большой цикл с кучей if внутри — можно динамически сгенерить код на конкретный набор условий. Выигрыш — порядка сотни разТак можно и на Си написать 100500 вариантов функции с разными наборами if, и скомпилировать. Уверен, результат будет лучше, чем при ручной генерации, т.к. компилятор из 100500 вариантов сможет найти «специальные» случаи (например, когда константа умножения случайно равна 16, или ширина массива кратна 4, а ещё всегда выровняет начало внутреннего цикла по линии кеша, подобрав перед циклом nop-инструкцию, занимающую нужное кол-во байт).
Это всё можно зашить в свой кодогенератор, но вряд ли получится превзойти 20-летнюю экспертизу кодогенераторщиков си-компилятора.
Подход этот, кстати, рабочий. В математическом пакете maple12 в комплекте идёт Open Watcom C++ 1.3, и решатели сложных задач генерят си-код под задачу, компилируют и запускают.
Функциональщина, хоть и привлекательна мне академически, не заходит дальше математического решения. А что бы положить это на существующие процессоры, нужен С.Функциональщина позволяет иметь ОС и IDE, на машине с 16 килобайтами ОЗУ. И никакого Си — компилятор, операторы языка, ядро ОС, IDE — все написано на этой самой функциональности. На ассемблере — лишь 3 килобайта примитивов.
На каком основании Форт вы причислили к ФП?
Нет функций высшего порядка, замыканий, да хотя бы неизменяемых переменных.
Нет функций высшего порядка, замыканий, да хотя бы неизменяемых переменных.
Функции высшего порядка — имеются. Например: цикл — это функция, примененная к телу. :-) И написан он — на форте. Все прочее — просто пишется на том же форте.
Форт тем и хорош, что набор операторов и структур данных пишешь сам под себя.
Форт тем и хорош, что набор операторов и структур данных пишешь сам под себя.
Я не понимаю, как это синтаксически возможно.
Приведите форт-реализацию вот этого классического примера:
Приведите форт-реализацию вот этого классического примера:
function makeAdder(x){
function add(y){
return y + x;
};
return add;
}
var plusFour = makeAdder(4);
console.log(plusFour(10)); // results 14
console.log(plusFour(40)); // results 44Ох… 30 лет не писал на форте. А чем вы видите проблемы? makeAdder генерит словарную статью (как двоеточие) с автоматически сгенеренным случайным именем и выдает её адрес на стек. А USEFUNC — берет число со стека и воспринимает его как адрес подпрограммы, которую нужно вызвать.
Какую из этих частей вы не понимаете, как реализовывать?
Какую из этих частей вы не понимаете, как реализовывать?
Какую из этих частей вы не понимаете, как реализовывать?Не знаю такого слова, которое бы приняло строку со стека и сгенерировало слово с этим именем. Слова типа CREATE берут строку имени не из стека, а из потока программы, т.е. новое имя должно быть явно указано, не может быть сгенерировано.
CREATE, насколько помню, написано на самом форте. Так что проблем не вижу. Ну разве что с переносимостью между форт-системами с различным устройством словаря.
Ну и потом, у авторов форт-систем — чуть иной взгляд на это дело. Если чего-то в ядре нету — то почему бы туда не добавить? Делов-то на полчаса. :-)
Главное — синтаксис позволяет. А переносимость и стандартность — это уже другие моменты.
Ну и потом, у авторов форт-систем — чуть иной взгляд на это дело. Если чего-то в ядре нету — то почему бы туда не добавить? Делов-то на полчаса. :-)
Главное — синтаксис позволяет. А переносимость и стандартность — это уже другие моменты.
Если у нас нет стандартных слов для решения задачи, мы модифицируем интерпретатор и/или среду исполнения, и получаем другой язык. То есть, исходный язык не имеет нужных средств.
Если в стандартном Форте есть слова для генерации слов с произвольным именем, то я их не знаю. Если вы думаете, что они есть, для закрытия вопроса достаточно их просто назвать )))
Если в стандартном Форте есть слова для генерации слов с произвольным именем, то я их не знаю. Если вы думаете, что они есть, для закрытия вопроса достаточно их просто назвать )))
Уж поверьте человеку, писавшему свою реализацию Форт-83 для i8080 — функциональщиной там не пахнет совсем. Си больше оснований имеет считаться функциональным языком.
Сдаётся мне, это опять сарказм, как и ниже в этом комменте.
Как соавтор двух форт-систем — считаю его функциональным. Просто функциональность у него такая, польская.
И что же практичное можно начать писать после элементарного освоения C? Сортировку? Двусвязные списки?
Да, почитал. ПО больше мотивационных, а то я застрял в развитии и ты прям четко описал мою ситуацию — я погрузился во внутренности, вместо 5-15 строчек кода и готовых библиотек, хотя тот же битрикс как раз это все позволяяет делать как мегафреймворк. Вот засел после твоей статьи на несколько онлайн курсов бесплатных быстрых по php и python, чтобы переформатироваться с нолика как бы. И сразу же звоночек от интересантов по мне по моему резюме… и как раз по битрикс24 — на волне хайпа так сказать, хотя с 2014 года я из ИТ выпал как и перебивался как ты видишь в моей ленте всем подряд. Как говорится — ИТшникам нужная своя «мотивационная» статейка :) Ну или как Олег порой фигачит ;)
эх, боюсь меня запинают за этот комментарий, но все же напишу…
эхх, конечно нужно стараться изучать языки которые находятся ближе к вашим интересам. Конечно, нужно изучать теорию, пробовать на практике, при нулевом знании сложно начинать с асма, конечно сложно начинать с С/C++.
Но надо когда-то попробовать С, немного поковыряться с Асмом.
Причины простые:
1. если совсем не знать теорию, а также не пробовать языки в которых вы можете почувствовать теорию на практике, то скорее программист так и останется на начальном уровне.
2. на каком то либо языке многие вещи можно решить в 5 строк, но без многих знаний и практики это превращается в копипаст, а не в понимание что программист пишет
и в подтверждение, могу сказать то, что я вижу на практике:
Многие начинающие программисты пишут код не понимая разницы в парадигмах, толком не видят разницы(если вообще видят), то есть у них вечный поток сознания и какие-то замашки в одну или другую сторону.
И что бы победить этот поток сознания все равно приходится объяснять многие вещи на пальцах, а также указывать им на пробелы знаний в основах.
На мой взгляд хорошо начинать с языков похожих на Java или C#(язык хорош, но по религиозным взглядом, я отношусь к нему не очень хорошо), может в них и надо чуть больше писать, но за то в них все более явно, а также программист может читать полноценно всю логику своих мышлений. Python, отличный язык, простой и лаконичный, с хорошей философией.
Две самых важных вещей который я вижу, они достаточно строгие, а так же на них можно испробовать разные сферы.
эхх, конечно нужно стараться изучать языки которые находятся ближе к вашим интересам. Конечно, нужно изучать теорию, пробовать на практике, при нулевом знании сложно начинать с асма, конечно сложно начинать с С/C++.
Но надо когда-то попробовать С, немного поковыряться с Асмом.
Причины простые:
1. если совсем не знать теорию, а также не пробовать языки в которых вы можете почувствовать теорию на практике, то скорее программист так и останется на начальном уровне.
2. на каком то либо языке многие вещи можно решить в 5 строк, но без многих знаний и практики это превращается в копипаст, а не в понимание что программист пишет
и в подтверждение, могу сказать то, что я вижу на практике:
Многие начинающие программисты пишут код не понимая разницы в парадигмах, толком не видят разницы(если вообще видят), то есть у них вечный поток сознания и какие-то замашки в одну или другую сторону.
И что бы победить этот поток сознания все равно приходится объяснять многие вещи на пальцах, а также указывать им на пробелы знаний в основах.
На мой взгляд хорошо начинать с языков похожих на Java или C#(язык хорош, но по религиозным взглядом, я отношусь к нему не очень хорошо), может в них и надо чуть больше писать, но за то в них все более явно, а также программист может читать полноценно всю логику своих мышлений. Python, отличный язык, простой и лаконичный, с хорошей философией.
Две самых важных вещей который я вижу, они достаточно строгие, а так же на них можно испробовать разные сферы.
спасибо, прямо в «десяточку»
Глубокая мысль, да. Но Вы бы на троллинг просто не отвечали — ибо это провокация. Я вот уже давно перешел на С# — так все быстрее в современных реалиях, тем неменее, ой да ладно. Никто Вас запинывать не будет.
Кстати о Сишарпе замолвите слово
А есть про него в посте же
Я о вашем мнении, впечатлениях. Вот не выдержал, поставил visual studio — решил сишарп попробовать :)
C# — прекрасный язык, о нем много хороших отзывов от коллег и экспертов. Удачи Вам в изучении технологии и интересных, развивающих проектов!
Моя большая проблема в том, что я частенько не могу выйти на профит в виде решения практической задачки с помощью какого либо инструмента.
Возьми язык помощнее, типа php или python или ruby или js — там будешь очень быстро двигаться вперед. Главное — пиши максимально строго и ясно. Логику инкапсулируй в функи или, если прям сложная, в классы — и так снизу вверх, разделяй и властвуй — любая проблема решается в разумное время.
Можно еще форт посмотреть. Тоже весьма мощный язык.
Если не отпугивает то, что последний компилятор обновлялся лет 15 назад.
Это был сарказм. Без смайлов сложно, понимаю.
git.savannah.gnu.org/cgit/gforth.git — 5 дней назад :)
Какой язык программирования учить в 2018 году и почему именно его?