на C это и будет main(), если не использовать threads, реализаций которых много, но стандартной является LinuxThreads <http://pauillac.inria.fr/~xleroy/linuxthreads/>; Если надо писать под X на C/C++ то надо читать про: 1) X O'reilly'вские книжки и optional 2) про GTK <www.gtk.org> 3) про QT <www.troll.no> это наиболее продвинутые toolkit'ы

Рекомендую книгу Теренса Чана "Программиррование С++ под Юних" - вроде так называется.

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

А ты побыстрее разлюби писать на этом ламерском язычке по имени "C", и все проблемы сами собой отпадут.

Согласен. Люди, переходите на Аду95 :-)

FLTK!

FLTK!

I recomend you to use FLTK:
it uses C++, your programm starts with main() (even under windows),
it WILL run undex Unix/X, Win32, MacOS
it is VERY simple & powerfull
it has perfect & easy to read docs.

I have learned FLTK in 2 (two) hours !!!!! FLTK: http://www.fltk.org
cyrillic-FLTK and threaded FLTK: http://yaroslav-v.chat.ru (my page)

Это даже не смешно.

Это даже глупо. Напоминает рекламу МММ и Тампаксов

Вован со святой земли

Ну, начинается... Сейчас я вот встану и начну орать, что Qt рулез, а все остальное сакс. Ну и что. Кому это будет интересно? Человек спрашивал про программирование под иксы и консоль, я так понимаю. Надо, ему, наверное, для начала пояснить, что под консоль писать относительно просто, а под иксы - есть куча библиотек, начиная с совсем "базовых" Xlibs, Xaw и т.п. вплоть до "продвинутых" Qt и Gtk. Если писать современный (читай - юзерский) софт, то скорее всего надо ориентироваться на "продвинутые" либы. Изучаются они все очень легко, особенно если имеешь какой-либо опыт программирования гуев. Все имеют кучу туториалов и документации. Я, например, на Qt первую програмку написал за один вечер изучения, причем програмка уже была полезной и делала то, что нужно (до сих пор ей пользуюсь). Gtk и Qt в общем-то очень схожи, не буду призывать к Qt, хотя лично мне она и симпатизирует больше всего (почему - это уже вопрос не здесь) - надо попробовать обе либы и решить самому, что лучше.

to vsl : не изучать на начальном этапе си, это всё равно, что начинать программировать в DELFI - а таких криворуких программеров море.

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

Если начинать - то имхо примерно в таком порядке... bash script... потом что-нибудь типа Питона или Схемы. А потом уже Перл, Лисп, Це, Це++, Паскали и Джавы всякие. После десятого "изученного" языка - "изучить" новый язык будет задачей одного вечера. Тем более, что есть несколько групп языков и внутри групп они отличаются весьма мало (C, Pascal, Java - имхо вот одна группа, всякие лиспы - другая, скриптовые Perl, PHP, Basic - третья)... (Ой, щаз так чувствую на меня повалится много грязи, за то что бейсик рядом с перлом поставил...)

Хехе, ну и будешь знать Лисп, пролог, перл , питон и etc. А, что такое машинный стек, сегмент памяти, аппаратные прерывания или там порт знать не будешь. Сначала нужно изучить машину и естественно ASM&C. А потом уже и более углубленно теорию алгоритмов, ООП, высокоуровневые языки различных направлений и тд по вкусу. Изучать машину после изучения кучи высокоуровневых языков будет нелепо, хотя такое часто встречается (пример про DELFI).

А ты объясни, на хрена прикладному, или даже системному программисту знать всю эту херню (особенно про прерывание - фишка из самой дебильной платформы, нормальным людям на хрен не нужная). И уж точно не стоит изучать в начале ассемблер. Надо иметь глубокую теоретическую подготовку, прежде чем за конкретные задачи браться, иначе очередной виндовз или слюникс получится. P.S. Особенно ты меня умилил этим "сегментом памяти". Вот уж дурь, которую на хрен знать не надо, если ты только не пишущий под досятину ламух.

> А ты объясни, на хрена прикладному

смотря насколько прикладному (опять пример с Дельфи просится)

> или даже системному программисту знать всю эту херню
(особенно про прерывание - фишка из самой дебильной платформы, нормальным людям
 на хрен не
нужная)

ууу нагородил, системному программисту надо знать всю эту херню!
Хехе без прерываний не одна платформа (аппаратная) не обходится, как так без них. 
Не имелось ввиду программирование прерываний (нигде это в основном и ненадо), 
но знание основ нужно. 

> И уж точно не стоит изучать в начале ассемблер

активно на нём писать может быть и не стоит, 
но узнать про регистры, флаги, стек, и опять же СЕГМЕНТЫ памяти нужно.

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

я подразумевал вообщето начальный этап, когда за написание ОС
действительно браться не стоит

> P.S. Особенно ты меня умилил этим "сегментом памяти". Вот уж дурь, которую на хрен
знать не надо, если ты только не пишущий под досятину ламух.

"вы меня умиляете, Дуся" (с) кто-то

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

Ладно давай не будем спорить, а то я вижу тебя никто переспорить не может.

Согласен с crazyalex почти полностью с чего начинать, это тяжелый вопрос и зависит от мышления человека. <i> Я начинал с Басика(Мне не было и четырнадцати (более 11 лет назад)) а затем перешел уже в институте на первом курса на С и ASM и не жалею. А вобще полезно знать и изучать паралельно С/С++ + ASM - поможет изучить платформу и научит более менее стилю программирования без клях (Научит порядку) Паскаль или Басик (Может и Фортран) Поможет изучить основные алгоритма и матеметические модели. На C алгоритмы по началу тяжело даются (Я говорю что нельзя) <u><b> Но если программист не знает первого, то он только <h1> на половину программист</h1> </u></b> Что касается апаратных платформ то поправде говоря они не очень сильно и отличабтся (Зная хотя бы одну платформу можно представлять о работе других) Хоть и приблизительно, но полезно. ASM & C нужен программеру как воздух а все остальное приложется Что касается С++ И С то вот тут я вобще не вижу принципиальных споров. Потомучто что на писано на С++ можно перенести на С хоть и с большой кровью. А всетаки ООП классная штука(просто кайф) <b> Что касается Linux и Windows то тут также глупо спорить что лучше как сравнивать что лучше мужчина или женщина Если умрет одна часть то и вторая часть выродится Вот мое мнение </b> Андрей <i>aydy@mail.ru</i> Программирую на С++ и ASM под Винду и Линух

Согласен с crazyalex почти полностью с чего начинать, это тяжелый вопрос и зависит от мышления человека. <i> Я начинал с Басика(Мне не было и четырнадцати (более 11 лет назад)) а затем перешел уже в институте на первом курса на С и ASM и не жалею. А вобще полезно знать и изучать паралельно С/С++ + ASM - поможет изучить платформу и научит более менее стилю программирования без клях (Научит порядку) Паскаль или Басик (Может и Фортран) Поможет изучить основные алгоритма и матеметические модели. На C алгоритмы по началу тяжело даются (Я говорю что нельзя) <u><b> Но если программист не знает первого, то он только <h1> на половину программист</h1> </u></b> Что касается апаратных платформ то поправде говоря они не очень сильно и отличабтся (Зная хотя бы одну платформу можно представлять о работе других) Хоть и приблизительно, но полезно. ASM & C нужен программеру как воздух а все остальное приложется Что касается С++ И С то вот тут я вобще не вижу принципиальных споров. Потомучто что на писано на С++ можно перенести на С хоть и с большой кровью. А всетаки ООП классная штука(просто кайф) <b> Что касается Linux и Windows то тут также глупо спорить что лучше как сравнивать что лучше мужчина или женщина Если умрет одна часть то и вторая часть выродится Вот мое мнение </b> Андрей <i>aydy@mail.ru</i> Программирую на С++ и ASM под Винду и Линух

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

Представляю, какая у тебя в голове каша, после ассемблера и сей... Помню, с каким трудом я из себя вышибал идиотские привычки, привитые Фортраном и Macro-11 (был такой ассемблер)... И ООП - ни в коей мере не классная штука, и вовсе не панацея, а полезная метода, которую ИНОГДА (весьма редко) стоит применять. И, кстати, если ты программируешь на асме, то ты не программируешь под линух, чисто по определению. Ибо работать твои поделия будут только на x86, а кому это в мире юниксов на хрен надо?

c> Хехе, ну и будешь знать Лисп, пролог, перл , питон и etc. А, что c> такое машинный стек, сегмент памяти, аппаратные прерывания или
c> там порт знать не будешь. Сначала нужно изучить машину и
c> естественно ASM&C. А потом уже и более углубленно теорию
c> алгоритмов, ООП, высокоуровневые языки различных направлений и тд c> по вкусу.

Вот по этому лучше изучить язык Ada. Тогда познакомишься с железом,
real-time, OOP и выработаешь правильный стиль. C/C++ уже достаточно народу испортил...

Доброжелатель.

to vsl : 

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

Вот только оскарблять не стоит ! За что я тебе должен извинятся,
что-то не понял.

Тебе, как я погляжу немало лет уже, я только на 2 курсе учусь в местном политехе.
Просто могу сказать, что зная ассемблер под 8-разрядную платформу я писал на 1 курсе 
программы на паскале без труда и лучше чем другие.
Ну как же так, ребятам не объяснили что такое бит и байт, а кинули в паскаль. 
Так что насчёт того пригодилось мне это или нет, сказать могу мало - пригодится ещё.
Да, использовал вовсю ассемблер в курсовой (паскаль), в программе реализован оконный
интерфейс подобный Turbo Vision (кстати тоже сделано с ООП).
Там понадобился асм для реализации работы с видеопамятью , мышью и всяческими перехватами 
прерываний (да да это кривой дос).
Ну это туфта всё, и в какойто мере неправильно со стороны переносимости, хотя всё вынесено в библиотеку,
которую можно переписать для другой ОС, а программу не обязательно.
Не очень наглядный пример, но всё же.

> почему ты так уверен, что прежде чем узнаешь, что такое алгоритм
>(в интерпретации Тьюринга и Черча), что такое функция, и все такое прочее, 
>надо разбирваться с
>деталями какой-либо конкретной на хрен не нужной фон-Неймановской архитектуры?
  
наверное, чтобы сразу понять зачем же тебе строить алгоритмы, 
и как их реализовать максимально эффективно реализовать. 

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

И про ООП я сказал, что это по вкусу. Хочешь вообще напрягись и реализуй свой язык,
компилятор опять же будет написан на связке C&ASM.

А программирую я мало в данный момент. А с linux&unix вообще недавно - полгода назад всего лишь.
Естественно пишется всё на родном unices язаке С. И синтаксиса асм для линукс я не знаю.

Незнаю, что тебе ещё сказать - всё вызовет у тебя бурю эмоций. Если есть время, зайди как-нибудь на канал #russian_linux 
на сервере irc.dal.net.

Да, понимаешь, у меня это болезненный вопрос. Многих приходилось переучивать, у кого мозги были испорчены C/C++, ассемблером, Паскалем. Да я и сам таким был. Вот и кричу везде, стараюсь людей остеречь. Этот форум же дети читают, и плохо, что их смущают предложениями начинать с C. Про бит и байт - читай Кнута, он старательно НА АССЕМБЛЕРЕ показывал, как надо писать, не заботясь о разрядности. Про асм для реализации низкоуровневой работы с железками - да, когда-то это было полезно. Но не теперь. И тем более неприлично советовать это новичкам. Теперь про понимание, на фига алгоритмы вообще нужны. Тут как раз не знание железа может пригодиться, а знание предметной области, задачи из которой предполагается решать. И знание теории программирования, которая позволит сформулировать правильную постановку задачи. Ну и про компиляторы других языков: они, как правило, бустрапятся сами собой, и на сях пишут максимум интерпретатор байткодов и подобную мелочевку. Посмотри на досуге, как пишутся компиляторы. Хороший курс лекций для самых начинающих можно почитать тут: http://www.schemers.org/ и далее по ссылкам, и еще тут: http://www.cl.cam.ac.uk/Teaching/Lectures/funprog-jrh-1996/index.html И нет никакого "программирования под линукс", или "программирования под DOS". Есть просто программирование, и когда большинство разработчиков это поймут, заживем все счастливо и безбедно, без всяких там поганых виндовзов. Ты не обижайся, что я наехал - это необходимо. Дурь или одним ударом выбивается, или остается навсегда, и растут ряды кульхацкеров ассемблерных, позорящих великое Искусство.

To vsl: не мог бы ты ответить на искренний вопрос: чем, по-твоему, ФП лучше ООП? Мне, например, как-то против шерсти ограничивать себя одними только функциями, без side-effect'ов. А объекты, по-моему, вовсе даже не плохая вещь.
P.S. Я не эксперт ни в ФП, ни в ООП.

VSL тяжелый случай.

Скажы что тебе лень и ты не программист
и все дело сконцом.Не будь упрямым ослом и не уговаривай себя что это не нужно. Ты не прав. C & Asm нужен минимум для твоего внутреннего
развития и пригодится тебе в будущем еще много и много лет.
Ты должен развиватся, а не стоять как баран, который уперся рогами в дерево.

с crazyalex я согласен хоть он и пишется что крэзи.
Идет верной дорогой.
А боятся чото узнвать новое это путь
не правильный для программиста.
О себе 25 лет
11 лет программирую сначала на басике
потом почти одновременно
на ассемблере(Z80) и паскале
потом на С+ASM (DOS & DOS4GW)
C++ Windows & Linux
C++ Linux & С++ Solaris

В будущем еще ЖАБА и COM

Андрей
aydy@mail.ru

А еще на вопрос ФП и ООП

Пиши как удобнее.
Функциональное рограммирование
только маленькая часть ООП
и говорить чо прога на С
быстрее чем на С++
не правильно.
Это зависит от тебя.
Но дальнейшее развитие программы на С++
куда более реально (Имеется ввиду повтороное использование)
А С++ проще для понимания (Реальная концепция мира)
и удобнее для реализации

даже на С можно писать на ООП
но проще на С++

Я много видел кода когда на С
пытались реализовывать С++ концепции.
даже в ядре линукса часто можно встретить
стректуры с указателями на функции

Я еще не видел ни одного программиста,
которого испортил бы С++
маслом кашу не испортишь

Не судите и не судимы будете

Адрей

aydy@mail.ru

Ой, чего щаз будет... Тут уже чуть-ли мордобой завязывается... Вставлю и я пару слов. Просто скажу что для меня есть программирование. Программирование - в первую очередь - это создание эффективных программ. Тех, которые работают быстро на относительно слабых на данном этапе времени машинах. И я ни в коем случае не буду ограничивать себя никакими библиотеками, идеологиями и т.п. чушью, если мне надо, чтобы моя программа работала быстро. Полезу и в асм, и откажусь от C++, возможно, откажусь от линукса вообще - например, рилтаймовые обработки скорее всего я буду писать под чистым досом (функции доса, естественно, не используя). То, о чем говорил vsl - это вообще-то в основном называется информатика, теоретическое программирование, алгоритмизация и т.п. умными словами. Да, теоретически это красиво, ООП, например, великая вещь с точки зрения теории, на практике оказывается часто вредной, а не полезной. Я пока знаю фактически только одно нормальное применение ООП (там, где оно действительно нужно) - это ГУИ (такие мысли у меня появились после того, как я написал один проект на gtk). Больше пока ни одного достойного применения не видел. Есть, у меня, конечно, нехорошие привычки, которые, конечно, не стоит повторять, типа написания программы на C/Pas с глупыми ассемблерными вставками. Ну не понимал я тогда, что кривой вызов моей навороченной ассемблерной функции, который сгенерит компилятор будет раз в 100 медленнее выполняться, чем сама функция и все дело портит именно он. Что ж делать... Но все-таки идеологии идеологиями, но программы должны в первую очередь работать и работать быстро - на пределе возможностей компьютера.

to GreyCat: > Но все-таки идеологии идеологиями, но программы должны в первую очередь работать и > работать быстро - на пределе возможностей компьютера. Простите, ваши 5 центов не катят :) Никому они не должны, если только это не ломалка ключей или теория информатики об оптимизации. Да, обидно, что, например, glibc от libc5 отличается тормознутостью и объемом, зато насколько оно стало портабельней, логичней и удобней. А писать надо самодокументирующе, с оглядкой на всевозможные ошибочные ситуации и максимально без архитектурных зависимостей. Это поможет как для стиля собора так и базара, портировать, использовать повторно, исправлять и т д.

Я не противопоставляю ФП и ООП. Они прекрасно умеют жить вместе (e.g CLOS, Objective Caml). Только вот из ООП постоянно все пытаются изобразить панацею, что крайне неверно - использовать объектную декомпозицию на низком уровне детализации просто глупо, ибо там уже как правило не бывает сущностей, легко отображающихся на объекты, а на высоком уровне детализации как правило более уместны другие средства OOD, кроме объектов - модули. То есть, область применимости объектного программирования весьма и весьма узка.

Anonymous> На C алгоритмы по началу тяжело даются (Я говорю что нельзя) Но если программист не знает первого, то он только на половину программист
Ну конечно. То есть до 1974 года настоящих программистов не существовало?
GreyCat> Я пока знаю фактически только одно нормальное применение ООП (там, где оно действительно нужно) - это ГУИ
В крупных проектах ООП сильно облегчает жизнь. GUI, как правило, тоже крупные проекты.
GreyCat> Но все-таки идеологии идеологиями, но программы должны в первую очередь работать и работать быстро - на пределе возможностей компьютера.
Эффективностью пренебрегать не стоит, но ее важность сильно зависит от предметной области. Когда я веду проект, для меня важнее закончить его вовремя и чтобы заказчик остался доволен. Обычно проще заказчика убедить поставить лишние 2^28 байт в сервер, чем продлить срок договора на пару месяцев ради тотальной оптимизации. Поэтому я обычно ограничиваюсь алгоитмической оптимизацией, подчисткой внутренних циклов и обеспечением локальности данных (для минимизации промахов кэша), а заточку кода под машину оставляю компилятору. Это только мой случай, YMMV.
И опять-таки, для различного рода оптимизаций подходят разные языки. Взять к примеру написание regexp-парсера: на Си ты наверняка сделаешь весьма быстрый интерпретатор regexp. На Лиспе (не плюйтесь, это только пример) *такой же* алгоритм как правило будет работать медленнее, но я могу достаточно безболезненно написать обработчик regexp, который будет на лету компилировать каждое выражение в native code и выполнять поиск на порядок-другой быстрее, без учета времени компиляции. И если при поиске большого количества выражений в небольшом объеме данных будет выигрывать твоя реализация, но при поиске одним выражением по большому объему лучше будет моя.

Ты сильно неправ. Да, естественно, изучая что-то новое ты развиваешься. Но вот только вопрос - в какую сторону? C&Asm - это путь в кульхацкерство, и свернуть с этого пути очень тяжело. Тому, кто так начинал, возможно уже не стать грамотным программистом. И, естественно, каждый программист должен постоянно стремиться узнать новое, но только имея для этого сильный теоретический фундамент. Как ты думаешь, много смысла в изучении релятивистской квантовой теории тем, кто в школе арифметику не доучил? Ну вот - браться за ассемблер, не зная глубоко теории, примерно то же самое. Я, когда начал писать на фортране и Macro, уже немного знал математику, и то, потом сложно было выбить из себя все те заблуждения, которых я успел нахвататься, кинувшись без подготовки решать прикладные задачи.

Прежде, чем желать, чтобы программа работала эффективно, надо добиться хотя бы того, чтобы она работала вообще. Кстати, ООП в ГУИ - просто вредительство, гуйня на объекты хреново ложится. Достойное применение ООП - это всякие крутые framework-и, на которых предполагается быстро решать простые однотипные юзерские задачи. Пример - ROOT (http://root.cern.ch/). Ну и вообще я никак не могу согласиться с тезисом о предельной утилизации ресурсов. В 99.99999% случаев в разы дешевле купить дополнительную память или подкачать мегагерцы, чем тратить лишние человекогоды на оптимизацию и вылизывание кода. Честно говоря, я вообще могу только одну задачу представить, где подобный подход оправдан: всякие embedded real-time железки, производительность которых ограничивается требуемыми физическими характеристиками (размеры, потребляемая мощность). И то, даже в мобильных телефонах потроха не на ассемблере пишутся, а на Жабе.

Не, ну надо же, такой большой, а все еще такой безграмотный! Назвать ФП частью ООП - мало кто додумался бы. Они как бы совершенно ортогональны. Функциональное программирование - это результат альтернативного подхода к определению понятия "алгоритм", это просто отображение на реальные языки программирования формализма лямбда-исчисления, введенного Черчем. Плюсы такого подхода несомненны: мы можем работать с программой, как с обычным математическим выражением, использовать все наработки в области символьной математики для автоматического доказательства кода, для суперкомпиляции, и т.д.
Ну а то, что ты не видел программистов, испорченных C++, говорит лишь о том, что ты и сам испорчен. Старайся исправляться. URL-ы я дал.

> ????? ?????? ??????? ??????????:
?????? ???? ????????: ??-??????, ????? ???????????????? ???????? ????? ????????? ? ?????????????? ??????????. ????????, ??? ? ???? ????? ????? ???????? ???????????? ????? ??????? ?????????????? ??????????? (? ?? ??? ??? ?????, ?? ??? ??????? ? ??????-???????????), ?? ????? ???????????? ?? ??????? ??????????????? ????.
??-??????, ?????????????? ? ??????? ????? ???? ???????? ??????, ? ??? ?????/?????? ????????? ??????????. ??????? ?? ???????? ???????????? ?????????????? ?????? ???? ??????? ?? ????? ??????????????? ??????? (Scheme), ???? ?????? ????????? ???????????, ?????????? ???????? (???? ????????? ??????? ?? ?????????).

Сорри, это была попытка запостить из StarOffice :)
> Плюсы такого подхода несомненны:
Минусы тоже известны: во-первых, мозги нетренированного человека плохо оперируют с функциональной парадигмой. Учитывая, что в наше время очень немногие программисты имеют хорошее математическое образование (а из тех кто имеет, не все знакомы с лямбда-исчислением), не стоит рассчитывать на большую пользвательскую базу.
Во-вторых, взаимодействие с внешним миром есть побочный эффект, а без ввода/вывода программы бесполезны. Поэтому на практике разработчики функциональных языков либо отходят от чисто функционального подхода (Scheme), либо вводят уродливые конструкции, называемые монадами (хотя некоторые считают их красивыми).

Естественно, на чистом функциональном языке программировать сложно. Как раз для ввода/вывода можно юзать такие императивные фичи, как циклы. Они все равно легко поддаются автоматической обработке, так как все операции с "состоянием" (а там только индекс цикла и будет) легко отследить. Да и можно криво, но однозначно отобразить на лямбду. Ну а про доступность: я на своем опыте убедился, что для всех, даже закоренелых нематематиков, проще объяснить, что такое high order function, чем такое новое и незнакомое понятие, как "переменная". По этой причине как раз многие буржуйские университеты начинают преподавание computer science с функциональных языков. То, что у нас это не так, ничего не меняет. Кстати, в том же МГУ можно отловить немало студентов, для которых первым языком программирования был РЕФАЛ...

В ваши любимые споры ФП vs ООП влезать не буду - это отнюдь не моя специализация, рисковать не стоит. А вот про оптимизацию скажу. Тут, как мне кажется, все глубоко заблужаются, и заблуждение это, конечно, отнюдь не из-за отсутствия интеллекта, а из-за коммерциализации софта. Практически любая оптимизация оправдана, особенно в крупно используемом софте. Писать вещи типа десктопов на тяп-ляп, лишь бы побыстрее зарелизить и отдать юзерам имхо непростительно. Пусть даже разработчики затратят 2-3 лишних человекодня на оптимизацию загрузки на 1 секунду. В крупном софте это даст гигантский прирост производительности по всему земному шару в производительности юзеров, юзающих этот софт. Если софт грузится по 2-3 раза в день и используется десятками и сотнями тысяч людей - то это человекосекунда выльется в огромные сбережения человековремени для всего человечества (извиняюсь за огромную повторяемость слова "человек"). Одно дело - коммерческий софт, его задача - побыстрее написать и сбагрить клиенту. Слава богу, с появлением Линуксов и т.п. широко распространенных юниксов, хотя бы концепция "перед релизом надо много тестить, так как у нас не коммерческий софт" вошла в общепринятую практику. Теперь бы здорово было бы, если бы люди поняли, что "перед релизом надо много оптимизить". Сделав идеальный (ну, близкий к идеальному) софт один раз никогда больше не придется его менять - только расширять и апгрейдить.

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

Ню-ню ... :)))
А что тогда будут производители/продавцы железа делать? Лапу
сосать ? :-) Им же тоже деньжат хочется. Если фирмы
производители софта начнут вылизывать код, многие производители/продавцы железа просто по миру пройдут :)

Короче, в производстве толстого софта лежит так же чисто коммерческий
интерес. Толще софт, купят новое, более мощное железо. Твой же взгляд
отражает совковую действительность, где на новое железо у большинства
просто нет финансов, вот и выкручиваются через C&ASM&BP.

Всего хорошего !

Mr.Bool

Ну что, все уже передрались? А зачем спрашивается. Вы же все знаете русскую пословицу про ЖАБУ!!! Мужик программируй на том, что нужно для решения поставленной задачи, ибо нет языка, котрорый бы мог решать любые задачи элегантно и с минимумом кода, и максимальной скоростью. Каждый язык писался для решения определенных задач. Так что изучай то, что тебе необходимо сейчас!!!

> Сделав идеальный (ну, близкий к идеальному) софт один раз никогда больше не придется его менять - только расширять и апгрейдить.
Идеал недостижим - оптимизация и сопровождаемость кода после определенного момента становятся вещами взаимоисключающими. Рано или поздно приходится жертвовать логической стройностью архитектуры системы в пользу машинных циклов. Кроме того, hand-optimized код как правило плохо читаемый.

Ошибаешься. Если оптимальное написание софтинки по времени займет пару лет, а неоптимальное - месяц, то лучше уж написать быстро и неоптимально, а не трахаться два года, до тех пор, пока софтинка еще в зародыше не устареет. Кроме того, ты очень сильно заблуждаешься на предмет разницы в потребляемых ресурсах для жестких компиляторов и интерпретаторов, байткодовых VM, и т.п. За исключением численных задач, практически все приложения имеют весьма узко ограниченные участки кода, на которые приходится более-менее конкретная нагрузка (не поленись, побегай с профайлером по любимой софтинке, которую подозреваешь в монстровости). Их можно затачивать, оптимизировать - на это много времени не потеряется. Но оптимизировать все - просто верх дебилизма, и позорное кульхацкерство. Кроме того, еще одно важное замечание: 99.9% времени большая часть софтин висит в сисколлах. Так на кой хер оптимизировать оставшиеся 0.01?!?

To vsl:

Однако, Вы -- теоретик!
Но откуда такая агрессивность и стремление "учить жизни"?

Наверняка, преподаватель. И, как большинство преподавателей,
ничего реально работающего не написали.

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

"Взаться за перо" меня заставил Ваш "Пример - ROOT".
IMHO, самая неудачная иллюстрация полезности ООП. Понимаете, он
НЕ РАБОТАЕТ. Я немного знаком с автором и единственным разработчиком
этого монстра Рене Брюном (Rene Brun). И вот, теперь до меня
дошло, что Вы можете из себя представлять! Наверное, то же самое:
бешеная энергия, довольно глубокие, но отрывочные познания в самых
невероятных областях математики, физики и практической информатики,
великолепные способности к кодированию и полное неумение
программировать (это я про Brun).

И не верьте тому, что написано на его сайте -- это не так. Ему
постоянно отказывают в финансировании, но он с бешенной энергией
находит новых коллаборантов и спонсоров. Пару лет назад он присосался
к Алисе, и они до сих пор используют некоторые из его технологий --
примерно так, как нерадивая секретарша пользуется M$ Office.

Вся его жизнь в последние годы связана с поиском источников
финансирования.

А по существу -- я разделяю многие из Ваших нетривиальных
высказываний, кое с чем не соглашаюсь, НО: хоть бы раз вы вставили
IMHO! Неужели Вы не понимаете, что стиль/методы/задачи при
программировании могут сильно отличаться от того, к чему Вы
привыкли? Я согласен, что многие из современных тенденций внушают
опасение за будущее программирования в частности и прогресса вообще,
но нельзя же быть настолько уверенным в собственной непогрешимости!


To all:
Не стоит верить тому, что говорит vsl. Иногда он бывает прав,
но это ЕГО ЛИЧНАЯ точка зрения, далеко не бесспорная.
Даже тогда, когда он декларирует ее как абсолютную истину.

С уважением,
"Новый" anonymous

2vsl: Ты или ламер, или программер с нетрадиционной ориентацией,слабо разбирающийся в том что такое компьютер.

Честно говоря, я ляпнул про ROOT просто так. Ведь действительно фреймворк, действительно хорошо СПРОЕКТИРОВАННЫЙ. Про глюки реализации тут речи не идет. Я сам как пользовал CERNlib+PAW, так и буду еще много лет пользовать, без всяких там ROOT-ов. Так что, думаю, лучшим примером объектного фреймворка был бы, допустим Swarm. Теперь ясно, об чем я имел сказать? Да, кстати - ROOT таки весьма активно юзают в D0, да и в той же ALICE рут весьма уместен, как мне кажется - все равно ничего другого, потребного для такого потока online-данных на момент начала проекта не было.

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

Я не ламер, я честный чайник. То есть, в отличие от упертых кретинов, стараюсь всячески развиваться и устранять недостатки в своих познаниях. Дык вот, что такое кульхацкерство: представь себе такую картину: поставлена простенькая задача - WWW-интерфейс к базе данных, ну, допустим, с данными о складах. Программист возьмет подходящий сервер БД, напишет простенькую прослойку на Perl/Tcl/еще-чем-скриптовом, формочки вывода в XML оформит, дабы любой дурак мог переделать дизайн по своему вкусу. Что сделает кульхацкер? Он напишет на ассемблере (для скорости!) нечто вроде собственной БД, заточенной исключительно под тот тип записей, которые есть в данной задаче, тем самым минимизирует оверхед на сторадж. Потом, устав от ассемблера и от пинков начальства (в то время, как нормальный программист все давно закончит, сдаст проект и поедет рыбу ловить, он будет отлавливать клопов с своей ассемблерной БД), он напишет на C кучу CGI-шек, в которые жестко впаяет интерфейс. Откомпилирует, и потом все же не ужержится и руками отточит полученный ассемблерный код. После того, как этого подонка уволят, сопровождать его софтину не возьмется никто. Вот, что такое кульхацкерство, вот почему оно позорно. Про время, проведенное в сисколлах: что ты называешь нормальной программой, чмо ушастое? Опиши круг задач. Возьми, к примеру, тот же сервер БД, и подумай, где у него узкое место - железный ввод/вывод, или его собственный код? Ты, ламерочек недоученный, умудрился еще спутать "структурное" программирование с императивным. Ничего, школу закончишь, узнаешь, что ошибался. Дык вот, НА ХРЕНА ТЕБЕ ОТОБРАЖАТЬ ЛОГИКУ ПРЕДМЕТНОЙ ОБЛАСТИ НА ЛОГИКУ ЖЕЛЕЗА?!? Какой смысл идти на такие дурацкие уступки? Пусть этим занимается компилятор. За наезды извиняться не собираюсь - ненавижу воинствующих кульхацкеров.

Ну тогда можете называть меня кульхацкером :) Я действительно сам себе лично вместо того, чтобы ставить MySQL и забивать тем самым мег 50 места, написал на C+Sh+Perl типа базы данных, которой и по сей день пользуюсь довольно часто, практически никаких глюков замечено не было, написал я все это дело очень быстро, практически за пару дней. На ассемблере ничего не оптимизил, там особенно оптимизить нечего. Вот это, например, то, что я считаю практически идеально написанным кодом. Да, я думаю, что мало кто в нем кроме меня разберется. Но мне - пофигу. Главное - я разберусь. Работал бы в команде - прибавлял бы какие-то комментарии. Но команду бы тоже заставил писать хорошо, а не быстро. Ну может, это и не кульхацкерство. Тогда другой пример - любое написание более-менее хорошей игрушки - по-вашему - это кульхацкерство :) Там тебе приходится и на асм переползать, причем весьма значительно иногда, и оптимизить вручную... И интерфейсы много где жесткие (правда я стараюсь их избегать). Может быть у меня такие замашки и от того, что я много занимался именно программированием игр... А не загнивал, делая какие-нибудь базы данных... Нет, я ни на кого не наезжаю... Просто писать игрушки - это самое серьезное программирование, а все, что тут сейчас обсуждается - ерунда, ширпотреб, как раз который любой ламер, прочитавший книжку типа "це плюс плюс за 24 часа" делать умеет... У меня такое впечатление, что тут все разделились как бы на три части - 2 функционально противоположных и все, кто посередине. Оптимизация и эффективность работы vs легкость написания и сопровождения...

Ну вот, опять не так поняли. Кульхацкерством называется использование НЕАДЕКВАТНЫХ средств, вызванное лишь стремлением показать свою крутизну. Есть сама задача требует извратов, то это уже не кульхацкерство, а суровая действительность...
Правда, я не могу согласиться с тем, что писание игрушек - серьезно. Ни фига подобного, нет в игрушках ничего особо сложного. Ни тебе крутого параллелизма, ни навороченной логики, ни даже риалтайма. Сплошная мультимедиа, в коей давно уже все придумано, и ничего интересного не откроешь.

Читайте первоисточники, vsl. Императивное программирование - ваш собственный термин. На оскорбления отвечать не собираюсь - видимо у вас не совсем стабильная психика. <p>Про syscalls: представьте себе алгоритм обработки SQL запроса, сколко времени займён чтение данных с диска, и сколько на их анализ. Второй пример: архиваторы, PGP, GNUPG - основное время затрачивается на обработку данных. Про "кульхацкерство" - таких программеров, каких ты описал просто не бывает, если и появляются, то быстро исчезают в процессе естественного отбора. <p>>>НА ХРЕНА ТЕБЕ ОТОБРАЖАТЬ ЛОГИКУ ПРЕДМЕТНОЙ ОБЛАСТИ НА ЛОГИКУ ЖЕЛЕЗА?!? <p>Очень интересное возражение. Боюсь быть не понятым, но всё же постараюсь объяснить: Любую мысль можно изложить на любом естественном человеческом языке (и даже на многих языках программирования), точно также ЛЮБУЮ программу можно написать на ЛЮБОМ полноценном языке программирования, но на языках, близких архитектуре компьютера, это делать немного сложнее. Впрочем это уже дело привычки. Я бы может и перешёл на Caml, но зачем? Все задачи прекрасно ложатся на C, C++, Java. Просто нужно понять их идеологию, а без этого, высказывания типа "C, C++ - sux" - просто идиотская распальцовка.

Читайте первоисточники, vsl. Императивное программирование - ваш собственный термин. На оскорбления отвечать не собираюсь - видимо у вас не совсем стабильная психика. <p>Про syscalls: представьте себе алгоритм обработки SQL запроса, сколко времени займён чтение данных с диска, и сколько на их анализ. Второй пример: архиваторы, PGP, GNUPG - основное время затрачивается на обработку данных. Про "кульхацкерство" - таких программеров, каких ты описал просто не бывает, если и появляются, то быстро исчезают в процессе естественного отбора. <p>>>НА ХРЕНА ТЕБЕ ОТОБРАЖАТЬ ЛОГИКУ ПРЕДМЕТНОЙ ОБЛАСТИ НА ЛОГИКУ ЖЕЛЕЗА?!? <p>Очень интересное возражение. Боюсь быть не понятым, но всё же постараюсь объяснить: Любую мысль можно изложить на любом естественном человеческом языке (и даже на многих языках программирования), точно также ЛЮБУЮ программу можно написать на ЛЮБОМ полноценном языке программирования, но на языках, близких архитектуре компьютера, это делать немного сложнее. Впрочем это уже дело привычки. Я бы может и перешёл на Caml, но зачем? Все задачи прекрасно ложатся на C, C++, Java. Просто нужно понять их идеологию, а без этого, высказывания типа "C, C++ - sux" - просто глупая распальцовка.

GreyCat> ...написал на C+Sh+Perl типа базы данных, которой и по сей день пользуюсь...
И далее:
GreyCat> ...не загнивал, делая какие-нибудь базы данных...
гы-гы :)
Я в общем-то с РСУБД тоже особо делов не имел, да и кромсать код ради голой производительности тоже приходилось, но все-таки я не совсем с тобой согласен. Если имеешь годовой проект в котором участвуют человек 10-15, шансы велики что кто-нибудь за это время свалит, и другим придется копаться в его коде. Поэтому кустарщина не приветствуется.

Мда интересная беседа (флейм) получился. Теперь тема : 
Какой язык лучше. А я всего лишь высказал мысль о том, с чего следует
начинать программирование на ЭВМ.

Так вот, после того как я последний раз запостил ответ "злому" vsl,
я случайно наткнулся на предисловие к одной из книг Дейкстры (я его не читал раньше). Там промелькнула интересная мысль, касающаяся обсуждаемой здесь темы, что язык для реализации задачи нужно выбрать так, чтобы ломать голову над задачей, а не над языком. Получается незачем ломать голову над изучением Лиспа, только потому, что кто-то в эхе или форуме сказал : Всё Си уже маздай и не нужно на нём писать.
И наоборот кому-то тот-же Лисп даётся очень легко и он пишет непринуждённо + задача соответствующая, так зачем ему тогда кидаться учить С++. 

А вот начинать обучение (именно обучение) необходимо с АСМ&C. Си ведь очень лёгок для понимания.

А продолжать можно, как я уже сказал, по вкусу.