LINUX.ORG.RU
ФорумTalks

“Программируйте с использованием языка, а не на языке” vs быдлокодерские и небыдлокодерские языки


4

2

//Видит бог, тему хотел создать в Talks...

Здравствуйте. Я новичок в программировании, опыта работы у меня нет. Следовательно какие-то особенности работы программиста, явления в программировании и “подводные камни” для меня могут быть скрыты. Сейчас я подыскиваю работу или место для стажировки и мне стали доступны вакансии C#-программиста и Python-программиста.

И вот в чём мой вопрос.

Я заметил, что существует два образа мышления среди программистов:

1. “Программируйте с использованием языка, а не на языке”. Программист – это образ мышления, способность к абстракции, логике, знание алгоритмов. Язык – это лишь инструмент для выполнения определённой задачи. Если ты хороший программист, то ты (с некоторыми оговорками) можешь решать разные задачи, на разных языках.

2. В мейнстримовых языках снижают порог вхождения. Их делают простыми. Технологии развиваются таким образом, чтобы сделать создание программ максимально простым и быстрым. Это правильно, но приводит к тому, что программисты “тупеют”, можно быть программистом, не зная основопологающих и очень важных вещей. Таким образом появляется деление на “быдлокодерские” и “небыдлокодерские” языки. Соответственно, программирование на “быдлоколерских” языках какбы отупляет.

С одной стороны есть C#. Он считается, как мне показалось, именно “быдлокодерским”. С другой стороны Python. Конечно, не haskell какой-нибудь, но язык (опять же – как мне показалось), считается серьёзным, пользуется популярностью в академиечских кругах, сам видел MIT'шные курсы на нём.

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

И в итоге, главный вопрос: в начале карьеры, стоит ли выбрать программирование на серьёзных языках (то есть, принять ли правильным пункт 2), или не парить себе мозг (принять пункт 1)? Или возможно, даже если первый пункт верен, всё равно стоит предпочесть Python?

Перемещено post-factum из general


Ответ на: комментарий от dave

Вспомнил. Увязка с методом проектирования встречается (уже/еще ?) у Пола Грэма в книге On Lisp.

dave ★★★★★
()
Ответ на: комментарий от dmitryalexeeff

Добавлю, что можно даже делить людей на предрасположенность к тем или иным языкам программирования. Выбор может зависеть от наклонностей, характера и образования.

dave ★★★★★
()
Ответ на: комментарий от dmitryalexeeff

Давно на практике была признана необходимость разделять людей на инженеров,теоретиков и техников.

A census taker tried to quantify me once. I ate his liver with some fava beans and a big Amarone.

Macil ★★★★★
()
Ответ на: комментарий от Macil

Гугл намекает что автор сего изречения вложил его в уста некоего Ганнибала Лектера.
Занятные у вас, однако, литературные предпочтения...

dmitryalexeeff
()
Ответ на: комментарий от dave

что одно из достоинств (общего) лиспа состоит в том, что язык программирования приближается к предметной области

В этом и состоит величие и беда CL. Он это делает, но делает это таким способом, что оказался не принят и не понят. В CL первичны CLOS и MOP, макросистема же вторична и *предельно утилитарна* (пресловутое хочешь написать макрос - не пиши макрос).

ООП в CL организован в духе Simula и Smalltalk, где во главу угла ставится поведение (динамика, процесс). Хотя, стоит заметить, что применять термин ООП к CLOS (как и к Smalltalk с Simula) - есть *крайне* некорректно, т.к. в те времена никакого ООП не существовало.

Увы, погоня за динамикой вышла CL боком: он предельно аморфен. На деле вышло так, что индустрии было выгоднее жрать блевотину «класс - есть тип-интерфейс-поведение», чем пытаться оснастить CL «хребтом» на более высоком - компонентном - уровне.

Самое смешное, что Scala подошла к той же самой черте, только с другой стороны. Помимо всего прочего, Одерский соврешенно спокойно, без слюнобрызганий, на практике доказал что нет никакой «пропасти» между «ООП» и «ФП». В мире CL этого сделать не смогли. Видимо, потому что своих «одерских» в стане лиспа нет. ИЧСХ, Scala также не принята и не понята индустрией, даже в режиме ява-на-стероидах.

Macil ★★★★★
()
Ответ на: комментарий от dmitryalexeeff

Занятные у вас, однако, литературные предпочтения...

Да ладно, у меня круче - Бухановский, эксперт по серийникам.

makeB
()
Ответ на: комментарий от dave

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

Не надо! «Поделили» уже на «технарей» и «гуманитариев», что служит железобетонным оправданием для задротов и зачуханов из обоих лагерей.

Macil ★★★★★
()
Ответ на: комментарий от dmitryalexeeff

То есть, вы больше маньяков предпочитаете - трудное детство, насилие может быть?

makeB
()
Ответ на: комментарий от vertexua

Scala уже активно используют в швейцарском банке

Как-то SPJ, шутил что в каждом банке есть «секретная» группа, использующая хаскель.

Не показатель. А вот наличие массы «недо-Scala», пилимых серьезными игроками рынка, увы, показатель.

Macil ★★★★★
()
Ответ на: комментарий от Macil

А вот наличие массы «недо-Scala», пилимых серьезными игроками рынка, увы, показатель.

Ну я думаю что это просто свои лаборатории исследований. Ну нельзя же серьезно думать что Kotlin или Ceylon кто-то будет использовать. У Scala и Groovy, при всей их инфраструктуре и лучшему дизайну языка с этим проблемы.

vertexua ★★★★★
()
Ответ на: комментарий от Dron

Мой совет выучи Си для начала. Хороший такой годный базис будет.

Будет, но смысл ему учить его, если сейчас он используется разве что в драйверах под чудо-технику, а парню явно тупо деньги нужны, и деньги он хочет программингом зарабатывать - пусть лучше что то простейшее, модное учит, к сишке он еще успеет вернуться, не факт что *** защемит после «скрипто-языков», но на это все нарывались :]

makeB
()
Ответ на: комментарий от vertexua

Ну я думаю что это просто свои лаборатории исследований.

А на *кой* черт, спрашивается? На кой черт заново изобретать «велосипед». С квадратными колесами, штырем вместо сиденья, и рулем сзади?

Ну нельзя же серьезно думать что Kotlin или Ceylon кто-то будет использовать.

Будут! Еще как будут. Ибо, их создатели пекутся о целостности шаблона своих адептов. А потом э-э-эк ливанут тонну маркетигнового буллшыта. А потом набугут «евангелисты» и понапишут тонну «книг». И пошло-поехало.

Macil ★★★★★
()
Ответ на: комментарий от Dron

Мой совет выучи Си для начала.

С - есть высокоуровневый ассемблер. Учить его per se - напрасная трата времени.

Macil ★★★★★
()
Ответ на: комментарий от Macil

Учить его per se - напрасная трата времени.

Категоричное высказывание. Мы таки точно-то не знаем цели автора, лишь догадки; может он действительно с малых лет мечтал заниматься сексом с м-контроллерами.

makeB
()
Ответ на: комментарий от Macil

Про связь ООП и ФП относительно лиспа могу сказать так. Обычный для других языков метод является в CL функцией, точнее обобщенной функцией, которая может специализироваться на аргументах. Ну, буду проще. На метод смотрят как на функцию. Чем не симбиоз ООП и ФП?

С другой стороны, можно создать класс, объекты которого будут вызываемыми как функции. Правда, для этого нужно знать о мета-объектном протоколе MOP. Но результат равносилен тому, что мы создаем в Scala объект с методом apply.

Я могу сказать, что вполне успешная попытка скрестить ФП и ООП состоялась в CL, и произошло это много раньше появления Scala. Другой разговор, что не пошло в массы. Да, и как-то всеобщая зацикленность на ФП появилась совсем недавно, и возможности ФП в лиспе не настолько сильно выделяются на фоне других возможностей этого замечательного гибридного сбалансированного языка. Кроме того, можно сказать, что большинство современных программистов почти не знает лиспа. Поэтому некоторые его возможности остаются до сих пор непонятыми или скрытыми для многих. И я не вижу в этом ничего плохого.

Кстати, меня пугает вектор развития Scala. Если лисп только кажется большим, а на проверку он - очень простой язык, но с раздутой стандартной библиотекой, то Scala сама по себе сложна и становится все сложнее, а ее библиотека коллекций, вообще, запутанная. Одни развесистые иерархии наследования и имплиситы чего стоят. Что-то перестало мне нравиться это.

dave ★★★★★
()
Ответ на: комментарий от Macil

Ой да ладно, википедии начитались? Си универсален, на нём писать одно удовольствие хоть гуяшное хоть консольное хоть что угодно. В том и прелесть си что у него нет специализации, пиши как хочешь, я даже его использую вместо bash скриптов, ну да иногда применяю system("");.А толк от си в том что он поймёт как программировать, а не чем. Но всё это ИМХО конечно, и вэб приложения пролетают мимо конечно. Хотя написать интерпитатор сишный не проблема да и есть он вроде root назывался кажется.

Dron ★★★★★
()
Последнее исправление: Dron (всего исправлений: 2)

А вообше, Python==деньи сейчас вроде.

Dron ★★★★★
()
Ответ на: комментарий от Dron

А толк от си в том что он поймёт как программировать, а не чем.

Жир стекает с монитора. Си диктует свои правила не меньше других в-уровневых языков.

makeB
()
Ответ на: комментарий от dave

Обычный для других языков метод является в CL функцией, точнее обобщенной функцией, которая может специализироваться на аргументах. Чем не симбиоз ООП и ФП?

Внезапно везде так же. За тебя это делает компилятор в других языка, вон в Python шестеренки внаружу торчат с их self.

Но больше dance в создании класса и методов чем в Common Lisp есть только в GObject

vertexua ★★★★★
()
Ответ на: комментарий от Dron

я даже его использую вместо bash скриптов

сурово

qaqa ★★
()
Ответ на: комментарий от dave

Да, и как-то всеобщая зацикленность на ФП появилась совсем недавно

На ЛОРе

vertexua ★★★★★
()
Ответ на: комментарий от vertexua

Внезапно везде так же. За тебя это делает компилятор в других языка, вон в Python шестеренки внаружу торчат с их self.

Нет, есть различие. В CL можно метод от одного аргумента превратить в предикат. В Scala же для этого нужно применить partial application, а это такая особенная штука, которая есть далеко не во всех языках.

Но больше dance в создании класса и методов чем в Common Lisp есть только в GObject

Не понял смысла. Если что, мне нравится, как задаются классы и методы в CL. У этого есть своя логика, и это очень хорошо сочетается с макросами, когда можно легко генерировать классы и методы на-лету (а не так, как в Nemerle).

dave ★★★★★
()
Ответ на: комментарий от makeB

Ты меня не понял,жаль.

Си диктует свои правила не меньше других в-уровневых языков.

Да это так.

Dron ★★★★★
()
Ответ на: комментарий от dave

Я могу сказать, что вполне успешная попытка скрестить ФП и ООП состоялась в CL,

Не говори «скрестить». Когда «скрестили» - это ужа с ежом. А тут именно совместное использование.

и как-то всеобщая зацикленность на ФП

Эта «зацикленность» сродни зацикленности на ООП в начале 90-х. Ничего годного/путного из нее не выйдет. Эта зацикленность мешает разглядеть потенциал текущих ООП-языков, эта зацикленность мешает разглядеть потенциал CL, эта зацикленность заставляет плодить «новые и улучшенные».

Поэтому некоторые его возможности остаются до сих пор непонятыми или скрытыми для многих. И я не вижу в этом ничего плохого.

Я - вижу. CL де факто сдох.

Реализации CL либо хронически недоделанные, либо стоят непомерных денег. FFI не стандартизован, параллелизм/конкурентность не стандартизована. Количество сторонних библиотек мало. Евангелистов (современных) нет, сообщество слывет неадекватным.

Одни развесистые иерархии наследования и имплиситы чего стоят.

Это она, бедная, от явы подхватила.

Macil ★★★★★
()
Ответ на: комментарий от Macil

Не говори «скрестить». Когда «скрестили» - это ужа с ежом. А тут именно совместное использование.

Принимается :)

Я - вижу. CL де факто сдох.

Не согласен. В последнее время неплохо развивается.

Реализации CL либо хронически недоделанные, либо стоят непомерных денег. FFI не стандартизован, параллелизм/конкурентность не стандартизована. Количество сторонних библиотек мало. Евангелистов (современных) нет, сообщество слывет неадекватным.

Если считать, то LispWorks Professional, 32 бита, Windows, стоит $1500. Иной навороченный визуальный компонент для .NET стоит не дешевле. Может, и хорошо, что есть коммерческие лиспы - у них денежный стимул для развития.

Многопоточность - bordeaux-threads. MOP - closer-mop. Если брать параллелизм/конкурентность не в смысле многопоточности, то оно мало где стандартизировано.

Что касается сообщества, то, судя по ЛОРу и comp.lang.lisp, значительная часть неадекватов - это ненавистники лиспа. Что есть, то есть, но по количеству ненавистников и противников общелисп впереди всех будет, причем многие из них схемеры или поклонники других лиспов, чаще всего, недоучившие CL ;)

dave ★★★★★
()
Ответ на: комментарий от vertexua

Scala уже активно используют в швейцарском банке, на который я работаю как удобный процессор XML

Казалось бы, причем здесь Швейцария? :)

dave ★★★★★
()

а почему «или или»? можно haskell и python изучать я так и делаю

не обязательно делать haskell основой, но познакомиться с ним уж точно не лишнее

Deleted
()
Ответ на: комментарий от dave

В последнее время неплохо развивается.

Вроде бы активность на planet-lisp несколько возросла. Но я уже не верю.

Даже archimag CL забросил ;)

А если сравнивать достижения CL за последние лет 5 с достижениями хаскеля, то совсем грустно получается.

коммерческие лиспы - у них денежный стимул для развития

Какой вообще стимул может быть у абсолютной монополии?

Macil ★★★★★
()
Ответ на: комментарий от dave

Время жизни замыкания.

Оно (лямбда с capturing) там может сколько угодно жить, просто управление памятью ложится на плечи программиста - GC не помогает, нужно упаковывать лямбды (в виде std::function) с замыкаемыми данными (можно в виде std::shared_ptr) в возвращаемые структуры (собственно, «замыкания»). И то только если делать подобие let over lambda - обычные чистые «замыкания» в духе хаскеля делаются без проблем.

quasimoto ★★★★
()
Ответ на: комментарий от Macil

А если сравнивать достижения CL за последние лет 5 с достижениями хаскеля, то совсем грустно получается.

CL - уже давно устоявшийся язык. Меняются в основном реализации и развиваются библиотеки. Некоторые из реализаций наконец-то стали иметь версию 1.x после многочисленных 0.x (sbcl, abcl), что о чем-то да говорит. Недавно появилась новая реализация mkcl. Потом, я вижу явный прогресс с библиотеками для реализации ecl. Вот-вот, скоро заработает там closer-mop (общая прослойка для meta object protocol), а там множество других библиотек, даже таких необычных, как cl-cont.

Но если брать область разработки коммерческого софта, то я думаю, что позиции lispworks и allegro cl по-прежнему очень и очень сильны, по крайней мере, мне так видится. Десктопное приложение я бы стал создавать на одном из них, а это - качественная реализация стандарта, хорошие библиотеки, включая библиотеки GUI, хорошая документация, служба технической поддержки. Думаю, что проблемы здесь преодолимые.

Я настроен вполне оптимистично. На мой взгляд скорее Scala загнется, чем CL.

dave ★★★★★
()
Ответ на: комментарий от quasimoto

О чем и я. Кроме того, shared_ptr - далеко не полное решение.

dave ★★★★★
()
Ответ на: комментарий от makeB

4.2 такое 4.2. куча разработов питона работают под вендой, более того, делают такие косяки как слеш не в ту сторону... что говорит о том, как хорошо они знают линукс. сам с этим сталкивался

BattleCoder ★★★★★
()
Ответ на: комментарий от makeB

Ты вот скажи мне: зачем в игровой прошивке ЯП?

Eddy_Em ☆☆☆☆☆
()
Ответ на: комментарий от Macil

А если сравнивать достижения CL за последние лет 5 с достижениями хаскеля, то совсем грустно получается.

Clojure заменила CL. У Кложуры сейчас всё цветёт и пахнет, очень модный и молодёжный язык.

mv ★★★★★
()
Ответ на: комментарий от Eddy_Em

Разложилась на плесень и липовый мед?

Продолжай приматывать медные проволочки к 40-ваттному паяльнику и ваять на сишечке банальную прикладную аппликуху. У меня паяльная станция и лисп ;)

mv ★★★★★
()
Ответ на: комментарий от dave

человеческий язык диктует то, как и какие мысли формулируются.

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

iVS ★★★★★
()
Ответ на: комментарий от dave

Основаны эти утверждения на его богатом опыте создания и изучения программ по ИИ (AI) (целую книгу PAIP написал на тысячу страниц).

но ИИ он так и не создал. Что символизирует.

И все-таки, язык сильно диктует то, как НЕ решается задача.

//fixed

drBatty ★★
()
Ответ на: комментарий от drBatty

Не надо недооценивать успехи в области ИИ. Если бы не было Macsyma, то и не было бы сейчас Mathematica и Maple (Последний живой еще? Баловался, когда был студентом). Потом область компьютерной алгебры просто отпочковалась от ИИ в отдельную область. Само же понятие ИИ очень размытое, и оно никогда не имело четких границ.

dave ★★★★★
()
Последнее исправление: dave (всего исправлений: 1)
Ответ на: комментарий от dave

Я настроен вполне оптимистично.

Действительно. Оказывается ECL, крайне оптимистичная штука. Надо будет замутить на нем что-нибудь. ;)

Правда REPL у него, как я понял, только в режиме интерпретации а-ля GHC.

Macil ★★★★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.