gilch

And that's... bad? Culture shock, sure, but this looks like fairly clean APL-style C to me. I would have wrapped some of those lines though.

At least for the contrived example from the article, the solution isn't to break up the code, but to use denser code. Use a regex.

Does anybody really think that e.g. sregex[1] is better than just learning and using the regex language directly? Because that's where this kind of thinking leads.

[1]: https://github.com/jwiegley/emacs-release/blob/master/lisp/o...

Python's lambdas can have as many lines as you want. Just wrap parens around it. Hissp uses this form as a compilation target. Its REPL shows the Python compilation. Play around with it til you get it: https://github.com/gilch/hissp

Idiomatic Python wouldn't use a map here, but a generator expression:

    (x.split('=')[1] for x in s.split('?')[1].split('&')[-3:])

Removing the lambda cuts down on the noise considerably.

And honestly, with this many splits with fixed indexes, I'd probably use a regex. Now there's a dense language for you.

The article starts with some reasonable premises, but the conclusion does not follow.

I think most APL programmers would disagree with this take. Dense code has real advantages, and naming everything has real costs that are hard to see. There's nothing magic about a "line" that suddenly allows for chunking. You have to build a parse tree in your head in any case.

I'm reminded of Doug McIlroy's challenge to Knuth.[1] It's worth a read. Would you rather have 6 lines of dense shell, or 10 pages of Fabergé egg? I'll take the shell, thanks.

Look at the source code for J (an APL derivative)[2]. It's written in C, but that C was written in APL style by APL programmers. Lines leverage macros and 1–2 character names, making them extremely dense. Some files have a comment on nearly every line. For an average C programmer, this code looks absolutely insane. But it's not. The J devs find this perfectly readable and maintainable. It's clean code! If written with the typical C idioms, it could easily be 10x as long, and therefore harder to maintain. Your first impression is a snap judgement due to a difference of culture. You can learn to read this style with practice. Whatever your current style, that took practice too.

[1]: http://www.leancrew.com/all-this/2011/12/more-shell-less-egg...

[2]: https://github.com/jsoftware/jsource

I think a trust can also buy $10,000. You can also gift I-bonds (say to family). I think they can only receive up to the $10k worth of gifts per year, less what they've bought themselves, but (and this is important) the bond itself starts earning interest immediately, when they are gifted, not when they are received. So the family member can just take it next year, after it's already started earning at this year's higher rate. I'm not a CPA or financial advisor, so please double-check me on this.

How close is Hissp? https://github.com/gilch/hissp

That's really only a concern for the first $10k in the first year. After that, everything (but your most recent year) is at least a year old and you can exit early if you have to.

> And while the yield is great on paper, it merely lets you keep up with inflation in practice.

True in the normal case, when inflation changes slowly, but because the I-Bond rate is computed retroactively, it's a better deal than normal when inflation suddenly increases.

[Not investment advice.]

I'm maxed out, and maxed out last year too.

If ones investments are in leveraged instruments like calls and futures, then after levering up to sensible levels of volatility (the Kelly Criterion implies there is a maximum level for ones bankroll and investments, no matter how high ones risk tolerance), one will still have a lot of cash left over that needs to be parked somewhere that at least keeps up with inflation.

I-bonds are attractive for this role because of the retroactive effects of recent inflation. But the cap means it's not enough for all of my excess cash. One who is below that cap might still want to keep a portion in something more liquid. In my case, it's a small enough fraction (because programmers are paid well in America) that I'm not too concerned about the lack of liquidity in the first year.

Something like Hebigo? https://github.com/gilch/hebigo#examples

Hissp might be easier to get started with. It's much less complex as a whole and has pretty thorough introductory docs.

Hardly a unique idea. J also does this in explicit function definitions, but with `)`. https://code.jsoftware.com/wiki/JPhrases/ExplicitDef

> "full" dependent types

From the quotation marks, I surmise that you're wondering what a non-full dependent type system could possibly mean. I added that qualifier because Python, in fact, had one, last I checked, with its `Literal` type (https://peps.python.org/pep-0586/#rejected-or-out-of-scope-i...), which is "a very simplified dependent type system", according to the PEP, but "True dependent types" are out of scope, at least for now.

I haven't worked with Haskell enough to fully object to this, so any complaints I could come up with would be second hand, so I'll abstain. I don't feel fluent in Haskell yet, but my impressions so far were mostly not negative.

I'm mostly complaining about static typing in the style of Mypy/Pyright and Java (and half of Scala, the other half is like Haskell). You know, the static typing one is likely to encounter in industry. But even Hindley-Milner isn't as expressive as fully dependent types like Agda or Idris. If you're going to use static typing at all, why not go all the way?

I found Scala horribly overwrought compared to either Java or Haskell. It's like it tried to mush together two different type systems and got the worst of both worlds. Languages do not need to be that complex. My next JVM language was Clojure, and I've never looked back. I'd try Kotlin before I'd go back to Scala.

Anecdote, but I like the Python community's emphasis on "readability counts". I did not get that from e.g. Ruby.

Python's internals are also relatively accessible and easy to work with, so it's smooth sailing once you have that need. The language starts out easy, and grows with you. Of the languages I've tried (and there are many), only Smalltalk and the Lisp family were comparable in expressiveness.

The language mostly gets out of my way and lets me do what I want. I don't feel like I have to fight the compiler (at least until I tried Mypy) or write a lot of tediously verbose boilerplate just to get out a "Hello, World!" like I did in Java.

Unlike, say, JavaScript, Python is pretty strongly typed and fails fast. The stack traces almost always point you to the exact location of the problem (unlike the JS tendency to propagate `undefined` everywhere). There aren't a lot of surprises or gotchas. I can pretty much run it in my head just by reading the code and be right most of the time. I cannot say the same for C++ or JavaScript, which naturally tend to become inscrutable without discipline.

Numpy uses magic methods (Python's version of operator overloading). Django uses metaclasses. Pytest dynamically rewrites assert statements using AST. I'd say it's pretty common, at least in libraries. I certainly depend on Python's dynamism when fully leveraging the REPL.

Even with strict static typing, it's possible to have errors. Mypy is static typing.

I do think that's helpful compared to the strict alternative, but much of the up-front cost is still there. You still write most things twice, and the static type checker still slows you down when prototyping. You'd still be tempted to write bad code to work around the insufficiently-expressive type language, rather than write it in the most natural way, and only give up when it's too hard.

You can also approach this from the other direction: why not start with a dynamic language for the rapid prototyping and gradually introduce typing as the code stabilizes? Python and Typescript do this.

Python's popularity has grown pretty steadily over decades. It retains users because of its merits and became popular in multiple niches more or less independently.

Mypy still couldn't handle recursive types, last I checked. Pyright can do it, but seems to have trouble with even basic type inference. The annotation syntax is working OK, although it tends a bit verbose, but the type checkers are still crippled IMHO.

You do know you can statically type Python, right?

And static languages introduce a whole class of issues that dynamic languages don't have to deal with. You have to learn a separate metalanguage just for the types that isn't expressive enough to do things that are easy in a dynamic language, and even if it were, you'd still have to write everything twice: once in the real language, and once again in the type language. And then you still have to test, don't pretend you don't. If tests are both necessary and sufficient, then why bother with the type language? The static typing is not worth the cost.

Python is statically typed though. [1][2][3][4]

These aren't just some third-party tools bolted on. The type annotation syntax is built into the language[5] and standard library[6][7].

I personally find static typing to be more trouble than it's worth most of the time. Industry typing metalanguages are not expressive enough to deal with even fairly basic real-world programs and force you to write bad code to work around the type checker's stupidity. And, of course, you still have to write tests. Maybe someday they'll catch up to Idris. Python's static typing is no better, but at least it allows you to turn it off when it's not worth it.

[1]: https://github.com/microsoft/pyright

[2]: https://github.com/python/mypy

[3]: https://github.com/google/pytype

[4]: https://github.com/facebook/pyre-check

[5]: https://peps.python.org/pep-3107/

[6]: https://peps.python.org/pep-0484/

[7]: https://docs.python.org/3/library/typing.html#module-typing

No shortage of options, e.g. Dg, Mochi, Coconut, and Hebigo (based on Hissp[1]).

[1]: https://github.com/gilch/hissp

Haskell can use brackets, people just don't.

Don't forget Hissp!

See https://www.reddit.com/r/whitespaceLisp/ for more examples.

Or go full circle: Whitespace to Lisp to Python.

https://github.com/gilch/hebigo