LINUX.ORG.RU

Пук!

(больше слов на это все не нашлось у меня)

deep-purple ★★★★★
()

Интересный сайтик, однако (я про движок - это пожалуй стоит посмотреть).

А вопрос сам по себе дурацкий до безобразия.

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

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

deep-purple ★★★★★
()
Ответ на: комментарий от Bad_ptr

OCHE TOLSTO

functional-programming-is-not-useful
vim-is-better-than-emacs
python-is-better-than-ruby

OCHE TOLSTO

computer-science-is-not-actually-a-science

Сасман с этого тезиса начинает лекцию SICP.

Camel ★★★★★
()
Ответ на: OCHE TOLSTO от Camel

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

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

адекватного спора

Сама постановка вопроса идиотская. О чем спорить-то?

kirk_johnson ★☆
()

у холиварщиков теперь еще и тулза появилась ))))). Отрицать ФП (или отказываться) ровнозначно как если бы мы не признавали эволюцию. Идиотизм же. Все языки эволюционируют в сторону ФП ибо сложность систем растет, а ресурсы человеческие нет. Посему обрастаем абстракциями и шаблонами. Кому не нравится, могут обратно деградировать в сторону ассемблера.

Deleted
()

Очень интересная тулза для дискуссий. Хотя сайт пока набит говном на 100%.

ptarh ★★★★★
()

Интересный сайт. Хочется русский раздел.

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

Необсуждаемо

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

Идея интересная, но изначально провальная. Вопрос что лучше, моча или говно, изначально религиозный, а значит никакие доводы в нём не могут считаться верными.

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

Троллесрач

Очень интересная тулза для дискуссий. Хотя сайт пока набит говном на 100%.

Этот сайт обречён быть набитым говном именно из-за тулзы. Ничего кроме генерации троллесрачных заголовков этот сайт не породит.

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

Если программа хорошо работает - какая разница, на чем она там написана?

Разница возникает, когда надо найти людей, способных понять исходый код этой самой программы, и что-то доработать/поменять. Или если возникает потребность запускать программу на некоей архитектуре, а компилятор/интерпретатор/среда_исполнения не поддеживает такую архитектуру вообще, или не поддерживает достаточно хорошо(генерирует медленный код например). Программы на языках с жирной средой выполнения (.NET, JVM, Node.JS etc) тратят ресурсы процессора и дополнительную память (сборка мусора там всякая, JIT). Задержки, возникающие при сборке мусора, могут быть критичны для некоторых применений, когда требуется реалтаймовость.
Или противополжный случай. Если программа написана на ассемблере, у нее будет околонулевая переносимость, что тоже плохо.

Так что есть случаи, когда то, на чем программа написана, имеет большое значение

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

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

Для тебя, наверное, это будет шоком, но существуют системы реального времени со сборкой мусора. Начиная от Erlang (да-да, его ради soft real-time приложений и создавали) и заканчивая жабой.

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

Разница возникает, когда надо найти людей, способных понять исходый код этой самой программы, и что-то доработать/поменять. Или если возникает потребность запускать программу на некоей архитектуре, а компилятор/интерпретатор/среда_исполнения не поддеживает такую архитектуру вообще, или не поддерживает достаточно хорошо(генерирует медленный код например). Программы на языках с жирной средой выполнения (.NET, JVM, Node.JS etc) тратят ресурсы процессора и дополнительную память (сборка мусора там всякая, JIT). Задержки, возникающие при сборке мусора, могут быть критичны для некоторых применений, когда требуется реалтаймовость.

Если компилятор не поддерживает архитектуру - программа у тебя не работает. Я же говорил о том, что если она работает - тебе, в целом, пофиг.

kirk_johnson ★☆
()
Ответ на: Необсуждаемо от Camel

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

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

а вот это уже реально жирно было

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

Для тебя, наверное, это будет шоком, но существуют системы реального времени со сборкой мусора. Начиная от Erlang (да-да, его ради soft real-time приложений и создавали) и заканчивая жабой.

Нет, не будет. Насчет Erlang не знаю, а что касается Java, то для жабы там есть Jrockit с этим самым GC для реалтайма, так там говорили о каком-то огромном оверхеде по сравнению с классическим сборщиком мусора (да, там такая опция есть XpauseTarget - которая выставляет время, разрешенное под сборку мусора) но это все костыли, надо для таких задач выбирать другой инстумент

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

Если компилятор не поддерживает архитектуру - программа у тебя не работает. Я же говорил о том, что если она работает - тебе, в целом, пофиг.

Где-то(на мощном железе с кучей RAM и мощным процессором, под который компилятор хорошо заточен) программа работает, но возникла необходимость заставить ее работать на другой архитектуре - а она не работает или работает плохо. Так что если предполагается в будущем использовать программу не только на мощном ширпотребном железе(вроде x86-64), имеет смысл выбирать правильный язык, а не писать на чем попало.

SZT ★★★★★
()

Занятный сайт.

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

У меня есть знакомцы, которые свой код на хацкеле в production примерно по такому принципу пихают. Как ни странно, с этими кодом проблем обычно нет.

kirk_johnson ★☆
()

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

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

так написано на этом сайте,если я правильно понял

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

Насчет Erlang не знаю

Сходи и узнай же.

для жабы там есть Jrockit с этим самым GC для реалтайма, так там говорили о каком-то огромном оверхеде по сравнению с классическим сборщиком мусора (да, там такая опция есть XpauseTarget - которая выставляет время, разрешенное под сборку мусора) но это все костыли

Почему костыли? Сборка мусора в отведённый период укладывается? Укладывается. Другие задачи время получают? Получают. Вот тебе и реальное время.

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

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

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

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

Это и есть более подходящие инструменты. Они позволяют сэкономить на управлении памяти и трудозатратах со стороны программиста.

И в микроконтроллер это не засунуть.

Смотря какой контроллер. Во многие - без проблем.

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

Это и есть более подходящие инструменты. Они позволяют сэкономить на управлении памяти и трудозатратах со стороны программиста.

Подходящие для кого/чего? Это более подходящие инструменты, если нам проще на тяп-ляп сделать побыстрее программную часть(не тратя время на ручное управление памятью), только потом на аппаратную часть придется раскошелиться (больше памяти и быстрее контроллер, чтобы он этот GC успевал пережевывать c сохранением реалтаймовости).

Смотря какой контроллер. Во многие - без проблем.

Многие это какие? Atmega16 потянет?

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