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

>А еще встать у казино в Лас-Вегасе и объяснять заходящим в него, как бы они могли потратить свои деньги.

хе-хе. надо запомнить))

читабельность с goto уменьшается и это факт.

Да, в российской аэрокосмической промышленности, например. (Пишут ПО для искуственных спутников).

Если вы не умеете им пользоваться, то несомненно. А по ссылке как раз все четко и ясно.

> Разрешаю вам пилить офис.

А еще встать у казино в Лас-Вегасе и объяснять заходящим в него, как бы они могли потратить свои деньги

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

Часом не для глонасса и его ракет? Wait, oh shi~!

пусть ненавидят. меньше красноглазого ламерья среди .NET разработчиков. :-) все равно лучше дотнета ничего нету.

Да. Поэтому глонассы благополучно упали. Это как одни шаромыжники на freepascal программу для АЭС пишут, ждем конца света :-o

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

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

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

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

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

Что-бы бойцы не занимались всякой фигней,

А что по твоему не фигня? Клепать одинаковые сайтики на было-фреймворках?

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

меньше красноглазого ламерья среди .NET разработчиков. :-) все равно лучше дотнета ничего нету.

В вашем .net таки появилась крссплатформенная абстракция механизма select, которая под linux в качестве импелментации использует epoll? Нет, а вот в JVM есть.

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

Break ухудшает читаемость в разы больше гото, особенно когда их пачка и много скобок или бегин эндов. Это просто тихий ужас а не улучшение читаемости. За рефакторинг кто-то должен платить, а в линуксе много бесплатного кода, предлагаете авторам за свой счёт заниматься ненужной работой;) Вирт чтобы избавиться от гото, несколько новых языков придумал а толку от этого мало. Без ооп польза от неиспользования гото неочевидна.

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

А что с современными теориями? Мож я из анабиоза, но Кнут ничего особо нового не придумал, все как и много лет назад - струкутрное программирование.

Не только ООП. Функции-обертки вполне годятся, вот только не в данном примере их применение будет еще большим ужасом чем do {} while(0) :-)

Декларативное и функциональное программирование прошло мимо вас? Это печально.

Ухудшается не читабельность, а структура.
И не ухудшается, а усложняется.
И не с goto а с безусловными переходами.
И не факт, а так, наблюдение за малообразованными кодерами.

Декларативное и функциональное программирование прошло мимо вас? Это печально.

Нет, почему. Я где-то год жизни отдал Scheme и Haskell. Потом как-то приелось и интерес растворился. Во-первых архитектура современных компов идет сильно в разрез с функциональным программирование. Тот же GHC сглаживает различия, но все равно без бубна не обходится. Во-вторых вся серьезная алгоритмика разработана под императивные языки. Если говорить по-тупому: вот если Кнут вдруг напишет книжку по эффективным функциональным алгоритмам, я с радостью прочитаю и буду писать на хаскеле. Никакого функционального программирования (а конкретно эффекивных функциональных алгоритмов) пока не существует, оно еще не разработано и не принято. Да, видел, что какие-то работы ведутся, но все же. А так идеи светлые, многообещающие, но из сильно далекого будущего.

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

Вот именно!

И C++, и Python допускают несколько стилей программирования. Ну а виртовые поделки едва дотянулись до ООП.

Бывают вещи, которые в изящно выглядят в декларативном стиле, другие можно внятно записать только в императивном. Виртовые поделки просто не позволяют выразить, к примеру, описание грамматики в XBNF.

Ну а виртовые поделки едва дотянулись до ООП.

Я вот устал плеваться от процедурного кода (именно процедурного, до структурного такие поделки не дотягивают) на Java. И ничего, живет народ! Структурное программирование + модульность- это и так очень много. Настолько много, что в мире реально существует очень мало кода, соответствующего этим концепциям. ООП кода еще меньше. Так что это все очень сомнительно.

Виртовые поделки просто не позволяют выразить, к примеру, описание грамматики в XBNF.

Ну тут вопрос филосовский. Либо сильно изощрять язык и допускать выкрутасы вроде написания xbnf прямо кодом. Либо решить, что xbnf пишут ооочень редко и это можно делать средствами внешеней тулзы, генерирующей целевой код. Язык же при этом можно сильно упростить.

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

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

>И C++, и Python допускают несколько стилей программирования. Ну а виртовые поделки едва дотянулись до ООП.

Во первых, паскаль как раз допускает ООП и процедурное программирование.

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

> Не только ООП. Функции-обертки вполне годятся

Давайте называть вещи своими именами. Вместо одной большой функции придётся сделать одну поменьше и кучу мелких велосипедных. А поскольку внутри функции значительная часть данных локальные переменные, придётся гонять туда/сюда лишние данные. Чтобы это было легче делать - наплодить побольше новых типов переменных, для каждого случая новый а потом разбираться в какую переменную через какое отверстие запихивать/вынимать данные. Это только один аспект вопроса. Через какое-то время от кода потребуются новые свойства, и тут-то потребуется вместо добавления пары переменных и гото что-то переделывать и отлавливать баги. Сколько лишних сущностей и при этом нельзя сказать функции: да пошла ты на тысячную строку, @#$%~ Последнее самое важное, поскольку даёт возможность применять в коде _живой_ разговорный язык.

> Либо сильно изощрять язык и допускать выкрутасы вроде написания xbnf прямо кодом.

И C++, и Python позволяют делать это без выкрутасов. Шаблоны + перегрузка операторов + хорошая фантазия. Как мне кажется, метапрограммирование при помощи шаблонов в C++ возникло как побочный эффект. :-)

Либо решить, что xbnf пишут ооочень редко и это можно делать средствами внешеней тулзы, генерирующей целевой код.

Вы знаете, код bison выглядит крайне чужеродно в коде C++. Boost.Spirit в том же месте куда изящнее.

Я вообще считаю, что если есть возмжность обойтись без какой-то фичи, то ее нужно непременно выкинуть.

Чтобы каждый изобретал свой велосипед? Если что-то нужно каждый день, то выкидывать это себе дороже.

но идеи славные, и ничто не запрещает их невозбранно черпать и использовать.

Вот чего у вирта нема, того нема.

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

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

Чтобы каждый изобретал свой велосипед?

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

> поцкаль

ООП

Да когда же?!

Вирт всегда делал учебные языки

Учебный язык --- это лого, про черепашек.

Если он делал учебные языки, почему же это убожество так любят пихать в реальные задачи?

Вот чего у вирта нема, того нема.

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

> Ну вот почему явление «думать и создавать хорошо заточенное под задачу решение» многие непременно называют велосипедостроением?

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

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

Я такого никогда и не утверждал.

Откройте для себя Питон. Там поток Enhancement Purposes куда шире. :-)

Я такого никогда и не утверждал.

Ну извиняй тогда :)

Откройте для себя Питон.

Уже-уже. Пишу немного по работе.

>Вирт еще говорил, что нельзя учить студентов не продакшн языку.

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

И потом, ничто не мешает писать на учебном языке. Он вовсе не бездумно упрощеный. Учебный язык должен быть прост в понимании и чист в реализации. А писать на нем можно быстро и эффективно.

>Если он делал учебные языки, почему же это убожество так любят пихать в реальные задачи?

потому что простой язык, на котором пишут в институтах, значит проще найти дешевых программеров. Вот и пишут.

Я не знаю решительно ни одной задачи, которую на пацкале можно было бы написать быстрее, чем на Питоне или на C++.

Причем пишут, заметьте, не на изначальном убожестве, а на убожестве, удобренном десятками, если не сотнями, костылей. Однако если говно посыпать пудрой --- это будет говно, посыпанное пудрой. Иными словами, идея «учебного языка» изначально тупиковая.

Рядом с Кнутом и его TeX-ом вирта с поцкалаями даже и не видно.

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

o_0

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

Иными словами, идея «учебного языка» изначально тупиковая.

Точно.

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

>Ну а виртовые поделки едва дотянулись до ООП.
Ну а виртовые поделки едва дотянулись до АОП.
fixed

>Я не знаю решительно ни одной задачи, которую на пацкале можно было бы написать быстрее, чем на Питоне или на C++.

Напиши быстро линукс на чистом питоне так чтобы был быстрее и неглючнее паскалевских программ)))))))) А на паскале была написана первая винда и до сих пор живее всех живых. Питоновая реализация не дожила бы до второй версии и на плюсы портировать было бы нечего. Дельфи и лазарь это тоже паскаль, плюсы там вообще не нужны, так как базируются на древнем сишном синтаксисе. «Напиши то, не знаю что и чтобы не тормозило» на паскале лучше всего. Вот чистый Си нужен. И только для того, чтобы собиралось через привычные configure/make и его либами в других языках пользовались. При этом, сколько времени затратили сишники на разработку, не имеет большого значения, это их личное дело.

Если он используется только как «finally для бедных» --- не уверен.

А с этим что не так? В моно для реализации не epoll использует?

http://msdn.microsoft.com/en-us/library/system.net.sockets.socket.select.aspx

Товаищи обсирая паскаль так вовремя забывают что GNU C бутстрапился с паскаля, что аж грешно не напомнить ;-)

> Задачи решают не на языке программирования, а в голове.

«И скачет не лошадь, а жокей».

> А на паскале была написана первая винда и до сих пор живее всех живых.

В первой условно-работающей Windows от паскаля остались только соглашения о вызовах.

> Задачи решают не на языке программирования, а в голове.
«И скачет не лошадь, а жокей».

Однако... «Кадры решают все».
И посему мне видится разрешение данного тобою утверждения в ключе: «Плохой жокей скачет, хороший жокей ведет». Аналогично и про ЯП с головой.

>Рядом с Кнутом и его TeX-ом вирта с поцкалаями даже и не видно.

А ты, школьничек, знаешь на чём TeX написан?:)

В mono используется системный вызов select. И mono != .net.

Название web2c наводит тоже на мысли %)