Версия для печати темы
Нажмите сюда для просмотра этой темы в оригинальном формате
Форум программистов > Философия программирования > Мощь программирвоания:


Автор: Rickert 18.2.2009, 06:35
У меня с Чипом открылась сегодня очередная дискуссия. Я утверждал, что мощь языка - это его возможности: то что он позволяет сотворить с системой/железом. А Чип считает что мощь тем больше, чем меньше человек задумывается о переводе мыслей в код, при использовании определённых языков.
С моей стороны были конечно асм/C++, а со стороны Чипа - LISP.
Что вы думаете, уважаемые коллеги?

Автор: chipset 18.2.2009, 06:44
Разница между LISP и Си такая-же как и разница между Си и ассемблером.

Автор: Rickert 18.2.2009, 07:25
Только этажом выше smile

Автор: chipset 18.2.2009, 08:35
Десятком этажей smile Это выглядит вот так:

LISP
.
.
.
Ruby
Python

.
.
.
.
.
.
.
.
.
.
C++
C
.
Assembler

Автор: Rickert 18.2.2009, 09:32
А пустые точки - это этаж, который проломили пока падали и не успели закрепиться?

Автор: skyboy 18.2.2009, 10:29
а почему нельзя выбрать оба варианта одновременно? что, если я - за компромиссы?

Автор: Rickert 18.2.2009, 11:11
skyboy, вопрос конкретный: выберите наиболе близкий вариант smile

Автор: ksili 18.2.2009, 11:29
Мощь языка - возможности

Скорость перехода мысль -> код - мощь среды разработки

Автор: Rickert 18.2.2009, 14:22
Цитата(ksili @  18.2.2009,  11:29 Найти цитируемый пост)
Скорость перехода мысль -> код - мощь среды разработки

Не согласен. Какая бы среда разработки не была, на асме всё равно придётся думать, прежде чем писать. Причём думать раза в 2 больше, чем на том же Си smile 

Автор: GoldFinch 18.2.2009, 15:02
Цитата(Rickert @ 18.2.2009,  14:22)
на асме всё равно придётся думать, прежде чем писать. Причём думать раза в 2 больше, чем на том же Си smile

если кодить вызовы функций (API и библиотечных), то на асме думать примерно столько же сколько и на С а в ряде случаев и меньше
управляющие структуры - условия и циклы на асме выглядят примерно также как и на ЯВУ
с арифметикой на асме плохо, но он не всегда и нужна, хотя целочисленая арифметика кодится быстро, а быстро кодить на FPU тоже можно научиться, по крайне мере на уровне компилятора С

код на асме может выглядеть так
Код
include 'hll2.inc'
proc Main
      local psMsg:DWORD
      FindWindowA("GcxPropertyPageSite.Window.1",0) 
        test eax,eax
        jz .err
      SetWindowPos(eax,HWND_TOPMOST,0,0,0,0,SWP_SHOWWINDOW+SWP_NOSIZE)
        test eax,eax
        jz .err
      ret
.err:
      GetLastError()
      FormatMessageA(FORMAT_MESSAGE_ALLOCATE_BUFFER+FORMAT_MESSAGE_FROM_SYSTEM+FORMAT_MESSAGE_IGNORE_INSERTS,\
            0,eax,0,psMsg,0,0)
      MessageBoxA(0,[psMsg],0,0)
      ret
endp


"test eax,eax \ jz .err" можно тоже свернуть в макрос

Добавлено через 2 минуты и 43 секунды
Цитата(chipset @  18.2.2009,  06:44 Найти цитируемый пост)
Разница между LISP и Си такая-же как и разница между Си и ассемблером. 

LISP  - функциональный ЯП, Си и асм  - императивные ЯП

Автор: chipset 18.2.2009, 18:09
Цитата(GoldFinch @  18.2.2009,  05:02 Найти цитируемый пост)
если кодить вызовы функций (API и библиотечных), то на асме думать примерно столько же сколько и на С а в ряде случаев и меньше


Угу, с высоты LISPa асм и си сливаются в один очень близкий к машине язык.

Автор: GoldFinch 18.2.2009, 19:05
chipset, вы GUI на лиспе кодите? какая еще высота? лисп вообще переводится как ЯзыкОбработкиСписков, у них совершенно разные области применения, у лиспа и С

Автор: BASILIO 18.2.2009, 20:30
Конечно же возможности, так как имея более низкие доступы к командам, мы можем ими очень гибко воспользоватся, что приведёт к увелечению скоростей и разгрузки желаза. И на оборот, вы можете взять готовые команды тех же рельс для ДБ, которые сначала похавают проц тем, что переведут всю свою мишуру в номальный сквел, а потом отравят на базу, и там его ещё раз бработает база, короче, лишния нагрузка, язык для ленивых или туповытых програмистов, как результат мега дурацкие сайты, за которые хочется "творцам" отрубать руки, как в зонах с действием законов шириата, ибо посещение таких сайтов, это тоже самое воровство, воруется время юзера, на понимание построения сайта.

Автор: chipset 18.2.2009, 20:43
Цитата(Philip Greenspun)

"Десятый закон Гринспуна о программировании: каждая достаточно сложная программа на Си или Фортране содержит неформальную, глючную, медленную реализацию половины Common LISPa."


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

Медленный? Я бы не сказал. Посмотрите последние http://shootout.alioth.debian.org/u64q/benchmark.php?test=all&lang=all&box=1. 

Я не спорю что для десктопных приложений лучше всего Си/C++ и какая-нибудь кроссплатформенная библиотека наподобие Qt. Для server-side программирования лучше взять ЛИСП вместо Явы, Питона, или даже, не побоюсь этого сравнения, PHP.

Автор: BASILIO 18.2.2009, 20:45
chipset, ок, тогда такой вопрос: почему гугл пользуется в основном своим софтом и только изредка прибегают к уже готовому?

Автор: chipset 18.2.2009, 21:43
Цитата(BASILIO @  18.2.2009,  10:45 Найти цитируемый пост)
chipset, ок, тогда такой вопрос: почему гугл пользуется в основном своим софтом и только изредка прибегают к уже готовому?


У гугла сотни девелоперов. Для  таких больших компаний нужно использовать максимально читабельные языки вроде Питона или Явы (что гугл и делает собственно).

Автор: BASILIO 18.2.2009, 22:57
chipset, ты ушёл от ответа, я спросил о другом, они используют питоны да явы, в местах не столь важных, вроде их ФАКов, а вот для поисковика, и многих других служб, у них собственые разработки.

Автор: chipset 19.2.2009, 00:15
Цитата(BASILIO @ 18.2.2009,  12:57)
chipset, ты ушёл от ответа, я спросил о другом, они используют питоны да явы, в местах не столь важных, вроде их ФАКов, а вот для поисковика, и многих других служб, у них собственые разработки.

При чем тут вообще Гугл? Если гугл написал для себя вебсервер, то что, для каждого нового сайта надо писать с нуля на асме, HTTP вебсервер?

Откуда я знаю зачем они пишут собственные разработки? Возможно потому-что у них сильно большая нагрузка, и они вытачивают каждый байт чтобы было очень быстро. Я тебе говорю про то что ЛИСП это язык в котором можно все и что он мощен, а как Гугл  разрабатывающий собственный софт относится к этому?

Автор: BASILIO 19.2.2009, 08:34
chipset, я привёл гугл в пример, так как он подходит под тему первого поста, они забили на высокие языки, и вернулись к низко уровневым, стоит задуматся ;)

Автор: Shaggie 19.2.2009, 09:08
Цитата(BASILIO @  18.2.2009,  20:30 Найти цитируемый пост)
имея более низкие доступы к командам, мы можем ими очень гибко воспользоватся, что приведёт к увелечению скоростей и разгрузки желаза.

Пока количество оптимизаций не начинает выходить за пределы возможностей программиста, как в случае с современными процессорами - человек в 99% случаев не напишет машинный код, использующий возможности машины эффективнее кода, сгенерированного компилятором. Мы же не про хелловорлд говорим?

Автор: chipset 19.2.2009, 09:32
Цитата(BASILIO @  18.2.2009,  22:34 Найти цитируемый пост)
chipset, я привёл гугл в пример, так как он подходит под тему первого поста, они забили на высокие языки, и вернулись к низко уровневым, стоит задуматся ;)

На какие языки они забили и к каким языкам они вернулись?

Автор: bilbobagginz 19.2.2009, 11:22
Цитата(BASILIO @  19.2.2009,  08:34 Найти цитируемый пост)
они забили на высокие языки, и вернулись к низко уровневым, стоит задуматся ;) 

вот давай и задумаемся вместе: 
гугл начал с того, что не хотел покупать т.н. "supercomputer", т.к. это было НЕРЕНТАБЕЛЬНО. 
что сделал гугл - снимал дешевые гаражи, накупал тонны ящичков первого звена PC, придумал хитрый механизм распределенного деплоймента, т.е. распределенную инфраструктуру, и соединил все эти гаражи быстрым каналом. И получил дешевый "недосуперкомпьютер".
А потом на основе данной инфраструктуры пришел к выводу, что на сэкономленные деньги имеет смысл зашкодить свой, PC-ориентированный сервер, обходя грабли apache и lighttpd, но еще не стоит покупать настоящий Cray или как их там мать мать мать. ну и что ?

и всё равно большинство разработок в гугле - на python. 
И на LISP тоже пишут. Но ввиду того, что на лиспе просто не так уж много профессионалов, бОльшей популярностью пользуются питоны. 
и не Си, и на ассемблер.

На чём написаны их клиентские приложения - chrome, earth, и т.д. ? на asm ?

chipset, IMHO даже очень прав в том, что LISP действительно недопопуляризированный язык с недоиспользованными возможностями. Может быть из-за того, что на нем меньше прикладных модулей, чем на других скриптовых языках.

Цитата(GoldFinch @  18.2.2009,  19:05 Найти цитируемый пост)
chipset, вы GUI на лиспе кодите? какая еще высота? лисп вообще переводится как ЯзыкОбработкиСписков, у них совершенно разные области применения, у лиспа и С 

Да, кстати, List - это структура данных, в которой может быть всё что хочешь, даже дерево ;-),  а не тупо "список" в контексте "некоторый текст".
список объектов, список списков объектов, и т.д.

А насчет чем язык "мощнее"  я не могу участвовать в споре о крокодиле:
что в нём "мощнее" то, что он зелёный, или что длинный ?

Автор: chipset 20.2.2009, 07:14
Цитата(bilbobagginz @  19.2.2009,  01:22 Найти цитируемый пост)
chipset, IMHO даже очень прав в том, что LISP действительно недопопуляризированный язык с недоиспользованными возможностями. Может быть из-за того, что на нем меньше прикладных модулей, чем на других скриптовых языках.


Уже нет. Диалект Clojure компилируется в байткод JVM. Т.е. Hibernate, Struts, JSF, JAX-WS, даже Rails скомпилированные JRubyем -- могут юзаться из лиспа.

ВЕЛИК ЛИСП

Автор: ksili 20.2.2009, 08:15
Цитата(chipset @  20.2.2009,  11:14 Найти цитируемый пост)
ВЕЛИК ЛИСП

но об этом почти никто не знает

Автор: Pointer 20.2.2009, 11:09
Я думаю мощь языка разработки заключается в соединении этих двух свойств "Возможности" и "Скорость перехода мысль -> код" и насколько язык удобнее позволяет все это задействовать в своей программе, тем он шире используется и мощнее.
Если посмотреть на С++, он наиболее пока развит в этом отношении....может я просто не видел ничего другого...?
Вообще мне кажется что в выборе языка разработки действуют тот же принцип "Естественного отбора" что и в природе, наиболее понятные и приспособленные под общие задачи приживаются, на остальных кодят мало и специфические программы....smile

P.S Где-то видел справочник....там около 2000 языков программирования, но в процессе "эволюции" они отсеялись...smile

Автор: Shaggie 20.2.2009, 14:51
user posted image

Автор: chipset 20.2.2009, 23:55
Цитата(Pointer @  20.2.2009,  01:09 Найти цитируемый пост)
Вообще мне кажется что в выборе языка разработки действуют тот же принцип "Естественного отбора" что и в природе, наиболее понятные и приспособленные под общие задачи приживаются, на остальных кодят мало и специфические программы....


Скорее какой язык продвинут компании маркетингом.

Автор: Rickert 21.2.2009, 08:19
chipset, не согласен smile
Сколько бы не толкали великие брэнды - всё равно, если отстой, не будут пользоваться. Отличный пример игра F.E.A.R.

Автор: Rickert 19.3.2009, 09:33
Вообще - ничья smile 

Автор: ksili 19.3.2009, 09:35
Цитата(Rickert @  19.3.2009,  13:33 Найти цитируемый пост)
Вообще - ничья

Ну это ты подождал, пока все отвернутся и флэшмобнул... А так, наши выигрывали!  smile  smile 

Автор: Rickert 19.3.2009, 10:16
0) Как это я мог флэшмобнуть? smile 
1) Кто это - наши? smile 

Автор: ksili 19.3.2009, 10:28
Цитата(Rickert @  19.3.2009,  14:16 Найти цитируемый пост)
1) Кто это - наши?

наши это те, кто голосовал за тот же пункт, что и я  smile 

Автор: Rickert 19.3.2009, 13:42
А это какой?

Автор: ksili 19.3.2009, 14:18
Цитата(Rickert @  19.3.2009,  17:42 Найти цитируемый пост)
А это какой?

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

Автор: Rickert 19.3.2009, 16:11
ksili, по-принципу чтоб задолбаться smile 

Powered by Invision Power Board (http://www.invisionboard.com)
© Invision Power Services (http://www.invisionpower.com)