Kentaro Inomata matarillo

Keynote: Debug your thinking

There’s a myriad of complexity involved in building systems. However, two decades in software engineering taught me what truly makes or breaks a system: decisions. It’s not the programming language, the data store, the deployment model, or [insert your favorite tech here]. It’s about the decisions made and the ripple effects they cause. We spend endless hours trying to keep up with the latest and greatest in an industry that sprints faster than a caffeinated cheetah... But how much time was invested in questioning, improving, or, essentially, debugging our thinking process?

How do you structure your decisions, and how do they affect the software you build? When suboptimal decisions occur, do you reflect on the decision-making process itself? I've spent the last few years debugging my decision-making thought process, placing breakpoints to inspect which assumptions got me here and what alternatives I may have mi

Claude3のまとめ

オブジェクト指向プログラミング（OOP）は、1960年代後半にAlan Kayらによって提唱され、Smalltalkの開発を通じて具体化されました。当初のオブジェクト指向の概念は、メッセージングを中心とした動的で柔軟なシステムの構築を目指していました。オブジェクト同士がメッセージを介して相互作用することで、プログラムの振る舞いが決定されるという考え方は、従来の手続き型プログラミングとは大きく異なるものでした。

オブジェクト指向の発展において、学術的な場が果たした役割は非常に大きいと言えます。OOPSLAをはじめとする国際会議や、各種学術誌での議論は、オブジェクト指向の概念を洗練し、新たな手法や言語の開発を促しました。カプセル化、継承、ポリモーフィズムといったオブジェクト指向の基本原則は、学術的な議論を通じて体系化され、現在に至るまで広く受け入れられています。

一方で、オブジェクト指向の本質的な考え方をめぐっては、意見の相違もあります。Kayらが提唱したメッセージングの概念は、動的型付けと親和性が高く、Smalltalkに代表されるような動的言語で活用されてきました。しかし、静的型付けを重視する立場からは、動的なメッセージングはシステムの複雑性を増大させ、実行効率や型安全性に課題があると指摘されます。また、オブジェクト指向分析と設計の手法についても、UMLなどは静的な構造の表現に偏っており、動的なメッセージングの側面を捉えきれていないとの批判があります。

オブジェクト指向プログラミングは、その誕生以来、絶え間ない進化を遂げてきました。1980年代から1990年代にかけて、C++やJavaなどの言語が登場し、オブジェクト指向の概念を静的型付けと融合させることで、大規模なソフトウェア開発に適用可能になりました。また、デザインパターンやSOLID原則など、オブジェクト指向設計の手法も確立され、ソフトウェアの品質向上に寄与してきました。

ピタゴラスの三角形

比率 (3, 4, 5) の和は 12
比率 (5, 12, 13) の和は 30
比率 (8, 15, 17) の和は 40
比率 (7, 24, 25) の和は 56
比率 (20, 21, 29) の和は 70
比率 (12, 35, 37) の和は 84
比率 (9, 40, 41) の和は 90
比率 (28, 45, 53) の和は 126

SponsorLink：フィードバックと前進

ダニエル・カズリーノ

元記事 https://www.cazzulino.com/sponsorlink-feedback.html

Translated By: DeepL Pro

SponsorLinkの紹介記事で述べたように、オープンソースの持続可能性は厄介なトピックだ。私は20年以上オープンソースをやっているので、この分野に対して全くの初心者というわけではない。私はとにかく「専門家」を信じていないので、個人的な経験や、過去に読んだり見たりした他の開発者仲間の行動などから判断しています。だから、もし十分明確でなかったら、私は自分以外の誰の代弁者でもない。私は "dotnet OSSコミュニティ "を代表しているわけでも、"OSSはどうあるべきか/どうあるべきか "や、ここでの "正しさ "や "間違い "を語っているわけでもありません。

Original: https://wiki.c2.com/?AlanKaysDefinitionOfObjectOriented

Translated by: https://www.deepl.com/ja/translator

アラン・ケイのオブジェクト指向の定義

以前からこのページをアップしようと思っていたのですが・・・。

AIハルシネーションの謎を解明: 深層学習における現象の解析 (Bard 著)

https://note.com/it_navi/n/n81fb83893995 のまねっこ

1. AIのハルシネーションとは？
  1.1. ハルシネーションの定義
  1.2. AIにおけるハルシネーションの歴史
  1.3. AIハルシネーションの種類

	package main

	import (
	"bufio"
	"bytes"
	"encoding/json"
	"fmt"
	"io/ioutil"
	"os"
	"strings"

	type Polynominal<'a>(x : 'a) =
	static member op_Implicit (x : 'a) = Polynominal x

	type Rational<'a>(x : 'a) =
	class end

	let x : Rational<Polynominal<float>> = Rational 1.0

	printfn "%A" x

	import { useState, useEffect } from "react";
	import { useAuth } from "react-oidc-context";

	const [UNAUTHENTICATED, AUTHENTICATING, AUTHENTICATED] = ["unauthenticated" , "authenticating", "authenticated"];

	function Content(props) {
	switch (props.authState) {
	case UNAUTHENTICATED:
	return (
	<p>

	[
	[
	{
	"title": "Keynote: Debug your thinking",
	"text": "There’s a myriad of complexity involved in building systems. However, two decades in software engineering taught me what truly makes or breaks a system: decisions. It’s not the programming language, the data store, the deployment model, or [insert your favorite tech here]. It’s about the decisions made and the ripple effects they cause. We spend endless hours trying to keep up with the latest and greatest in an industry that sprints faster than a caffeinated cheetah... But how much time was invested in questioning, improving, or, essentially, debugging our thinking process?",
	"courseText": "How do you structure your decisions, and how do they affect the software you build? When suboptimal decisions occur, do you reflect on the decision-making process itself? I've spent the last few years debugging my decision-making thought process, placing breakpoints to inspect which assumptions got me here and what alter