ИМХО неудачный пример. Если мне придется парсить что-либо, для чего можно составить регулярное вражение или КС-грамматику, я обязательно буду использовать средства автоматизации. Раньше это были bison/lex, сейчас еще хочу попробовать boost::spirit. Даже если мне нужно будет написать парсер для ini-файла, я также буду использовать средства автоматизации. Потому-что:
— это просто (Сравните объем кода парсера и объем грамматики.)
— это надежно (Во-первых, средства автоматизации обнаруживают все ошибки несоответствия формата. Во-вторых
генерируемый код достаточно надежен. Это конечно справедливо для известных инструментов.)
— это расширяемо (Расширился формат — добавили несколько прaвил в грамматику.)

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

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

Здравствуйте, Maxim S. Shatskih, Вы писали:

sch>>даже сделать следующий опыт. Зайти на форум по C++ и спросить: как парсить
sch>>CSV-файлы. Вам тут же начнут предлагать варианты типа Boost.Tokenizer, еще
sch>>какие-то библиотеки, предложут воспользоваться генераторами парсеров и
MSS>Вот на мой скромный взгляд, когда девелопер в ответ на такие вопросы с ходу говорит "давайте возьмем готовую библиотеку такую-то" — это двойка.

Двойка — это когда он не знает, как решить проблему быстро и эффективно (да и то, спорно), а когда человек уже знает готовое решение, а уж если решение по соотношениям цена/качество удовлетворяет поставленным требованиям, то это твердая пятерка. Как тут неоднократно упоминалось — заказчиков не интересуют ни использованные библиотеки, ни языки программирования... Их интересует конечный результат за конечное время за конечные деньги, которые они вам заплатят.

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

Здравствуйте, beroal, Вы писали:

B>Здравствуйте, vdimas, Вы писали:
V>>Проблема еще в том, что у нас умерли более-менее наукоемкие направления в программировании. Мы пишем склады с бухгалтериями, сайты-магазины и это грустно (не все, к счастью, но это явный mainstream у нас). Ради прикола дал свое резюме на одном из
B>Читал не важно по какому поводу такую работу Composing contracts: an adventure in financial engineering
B>Financial and insurance contracts do not sound like promising territory for functional programming and formal semantics, but in fact we have discovered that insights from programming languages bear directly on the complex subject of describing and valuing a large class of contracts.
B>Научность определяется отношением и подходом к предмету.
B>Построение сайта-магазина как точная наука.

Почему нет? Посмотрим на эти сайты-магазины лет через 10, когда в построении "конструктора" для них будут задействованы различные профи, начиная от спецов по проектированию отказоустойчивых систем, и кончая спецами по статистике, рекламе и психологии обывателей

Ведь какая сейчас-то достигается цель? ЧТОБЫ РАБОТАЛО ХОТЬ КАК-ТО И НЕ ПАДАЛО!!!

Здравствуйте, FDSC, Вы писали:

FDS>Кстати, что за вложенные макросы? Зачем это? Если не секрет.


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

Здравствуйте, vdimas, Вы писали:
V>могут принимать другие макро как параметры (это вообще рулез).
Т.е. имя макро как параметр? А потом текст макро с этим именем можно вставить? А если он имеет параметры, как тогда?

Здравствуйте, vdimas, Вы писали:

V>Здравствуйте, FDSC, Вы писали:

FDS>>Кстати, что за вложенные макросы? Зачем это? Если не секрет.


V>это макро, в которых дозволяется юзать другие макро (и самих себя в т.ч.). Хорошие макро поддерживают внутри себя ветки условной компиляции, в выражении которых могут стоять параметры макро, и могут принимать другие макро как параметры (это вообще рулез). В общем, чем-то приближаются по возможностям к С++ с его специализацией шаблонов (и частичной в т.ч.).

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

Здравствуйте, vdimas, Вы писали:

V>Ведь какая сейчас-то достигается цель? ЧТОБЫ РАБОТАЛО ХОТЬ КАК-ТО И НЕ ПАДАЛО!!!

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

Здравствуйте, VladD2, Вы писали:

VD>Не, ну, языком то многие многое могут. Я вот, например, приблизительно знаю как создать ОС курче винды, но это не значит же, что я это смогу реально сделать. Хотя при большой нужнде...

Я собственно про то же. И вообще, вопрос как глубоко надо знать всё, что используешь.

приблизительно знаю Хорошее выражение. Надо взять на заметку.

Здравствуйте, GlebZ, Вы писали:

GZ>Здравствуйте, sch, Вы писали:

GZ>Когда-то были люди, которые знали только машинные коды напрямую выполняемые процессором, и именно они назывались программистами. Эти люди знали как устроена память, как устроен процессор, что такое триггер и элементы логики. Они знали все, почти до последней электронной лампы, с чем они работали. Только сомневаюсь, что им было интересно какой газ был закачан в эти лампы.

Между прочим, я некоторое время назад интересовался технологией изготовления ламповых приборов, правда немного из другой области. А триггеры вообще по электротехнике проходил. И транзисторы то же. И на машинных кодах программировал в учебных курсах (просто так то же). Но вообще, слава богу — есть С++, С#, Delphi и т.д.

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

По моему каждый программист знает как с регистрами работать. Не надо утрировать.

GZ> Мало кто знает как устроена сетевая карта.

Я не знаю. Согласен.

GZ>Поэтому абстракции — это хорошо. Без них никуда. Ну а если у них есть избыточность? GZ>То это тоже неплохо.

Хотя железо будет всё делать. Полностью согласен. Очень здорово.

Здравствуйте, ON, Вы писали:

>> Программирование должно стать и несомненно
>> становится более выскоуровневым.

ON>Для высокоуровневости есть предел — Лисп.
ON>Который на самом деле ассемблер.

Никогда на Лиспе не программировал, но по моему это не предел. Предел высокоуровневости не достижим. Интересно, как ты на "ЛИСП" робот запрограммируешь?

В каждой области будут появляться всё более мощные и адаптированные к ней приложения, которые будут больше делать за человека (за счёт вложенных в них знаний) — и чем больше знаний в этом приложении будет, тем более высокоуровневым оно станет.

Здравствуйте, AndrewVK, Вы писали:

AVK>Еще бы. Потому что в этих лампах никакой газ не присутствует .
А там что, вакуум закачивают?

AVK>Вобще то по идее преподают во многих профильных вузах по сю пору.
В профильных? Может быть. Я тоже изучал это(МИЭС). Я так-же изучал как устроена например микросхемы контроллера DMA и контроллера прерываний. Очень просто они строятся. Но поскольку мне это не надо, и я это благополучно забыл.

С уважением, Gleb.

Здравствуйте, Maxim S. Shatskih, Вы писали:

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

Если в этой библиотеке есть соотв. решение?

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

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

Здравствуйте, GlebZ, Вы писали:

AVK>>Еще бы. Потому что в этих лампах никакой газ не присутствует .
GZ>А там что, вакуум закачивают?

Ага, специальный, класса ХЧ.

Здравствуйте, beroal, Вы писали:

B>Здравствуйте, vdimas, Вы писали:
V>>могут принимать другие макро как параметры (это вообще рулез).
B>Т.е. имя макро как параметр? А потом текст макро с этим именем можно вставить? А если он имеет параметры, как тогда?

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

разумеется, если подал "не такой" макро, то на этапе ассемблирования выдаст ошибку

Здравствуйте, FDSC, Вы писали:

FDS>Никогда на Лиспе не программировал, но по моему это не предел. Предел высокоуровневости не достижим. Интересно, как ты на "ЛИСП" робот запрограммируешь?

Ну вроде как ничего особо сложного... особенно если учесть что существуют лисп-машины
(к сожалению не получившие распространения, хотя думаю на сегодняшиних технологиях
стоили бы они копейки). А если вопрос именно в том как их программировать то вот гугл
все знает
http://lists.tunes.org/archives/lispos/1997-May/001639.html
http://mumble.net/~jar/pubs/scheme-mobile-robots.ps
http://www.cs.northwestern.edu/~ian/grl-paper.pdf

Здравствуйте, vdimas, Вы писали:

V>Здравствуйте, fplab, Вы писали:

F>>А я согласен с автором топика. Серость прет как моча по канализации. Выпускники физико-математических вузов (не все, конечно, но, увы — много-о-о-о-о ...) очень часто откровенные слабаки. На Дельфях формочку слепить, навесить пару кнопок — это они могут. А чуть в сторону — амбец

V>Вообще-то, сильный выпускник физмата — это находка для определенных областей. Обработка сигналов, сжатие информации, моделирование динамических систем, распознавание образов и т.д. и т.п.

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

V>Проблема еще в том, что у нас умерли более-менее наукоемкие направления в программировании. Мы пишем склады с бухгалтериями, сайты-магазины и это грустно (не все, к счастью, но это явный mainstream у нас). Ради прикола дал свое резюме на одном из сайтов в штатах, указал "обработка сигналов", "реализация сетевых протоколов". И постоянно приходят приглашения на работу. Т.е., в мире-то спрос на них есть.

V>(То же самое относится к грамотным сетевикам — спецам по сетевым технологиям. У нас они почти не востребованы, однако, спрос на них достаточный в мире.)

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

Здравствуйте, GlebZ, Вы писали:

GZ>Здравствуйте, AndrewVK, Вы писали:

AVK>>Еще бы. Потому что в этих лампах никакой газ не присутствует .
GZ>А там что, вакуум закачивают?

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

AVK>>Вобще то по идее преподают во многих профильных вузах по сю пору.
GZ>В профильных? Может быть. Я тоже изучал это(МИЭС). Я так-же изучал как устроена например микросхемы контроллера DMA и контроллера прерываний. Очень просто они строятся. Но поскольку мне это не надо, и я это благополучно забыл.

В общем-то правильно. Более высокоуровневое средство разработки, адаптированное к конкретной отрасли, напичканное соотв. знаниями — это хорошо.

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

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

2. Изменение стиля и удобства написания программ: машинные коды, ассемблеры и функциональные языки (позволяют работать программисту с именованными объектами, а не числами), OO языки и декларативные языки (позволяют программисту работать с объектами, ориентированными не на выч. среду, а на модели внешнего мира и относительно просто задавать связи между ними)

3. Изменение интерфейса написания программ: программирование с помощью выключателей и перфокарт (человек выполняет вспомогательную работу по преобразованию данных в машинный формат), программирование с удобными устройствами I/O, п. с использованием стандартных или подключаемых библиотек (позволяет использовать наработанный другими код, не занимаясь программированием стандартных операций), и п. с исп. средств разработки, имющих интерфейс с пользователем на основе объектов соответствующей отрасли знаний (например, визуальный конструктор форм (Delphi, Builder, VS .NET), визуальные конструкторы и мастера, создающие HTML-файлы и Web-узлы, Borland Enterprise Core Object или Borland Bold — позволяющий работать с реляционной базой данных на уровне связей между объектными сущностями, а не на уровне таблиц). Даже иногда говорят: "программирование мышкой" — имея ввиду его отсутствие.


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

Что хорошо:

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

Что плохо:

• системы и библиотеки готовых решений не всегда генерируют оптимальные решения. Оптимальность решения зависит от зрелости соотв. системы или библиотеки. В принципе, качество может быть и выше, чем при "ручной" разработке
  
• системы позволяют работать людям, поверхностно понимающим детали работы выч. систем, не готовым к ошибкам в действиях САПР (компилятора, мастера и т.д. и т.п.)
  
• системы могут препятствовать нестандартному мышлению разработчика, вынуждая его идти на стандартные и иногда не эффективные решения. Это особенно чувствительно при первичной проработке решения.

Здравствуйте, Maxim S. Shatskih, Вы писали:

sch>>даже сделать следующий опыт. Зайти на форум по C++ и спросить: как парсить
sch>>CSV-файлы. Вам тут же начнут предлагать варианты типа Boost.Tokenizer, еще
sch>>какие-то библиотеки, предложут воспользоваться генераторами парсеров и

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

MSS>Т.е. это признак девелопера низшего уровня профессионализма. Соответственно решается вопрос о том, на какую позицию он пригоден.

MSS>Видел таких. Они потом банально путаются в несложных проблемах, и решают их неделю, причем с неправильных подходов. Реальной работы по решению проблемы — полдня.

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

Заказчику нужна надежная система за минимальные деньги. Даже 10% измеменеия производительности он не увидит, а на БД и 50% в некоторых случаях не видно. Исполнителю (владельцу конторы) важно получить максимальную прибыль, т.е. деньги_заказчика-ЗП_програмистов. А за 2 дня возни (и даже за 0,5 дня) платить то людям надо. Вот и выходит, что из кирпечей система дешевле чем из камешков, а панельный дом еще проще строить — следовательно дешевле и быстрее.

Здравствуйте, aka50, Вы писали:

За ссылки — спасибо.

FDS>>Никогда на Лиспе не программировал, но по моему это не предел. Предел высокоуровневости не достижим. Интересно, как ты на "ЛИСП" робот запрограммируешь?

A>Ну вроде как ничего особо сложного...

Это не так: можно по разному их программировать. Для РТК нужно учитывать погрешности установки манипулятора, деформацию моста, на котором он подвешен (если он конечно подвешен) и т.п.

Это сложные манипуляции, расчёт которых осуществляется дорогими САПР с соотв. надстройками (например, Сatia). Я уж не говорю про инверсную кинематику, избыточные степени подвижности, работа с препятствиями, контроль точности обработки фасонных поверхностей, работа нескольких роботов в одном рабочем пространстве и т.п.

К тому же роботы имеют нехорошее свойство — иногда ломаются.

Здравствуйте, FDSC, Вы писали:

A>>Ну вроде как ничего особо сложного...

FDS>Это не так: можно по разному их программировать. Для РТК нужно учитывать погрешности установки манипулятора, деформацию моста, на котором он подвешен (если он конечно подвешен) и т.п.
Дык это понятно... но что мешает данные абстракции (если они конечно могут ими быть) вынести на уровень языка? Или даже
более того создать свой язык (благо лисп это позволяет легко делать)?
Не очень понятно тогда к чему был вопрос "Интересно, как ты на "ЛИСП" робот запрограммируешь?"

FDS>Это сложные манипуляции, расчёт которых осуществляется дорогими САПР с соотв. надстройками (например, Сatia). Я уж не говорю про инверсную кинематику, избыточные степени подвижности, работа с препятствиями, контроль точности обработки фасонных поверхностей, работа нескольких роботов в одном рабочем пространстве и т.п.

И? Тот же AutoCAD вполне неплохо себя с лиспом чувствует (там правда не совсем лисп, но это уже ньюансы). В чем проблема в такого монстра как коти засунуть лисп?
(сейчас конечно уже не засунешь, но в момент начала ее разработки например). Вообще не очень понятно к чему эти сложности тут приведены. Они решаются на любом языке
в той или иной степени и имеется определенные плюсы/минусы в реализации.
Если по поводу скорости, то это как Java vs C++ . Например тут: http://openmap.bbn.com/~kanderso/performance/