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

Будущего нет.

/thread

https://www.youtube.com/watch?v=mslMLp5bQD0 tl;dr lisp

Это весьма условная правда. С таким же успехом, можно сказать наоборот:

Все сложности с наоборот будут из разряда «блджад, на какую кнопку жать, чтобы оно начало компилировать?!». Поработав на unix-подобных ОС, ты будешь знать язык. Поработав на венде, ты будешь знать расположение всех нужных тебе кнопочек в вижуал студии. Проблема именно в том, что знание матчасти обычно не является обязательным на венде в той же степени, в какой на юниксах.

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

Если тебе интересно, вытеснит ли один из вариантов «типизированного полиморфного лямбда-исчисления» все прочие методы. Нет, не вытеснит.

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

Востребованность формальных методов зависит от области. Где-то даже разговаривать не будут без серьезного бэкграунда, где-то, наоборот, не будут разговаривать при наличии оного.

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

Но, повторюсь, в целом, доля формальных методов останется невелика.

Самый простой пример. Существует формальная семантика XML. Правда, почему-то называется «XQuery 1.0 and XPath 2.0 Formal Semantics», но да пёс с ней. Кто-то читал данную спецификацию? Не читали? И *не* читайте, потому что даже *W3C* её забросил, и ваяет дальнейшие спецификации исключительно в рамках эпистолярного жанра!

И я с ним всецело согласен. Кому нужны спецификации, которые никто не читает? Я сам лично «взял» её только с третьего подхода. И если бы не замечательные статьи Вадлера (одного из разработчиков), то хрен бы я в неё въехал бы вообще. И естественно, полученные знания на практике применить еще не удалось (пока).

Нет. Пример тому Эдик, который не может осилить плюсы, потому, что долго писал на сишке.

Анон, который смог выразить мои мысли! Два чая ему.

Всё, думаю, останется также.

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

Qbasic

Qbasic — 1990 г. // 298 КB слишком жирный.
BASIC+  — 1975 г. // 8 KB — «вечно живая классика» для Intel 8080.

Но с «более удобными» языками всё равно никогда не сравняется.

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

Возможно вполне Perl6

Нет, я не осиливаю плюсы не по этой причине (кстати, 12 лет назад я на плюсерах пописывал). Просто у меня нет ни одной задачи, где нужны плюсы. А еще, я года 2-3 назад писал сишную обертку для плюсерской библиотеки, т.к. с ПСЗской нужно было срочно начинать работать, а библиотека лишь на плюсах была (да еще обертки для пхытона и жабки). По мере необходимости добавлял туда нужные функции.

Разобратся можно всегда, было-бы желание и время.

Я немного о другом сказать хотел. Если человек хоть немного интересуется, то опыт пусть и не очень глубокий в «смежных областях» получит. Ну а общий опыт (языка, «решения проблем» и т.д.) решает. Понятно, что знание конкретной области важно, но можно подумать выбор всегда стоит как: или берём специалиста с 15 лет опыта писания драйверов под линукс или гуи-программиста под винду.

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

Просто часто на собеседования приходят вчерашние студенты и по ним видно что ребята вродебы и толковые, но опыта катострофически не хватает

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

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

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

Поработав на unix-подобных ОС, ты будешь знать язык. Поработав на венде, ты будешь знать расположение всех нужных тебе кнопочек в вижуал студии.

Странное заявление. Я бы ещё понял, если бы ты говорил про «сопутствующие инструменты» (да хотя бы дебагер, мейкфайлы и т.д.), но от языка винда совсем не изолирует. Ну и ты так говоришь, что под линуксом нельзя взять какой-нибудь Qt креатор.

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

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

Что-то я тебя совсем не понял. Сказать хотел как раз то, что «в удобстве» (или возможности игнорировать мелочи) С++ никогда не обгонит «менее низкоуровневые языке» (хз как одним словом обозвать менеджед языки и всякие «более современные» вещи типа Gо).

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

General purpose high level язык будущего - это имхо Scala.

Java, конечно, будь он неладен.

В вебе — javascript.

Смотря для чего, вообще хороший программист я думаю должен знать хотя бы 3 языка программирования: один низкоуровневый язык программирования (Си, Ассемблер...), один ООП яп (С++, Java, Ruby...), и один функциональный (Lisp, Ocaml, Haskell...) И в зависимости от задачи уже выбирать нужный язык программирования, например для программирования микроконтроллеров, драйверов итд лучше взять Си или Ассемблер, для прикладного программирования ООП, а для обработки текста или еще что-то подобное (к примеру написать свой интерпретатор или компилятор) взять функциональный яп.

А если с веб технологиями хочешь работать то PHP, JS, Coffe, либо вместо php можно использовать Ruby on Rails, лично мне рельсы не очень нравятся, сам ruby прикольный, а вот фреймворк мне быстро надоел :)

Будут постепенно сливаться ООП и ФП парадигмы воедино. Может еще что-то придумают.

Но сейчас ближе в сторону rust, js, go, erlang, php, java, python, lisp...c

И попросит его написать простенький аналог telnet-а повергнит его в ступор на пару дней а то и недель (тогда как для опытного C/C++ unix/linux разработчика это задача на пару часов)

Я не вижу связи этой задачи с unix/linux. Или человек 20 лет писал по винду и ни разу не писал ничего связанного с сетью?

кобол нашего времени

в «хипстерских» язычках нет чего-либо из списка

Ога, потому что ты перечислил список костылей для ассемблера с классами.

Ruby.

streem

Дело не в сети, дело в мелочах:

1. Инструментарий - человек который привык работать в VS угробит уйму времени чтобы поднять/настроит/освоить весь стек разработчика под инородную платформу (можете себе представить человека который всю жизнь работал под VS, а тут ему втыкнули vim + консоль и сказали: работай). А инструментарий на самом деле не такой-уж и маленький (IDE, компиляторы, отладчики, профайлеры, VCS и тд).

2. Под каждой платформой есть какието особенности которые нужно знать и учитывать. В данном случае это как минимум система сигналов, и сособенности работы с терминалами в Linux/unix (нужно переводить его в различные режимы работы (строчный/символьный), возможно понадобится какойто свой обработчик/генератор командеых кодов + есть смысл посмотреть в сторону стандартныз библиотек (termcap/readline)).

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

Зачем ему это делать? Аналог телнета можно написать и на виндовом стеке в msvs.

сособенности работы с терминалами в Linux/unix

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

1)если это так, почему три четверти этих «костылей» успешно передраны (с разным успехом) в том же шарпе?

2)почему эти костыли встречаются во всех хипстерских язычках, но никогда все вместе?

Или не считаешь, что шарп и джава меньше граблей подставляют?

код на плюсах, как правило, быстрее пишется (по крайней мере, по сравнению, с джава уж точно, в которой даже вывод типов до сих пор не осилили)

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

Зачем ему это делать? Аналог телнета можно написать и на виндовом стеке в msvs.

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

Ты же сказал «простенький», поэтому особенности не нужны.

Ну я же говорил телнет а не NetCat - а у базового телнета есть базовый функционал.

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

Аналогичная ситуация, я тоже програмирую под линукс со второй половины 90х и тоже ни разу не доводилось програмировать терминал. Но это не мешает мне (и думаю вам тоже) знать что терминалы в линуксе есть, что у них есть различные режимы работы и что есть стандартные библиотеки для работы с ним. Человек же который не имеет таких престовлений может написать чтото очень простое на основе getchar() - а потом долго искать причину почему половина кнопок не работает да и получает данные от пользователя както странно. При этом часть приложений с этими особенностями работают нормально, а часть (например mc) вообще не работают. Улавливаете суть ?

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

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

Ну я же говорил телнет а не NetCat - а у базового телнета есть базовый функционал.

Это какой?

Улавливаете суть ?

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

1)если это так, почему три четверти этих «костылей» успешно передраны (с разным успехом) в том же шарпе?

Чтобы быдлокодеров не смущать.

2)почему эти костыли встречаются во всех хипстерских язычках, но никогда все вместе?

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

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

Нет, утечки там встречаются гораздо раньше. Например, в джаве и даже в её новомодной хипстерской версии (то есть скале) нет деструкторов, поэтому, внезапно, ресурсы надо чистить руками как в старом добром Си. Забыл чего-то очистить и трындец!

код на плюсах, как правило, быстрее пишется

Я не согласен, но спорить лень. Пишу на С++, если что.

На Clojure.

C++14 и выше, а также Rust.

ZX Spectrum 48K Basic

пидо-1c-systemd-лгбт, если вовремя не взяться за ум.

никому не нужни програмисты знающие C/C++ или Java. Нужны Java разработчики для Android, или Java разработчики со знанием Spring/JBoss/JDBC/Swing

лорчую, полностью согласен с данными оратором

а что именно вы пишете? под плюсы много чего есть плане фраемворков.

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

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

драйвера, системщина. — nuff said

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

физмат. под шарп, яву, хипстоту, нет ни одной приличной либы.

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

Haskell, OCaml, Scala, Erlang. Вот тебе на изучение в порядке убывания качества.

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

http://lotusrb.org/

Я вообще считаю, что писать в будущем программы будет незачем. Лишнее это. Творчество, изобретательство, работа на уровне форм и сущностей. А Вы тут в if'е вместо == вдруг = напишите, и конец полету мысли.

Он закостенел. Ему не требуется учить плюсы, ему и сишки хватает. Не хватало бы - выучил бы.

примерно такая эволюция, сорри за небольшой оффтопик, хотя...

http://www.ariel.com.au/jokes/The_Evolution_of_a_Programmer.html

думающие (программисты) только мешают бизнесу/хаосу

смысл изучать низкопробное качество?

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

Чернорабочие нужны всегда. Кодеры, подвид чернорабочих, тоже. И среди них всегда будет илитка в количестве меньше процента. На эту илитку будут ровнять всех остальных - кодь в следующем квартале ещё больше, и станешь ближе к илитке.

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

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

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

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

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