C или C++ что выбрать

Мне лично, больше нравится С99.

С Си будет жить проще. Когда станет не хватать, учи сразу схему/лисп

C

А в каком направлении хочется писать?

Haskell

Logo

> А в каком направлении хочется писать?

BioReactor real-time control management.

в направлении сетевых приложений, в частности в области Ldap.

python выбрать.

>А в каком направлении хочется писать?

Настенная живопись, то бишь расписание стен остатками живых программистов.

Сначала лучше выучить C

Да и лучше не учить, а решать какие-нибудь задачи, используя Си как инструмент. Практика в первую очередь.

Если ничего до сих пор серьзного не написал, то лучше всего начать с C. Потом к чему-нибудь более специализированному и удобному в своей области.

Существует обоснованное мнение, что если на чём то пишешь, то нужно знать как оно работает. т.е. используешь Java - разберись с устройством VM и GC. Используешь Python - напиши пару интерпретаторов. Используешь C - учи asm. ;)

Тему сперва в talks, потом в топку :)))

А вообще, конечно pure C :) или С & glib

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

А на μC++ они не смотрели?

Кстати, есть еще C#! :)

не знаю, может и смотрели, но упомянул он только о Хаскеле

>Недавно в Москву приезжал дядька из МС, говорил, что они давно уже экспериментируют с Хаскелем.

вас это удивляет? ghc разрабатывается в microsoft research'е

>Уверял, что ФП и в частности Хаскель - это очень круто, потому что можно автоматически распараллеливать код, а это сейчас очень важно в свете многоядерных процессоров.

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

>то что можно -- это все понятно(функции "чистые"), но на практике не выгодно автоматически распараллеливать

и что сие должно означать ?

>хотя паралелизовать при помощи Control.Parallel очень легко и понятно, хотя явный хак

в каком месте это хак, да ещё и явный ?

>ну еще не стоит забывать про ленивость, она сильно производительность снижает

совершенно верно. только не всегда, не сильно, не снижает. и не ленивость

если выбор из C и C++, то несомненно C. независимо от того, какой высокоуровневый язык будешь применять в дальнейшем, без знания C далеко не уйдёшь. удачи

> ну еще не стоит забывать про ленивость, она сильно производительность снижает

В теории она вовсе не обязана этого делать. И умные компиляторы об этом знают (см. Clean).

C

>>ну еще не стоит забывать про ленивость, она сильно производительность снижает

>совершенно верно. только не всегда, не сильно, не снижает. и не ленивость

+1, анонимус - феерический идиот

плюсы в юниксе побоку , особенно в системном программировании
если только не собираешься ваять гуй

я за c(системное программирование), python(всё остальное программирование), perl(логи парсить), sh/bash(стартовые скрипты итп, нужно знать в виду широкой рапсространённости).

Моё имхо C++ потерял красоту C. Слишком сложный он. Вот с C как-то гораздо проще имхо, его можно изучить прочитав Кернигана и Ритчи. А вот дока по cpp, чую, в разы больше будет.

>и что сие должно означать ?

что можно параллелить "автоматически", т.к сайд-эффектов нет.

>в каком месте это хак, да ещё и явный ?

par :: a -> b -> b seq :: a -> b -> b

>не снижает. и не ленивость

продолжаем.....

Erlang

>что можно параллелить "автоматически", т.к сайд-эффектов нет

а можно неавтоматически. и что ? и не только через Control.Parallel, кстати

>par :: a -> b -> b seq :: a -> b -> b

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

>продолжаем.....

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

>а можно неавтоматически. и что ?

ничего.

>и не только через Control.Parallel, кстати

это, имхо, самый удобный инструмент

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

м-да... как все запущенно.. хиндли-милнера явно в школе не учили. вас не смущает аргумент типа a?

>что же ты такое программишь, анонимус, что ленивостью воспользоваться эффективно не можешь ?..

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

>хиндли-милнера явно в школе не учили

не учили. с системами типов у меня вообще пока плохо. если обьяснишь буду весьма благодарен

Ну, вообще-то, HM явно не идеален. Просто пока ничего лучшего не придумали. Приходится хаками обходиться.

Начни с С. Потом уже дальше сам разберешься.

>Ну, вообще-то, HM явно не идеален. Просто пока ничего лучшего не придумали

Мартин-Лоф ?

>не учили. с системами типов у меня вообще пока плохо. если обьяснишь буду весьма благодарен

par :: a -> b -> b seq :: a -> b -> b

у нас функции возвращают значения типа b, и примимают два аргуманта с типами a и b, при этом мы никак не можем преобразовать первый аргумент (a) к типу b, а следовательно компилятор в праве соптимизировать эти определения до следующих:

par :: b -> b seq :: b -> b

но в реальности такого не происходит...

>par :: a -> b -> b seq :: a -> b -> b

>у нас функции возвращают значения типа b, и примимают два аргуманта с типами a и b

это понятно

>при этом мы никак не можем преобразовать первый аргумент (a) к типу b

а зачем ?

>а следовательно компилятор в праве соптимизировать эти определения до следующих:

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

>par :: b -> b seq :: b -> b

или par :: b -> b -> b seq :: b -> b -> b ? почему теряем аргумент ?..

>но в реальности такого не происходит...

ну и почему не происходит тоже интересно :)

> C или C++ что выбрать

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

Нас вот в универе учили по такой схеме
Pascal-[парралельно Assembler]-C++-C-Delphi-VC

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

>Мы всей группой в одну глотку кричали, что изучение C++ пеед С - это по крайней мере глупо

Где то читал "Ни в коем случае не учите Си перед С++, иначе научитась плохому из Си", в чем то правы оказались люди. Но тут все субьективно.

>вот это совершенно непонятно. почему из невозможности приведения одного типа к другому слует возможность подобной оптимизации ? и какой в ней смысл ?.. почему теряем аргумент ?..

потому что у нас первый аргумент никак не влияет на возвращаемое значение, т.е он не нужен.

>ну и почему не происходит тоже интересно :)

мне тоже :)

> Нас вот в универе учили по такой схеме

Зачем ты учился в таком гадюшнике?

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

> Где то читал "Ни в коем случае не учите Си перед С++, иначе научитась плохому из Си", в чем то правы оказались люди. Но тут все субьективно.

Кстати вот это да..

>Выбор языка в первую очередь определяется задачей

чтобы правильно выбрать язык для решения задачи, ты должен знать эти языки. или я что-то путаю? :) вопрос ведь не стоит, на каком языке мне сделать вот это... человек спросил, с чего лучше начать ;).

Извините, я там не увидел слово "обучение". Вопрос задан несколько расплывчато.

Для системного программирования в Unix и сетей - С + asm ЗЫ: сам использую C

Assembler или SQL — что выбрать? Порекомендуйте!