今夜からやろうかと思ったけどまだ正月休みしたい
January 4, 2026 at 11:19 AM
今夜からやろうかと思ったけどまだ正月休みしたい
コード書いてて複雑で難しいなと感じた時点でど設計がどこか間違ってると断定しちゃっていいと思っている、経験から
とはいえ最初から複雑だったわけじゃなくなんなら簡潔にするためにやってたはずのことが裏目に出て知らぬ間に複雑になっていくので悪気はないんだ
とはいえ最初から複雑だったわけじゃなくなんなら簡潔にするためにやってたはずのことが裏目に出て知らぬ間に複雑になっていくので悪気はないんだ
「こんな複雑なことをしないといけないのはおかしい」というソフトウェアエンジニアの勘 - valid,invalid
時折、「やりたいことに対してこんな複雑なことをしないといけないのはおかしい」という感覚がはたらく。ソフトウェアエンジニアの勘といってもいい。 FizzBuzz Enterprise Editionはプログラマジョークとして解されるが、実際のエンジニアリングではもっと微妙な形で表れる。たとえば設計やコードレビューの最中に「こうしたらどうなるだろうか」と思いつき、提案を実装した結果として管理すべき状態やコード量が減ったりする。(関連: 状態、結合、複雑性、コード量の順に最適化する - valid,invalid) あるいはシステム要件や仕様について話す中で表出することも多い。「新しい画面を作ってこ…
ohbarye.hatenablog.jp
December 31, 2025 at 4:52 AM
コード書いてて複雑で難しいなと感じた時点でど設計がどこか間違ってると断定しちゃっていいと思っている、経験から
とはいえ最初から複雑だったわけじゃなくなんなら簡潔にするためにやってたはずのことが裏目に出て知らぬ間に複雑になっていくので悪気はないんだ
とはいえ最初から複雑だったわけじゃなくなんなら簡潔にするためにやってたはずのことが裏目に出て知らぬ間に複雑になっていくので悪気はないんだ
行連結の処理がまあまあいい感じになって本当に良かった
lexerで気をつける必要がややあるものの基本的にはないものとして扱われるので面倒が減った
スクリプトを文字毎に分けた際に行連結記号はコメントや改行を含めて一文字扱いで存在してるので意味付けパーサーではそれをなんかいい感じに暗い色にするとかそういうことができたらいいですね
lexerで気をつける必要がややあるものの基本的にはないものとして扱われるので面倒が減った
スクリプトを文字毎に分けた際に行連結記号はコメントや改行を含めて一文字扱いで存在してるので意味付けパーサーではそれをなんかいい感じに暗い色にするとかそういうことができたらいいですね
December 28, 2025 at 4:02 PM
行連結の処理がまあまあいい感じになって本当に良かった
lexerで気をつける必要がややあるものの基本的にはないものとして扱われるので面倒が減った
スクリプトを文字毎に分けた際に行連結記号はコメントや改行を含めて一文字扱いで存在してるので意味付けパーサーではそれをなんかいい感じに暗い色にするとかそういうことができたらいいですね
lexerで気をつける必要がややあるものの基本的にはないものとして扱われるので面倒が減った
スクリプトを文字毎に分けた際に行連結記号はコメントや改行を含めて一文字扱いで存在してるので意味付けパーサーではそれをなんかいい感じに暗い色にするとかそういうことができたらいいですね
今年はこんなもんでいいでしょう
テストも動くようになったし
実装してないとこ多くてテスト通りはしないのだけれども
テストも動くようになったし
実装してないとこ多くてテスト通りはしないのだけれども
December 28, 2025 at 3:55 PM
今年はこんなもんでいいでしょう
テストも動くようになったし
実装してないとこ多くてテスト通りはしないのだけれども
テストも動くようになったし
実装してないとこ多くてテスト通りはしないのだけれども
ねんまつなのでおやすむつもりだったがキリが悪いのでもう少しやる
December 28, 2025 at 10:00 AM
ねんまつなのでおやすむつもりだったがキリが悪いのでもう少しやる
もうねんまつなのでおやすんでいいのでは？？？
December 24, 2025 at 3:56 PM
もうねんまつなのでおやすんでいいのでは？？？
わざわざローグライクにしたものをやりたいかというと
December 24, 2025 at 2:07 PM
わざわざローグライクにしたものをやりたいかというと
ビルトイン関数の表現を
struct BuiltinFunction<F, A> {
_f, PhantomData<F>, _a: PhantomData<A>
}
で表現できそう
Fは関数定義を表す構造体でAは引数を表す構造体
let result = BuiltinFunction::<Hoge, HogeArgs>::invoke()?;
みたいにできる
struct BuiltinFunction<F, A> {
_f, PhantomData<F>, _a: PhantomData<A>
}
で表現できそう
Fは関数定義を表す構造体でAは引数を表す構造体
let result = BuiltinFunction::<Hoge, HogeArgs>::invoke()?;
みたいにできる
December 21, 2025 at 5:37 AM
ビルトイン関数の表現を
struct BuiltinFunction<F, A> {
_f, PhantomData<F>, _a: PhantomData<A>
}
で表現できそう
Fは関数定義を表す構造体でAは引数を表す構造体
let result = BuiltinFunction::<Hoge, HogeArgs>::invoke()?;
みたいにできる
struct BuiltinFunction<F, A> {
_f, PhantomData<F>, _a: PhantomData<A>
}
で表現できそう
Fは関数定義を表す構造体でAは引数を表す構造体
let result = BuiltinFunction::<Hoge, HogeArgs>::invoke()?;
みたいにできる
まあでもバージョン2の開発はバージョン1の実装の悪さ故ににっちもさっちもいかなくなったことが原因なので、ヤバいとこつぶせるうちに潰しとかないとバージョン3の開発が始まってしまう
December 20, 2025 at 4:13 AM
まあでもバージョン2の開発はバージョン1の実装の悪さ故ににっちもさっちもいかなくなったことが原因なので、ヤバいとこつぶせるうちに潰しとかないとバージョン3の開発が始まってしまう
字句解析でエラーが生じた際の挙動も見直すことにした、良かれと思って今の実装にしたものの取り扱いが極めて面倒なのにそれにより得られるメリットが特になくってェ…
December 20, 2025 at 4:12 AM
字句解析でエラーが生じた際の挙動も見直すことにした、良かれと思って今の実装にしたものの取り扱いが極めて面倒なのにそれにより得られるメリットが特になくってェ…
字句解析用のメソッドたくさん書いたのに今になってなんでこの構造体にimplしてんの…？責務考えろよ！ばか！ということがあり来週はまた大掛かりなリファクタリングが始まる
December 20, 2025 at 4:09 AM
字句解析用のメソッドたくさん書いたのに今になってなんでこの構造体にimplしてんの…？責務考えろよ！ばか！ということがあり来週はまた大掛かりなリファクタリングが始まる
Option<impl Into<Hoge>>を取る引数にNoneを渡すと型アノテーションが必要 (None::<T>のTが不明なので) って怒られるの気持ちはわかるんだけどNoneである以上中の型どうでもよくね！？って思う
December 19, 2025 at 4:33 AM
Option<impl Into<Hoge>>を取る引数にNoneを渡すと型アノテーションが必要 (None::<T>のTが不明なので) って怒られるの気持ちはわかるんだけどNoneである以上中の型どうでもよくね！？って思う
文字に分解する際に行連結記号+コメントの場合はコメント付き行連結を示す文字オブジェクト的なものにして、字句解析のときにはうまいことやるしかない
あとあれだtextblock内もルールが適用されないはずなのでそのへんも考慮しねーと…
あとあれだtextblock内もルールが適用されないはずなのでそのへんも考慮しねーと…
December 18, 2025 at 7:43 PM
文字に分解する際に行連結記号+コメントの場合はコメント付き行連結を示す文字オブジェクト的なものにして、字句解析のときにはうまいことやるしかない
あとあれだtextblock内もルールが適用されないはずなのでそのへんも考慮しねーと…
あとあれだtextblock内もルールが適用されないはずなのでそのへんも考慮しねーと…
行連結記号の仕様がクソすぎてアカンのですわ
- 行末に`_`があれば行連結 (改行がないものとする
- `_`から改行までのホワイトスペースは無視され行連結する
- ホワイトスペース以外では`//`があったら以降はコメントなのでこれも行連結する
が基本ルールなので
abc_
def
はabcdefだし
abc_ // コメント
def
もabcdef
ただし文字列リテラルの中は例外で
print "abc_
def"
は有効なのに
print "abc_ // コメント
def"
は無効にしなければならない
字句解析前に整形できれば楽なのにこの例外のせいでそれができないのサァッ
- 行末に`_`があれば行連結 (改行がないものとする
- `_`から改行までのホワイトスペースは無視され行連結する
- ホワイトスペース以外では`//`があったら以降はコメントなのでこれも行連結する
が基本ルールなので
abc_
def
はabcdefだし
abc_ // コメント
def
もabcdef
ただし文字列リテラルの中は例外で
print "abc_
def"
は有効なのに
print "abc_ // コメント
def"
は無効にしなければならない
字句解析前に整形できれば楽なのにこの例外のせいでそれができないのサァッ
December 18, 2025 at 7:39 PM
行連結記号の仕様がクソすぎてアカンのですわ
- 行末に`_`があれば行連結 (改行がないものとする
- `_`から改行までのホワイトスペースは無視され行連結する
- ホワイトスペース以外では`//`があったら以降はコメントなのでこれも行連結する
が基本ルールなので
abc_
def
はabcdefだし
abc_ // コメント
def
もabcdef
ただし文字列リテラルの中は例外で
print "abc_
def"
は有効なのに
print "abc_ // コメント
def"
は無効にしなければならない
字句解析前に整形できれば楽なのにこの例外のせいでそれができないのサァッ
- 行末に`_`があれば行連結 (改行がないものとする
- `_`から改行までのホワイトスペースは無視され行連結する
- ホワイトスペース以外では`//`があったら以降はコメントなのでこれも行連結する
が基本ルールなので
abc_
def
はabcdefだし
abc_ // コメント
def
もabcdef
ただし文字列リテラルの中は例外で
print "abc_
def"
は有効なのに
print "abc_ // コメント
def"
は無効にしなければならない
字句解析前に整形できれば楽なのにこの例外のせいでそれができないのサァッ
理屈は合ってるはず…！と思ったけど理屈が間違ってるのでバグってんでは！！？？？
December 18, 2025 at 6:59 PM
理屈は合ってるはず…！と思ったけど理屈が間違ってるのでバグってんでは！！？？？
便利イテレータを作ろうとしたらスタックオーバーフローする、やばい
December 18, 2025 at 6:58 PM
便利イテレータを作ろうとしたらスタックオーバーフローする、やばい
UWSCだと
call "hoge.uws(<#DBL>はわわ<#DBL>)"
みたいなのが書けてしまうので予め特殊文字を置換しつつも置換前の文字の位置を維持できるようにするイテレータを書いた
ちなみに途中で
call "hoge.uws(<#DB_
L>はわわ<#DBL>)"
に対応しないといけないことに気付いたのでやった
そんでさらにOPTION SPECIALCHARには仕様上対応できないので頭抱えたがUWSCも対応してなかったからセーフ
call "hoge.uws(<#DBL>はわわ<#DBL>)"
みたいなのが書けてしまうので予め特殊文字を置換しつつも置換前の文字の位置を維持できるようにするイテレータを書いた
ちなみに途中で
call "hoge.uws(<#DB_
L>はわわ<#DBL>)"
に対応しないといけないことに気付いたのでやった
そんでさらにOPTION SPECIALCHARには仕様上対応できないので頭抱えたがUWSCも対応してなかったからセーフ
December 17, 2025 at 6:29 PM
UWSCだと
call "hoge.uws(<#DBL>はわわ<#DBL>)"
みたいなのが書けてしまうので予め特殊文字を置換しつつも置換前の文字の位置を維持できるようにするイテレータを書いた
ちなみに途中で
call "hoge.uws(<#DB_
L>はわわ<#DBL>)"
に対応しないといけないことに気付いたのでやった
そんでさらにOPTION SPECIALCHARには仕様上対応できないので頭抱えたがUWSCも対応してなかったからセーフ
call "hoge.uws(<#DBL>はわわ<#DBL>)"
みたいなのが書けてしまうので予め特殊文字を置換しつつも置換前の文字の位置を維持できるようにするイテレータを書いた
ちなみに途中で
call "hoge.uws(<#DB_
L>はわわ<#DBL>)"
に対応しないといけないことに気付いたのでやった
そんでさらにOPTION SPECIALCHARには仕様上対応できないので頭抱えたがUWSCも対応してなかったからセーフ
まるで意味がわからんぞなバグに遭遇している
バグの発生箇所以外は想定通りに動いているせいでなんでそこだけバグってんのかまったくわからない
バグの発生箇所以外は想定通りに動いているせいでなんでそこだけバグってんのかまったくわからない
December 16, 2025 at 6:08 PM
まるで意味がわからんぞなバグに遭遇している
バグの発生箇所以外は想定通りに動いているせいでなんでそこだけバグってんのかまったくわからない
バグの発生箇所以外は想定通りに動いているせいでなんでそこだけバグってんのかまったくわからない
ピンク・レディー🍎たべた
すっぱくてうまい
すっぱくてうまい
December 15, 2025 at 6:39 AM
ピンク・レディー🍎たべた
すっぱくてうまい
すっぱくてうまい
ところでUWSCだとconstで配列を宣言できないのだけれどあれはなんなのだろうね
December 15, 2025 at 5:09 AM
ところでUWSCだとconstで配列を宣言できないのだけれどあれはなんなのだろうね
オブジェクト参照とかね、ほかでオブジェクトの値変えられちまうことを防ぎようがないのだけれど、あるオブジェクトの参照である、ということは不変にできるのでまあ文脈的にもおかしくないよねって
December 15, 2025 at 5:08 AM
オブジェクト参照とかね、ほかでオブジェクトの値変えられちまうことを防ぎようがないのだけれど、あるオブジェクトの参照である、ということは不変にできるのでまあ文脈的にもおかしくないよねって
constと新たに追加予定のletについて、これらで宣言した定数は不変であることを保証すべくいろいろ検討してみたもののどうにもならん部分もあるので代入式の左辺にするとエラーになるくらいが落とし所になりそう
December 15, 2025 at 5:06 AM
constと新たに追加予定のletについて、これらで宣言した定数は不変であることを保証すべくいろいろ検討してみたもののどうにもならん部分もあるので代入式の左辺にするとエラーになるくらいが落とし所になりそう