LINUX.ORG.RU

Haskell VS Common Lisp VS OCaml VS Scheme VS Scala VS Clojure


0

1

Небольшой троллинг на тему «что лучше» и в то же время тема для помощи, тем, кто хочет сделать выбор в пользу одного из ФЯ. Я свой выбор сделал в сторону Haskell, т.к. он на мой взгляд более функционально чистый и является языком с прекрасной системой типов. Вы что считаете лучше и почему?

Ответ на: комментарий от siberean

> Ну при чём тут Plan 9 и 9p?

Им нужно отредактировать свои отчёты из домашнего комфорта (в последний момент) или с любого компа с работы, работая с одной копией, возможно группой.

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

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

И при чём здесь план?

при том, что он позволял организовать такую инфраструктуру 20 лет назад.

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

> я конечно могу не понимать - что такое план9 и как реализовать прозрачную коллаборативную работу с документами через план9 для удалённых пользоватей, большинство из которых имеют венду и браузер (фаерфокс можно потребовать установить на крайняк: не сложно).

Объясни тогда.

в план9 для приложений нет разницы между сетевыми и локальными ресурсами. при этом любые ресурсы представленны в виде файлов, отдельные окна оконной подсистемы например и прочее

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

> в план9 для приложений нет разницы между сетевыми и локальными

ресурсами. при этом любые ресурсы представленны в виде файлов,

отдельные окна оконной подсистемы например и прочее



Странно, почему ты не понимаешь, что это абсолютно не может быть никакой альтернативой web, а твое противопоставление просто абсурдно.

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

Ну ведь _эволюция_ - выбирает.
Много вещей было хороших. Но вот пошла tcp/ip а не OSI модель, которую я например учил в универе. Не SGML, а урезанный хмл. Не Х.500 - а LDAP, не справедливый абстрактый коммуннизм, а алчный но работающий капитализм итд.
Я тоже хотел бы видеть Хы и помогал бы секретаршам с «xhost bla-bla-bla» и «export DISPLAY=bla-bla-bla:0.0», но увы и ах.

Надо фиксить то что есть в реале и то что уже широко работает.

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

> Странно, почему ты не понимаешь, что это абсолютно не может быть никакой альтернативой web, а твое противопоставление просто абсурдно.

странно, почему ты не понимаешь, что веб к этому стремится, а твои замечания абсолютно бессмысленны

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

Нет, я завязываю с тобой общаться, удачи тебе с plan9.

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

> странно, почему ты не понимаешь, что веб к этому стремится, а твои замечания абсолютно бессмысленны

Как веб (html + css + js + php/python/java) - средства разработки клиентских интерфейсов и серверной части могут противостоять 9p - протоколу распределенной файловой системы, тобишь протоколу общения сервера и клиента? Это же совершенно ортогональные вещи - тот же html + css + js можно гонять по любому протоколу, какому хочешь - хочешь 9p, хочешь свой пиши, только сделай для него свой 9p-сервер и свой 9p-браузер-клиент. Если уже сравнить, то сравнивать 9p с http + httpd + ff/ie/opera/safari.

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

>никаких сегфаултов

Ну конечно, ошибки в жабоскрипте и тормоза интерфейса при проблемах с каналом связи это намного лучше! (* sarcasm *)

И ещё куча негромких «непуков»

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

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

На мобилках у двануля весьма сомнительное будущее. Причина проста: батарейки надо экономить и использовать нативный гуй. Именно для мобилок пишется и продается основная часть «клиентов для социальных сетей».

такая модель может работать и просто на localhost

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

Опять - «И ещё вопрос что удобнее»

Удобнее всегда то, к чему ты привык. Мне, к примеру, плюсы на порядок удобнее питона, отсюда и вопрос про жабоскриптеров. Те, кто писал мало-мальски сложный нативный гуй и имеют опыт небольших сношений с жобоскриптом понимают, что на жобоскрипте легко и приятно лепить разве что демки для жквери. Серьезное приложение, удобное и интенсивно общающееся с внешними источниками данных писать на жабоскрипте ой как геморно, потому что все, что умеет жабоскрипт — это XMLHTTPRequest и парсить json.

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

> Те, кто писал мало-мальски сложный нативный гуй и имеют опыт

небольших сношений с жобоскриптом понимают, что на жобоскрипте легко

и приятно лепить разве что демки для жквери.



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

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

> XMLHTTPRequest и парсить json.

а что ещё надо?
Есть механизм притаскивания _любой_ даты с сервера. Сервер снабжает любой датой через простой и быстрый REST. Далее есть компоненты фреймвоков типа yui, из которых можно налепить что угодно (только квалификацию надо иметь соответствующую).

Я не понимаю - о какой такой абстрактной нативной аппликации говорится.
Возьмём даже репозиторий букмарков. Где хранить базу? Как синхронизовать 2 инстанса этой базы на 2х компьютерах? Итд. И в нативной аппликации постепенно появится и клиент-сервер и аналог XMLHTTPRequest и json'а. Так какая разница? Придётся ещё парится с лейаутами, теми же табами - в не меньшей степени итд. Как дистрибутить нативную аппликацию и проверять автоматически версии и делать патчи на лету? Браузер наоборот - упрощает все эти вещи.
Мне когда-то очень давно тоже нативные аппликации казались проще, лет 12 назад. Но с ними - не меньше проблем, поверь мне - когда таблицы будут такими же сложными, когда будут деревья, таблицы, подмена панелей на лету итд итп, т.е. функциональность аутлука, например. Времена меняются.

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

XMLHTTPRequest, json и REST - это комманд-лайн веба.
А нам как юниксоидам известно - что командные (посикс) строки (+возможность передать дату в файлах) - дают возможность делать всё что угодно.
Поэтому кроме XMLHTTPRequest и сложнее его - ничего не надо.
И сложность таким макаром легко разгребается - если всё дробить на простые реквесты (как это ещё 6 лет назад делалось с формами).

Так что твой аргумент - это не недостаток, а достоинство, как и в случае с «всё есть файл» и командными строками - в юниксах.

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

Внезапно: канал связи должен быть быстрым, а js - без ошибок :) Там же не низкоуровневая лапша, а функциональный язык, довольно мощный, да и большинство типовых задач решены во всяких джекуери.

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

Ну посмотрим что будет ещё через два года. Тенденция всё-таки.

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

Ну а если веб-приложения трансформируются во что-то другое? Например, X-ы же работают по такой схеме. Вот представь - возьмёт гугл ядро linux, поставит на железо с обычной видео-картой, X-ы ставить не будет, напишет backend к webkit который будет рисовать прямо в видео-буфер и запустит веб-сервер с песевдо-оконной веб-ОС :) Сколько людей большую часть виртуального времени сидит в «моё лицо» и двигает псевдо окошки в гугло-серверах - будут покупать гугло панели.

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

> Ну а если веб-приложения трансформируются во что-то другое? Например, X-ы же работают по такой схеме. Вот представь - возьмёт гугл ядро linux, поставит на железо с обычной видео-картой, X-ы ставить не будет, напишет backend к webkit который будет рисовать прямо в видео-буфер и запустит веб-сервер с песевдо-оконной веб-ОС :) Сколько людей большую часть виртуального времени сидит в «моё лицо» и двигает псевдо окошки в гугло-серверах - будут покупать гугло панели.

ну то есть тупо изобретёт 9p и Rio, причём костыльно и урезано

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

ну то есть тупо изобретёт 9p и Rio, причём костыльно и урезано

Вот ассемблеры, cc и системные библиотеки из Plan9/Inferno Google уже утащила в Go. То что Робу Пайку свойственно создавать по языку программирования каждые десять лет - понятное дело :) Но гуглу зачем-то было нужно делать Go - вот мне кажется, что если бы у них была подобная мотивация, они бы и 9p продвигали, но почему-то вместо этого двигают обычный веб - почему? У них ведь есть какое-то своё видение предмета. Может 9p это передний край, а может proof of concept, в то время как «костыли» - вайдли юзед.

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

> почему?

это же очевидно — миллиарды тон интернетов

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