Вообще, получилось не только про Си, но, все таки.
Так вот, то что Си еще жив это, если подумать, вершина идиотизма около-ITшных масс.
Сишечка изначально была "языком расширений Unix".
Unix, как я уже как-то писал, был одной из ранних и убогих реализаций Dataflow-парадигмы программирования. Ну, то есть, для более-менее массового железа 70х Unix был не такой уж убогой реализацией, если подумать, но все равно.
Суть Unix заключалась в куче мелких утилит, общающихся через файлы и пайпы, и плюющихся друг в друга текстом и просто бинарными данными.
Так вот, Сишечка использовалась только в Unix, и исключительно только для написания вот этих вот мелких утилит. Ну там, считать файл в stdout, или строчки со stdin отсортировать. Самой сложной программой на сишечке в то время был шелл(даже ядра ранних юниксов были проще шелла). То есть, программы были мелкие, простые, и их было довольно мало(ну можно себе представить железо 70х, учитывая закон Мура и все такое, да?). Всё, на этом предназначение Си заканчивалось. Потому что ну, что еще можно взять с языка, который от ассемблера PDP-11 отличается только тем, что регистры не надо указывать вручную?
Все более-менее ответственные и сложные дела в то время делали на больших и сложных компьютерах, на нормальных языках, типа тех же лиспов(оптимизирующие компиляторы в машкоды для лиспов существовали уже в 70х). Ну, вычисления делали на фортране.
Так вот, на этом всем предназначение и жизнь Си и закончилось бы, если бы IT не наводнили толпы, извините, ебланов, подхвативших первое что попалось под руку и начавших клепать килотонны говнософта. Это сейчас называется "worse is better". Юниксы со временем невероятно жирели и превращались в отвратительных монстров, программы на них тоже жирели, но вот от Си никуда было не деться, потому что Си это сердце, суть, и модель исполнения Юникса. Си и Юникс это одно и то же, как рантаймы лиспов и сами лиспы, например.
Пока те же лиспы использовались либо только в академии, либо же самодовольными и жадными крупными корпорациями, Си захватил мир.
Особенно мир настольных компьютеров, где уровень железа просто не позволял запускать нормальные языки(кто-нибудь знает на какое железо расчитан DOS? "640 килобайт будет достаточно для каждого", ага. И сравните с лиспами, среднестатистическим реализациям которым уже тогда надо было минимум несколько мегабайт под рантайм и стандартную библиотеку).
Сишечка в 80х стала просто невыносимо популярна. Но уже тогда народ начал понимать ее убогость и ограничения. На волне этого некто Б. Страуструп придумывает препроцессор на Си, теперь известный как самостоятельный язык C++.
Нормальные языки, типа лиспов(а также смоллтолков, и других подобных), в то же время, под конец 80х постигает очень и очень незавидная участь. Дело в том, что в то время лиспы, как одни из наиболее фичастых и продвинутых языков программирования, в основном использовались в сфере разработок в области искусственного интеллекта.
Не только, естественно, в ней(лисп тогда был вообще довольно популярен. Не настолько, насколько Си, но например на tiobe.com можно посмотреть что в 87 году, "Lisp" был на 2м месте рейтинга), но в основном.
Но, так как искусственный интеллект вещь весьма и весьма туманная, никаких особых подвижек в этой области, несмотря на огромные вливания крупных контор, к концу 80х так и не произошло. По этой причине, крупный бизнес и даже, отчасти, академия, от AI начали отворачиваться, и, в конце концов, отвернулись совсем.
При чем тут лисп? Дело в том, что основные вливания в развитие лисповых компиляторов, рантаймов и всего такого, вливания на популяризацию и маркетинг лиспов, шли как раз из сферы AI, и соответственно, как эти вливания прекратились, экосистемы лиспов тоже резко стали хилеть, и в конце концов схлопнулись.
Добавляло "плюшек" к этому всему то, что не только корпорации, а просто даже люди из IT стали отворачиваться не только от сферы AI, но и от всего, что с ней связано, и в частности от лиспов.
Закончилось это всё очень плохо - передовые реализации лиспов(типа CMUCL) просто выбросили на помойку(т.е. в опенсорс), а вендоры коммерческих лисп-систем либо массово обанкротились(Symbolics и другие), либо ушли в подвал, и чтобы хоть как-то выжить, взвинтили цены на свои реализации чуть ли не до облаков(Xanalys(который сейчас LispWorks), Franz, и т.п.). В итоге о лиспах практически все забыли лет на 10, а то и больше.
Сейчас то время(конец 80х, начало 90х) называется "AI Winter".
Вот тут кое-что можно об этом почитать: http://www.flownet.com/gat/jpl-lisp.htm
В то же время, как раз тогда, Си и C++ набирают огромную популярность, потом на волне популярности этих языков выходит как-бы-похожая-на-них-но-избавленная-от-о
1) Повсюду какое-то древнее говно, предназначающееся для мелких расширений юниксов 70х, скриптовые недоделки, сделанные на коленке чтобы быстро-быстро писать какую-нибудь очередную гостевуху, и помеси из этих самых древних говн и скриптовых недоделок с ранними лиспами, отрицающие родство с последними и всячески от него открещивающиеся.
2) Про лисп мало кто что знает, кроме того что там "куча скобок" и "все состоит списков", и вообще, все как минимум его избегают и пугаются, как максимум над его использованием еще и стебутся.
3) В областях CS, связанных с языками программирования, прогресс уперся в какие-то тупиковые темы, типа статических систем типов, и там зациклился(ну это я просто чтобы позлить хаскелистов написал, можете не обращать внимания).
Это всё грустно.
Anonymous
January 31 2012, 19:38:14 UTC 3 months ago
(и выключи капчу для друзей :)
January 31 2012, 19:44:27 UTC 3 months ago
January 31 2012, 19:39:15 UTC 3 months ago
Извини не залогинился :) гг
January 31 2012, 19:42:40 UTC 3 months ago
кстати, я с ним начал знакомиться после WPF, и было некоторое дежавю("команды", например, и другое)
3 months ago
3 months ago
3 months ago
January 31 2012, 19:45:57 UTC 3 months ago
а накидай мне аргументов, почему это тупик? а то мне вечно не хватает :(
January 31 2012, 19:53:29 UTC 3 months ago
Я имею ввиду, в тотальной статике.
Для тьюринг-полного языка ни одна система типов не будет полной. А обратное можно посмотреть на примере всяких там языков с зависимыми типами, которые крайне неюзабельны для риал-ворлд программ.
По мне так, если говорить о типизации, то надо копать в сторону опциональной типизации, и оптимизации эвристик частичного вывода типов(которые в реализациях CL, например, используются).
January 31 2012, 20:38:23 UTC 3 months ago
подобных Продолжениям на практике от swizard@fprog.ru
Anonymous
February 1 2012, 08:29:35 UTC 3 months ago
Ты хочешь сказать, что хаскель не тьюринг полный или в нем с системой типов что-то не так?
3 months ago
January 31 2012, 19:56:42 UTC 3 months ago
1. C - портабельный ассемблер. Первую версию юникса написали на ассемблере, но потом портируемости ради переписали на специально созданном портируемом ассемблере.
2. Железо 70-х особо от железа 2010-х не отличалось. Даже уже была виртуализация. Вспомни, сколько лет назад появилась нормальная виртуализация в твоём домашнем компьютере.
3. CMUCL внутри - страшная помойка. Наследник-SBCL чуток проще собирается, но внутри всё та же помойка.
4. Кухню коммерческих лиспов ты не знаешь, а, опять же, рассуждать лезешь. Disclaimer: я тоже толком не знаю.
5. Если ты не написал хотя бы мегабайт кода на ассемблере для 8-битной машины с кол-вом памяти до 64 кб, то даже не трогай эту тему в своих размышлениях. Выглядит непрофессионально. Занимаешься гуйнёй - прекрасно, пиши про гуйню.
January 31 2012, 20:06:46 UTC 3 months ago
Дык, че еще делать в среду вечером?
>C - портабельный ассемблер. Первую версию юникса написали на ассемблере, но потом портируемости ради переписали на специально созданном портируемом ассемблере.
Никогда не любил вот когда его так называют. Вот как можно быть одновременно ассемблером под x86 и лисп-машины, например? Си это такой ассемблер PDP-11 с автоматической раскраской регистров.
>Железо 70-х особо от железа 2010-х не отличалось.
Ой да ладно. Векторные инструкции, например? Сегментная модель x86(которая, правда, была похоронена той же сишечкой с ее линейной виртуальной памятью). Да куча всего. Я уж не говорю про архитектуры с тегами, которые в 80х еще были(правда сплыли, вместе с лиспами и прочим, да).
>Кухню коммерческих лиспов ты не знаешь, а, опять же, рассуждать лезешь. Disclaimer: я тоже толком не знаю.
Историю вполне знаю :)
>CMUCL внутри - страшная помойка. Наследник-SBCL чуток проще собирается, но внутри всё та же помойка.
Да ладно, он просто сложный. Я сорцы довольно плотно смотрел. Там есть засранные места, да, но тем не менее. Но даже это не отменяет того, что это один из самых крутых компиляторов что на то время, что на сегодня(вот кстати, обидно что прогресса мало).
>Если ты не написал хотя бы мегабайт кода на ассемблере для 8-битной машины с кол-вом памяти до 64 кб, то даже не трогай эту тему в своих размышлениях. Выглядит непрофессионально. Занимаешься гуйнёй - прекрасно, пиши про гуйню.
Сперва добейся, ага :)
Кстати, не гуйней, в основном.
И что конкретного тебе на эту тему не понравилось, например?
3 months ago
3 months ago
3 months ago
3 months ago
3 months ago
January 31 2012, 20:31:49 UTC 3 months ago
Совсем уж помойкой я бы это не назвал. Концептуально/идеологически компилятор вполне нормален, особенно на фоне многих современных ВМ (хоть и устарел порядком). Но внутренности рантайма меня очень удивили, мягко говоря.
January 31 2012, 20:33:00 UTC 3 months ago
Почему? Maclisp и Interlisp вполне себе работали на машинах со всего одним мегабайтом, и даже под DOS вот какой-то Le Lisp нагуглился, вышедший в 1985 году.
В областях CS, связанных с языками программирования, прогресс уперся в какие-то тупиковые темы
Ну это неправда, прогресс никуда не упёрся, наоборот сейчас всё активно развивается практически по всем фронтам -- параллелизм, DSL, всякая веб-хрень, те же лиспы (CL/Clojure/Racket), да в конце концов и нынешний .NET не так уж плох.
January 31 2012, 21:09:28 UTC 3 months ago
"Всё это уже было в Симпсонах".
January 31 2012, 21:50:51 UTC 3 months ago
> убогих реализаций Dataflow-парадигмы программирования
OMG. Каким образом система, построенная на некой единственной сущности (файлы) и при этом не имеющая механизмов для уведомления об изменении экземпляров этой сущности (inotify-like до сих пор в POSIX нет), может иметь хоть какое-то отношение к Dataflow?
С тем же успехом UNIX можно назвать одной из ранних и убогих реализаций Forth-машины, чо. Действительно ранняя и с этой точки зрения реально убогая :-)
> основные вливания в развитие лисповых компиляторов,
> рантаймов и всего такого <..> шли как раз из сферы AI,
> и соответственно, как эти вливания прекратились,
> экосистемы лиспов тоже резко стали хилеть
Каким образом это произошло? Ведь язык C с 1990 года и по наше время тоже, мягко говоря, не особо бурно развивался, но популярности не потерял.
А вообще да, C сам по себе как язык-то отвратителен, но все попытки перевести нагруженные и высокопроизводительные элементы системы на что-то более высокоуровневое, как правило, заканчиваются воплями со стороны пользователей, что-де всё теперь у них тормозит. Java и .NET уже прошли по этому печальному пути. С другой стороны, вот на кой в 21 веке на C пишут менее нагруженные части системы а-ля at, cron и logrotate, мне не очень понятно.
February 1 2012, 07:10:40 UTC 3 months ago
February 1 2012, 07:22:09 UTC 3 months ago
Мало кто хочет такого же конца.
3 months ago
3 months ago
3 months ago
3 months ago
3 months ago
Anonymous
February 1 2012, 08:06:25 UTC 3 months ago
С - один из древнейших языков, который на ряду с lisp и Fortran составляет костяк современных языков. Если вы найдете хоть один не эзатерический язык, не испытавший влияние этой троицы приведите его тут.
Всем не нравится что в С можно выстрелить себе в ногу, так это господа плата за производительность языка и за размер результирующей программы как и ее слабой зависимости от внешнего окружения.
February 1 2012, 08:17:04 UTC 3 months ago
February 1 2012, 08:17:34 UTC 3 months ago
Можно. В сообществах филологов вон ругают русский и французский, чем мы хуже? Мы даже лучше. Если филолог скажет, что нужно переучить всех французов на английский, его в фашизме обвинят, а мы -- белые и пушистые.
> С - один из древнейших языков, который на ряду с
> lisp и Fortran составляет костяк современных языков
И? Латынь тоже составляет костяк, но учат её только историки по долгу службы и юристы, потому что так заведено.
> Всем не нравится что в С можно выстрелить себе в ногу,
> так это господа плата за производительность языка
А зачем нужно на таком производительном и вследствие этого кривом языке писать утилиты, от которых не нужна высокая производительность? Вон, я приводил примеры -- at и logrotate. Могу ещё напридумывать. Выиграли в ненужной производительности, потеряли в нужной как воздух стабильности. Зачем?
Anonymous
February 1 2012, 08:27:54 UTC 3 months ago
Предвидя разговор о том, что Common Lisp появился в середине 80х, а последний стандарт в середе 90х вышел, отвечаю - с сишечкой было то же самое, постепенная эволюция в виде C++, жабы, дуднета.
February 1 2012, 08:40:47 UTC 3 months ago
Anonymous
3 months ago
3 months ago
Anonymous
3 months ago
Anonymous
February 1 2012, 12:01:05 UTC 3 months ago
> Юниксы со временем невероятно жирели и превращались в отвратительных монстров
А венда твоя любимая со временем худеет и превращается в прекрасную прынцессу, ага.
> выбросили на помойку(т.е. в опенсорс)
Ну это вообще пушка. Emacs, SBCL, CLisp, которыми ты наверняка пользуешься, Apache/nginx/lighttpd/whatever, которые тебе странички ЖЖ отдают, Firefox/Chrome/whatever, которые тебе эти странички рисуют - это всё с помойки? Хули ты тогда всем этим пользуешься, бомжара, чтоле?
> тупиковые темы, типа статических систем типов
Динамикопетушок закукарекал?
February 1 2012, 13:14:04 UTC 3 months ago
"На помойку" это когда крупные конторы или университеты выбрасывают программу в опенсорс и перестают ей заниматься - т.е. поддерживать и развивать ее.
Anonymous
February 4 2012, 03:51:23 UTC 3 months ago
упорно видят достоинства в недостатках своего геморроя.
и так же упорно видят вокруг лишь плохие языки когда есть и лучше чем лисп.
полистайте тут блог мл-щика, может что и западет в голову:
http://existentialtype.wordpress.com/201
зы. хаскелл - академическая игрушка. мл и камл - получше.
Anonymous
February 4 2012, 04:15:58 UTC 3 months ago
То есть, имеется два способа представить комплексное число, используя две разные системы координат. Они, само собой, взаимозаменимы, поскольку представляют значения одного типа. Но форма представления отличается, и некоторые формы более удобны чем другие (прямоугольная для сложения, полярная для умножения, например). Мы можем, конечно, выбрать "структуру реальности", и представлять все комплексные числа одним способом, и считать координаты всего лишь способом представления числа. Но так же может быть и удобно считать что тип комплексных чисел состоит из двух видов, каждый из которых образован двумя вещественными числами, которые однако интерпретируются по-разному в зависимости от используемой системы координат.
Принципиально тут то что различие между двумя видами комплексных чисел динамическое в том смысле что некое вычисление может вернуть число любого вида, в зависимости от удобства или соглашения. Программа может проверять, находится ли комплексное число в полярной или прямоугольной форме, и мы можем формировать структуры данных, такие как множества комплексных чисел, в которых отдельные элементы могут быть любого из видов. Но это не противоречит тому основному факту, что есть только один статический тип комплексных чисел! С точки зрения теории типов я говорю что тип комплексное определен как объединение двух картезианских произведений вещественного типа с самим собой. Одно из произведений представляет вид прямоугольных представлений, другое представляет вид полярных представлений. Будучи типом-объединением, мы можем "диспетчеризовать" (проводить анализ случаев) по виду значения типа комплексное, и решать что делать во время выполнения. В этом ничего особенного нет. Фактически, это вполне просто и естественно в языках таких как МЛ или Хаскелл, которые поддерживают типы-объединения. (Языки которые объединения не поддерживают, связаны по рукам и ногам, и отсюда происходит часть путаницы.)
Какое все это имеет отношение к концепции динамического языка? Характеристики динамического языка те-же самые, значения делятся по видам на множество форм, которые можно отличать друг от друга во время выполнения. Набор значений которые могут быть нескольких видов, и мы можем отделять во время выполнения что есть что и как обрабатывать каждый вид значения. Поскольку каждое значение в динамическом языке делится по видам в этой манере, что мы делаем так это склеиваем все значения языка в один, гигантский (возможно даже расширяемый) тип. Заимствуя удачное описание у Даны Скотт, так называемые нетипизированные ("динамически типизированные") языки являются, фактически, единотипными (языками с одним типом). Вместо того чтоб иметь множество типов из которых можно выбрать, имеется только один!
И это именно то что неправильно с динамическими языками: вместо предоставления свободы игнорировать типы, они вместо этого навязывают рабское сужение внимания до одного типа! Каждое значение будет значением этого типа, у вас нет выбора! Даже если в конкретной ситуации мы полностью уверены что конкретное значение есть, скажем, целое, у нас нет выбора кроме как отнести его к значению типа "один истинный тип", вид которого определяется как целое, а не тип. Концептуально, это просто бред, однако такой подход несет за собой и серьезные, ощутимые расходы. Во-первых,вы лишаете себя способности формулировать и принуждать инвариант, что значение в данной конкретной точке программы должно быть целое (прим.перев. то есть не сможете рассуждать о программах вообще, а параллельное например не протестируешь. значит ошибки в ваших программах останутся навсегда. а при переменах в реализации языка даже будут появляться новые. с другой стороны, если бы не ошибки в компиляторах и библиотеках, тестирование вообще при правильном подходе было бы не нужно). Во-вторых, вы добавляете довольно приличные накладные расходы на представление самого вида (тэг какой-то разновидности) и на проверку, снятие и применение тега вида на значение каждый раз как оно используется. (Смотрите книгу ПОЯП для полного описания того что происходит.)
....