LINUX.ORG.RU

почему Си самый гибкий язык?


0

0

Считается почему-то что Си самый гибкий язык, и любую прогамму какую
можно теоритически написать, можно написать и на Си, а значит если есть
Си то нет никакого смысла писать на чем-нибудь другом. А по-моему гибче
всего ЛИСП, потому что на нем можно любой другой язык написать, а значит
и любую программу.

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

anonymous

Однако, интерпретаторы ЛИСПа все на Це написаны.

Ничего не звенит? :-)

Вообще-то, тема -- для Talks'ов.

Die-Hard ★★★★★
()
Ответ на: комментарий от Die-Hard

> Однако, интерпретаторы ЛИСПа все на Це написаны.

Фигня. Интертрепаторы лиспа написаны на лиспе. А вот gcc как раз компилирует Си, используя лиспообразное промежуточное представление.

anonymous
()

Этто Вам, батенька, ассемблер нужен.

anonymous
()

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

kraw ★★★★
()
Ответ на: комментарий от eXOR

1. >маразм.

согласен

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


2. см. 1

carrot
()
Ответ на: комментарий от Die-Hard

Na C pisany runtime, a kompiliatory - na samom Lispe. Tak chto ne swisti.

anonymous
()

Лисп хорош для решения каких-то определённых задач, а Си универсален.

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

anonymous
()

Смотря как что понимать.

На любом языке можно написать всё что угодно. Что, из этого выходит, что все языки одинаково гибки? Или что в этом контексте тогда понимать под гибкостью,

wieker ★★
()
Ответ на: Смотря как что понимать. от wieker

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

Дорогому анониму,
любой язык (компилятор, интерпретатор), как программа -
это на 90% (могу ошибаться) parser.

Я не думаю, что LISP удобен для написания "parsing program".
Время от времени появляются библиотеки, программы, языки,
чья специализация написание других языков. Пример - lex и yacc.

В этом смысле утверждение - "гибче всего ЛИСП, потому что на нем
можно любой другой язык написать", ну, не очень "корректное".

Будьте здоровы. Марк

++
Спасибо за ссылку.

carrot
()
Ответ на: комментарий от carrot

>> А по-моему гибче всего ЛИСП, потому что на нем можно

>> любой другой язык написать, а значит

>> и любую программу.



> Дорогому анониму,

> любой язык (компилятор, интерпретатор), как программа -

> это на 90% (могу ошибаться) parser.



нет, я бы перефразировал .. 1-10% любого компилятора/интерпритатора

это парсер, осатальное это трансляция семантической структуры в RTL а

дальше основная работф компилятора происходит в терминах RTL .. тоесть

реально 70-90% компилятора это работа с RTL ..

                                                                                                   

> Я не думаю, что LISP удобен для написания "parsing program".

> Время от времени появляются библиотеки, программы, языки,

> чья специализация написание других языков. Пример - lex и yacc.



один из языков наиболее удобных для написания парсеров - lisp.  Ты не

можешь написать ничего стоящего _тоьлко_ в терминах lex&yacc, ты

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

код .. так вот один из наиболее удобных языков окажется lisp

.. lex&yacc это просто техника, они не привязаны к языку .. с таким же

успехом можно пользовать эту технику для генерации lispa ..



> В этом смысле утверждение - "гибче всего ЛИСП, потому что на нем

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



нет, *не* в этом смысле, но утверждать что lisp идеально гибкий язык

тоже не правильно ..



кстати, не забывай что gccшный RTL - это не что иное как диалект лиспа

:)



lisp один из гибчайших и мощнейших языков программирования общего

назначения ..

lg ★★
()
Ответ на: комментарий от carrot

>> А по-моему гибче всего ЛИСП, потому что на нем можно
>> любой другой язык написать, а значит
>> и любую программу.
                                                                                                   
> Дорогому анониму,
> любой язык (компилятор, интерпретатор), как программа -
> это на 90% (могу ошибаться) parser.

нет, я бы перефразировал .. 1-10% любого компилятора/интерпритатора
это парсер, осатальное это трансляция семантической структуры в RTL а
дальше основная работф компилятора происходит в терминах RTL .. тоесть
реально 70-90% компилятора это работа с RTL ..
                                                                                                   
> Я не думаю, что LISP удобен для написания "parsing program".
> Время от времени появляются библиотеки, программы, языки,
> чья специализация написание других языков. Пример - lex и yacc.

один из языков наиболее удобных для написания парсеров - lisp.  Ты не
можешь написать ничего стоящего _тоьлко_ в терминах lex&yacc, ты
неизбежно будешь пользовать конструкции языка на котором они генерят
код .. так вот один из наиболее удобных языков окажется lisp
.. lex&yacc это просто техника, они не привязаны к языку .. с таким же
успехом можно пользовать эту технику для генерации lispa ..

> В этом смысле утверждение - "гибче всего ЛИСП, потому что на нем
> можно любой другой язык написать", ну, не очень "корректное".

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

кстати, не забывай что gccшный RTL - это не что иное как диалект лиспа
:)

lisp один из гибчайших и мощнейших языков программирования общего
назначения ..

lg ★★
()
Ответ на: комментарий от lg

2lg.

Как всегда, изложил доходчиво, спасибо.

Вопрос - "почему Си самый гибкий язык?", конечно
провокационный, который "Как всегда" порождает
Траянские войны ("Holy wars"), "у кого толще, а у кого длинее",
все эти детские споры "какая группа лучше?" ..

На самом, деле вопрос надо было ставить -
- "Зачем задвинули(гают) ЛИСП?".
- "Почему такой гибкий язык оказался "невостребованным"?"

Было бы интересно услышать мнение самого автора поста.

anonymous
()
Ответ на: комментарий от anonymous

... я и сам, неожиданно, записался к врачу как anonymous :-(

carrot
()
Ответ на: комментарий от carrot

Ты очень сильно ошибаешься. Сразу видно, что ни компиляторов, ни интерпретаторов ты не писал. Ещё раз - читать статью, на которую тут была ссылка. Ну и смотреть на софт - http://dslengine.sourceforge.net/

anonymous
()
Ответ на: комментарий от anonymous

http://www.paulgraham.com/ - там очень доходчиво описано, почему Лисп невостребован быдлом, в отличии от всяких там разрекламированных ерундовин в красочных упаковках, таких, как Жаба или C++.

anonymous
()
Ответ на: комментарий от anonymous

Вот только для Java и C++ уйма библиотек и горы наработанного опыта аккуратного хождения по граблям языка и концепций (типа ООП). И этого у них не отнять.

ИМХО, для каких-то задач большую роль играют библиотеки, для каких-то - язык.

WFrag ★★★★
()
Ответ на: комментарий от WFrag

И кто тебе мешает использовать библиотеки Жабы из Лиспа? Библиотеки - не аргумент. Единственный аргумент у сторонников Жабы - это их безмозглость. Типа, Лисп якобы слишком сложный для них, глупеньких, вот и не желают его изучать.

anonymous
()
Ответ на: комментарий от anonymous

Раз такой умный, поделись знанием.

Пишу проект, как плагин к Eclipse. Это обязательное условие - не хочу заново изобретать велосипеды и костыли для ООП/КОП, в Eclipse многие вещи уже хорошо проработаны. Как мне туда Lisp прикрутить? Пока что лучшая альтернатива, что я вижу - это Jython. Правда, мне в Python-е динамическая типизация не устраивает, но есть надежда, что можно попробовать применить ядренную смесь Java и Jython-а :)

Еще одна штука, которую, наверное, можно было бы попробовать - это Bigloo. Но он достаточно своеобразен - сложно сказать, насколько легко его будет задействовать.

То есть условие простое - язык работает на JVM.

>Единственный аргумент у сторонников Жабы

Не надо фанатизма. Развелось, блин, дерьмовых ясновидцев.

WFrag ★★★★
()
Ответ на: комментарий от WFrag

SISC - очень шустрый и качественный. Kawa - работает, хоть и не без косяков, достаточно быстрая.

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

anonymous
()
Ответ на: комментарий от WFrag

P.S. про Bigloo - очень даже можно использовать, единственный косяк - это то, что сам компилятор отдельно (не под JVM) - теоретически собрать и под JVM можно, но на практике - никто этого не делал. В то же время, REPL евонный под JVM отлично работает. Существенный плюс Bigloo - хорошие родные библиотеки, довольно таки удобный FFI к Жабе (хоть и хуже, чем в SISC), очень хорошая система модулей и качественные макры. Я как правило под JVM использую именно Bigloo, хотя, по некоторым причинам, иногда был вынужден и Kawa юзать. Если намерения использовать хорошие языки под JVM серьёзные - могу помочь советами, если не в падлу будет.

anonymous
()
Ответ на: комментарий от anonymous

> Сразу видно, что ни компиляторов, ни интерпретаторов ты не писал

заранее извиняюсь, конечно, это "пере-палка" ..
Но просто, интересно, какой компилятор/интерпретатор
писал/написал многоуважаемый аноним.

carrot
()
Ответ на: комментарий от anonymous

>P.S. про Bigloo - очень даже можно использовать, единственный косяк - это то, что сам компилятор отдельно

Ну, например, в нем call/cc покоцанный.

WFrag ★★★★
()
Ответ на: комментарий от anonymous

>Лучше SISC - у него макры корректно поддерживаются. Интерфейс к Жабе - идеальный, никаких промежуточных прослоек делать не надо. И всё это ты легко мог бы узнать гуглением - так что, мой тезис о малограмотности жабописцев ты подтвердил.

Честно пионерское, первый раз слышу, хотя специально искал языки для JVM...

WFrag ★★★★
()
Ответ на: комментарий от WFrag

Не с той стороны искал - надо было искать реализации Схемы. ;)

anonymous
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.