Нашли или выдавили из себя код, который нельзя назвать нормальным,
на который без улыбки не взглянешь?
Не торопитесь его удалять или рефакторить, — запостите его на
говнокод.ру, посмеёмся вместе!
А на чём ты предлагаешь писать? Си с ручным управлением памятью? Или на говнопитоне? Писать-то можно на любом языке, только результат изменится не сильно.
Тут смысл не в ЯП, а в ущербности биндингов.
Я тут недавно написал несколько лаб на Си с автоматическим управлением памятью (#include <gc>). И смело заявляю, что говнистость Си одним только ручным управлением памятью не ограничивается.
Невнятной системой типов (кастовать можно что угодно во что угодно, т.е. по-сути тот же ж.скрипт, только ошибка приведения типов либо пройдет незаметно, либо сегфолт). Ну и каст из int в float работает не так, как каст из int в struct какой-нибудь, например, Отсутствием инкапсуляции. Плохо продуманый синтаксис. Куча каких-то безумных и ненужных правил работы со знаковыми / беззнаковыми числами. Ну это только для начала.
>кастовать можно что угодно во что угодно
Есть еще unionы и void*
И если юнион таки удобная и годная штука, void* (да-да-да, в сишке есть не только автовывод типов, но и генерики).
См также: "очень полезный тип указатель", "единственно верный тип данных массив"
>>Невнятной системой типов
да, в си достаточно слабая типизация. Но именно это и было нужно так как программист должен управлять памятью. Например, он знает что в памяти лежит 2 байта определенного формата, и кастит int с этими байтами в структуру).
Понятное дело что писать бизнес-логику на этом грустно. Но это не говнистость, а особенность ЯП для конкретных задач. Иначе можно сказать что и ассемблер говнист.
>>Отсутствием инкапсуляции.
Инкапсуляция прекрасно достигается в сях! static функции + opaque types.
>> Плохо продуманый синтаксис.
да, синтаксис мог бы быть и по-лучше, согласен.
>> Куча каких-то безумных и ненужных правил работы со знаковыми / беззнаковыми числами.
Каких это?
Блин, как я люблю когда человек не понял зачем нужен инструмент, не осилил его и начал рассказывать про говнистость.
Молоток это говно! Им неудобно накалывать макароны (в той же вилке это в тысячу раз лучше решено!!). Им очень легко сломать себе ногу, если по ней ударить (заметьте: ни палка для селфи, ни мочалка такими проблемами на обладают!) и наконец молотком совершенно неудобно чесаться
> как я люблю когда человек не понял зачем нужен инструмент
Как я люблю, когда языки программирования сравнивают с отвёртками и молотками!
> Молоток это говно!
Конкретно у этого молотка могла бы и не отваливаться ручка через раз.
Сишка могла бы быть проще и удобней.
Не втыкать все эти неявные касты, упростить синтаксис, предоставить вменяемую альтернативу макросам, изначально продумать модульную систему (теперь-то мы модулей уже никогда не увидим) и т.п.
пиздатые, да. Потому что макросы в АСМе куда важнее, чем в сях. Без них там было бы ну очень много бойлерплейта.
Касперски как-то приводил пример: ему нужно было повторить код N раз. Причем именно один и тот же код (не цикл, не вынос в функцию итд). В сях это почти никак не сделать, а в MASM делается макрос, коий параметризуется кол-вом повторений
>>Как я люблю, когда языки программирования сравнивают с отвёртками и молотками!
и сразу же сам сравнил:
>>Конкретно у этого молотка могла бы и не отваливаться ручка через раз.
Причем заметь: я в своем сравнении указал на конкретную глупость: товарищ ждет от инструмента не того, для чего он был задуман.
А о чем говорит твое сравнение? что такое "ручка отвалилась"? что-то перестало работать? компилятор упал? что такое ручка?
>>Сишка могла бы быть проще и удобней.
Разумеется!
А теперь скажи мне: есть-ли такой язык, который идеален и не мог бы вот уже быть проще и удобней?
>>упростить синтаксис, предоставить вменяемую альтернативу макросам, изначально продумать модульную систему
Тогда это будет уже другой язык, правда?
А что вы все доебались до модульности? Что не так с модульностью то?
Неймспейсов нет, это плохо, а еще что?
Ну так это намеренно, чтобы было понятней, как херово выглядят подобные размытые аналогии.
> А о чем говорит твое сравнение?
А что означает накалывать макароны молотком? Что здесь макароны?
> Что не так с модульностью то?
Её нет. Ваш кэп.
Извольте соблюдать ODR ручками, надейтесь, что обезяны, написавшие какую-нибудь библиотеку, не используют те же символы, что и ты, или те же символы, что другие обезьяны.
Ну и текстовые инклюды с перекомпиляцией хедеров раз за разом - это божественно.
>>А что означает накалывать макароны молотком? Что здесь макароны?
Вы правда не поняли моей аналогии? Глупо ждать от "переносимого ассемблера" строгой типизации, правда?
Серьезно, говорить что минус сей в том, что "кастовать можно что угодно во что угодно" может только человек, который совершенно не понял зачем си нужны, и когда их нужно использовать.
>>, не используют те же символы,
да, в сях нету неймспейсов и это плохо. Но эту проблему решают префиксами. И, в целом, она решается.
>>Ну и текстовые инклюды с перекомпиляцией хедеров
А есть percompiled headers вообще-то.
Пляски с include guards это правда оцтой, но например в Objc эту проблему решили конструкцией #import (не путать с VCшным #import).
>>Её нет. Ваш кэп.
Дайте пожалуйста определение модульности.
>>о создателям было лень писать явные касты руками.
стоп! Так претензия в _неявном_касте_ или в физической возможности скастовать поинтер в int _в_принципе_ ?
Это важно. Потому что если проблема в неявности, то я согласен (хотя и так компилятор выдаст варнинг)
>> Нуль, к примеру, прекрасно кастится к указателю даже в плюсах
Хочется верить что в 2016м году попытка его разыменовать приведет к ошибке в большинстве сред)
резюмируя:
В сях много говнистости (неявные касты, модульность реализуемая в полуручном режиме, путаный (в сложных случаях) синтаксис). Это правда.
Но ни ручное управление памятью, ни возможность кастить что угодно во что угодно *НЕ* являются проблемами сей, ибо это именно то, ради чего они были сделаны.
Ну и инкапсуляция, очевидно, так же не является особенностью языка (это особенность кода)
> Ну и инкапсуляция, очевидно, так же не является особенностью языка (это особенность кода)
Язык задаёт тон. Или плясать с гирей на ноге, или с ленточкой. Конечно, это особенность танцора, но гиря мешает.
В том же жс можно так спрятать функцию в функции, что даже её имя никто не узнает, не то что вызовет. Можно разделить задачу на мелкие части и вкладывать функции в функции так, чтобы более мелкие куски из одной подсущности не знали своих двоюродных братьев, не имели к ним доступ без воли бабушки. В C для такого же эффекта (точно такого же? если в 2х файлах одно и то же имя неэкспортируемой сущности, не бомбанёт?) нужно создавать несколько файлов.
> HANDLE в w32api
> ну чем не инкапсуляцы?
Инкапсуляция, не спорю.
Но в JS инкапсулировать легче. function в function через function и уже не то, что в одном и том же файле, в одной и той же функции питушня сокрыта.
>>Язык задаёт тон
Точнее сказать язык дает инструменты.
Сишечка позволяет модульность, но модули нужно поддерживать руками:
1) в .h файле
2) в .c файле
3) во всех местах испольхования
4) в сборщике (передать нужные опции линкеру и компилятору)
5) следить за ODR
6) следить за неймингом
Си был сделан для системщины. То, что в нем указатели можно кастовать в числа и обратно - скорее всего получилось случайно / создатели не догадывались каким злом это обернется. Практических бонусов каких-то от этой фичи нет.
Инкапсуляция нуждается в инструментах, для того, чтобы ее можно было реализовать. Возможно, авторы Си не представляли себе необходимости писать большие / модульные программы, вот они и не заморачивались этим вопросом.
>>То, что в нем указатели можно кастовать в числа и обратно - скорее всего получилось случайно
>> Практических бонусов каких-то от этой фичи нет.
Нет.
В спецификации вот даже на IBM PC есть знания о том, по каким адресам в памяти доступен, например, BIOS.
Очевидно что в си именно для этого можно пойти в память по определенному адресу.
>>Инкапсуляция нуждается в инструментах, для того, чтобы ее можно было реализовать.
И снова: В Win32API _прекрасно_ реализована инкапсуляция. И не только в нем.
Каж жеж это прекрасно, когда можно случайно найти два файла-заголовка с одним и тем же прототипом но реализованым в разных местах, и по-разному, а потом в зависимости от того, что первым скомпилировалось поиграть в рулетку.
> Инкапсуляция прекрасно реализуется без неймспейсов
Ну так-то сишка на удивление мультипарадигменный язык. При должном усердии и внимании, в нем прекрасно реализуется модульность, инкапсуляция, полиморфизм, наследование, обобщённое программирование, функциональное программирование и даже автоматическая сборка мусора!
По поводу доступa к памяти по определенному адресу: это никак не заставляет кастовать адреса в числа и обратно. Ну будет тип "указатель" со значением "123", и будет тип "число" со значением "123" - проблема же не в этом, а в ненужной возможности подставить число вместо указателя, или прибавить число к указателу и т.д. Но это уже такая избитая тема, что и возвращаться к ней не хочется.
> ненужной возможности подставить число вместо указателя, или прибавить число к указателу
А как мне обратиться к пачке memory mapped регистров по адресам 0xEFFF0000 .. 0xEFFF0007?
Никто не запрещает делать перебор адрессов, или массивы из них. Речь же не об этом, а о том, что адресса - это не числа и не нужно их друг с другом складывать, умножать и т.д. Никого же не смущает невозможность умножить целое на вещественное, почему тут такая сложность?
> друг с другом
Друг с другом их и не дают складывать. Только с числом. И умножать-делить не дают. Только вычитать ещё можно (получается знаковое число). И указатели в числа и обратно не кастуются, если явно этого не захочешь...
Вот у меня есть адрес начала блока 32-битных регистров. Как мне получить адрес i'го регистра в блоке? Кроме как прибавить число к адресу?
Ну здесь можно было бы сделать специальный литерал для адресов, который бы не смешивался с числами. Например uint32_t * secretAddress = 0x1234P.
А вот от арифметики над адресами один хуй никак не избавиться. Ну и от желания указывать адреса в конфигах, собирать их из байтиков по кускам и творить прочие непотребства...
> Как мне получить адрес i'го регистра в блоке?
В любом случае нужно прибавлять не число, а расстояние от одного адресса до другого. Как именно это сделать - проблема компилятора. В итоге это все-равно будет сложение чисел, вот только смысл будет другой с точки зрения программиста.
Просто числа в Си плохие изза того, что их решили использовать для представления памяти, ну а потом поняли, что может это было не самым удачным решением, но поезд уже ушел.
К слову об замечательных инкапсуляциях в ВинАПИ: чет у них не очень получилось заинкапсулировать способ адрессации памяти, и врезультате такой замечательной инкапсуляции, 32-битные программы будут еще очень долго поддерживаться отдельными костылями.
лол, какие есть способы описать некое расстояние не прибегая к числам?
>> не очень получилось заинкапсулировать
Очевидно что дело тут в кривых руках пользователей. Если не использовать знание о размере поинтера, то проблем нет.
А в Vala типа не ручное? Там ещё хуже - если в сишке понятно, что за всё сам отвечаешь, то с валой надо понимать, где какой сишный код сгенерится, что там управляемое, а что нет.
Пытался ради интереса посмотреть эту порнографию, но уж лучше на C++ писать, и с "биндигами" проблем не будет.
Даже Canonical забросил эту унылую Vala и фигачит новые проекты на Qt.
проблема этого кода и правда не в языке, но это не отменяет вопроса
зачем пользоваться очевидно нестабильным, сырым, и при этом не развивающимся инструментом?
Ви так говорите, как будто в циферках версии действительно видно прогресс.
Цифры версии вообще ничего не значат. Могут три мажорные версии поменять и поправить два минорных бага. А могут с 0.1 дойти до 0.2 и поменять вообще всё.
Тут смысл не в ЯП, а в ущербности биндингов.
Нету команды для перехода к i элементу плейлиста?
>кастовать можно что угодно во что угодно
Есть еще unionы и void*
И если юнион таки удобная и годная штука, void* (да-да-да, в сишке есть не только автовывод типов, но и генерики).
См также: "очень полезный тип указатель", "единственно верный тип данных массив"
Ну типа все что угодно это указатель на какой-то char?)
да, в си достаточно слабая типизация. Но именно это и было нужно так как программист должен управлять памятью. Например, он знает что в памяти лежит 2 байта определенного формата, и кастит int с этими байтами в структуру).
Понятное дело что писать бизнес-логику на этом грустно. Но это не говнистость, а особенность ЯП для конкретных задач. Иначе можно сказать что и ассемблер говнист.
>>Отсутствием инкапсуляции.
Инкапсуляция прекрасно достигается в сях! static функции + opaque types.
>> Плохо продуманый синтаксис.
да, синтаксис мог бы быть и по-лучше, согласен.
>> Куча каких-то безумных и ненужных правил работы со знаковыми / беззнаковыми числами.
Каких это?
Блин, как я люблю когда человек не понял зачем нужен инструмент, не осилил его и начал рассказывать про говнистость.
Молоток это говно! Им неудобно накалывать макароны (в той же вилке это в тысячу раз лучше решено!!). Им очень легко сломать себе ногу, если по ней ударить (заметьте: ни палка для селфи, ни мочалка такими проблемами на обладают!) и наконец молотком совершенно неудобно чесаться
Как я люблю, когда языки программирования сравнивают с отвёртками и молотками!
> Молоток это говно!
Конкретно у этого молотка могла бы и не отваливаться ручка через раз.
Сишка могла бы быть проще и удобней.
Не втыкать все эти неявные касты, упростить синтаксис, предоставить вменяемую альтернативу макросам, изначально продумать модульную систему (теперь-то мы модулей уже никогда не увидим) и т.п.
Касперски как-то приводил пример: ему нужно было повторить код N раз. Причем именно один и тот же код (не цикл, не вынос в функцию итд). В сях это почти никак не сделать, а в MASM делается макрос, коий параметризуется кол-вом повторений
BOOST_PP
но вообще нахуй такие упражнения
и сразу же сам сравнил:
>>Конкретно у этого молотка могла бы и не отваливаться ручка через раз.
Причем заметь: я в своем сравнении указал на конкретную глупость: товарищ ждет от инструмента не того, для чего он был задуман.
А о чем говорит твое сравнение? что такое "ручка отвалилась"? что-то перестало работать? компилятор упал? что такое ручка?
>>Сишка могла бы быть проще и удобней.
Разумеется!
А теперь скажи мне: есть-ли такой язык, который идеален и не мог бы вот уже быть проще и удобней?
>>упростить синтаксис, предоставить вменяемую альтернативу макросам, изначально продумать модульную систему
Тогда это будет уже другой язык, правда?
А что вы все доебались до модульности? Что не так с модульностью то?
Неймспейсов нет, это плохо, а еще что?
вы о том что знание о депенденсах пишется 2 раза: сначала в виде импорта, затем в виде ключика в Make файле?)
Ну так это намеренно, чтобы было понятней, как херово выглядят подобные размытые аналогии.
> А о чем говорит твое сравнение?
А что означает накалывать макароны молотком? Что здесь макароны?
> Что не так с модульностью то?
Её нет. Ваш кэп.
Извольте соблюдать ODR ручками, надейтесь, что обезяны, написавшие какую-нибудь библиотеку, не используют те же символы, что и ты, или те же символы, что другие обезьяны.
Ну и текстовые инклюды с перекомпиляцией хедеров раз за разом - это божественно.
Вы правда не поняли моей аналогии? Глупо ждать от "переносимого ассемблера" строгой типизации, правда?
Серьезно, говорить что минус сей в том, что "кастовать можно что угодно во что угодно" может только человек, который совершенно не понял зачем си нужны, и когда их нужно использовать.
>>, не используют те же символы,
да, в сях нету неймспейсов и это плохо. Но эту проблему решают префиксами. И, в целом, она решается.
>>Ну и текстовые инклюды с перекомпиляцией хедеров
А есть percompiled headers вообще-то.
Пляски с include guards это правда оцтой, но например в Objc эту проблему решили конструкцией #import (не путать с VCшным #import).
>>Её нет. Ваш кэп.
Дайте пожалуйста определение модульности.
Нет, не глупо. Слабую типизацию сделали исключительно потому, что создателям было лень писать явные касты руками.
> А есть percompiled headers вообще-то.
Костыль.
стоп! Так претензия в _неявном_касте_ или в физической возможности скастовать поинтер в int _в_принципе_ ?
Это важно. Потому что если проблема в неявности, то я согласен (хотя и так компилятор выдаст варнинг)
>>Костыль.
все, короче я понял чего вы хотите
Вот этого:
https://stoneofarc.wordpress.com/2013/06/25/introduction-to-objective-c-modules/
да?
> стоп! Так претензия в _неявном_касте_ ... ?
читать умеешь, гест?
> (хотя и так компилятор выдаст варнинг)
Не всегда. Нуль, к примеру, прекрасно кастится к указателю даже в плюсах, на это запросто можно наступить.
> все, короче я понял чего вы хотите
Хотим модулей хотя бы в том виде, в котором они реализованы в D.
Посмотри выше.
Хочется верить что в 2016м году попытка его разыменовать приведет к ошибке в большинстве сред)
резюмируя:
В сях много говнистости (неявные касты, модульность реализуемая в полуручном режиме, путаный (в сложных случаях) синтаксис). Это правда.
Но ни ручное управление памятью, ни возможность кастить что угодно во что угодно *НЕ* являются проблемами сей, ибо это именно то, ради чего они были сделаны.
Ну и инкапсуляция, очевидно, так же не является особенностью языка (это особенность кода)
Язык задаёт тон. Или плясать с гирей на ноге, или с ленточкой. Конечно, это особенность танцора, но гиря мешает.
В том же жс можно так спрятать функцию в функции, что даже её имя никто не узнает, не то что вызовет. Можно разделить задачу на мелкие части и вкладывать функции в функции так, чтобы более мелкие куски из одной подсущности не знали своих двоюродных братьев, не имели к ним доступ без воли бабушки. В C для такого же эффекта (точно такого же? если в 2х файлах одно и то же имя неэкспортируемой сущности, не бомбанёт?) нужно создавать несколько файлов.
Нет. JS, вообще говоря, не самый удачный пример модульности 🙂 Образцом я лично считаю StandardML.
Даже за импортить модуль в языке нельзя, нужны левосторонние либы.
инкапсуляция есть сокрытие внутренней структуры с использованием публичного интерфейса
в сях это прекрасно работает, это те самые opque types о которые я уже изык разбил
HANDLE в w32api
ну чем не инкапсуляцы?
> ну чем не инкапсуляцы?
Инкапсуляция, не спорю.
Но в JS инкапсулировать легче. function в function через function и уже не то, что в одном и том же файле, в одной и той же функции питушня сокрыта.
Точнее сказать язык дает инструменты.
Сишечка позволяет модульность, но модули нужно поддерживать руками:
1) в .h файле
2) в .c файле
3) во всех местах испольхования
4) в сборщике (передать нужные опции линкеру и компилятору)
5) следить за ODR
6) следить за неймингом
В сях не бомбанет если две функции статик
Инкапсуляция нуждается в инструментах, для того, чтобы ее можно было реализовать. Возможно, авторы Си не представляли себе необходимости писать большие / модульные программы, вот они и не заморачивались этим вопросом.
>> Практических бонусов каких-то от этой фичи нет.
Нет.
В спецификации вот даже на IBM PC есть знания о том, по каким адресам в памяти доступен, например, BIOS.
Очевидно что в си именно для этого можно пойти в память по определенному адресу.
>>Инкапсуляция нуждается в инструментах, для того, чтобы ее можно было реализовать.
И снова: В Win32API _прекрасно_ реализована инкапсуляция. И не только в нем.
Она есть, я не спорю. Но реально она решается путем конвенции: давайте функциям префиксы, и все будет работать.
Инкапсуляция прекрасно реализуется без неймспейсов. Разгребайте уже кашу в голове
Ну так-то сишка на удивление мультипарадигменный язык. При должном усердии и внимании, в нем прекрасно реализуется модульность, инкапсуляция, полиморфизм, наследование, обобщённое программирование, функциональное программирование и даже автоматическая сборка мусора!
Во-вторых неймспейсы это просто способ нейминга, к инкапсуляции он отношения не имеет.
В ObjC нету неймспейсов, а инкапсуляция в Cocoa прекрасная.
В PHP 6 есть неймспейсы, а инкапсуляции обычно никакой нет.
Именно поэтому он не вышел в релиз?
когда там у вас эти спейсы появились?
Он не т в 5.4 трейты появились неймспейсы значит еще раньше в 5.3. а это 9 год.
А как мне обратиться к пачке memory mapped регистров по адресам 0xEFFF0000 .. 0xEFFF0007?
Друг с другом их и не дают складывать. Только с числом. И умножать-делить не дают. Только вычитать ещё можно (получается знаковое число). И указатели в числа и обратно не кастуются, если явно этого не захочешь...
Вот у меня есть адрес начала блока 32-битных регистров. Как мне получить адрес i'го регистра в блоке? Кроме как прибавить число к адресу?
вот у тебя есть знание о том, что волшебное яйцо лежит по адресу 0x1234.
Как тебе по этому адресу обратиться не используя int? Ведь литерал 0x1234 будет иметь тип int, а значит придется int кастить в pointer!
А вот от арифметики над адресами один хуй никак не избавиться. Ну и от желания указывать адреса в конфигах, собирать их из байтиков по кускам и творить прочие непотребства...
В любом случае нужно прибавлять не число, а расстояние от одного адресса до другого. Как именно это сделать - проблема компилятора. В итоге это все-равно будет сложение чисел, вот только смысл будет другой с точки зрения программиста.
Просто числа в Си плохие изза того, что их решили использовать для представления памяти, ну а потом поняли, что может это было не самым удачным решением, но поезд уже ушел.
К слову об замечательных инкапсуляциях в ВинАПИ: чет у них не очень получилось заинкапсулировать способ адрессации памяти, и врезультате такой замечательной инкапсуляции, 32-битные программы будут еще очень долго поддерживаться отдельными костылями.
>> не очень получилось заинкапсулировать
Очевидно что дело тут в кривых руках пользователей. Если не использовать знание о размере поинтера, то проблем нет.
cl.exe: error C2110: '+' : cannot add two pointers
gcc: error: invalid operands to binary + (have ‘char *’ and ‘char *’)
Знаешь, почему я не рассуждаю об истории Суахили?
Потому что ничерта в ней не понимаю.
Ну тогда возвращаемся к первому вопросу:
>>лол, какие есть способы описать некое расстояние не прибегая к числам?
А в Vala типа не ручное? Там ещё хуже - если в сишке понятно, что за всё сам отвечаешь, то с валой надо понимать, где какой сишный код сгенерится, что там управляемое, а что нет.
Пытался ради интереса посмотреть эту порнографию, но уж лучше на C++ писать, и с "биндигами" проблем не будет.
Даже Canonical забросил эту унылую Vala и фигачит новые проекты на Qt.
с другой стороны, кто в нынешние времена вообще что-то новое на gtk писать начинает? все нормальные люди давно на WxWidgets или Qt пересели.
https://www.youtube.com/watch?v=ON0A1dsQOV0
например тот же reference counting легко организовать и в C, и например в ObjC (до ARC) люди прекрасно себе жили с полуручным управлением
о чем ты?
ты видел как RefCount сделан с COM или Objc?
зачем пользоваться очевидно нестабильным, сырым, и при этом не развивающимся инструментом?
конечно, ЯП за 10 лет прошедший путь от 0.0 до 0.3 быстро развивающийся
Цифры версии вообще ничего не значат. Могут три мажорные версии поменять и поправить два минорных бага. А могут с 0.1 дойти до 0.2 и поменять вообще всё.
Цифры. Цифры ничего не значат.