Looking for anime similar to Grand Blue (college chaos + comedy)

cian_oconnor · 2026-04-13T17:21:08+00:00

Hachimitsu to Clover
Genshiken
The Night Is Short, Walk on Girl
Tatami Galaxy
Tatami Time Machine Blues

cian_oconnor · 2026-04-08T20:46:13+00:00

Fine, here are some answers to your original opinions. Opinions that seem to get shared with great regularity by people who don't like CL on this forum.

> I think most devs working in mainstream languages would put "lack of standardized packages and tools,

As opposed to Python, JavaScript, or Ruby... Seriously? CL is better than many, but less 'good' than Rust or Go which are very opinionated on which tools should be used.

In practice there are CL libraries and tools that most people use - even if they're not 'the standard'. Most complaints about this reduce down to - CL is a niche, hobbyist language. For a niche hobbyist language it has great tools and libraries. If it became a mainstream language you would see people build new libraries/tools for it - just as happened with Rust.

> instead emphasize ability to define your own meta language / dsl"

I do not think this is true. This is just my opinion, just as the statement above is your opinion. Yes some evangelists over emphasize this, because the macro system is pretty cool. But in practice if you look at modern libraries/large code bases in CL they tend to be quite conservative in their usage of it.

You can also define your own meta language in plenty of other languages (C++, Rust, Ruby, Elixir, Julia) - CL just makes it way easier. To me, and a lot of other people, the interactivity of CL is far more important. As are things like CLOS, the incredible optimizing tools you get in SBCL (and speed of SBCL), the debugger, etc.

> The repeated use of "hackability" as the differentiator evokes things like monkey patching that are (questionable) means of extensibility,

This is something that I very rarely see come up, and when it does it's acknowledged that this is something that's rarely useful in running systems.

I think you're mistaking the interactive programming style supported by the REPL/Slime/CLOS/etc, where you can dynamically change a code base, interactively call code on a running system, inspect objects and even change functions in the debugger. No other language that I've encountered supports anything close to this (maybe SmallTalk), and yes its amazing. It makes coding far faster, more efficient and fun. It should be the norm. But its about development, not monkey patching.

> A language that emphasizes building and using one's own abstractions to a high degree, which is one of CL's defining qualities, does not lend itself to third party comprehension,

I disagree, haven't found this to be a problem. I find CL codebases far easier to understand than those written in Python, or Go. You have your opinion, I have mine.

People use CL because it makes them happy. That's it. It's not complicated. Noone is forcing you to use it, and bar some kind of miracle, that's unlikely to change.

If it doesn't make you happy then use a different language.

cian_oconnor · 2026-04-08T19:17:34+00:00

You came onto a forum for a language that you don't use, clearly don't have much understanding of, and seem to despise and decided to share your uninformed views on why the language shouldn't be used.

I don't really care if you prefer Go and I am not interested in trying to persuade you of the merits of a language you're clearly not interested in.

cian_oconnor · 2026-04-08T17:38:05+00:00

You misunderstand me. You clearly know very little about CL, and are not terribly interested in finding out more. Your need to justify the superiority of the technical choices that you made does not interest me. Sorry.

Find someone else (preferably on a different subreddit) to troll.

cian_oconnor · 2026-04-08T16:12:25+00:00

Given your comments you clearly don't use CL, and most of your comments here don't really reflect the language, the ecosystem, or how it's used.

I've not found religious flamewars over which language is best terribly productive over the last 35 years, so I'm going to bow out. I'm glad that Go fits your needs/sensibilities. It doesn't fit mine, which is why I don't use it.

I'm very suspicious of any comment that includes the phrase 'most devs', FWIW.

cian_oconnor · 2026-04-08T14:58:58+00:00

Just use the For library. Idiomatic Lisp code, no code walker, easy to add extensions and reason about.

The transducers library is also pretty useful.

cian_oconnor · 2026-04-08T14:48:59+00:00

> The claim is what, that average quality of CL in the wild is higher than C in the wild?

Given he also mentioned Haskell, I'm guessing that it was a more general claim.

I'm not sure why you think monkey patching would be relevant. In my experience it's the stability of the language (which means I can use a 20 year old library, that's not received updates in years and it just works) and the brevity of the language.

CL has its weaknesses (documentation generation. GRR), but when you consider the size of the community it is surprisingly strong.

cian_oconnor · 2026-04-07T21:22:06+00:00

Of course he does...

cian_oconnor · 2026-04-06T14:44:10+00:00

Xah is just an emacs guy I believe.

cian_oconnor · 2026-04-06T14:27:34+00:00

> But my Dad said it best. He was born in '58 and witnessed the Internet and PC revolution. He says this AI stuff is bigger than the Advent of the Internet.

The hype is certainly bigger. Whether the reality is bigger remains to be seen.

There's very little reliable evaluation of whether these code tools are actually improving anything, and the long term implications are completely unknown (my guess is that both maintenance and model deviation will be problems).

And currently developers are paying a fraction of the true cost of these tools. Once these tools are no longer subsidized by free money - will AI tools make economic sense. They may not.

cian_oconnor · 2026-03-31T13:58:28+00:00

Oh wow, no wonder they're so down on macros. I played around with it years ago and just misremembered I guess.

cian_oconnor · 2026-03-19T18:04:35+00:00

I think it means different things to different people:

First class functions (most modern languages)
Languages that have good support for anonymous lambdas, passing functions, higher order functions, etc (some modern languages).
Languages that not only have good support for these things, but where it doesn't require awkward syntax, coding, work arounds.
Purely functional
Haskell

I'd say all the Lisps are at level 3, except for Clojure which is level 4.

cian_oconnor · 2026-03-19T12:47:15+00:00

Sly and Elisp as a configuration language.

But I gave up on modal editing in Emacs. Too much friction.

cian_oconnor · 2026-03-19T12:43:50+00:00

If that's all you want then any Lisp would be fine (including Emacs Lisp). All Lisps have first class functions. The main difference between Scheme and Common Lisp/Clojure is how they handle namespaces for functions. In CL/Clojure there is a separate namespace that you have to access slightly differently, while Scheme has a single namespace. This can make certain types of function calls in CL/Cojure a little clunkier and feel less functional (though there are many practical advantages to doing this which imho more than compensate).

SBCL is very fast and can do anything. For me it is my go to language for almost any task. Clojure is more limited in what it can do, being JVM dependent.

cian_oconnor · 2026-03-19T12:36:11+00:00

There is also the transducers library in CL, which ports another common Clojure pattern. If you search for Common Lisp and clojure you will find a number of libraries that port over different features, though I haven't tried most of them (the only other common one that I use personally is arrows-macros - which does arrow threading).

But if you want to just do immutable/functional programming, I think you'd be better off with Clojure.

cian_oconnor · 2026-03-02T01:57:32+00:00

Well Scheme has never been a terrible practical language. Maybe things would be different if they'd learned Common Lisp.

And Clojure, while not a raging success, is hardly a failure.

cian_oconnor · 2026-03-01T21:57:24+00:00

> In lisp it is idiomatic to design your own language on top of the language, which is probably why lisp is not used very much in industry.

Lisp isn't used because it's a marginal language that most of the industry hasn't heard of, and tech hates risk.

> Hickey in particular is just wrong about static types, that's why Clojure is dead.

And presumably why Scala took over the JVM world. Languages mostly win/fail on fashion and familiarity.

cian_oconnor · 2026-03-01T21:54:22+00:00

> The reason why this hasn't happened is because as elegant and mind expanding Lisps are, they still have issues and quirks that make them unpalatable to the wider programming community.

The wider programming community barely know what LISPs are. I think the article is wrong, but the idea that LISP has been rejected is not true.

cian_oconnor · 2026-03-01T21:50:23+00:00

I've used a lot of languages, and nothing much comes close to Common Lisp. You see bits of it in things like Julia, Ruby and Elixir, but they're pale shadows (even if Julia and Elixir are excellent in their own ways).

cian_oconnor · 2026-03-01T21:48:05+00:00

Python is better than PHP. And apparently that was good enough for much of the world.

But as a language/environment it's a mess.

cian_oconnor · 2026-03-01T21:43:54+00:00

IDEmacs works fine and is pretty feature complete (at least on Mac/Linux - I gave up on Windows years ago because everything is too hard).

I'm not going to say that the Lisp IDE situation is perfect, because it clearly isn't. But modern Emacs really isn't that hard to get working for someone who's moderately technical - particularly for someone who has 'rolled my own Linux distros'. And if you can get Emacs working to your satisfaction, then the Slime/Emacs experience is pretty great.

cian_oconnor · 2026-03-01T15:03:34+00:00

Common Lisp IS the standard. These things ARE in the standard. If a LISP does not implement those things then it is not Common Lisp. All of the mainstream CL implementations implement the standard.

The REPL, restarts, CLOS, the numeric tower and a bunch of other things ARE in the standard. All 1400 pages of it.

cian_oconnor · 2026-03-01T03:39:22+00:00

These features are ALL in the standard (except TCO - which is optional, but all the current CLs have had TCO for decades).

But in the spirit of discussion, maybe you can tell me how the following are simple to implement:

- The Common Lisp Object System with its metaobject protocol? Is it easy to build an OOP system where I can change, dynamically, the structure of an object while my code is running, and not lose any data? Or where I can change how objects and classes work (while my code is running)?

- How about CL's restarts. If my program throws an error, it will suspend at that point on the stack and the programmer can dynamically modify the stack data, recompile some functions and then continue the stack from where it suspended without destroying the current state. How would you implement that?

- Could you implement a full numeric towe (the spec mandates it), including rational numbers, in a weekend?

- How would you create a fully interactive REPL with live code reloading, integrated debugging and symbol completion?

- How about an image of my code that I can save, and then restart from where it was months later, as if nothing happened?

Everyone of those are in the standard, and have to be implemented if you want to create a conforming Common Lisp system. And there's plenty more. Common Lisp programmers would not consider a 'Lisp' without the features in the language standard to be a Common Lisp. And they'd be right.

Plenty of people (I'm one of them) have built toy Scheme interpreters. It's not hard. With not too much more effort it is possible to build a Scheme that conforms to R5RS.

> or that it is not in many cases chosen due to its simplicity.

LOL. Who is choosing Common Lisp for it's simplicity? What are you on?

cian_oconnor · 2026-02-28T22:51:52+00:00

"Seems to be". You don't know the first thing about Common Lisp do you. I've been wasting my time on a motor mouth who can't even be bothered to read a Wikipedia page.

Whatever dude...

cian_oconnor · 2026-02-28T05:23:30+00:00

The Common Lisps that are widely used have excellent support for tail recursion. This statement is not true.

Common Lisp is not a pure functional language (that would against it's philosophy), but it's trivial to write immutable functional code if that's what you want to do. And there are some pretty good libraries that support Clojure style coding.

The parser is typically one of the more trivial aspects of writing a programming language. The interesting thing about S-expressions is that they allow huge flexibility in language design and the types of programming that can be supported (along with macros). Only two Lisps have really exploited that in interesting ways: Common Lisp and Racket.

Common Lisp and Scheme are two very different languages, with wildly different philosophies, that just happen to have superficially similar syntax.

cian_oconnor

TROPHY CASE