Lisp users try to make a simple program, part II

If Lisp is so good, how come nobody has even made a text editor with it? No, Emacs doesn't count, it's not pure lisp. Neither does DrRacket, you need to install entire Racket language for it. Same applies to Edwin which requires installing Scheme to use it. Climacs neither, there are no binaries, it apparently doesn't even work and is basically just a joke. Zmacs is 1980's history, no binaries, no source, can't verify anything, so no.

Requirements in plain English are on picture there, and those requirements translate basically just to "make a usable open-source desktop application that can be distributed like any other desktop application", no miracles required.

Previous thread:
Its archive: archive.is/mnbNo

Attached: mission impossible for elite lisp hackers.jpg (887x535, 148.8K)

Other urls found in this thread:

docs.racket-lang.org/raco/
github.com/LightTable/LightTable
a.cockfile.com/MR0OcP.
flapp.sourceforge.net/
crossfire.real-time.com/
sourceforge.net/projects/jflagcap/
en.wikipedia.org/wiki/Robin_Milner
docs.racket-lang.org/raco/exe-dist.html
twitter.com/NSFWRedditVideo

You don't need to install entire Racket. Read the docs dumbass. That's like saying you need GCC to run a C program. Of course you do, dumbass.

Let the great kvetching begin!

Attached: try again.PNG (992x404, 49.73K)

docs.racket-lang.org/raco/

Now kill yourself, and go back to /g/, winshill.

Because creating yet another text editor is a fucking waste of time. Every idiot can make text editor in Lisp, pic related is the proof. I've only read first chapter of SICP along with some pages of racket documentation and managed to create a working text editor. To be honest, it was the one of the most pleasant GUI development experiences I've ever had.

Attached: 2018-08-07-141940_1920x1080_scrot.png (958x1029, 126.35K)

If you have some spare time give CL's native GUI, McClIM a spin. It's a recreation of Genera's toolkit and a pure joy to use.

Wow. You need an interpreter to interpret a language. How shocking.

Attached: Data_Says_Jew.webm (960x720, 286.34K)

It's a fucking compiler also. It's like he's arguing that to run a C program you need to download a compiler.

Is clojure an accepted language for this challenge ?

Attached: 1501082901661.jpg (402x604, 48.88K)

import textEditortextEditor.run()


It's like the opposite.

Yes, keep moving the goalposts. This is racket's standard library. Do you want me to write a GUI toolkit from scratch? But why stop there, should I also rewrite Xorg in lisp? While I'm at it why not also rewrite the whole userspace and the kernel? Oh so now the BIOS is not written in lisp, let me also rewrite that. What is this? Firmware of NIC is written in lisp? And what is this? A LCD controller with firmware written in C? Hahaha lispfags can't even write text editor in pure lisp. I bet you would still complain that electricity from power grid uses PLCs and other hardware that has firmware written in C or something. Then you would complain that trucks used to deliver the hardware also run C in their ECUs. Every GUI toolkit has some sort of text-editor widget, look at Qt or GTK. Editing text is a common task and reimplementing widget from scratch every time is counterproductive. Do you think notepad doesn't use a widget of whatever toolkit windows uses to enable text editing?

can we end these fucking threads now?

Oh my God you're even spamming your threads to halfchan.
Imagine being so assblasted by LispMfag shitting on Unix that you go on a months-long autistic meltdown about a meme language

Attached: Screenshot from 2018-08-07 10-11-43.png (897x293, 45.71K)

github.com/LightTable/LightTable

The challenge has been clear for 100s of posts now.


what a gommunity

...

gas.png

...

UH WHAT I MEANT IS HOW COME THERE ISN'T AN iOS APP FOR IT

He might just be the most pathetic poster this board has ever seen.


pic related

Attached: jeps.jpg (603x398, 57.78K)

What part of "executable binary providing usable editor must be provided" you don't understand?


Now all you need to do is provide sources and binary so people can use it.


It is when it has been time and time again been said that you must provide executable binary. Shocking because lispfags are demonstrably not only utterly incompetent, but likely don't even understand what executable binary is.


No. It needing JRE to run unfortunately doesn't fill requirements for rule one.


Oh, why aren't you rejoicing that more and more people learn of wonderful, smart and very competent lisp community whose super language accomplishes pleb challenges like this easier than any other language? Oh wait...


Nope, it's not.


Try stronger medication, it might help.

Attached: kizuna sigh.jpg (451x442, 33.19K)

>>>/cuckchan/

Here you go:
#lang racket/gui(define frame (new frame% [label "Shalompad - Ver 0.1 (OP is a faggot)"] [width 640] [height 480]))(define editor-canvas (new editor-canvas% (parent frame) (label "Editor Canvas")))(define text (new text%))(send editor-canvas set-editor text)(define menu-bar (new menu-bar% (parent frame)))(define file-menu (new menu% (label "&File") (parent menu-bar)))(define edit-menu (new menu% (label "&Edit") (parent menu-bar)))(define search-menu (new menu% (label "&Search") (parent menu-bar)))(define help-menu (new menu% (label "&Help") (parent menu-bar)))(new menu-item% (label "Open") (parent file-menu) (callback (lambda (item event) (define file (get-file)) (if file (let () (define in (open-input-file file)) (send text insert (port->string in)) (close-input-port in)) #f))))(new menu-item% (label "Save As...") (parent file-menu) (callback (lambda (item event) (define file (put-file)) (if file (let () (define out (open-output-file file #:mode 'binary #:exists 'replace)) (display (send text get-text) out) (close-output-port out)) #f ))))(new separator-menu-item% (parent file-menu))(new menu-item% (label "Oy Vey, shut it down!") (parent file-menu) (callback (lambda (item event) (exit) )))(send frame show #t)

Linux binary:
a.cockfile.com/MR0OcP.
SHA1 sum: 7536a1c8b14102be7aeb8a09e3448a6bdd1d92ad
Or compile with "raco exe --gui filename.rkt" if you think I put something harmful in the binary.

Now off to >>>/g/ you go.

you are a terrorized member of the lisp computer-god memefaggotry

Good lord why do you people fight over programming languages of all things? This is the equivalent of fighting over construction tools
Programming languages are just tools, nothing else

faggot, there are clear differences in quality between tools

No one (hopefully) takes this seriously, we're just having fun.
I bet he bought his angle grinder at harbor freight.

Also good on for delivering.

Attached: 20892277b01a1e50bf2b6bee39dc43a755e2fb2249df22348d1bf4314b50a378.png (955x957, 85.66K)

(define search-menu (new menu% (label "&Search") (parent menu-bar)))(define help-menu (new menu% (label "&Help") (parent menu-bar)))
Is this a reverse troll? You tricking the LARPers?

404

Does Java need a binary to run on Linux (or Windows/Mac), other than the JRE?

That's a pretty big "other than". Somehow even .NET on Linux requires less.

Why is everything to do with lisp so Jewish?

Attached: racket.png (91x24, 1.28K)

Doesn't matter. Tons of android phones run Java stuff. If it fits on a phone, it will run on a desktop.

...

You sound like Oracle. In the real world, almost nothing on your desktop is in Java despite 20+ years of Java, and Java on Android is considered to be a tragic mistake. Apple avoided lagdroid's garbage collection stutter with Swift, and Google is trying to develop an Android replacement which will only have Java for backwards compatibility.

Everything is already bloated. I used to run Slackware with kernel 1.2.8 on a 486 with 4 megs ram. Not possible anymore with modern kernel and hardware. I could even run a slim X11 setup called TinyX on that computer. Granted, I couldn't run heavy clients, but it was enough for twm, rclock, and a few rxvts, and even Mosaic.

So what? You don't have a problem running bloated GUI programs, if you're an average Linux user. So a JRE or other runtime isn't going to mean jack in the overall footprint of your OS.

So I compiled this on Windows. It took 10 seconds despite being just a few lines of code, and the executable is a massive 13 megs. It looks like it bundled the entire racket interpreter in the executable. If I run strings on the executable, it clearly contains the racket interpreter (all these commandline options can't actually be used, it's showing their method of making a "stand-alone" executable is just shipping the whole runtime with the code and using the exe like a zip file).
%sgracket [ ...] ... File and expression options: -e , --eval : Evaluate , prints results -f , --load : Like -e '(load "")' without printing -t , --require : Like -e '(require (file ""))' [*] -l , --lib : Like -e '(require (lib ""))' [*]
SBCL does the same bullshit. What a joke.

You might as well try to compile Perl programs. It wasn't designed for making binaries.

Apparently it does mean jack as there are so few Java programs on the desktop. That's some real-world objective proof to counter your bullshit. Java programs are also difficult to distribute, much like lisp.

Maybe that's why perl is a dead language.

Not really, since a Java program can be bundled with what libraries it needs. All you have to install is the JRE, via your package manager.

It's not any different with Python and Ruby. They're VM languages.

Have you ever tried to make standard packages for Windows, Linux, and Mac for a Java program that work just like any other package for that platform, to the point the user is unaware that your program is in Java? Try it. That's why Java failed on the desktop.

Okay, and how many cross-platform desktop apps are you using written in python or ruby? Like lisp and Java they also have deployment issues which is why they got pigeon-holed as web and scripting languages despite being designed as "general-purpose".
Meanwhile, I can write C++ code for literally anything and know that it will run and work the way the user is accustomed to and not force them to do things any different.

That is true. As seen in the racket docs.
Homever, you can compile Racket into C and get smaller binaries, if you are able to read documentation and use a search engine (which you've proven to be unable to do).
Anyways, the simple text editor is done, you have a binary that runs across systems, so shut the fuck up and go back to /g/.

How about you just provide a proper fucking executable rather than continue to make excuses? I ran the exact command as given in

It's a proper fucking executable, retard. It runs everywhere, and runs exactly like intended.

wew

everything that was asked is done, so stfu and go back to leddit

I've come across plenty of games and emulator front-ends made in Java, so apparently it's useful enough to work on Windows/Linux/Mac desktops. Here's a few I happened to like:
flapp.sourceforge.net/
crossfire.real-time.com/
sourceforge.net/projects/jflagcap/

Yeah, you met the requirements in the most pajeet way possible by bundling the whole interpreter rather than compile it.

I have the source. You could look up a video of it though.

It was stated pretty clearly in OP that it doesn't count if you need to install the entire language just to run the executable.

if you were using a Scheme machine he could've given you a binary that uses the local Scheme runtime, same as a bare C binary would do.

...

Stop shilling that overrated piece of garbage.

I fucking love these threads, please keep going at it sweet Kizuna.

Good to know that it'd have worked were we living in an alternate universe.

But you don't. Once you've compiled it and created an executable binary, you can uninstall gcc and your program will still work.

well....
tbh I can't either.
abandon your lisp fetishism and take up ML.
apart from being too cowardly to become an American, he was pretty cool: en.wikipedia.org/wiki/Robin_Milner

I forgot to mention that you have to also use "raco distribute" in the build process to make it portable docs.racket-lang.org/raco/exe-dist.html
To my defense It's the first time I've used racket to make something with it.

ML-based languages are really nice, variant types in OCaml for example are the one thing I really miss when writing Haskell.
There is nothing cowardly, however, in not becoming an American, since it's impossible in the first place. Actual Americans are almost extinct.

Notice the "#lang racket/gui" line. There is a whole GUI toolkit included in that executable. Hello world would only take about 1M with base language only which could be brought down even more to about 300K.

Is there something about lisp that makes it impossible to compile for real? It seems like all the "compilers" we've seen just bundle the whole intetpreter. What aspect of the language is crippling it?

A win32 or GTK Hello, World text widget would be under 10k, and almost all of that would be ELF and PE header bloat. Compiled more carefully, could get it down to 1k.

The programmers.

1k is a lot for just "hello world". Some computers in the 80's came with only 1k memory stock.

Attached: Jupiter-ACE_small_system_(modified).jpg (1536x1929, 1.6M)

Well when a program crashes you enter the debugger and from there you can eval anything, so that means you need to bundle all of common lisp too. Most people bundle a bloated interpreter though. A basic ECL binary is only like 13 KiB. Proprietary implementations have proper tools for making small binaries that free ones do not offer.

and 40 years have passed since. we should aspire to move forward and innovate instead of getting stuck in the past.
40 years until kernels written in javascript

I know, I used to do 1k intros for DOS complete with a limited s3m player. If you look at the text segment it'd be like 100 bytes most of which is 64 bit bloat (never test errors with == -1, by the way). The rest is one-time setup for various modern bullshit that is hard to remove via compiler options. Thread-local support, mmapped stringtable hash, etc..

I'm not a lispfag, but I feel like playing devil's advocate right now.
Due to its intrinsic dynamic properties, like dynamic typing, macros, symbolic evaluation and being able to treat code itself as data and vice versa, Lisp basically requires an highly capable runtime environment to actually do all of those things. The same can be said, to a lesser extent, for Python.

It's not about being "high level": Haskell and ML can be compiled without issues to native code that doesn't need an additional runtime to be executed, just like C can. Even Java can be easily compiled to native code that doesn't need the JVM to run if you use a compiler such as GCJ, although that kinda defeats the point of using Java. It's still quite interesting to do, though, and the performance is surprisingly good, although not on par with C++ or C.

Notice one thing all these languages have in common: they feature a *static* type system.
This is by far the most important kind of information to give to the compiler. By knowing what kind of data functions take in, what they return and having all operations among types unambiguously defined, the compiler can easily generate code that assumes some properties about the data it manipulates (Integers of a certain size? Strings? Lists?) without needing to check at runtime if those operations are permitted, since static analysis has guaranteed that function f will receive, say, an integer and a string every time it is invoked. You can't do the same with dynamic typing.
The often mentioned property about static typing catching compile-time type errors is really just a happy side effect, it's not, in my opinion, the most important thing about it.

Now, theoretically, even highly dynamic (not only with respect to typing) languages like the Lisps could theoretically be compiled down to a standalone binary, but it would pretty much require a massive amount of additional code you didn't write yourself to support its full functionality. And often, the easiest solution is to just bundle the interpreter with it.

Too late.

Probably because Lisp is a commie language.

Nobody cares about binary sizes in 2018 when the average hard drive has 500 gigs or more, user. This isn't the 70s anymore.

The problem is that the program isn't doing anything fundamentally different from what it did back in the 70s, but it has a way higher binary size for no good reason.

I've got over a thousand executables in my bin directories of a basic Debian install. After doing "raco distribute", the racket text editor is 27M. If everything was made this way with racket, you'd make a basic Debian install weigh in at 30 gigs. I don't think people would be pleased, especially the cloud guys who pay per gigabyte. That you see nothing wrong with bloat this extreme is why people make fun of lispfags and why no one writes anything in it.

protip: If you assume the Racket interpreter is installed as a prerequisite, then there is no need to statically link the interpreter into the program. If you remove that assumption away, then your Racket program will need to bundle the interpreter functions by default

Yeah sure so when I call eval in racket the whole thing just explodes? O wait it actual bundles all of fucking racket into the executable. When you run a c program it sure as fuck does not include gcc in the bundle.

Holy shit, lispfags are now on the same level as webdevs.

When you run a C program, the standard C library is preinstalled on your system to make it work.

Dynamic linking has nothing to do with requiring a compiler for basic runtime functionality.

Runtime interpretation is not an inherent property of any programming language, it is an implementation detail. There's no theoretical reason why a Racket program cannot be translated into machine code. It doesn't happen because nobody has made an implementation to make it work that way.

I don't get OP's binary obsession. People don't wail and scream that python isn't compiled. Why would one do the same about scheme? Most scheme implementations aren't compiled, they're interpreted. Even the ones that can be compiled come with an interpreter.

There is no theoretical reason brainfuck cant beat out a highly tuned c or assembly program.
Well mr lispfag come back when you get that magical sufficiently advanced compiler that will never exist for non trivial use cases.


Yes they do. It being a slow as fuck global interpreter lock piece of shit is one of the primary complaints.
Only the bad ones are interpreted. Chez is godly.

I though Chez decided on jit compilation or I terpretation depending g on which would be faster?

Yes Chez is amazing

you have 10 minutes to convince me to use a lisp dialect over rust. i'm a beginner programmer, i can make a text based adventure and maybe a gtk-based calculator. rust has done pretty well for me and looking at C or C++ they look more complicated even with small programs. will *lisp make my life easier? how and why?

You will waste your life implementing new lisps inside lisp and never actually write a program.

I see the Klabnik's propaganda is working splendidly. Lisp is the language for the beginner programmer. Syntax is very minimal and very easy to learn which means you won't be wasting time figuring out what all of the
impl AsRef system.sjwlib::out>>faggot->OP.is() means, without having a slight idea about reasons behind those abstractions and data structures you're trying to use. Rust is probably the worst possible language for a beginner.

could you give me some examples on why?

op thinks that having less syntax makes it easier instead of just making it impossible to tell anything apart

efficiency at the expense of readability?

no

The thing is that Python users rarely if ever go around boasting about their favorite language's superiority, unlike lispfags. Not to mention that, unlike Lisp, there is quite a lot of useful software out there written entirely in Python.

Let's take a basic example of implementing newton's method of calculating square roots. In lisp, when you start learning you would do something similar to
(define (sqrt-iter guess x) (if (good-enough? guess x) guess (sqrt-iter (improve guess x) x)))(define (improve guess x) (average guess (/ x guess)))(define (square n) (* n n))(define (good-enough? guess x) (< (abs (- (square guess) x)) 0.001))(define (average x y) (/ (+ x y) 2))(define (sqrt n)(sqrt-iter 1.0 n))
Now if you take same problem and apply Rust you will get a mess of code that even author himself does not completely understand what exactly it does.
.../// Safe solver hybidizes iterative method to ensure convergence.////// Do not use this!////// The code is both messy and untrustworthy. I had to tighten to convergence/// criteria to get expected results, for reasons I don't yet understand.///pub fn safe_iterative_root_find( f: &F, iterate: &I, bounds: &Bounds, finish: &C, max_iter: usize,) -> Resultwhere F: RealFnEval, I: Fn(&F, f64, f64) -> Result, C: IsConverged,{ // solver always kept in window let mut window = bounds.clone(); let mut f_a = f.eval_f(window.a); assert!(is_sign_change(f_a, f.eval_f(window.b)));... What follows is several lines of rust mess that nobody understands.
I actually couldn't find a simple implementation of that algorithm, closest to it would be something like (not actually what I wanted and uses external module)
extern crate num;use num::FromPrimitive;use num::bigint::BigInt;use num::rational::{Ratio, BigRational};fn approx_sqrt(number: u64, iterations: usize) -> BigRational { let start: Ratio = Ratio::from_integer(FromPrimitive::from_u64(number).unwrap()); let mut approx = start.clone(); for _ in 0..iterations { approx = (&approx + (&start / &approx)) / Ratio::from_integer(FromPrimitive::from_u64(2).unwrap()); } approx}fn main() { println!("{}", approx_sqrt(10, 4)); // prints 4057691201/1283082416} I therefore invite all rust code artisans to create simple implementation of Newton's algorithm for finding square roots that a beginner could understand.

...

hes not fucking wrong though holy shit
i really thought on settling down on some c-like language but clisp looks great rn

It's amusing. OP's threads trying to shit on lisp has only convinced me to work through SICP and learn scheme. Decided to go with gambit-c.