• Как найти самый длинный непрерывный ряд событий с помощью SQL
    0
    Так еще можно:

    declare @Posts table ( CreationDate date  )
    insert into @Posts (CreationDate) values('2010-11-26')
    insert into @Posts (CreationDate) values('2010-11-27')
    insert into @Posts (CreationDate) values('2010-11-29')
    insert into @Posts (CreationDate) values('2010-11-30')
    insert into @Posts (CreationDate) values('2010-12-01')
    insert into @Posts (CreationDate) values('2010-12-02')
    insert into @Posts (CreationDate) values('2010-12-03')
    insert into @Posts (CreationDate) values('2010-12-05')
    insert into @Posts (CreationDate) values('2010-12-06')
    insert into @Posts (CreationDate) values('2010-12-07')
    insert into @Posts (CreationDate) values('2010-12-08')
    insert into @Posts (CreationDate) values('2010-12-09')
    insert into @Posts (CreationDate) values('2010-12-13')
    insert into @Posts (CreationDate) values('2010-12-14')
    insert into @Posts (CreationDate) values('2010-12-15')  
    insert into @Posts (CreationDate) values('2010-12-16')  
    insert into @Posts (CreationDate) values('2010-12-19')  
    
    insert into @Posts (CreationDate) values('1900-01-01')  
    insert into @Posts (CreationDate) values('3000-01-01')  
    
    
    ;with dates AS (
    	select cast(p1.CreationDate as date) FinishDate, cast(MIN(p2.CreationDate) as date) StartDate 
    	from @Posts p1, @Posts p2
    	where p1.CreationDate < p2.CreationDate
    	group by cast(p1.CreationDate as date)
    	having MIN(datediff(day, cast(p1.CreationDate as date), cast(p2.CreationDate as date))) > 1
    )
    select d1.StartDate, MIN(d2.FinishDate) FinishDate from dates d1, dates d2
    where d1.StartDate <= d2.FinishDate
    group by d1.StartDate;
    


    Стремился только к краткости, как его SQL-SERVER оптимизирует, не проверял. Суть: добавляются две граничные даты сверху и снизу. И ищутся дырки.
  • Как учить детей программированию: Kodu Game Lab теперь доступен для PC
    0
    Попиарюсь немного. Я хоть и не разработчик игр, но недавно знакомый предложил мне подумать над этим, потому как у него ребенок, он хотел бы, чтобы какую-то игру ему обучающую дать. Для такого возраста не нашел.

    И я создал небольшую онлайн-игру. Для детей, наверное, младше 12 лет. Простенькую. Программируется робот, тоже визуально. Мышкой. Сравнивать с игрой, о которой тема, конечно, не имеет смысла, у меня не создаются игры и не 3-d. Но и порог вхождения значительно ниже, что важно для таких игр.
    Игра детей знакомит с ветвлениями и простыми циклами. Не смотрите, что на первых уровнях очень простая. Под конец детей такого возраста вполне нагружает. Напоминает головоломку. Проверял на детях, понравилось. (может только придется вам поучаствовать в объяснении вевтления и цикла. Но были дети, которые сами разобрались)

    Может и вашим подойдет.
    http://robotinmaze.net/ru
  • Можно ли стать программистом после 30-ти?
    +2
    Можно. Я начал работать почти в 28. Уже нет проблем никаких, опыт. Но учтите, что опыт нарабатывается очень долго, знаний очень много. Я даже поначалу не знал, что так много придется читать всего, изучать. Уже 10 лет опыта работы, а всё еще есть пробелы. По образованию не программист, многое догонять пришлось.

    Хотя, это зависит, наверное, от направления и языка программирования. Кому-то и поверхностное знание PHP с каким-нибудь фреймворком хватает для зарабатывания денег.
  • Язык программирования J. За что любить?
    0
    Если вы отличный специалист в С++, то всегда можно написать программу, работающую быстрее, чем на J. Но разница будет: месяц по сравнению с час, утрированно, работы программиста. Иногда это просто неприемлемо. Пусть J и медленнее, но он достаточно производителен. Причем не факт, что он будет медленнее, если писать на плюсах в лоб.

    Я так прямо не могу дать сравнительные тесты, просто из своего опыта. Потому что допиливали проблемные места кода на джее с помощью С или плюсов.
    Местами он заметно неэффективен. Причем, эти места даже понятны, можно привыкнуть. Он энергичный, не ленивый. И в непонятной ситуации для сохранения имутабельности данных делает копию. А копии — это весь массив, который может быть большим. Поэтому там неэффективна рекурсия.
    Но и оптимизируется легко. Пишете на С эту часть. Джей передает туда ссылку на массив и вы уже делаете, что хотите.
  • Язык программирования J. За что любить?
    0
    А, я не понял вопрос правильно, понял как общий вопрос, сколько бы я искал ошибку в коде джея такого объема.

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

    11&0. — это свалит джей, т.к. нет глагола с цифрой ноль и точкой. буква о с точкой есть. Если вы сюда внесли ошибку. Вообще эта «хитрость» с нулем ищется почти мгновенно, если это в IDE перенести. Глагол о. зеленым рисуется, цифра фиолетовым. Т.е. даже если шрифты бы были неудобные

    И читается он также легко.
    Второй глагол (g) описывать не буду, т.к. голова у читающих сломается. Там два сдвига вектора, на один и два элемента, разности с исходными, поиск сопряженного, перемножение их, нахождение углов, проверка, меньше углы нуля и отрезать два с хвоста. Всё читается, много логики, а что за логика, надо смотреть — зачем это в алгоритме. Этот глагол вычисляет булевский вектор. Если вас пугает такая сложность и много логики в этом глаголе, то представьте себе этот код на Си. Он не будет понятнее. Сложный алгоритм и останется сложным, для тех, кто не понимает, зачем производятся такие действия (не знает алгоритма) и такой математики, допустим, что такое сопряженное число.

    Третий глагол добавляет единицы в голову и хвост вектору, который вернул второй глагол g. Он возвращал без двух элементов, этот глагол их добавляет. И применяет вектор как фильтр к аргументу.

    Ну и последний: применяет s — т.е. сортирует по углам исходный вектор. А далее, применяет r в цикле, до тех пор, пока вектор не перестанет меняться.

    Неясность моего описания связана только со сложностью алгоритма, а не с джеем. Джей ничего не усложняет
  • Язык программирования J. За что любить?
    0
    Я опять не понял, что вы хотели сказать. Вы имеете в виду, что те глаголы, которые использу.ются в примере, встроены в язык, а типы и методы вроде List и sortBy являются частью стандартной библиотеки? А какая разница?

    Разница небольшая, но есть. Просто я показал как разобрать удачную для Scalа строку джея. Но джей с нуля позволяет и другие, неудобные для других языков вещи писать кратко. Все таки — это работа с многомерными массивами, а не списками.
    Вот, расскажу, что делается в предыдущем примере в этом коде. Хотя код аналогичен вашему, но мог бы быть и другим.
    s =: /:[:|-/12"_ o.],:<./


    Найти минимальный элемент. Склеить его снизу к входящему вектору, получить двумерную матрицу. НАпример такую

    3 7 8 2 9
    2 2 2 2 2
    Найти у каждого элемента угол. И отнять от второй строки первую. Далее, найти перестановку для сортировки этого массива и применить эту сортировку к исходному массиву.

    Да, это Спарта. Но в джее мышление немного как бы шире списков. Этим он и прекрасен.

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

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

    Потом, эти значки — это операции с массивами, а не привычные нашему ООП-мозгу названия из нашего реального мира. Тяжело им названия подавать и чтобы они были более понятные чем значки. Тут нет объекта птичка или бизнес-правило. Если soryBy еще куда ни шло, то там есть и похитрее операции. Плюс к этому, джеист мыслит этими многомерными массивами, его воображаемая очевидность для вас будет совсем не очевидна, даже если он назовет.

    Однажды меня попросили описать алгоритм для документа, это была жесть. Мне надо было или врать, или говорить: берем 6-ранговый массив, меняем 3 ранг с пятым и находим проекцию на вектор с операцией агрегации такой-то. Технический писатель отказалась переводить и оформлять этот документ.

    Так что тяжело в учении — легко в бою. Эти значки — неплохая и вынужденная вещь. Я думаю, было бы лучше, если бы там были по одному символу на глагол значки и какие-то покрасивее, чтобы картинка подсказывала, что за операция. Но клавиатуры не позволяют. И вообще, это не критичная проблема. За неделю можно заучить все эти комбинации.

  • Язык программирования J. За что любить?
    +2
    я участвовал в реальных проектах, написанных на джее: датамайнинг.

    Один из проектов — высоконагруженный сервер, нереляционная субд, для датамайнинга. Кластер, шардинг. Это еще в далеком 2005 году, когда такие слова не были особо в обиходе у программистов модными.

    Я лично, например, писал там еще математические сервер, считающий ОЛАП-преобразования. Еще про олап мало кто слышал.

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

    Посмотрите на главной странице http://www.jsoftware.com/ в разделе Representative Users кто его использует и найдете Hewlett Packard, Intel, Microsoft и много других.

    И не стоит противопоставлять математику джеевской форме записи. Иначе все языки попадут под такую категорию. Не говорю только о Лиспе, а даже и о плюсах и Scala. В математике звездочки вместо умножения не пишут, наклонную черту вместо деления не пишут. Или во многих других языках есть графические способы записать интеграл?
    Математика создавалась тысячелетия, но далеко не вся. Интегралы только во время Ньютона появились. И сейчас появляются новые значки. И не думаю, что Кенет Айверсон глупее араба две тысячи лет назад.

    Я лично тоже считаю, что один красивый уникальный значок на глагол был бы понятнее, чем комбинация из двух. Но клавиатуры мешают. И это не критично. А сама форма записи и разбора предложений — очень и очень неплохая в джее.
  • Язык программирования J. За что любить?
    0
    Я извините, не внимателен. Scala, а не Питон.
  • Язык программирования J. За что любить?
    +1
    Этот код, который написан, понятен и да, он больше. Но он понятен, но не использует по всей видимости только изначальные языковые вещи. (Я не знаю Питон).
    sortBy — это скорее уже библиотечная функция, как и тип List, даже если они из коробки.

    Почему это важно? Потому что я показал разбор только одной строки, которая удачно, только с сортировкой связана. На джее таким же образом можно сделать всё. Кстати, у вас голова не вычитается, это меняет алгоритм, потому как 0 может получиться не только у самого себя, но и у точек на одной линии. Далее, вы не сортируете углы относительно минимальной точки. Вы сортируете углы относительно 0+j0, просто отняв угол минимальной точки и взяв абсолютное значение. Это был тест, насколько я пойму код другого неизвестного языка?

    На джее, аналогичный вашему код будет поменьше:

    s =: /:[:|-/12"_ o.],:<./


    И специально, для ненавидящих таситную форму джея и любителей абстракций, то же самое в экслисит форме с именами, чтобы не раздражали значки глаз:
    min =: <./
    angle =: 12&o.
    sortBy =: /:
    abs =: |

    s =: monad define
       y sortBy abs
    (angle y) (angle min y)
    )



    Как видите, этот код не хуже вашего питоновского, но он все же хуже того, что в таситной форме как по мне.
    Почему 12 выбрано? Это к создателям джея. Это язык такой, что там элеметнарным глаголам имена не раздаются направо и налево. o. применяется для разных случаев.
  • Язык программирования J. За что любить?
    +2
    Слишком резкие высказывания. Его используют. Я всеми силами тут пытаюсь объяснить, что язык семантичен, не стоит дураками китайцев например, называть, или немцев, что ж они очень семантический русский не пользуют? Чтобы понять, насколько семантический язык, надо его знать и сравнить, а не пугаться всего, что непонятно.

    Это скорее психологическая реакция. Дети в школе так делают — называют всё, что непонятно, идиотизмом. Физику, математику. «какой это идиот придумал?»

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

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

  • Язык программирования J. За что любить?
    +3
    Вопрос

    Вы часто на SQL-ле пишете сам движок субд? Код, который ниже, который на джее — не делает выборку, он создает возможность такой работы. Навесить парсер SQL и можно писать к такой СУБД уже какие-то запросы.
  • Язык программирования J. За что любить?
    0
    Странно, за что столько минусов? Где я не логичен?

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

    То, что вы критикуете, что программист пишет большую часть логики в одном предложении, так это потому, что для него так комфортно писать, что есть, несомненно, плюсом. И ваша критика основывается только на непонимании, почему этот программист понимает этот код. А именно, не знание глаголов и правил построения. Вам кажется тот код сложным? Чистый и простой код. Просто обратите внимание на скобки. Их много? Нет. Если их не много, то внутри код читается линейно. Давайте разберем первое:
    s =: ({., }. /: 12"_ o. }. — {.) @: /:~

    справа налево. Первый глагол:
    /:~
    Обозначает отсортировать по возрастанию. Тут наверное вектор, т.к. в задаче вектор. Я давно статью читал и вообще в код не вникаю сейчас, с нуля разбираем. Сортировка — понятно, что это такое.
    Далее союз @: — говорит, что после сортировки надо делать то, что в скобках.
    В скобках берем три первых (с конца) глагола:
    }. — {.
    Отсечь голову вектора (списка) и от этого получившегося списка отнять голову.
    Следующие два глагола берем:
    12"_ o. }. — {.
    Сначала выполняется первый левый, потом тот, что посредине, берет правую (уже вычисленную раннее) и левую часть.
    12"_ — это хитрый глагол, порождающий константу (12), вне зависимости от аргументов. Просто число не подошло бы, т.к. требуется глагол, а не существительное. Т.е. по сути, далее, если в прямом режиме, без глаголов писать, то выполнится выражение:
    12 o. к нашему обрезанному и отнятому списку
    12 o. — это поиск угла комплексного числа. К списку применяется, значит там список комплексных чисел — применится к каждому. Берем новые два глагола:
    }. /: 12"_ o. }. — {.
    То же самое. Сразу левый выполняем — отрезать голову исходному отсортированному (за скобками вначале) списку. И диадный глагол сортировки — это значит, что находим перестановку для углов справа и в этом порядке располагаем список слева. Т.е. перемещаем все комплексные числа так, чтобы углы, если их взять, были отсортированы.
    Снова берем два глагола:
    {. ,}. /: 12"_ o. }. — {.
    Взять голову отсортированного списка и запятой приклеить к списку справа — т.е. отсортированному (без головы)

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

  • Язык программирования J. За что любить?
    +5
    Зря вы так пугаетесь джея. Выучить его вполне возможно, не верная аналогия с китайским. Просто дольше, чем обычные языки. Но а разве слишком долго сами языки другие изучаются?

    Я джей изучил за месяц по вечерам. Просто прочитал и опробовал все примеры в книге Lerning J. Я ее даже конспектировал. Неделю заучивал на память все глаголы. Просто, зазубривал. Наверное, для джея это важно, т.к. их там достаточно. Но и надо сказать, что такое зазубривание — не так много времени и занимает.
    После этого делал первое свое большое задание. Тоже с месяц по вечерам. Было очень сложно. Но постепенно мышление привыкало мыслить массивами.
    После этого был готов работать. Пошел на работу на этом языке. Хотя как-то работать и мог, нельзя сказать, что ясно понимал текст и хорошо писал. В процессе, с год этот навык улучшался.

    Так что вполне в разумные сроки можно изучить. Возможно, это требует какого-то специального мышления, у меня статистики нет.
  • Язык программирования J. За что любить?
    0
    Есть особенности работы человеческого мозга, которые не позволяют эффективно парсить подобные структуры.


    В отношении джея это утверждение для меня не очевидно. А личный опыт говорит об обратном.
    Люди говорят, что в Лиспе скобки — самое вкусное. И что это круто. Я их не понимаю, потому как глазами разбирать, где какая скобка закрывается — мне неуютно. Джей же как раз наоборот — эргономичен. Вилки и крючки (правила построения выражений) как раз минимизируют скобки, позволяют писать и читать линейно сложные алгоритмы, а не только последовательные преобразования.

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

    Кстати, в этом тоже плюс джея. На нем можно достаточно легко написать вот такие длинные большие штуки и они работают. И не париться. Там внизу писали, что джей используется когда много данных и мало времени. Это отчасти верно. Джей — он как инструмент для быстрой обработки данных, здесь и сейчас. Иногда и не надо ничего рефакторить, возможно, это одноразовый был бы код в реальной задаче.
  • Язык программирования J. За что любить?
    –15
    В современных языках как раз избегают писать длинные выражения в одну строку. Гораздо понятнее и удобнее разбивать сложный алгоритм на несколько более простых, которые затем комбинируются понятными операторами.

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

    В общем, джей позволяет писать бОльшими кусками и не запрещает разбивать на меньшие.

    Как быстро вы сможете найти ошибку в следующем алгоритме?

    Плотно в проектах я давно с джеем работал. С тех пор развилось IDE хорошо, появились какие-то средства отладки. Но вообще, ни разу как-то не видел надобности в таких средствах. Действительно, через время пишется на этом языке легко. А в побольше проектах надежность кода гарантируется как обычно — юнит-тестами.
  • Язык программирования J. За что любить?
    –2
    позвольте возразить )

    На счет выбора знаков, почему именно эти — я не в курсе истории. Наверняка были на то причины.

    Но вот это:
    max(a) + sum(a)/len(a)
    понятно, пока оно просто. А так:
    sum(a)/len(a) + max(a)
    Тоже понятно. Тогда так:
    sum(a)/len(a)<<2 + max(a) Упс, уже надо смотреть приоритеты.
    А если надо к сумме добавить максимальное, а потом всё поделить? Только скобки. Когда как в джее всего лишь меняются местами операции. Если выражения усложняются, то вам как математику и программисту на каком-то уровне придется пойти покурить и передохнуть, чтобы понять длинное выражение со скобочками.

    В этом то и плюс джея — вилки и крючки. И отсутствие приоритета операций. Именно это и позволяет писать большие выражения, а потом так же их легко читать. Вам сейчас просто кажется из-за незнания синтаксиса, что там ужас написан. Но привыкнув к нему, он начинает давать профит. В лиспе, например, тоже передумали писать, как привыкли математики. И не для усложнения, а для упрощения.
  • Язык программирования J. За что любить?
    –4
    C#, допустим.
    Готов поспорить, что если бы программист написал методами или в одном методе код, то в любом случае этот код выше читается намного проще. Просто пройтись глазами справа налево.
    И это простенький глагол. Если бы написали побольше алгоритм, то мне только на небо надо было бы надеяться, что программист, назвав как-то метод в другом классе в другом файле, делает в том методе то, что говорит его название. Если оно говорит.

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

    А вообще, где-то похоже по ощущениям. На джее вообще, ощущения как и на SQL. Только на последнем реально бывает очень тяжело выразить довольно простые мысли, в отличии от джея. Где-то в мозгах так же на SQL комбинируете множества, как и на джее, но там сложности из-за отсутствия упорядоченности, индексного доступа. На джее же всё пишется легко.
  • Язык программирования J. За что любить?
    0
    а, да. Комментарии нужны, просто я хотел кпд языка показать. Обычно, под каждый глагол аннотацию желательно писать. Потому как глаголы обобщенные, но часто при создании глагола программист какие-то ожидания на них вешает, тип массива например. Вот, в isVar нужно передавать бокс с текстовой строкой. Хотя, из тела видно, но можно, обычно пишут.

    Комментарий после NB.

    Не особо плюсы или шарп и естественные. Они позволяют просто давать имена. А ООП ближе к естественному мышлению, чем массивное программирование. Но имена и здесь в джее хорошо даются глаголам, можно и классы писать. Никакой разницы в этом нет. Просто джей позволяет это делать меньше. Хотите, делайте очень маленькие простые глаголы и каждому давайте имя. Будет как в С++
  • Язык программирования J. За что любить?
    –2
    А вам не очевидно, что я, например, вполне себе читаю, иначе бы просто не смог бы написать сколько кода write-only?

    isVar =: [:(91&>*.64&<)[:a.&i.[:{.>

    Отрыть коробку, взять первый элемент со списка (символ), узнать его номер в алфавите (ASCII), и истина, если он входит в интервал — (91;64) — и называется isVar. Вспоминаем, что в прологе переменные пишутся с большой буквы.
    Читается такой код элементарно, никаких хитростей нет. Просто надо знать эти элементарные глаголы и правила построения выражений.
  • Язык программирования J. За что любить?
    +7
    Вам да. Также, как и китайский язык. Непонятен и перевести невозможно.
  • Язык программирования J. За что любить?
    +15
    Наверное не совсем донес идею, а наоборот испугал непонятным кодом.

    Он не такой уже непонятный. Чтобы понимать язык, нужно знать его слова. Джей по словам-примитивам намного богаче, чем привычные языки программирования. Например, никого не убивает в С++, операция >>, или ++, или просто скобки {}, служебное слово class и тому подобное.
    Также и здесь.
    Я в посте хотел объяснить именно эту логику, потому что люди думают эмоциями в таких случаях. Если вас пугает синтаксис, то это где-то аналогично, как пугаться иностранного языка и думать, что им пользуются дураки только – он же на ваш родной не похож. Это «попроще» — просто ваши ожидания от языка. Вам хочется, чтобы он сразу был понятен. Не изучая слова. Но тогда, он либо должен быть похож на естественный язык, причем желательно родной (а таких нет еще), либо не содержать слов, а позволять их побольше самому писать. В этом случае, заметьте, что вы бъете по своим воротам. Разве не надоело в каждой новой компании разбиратьяс я с новым методом DoSomethingEveryYearBefore2012? Слова понятны, но они не из языка программирования – это наносное. А наносят бог весть что. И каждый раз нет претензий к самому языку, претензии только к предыдущим именователям.
    Ожидания от языка, которого вы не знаете, не всегда играют хорошую роль. Этих глаголов здесь штук 150 и за долгое время работы они становятся узнаваемыми. Правила комбинирования глаголов довольно простые. Поэтому, еще очень спорный вопрос, на каком языке код понятнее.
    Далее, наиболее важный плюс джея – это работа с многомерными массивами. Т.е. представьте себе алгоритмическую сторону ваших программ. Вам часто надо создать массив. Тут делается элементарно. Хотите траспонировать? |: без проблем. Хотите развернуть список/массив. |. без проблем. Хотите уникальные элементы найти? ~. без проблем. Вот эти маленькие комбинации избавляют вас от кучи кода в других языках и вы мыслите совсем на другом уровне. Код без циклов, практически, вы только вращаете кубы, клеите их, находите пересечения, проекции – что угодно. А то, что эти операции обозначаются значками – это во-первых кода меньше, а во-вторых не особо им из нашего мира дашь подходящее название. Это векторно-массивные операции. Которыми можно легко выражать почти любой алгоритм.
  • DES на J в сотню строк
    0
    Язык — прямой наследник APL, поэтому не эзотерический.
    Программы читаются, но этот навык долго нарабатывается.
    В данном посте читается сравнительно легко, тут в основном explicit-форма записи. Есть tacit-форма. Ее читать сложнее. Также очень зависит от кода. Если люди много скобок пишут, не могут пользоваться нормально крюками и вилками — то читается плоховато.
  • Люди с кодопрошлым или закат программистов
    0
    да, облако скорее всего сначала получится. Там будет огромная база знаний, которую пока в телефон не запихнешь, с параллельным доступом к информации с разных «телефонов», что еще полезнее, т.к. эта база будет пополняться в одном месте.
  • Язык программирования J. Взгляд любителя. Часть 4. Коробки и циклы. Заключение
    +1
    PS. «по гибкости» — я конечно подразумевал — какие структуры данных можно на С сделать. На джее попросту об этом не заморачиваются. Пусть оптимальную структуру данных подбирает интерпретатор
  • Язык программирования J. Взгляд любителя. Часть 4. Коробки и циклы. Заключение
    +1
    В J связный список не нужен. Такой список – это слишком что-то низкоуровневое. Если Вы пишете программу на относительно низкоуровневом языке, на С, то Вы создаете структуру данных из совсем слабых абстрактно примитивов. И когда Вам для некоторого алгоритма достаточно связного списка, то не нужно создавать больше функционала, на этом Вы и останавливаетесь.

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

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

    Есть еще в J классы. Можно создать кусок кода, любой по форме, который допустим будет хранить и существительные (т.е. данные). А потом создавать экземпляры классов и каждый экземпляр будет иметь свои отдельные данные. Так что можно создать и какую-то сложную абстракцию.

    J написан на С и он, конечно, не может его обогнать по гибкости и возможности оптимизаций. Он дает преимущество – рассматривание задач в другом совершенно виде, в виде матриц/массивов. Совершенно меняется взгляд на алгоритмы. Позволяет задачи решать очень кратко. При этом его быстродействие сравнимо с С.
  • Язык программирования J. Взгляд любителя. Часть 1. Введение
    0
    Была сделана давно интеграция с дотнетом (давно не интересовался этим, не знаю как сейчас).
  • Язык программирования J. Взгляд любителя. Часть 4. Коробки и циклы. Заключение
    +2
    J написан на С. Можно найти исходники. Правда их изучить не представляется возможным, потому что они на С пишут как на джее ))

    Работа с памятью — сишные malloc. Выделяются массивы в куче. Единица данных — n-мерный массив. 0-мерный — скаляр, 1-мерный — вектор, 2-мерный — матрица и т.д. На счет, выделяются ли и скаляры в куче — не знаю, не интересовался.
    Массив имеет всегда одинаковый тип элементов — булевский (0,1), целый, целый с любым количеством знаков, действительный с плавающей точкой, рациональный, комплексный, символьный, symbol ('sdf, 'sdfsfd — нечто похожее на символьный тип в Scheme) и боксы. Боксы — это некий аналог нетипизированных указателей. В массивах из боксов можно хранить разнотипные данные. В боксе можно хранить и другие массивы, поэтому боксами реализуются деревья, например.
    Также есть специальные значения — +бесконечность, -бесконечность, неопределенность.
    Надеюсь, ничего с типами не пропустил.
  • Язык программирования J. Взгляд любителя. Часть 2. Тацитное программирование
    +2
    Надо готовить статью точно по этой теме. Всё в нем нормально. Только высокий порог вхождения. Он читаем, читаем поболее других языков. Но к этому прийти можно после нескольких лет работы на нем. Поначалу, пару месяцев, сможете только писать и только с трудом, а читать даже свой код не сможете.

    На счет производительности — не правы. Он очень производителен. Даже иногда как некоторая магия воспринимается, как он умеет так относительно быстро работать, не смотря на такую высокоуровневость. Он бывает и тупит, заметно тупит, от этого никуда не деться. Тем не менее, он прекрасно работает с библиотеками, написанными на других языках, поэтому позволяет делать точечные оптимизации узких мест. Т.е. например, в нем можно вызвать функцию из библиотеки, написанной на С, и передать туда массивы, как аргументы. И сделать с ними там уже что хотите. Я работал на высоконагруженных проектах, сделанных на J. Вполне отличный язык в плане скорости создания прототипа, удовлетворительной производительности самой по себе и оптимизации проблемных участков.
    Использовал его для датамайнинга. Очень хорош как язык для быстрого создания сложных алгоритмов и обработки больших массивов данных. Т.е. в финансовой сфере, для предсказаний и т.д.

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

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

    Минусы скорее только такие: высокая сложность, не надейтесь научиться ему быстро. Я изучил его за месяц (прочитал книгу и запомнил все глаголы, примеры и т.д.). Еще с месяц писал первое задание, которое придумал. Это всё по вечерам. Но привыкал с год, более менее читать. И дальше тоже развивался. И думаю, еще не достиг идеала понимания этого языка. Хотя со временем он становится понятнее и понятнее.
    Эта сложность языка является и причиной другого минуса — мало кадров. Т.е. выбирая его под проект, вы рискуете не найти людей.
  • Проект «Бэкап планеты»
    0
    Думаю, к тому времени, когда люди научатся летать на другие планеты, инфраструктуры будут создавать принтеры. Задача первых прибывших будет только в наблюдении, чтобы их никто не своровал.
  • Почему мы не тестируем. Практика проведения технического интервью
    0
    Понятно. Спорить в общем-то нечего, у нас разные мировоззрения.

    Я не утверждаю, если что, что работа должна быть ненавистной и надо ее выполнять с настроением мытья посуды. Просто думаю, что должен приносить удовлетворение процесс, а не результат. Мотивировать себя на результат — это на слишком короткие дистанции. Никто так не становится чемпионом в спорте. Никто не станет хорошим программистом, желая всего лишь взять эту высоту. Только привычка работать и только работа, долгосрочная к этому приводит. А выбрать себе деятельность, которая еще и приносит удовольствие как процесс (в моем случае программирование) — это вообще удача.
  • Почему мы не тестируем. Практика проведения технического интервью
    +2
    успех — это возможность самореализовываться

    Это то же самое, только в профиль. Т.е. «стать известным» в какой-то сфере. Когда всё, что надо, есть, еще бы славы )))

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

    Получать от работы удовольствие, конечно, важно. Но, ИМХО, эмоции — лишнее.
    Хотя бы потому, что если Вы сделаете
    комплексную программу проектов общим объемом 6000 чел.*мес. Для меня это вызов.
    , после этого за подобную задачу не будет интересно браться. А как быть опытному программисту, когда он уже поучаствовал в нескольких десятках проектов, многие сделал сам, и они охватывают уже все интересные для него сферы? Бросать работу и идти в космонавты ))
  • Почему мы не тестируем. Практика проведения технического интервью
    +2
    Озвучить можно мягко, конечно. Честным быть хорошо.

    Но это так же и очевидно. Если человек на собеседовании начнет прямо говорить, что меняет работу ради +ХХХ денег, то как-то не сумел выглядеть немеркантильным, жаждущим знаний, с четкой жизненной позицией и т.д. (прямо по статье). А если еще добавит, что мудаки на прошлой работе достали )))) Тогда Вы его точно не возьмете.

    Но ведь человек в первую очередь решает свои личные проблемы. Не надо врать, что он за идею работает.
    Конечно, когда опыт большой, когда уже нет особой разницы — везде платят хорошо, то иногда могут найти какой-то интересный плюс в какой-то другой компании. Вроде командировок в Лондон или просто компания более известная. Но опять же, по этим причинам с текущей работы не уходят. Уходят только тогда, когда вынуждают более веские причины.
  • Почему мы не тестируем. Практика проведения технического интервью
    +1
    за всех и сразу отвечу: практически всегда уходят по одной из двух причин или двум сразу — первое, хотят больше зп, второе — напряженные отношения в коллективе (часто с начальством). Ни первое ни второе на собеседованиях никто в своем уме озвучивать не будет.
  • Почему мы не тестируем. Практика проведения технического интервью
    +9
    По-моему, плохой вариант собеседования. Хотя верно, вы же ищете похожих по менталитету, вы и барин.

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

    Зрелость личности — это умение работать без особых мотивационных заморочек. Стрелянный волк, т.е. опытный программист видел разные проекты, все время работает. Работа — это просто рутина и те, кто умеют делать рутину — настоящие профессионалы. Достигают результатов в чем либо только те, кто работает над чем-то каждый день, переводит занятие в привычку. Огни в глазах перегорают за месяц.

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

  • Проблемы использования IEnumerable
    0
    Прошу прощения за косноязычность. Конечно, я не подразумевал, что ради единственного Last() надо кругом всё превращать в массивы. Ответ немного выше.
    Но снова об оптимизации. Зло это. Вообще, думать об оптимизации. Я со всем согласен и с Вами и с постом, не нравится только ракурс — рассматривание проблемы с т.з. того, как это плохо — многократные итерации. И Ваша т.з. — как это плохо — складирование строк в памяти. Как вроде ничего больше в программировании интересного и нет )
  • Проблемы использования IEnumerable
    +1
    гарантирующий конечность (и только чтение), насколько я понимаю, этот:
    msdn.microsoft.com/en-gb/library/hh881542.aspx

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

    Добавить своих расширяющих методов можно. Часто передаются IEnumerable<> кругом. Но при этом, если программисты пользуются в своим коде List<>. Чтобы не идти на компромиссы, выбирая, что же надо передавать кругом — связный список (IEnumerable<>) или список с индексным доступом(IList<>), а ToList() делает копию, что бывает накладно, то можно добавить такой метод:
    IReadOnlyList<> ToReadOnlyListByRefOrCopy(...)
    А там проверять, если это список, то приводить просто по ссылке и возвращать враппер, если нет — враппер над копией.
    Таким образом получите некий компромисс между производительностью и выразительностью кода. Как только нужен индексный доступ — вызвали этот метод.

    Типами можно хорошо описывать намерения. Не всегда всё гладко получается и с типизацией проблемы, но имхо, лучше уже так, чем просто беспорядочно IEnumerable<> использовать.
  • Проблемы использования IEnumerable
    0
    У IEnumerable просто даже нет последнего элемента по смыслу. Это просто множество без заданного порядка. Нет гарантии, что два перебора дадут тот же самый порядок и что один и тот же элемент будет в конце.
  • Проблемы использования IEnumerable
    +1
    Сложная тема. Последняя строка как по мне — недостаточно. Поиск последней строки — это тоже индексный поиск. Также Count() — неродная операция.

    У интерфейсов есть назначение. IEnumerable нужен только для перебора, возможно бесконечных множеств. Если программист объявляет такой тип, он это и декларирует — ему надо перебрать, ему не важен порядок элементов (индексы) и т.д.

    ElementA(), Last(), Count() — это всё экстеншин методы, они не входят в IEnumerable. По моему, типами, программист также говорит о том, что он собирается делать. Это улучшает читаемость.

    Если бы C# был таким чистым функциональным языком с немутабельными типами — то особых проблем бы не было с вызовом этих методов и с итерациями. Можно бы было один список, как в Lisp использовать для всего. C# не может гарантировать в общем случае, что в множестве не изменяются элементы от вызова к вызову, поэтому не может использовать ленивые оптимизации.
    А поэтому, лучше использовать правильные типы.
  • Проблемы использования IEnumerable
    +1
    Если нужен индексный доступ, то по смыслу самому List (в смысле вектор для плюсовиков) подходит явно. Конечно, на любых переборах, не зависимо от структуры данных программист может найти по индексу элемент. И не должен задумываться, что там за структура.

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

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

    var lines = File.ReadLines("data.txt");
    string lastLine = lines.ElementAt(lines.Count());
    

    Говорит только о том, что здесь явно не IEnumerable нужен. ElementAt — это просто не родная операция для него. Если решили использовать Count() или ElementAt() — то скорее контракт нарушен, когда заводили переменную/параметр типа IEnumerable