Re: [Frunge] Brechprogramm

[Dennis Heidsiek]

Hallo allerſeits,


Martin Roppelt ſchrieb am 22.09.2009 05:16 Uhr:
> OK, schön, ich habe auch mal mit Java programmiert. Nimm es also ruhig.¹
>   

Wie bereits geſagt, fühle ich mich in Java halt ſehr wohl. Ich beſtreite 
aber nicht, daſs für andere Perſonen andere Sprachen beſſer geeignet 
ſein mögen – da bin ich wesentlich weniger miſſionariſch als bei Neo ;-).

> Aber dann sollte es auch mit einer annehmbaren Geschwindigkeit brechen. 
> Wenn ich für 1 KB 1 Minute warten müsste, wäre mir das zu lang … ;)

Kann ich gut nachvollziehen, das würde mir auch ganz entſchieden auf den 
Wecker gehen. Aber da bin ich wie geſagt etwas optimiſtiſcher … bſpw. 
braucht mein Java-Programm eine Sekunde, um die UnicodeData.txt (1.091 
KB) einzuleſen und daraus die unicode.module (1.716 KB) zu generieren 
(1.114.428.719 Nanoſekunden auf einem Intel Celeron 430 @1.8 GHz, um 
›etwas‹ ;-) genauer zu ſein). Da ſehe ich jetzt nicht wirklich 
Optimierungsbedarf.

Alſo ſollte man auch ein Bruchprogramm in akzeptabler Geſchwindigkeit 
hinkriegen können :-).

> Allerdings ist Java selbst ziemlich speicherfressend (auf meiner Festplatte) 
> (?),

Man braucht tatſächlich erſt eine Java-Laufzeitumgebung (JRE), um 
Java-Programme ablaufen zu laſſen. Unter Windows muſs ſich man ſich 
dafür knapp 16 MB herunterladen, unter Linux (sudo apt-get install 
openjdk-6-jre bei Debian) ſollte das ähnlich ſein. Ob das jetzt 
beſonders viel oder beſonders wenig iſt, kommt wohl auf den 
Vergleichsmaßſtab an … die Komplettinſtallation von MiKTeX belegt 1,33 
GB auf meiner Feſtplatte, ſo geſehen iſt es alſo geradezu ein ſchlankes 
Programm ;-).

> man kann doch auch direkt Programmdateien daraus erzeugen, stimmt das? (Sind 
> die dann auch entsprechend groß?). Die Objekt-Datei(en) für das Bruchprogramm 
> wären aber bestimmt nicht allzu groß?

Bei Java entſprechen .class Dateien wohl am eheſten Objekt-Dateien, und 
ſie ſind im allgemeinen tatſächlich nicht ſehr groß. Zudem werden 
mehrere davon üblicherweiſe komprimiert als jar (das iſt praktiſch 
geſehen eine zip-Datei) ausgeliefert. Richtig groß werden jar-Dateien 
eigentlich erſt, wenn entſprechend ſpreicherfreſſende Reſſourcen 
(jpeg-Bilder, …) hinzugefügt werden.

Anſonſten enthält die GCC (GNU Compiler Collection) tatſächlich auch 
einen Compiler für Java (gcj); praktiſch geſehen ſind die davon 
produzierten ausführbaren Programme aber ungefähr gleich ſchnell und 
gleich groß wie jar-Dateien (ſogar wesentlich größer, wenn es eine GUI 
enthält und das ganze ›Toolkit‹ eingebettet werden ſoll). Zudem ſind ſie 
– im Gegenſatz zu jar-Dateien – dann nicht mehr unter Windows oder Apple 
ausführbar, weshalb in der Praxis eher ſelten auf dieſen Weg 
zurückgegriffern wird.

Zudem man auch jar-Dateien noch einmal ordentlich verkleinern (und auch 
verſchnellern) kann:
http://de.wikipedia.org/wiki/Proguard

> So viel Programmlogik ist dafür bestimmt nicht nötig, eher eine gute Datenbank?
>   

Sehr gute Frage! Das Problem bei einem primär Datenbank-baſiertem 
Programm wäre wohl, daſs dieſe erſtmal erſtellt bzw. gepfegt werden 
müſſte … weshalb ich da derzeitig eher zu einer Umſetzung der ſ/s (und 
Ligatur-Regeln) in Programmlogik tendiere. So gibt es bereits eine freie 
Umſetzung des TeX-Silbentrennungsalgorithmus in Java; wenn man den mit 
den überarbeiteten (freien) Trennmuſtern füttert, ſollte man eigentlich 
ſchon eine recht gute Baſis haben (Schlussstrich -> Schluss-strich → 
Schluſsſtrich bzw. Sluſsſtri). Wenn man dann noch eine 
Ausnahmebehandlung für ſſ (aſ-ſe, iſ-ſe, üſ-ſe, aſ-ſt, uſ-ſt, eſ-ſor, …) 
hinzufügt, ſollte das eigentlich ſchon recht brauchbare Ergebniſſe liefern.

Obwohl … noch viel beſſer wäre es wohl, erſtmal den TeX-Algorihmus um 
Hauptwort-Trennſtellen zu erweitern.

Aber wo wir grade dabei ſind: Gibt es irgendwo einen längeren, 
einigermaßen aktuellen Text in garantiert korrekter Frakturſchreiweiſe 
(etwa das Grundgeſetz)? Das wäre ein recht guter Teſtfall –
›antiquieren‹ und anſchließendes brechen ſollte wieder den Originaltext 
ergeben.

> ¹Java und C sind ziemlich ähnlich, also?² …
> ²War nur’n Scherz³ ;)
>   

Ich erinnere mich noch an Borland C unter MSDOS, da konnte man noch ſo 
etwas wie
for(int i=0; i>0, i++) ARBEITSSPEICHER[i] = 0;
machen … dieſes kleine Progrämmchen hat mir noch unter Win95 äußerſt 
zuverläſſig einen BlueScreen produziert ;-).

> ³Am liebsten wäre mir natürlich ein Shell-Programm; danach käme eine 
> Skript-Sprache.
>   

Das traue ich mir leider nicht zu :-(.

> PS: So was wäre echt nützlich, dann könnte ich meine E-Mail hier mit einem 
> Aufruf von ‚blacken --only-ſ /tmp/mutt-arch-1000-14373-258‘ brechen.
>   

Weck’ bloß nicht meinen Ehrgeiz ;-).


Viele Grüße,
Dennis-ſ