Re: COBOL programmers answer call
       
I asked a few friends about the New Jersey call. They (2 of them, both retired and over 70) claimed there's no work to be done and it's actually an incompetently administered administration with human problems who are scapegoating the technology. Also supposedly the New Jersey govt sacked their team and then was trying to contract out the work at $50/hr. Now they are offering $0/hr. And the solution isn't in software, or so they claimed.

This assessment was after both signed up to volunteer to do the work and saw it was a human process failing and not a software issue. People tend to point to the parts most mysterious to them when things start to fail - a zSeries frame is in actual reality, a very important big black mystery box that officials with access to microphones are not allowed to touch - perfect.

Don't let this discourage you though, their problems are still very real.
       
kristopolous, 1 hour ago

Интересная лекция Automating Abstract Interpretation от одного из крупнейших специалистов в области статического анализа:

https://www.youtube.com/watch?v=wiYfS1aoAAg

Что касается лично меня (как бывшего преподавателя), то я не согласен с Вашими prior assumptions, так сказать. 😊 Я не вижу, чтобы драверописательсво (или embedded в целом) было как-то особенно актуально и востребовано, по моему опыту у большинства студентов НЕ возникает вопроса "как оно на самом деле работает в компьютере", и язык ассемблера знать они вообще не хотят. Так что остаюсь при своём мнении. 😊

От региона, может, зависит? У нас вот, наоборот, на драйверописателей спрос.

Кстати, вопрос: пытался ли кто-нибудь делать эмс... абстрактную компиляцию? Ну. То есть. Цель абстрактной интерпретации вычислить некоторые предикаты. Эти же вычисления можно (?) откомпилировать в машинный код по исходнику конкретной программы. По идее, если разработка итеративная, то время компиляции может быть амортизировано. Или это бессмысленно?

Все. Всех желающих преподавателей добавляю в новую группу https://t.me/teach_cs :)

А что будет представлять собой результат компиляции над абстрактными доменами? Абстрактно скомпилировали мы, допустим, калькулятор, и он нам на "2 + 2" отвечает "четное число"? :)

Ну... Да. Но мы же можем скомпилировать и f(x) = 2*x. И потом, везде, где f вызывают, будет вызвана эта склмпилированная абстракция и обновлять как-то предикаты.

То есть скомпилировать конкретно этот кусок кода, и если встречаем 2*x то вставлять уже скомпилированный кусок кода без повторной компиляции?

Кусок кода абстрактной интерпретации. Нет, ну а что? Она же описывается "обычной" операционной семантикой. Можно перевести в скомпилированный код или в VM хотя бы, чтобы каждый раз не сопоставлять куски программы.

Если брать мелкие варианты по типу 2*x, то хранить их в скомпилированном виде, хранить в АСТ виде, и постоянно сверять АСТ с ним будет слишком затратно
Если же большой участок кода повторяется несколько раз, проще его вынести в функцию, тогда тоже скомпилируется один раз

Объясните пожалуйста. Как я понимаю, Haskell не требует юнит-тестов, потому что сам язык обеспечивает гарантии. Код супер-надёжен. Но юнит-тесты всё таки пишут. Например servant. Почему так получается?

Haskell конечно надежный но все же у него нету зав типов как у Idris

тоже есть тесты

наверное потому что он общего назначения и для io например хочешь не-хочешь а тесты придется писать?

> Как я понимаю, Haskell не требует юнит-тестов
Это не так. Подробности можешь тут узнать - @supapro

правильно ли я понимаю, что для io языки подобные Haskell не дают особых преимуществ перед менее типизированными языками?

А в чем вы измеряете преимущества ?

Дают

там чатик про плюсы, странно