Язык программирования Си сложен в изучении?

не видимость результата, а результат.

Там по сцылкам горы просто результатов... С комментариями очевидцев :) На ЛОР тебя потом ветром попутным надуло :)

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

http://hashcode.ru/questions/171901/c-структуры-оптимизатор-компилятор - первая ссылка - разоблачай, я жду. Где ко-ко-ко?

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

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

UPD. http://amvnews.ru/index.php?go=Ratings&file=bycommauth&author=o2n3e А еще царевна тонкий музыкальный критег :)

Начинай искать себе другой язык, когда будешь знать все тонкости текущего, когда будешь реально видеть его границы. За два месяца изучения программирования в целом достигнуть такого потолка в паскале нельзя. А чтобы понтоваться перед пацанами, освой лучше какие-нибудь интересные структуры данных и алгоритмы работы с ними - это будут намного более разумные инвестиции времени сейчас. Ты уже знаешь, чем красно-черное дерево отличается от B-дерева? Ты уже знаешь, для каких случаев подходят различные подходы к реализации хеш-таблицы? Ты умеешь работать с графами? Ты умеешь с ходу программировать алгоритмы, основанные на конечных автоматах? Если нет, то дело не в паскале.

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

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

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

Зачем мне это? Зачем тратить время на понимание(бессмысленное) (бессмысленных)тонкостей (бессмысленного)недоязычка, если меня тошнит от одного его вида?

За два месяца изучения программирования в целом достигнуть такого потолка в паскале нельзя.

Можно, конечно не по вузовской программе и не тебе, но всё же.

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

В этом мире нет никаких структур данных и алгоритмов - это мифы и легенды со днища окиана( вузы там, низкасортная жаба-работёнка за еду), особенно в сишке.

Это инвистиции бездаря, которые какраз только и нужны для понтов перез пацанами.

Ты уже знаешь, чем красно-черное дерево отличается от B-дерева?

Зачем мне это знать?

Ты уже знаешь, для каких случаев подходят различные подходы к реализации хеш-таблицы?

Для каких? Давай проверим это? Придумывай сулчаи, посмотрим как мы выберем «оптимальные подходы».

Ты умеешь работать с графами?

Ненужно, да и что ты понимаешь под «умением работать»?

Ты умеешь с ходу программировать алгоритмы, основанные на конечных автоматах?

Ты нет, да и чего алгоритмы? 1-й курс детсада?

Если нет, то дело не в паскале.

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

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

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

это всё — да, «ниодин». А что-то конкретное из списка многие знают.

PS: один таки есть, это Дональд Кнут.

Нищеброд анскильный, тебя опять слить, или сам исчезнешь?

так ли он сложен как его знакомый малюет?

Есть только один способ научиться плавать - зайти в воду. Чего спрашивать-то? Начни изучать. Если тебе нравится программировать, знание Си в любом случае лишним не будет, даже если в жизни ты будешь писать исключительно на Java.

Я, правда, не понял, чего тебя так тошнит от Паскаля. Вполне вменяемый язык.

И поскольку я предполагаю, что изучаешь ты не виртовский паскаль 70-х годов, а что-то более современное (fpc, delphi или даже турбопаскаль) - ПРЕДОСТЕРЕЖЕНИЕ. Во всех современных паскалях есть модульность. В Си её нет. Есть только раздельная компиляция и ряд костылей типа #include для имитации модульности. При этом ответственность за малейшую ошибку несёт программист. Чтобы не ловить глупые ошибки:

• строго разделяй файлы .h и .c - в первых определение, во вторых реализация;
• включай в каждый модуль ВСЕ необходимые ему #include, не полагайся на неявное включение;
• в каждом .h обязательно делай страж компиляции и следи, чтобы имена стражей были уникальными.

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

Удачи.

А вообще изучать Си в линуксе легко и приятно благодаря наличию gcc, make и mcedit :) Вместо mcedit можно подставить vim или emacs.

следи, чтобы имена стражей были уникальными

Для gcc достаточно написать #pragma once — и никакие "стражи" не понадобятся. Но "на всякий пожарный" после этой строчки можно еще и "блоком" #ifndef H_NAME … #endif окружить содержимое h-файла.

Причина субъективна он приелся. Хочется чего-то нового!

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

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

Вот если перейти к функциональщине - это действительно ДРУГИЕ языки.

Учи лучше Objective-C. Гораздо перспективнее, компиляторы есть под вин мак и линь. Сможешь устроиться потом iOS кодером :-) Платят хорошо.

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

За два месяца изучения программирования в целом достигнуть такого потолка в паскале нельзя.

Можно, конечно не по вузовской программе и не тебе, но всё же.

Я конечно же не брал в расчет способности илитарных лоровских анонимусов.

Чем ниже уровнем, тем сложнее.

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

Для gcc достаточно написать #pragma once — и никакие «стражи» не понадобятся.

оно до сих пор AFAIK нестандартное.

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

В этом мире нет никаких структур данных и алгоритмов - это мифы и легенды со днища окиана( вузы там, низкасортная жаба-работёнка за еду), особенно в сишке.

ЛОЛ

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

это тебе только так кажется. Когда ты пишешь говнокод в говномодульности, то это сразу видно, потому что у тебя не собирается и/или не работает. Когда ты пишешь говнокод с говноуказателями, то у тебя всё работает, и ты думаешь «я опытный программист!». На самом деле, ты говно. Причём глупое и самоуверенное.

Ничего личного, я сам таким был.

Просто надоел!

«надоели уже эти скучные виндусовые обои». Я серьёзно.

Чем ниже уровнем, тем сложнее.

это расспространенное заблуждение.

да.

и чем выше уровень, тем сложнее

Истина в том, что везде свои сложности. Т.ч. ты тоже ошибаешься.

надо сделать так, чтобы они не текли катастрофически хотя бы в самых критических местах, а чем выше по уровню, тем меньше low-hanging fruit.

на низком уровне всё _уже_ сделано, и вариантов часто нет(не считая замены железа). Сложность в том, что на низком уровне нужно очень чётко понимать КАК и ПОЧЕМУ сделано именно так. Для этого тоже требуется умение строить абстракции. На самом деле, регистр rax это тоже абстракция и символическое имя. А вовсе не 100500 транзисторов, как ты наверное думаешь. Ну и даже если это действительно 100500 транзисторов, то с т.з программиста это всё равно абстракция, ибо это разные 100500 транзисторов.

Мне кажется, что начинающий говнокод на си будет состоять из единственного programma.c, делов-то разбираться с этими хедерами.

Мне кажется, что начинающий говнокод на си будет состоять из единственного programma.c, делов-то разбираться с этими хедерами.

ну да. Это тоже.

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

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

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

Нет. Сложно создавать высокоуровневые абстракции на низкоуровневом языке. То есть, низкоуровневые языки сложны.

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

А чем выше уровень языка, тем труднее не создавать ненужные абстракции :)

включай в каждый модуль ВСЕ необходимые ему #include, не полагайся на неявное включение;

Ссаной тряпкой по соплям за такое.

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

Чего? static и префиксы к именам функций - куда уж проще-то?!?

А чем выше уровень языка, тем труднее не создавать ненужные абстракции :)

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

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

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

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

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

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

хм. возможно, вы с тейлганнером правы. я не особо программист, чтобы об этом судить. однако мне показалось что создавать годные абстракции одинаково сложно — что в Си, что в Питоне, что в Эрланге. просто, скажем, в Си приходится вручную администрировать память. и, скажем, двухсвязный список прийдется самому запилить (а у вас разве нет уже готового модуля?). ну и что? на сложность именно создания праильной абстракции это не влияет.

имхо сложность создания абстракции зависит от уровня абстракции. чем ближе к железу, тем проще, чем больше подробностей абстракция скрывает, тем она сложнее — скажем, csma/cd сильно проще того же sctp. ведь первый скрывает гораздо меньше подробностей реализации. а на каком языке писать — вот честно пофиг, даже соотношение LoC будет приблизительно равным, я уверен.

Ну, в gcc же работает!

конечные автоматы

Без этого вообще хрен решишь огромный спектр задач!

ну и что?

Ну и то. Больше деталей приходится держать в голове. Больше возможностей ошибиться. Меньше ресурсов головного мозга остаётся на собственно абстракцию.

сложность создания абстракции зависит от уровня абстракции.

Конечно, зависит! Но уровень необходимой абстракции зависит не от языка, а от задачи. Он задан «извне», от языка зависит, насколько легок будет создать абстракцию ДАННОГО уровня.

Сложно создавать высокоуровневые абстракции на низкоуровневом языке

Ага, а на "высокоуровневом" языке иной раз таких "абстракций" понагородят, что хочется, как правильно сказал аноним, ссаными тряпками по морде!

вопрос напоминает хорошо известную фразу: «А сторож сильный? (с)»

Про хеш-таблицы я неточно сформулировал. Я имел в виду «хэш-таблица vs дерево», реализация ассоциативного массива; а когда писал, в голове крутилось HashMap.

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

Ты бы видел, что городят на низкоуровневых.

;)

http://julialang.org/

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

Больше деталей приходится держать в голове. Больше возможностей ошибиться. Меньше ресурсов головного мозга остаётся на собственно абстракцию.

ну так абстрагируй сначала эти детали, епт :) разве не все начинают с подключения своей «библиотеки» макросов? да, это больше геморроя, да, это проще в более высокоуровневых языках, для этого они и есть, но это — механические детали, а не детали абстракции.

иными словами, «насколько легко будет создать абстракцию ДАННОГО уровня» от языка не зависит, от языка зависит только насколько легко будет ее механически закодировать.

C == сила;

Чего? static и префиксы к именам функций - куда уж проще-то?!?

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

о каких таких «разных подходах к реализации хеш-таблиц» речь? какие есть разные подходы?

вангую, речь про коллизии.

Речь ведь шла о ЯП более-менее общего назначения. Теперь скажи, как на этой Юле мне написать системный демон/веб-сервер/100500ый медиапроигрыватель?

На самом деле, я не коллизии имел в виду, но про них тоже знать полезно :)

Ну, в gcc же работает!

наверное. Я откуда знаю? Мне достаточно классики.

Ну а вообще, тут всё сложнее. У меня gcc строит файлы с зависимостями (*.d) для make, потому мне глупо включать всё в каждый файл. Я включаю только то, что надо, так быстрее собирается. Возможно, я и не Ъ...

Я имел в виду «хэш-таблица vs дерево»

это всё у Кнута подробно обсосано. Зачем помнить такие вещи?

Пруфцы будут предыдущих достижений, либо сольёшься как предыдущий оратор на «сасайлалка»?

Точно так же, как и на остальных языках. Оно — общего назначения.

Берёшь готовые биндинги и пишешь. Если нет биндингов — чуть больше работы, но при возможности вызывать C-функции напрямую терпимо.

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