Comments 94
Могу добавить что для компиляции и запуска несложных программ на очень многих языках программирования (несколько десятков) очень удобной оказалась среда разработки Geany (под Linux, но вроде и под Винду есть порт). Раньше под виндой приходилось держать кучу сред разработки (да, конечно можно и из командной строки… но лично мне удобнее и писать код, и компилировать и запускать из одной программы).
… и уберёт страх перед незнакомым синтаксисом

Страх сам собой пропадает после того, как приходит понимание, что есть грубо говоря три варианта синтаксиса:
— «синтаксис в стиле Си» (C++, Java, C#, Javascript, Go, Vala...)
— «жизнь без скобок» (Python, Ruby, CoffeeScript… ассемблер? Хотя нет, не будем про него)
— «жизнь в шоколаде)))))))» (Clojure, Scheme, Common Lisp...)
Стоит разобраться с одним языком из каждой «языковой группы», как сразу появляется возможность относительно спокойно читать код и на остальных языках.

P.S.: Было бы здорово, если бы мысли, описанные в статье, применялись в наших вузах. А то сейчас часто берут какой-то один язык и мучают только его, даже не сравнивая с другими.
Языки подразделяются не только по стилю. Есть ещё функциональные (Erlang, Scala, F#), декларативные (SQL, QML, XML) и совсем экзотические (Prolog)
Я говорю не о методах классификации языков, не о парадигмах (тот же самый JS позволяет как писать в функциональном стиле, так и строить систему классов, хотя и немного странную), а именно о синтаксисах. Упомянутые вами Erlang или F# синтаксически похожи на CoffeeScript.
Упомянутые вами Erlang или F# синтаксически похожи на CoffeeScript.
Не, это совсем мимо. CoffeeScript сам по себе очень искусственный гибрид.
Erlang — говорят, синтаксически Prolog.
F# — довольно типичный ML(SML, OCaml, множество их).
Синтаксис Erlang создавался под влиянием синтаксиса Prolog, F# — на базе ML. Даже с точки зрения синтаксиса у них мало общего с CoffeeScript, на который повлияли js, python и ruby.

Ant — не язык программирования общего назначения. Скорее можно назвать это dsl'ем, использующим xml разметку. Другой пример — xslt.

не экзотические, а языки логического программирования, обертка над исчислениям высказываний или предикатов, только и всего
Не всё так однозначно даже с синтаксисом.
Синтаксис PERL (да и не только синтаксис) основан на С, однако зная второй, но не первый — читать его будет ой как не просто.
Спорное утверждение. Скрипты на perl обычно сложно читать из-за того, что люди делают на нем однострочники с кучей регулярных выражений. Если бы мы на С писали все в одну строку и активно пользовались регулярками — это тоже было бы довольно сложно воспринимать. Тут уже вопрос стиля конкретного программиста/проекта/задач, которые ставятся. И на perl можно писать чисто и красиво, и на С можно сделать что-то страшное.

Чем Perl отличается от PHP? В Perl сразу всё не понятно, а в PHP — только в регэкспах.(Ц) баш
PS. Мне те же скрипты удобнее написать на perl под виндой, чем на powershell, а у cmd возможностей просто не хватает.

UFO landed and left these words here

А также Pascal/Modula/Ada, MLи (начиная от непосредственно семейства: SML, OCaml, заканчивая Scala и Rust), всякие вещи типа APL/J/K/R. В общем, не очень получилась классификация групп синтаксиса.

Сам на нем не работал, поэтому посмотрел случайные примеры на rosettacode, особенно понравилась инициализация OpenGL — https://rosettacode.org/wiki/OpenGL#Forth. Непривычно видеть все написанным «в обратную сторону», но в целом многие конструкции сразу узнаются. Можно отнести к «перевернутому» варианту без скобочек :)
А вы напишите свою форт-систему — тогда начнете лучше понимать основы.

В порядке ликбеза.
«Конкатенативный» — означает стековый. Это практически синонимы.
Обратная польская запись — это форма записи выражения в стековом языке. Собственно их всего две: прямая и обратная. И любой стековый (конкатенативный) язык относится к одной из двух форм.
P.S. я соавтор двух форт-систем

Конкатенация (соединение) слов программы это не прямая иерархия "пассивных" аргументов и "активных" действий по их обработке. СЛОВО (в рамках концепции Форт языка) это произвольно семантически наполняемая абстракция без необходимости формально фиксировать иерархию подчинения слов. СЛОВО может быть как активным (беря обработку входного потока программы) так и пассивным. Полиз нотация это только частный взгляд на возможность упрощённого понимания точки применения действия в сформированном контексте.


P.S. Предпочитаю не писать без необходимости свою Форт систему, а использовать уже существующие.

Immediate — это частный случай. Вы же не называете С++ макро-языком? Хотя у него аж две стадии макроообработки.

Immediate, да это частный случай дизайна Форт как и другие частные механизмы введённые в дизайнм языка и позволяющие создавать произвольную синтаксис-семантику (DSL) в процессе трансляции программы для поддержания любой парадигмы программироания при создании ПО (без ограничений) минимальными штатными средствами.


P.S. Если бы Форт ограничивался пониманием Полиз, то возможно было бы его формально перетранслировать в Си выполняемый листинг. :)

Не вижу никаких проблем в трансляции в исполняемый код или Си. Если сильно заплатят — готов сделать. Это все делается JIT-компиляцией (или полной), к которой форт отлично приспособлен (получше JAVA).

Как пример кросс-компиляции — игрушка "Ну погоди". Там явно вычищены заголовки словарных статей и все неиспользуемое, включая механизм компиляции. Иначе бы не влезли.

То есть компиляции форта в Си выглядит так
1) Компиляция самого форта в словарь и назначение главного слов
2) Обход дерева и маркировка используемых слов.
3) Пословная кодогенерация на нужный язык. Проще в машинный код, но можно и в Си.
4) Если в Си — маркировка часто-используемых слов как inline и прочие оптимизации.

Это интересно с исторической точки зрения т.к. далее был принят стандарт на язык 94года и развитие Форт реализаций продолжилось до настоящего времени.


P.S. В тоже время где то был в развитии ДССП (диалоговая система структурного программирования)

Это будет уже не совсем Форт, но ничего не мешает использовать механизм "ленты" или буфера ввода/вывода. В Форте можно и сейчас со стэком работать как с индексируемым или использовать именованные локальные переменные.


P.S. Использование стэка в Форт имеет ряд очевидных плюсов и меньшее количество минусов.

Вот поэтому и обратная польская запись.

Вас не удивляет, что в С++ — отдельный макропроцессор со своим собственным синтаксисом? И второй способ макрогенерации через темплейты. Ну вот и в форте — в компилируемой части обратная польская запись. А интерпретируемая часть (immediate) — это аналог макропроцессора, темплейтов и contexpr в С++.

Собственно immeduate-слова все равно работают со стеком, только есть ещё и вычитка последующих аргументов из потока. Но эта вычитка — не является конкатенативной!!! То есть immedaite программирование не подпадает под определение конкатенативного языка.
Вас не удивляет, что в С++ — отдельный макропроцессор со своим собственным синтаксисом? И второй способ макрогенерации через темплейты.

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

Согласен. В форте слова, исполняемые во время компиляции, (immediate) предназначены в первую очередь для создания ключевых слов (операторов) языка форт. Кроме того, они могут заменить оба способа макрогенерации в СИ. А синтаксис… синтаксис может быть какой угодно. У immedaite полный доступ к компилятору, более того, сам процесс компиляции идет через immediate-слова.

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

Но! Никто так не делает. И в основе форта — именно обратная польская запись. Хотя да — можно извратиться.
Да в общем то. И C влияние чувствуется. Но let и: из ML туда пришли.

Это всё прекрасно, только в текущих реалиях "знание языка" — это не только возможность что-либо на нём написать, но и знание его преимуществ / недостатков / специфических конструкций, знания об "окружении" языка (библиотеки, фреймворки) и умение это знание использовать.

Просто очередной провокационный заголовок, где под знанием языка стали понимать знание синтаксиса. Знать синтаксис тех же плюсов и знать их так, чтобы более-менее нормально писать без UB каждые десять строк (особенно, если использовать стандарт младше C++11) — две большие разницы.

Ну да.
Я код на ruby вполне прилично читаю, если он в контексте, при том что ни строчки не написал на нём.

Руби в целом приятный и понятный, но за счёт большой гибкости самой объектной системы, которая мне крайне импонирует, в нём очень развито метапрограммирование и им периодически злоупотребляют ради удобных dsl'ей и convention over configuration.


В итоге часто читать легко, а понять как работает — куда сложнее. И это даже без monkey patching'а, который добавляет ещё радости.

Писать без UB довольно просто. А вот писать на С++ хорошо — это уже другое дело.

Писать без UB только изучив синтаксис просто?! Куча довольно опытных программистов достаточно регулярно наступают на UB на C и C++, поэтому ваше утверждение порождает во мне некоторые сомнения..

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

Во-вторых, «изучить я зык программирования» в статье понимается как «понять идеи, на которых основан язык» + «изучить синтаксис». Это — как правило, не проблема. Но что бы практически использовать язык, необходимо достаточно свободно ориентироваться в «стандартной библиотеке» (а она в том или ином виде всегда есть) и иметь навык комбинирования возмножностей, предоставляемых языком и стандартной библиотекой, для получения оптимальных результатов. А это уже совсем другие затраты сил и времени.

Хотя с основной мыслью статьи о полезности изучения базовых принципов, на которых строятся языки программирования, полностью согласен. Глупо было бы спорить.
С иностранными язывками то же самое. Научиться читать без словаря и воспринимать на слух речь не так уж сложно, а вот чтобы самостоятельно писать на уровне, существенно превышающем Google Translate, и тем более говорить — даже и 10 лет не хватит.
Причём причина в общем-то одна и та же: отсутствие обратной связи. Если где-то налажали с синтаксисом, компилятор вам об этом просигналит. А вот если не знаете особенностей управления памятью или обработки IP-пакетов, всё работать будет, но время от времени без видимых причин тормозить или крашиться под высокой нагрузкой. И совершенно непонятно почему и как это исправить.
То же и с естественными языками. Если вы не знаете какого-то слова или не можете распарсить предложение, потому что там 5 глаголов и все в разной форме, вам сразу понятно, что тут есть пробел и даже понятно, как его исправить.
А вот если вы накорябали фразу, то чёрт его знает, как определить степень корявости и чем заменить корявые участки. Нет обратной связи — нет обучения.
С иностранными язывками то же самое. Научиться читать без словаря и воспринимать на слух речь не так уж сложно, а вот чтобы самостоятельно писать на уровне, существенно превышающем Google Translate, и тем более говорить — даже и 10 лет не хватит.

Смотря как учить.
Чтобы говорить и так далее — для неплохого уровня хватит и трёх курсов интенсива (мой реальный опыт: три курса интенсива, каждый курс брал раз в год). А чтобы говорить на уровне "моя твоя понимать", хватит и одного хорошего курса.

один язык с продвинутой поддержкой параллелизма (Clofure или Go).

исправьте, опечатка

С точки зрения "сначала поржать, а потом подумать" очень интересен псевдодекларативный, объектный, заточенный для написания игр, язык Inform7. Обладая совершенно необычным синтаксисом, он тем не менее позволяет "на лету" городить сложные иерархии объектов и связывать их сигналами, а на них уже писать бота-говорилку. Это, в общем то, всё, что он умеет. Познавательно. Позволяет понять, что код может и не состоять из блоков — не единственная возможная.
Ну а для тех, кто хочет всерьёз задуматься о мире и своём месте в нём, всегда есть Haskell.

Haskell уже не так модно, лучше погружаться в экзистенциальный кризис в языках с нормальной поддержкой экзистенциальных типов всяких Idris.

Множество интересных синтаксических конструкций есть в Wolfram language.
Он не только мультипарадигмальный, но и приемлет большое количество синтаксических стилей, и синтаксис там можно сильно изменять.
Да что уж там говорить – графические файлы, математические формулы – валидные компоненты кода, у операторов настраивается приоритет, запросто можно ввести свою мудрёную нотацию, картинку использовать как переменную, использовать префиксную/постфиксную/инфиксную/надфиксную или любые другие формы записи, ну и так далее.
Это мой любимый язык в плане вариативности и кастомизируемости синтаксиса.
Если кому интересно, буду рад подискутировать**

большое количество синтаксических стилей, и синтаксис там можно сильно изменять… у операторов настраивается приоритет, запросто можно ввести свою мудрёную нотацию

А есть ли это хорошо?

Wolfram language был спроектирован таким, видимо, исходя из каких-то достаточно веских оснований. Для универсального языка программирования такие возможности скорее минус, чем плюс. Вот, кстати, Ruby: одно и то же действие можно описать 2-3 разными синтаксическими конструкциями. Типа «кто как привык, пусть так и пишет». Но такой подход приводит к тому, что при разборе чужого кода надо помнить эти 2-3 вида конструкций. И это уже не хорошо.

Люди разрабатывают code style для того, что бы ограничить разнообразие использования пробелов, отступов, переводов строк. А тут полная «демократия» на уровне конструкций языка.

Как же про Rust то не сказали. Вот уж там конструкции так конструкции.

Идея отличная, и сам ей следую. Но я никогда не буду учить Brainfuck, мне жалко свой мозг.

Ирония в сторону названия понятна, но если серъёзно — Haskell, например, больше brainfuck чем brainfuck )

Позвольте поинтересоваться, как именно вы сталкивались с обоими?

Самое смешное, что после изучения 5-10 языков, можно отлаживаться и на незнакомых языках.

1986ой год. Приехал в пионерлагерь к приятелю, работавшему вожатым. Весь вечер помогал деткам отлаживаться на БК-0010. И только ночью наконец-то почитал, что такое FOCAL.

Ну вообще-то из второго первое вовсе не следует. В случае данных примера и утверждения так совсем ложь.

А в чем ложь-то? Свидетели ещё живы, могут подтвердить. Большинство багов — в алгоритмах, они от языка не зависят.

Совершенно верно. Как-то прочитал что, де, "я настолько давно программирую, что у меня уже нет любимого языка программирования". Собственно, принимая во внимание 30 летний стаж работы (читай — программирования) с компьютерами у меня эта стадия наступила уже давно. В принципе, на этой стадии можно не зная языка читать и понимать программы на нём, и, даже более того, находить и успешно патчить баги.
Кстати, начал я именно в 1986, а в 1988 уже имел свой БК-0010.

У меня примерно так же, начал в 1981ом, первое домашнее УПД на перфоленте — 1982ой, с 1983его — работаю программистом. А первый «свой» комп — тоже в 1988, только это была СМ-1420 и занимала она комнату метров 30 квадратных.
> Если провести историческую аналогию, то кем бы вам больше хотелось быть: работником за ткацким станком, ежедневно выполняющим рутинные операции или разработчиком новых моделей таких станков?

Извините, но для преподавателя он слишком узко мыслит… Можно знать как работают станки и быть директором завода. Можно быть отличным мастером станка и создавать шедевры на все времена. Можно быть средненьким задротом станка, но увидеть, где можно его оптимизировать и ускорить производство. А можно быть full-stack на заводе и мыть там полы, а когда сломался станок — починить его. Это как Микеланджело сказали бы: «зачем ты рисуешь? лучше придумывай новые краски и кисточки!»
UFO landed and left these words here
В статье не хватает упоминания о совсем другом мире языков — HDL (hardware definition language, verilog, vhdl). Крайне полезно попробывать себя в HDL даже для расширения кругозора, не обязательно быть инженером в области цифровой электроники. Принципиальный паралелизм языков описания электронных схем помогает взглянуть с другой стороны на понятия «одновременно» и «последовательно», и соответственно развить возможности сверх паралельного мышления, а значит и программирования.
Принципы работы HDL очень хорошо демонстрируются моделями на Haskell. Думаю, начинать надо с него, если есть желание двигаться в сторону железа.
Имхо, чтобы стать инженером разработчиком, а не программистом X-языка, нужно изучать в порядке важности:

Предметную область(или несколько), в которой вы хотите быть профессионалом. Например, структуры данных, алгоритмы или WEB итп.

Различные парадигмы и подходы, которые применяются в языках. ООП, функциональщина итд

И только потом уже смотреть на синтаксис языка и его особенности. Зная всё выше написанное, конкретный язык будет изучить не так сложно.
Тут бы один выучить хорошо, куда там все. Согласен, можно добиться общего понимания программирования как процесса и это позволит после изучения синтаксиса писать алгоритмы на разных языках, но какая от этого практическая польза?

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

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

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

В итоге, думаю что следует погрузиться в Structure and Interpretation of Computer Programs, а там видно будет.
Как говорится:«Хороший программист на фортране, может написать на любом языке хороший код фортрана». Или что-то вроде того…
Странно. Большая часть статей на хабре\ГТ рекомендует учить один-два-три языка и хорошо, дабы резюме не выглядело как «Фотограф\тамада\автослесарь». А тут про «минимум пять».

Написать небольшую программу на 100-200 строк не проблема после нескольких дней чтения мануалов практически на любом современном языке, для человека, выучившего хотя бы паскаль уровня школького кружка по информатике. Но зачем? Единственное положительное, что я в данном моменте вижу это открытие для себя новых горизонтов — «почувствовать» язык. Но для этого хватит недели-месяца.

Другое дело, что для «промышленного» программирования нужно более глубокое понимание принципов. Даже на ругаемом многими РНР написать гостевуху с $sql = «insert into soobshenia (text) values ('».$_GET['text']."')"; (Ну вы понимаете, к чему клоню =) ) и участвовать в разработке сложного проекта на каком-нибудь популярном фреймворке это совсем вещи разные. Сейчас мало знать чистый РНР или Питон, надо знать фреймворки, библиотеки и уметь их применять.

Очень многие не пишут в таких статьях, что между ИИ крестиков-ноликов и многопользовательской игрой лежит огромная пропасть взлетов, падения, мата, пота и кипения мозга. Поэтому лично мне изучения двух-трех языков ближе. На работе пользуюсь РНР по ряду причин и для специфичных задач (радует работающий из коробки snmpget(), например) учу Питон ну и JS для личных проектов.
Большая часть статей на хабре\ГТ рекомендует учить один-два-три языка и хорошо, дабы резюме не выглядело как «Фотограф\тамада\автослесарь». А тут про «минимум пять».

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


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

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

Странно. Большая часть статей на хабре\ГТ рекомендует учить один-два-три языка и хорошо, дабы резюме не выглядело как «Фотограф\тамада\автослесарь». А тут про «минимум пять».
Джейми Хайнеман (разрушители легенд) родился в США, имеет диплом по русскому языку и литературе, работал сертифицированным мастером погружения, был капитаном яхты, экспертом по выживанию в дикой природе, был владельцем магазина домашних животных, машинистом, строительным инспектором по бетону, шеф-поваром, делал спец эффекты и атрибутику для кино и рекламы, и конечно же был главным разрушителем легенд. И это без перечисления периодических участий в разных ТВ-шоу и тому подобных акций (сражения роботов, симпсоны, и т.п.)
Напоминает универсальный совет Кнышева «Старайся чаще бывать везде».
А ещё можно изучить QuickBasic, потом С++ и писать на С++ в стиле QuickBasic.
Ну изучение C будет полезно далеко не для всех языков — учить потом Haskell или Prolog будет даже сложнее.
Из параллельных языков стоит отметить незаслуженно забытый Sisal. Он бы хорошо на видеокарты лег.

А где in the wild используется Пролог? Не, его поверхностно изучить стоит, просто чтоб знать, что так вообще можно, но пролог по умолчанию медленный.

Не такой уж он и медленный. Просто стиль программирования на нем не поощряет эффективное программирование, а эффективный код выглядит кривовато.
Логическое программирование сейчас почти не применяется. Все, что я видел — это использование библиотеки core.logic в Clojure (вариация на тему mikiKanren).
Про Пролог слушал, что он применялся в программировании правил управления питанием в какой-то мобильной системе.
Я думаю, его с успехом можно было бы применять сейчас в разработке чатботов, в том числе с использованием индуктивного логического программирования (машинного обучения на базе Пролога).

А можете посоветовать какую-ть книгу по отсечению обхода и про то, как сделать так, чтобы порядок строк не влиял на поведение программы (т.е. как грамотно защититься от зацикливания)? У Братко я ничего такого не помню

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

Учитывая, что в классическом Прологе — строгая бинарная логика без каких-либо случайностей или неясностей, то для практических реальных задач лучше подойдёт Fuzzy Prolog, но он, вроде, увы, существует только "на бумаге" :(


PS кто в курсе как обстоят дела с Curry и Mercury?
Эти языки помимо логического программирования поддерживают ещё и функциональное, а значит должны лучше подойти для практических задач.

Нечеткая логика — вещь сомнительная. Она не соответствует теории вероятности, то есть может выдать внутренне противоречивые рекомендации. Хотя для работы с зашумленными данными действительно требуется что-то новое.

Про Curry давно ни чего не слышал. По моему проект не развивается, несмотря на две независимые реализации. В Merury вроде есть какая то жизнь, но я не очень слежу. Он уж слишком ориентирован на производительность, думаю это не очень актуально.
один декларативный язык (Prolog

А почему не SQL?


Я конечно понимаю, что идея Пролога — красивая. Но, на практике вряд ли кому придётся разбирать код на Прологе, скорее всего это будет код на SQL.

Есть еще язык запросов SPARQL, синтаксисов похожие на SQL, но семантикой ближе к Prolog. Он вполне может пригодиться.
Во-первых, я не понял, как от темы изучить все языки программирования автор так ловко перешёл к теме написания компиляторов. То есть если я хочу изучить все языки программирования, мне нужно уметь компилировать?

Во-вторых, про книгу дракона. Я как-то пытался её прочитать, но не смог, слишком сложно. Хотя как написать компилятор, я представляю. В общем, книга дракона слишком сложная. Читайте что-нибудь попроще. Ну или попытайтесь просто представить себе, как бы вы стали делать компилятор. И напишите. Вот отличная ссылка в тему, она необходима этому посту: http://prog21.dadgum.com/30.html
Мне кажется, автор немного путает теорию языков программирования и разработку компиляторов. Это хоть и рядом, но не одно и то же.

Именно теорию языков программирования можно изучать, на мой взгляд, двумя основными способами:
1. Практический: брать незнакомые языки разной степени упоротости и пробовать на них писать, попутно стараясь смотреть «вглубь», отмечая принципы, которые лежат в их основе, а так же идиомы, отличия от других языков и так далее.
Здесь могу порекомендовать книжку 7 языков за 7 недель, она весьма неплоха для поиграться с пользой.
2. Теоретический: писать на каком-нибудь лиспе интерпретаторы языков с разными свойствами, чтобы понимать, как оно внутри устроено, попутно копая в лямбда-исчисление и прочее.

Где-то посередине между двумя подходами находится отличный курс Дэна Гроссмана Языки программирования. Его я очень, очень рекомендую.
Спасибо за интересный перевод. Жаль, не успел принять участие в обсуждении. Обсуждение показалось мне интереснее, чем статья. Немного в сторону:
Треугольник иллюзий. Человек сразу видит на этом рисунке треугольник, но нужно потратить изрядные усилия, чтобы научить компьютерную программу делать это.
Это утверждение статьи вызвало недоумение. Преобразованием Хафа находим отрезки прямых, далее отрезки, лежащие на одной прямой, и точки пересечения этих прямых. Проще простого!
Only those users with full accounts are able to leave comments. Log in, please.