Forwarded from Питерач • Новости Питера
🤔 На экономическом форуме РБК разместил интересный слоган-ребус.
Про бизнес, конечно же.
Про бизнес, конечно же.
😁9❤4👍1🔥1🤔1
#лингво
en.wikipedia.org/wiki/James_while_John_had_had_had_had_had_had_had_had_had_had_had_a_better_effect_on_the_teacher
(thanks @egorku)
en.wikipedia.org/wiki/James_while_John_had_had_had_had_had_had_had_had_had_had_had_a_better_effect_on_the_teacher
(thanks @egorku)
Wikipedia
James while John had had had had had had had had had had had a better effect on the teacher
sentence used to emphasize lexical ambiguity and the importance of punctuation
🔥4👍2
Вышел из поезда.
Прошёл через турникет.
Подумал, что чего-то не хватает.
Понял, что не хватает зонта.
Решил, что оставил зонт в поезде, то есть фактически потерял.
Слегка расстроился и решил купить новый.
Спустя мгновение понял, что держу зонт под подмышкой.
Прошёл через турникет.
Подумал, что чего-то не хватает.
Понял, что не хватает зонта.
Решил, что оставил зонт в поезде, то есть фактически потерял.
Слегка расстроился и решил купить новый.
Спустя мгновение понял, что держу зонт под подмышкой.
🙏11👏6❤1
Блог*
Вышел из поезда. Прошёл через турникет. Подумал, что чего-то не хватает. Понял, что не хватает зонта. Решил, что оставил зонт в поезде, то есть фактически потерял. Слегка расстроился и решил купить новый. Спустя мгновение понял, что держу зонт под подмышкой.
Is it some kind of joke that I am too unpremium to understand?
🐳27🙏6🤣3👏1😢1
<илья as Человек>
Я НАШЁЛ Я НАШЁЛ ТУ САМУЮ СТАТЬЮ ГДЕ ПОКАЗЫВАЕТСЯ ПЛОХАЯ СТОРОНАЯ ГО И СРАВНИВАЕТСЯ С РАСТОМ https://fasterthanli.me/articles/i-want-off-mr-golangs-wild-ride
#prog #go #article
Experience Report: 6 months of Go
Later, while I was doing background research around previous posts on Go, and people’s responses to them, one comment stood out to me:
> I think Go follows the Worse Is Better principle. Which could explain why simplicity was chosen above correctness and completeness.
<...>
One of the things I realized that I was refusing to internalize was that the Go team prioritizes keeping implementation complexity down a LOT more than folk implementing other mainstream languages that I know of.
To half of my brain, this statement seems absurd at face value. That half indignantly insists, “Of course, complexity should be moved into the language as much as possible if it makes things better for language users! There are many more language users than implementors!” I suspect this is partly an outcome of and partly a cause for why I ended up working on Swift.
<...>
At the same time, I think for me, the MIT approach is so much more closer to how I think about software design and correctness, that even though I can “get” the New Jersey style in the abstract, it’s very difficult for me to internalize it. There is a serious cognitive effort that is needed to overcome the impedance mismatch between a conception of “how things ought to work” and the reality of “how things actually work.”
Experience Report: 6 months of Go
Later, while I was doing background research around previous posts on Go, and people’s responses to them, one comment stood out to me:
> I think Go follows the Worse Is Better principle. Which could explain why simplicity was chosen above correctness and completeness.
<...>
One of the things I realized that I was refusing to internalize was that the Go team prioritizes keeping implementation complexity down a LOT more than folk implementing other mainstream languages that I know of.
To half of my brain, this statement seems absurd at face value. That half indignantly insists, “Of course, complexity should be moved into the language as much as possible if it makes things better for language users! There are many more language users than implementors!” I suspect this is partly an outcome of and partly a cause for why I ended up working on Swift.
<...>
At the same time, I think for me, the MIT approach is so much more closer to how I think about software design and correctness, that even though I can “get” the New Jersey style in the abstract, it’s very difficult for me to internalize it. There is a serious cognitive effort that is needed to overcome the impedance mismatch between a conception of “how things ought to work” and the reality of “how things actually work.”
Typesanitizer
Experience Report: 6 months of Go
A report of my positive and negative experiences with Go after using it for 6 months at work.
Блог*
#prog #go #article Experience Report: 6 months of Go Later, while I was doing background research around previous posts on Go, and people’s responses to them, one comment stood out to me: > I think Go follows the Worse Is Better principle. Which could explain…
Telegram
Блог*
#prog #go
Замечательный канал, всем рекомендую.
@golang_the_best
Замечательный канал, всем рекомендую.
@golang_the_best
#soc #article
Not Rocket Science (Meeting Edition)
You know what else feels like a waste of collective time? When the CI is broken due to some failure which was introduced but not checked in PR testing, preventing people from landing their patches. In the context of CI, Graydon Hoare has this fun blog post from 2014: “Not Rocket Science” rule of software engineering. It proposes the following:
The Not Rocket Science Rule Of Software Engineering
Automatically maintain a repository of code that always passes all the tests
You can read the post for details, but my takeaway from it is that it is intended to save collective time at the expense of individual time. Also, it’s not a particularly genius idea; it requires some setup and work but it should be doable for many teams.
I’d like to propose a similar rule for meetings.
The Not Rocket Science Rule of Meetings
Planned meetings of three or more people should be accompanied by shared, written and persistent meeting notes, consisting of an agenda before the meeting, and added minutes after the meeting.
Not Rocket Science (Meeting Edition)
You know what else feels like a waste of collective time? When the CI is broken due to some failure which was introduced but not checked in PR testing, preventing people from landing their patches. In the context of CI, Graydon Hoare has this fun blog post from 2014: “Not Rocket Science” rule of software engineering. It proposes the following:
The Not Rocket Science Rule Of Software Engineering
Automatically maintain a repository of code that always passes all the tests
You can read the post for details, but my takeaway from it is that it is intended to save collective time at the expense of individual time. Also, it’s not a particularly genius idea; it requires some setup and work but it should be doable for many teams.
I’d like to propose a similar rule for meetings.
The Not Rocket Science Rule of Meetings
Planned meetings of three or more people should be accompanied by shared, written and persistent meeting notes, consisting of an agenda before the meeting, and added minutes after the meeting.
Typesanitizer
Not Rocket Science (Meeting Edition)
An argument for why you should have a written agenda and minutes for meetings that you organize. Loosely inspired by Graydon Hoare
👍1🌭1
#prog #article
A Cursed Bug
When you start dealing with large distributed systems, you see a lot of intermittent weird bugs, and it’s basically inevitable that you’ll never track down or diagnose all of them. But it turns out that sometimes, with a bit of luck and persistence, even the hairiest ones can sometimes be tracked down.
A Cursed Bug
When you start dealing with large distributed systems, you see a lot of intermittent weird bugs, and it’s basically inevitable that you’ll never track down or diagnose all of them. But it turns out that sometimes, with a bit of luck and persistence, even the hairiest ones can sometimes be tracked down.
Made of Bugs
A Cursed Bug
In my day job at Anthropic, we run relatively large distributed systems to train large language models. One of the joys of using a lot of computing resources, especially on somewhat niche software stacks, is that you spend a lot of time running into the long…
🔥1