Язык будущего?

А еще она сишку и асм обскакивает.

Не, этих только по уровню оплаты труда делает.

 auto x = my_str + 5; [br][/quote]а auto some_func(auto a, auto b) уже можно? polymorphic lambda уже можно?

[quote] Иными словами, по определению, это банальный switch. Он ещё в Сишке есть.[br][/quote]А ты попробуй дальше википедии посмотреть

[quote] зачем оно надо? ну держите, раз жить без этого не можете http://habrahabr.ru/post/85718/[br][/quote]зачем чесать ухо ногой? 

ну и полиморфный вариант для каррирования выкладывай.

auto x = my_str + 5;

а auto some_func(auto a, auto b) уже можно? polymorphic lambda уже можно?

Иными словами, по определению, это банальный switch. Он ещё в Сишке есть.

А ты попробуй дальше википедии посмотреть

зачем оно надо? ну держите, раз жить без этого не можете http://habrahabr.ru/post/85718/

зачем чесать ухо ногой?

ну и полиморфный вариант для каррирования выкладывай.

//FIXED

плюс за солидарность.

Я думаю, в будущем всеми силами будут стараться отказаться от такого явления, как «язык программирования». Что является идеальным условным компилятором? Это софтина, которая принимает на вход файл ТЗ от заказчика (как правило, неотформатированный docx-документ с кучей орфографических ошибок), парсит его, улавливает суть и выдает на выходе exe-файл с программой, реализующей желание заказчика. Понятно, что это утопия, вот и придумали кучу разных языков программирования, дабы можно было перевести требования на понятный компьютеру язык.

Вижу я, что всё движется к тому, что ЯП перестануть быть текстовыми, а будут графическими, а программы будут строиться по принципу drag-and-drop и напоминать UML-диаграммы. Компоненты будут надежно оттестированы и доступны из единого репозитория и, возможно, часть из них будет реализована на ЯП более низкого уровня (речь идет не о корчащемся в предсмертых муках Си, а о чем-нибудь вроде Haskell). Писать, а вернее рисовать программы будут люди, лучше всего знакомые с предментной областью. Исчезнут понятия «Java-программист» или «PHP-программист», вместо них придут «программисты-банкиры», «программисты-врачи» и т.д.

Ты не понимаешь разницы между анализом и синтезом, например. Вот тебе простейшее тз: на вход программа получает набор чисел, нужно отсортировать и вывести. Если программист не заложет в твой язык алгоритм сортировки, то как твой язык его выдумает?

Вижу я, что всё движется к тому, что ЯП перестануть быть текстовыми, а будут графическими, а программы будут строиться по принципу drag-and-drop и напоминать UML-диаграммы.

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

Годный тред. Читается, как ненаучная фантастика.

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

Ну так это и правильно же

Вот тебе простейшее тз: на вход программа получает набор чисел, нужно отсортировать и вывести.

Как думаешь, в реальной жизни встречаются такие ТЗ?

Ты заблуждаешься. Причём сильно.

Уж не с RSDN-а ли ты свалился? :)

auto some_func(auto a, auto b) уже можно?

(auto a, auto b) — 100 лет как, называется «шаблоны», но оно, правда, не реализует методы выстрела себе в ногу на пустом месте(слабую типизацию)

auto some_func — недавно стало можно, через decltype

зачем чесать ухо ногой?

вот и я спрашиваю: зачем нужны ленивые вычисления? простейший вариант, для чего они могут быть нужны ещё в сишке работает if(func1() && func1()), поэтому и спросил, зачем они нужны в общем случае?

ну и полиморфный вариант для каррирования выкладывай.

загуглите. мне лень.

Так получилось. Мне срочно нужно было родить что-то интерфейсно-кроссплатформенное, а дома как раз валяется книжка по Джава-2 (когда-то ходил на курсы).

Хохма в том, что софтина, ради которой принял столько героических мук, взлетела в итоге в другой конторе =)

Если бы знал, что так будет, делал бы на Сишечке.

А вот Пайтон курится нормально. То есть Джава очевидно не моё.

Пример модельный, что бы показать идею. В реальной жизни ТЗ гораздо сложнее.

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

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

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

В реальной жизни ТЗ гораздо сложнее.

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

хипстота — не годится для более-менее крупных проектов

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

Ты только конкретными примерами мыслить умеешь? Ладно, давай разжую: в более сложном ТЗ будут и свои более сложные задачи, которые не имеют простого решения вроде подстановки готового кубика. Реализация такого языка программирования равнозначна реализации полноценного искуственного разума. В теории такое возможно, вот только ученые понятия не имеют как его создать и тем более не имеют понятия какие это будет иметь последствия. Может тогда и людей не будет и программы некому и не для кого будет писать.

Это иллюстрация того, что в разных окружениях требуется знать сильно разное.

В реальной жизни ТЗ может быть наванговано оналитегом на основе глубокого пронзания как раз такого вот пожелания заказчика :) (Конверсия форматов биржевых систем при интеграции довольно часто сводится к чему-то подобному: маппинг из одних полей в другие, плюс дампы куда-нибудь в csv - технически задача очень простая :) Но без знания бизнес-значений этих полей и правил маппинга (100500 общих + кастомные «расширения», заточенные под серьезный бизнес заказчика, у каждого из которых «суслик != суслик», либо «суслик есть, но мы его явно не передаем»)) «все становится не так однозначно».

Скорее то, что вместо winapi будет posix+граф.фреймворк основные функции которых надо ещё в голову уложить, чтобы каждый раз в man не бегать.

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

Да, этот пример гораздо лучше.

Ладно, давай разжую: в более сложном ТЗ будут и свои более сложные задачи, которые не имеют простого решения вроде подстановки готового кубика.

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

Но без знания бизнес-значений этих полей и правил маппинга

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

Насчёт деплоинга подробнее не скажу, пока собираю через lein uberjar. Неуклюжий способ, в продвинутые пока не въезжал. А насчёт разработки, так там кложура ведёт себя как обыкновенная скриптота, точнее, компилит изменения и встраивает в образ, а при косяке просто откатывает своё состояние на предыдущее. Иной раз так морозится, что даже позитивные правки кода игнорит, не то, что те, которые ведут к ошибке. Решается запуском точки входа в repl с ключом :reload.

скоро на Русском языке будем код писать

Хватит припираться, ты понял о чем я. Ну или точно тебе архитектором не быть. Заренее кубиков на все случаи нет. Кто-то должен придумать кубик. И я не думаю, я знаю, что программирование состоит в основном из неповторяющихся задач. Все повторяющиеся уже сто лет реализовано в библиотеках. Тот, кто занимается рутиной - просто тупая мразь, которая не умеет переиспользовать код, про создание новых кубиков я уже молчу, куда им. Но мы же не будем потуги идиотиков называть программированием?

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

Сахарка хотелось бы, хотя-бы то что есть в java

for(int index : tmp){
                world.destroyBody(pBalls.get(index).body);
                pBalls.remove(index);
            }

вот и я спрашиваю: зачем нужны ленивые вычисления? простейший вариант, для чего они могут быть нужны ещё в сишке работает if(func1() && func1()), поэтому и спросил, зачем они нужны в общем случае?

потому что в общем случае тот крэп что ты привел, не работает:

bool b = false;

auto f1 = [&] () -> { return b; }
auto stupid_lazy_func = calc_once(f1);

bool ret = stupid_lazy_func();

b = true;

assert(f1() == ret);

а что будет если в лямбду затянут объект со стека а результат calc_func(...) возвращен из функции?

загуглите. мне лень.

фишка в том, что каррирование нужно там где частичное применение функции - идиома языка, в остальных случаях рождаются уродцы, вроде приведенных вами.

range-based-for уже есть в C++.

P.S. каптча izond как бы намекает

Скорее утилитки-парсеры с кодом на 4000-5000 и более для анализа данных. Социология + Программирование.

Не знаю что сказать. Классно) Может конечно жаба не мое просто. Пайтон в болшей части для системных скриптов использую. Си учу потихоньку. Еще коммон лисп мучаю.

range-based-for уже есть в C++.

Отстал от жизни со своей Сишечкой.

Классно

Кстати, в той конторе за поделку на Джаве приплачивают. Немного, но важен факт её востребованности. Что побуждает заниматься её поддержкой. Поэтому немного жалею, что не на Си она.

Хотел туда на полную ставку, но нет пока мест. Так что классно, да.

Удачи. Востребована, но уж сильно она мне не нравится.

Варианта два - или выкинуть, или хоть как-то приспособить. Ну и, кроме того, получил опыт построения ИС на основе Постгри.

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

Спасибо за беседу. Успехов!

если медленный процесс кодинга и тормоза не пугают, смотрите в сторону руби.

Писать на руби медленнее чем на плюсах?

само собой. автокомплита-то нет.

Взаимно)

вы на вопрос-то ответьте. зачем нужны ленивые вычисления. или у вас тоже с матчастью плохо?

смотрится лучше чем swap(&a, &b);

тащем-то, нет

вы на вопрос-то ответьте. зачем нужны ленивые вычисления. или у вас тоже с матчастью плохо?

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

void foo(bool a, uint64_t checksum1, uint64_t checksum2) {
   return (a? checksum1 : checksum2);
}

...

foo(true, expensive_checksum1(), expensive_checksum2());

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

что значит «ненужных»? это должно влиять на производительность? но у язычков со встроенной ленивостью с этим неважно. проигрывают и плюсам, и (ЕМНИП) шарпу.

что значит «ненужных»?

то и значит: один из параметров функции может не использоваться для вычисления ее результата.

это должно влиять на производительность? но у язычков со встроенной ленивостью с этим неважно. проигрывают и плюсам, и (ЕМНИП) шарпу.

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

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

зачем это нужно-то?

вот мы и пришли к любимому аргументу

ага. профит от ленивости какой? а нет его. уже 100 лет назад это выяснили.

зачем это нужно-то?

return socket_map_fetch(map, key, create_new_socket());

если в map'e нет ключа key, то ему присваивается значение create_new_socket() и оно же возвращается. вот тебе пример. сделай его ленивым. не получается? правильно, пиши портянки вроде if socket_map_has(...) ... socket_map_insert(...) и т.д.

return socket_map[key];

а внутри [] уже само решит, надо ему новый ключ создавать или нет. какие ещё портянки, lol?