tshatrov

ichiran

Common Lisp2015–2022

tshatrov / ichiran

ichiran

Linguistic tools for texts in Japanese language

Languages & Compilers

Explore on GitHub Read Hacker News discussions

3Distinct people

6Mentions

1Explicit recommenders

414GitHub stars

REPOSITORY AT A GLANCE

What to know before exploring

What it is

Linguistic tools for texts in Japanese language

GitHub

Where it is used

No documented product use has been verified yet.

What people are saying

You're forgetting that there are only 3 (three) verb conjugations in English, of which two are almost always the same. Only a finite number of verbs have irregular…

Grue3 used a recommendation phrase. One indexed comment matches. This is a phrase match, not a verdict.

No classified warning is attached to this page. Read the discussions before treating silence as approval.

Also in these discussions

No other repository is repeatedly linked in the same discussions.

This week on Hacker News

Nov 7–Nov 14 UTC · Direct repository links and separately labeled related project stories. Indexed through 11/14/2026, 5:04:57 PM UTC.

No direct repository links were found in the indexed HN discussions over the past seven days. Older discussions are available below.

Mentions over time

HN mentions by year6 dated mentions

Observed mentions: 2015-06-26 18:58:45 UTC to 2022-11-04 14:07:12 UTC.

Counts come from the repository’s dated source evidence. Index cutoff: 2026-11-02 08:16:59 UTC.

View mention counts and date ranges

UTC ranges include their start and exclude their end. Select a period to filter the source evidence.
Period	Start (UTC)	End (exclusive, UTC)	Mentions	Comments
2015	2015-01-01 00:00:00 UTC	2016-01-01 00:00:00 UTC	1	1
2016	2016-01-01 00:00:00 UTC	2017-01-01 00:00:00 UTC	0	0
2017	2017-01-01 00:00:00 UTC	2018-01-01 00:00:00 UTC	1	1
2018	2018-01-01 00:00:00 UTC	2019-01-01 00:00:00 UTC	1	1
2019	2019-01-01 00:00:00 UTC	2020-01-01 00:00:00 UTC	2	2
2020	2020-01-01 00:00:00 UTC	2021-01-01 00:00:00 UTC	0	0
2021	2021-01-01 00:00:00 UTC	2022-01-01 00:00:00 UTC	0	0
2022	2022-01-01 00:00:00 UTC	2023-01-01 00:00:00 UTC	1	1

What Hacker News says

6 sources

vindarel·Nov 4, 2022

Alright, here's my little selection of projects. If you don't see a project in your field it doesn't mean there is no software or library. Are they as awesome as the Rust/Go projects? It depends. Is it an exhaustive list? No. For a list of companies using CL and more projects, old or current, see the other links. ## Music - [OpusModus](http://opusmodus.com/) - a comprehensive computer-aided environment for the whole work of music composition. [Proprietary]. - [OM7](https://github.com/openmusic-project/om7) - a new implementation of the OpenMusic visual programming and computer-aided composition environment including a number of improvements on graphical interface, computational mode, and connection to external software libraries. [GPL3][2]. - [ScoreCloud](https://scorecloud.com/) - A web and mobile application to automatically create musi

Read the rest

c notation from music performance or recordings. Built with LispWorks. ## DB tools - [Pgloader](https://github.com/dimitri/pgloader/) - Migrate to PostgreSQL in a single command!. [PostgreSQL License] - [Pgchart](https://github.com/dimitri/pgcharts) - A self-contained web application that takes as input an SQL query text and outputs its data as a chart. [No License Specified] ## Utils - [Cepl](https://github.com/cbaggers/cepl) - Code Evaluate Play Loop. [2-clause BSD]. - [Regex-coach](http://weitz.de/regex-coach/) - a graphical application for Windows which can be used to experiment with (Perl-compatible) regular expressions interactively. Freeware. ## Text editors - [Lem](https://github.com/cxxxr/lem) - Common Lisp editor/IDE with high expansibility. [MIT]. Works for many languages, has a LSP client. ## Math - [Maxima](https://sourceforge.net/projects/maxima/files/) - Computer Algebra System written in Common Lisp. [GPL2]. - https://github.com/susam/mathb A math pastebin ## Graphics - [Sketch](https://github.com/vydd/sketch) -A Common Lisp framework for the creation of electronic art, visual design, game prototyping, game making, computer graphics, exploration of human-computer interaction, and more. ## Productivity - [Grammarly](https://www.grammarly.com/) - Grammar checking. [Proprietary]. - [Deftask](https://deftask.com/) - Painless task management for teams. [Partly Open Source]. - [Ichiran](https://github.com/tshatrov/ichiran) - Linguistic tools for texts in Japanese language. [MIT]. - [Ballish](https://gitlab.com/ralt/ballish - a pretty fast code search tool. ### Window Manager - [Stumpwm](https://github.com/stumpwm/stumpwm) - The Stump Window Manager. ## Mobile Applications - [ScoreCloud Express](https://apps.apple.com/us/app/scorecloud-express/id566535238) - An iPhone and iPad application that automatically creates music notation from music performance or recordings. ### Games Just 2: - Kandria https://kandria.com/ - [sucle](https://github.com/terminal625/sucle) - A Minecraft clone (voxel game engine). [MIT]. - [Notalone](https://github.com/borodust/notalone) - You wake up nowhere in the night. Hungry zombies around, but your ol' pal "BOOMSTICK" is with you. [GPL3] My selection comes from https://github.com/azzamsa/awesome-cl-software

In Why Lisp?

mikekchar·Apr 20, 2019

If you want to see some typical code from me, here are the commits from an experimental side project: https://gitlab.com/mikekchar/testy/commits/master Some caveats: I was experimenting with a different way of doing OOP in JS. Here is a description of the design: https://gitlab.com/mikekchar/testy/blob/master/design.md There is also a coding standard that I was following: https://gitlab.com/mikekchar/testy/blob/master/coding_standa... It's not one that I advocate, it was one that I was experimenting with. Some of the code in there is not great. Some of it is OK. It's not a big project, but it will give you an idea of the scope I use when I make commits. I use a very conservative approach when programming -- I don't pull everything apart and then try to build it back up. Instead I refactor everything and make incremental improvement

Read the rest

s. Every commit should improve either the quality of the code or add functionality. Especially in this project, I was building a test framework, so I didn't have a test framework to work with. This meant I had to use an even more conservative approach than normal. However, like I said it should give you a good idea. Perhaps you think this is bad code. I don't think it is. It's got a strange style (because that was the point of the exercise), but generally it was quite nice to work with. There are 2 pretty nasty hacks that I made in order to get the framework bootstrapped. I would have improved them eventually, but I ended up ending the project early. If I were to really criticise my work here, I would say that my commit messages are pretty awful. Interestingly, the TODO items that I check off in the actual commit are quite good IMHO. Probably I should cut and paste them, but... it's a personal project in my spare time... I was being lazy :-P I guess I'm responding to your comment mainly to hopefully open your mind to different ways of doing things. Maybe you'll be able to see it, maybe you won't. One of the things I've found in this job is that there are a lot of people who are stuck in "It's either my way or it's crap". Your comment seems to indicate that you might be one of those people. But in the case you are not, I hope you'll find the code interesting. I've worked on small projects and I've worked on big projects (I once "owned" a million lines of code!). The style I use now evolved based on my experiences. My basic approach is to look at a piece of code and try to find a general strategy for what I want to do. If I don't know the code, that can take a long time, but once I've figured out what I'm doing, things can go pretty rapidly. I make a TODO list of what I'm planning to do. Then I look at the code for a minute or two and ask myself, "Can I get there from here?" If the answer is "No", then I ask myself, "What would I ideally want?" Then I write that down in my TODO. Usually it's a fair number of things. Normally those facilities require pure refactoring (i.e. changing the code in a way that doesn't change behaviour). I try to break up my challenge in such a way that I make an improvement to the code, and that keeps the behaviour intact. Sometimes before I start I need to write tests to document the current behaviour. So a typical session would be: Write test(s) that are lacking. Check in code. Refactor code to provide facility(s) that I'm going to want. Check in code. Make a behavioral change with tests. Check in code. Then go back to my TODO list to get the next step. I will leave "bad" code in the build -- sometimes for a very long time, if I don't have a good idea for how it "should" look. Even if there is a "good" way to represent it, I'll often put it off if I don't know that this "good" way is going to fit with the direction the code is going. Overworking a piece of code often leads to unintentional inflexibility and sometimes good looking code adds constraints that you don't need. However, because the code looks good, nobody will refactor it and remove the constraints, leading to overly complex code. If you've gotten this far, you can see some of the challenges for TBD with this method, though. Every change has to keep the system completely functional! This means very deliberate and very careful modifications. It's difficult, but there is plenty of upside. IMHO there is more upside than downside by quite a margin. YMMV (and I won't tell you that you must be a crap programmer simply because you do things differently than me ;-) ). Edit: I went through some of your commits on https://github.com/tshatrov/ichiran It's interesting to me that the commit size is not really that different than mine. There are a couple of places I would have split it up into 2 or 3 chunks, but we're not talking about order of magnitude stuff here. I'm curious how long you spend on a commit. Nice project, BTW. I'm not a stranger to building that kind of tool ;-) I actually built an English parser in FORTH once. I also built: https://github.com/mikekchar/JLDrill (which actually is awful code... and it doesn't actually run any more thanks to bitrot).

In Show HN: Why you should not use feature branches

Grue3·Mar 1, 2019

You can do it for dictionary words with a relatively high degree of accuracy, but it's very hard. I have developed the most accurate tokenizer that currently exists [1], but there are still sentences where it fails. Words written in hiragana create an inherent ambiguity because almost any combination of hiragana can be split into existing words in several ways. Another problem is proper names. This one is inherently unsolvable, because anything can be a word. You can have a dictionary of proper names, but there will still be people, companies, fictional characters who aren't in the dictionary. [1] https://github.com/tshatrov/ichiran

In Finnish breaks natural language processors

Grue3·Mar 22, 2018

Yes, they are different from English. In English you say "one herd of cattle", "two herds of cattle", and so on. You just need to know a plural of "herd" and the regular numbers. In Japanese the numbers themselves depend on the counter. You can't say "one day", "two days", "three days". You can only say "one day (ichinichi)", "foobar (futsuka)", "bazbar (mikka)", and so on. And this counting system is used pretty much only for days. Except similar words to "foo" and "baz" here are also used to count some things. But not the others. Also the rules of combining a numeral and the counter are very inconsistent. Here's my implementation of Japanese counters, suffices to say the English version would be like 5 lines of code: https://github.com/tshatrov/ichiran/blob/master/dict-counter... And here's the pronounciation generator for so called "r

Read the rest

egular" numbers. https://github.com/tshatrov/ichiran/blob/master/numbers.lisp... I.e. 1000 = issen (ichi+sen) 3000 = sanzen (san + sen), 800 = happyaku (hachi + hyaku).

In Number systems of the world, sorted by complexity of counting (2006)

Grue3·Mar 19, 2017Recommendation phrase

You're forgetting that there are only 3 (three) verb conjugations in English, of which two are almost always the same. Only a finite number of verbs have irregular conjugations, so you just learn them along with vocabulary. In Japanese, the number of possible conjugations of all irregular verbs (copula, "suru", "kuru") is probably larger than the number of English irregular verbs that are commonly used. In fact, let's count the number of conjugations of "kuru" in my ICHIRAN [1] database: ICHIRAN/DICT> (length (get-kana-forms 1547720)) 186 Are English possessives considered difficult by anyone? Not sure what that demonstrates. Plurals! Oh, that's my favorite topic that I'm working on right now. -tachi is mostly used with people, so can't be used in most context. For inanimate objects you just say the number of them. And that's whe

Read the rest

re the counters come in... At which point any sane person gives up learning Japanese for good. Past tense, isn't that the same as conjugations? Also your rules don't really work. "tanoshii" => "tanoshiideshita"? Pretty sure that's not a word. The correct past tense is "tanoshikatta [desu]". [1] https://github.com/tshatrov/ichiran

In The Logic Behind Japanese Sentence Structure

Grue3·Jun 26, 2015

Common Lisp's macros and grammar go together like bread and butter. A grammar module in the app I built [1] uses macros to generate huge amounts of repetitive code. [1] https://github.com/tshatrov/ichiran/blob/master/dict-grammar... I wonder if they're still hiring Lispers. I once passed on the opportunity to work in their Kiev office, but I might give it a shot again.

In Running Lisp in Production