[ / / / / / / / / / / / / / ] [ dir / animu / arepa / asmr / fast / hypno / leftpol / tacos / vg ]

/tech/ - Technology

Winner of the 59rd Attention-Hungry Games
/blog/ - Tell us about your day

October 2018 - 8chan Transparency Report
Email
Comment *
File
Password (Randomized for file and post deletion; you may also set your own.)
* = required field[▶ Show post options & limits]
Confused? See the FAQ.
Flag
Oekaki
Show oekaki applet
(replaces files and can be used instead)
Options

Allowed file types:jpg, jpeg, gif, png, webm, mp4, pdf
Max filesize is 16 MB.
Max image dimensions are 15000 x 15000.
You may upload 3 per post.


File: 498d9964094ba64⋯.jpg (80.3 KB, 593x796, 593:796, 1501447229545.jpg)

 No.923254

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.

 No.923465

The same reason why 8ch/tech is so good but nobody is making a facebook feed plugin for it. If you know what I mean...


 No.923472

You have absolutely no clue how Lisp works.


 No.923474

>>923472

The core lisp interpreter was made in C so emacs isn't 100% lisp


 No.923479

>>923474

I don't understand why this has any relevance to reality. Emacs isn't the interpreter, it is the programming features that programmer needs to develop software.


 No.923485

>hurf durf Lisp is a programming language!

>can't program basic programs in it

A language which can only do maths and logic is useless. Any programming language can do that. If you don't have good I/O facilities it's fucking useless.


 No.923487

>>923485

>This is what "webdevs" actually believe


 No.923489


 No.923490

>>923487

>>923489

God damnit. Anyway I've literally never programmed in jabbashit in my life. Go write me a replacement for the unix utilities in lisp. Pro tip: some of them are probably completely impossible to write in Lisp.


 No.923492

>>923479

Emacs is powered by a lisp interpreter written in C. The rest of it is in lisp but the important backbone is done in C. So much for lisp being what stallman claims it is.


 No.923493

Has there ever been a Lisp compiler for x86, so that Emacs lisp interpreter could be rewritten in Lisp?


 No.923496

>>923254

Edwin, included with MIT/GNU Scheme.


 No.923498

>>923492

>>923490

* In another article DB writes:

* > Unix programmers have a bizzare idea of

* > efficiency. Emacs misuses pointers to save a few bytes

* > (while being huge and bloated), XWindows is a pig, but

* > hey, we saved a JMP! :-)

* That's not UNIX, that's MITnix. This massive abuse of

* virtual memory seems to have come in with the MIT "free"

* software: X, the GNU stuff, and so on... --

First of all, memory for PCs (and soon for workstations)

runs for about $30/MB, and 8 additional MB take care of both

X and GNU Emacs.

In addition, I won't say much about X, which I dislike,

although if I'm not mistaken most of the bloat has occurred

because of vendor requests. X 10 was much leaner, and

provided more than sufficient functionality as far as I'm

concerned.

With respect to Emacs, may I remind you that the original

version ran on ITS on a PDP-10, whose address space was 1

moby, i.e. 256 thousand 36-bit words (that's a little over 1

Mbyte). It had plenty of space to contain many large files,

and the actual program was a not-too-large fraction of that

space.

There are many reasons why GNU Emacs is as big as it is

while its original ITS counterpart was much smaller:

- C is a horrible language in which to implement such things

as a Lisp interpreter and an interactive program. In

particular any program that wants to be careful not to crash

(and dump core) in the presence of errors has to become

bloated because it has to check everywhere. A reasonable

condition system would reduce the size of the code.

- Unix is a horrible operating system for which to write an

Emacs-like editor because it does not provide adequate

support for anything except trivial "Hello world" programs.

In particular, there is no standard good way (or even any in

many variants) to control your virtual memory sharing

properties.

- Unix presents such a poor interaction environment to users

(the various shells are pitiful) that GNU Emacs has had to

import a lot of the functionality that a minimally adequate

"shell" would provide. Many programmers at TLA never

directly interact with the shell, GNU Emacs IS their shell,

because it is the only adequate choice, and isolates them

from the various Unix (and even OS) variants.

Don't complain about TLA programs vs. Unix. The typical

workstation Unix requires 3 - 6 Mb just for the kernel, and

provides less functionality (at the OS level) than the OSs

of yesteryear. It is not surprising that programs that ran

on adequate amounts of memory under those OSs have to

reimplement some of the functionality that Unix has never

provided.

What is Unix doing with all that memory? No, don't answer,

I know, it is all those pre-allocated fixed-sized tables and

buffers in the kernel that I'm hardly ever using on my

workstation but must have allocated at ALL times for the

rare times when I actually need them. Any non-brain-damaged

OS would have a powerful internal memory manager, but who

ever said that Unix was an OS?

What is Unix doing with all that file space? No don't

answer. It is providing all sorts of accounting junk which

is excesive for personal machines, and inadequate for large

systems. After all, any important file in the system has

been written by root -- terribly informative. And all that

wonderfully descriptive information after lots of memory

consumed by accounting daemons and megabytes of disk taken

up by the various useless log files.

Just so you won't say that it is only TLA OSs and software

that has such problems, consider everyone's favorite text

formatter, TeX (I'm being sarchastic, although when compared

with troff and relatives...). The original version ran

under FLA on PDP-10s. It is also bloated under Unix, and it

also must go through contortions in order to dump a

pre-loaded version of itself, among other things.

>>923493

SBCL converts Lisp directly into Assembly.


 No.923499

Lisp is good because it makes you realize there is more to life than programming.


 No.923502

>>923492

Except Stallman never claimed that. It's extended predominantly in Elisp but can also be extended in other languages. In fact, the new version of Emacs deprecates Linum for a much faster C module. Why would they do that if Stallman or the Emacs devs or whomever you're trying to antagonize (and doing poorly at that) were Lisp elitists. Here's a joke collected in the Emacs docs:

>Q: What do you call a subtle, clever hack in the favorite language?

>A: A gnuanCe.

Why are you even conflating Stallman with autistic Lisp elitists? Stallman may love Lisp, and he may be autistic, but he loves free software more than he loves Lisp. If this conversation were even a little less autistic, I would accuse you of being a third party actor for trying to fabricate your own narrative.


 No.923503

>>923499

No it doesn't


 No.923508

File: ea5378e7db88c84⋯.webm (233.86 KB, 958x526, 479:263, eshell.webm)

>>923490

It's called Eshell, you dolt.


 No.923516

>>923490

>implying anything can be impossible with a turing complete language

hmm...


 No.923520

>>923490

Unix shells suck. The shells of the various Lisp Machines were quite different. The Symbolics shell, later called "Dynamic Lisp Listener" allowed management of commands, completions, defaults, interactive help, etc..

See for example: https://www.hooktube.com/watch?v=o4-YnLpLgtk

The interactiveness of that Lisp Machine OS is quite a step up from what any typical shell offers. The problems of that (GUI) approach: it wasn't very sophisticated on the text terminal side; actually, it was quite bad. For development one needed an extended Common Lisp (or Zetalisp), which was a bit too complex for many users.

Really, It's not even hate. Most Unix shells are just dumb. Many people like to use primitive text based UIs with lots of corner cases, which makes them seem intelligent for remembering obscure commands and obscure options without real UI help.

Take cp. The shell does not know the various options the command takes. The shell does not know what the types and the syntax of the options is. The shell does not know which options can be combined and which not. It can't prompt for shell options. It can't check the command syntax before calling it. It can't provide any help when the syntax is wrong. It can't deal with errors during command execution. There is no in-context help. It can't reuse prior commands other that just editing them on a textual base. The output of the command is just text and not structured data. There are an endless amount of problems. There *have* been attempts to address this by putting different user interfaces on top - for example, IBM provided an extensive menu based administration tool for AIX. But no tool is perfect and pragmatically I've found shells to be far more productive than anything I've ever attempted to replace it with (on a modern OS, that is). Which is the real crux of why we use these tools. That's why there's a million different shells. You can even use Lisp-based shells like scsh and esh or Emacs. But for most part all these attempts still suffer from and don't escape the general problems.


 No.923524

>>923508

Eshell has saved my ass a few times when I've had a frozen and unresponsive terminal so I opened up emacs to kill it


 No.923525

>>923516

>turing complete == can do anything

Brainfuck is turing complete. It's absolutely, indisputably impossible to write multi-threaded or networking programs in standard Brainfuck.


 No.923533

>>923254

Zmacs you retard

>>923508

<not showing off that you can use elisp in it


 No.923554

>>923525

> multi-threaded

All multithreaded problems are single threaded problems that some asshole made more complicated. Also, there are multithreaded dialects of BF: Weave and brainfork to name two.

> networking programs

brainfuck++ adds networking


 No.923556

>>923554

>>923525

And, before you tell me that those aren't standard brainfuck, I will respond that C still doesn't have standardized networking or multithreading, and C++ only has multithreading, but just got it in 2011.

> It's absolutely, indisputably impossible to write multi-threaded or networking programs in standard C.


 No.923563

File: 1a3d1b9085ebfd4⋯.png (136.08 KB, 1498x599, 1498:599, scsh.png)

This is your brain on Lisp.


 No.923565

>cia/fsb keeps making lisp vs unix D&C threads


 No.923577

>>923520

How would your shell know ahead of time what some random program (including ones that don't exist yet) is going to accept as parameters?


 No.923588

>>923533

Except it did? "ff" is a popular alias for find-file. That's why the image file opened in mpv. Plus, there's nothing spectacular about repls. Eshell's strength lies in how it can interact and be extended with Elisp, not how Eshell can execute it when you issue a command.


 No.923589

>>923554

>All multithreaded problems are single threaded problems

Why don't you try cryptocurrency mining, hashing, or video encoding using only one thread. Usually it's 3 to 4 times slower to do it your autistic single-threaded way. Sure, singlethreading is way easier, but its performance is inferior in many situations.

>>923556

Perhaps, but you get the idea. In standard C one can perform I/O on arbitrary files. In brainfuck, you can only perform I/O on the standard streams. There are some things which the language makes impossible.


 No.923607

>>923496

Fair enough. Now bring that to feature parity with VStudio and give it GUI.

>>923533

>>923520

>>923520

>mooh leeesp macheens

ganbestigudasaiyio anon


 No.923616

https://common-lisp.net/project/climacs/

haven't used it, but I did use Portable Hemlock for a while.

'pure lisp' isn't important. It's a matter of degree and location. A thin shiv of C that makes things work is how lisps themselves work under Unix. Even Forths will do that, or write the shiv in assembler. What matters is that, when you want to improve on Emacs in any way, you get write in Emacs Lisp--you don't have to write in an even less pleasant language.

With that said, Lisp is not good. Depending on why you want it, go with Erlang or an ML instead.


 No.923617

>>923520

>Many people like to use primitive text based UIs with lots of corner cases, which makes them seem intelligent for remembering obscure commands and obscure options without real UI help.

B-but GUI is bloat!!!

Remember: "Weenix is the operating system preferred by Unix Weenies: typified by poor modularity, poor reliability, hard file deletion, no file version numbers, case sensitivity everywhere, and users who believe that these are all advantages”.


 No.923705

>>923474

>>923492

>the core of Javascript is written in C therefore nothing is written in Javascript.

This is how retarded you sound.


 No.923714

File: 0c2b617c5574f67⋯.jpg (61.02 KB, 675x900, 3:4, when-the-cheeky-is-breeky.jpg)

Why is there a shit tone a absolute ignorant and shit threads these days?

It seems that it's the same guy that made the thread about lisp machines...

He really sounds like a fucktard who just had his degree (if he's actually not a faggot who typed ping in the windows CMD and thinks he's a high level hacker), done with only atom, who know only java (if not javascript) and come and shit on the whole programming/hacker culture because of how "elitist" he finds it to be compared to his incompetence.

That's really revolting. But, well, it's not like /tech/ is not /g/ now.

I'm not even commenting on the "anime pic". There are really serious guy liking anime, I'm not even say shit about it, but in the over cases it's a clear sight of ignorance.

The question too is why people are feeding such a fucktard question. The three first answer would be "install gentoo", "what (cadr '(a (b c) d)) eval to? gtfo" or "Go to /tech/ Questions and Support and get ban faggot".


 No.923715

>>923520

>>923617

Ironically, this is why GNU Emacs is the ultimate Unix application. Because Emacs is a powerful, flexible, and respectful frontend for Unix tools.


 No.923724

>>923498

>C is atrocious;

>Unix is literally the worst;

What? Then why did you use them?

It's like if an american Jehovah's Witness went to preach in Africa, except he's only armed with japanese Shinto Prayers, and then complaining asian animism doesn't mesh well with JW theology, and translating from japanese to !Kung via english is a bitch.


 No.923726

>>923254

Lisp is a family of languages, not a language.


 No.923729

>>923714

LISPfags have always been lolcows, threads like this are far older than chans. It's a language that was put on a pedestal in academia and people based their careers around yet they ended up just sitting around being smug and condescending while everyone else who actually produced software used other languages. They've always had a cult atmosphere and been as ridiculous as audiophiles in their justifications.


 No.923731

>>923607

Great way of moving the goal. Polite sage.


 No.923745

>>923731

>waaah waaah muh goalpost extremely superior lisp can make a simple editor but don't ask it to do anything more

Get FUCKED.


 No.923762

>>923607

>>923745

>Fair enough. Now bring that to feature parity with a bloated, superfluous piece of shit and give it rainbow sprinkles.

Aren't Lispers supposed to be the ones who hate Unix? Are did you get your strawmans mixed up.


 No.923763

>>923762

Yes they are, same fuckbrains are frothing of lisp machines were so superior to minimalist Unix, yet crying about impossibility of making complex software with lisp.


 No.923767

>>923763

You're the only one who's frothing at the mouth right now.


 No.923769

>>923729

There was a /lisp/ thread, with actual coding and project.

Not this pile of crap.

And no, that's not ridiculous. That's simply people who love what they're doing actually pointing out nice things, and not things that have been developed only with money and capitalism in mind. That's the same in nearly every field. What is worth doing in term of money nearly never match the nobility of it. You can take example of the pharmaceutical field. You only do what could make you very rich. So you're gonna create new molecules that you can protect behind intellectual property, and certainly not conceive and sell plant mix, that would be "worthless" in an economical view.

This logic can be applied in every field ever.


 No.923779

>>923745

Where did Lisp touch you? Show me in the function


 No.923781

I'm not a lispfag but I'm open to try something different since I'm kind of getting fed up of Unix after doing the Linux and BSD shit since 1995. I'm fed up of all the unending upgrades and security patches and other related bullshit. There's got to be something better but every OS now is a fucking Unix clone, so it's like OS research hit a dead end. Also I'd like answer to >>923577


 No.923782

>>923577

Operating system provided/mandated interface for shell options using a known format. --options could give it, for instance.


 No.923786

>>923729

It's better to produce nothing than to produce garbage.


 No.923791

>>923782

But following a specific format only fulfills one part of the proposed interface (like getting consistent help). That still leaves:

> The shell does not know the various options the command takes. The shell does not know what the types and the syntax of the options is. The shell does not know which options can be combined and which not. It can't prompt for shell options. It can't check the command syntax before calling it

To do all that in Unix, you have to study the man page. The example he gave as an attempted improvement was the AIX TUI for sysadmins that had "canned" commands you could run, but that only worked for whatever small subset of commands and arguments were baked into it.


 No.923807

File: c9d00478f54b05f⋯.jpg (45.63 KB, 451x392, 451:392, 1459006618899.jpg)

>>923786

>we're not producing anything purposedly to prove our ways are superior


 No.923811

>>923724

Because there is no other way to do modern computing. On OpenBSD they avoid using flexible pchar/*char functions; instead they limit the length using StrLCopy, etc. C is not a good language but they still work with it - the real faggots are people like Linus Torvalds - he still hates Wirth and Dijkstra. Most people still think the antiquated C rules of the world are a Good Thing. (That's why everything is so vulnerable to buffer overflow attacks, among other things.) Well, what are these experts doing today? Copying Wirth, of course (see: Go, Limbo, C compilers having stronger typing). Ruby (a shitty language, to be fair) stole Modules from Modula. But yes, Wirth was a charlatan - we'll still copy his ideas though, and they won't suspect a thing!


 No.923813

>>923498

Thank you for no longer abusing the code tags.


 No.923814

"Lisp Machines are something that you think is really cool when you first learn about them, then you come to the realization that pining for them is a waste of time.

I've had a flash of inspiration recently and have been thinking about Lisp Machines a lot in the past three weeks.

But first, a digression. There's an important lesson to be learned about why Symbolics failed. I think Richard Gabriel came to the completely wrong conclusion with "Worse is Better" (http://www.dreamsongs.com/WorseIsBetter.html). There are two reasons why:

1. Out of all the LispM-era Lisp hackers, only RMS understood the value of what's now known as Free Software. (If you haven't read it yet, read Steven Levy's Hackers - it describes the MIT/LMI/Symbolics split and how RMS came to start FSF and GNU).

2. Portability is really important.

The key lesson to draw from Unix isn't that "Worse is Better," it's that survivable software is Free and portable. Free because getting software to someone's HDD is 80% of success, and portable because you don't know where people will want to use your software (there are some really weird places).

Symbolics was neither. If Genera had been Free Software, it would by definition still be around today. If Genera had been portable, it's likely Symbolics would never have gone out of business (the Alpha virtual machine would have been done sooner, with less resources, and for more systems).

Being released as Free Software today wouldn't help. Genera's predecessor, MIT CADR, was made available under an MIT-style license in 2004 (http://www.heeltoe.com/retro/mit/mit_cadr_lmss.html). There's a VM emulator which runs the code. The whole system is pretty useless.

Now on to the inspiration part:

It's possible to make a very high-performance, portable Lisp operating system on modern hardware. This has been a possibility ever since the Pentium came out. The main bottleneck to conventional Lisp runtime performance is the way operating systems manage memory allocation and virtual memory.

A type-safe runtime that has control over memory layout, virtual memory, and is aware of DMA can provide extremely high throughput for allocation and GC (this has been shown by Azure's Linux patches for their JVM), true zero-copy I/O, almost optimal levels of fragmentation, and excellent locality properties. If you go single address space (and there's no reason not to) and move paging into software (object faulting and specialized array access), you've also eliminated TLB misses.

Throw in the fact that it now becomes trivial to do exokernel-type stuff like for example caching pre-formatted IP packets, and it should be possible to build network servers that have throughput many times that of anything that kernel/user-space split OSes like Linux or FreeBSD are capable of for dynamic content (ie - not just issuing DMA requests from one device to another).

The only problem is device drivers. Lisp doesn't make writing device drivers any more fun, or reduce the number of devices you have to support.

What to do?

The reason I've been thinking about this is that I came across this: http://www.cliki.net/Zeta-C

I've heard of Zeta-C multiple times before, but for some reason this time I made the connection - "why not use Zeta-C to compile an OS kernel?"

I explored the idea further, and it seems to me that it wouldn't be an unreasonable amount of work to take the NetBSD device subsystem and have it running on top of a Lisp runtime with the necessary emulation of those parts of the NetBSD kernel that the drivers depend on. If you don't know, NetBSD's device drivers are modular - they're written on top of bus abstraction layers, which are written on top of other abstraction layers (for example, memory-mapped vs port I/O is abstracted). So the actual system twiddling bits can be neatly encapsulated (which isn't necessarily true for Linux drivers, for example).

I'm aware of Movitz (http://common-lisp.net/project/movitz/) and LoperOS (http://www.loper-os.org/). Movitz makes the mistake of trying not to be portable, but there's useful things there. I haven't spoken to Slava about this yet so I don't know what's going on with LoperOS. I am also aware of TUNES, and think it was an interesting waste of time.

The main thing is to get Zeta-C to work on Common Lisp. Then it's to build a new portable, boot-strappable runtime (I think the Portable Standard Lisp approach of having a SYSLISP layered on top of VOPs is the right way to go for this), and either build a compiler targeting that runtime, or adapt the IR-generating parts of one of SBCL, CMUCL or Clozure. Further bootstrapping can be done with SWANK and X11 once a basic networking stack is in place. I think such a system would be quite fun to hack on."

From here: https://news.ycombinator.com/item?id=1878608


 No.923817

>>923814

Free Software != $0 price

<Use Zeta-C to make a kernel for a LISP based operating system

This is the typical uweenie way of thinking. If you want to actually make a modern LISPM trying to take influence from Unix in making it is a bad idea. You are just adding in 40 year old brain damage into your system.


 No.923821

>>923577

>>923781

>>923791

The good ideas in AIX come from the IBM z and i ancestors. IBM wanted to put some of their technology into a workstation that was between the PC and their real computers, but since they based it on UNIX, it sucked. Every time a computer company's UNIX has a cool feature that didn't come from AT&T, it turns out that it's a bad knock-off of something from another OS, usually an OS that the same company sells or used to sell before shills talked them into hawking UNIX.

https://en.wikipedia.org/wiki/ISPF

https://en.wikipedia.org/wiki/IBM_i_Control_Language

(I tried to mail this once before, but (wouldn't 'ya know
it), the mailer on life was broken...)

Yes, Virginia, there *is* something worse than Unix - it is
called "AIX" and is currently being pushed on an unwary
public by IBM. But I digress. In case you don't read
abUsenet, here's a post I just made to
alt.folklore.computers:

From: RS
Subject: Hardware Architectures and I/O (was: Re: Jargon file...) **FLAME!!**
Date: Sun, 2 Dec 90 15:43:03 GMT
Lines: 53

In some previous article PT writes:

> Back when there were REAL(tm) computers like 780, a lot of
> time and energy went into designing efficient I/O from the
> CPU bus to the electrons going to the disk or tty. >

Damn right, but even the 780 was a step down. Get your
KL-10 documentation set out and read about *them*.

- Front-end PDP-11s that did Tops-20's command completion.
- Separate I/O and memory buses.
- 8-ported (that's eight, son) memory that talked to the
I/O front-end machines for *real* DMA, not cycle stealing!

> Sure OS's and apps have gotten bloated, but when you put a
> chip like the MIPS R3000 on a machine barely more advanced
> than an IBM-AT you end up with a toy that can think fast
> but can't do anything. I can't really blame companies
> like DEC and Sun for producing mismatched hardware,
> because their marketing drones are constantly trying to
> undercut each other in price. It's a hell of a lot more
> expensive to ship a product with a well designed I/O
> system than to drop in a "killer bitchen" CPU chip;
> occasionally someone makes the attempt do design a great
> piece of hardware, and you end up with something not half
> bad (like the DECstation 5000, which is only crippled by
> Ultrix

You left out the worst offender of them all - IBM. The
RS-6000 may crank out 27 MIPS, but it can't context switch
or handle interrupts worth sh*t. You can lower machine
performance to the point of unusability by FTPing a file
from another machine on the same ethernet segment!

Next time get a chance to play with an RS-6000, try
this: Pop about a dozen xterms, iconify them, put the icons
in a row, and wave the pointer back and forth over them as
fast as you can. Astounding, no? The highlighting on the
icons will keep bouncing back and forth long after you stop
waving the pointer. My personal record is 20 seconds.
Makes a Sun-2 running display Postscript seem astoundingly
fast.

RS-6000s also have an annoying tendency to "lock up" for
a few seconds (5 < x < 15) and then return to normal - I'm
told that this is normal and due to paging activity. The
microchannel card cage design is pretty bad too - sure, you
can put cards in, but God help you if you have to take them
back out! And you better tighten down the retaining screws
all the way... or the first time you look at the card funny
it will pop out.

To its credit, I must say it compiles GNU Emacs faster
than any other machine I've used, but I do more with a
workstation than just run compiles. And, if you think
Ultrix is bad, it's only because you haven't tried AIX.


 No.923837

>>923589

>Usually it's 3 to 4 times slower to do it your autistic single-threaded way.

So, what you're saying is that there is nothing intrinsic to the problem that requires multithreading, and that I was right? Your performance constraints require multithreading, not the solution to the problem.

> There are some things which the language makes impossible.

There is nothing that the language makes impossible. Brainfuck has a dialect that opens files. A language either is Turing complete, and thus nothing is impossible, or it is not, and thus it only solves specialized problems. Everything else is environment, which can be libraried over. There are multithreaded, networked, GUI applications written in C despite the C language not providing any of these things. The environment provides pthreads, Berkley sockets, and X Windows. As far as C is concerned, these are black boxes that do magic, but have a C interface so that they can be called as C functions. We don't change the language just because we add these magical functions. Lisp is no different.


 No.923865

>>923837

>A language either is Turing complete, and thus nothing is impossible

That's some pure academia horseshit. In the real world, there are all sorts of things a "turing complete" language can be useless for. How would a driver in lisp be written without cheating and having it call out to a different language if the memory has specific physical alignment constraints, can't be moved by compaction, and needs some concept of volatile? The language exists in some imaginary space that doesn't exist which is why it's total ass for real software development.


 No.923866

>>923817

>trying to take influence from Unix in making it is a bad idea

Because everything that was learned since fore ever in computing is bad ? The Unix mindset is a compilation of past practices it's not perfect and can be corrected/forked into something better. Whine all you want but the unix practices is mostly solid and works well long term speaking.


 No.923867

>>923866

>Because everything that was learned since fore ever in computing is bad

>The Unix mindset is a compilation of past practices it's not perfect and can be corrected/forked into something better.

>Whine all you want but the unix practices is mostly solid and works well long term speaking.

Everything you said is so patently false that I don't even know where to start; congrats.


 No.923868

>>923867

maybe start with a massive blockquote, mister lisp meanie!


 No.923871

>>923868

Why do people assume that if someone isn't fellating the "eunuch way" in their post, they must be the "lisp meanie" - maybe *nix systems aren't as good as you think they are.


 No.923882

>>923871

I feel the same way. I don't know who these people are that are pushing this Unix/Lisp dichotomy, but I feel like there's some kind of conspiracy going on to deface both.


 No.923895

>>923865

How is a driver written in Pascal? All languages that allow writing drivers call out to either another language (usually assembly) or a metalanguage to satisfy the constraints of the hardware. All languages exist in an imaginary space. You may say, "Not so with C", but that is fundamentally incorrect. All drivers written in C do stupid things with locations in memory that are semantically well defined (by the language) and semantically well defined (by the hardware), but the coupling is entirely enforced by the programmer (unless that programmer works for certain hardware companies, then there is no coupling). That the memory corruption that C stupidly allows to happen happens to cause the hardware to behave in a certain way is outside the scope of the language, and that anomalous behavior can be replicated in any language by giving the programmer an API to do stupid. I want to reiterate that: a device driver is to any programming language a program or function that performs anomalous actions that happen to cause the hardware to behave in a certain way. The language holds the programmer's beer and hopes all turns out well for him. The fact that stupid is foundational to the C language, but has to be wrapped in APIs in better languages, is a testament to C's poor design.

It's actually starting to turn me into a mean old man. I studying up on security issues, and lay security people (security people who aren't developers), rattle on about buffer overflows. The thing about it is that buffer overflows are primarily a C/C++ problem. Java, Lisp, BASIC, shit even COBOL, largely won't let you do it. If you give a pajeet any one of these languages and have them write a string processing program, the only exploits will likely be in the implementation of the language, not their code. One has to be a professional programmer to write code that has a buffer overflow vulnerability. Give a pajeet C/C++, it will have over 9000 vulnerabilities, because the language itself lends itself to writing insecure code. And a professional programmer writing a version without those vulnerabilities will produce code two orders of magnitude longer, because the language itself makes writing correct code hard and tedious.

The fact is that C/C++ have taken over software development because programmers have a culture of writing shitty code. We have a culture that values code that looks like eye cancer, works by happenstance, and is more brittle than a marshmallow frozen in liquid nitrogen.


 No.923897

People were saying that C was absolute garbage when it new/novel, and they knew it would set computing back by decades (it destroyed the lessons we learned from Lisp). Somehow, people praise C today. Look how far we've regressed - what was detritus yesterday is considered the cream of the crop today. Imagine where we'b be now if Lisp and Genera won the systems programming wars, instead of C. Genera was a Symbolics Lisp Machine OS where everything was a hackable Lisp object. Another interesting OS was Oberon. Oberon had an infinite desktop with a text REPL at mouse point. Most "innovations" today are on the kernel end, and it basically all relate to performance.


 No.923899

File: b9ba5fe2b6d9fff⋯.png (169.31 KB, 898x1142, 449:571, genera2.png)

>>923897

>we'b

we'd.

Also, I forgot the image.


 No.923901

Hey, MIT Lisp junkie, explain this

>the early beginnings of the microcomputer revolution, which would sweep away the minicomputer and workstation makers, cheaper desktop PCs soon could run Lisp programs even faster than Lisp machines, with no use of special purpose hardware.

If LISP machines were designed to run LISP efficiently, why was it that the big bad UNIX and C machines, even Windows, were running LISP faster? And if these machines were running LISP faster, why is LISP still demonstrably and detrimentally slower on them compared to most other languages running on the same hardware?


 No.923910

Why does the cult of Good Enough pervade all of modern computing? Some of us want brilliance, not hacks. Lisp Machines, though largely forgotten, can never be un-created. My standard of comparison for _any_ technology will always be everything previously achieved by mankind, rather than what is available on the market today.


 No.923912

>>923910

What's your point?


 No.923922

>>923882

Probably all they've ever seen is Unix and Windows. Never so much as touched a VAX or even a simple 8-bit computer. So it's like being born in the Matrix.


 No.923933

>>923901

It wasn't that big bad UNIX and C machines were running Lisp faster, it was that vending machine processors were running Lisp faster. Chips like the 8080 had a place in cheap hardware. And these chips were meant for hand coded assembly. Only after the chips became popular were they optimized for running C. The companies selling Lisp machines weren't selling just processors; they were selling integrated machines. You know the saying "jack of all trades, master of none". Intel is a master of making processors, but they don't really sell computers. Lisp machines were the whole computer, so the processor, while optimized for Lisp, was still inferior to the mass production ones coming out for hand coded assembly (from companies that only made processors).

For me, I don't particularly care for Lisp. I just hate what C has done to people. I'm talking to people who couldn't imagine writing a device driver in COBOL. It would be ugly, but there is nothing magical about C that makes C doable where COBOL isn't. The thing about Lisp machines is that they demonstrate this: C is a "fast" language because it is being run on hardware that has been optimized to run C. The hardware doesn't have to be optimized to run C. ENTER is still an instruction. There are good arguments from academia that if Lisp hardware had the same development budget, it would be faster hardware (if we remove certain core functions of Lisp that aren't as functional).


 No.923941

>>923933

It's a silly excuse. Cray made specialty hardware for specialized programs and their shit was extremely fast. Sun made both generalized and specialty systems and their shit was extremely fast. They both focused on forcing programmers to work like the hardware wanted rather than the LISP machine approach of forcing the hardware to work like the mathfags wanted. Shockingly, mapping the programmer to the hardware seemed to work a lot better.


 No.923944

>>923933

>machines optimized to run C today

>machines optimized to run LISP

I don't thank you for ignoring what I asked. If LISP machines were designed to run LISP efficiently then why did machines, which you say, "are optimized for C", run LISP faster than the machines which were designed to run LISP?


 No.923946

File: 412955c39d46764⋯.png (122.83 KB, 644x635, 644:635, 1452122840821.png)

Hey lispfags, write a text editor that is graphical, portable and has feature parity with VSCode. Needs to be 100% lisp.

I'll taunt you as eternal unaccomplished poser faggots until you do.


 No.923948

>>923946

>VSCode

>calls people "eternal unaccomplished poser faggots"

>>>/g/


 No.923951

File: 859294c6d4d5baa⋯.png (1.15 MB, 1920x1080, 16:9, mpv-shot0032.png)


 No.923952

>>923948

I set the bar lower as requesting VStudio feature parity caused nervous kvetching before.


 No.923954

>>923951

>100% lisp

Do you know what .c and .h files are, idiot?

https://github.com/emacs-mirror/emacs/tree/master/src


 No.923955

>>923954

Considering you want it to be portable, that means that I can't assume everyone has a LISPM to run it on. We need some sort of runtime in order to run the editor. The actual editor part of emacs is 100% lisp.


 No.923958

>>923955

>deploying on different machines is still a challenge for LISP

>after 60 years


 No.923959

>>923958

>deploying on different machines without using a compiler is still a challenge for C

>after 40 years


 No.923964

>>923946

>>923948

>>923951

>>923954

>>923955

>>923958

>>923959

all (you) thread sliding to avoid this post

>>923944


 No.923968

>>923964

>thread is about lispfag inability to even write a 100% lisp advanced graphical modern text editor

>resident lispmegafaggot barges in with his usual lisp computah nonsense

>accuses others of sliding thread

and your clairvoyance in calling out (you)s is right on par with your programming skills, error rate 71%.


 No.923970

>>923968

>error rate 71%

Prove it.


 No.923972

File: 6ccaa0bbcf0c5bf⋯.png (4.92 KB, 307x161, 307:161, Capture.PNG)


 No.923974

File: e5d5351b4448717⋯.png (9.71 KB, 368x192, 23:12, terrible.png)

>>923964

Terrible accuracy.


 No.923977

I don't get why someone would waste time writing a text editor in Lisp, when they've already got those things for Lisp. It's like asking me to write a thing for Python but do it in Perl. Well fuck that, I don't give a shit about Python, so I'm not gonna waste my time.


 No.923978

File: 4a87aff4c9157e0⋯.png (11.84 KB, 418x190, 11:5, Screenshot at 2018-06-02 1….png)

>>923964

Wow! How did (you) know?!


 No.923980

>>923977

The core point is that lispfags don't actually write software with lisp.


 No.923981

>>923980

What about clojure? A bunch of people are using it. And what about scheme and racket? Are you just fixated on some unique version of Lisp or what?


 No.923984

>>923981

You lisp retards are like communists, asked to prove a simple thing that would somehow would validate your claims to superiority despite all the plentiful evidence otherwise, you never deliver even that one bit. All you do is dodge.

>show big complex modern program made entirely in lisp pls

>why would you want that? what lisp? haha there are many lisps your quest makes no sense bet you didn't know that

>reemeeembeeer lisp machines from before you were born, now stop asking for something made this millennium

>big complex programs are bad u know unix principle which we hate too btw haha remember leesp calculators

>software x already exist as some kid whipped it up over summer using some baka inferior language 40 years after Lisp was invented, so we are more concerned with more interesting things such as... hmm well nothing to show really but trust me on this we have suupeerr cool things I'm sure of it, you need to believe


 No.923987

>>923984

Way to project, retard. I don't even know any Lisp at all, but apparently people use it because clojure and racket are getting a lot of attention these days. I think you're just a C tard who has something to prove, to make up for your lack of "something" in your pants, so you picked the (pointlessly) hardest language to write code for correctly to be all macho and shit. I've seen your kind of retards posting on Usenet and ganging up on newbies who fuck up some C program (which is inevitable in any language, but even moreso in C) and they love to go all aggro at him and prove how much they memorized the C standard and how they know all the undefined behavior cases (this is the retard olympics at its finest!)

Keep training at C, moron. Maybe in another 50 years when you're in the nursing home, you'll finally figure out that you could have saved yourself all kinds of trouble simplying by writing in Ada or even Pascal.


 No.923997

>>923987

>you could have saved yourself all kinds of trouble simplying by writing in Ada or even Pascal.

The irony is that both Ada and Pascal were considered bondage and Discipline languages; but modern C is much more restrictive than modern Ada/FreePascal.


 No.924000

>>923997

>bondage and Discipline

Bondage and Discipline.


 No.924006

>>923981

>What about clojure?

Javafags were desperate for a scripting language that would be less verbose than Java while still meeting project requirements and took whatever they could get. Having had to write Java, I don't blame them.

>And what about scheme and racket?

What about them? They're practically unused outside of academia and memes.


 No.924012

File: aa4f56e6ba1c2cd⋯.png (674.22 KB, 900x675, 4:3, gnusnap.png)


 No.924018

>>923987

Everything you apropooed about me was wrong. I'm not projecting anything. I'm observing. Just look at this fucking thread, all that greentext is here in some form or another.

Lispers are massive poser faggots and I absolutely fucking hate poser faggots. Now I was just playing with some filters on LineageOS gallery app, which is written in Java and oh boy it works well, filter preview is instantenous. Yes that terrible horrible forced OO Java lispers lament about.

Fine, you posers can't write a goddamn basic 21st century advanced gui text editor with git integration and all that other basic shit taken for granted now, just admit it, everyone can witness it.

Well let's lower bar again, write a photo gallery like that with a bunch of filters then. Surely you can do that much if bunch of dudes in their free time manage to do it in such a horrible inferior language and get it to run in a few hundred devices too. Fucking posers!


 No.924031

anything past assembly isnt good and is for brainlets


 No.924039

>>924031

Assembly is infantilized Intel bullshit that doesn't represent the way the processor really works


 No.924047

>>924039

Intel's one of the very few hardware companies that let you write assembly the way the processor really works but brainlets couldn't handle it and the Itanium became the Itanic. If you want your head fucked with, check out how you write assembly for one. I had to do that a long time ago and it was mind bending. Compiler authors weren't prepared at that time.


 No.924048

>>923944

>>923964

>why did machines, which you say, "are optimized for C", run LISP faster than the machines which were designed to run LISP?

Because those machines were faster in general. Because Intel and Motorola were good at making fast hardware, and Symbolics was a bunch of programmers trying to be a hardware company.


 No.924052

>>924031

I think it's only complicated if your architecture is fubar. I've read old text philes about asm on mainframes and it seemed easy peasy. And the 650x and Z80 are a piece of cake. A lot of kids grew up writing machine language for those. You often didn't even have an assembler back then and just POKE'd the equivalent hex codes somewhere in memory and called that routine from your BASIC program.


 No.924457

>>923978

>>923974

he didnt call you the same person dummies


 No.925809

>>923498

Very good post


 No.925870

We need a VSCode alternative (because industrial code is what the world needs)


 No.925872

>>925870

What's wrong with VSCode?


 No.925876

>>923474

C was written in assembly, so nothing is 100% C


 No.925877

>>925872

inb4 electron


 No.925888

>>925876

>C was written in assembly

What does this mean?

The programming language standard was written in English.

The compilers are usually written in C (or C++, or a mix) right from the start.


 No.925896

>>923817

Just say libre/gratis like a normal person.


 No.926944

>>925876

Look up what “bootstrapping” means.


 No.927237

>>923472

Not him, but what I know is that lisp has never been used for any substantial project of any sort. It's never been used to write an OS or a database or useful networking utilities, servers, encryption software, compression tools, analysis applications, browsers, or anything of any import ever.

People who talk about lisp being superior are the sort of people who would eat the packaging on junk food because the picture is prettier than actual cooking and then complain that cooking is inferior because it goes bad if you leave it out too long.


 No.927268

>>927237

That is a completely unrelated point to that of the post you're replying to, and you are an idiot. And you're probably going to argue that your point is valid and my dismissal of you is shallow of me, but you're still going to be wrong. You know why? Because your point is impertinent to the point made in that post, so I don't care what you have to say. Nobody cares what kind of authority you've garnered or whether your logic is correct because it doesn't matter. That is not how Lisp works.

And even if it did matter, you are incredibly misguided, because if you took even a second to listen to the people whom you antagonize, you would know that entire operating systems have been written in Lisp. And, yes, that includes a text editor, although that would be like calling Acme simply a text editor.

Take, for example, Clojure. It's never been used for a "pure" program, because it relies on JVE and CLR, but anyone who has even conducted a sliver of a miote of research would know that Clojure is one of the new trendy, enterprise hipster dialects, as evidenced by the fact that Clojure is used within industry firms like Walmart and Verizon. You've never heard of these management products because they're used for commercial and industrial purposes, not something that would affect an obnoxious larper. There are retarded conventions and conferences are conducted literally every year, and there's an incredibly high turnout. If you've ever been to Linux conventions or really any high-profile convention, you would know that there's always at least one twat giving a lecture on Clojure at every given event. Even that guy from Techsnap gave a Clojure lecture one time.


 No.927286

>>927268

You're talking to one of the guys who writes those industry management products.

I've heard companies produce tools for many purposes in many languages, everything from BASIC to Cobol to Clojure to Perl.

You know what language I don't hear used? Lisp. That wouldn't matter if it were used for other things, but I don't see it used anywhere else either.

Yes, Lisp has been used to write lots of things. None of them are important in the least. They're not significant, and they're not commonly used.

I also know companies whose entire accounting is done in Excel formulas, but that's hardly important because it only matters to that company and it's shit anyway.

I'll concede Lisp has been very important for fomenting features which have significantly improved other languages. Nobody with a brain argues against that.

It's academically significant, but it is not a useful language.


 No.927313

>>927286

>>You know what language I don't hear used? Lisp.

>What is Cisco


 No.927427

>>927286

Yes, because the authority of a single "industry management guy" is certainly worthwhile. Especially when they're an anonymous post on the Internet refuting a post that calls him out on his appeal to authority and yet still tries to convince you that he's Very Important.


 No.927432

LISP is a curiosity, nothing more.


 No.927434

>>923254

what is she thinkign about?


 No.927436

>>927434

She's thinking about how extensible GNU Emacs is and whether she should post about it on >>>/emacs/


 No.927442

>>925888

>right from the start

Then how was it originally compiled? Checkmate C purists


 No.927451

>>927286

Lisp has not been a single language since the 60s. Today it denotes a fairly broad family of languages sharing common ancestor.

Clojure is a Lisp[1], and it's widely used in industry.

Common Lisp also sees use in some specialised fields; DARPA had some software from the original AI days[2], CL was the language of choice for quantum computing research a few years back, and that grammar analyser thing you see advertised at the moment is also written in it.

I'm assuming ignorance, but if you're seriously arguing semantics, then fine, LISP 1.5 isn't used in industry.

[1] Unless you're really deep into the metaphysics of Lisp http://www.loper-os.org/?p=42

[2] https://en.wikipedia.org/wiki/Dynamic_Analysis_and_Replanning_Tool

[4] https://tech.grammarly.com/


 No.927454

>>927451

A few anecdotes of where LISP was used outside of academia doesn't make it an industry tool.


 No.927457

>>927454

That's like saying that Ada isn't an industry tool, because the programmer of today doesn't know its uses.

https://www.seas.gwu.edu/~mfeldman/ada-project-summary.html


 No.927459

>>927454

Which Lisp are you talking about?


 No.927463

>>927457

No it's not. It's saying that LISP is a language used in academia that has found a few niche uses outside.

>>927459

Dialects don't matter.


 No.927470

>>927463

That's my point - Lisp *could* be used effectively outside of those niche situations (much like Ada). The problem is, people don't know all the advantages Lisp has.


 No.927471

>>927470

People know about the propaganda and don't buy it. Where do you think all those fresh new employees are coming from to fill in the empty offices that the boomers are leaving behind? They weren't neet before, I can tell you that.


 No.927472

>>927463

>Dialects don't matter.

This echos an issue in linguistics where the difference between a language and a dialect is very hard to define and normally comes down to politics.

There's as much difference between CL and Scheme as there is between C++ and Java, the former are known as Lisp dialects simply because that's the nomenclature among the community. The various scheme implementations are more like dialects as users of other programming languages would understand the term.


 No.927474

>>927472

The syntax I've seen with various scheme dialects and CL is always the same: (function argument argument ...). What are any other differences? Do they have character for line endings or something?


 No.927475

>>927471

>Where do you think all those fresh new employees are coming from to fill in the empty offices that the boomers are leaving behind?

Sure, Ada programmers are being replaced. But, that has nothing to do with the "quality" of C/C++ - there just aren't enough Ada programmers. Bugs like this >>924397 will become more common, and then they'll realize that cutting corners when it comes to military applications is a no-no.


 No.927478

>>927475

Cutting corners? Contractors have been doing that for decades. You think programming language is going to make the whole government change that entire operation? You are delusional.


 No.927487

>>927470

>force every programmer to rigorously study it for 60 years in academia

>is still treated as a toy language

>must just not be understanding its advantages

It's a toy language. Move on.


 No.927491

>>927478

Do you know the situations in which Ada is used?

- Cannot fail

- Must be bug-free

It was a DoD project, they wanted something that adhered to the Steelman language requirements - none of the languages at the time (1979) did, so they made Ada.

>You think programming language is going to make the whole government change that entire operation? You are delusional.

I don't understand your point here. What I think you're saying is that the switch from Ada -> C/C++ will not change any of their plans. At first this might be so, but after enough rockets fail, they'll probably go back to Ada.


 No.927494

>>927491

A government funded program does not mean every other government program operates with its design or findings. This is because many government programs are contracted out to private companies. They each do it their own way. Just because you have a boner for ada doesn't mean that any other contractor will consider using it if it costs them money in the end.


 No.927495

No one will go back to Ada. That was the most absurdly verbose language I've ever run into in the wild. It'd be cheaper to just build another rocket.


 No.927499

can't even guarantee the language is bug-free because it must be dependent on the faults of the hardware, either design or manufacture defects.


 No.927501

>>927494

That doesn't change the fact that mission-critical software has used Ada/SPARK since the 80s.

>Just because you have a boner for ada

I always bring up Ada because C/C++ programmers think their language is the only one acceptable for "real" programming. The existence of Ada completely eviscerates their argument.

>doesn't mean that any other contractor will consider using it if it costs them money in the end.

Yes, and when their fighter jet fails, they'll go back to Ada even if you need to pay the Ada programmers more.


 No.927503

>>927501

That's not how government contracts work. Like I said, just because you have a boner for ada doesn't mean that all government contracts will use it.


 No.927506

File: caf3bb8452eac9e⋯.pdf (3.22 MB, AirForceMandate.pdf)

>>927503

>Like I said, just because you have a boner for ada doesn't mean that all government contracts will use it.

It was like that for a long time:

http://archive.adaic.com/pol-hist/policy/mandate.txt

If C++ causes too many issues, they'll switch back to Ada, and maybe even require it for all military software again.


 No.927507

>>927506

>where cost effective

It seems like if the contract would be too much, then using something else would be preferred to save costs.


 No.927508

>>927506

I forgot to say - I know that contractors write the software, and then military buys it. But, Ada was still the most common until recently.


 No.927509

>>927508

>and then military buys it.

and then the military buys it.


 No.928346

>>927442

Running the C code in your head and typing the output into a file


 No.928444

>>928346

>Buffer Overflow

>Brain Corrupted

>Remote Code Execution

u an RC robot now


 No.928516

Reddit was originally written in Lisp. I think that says everything.


 No.928570

>>928516

What does that say, exactly? The users who post there aren't the developers who made a product that became successful.

The same happened with Yahoo Stores. The developers were able to implement new features much faster than the competition who was using more "industry-approved" languages.


 No.928573

>>927487

Academia is jumping ship to Python in machine learning.


 No.928626

What do you think of Guile?


 No.928688

>>928573

Academics aren't known for being the sharpest knives in the drawer.


 No.928762

>>928688

>academics use lisp

>look how smart we lispfags are haha

<academics stop using lisp

<w-well academics are dumb hehe


 No.928791

>>928762

They had a good tool, and they squandered it. Then AI became a dirty word, and Lisp also by association. They blamed the tool instead of themselves. Now they've jumped on a different but lesser tool. They will again hype everything because they never learned from their mistake. With their funding and connections, they could build new Lisp machines that are even better. Instead they go use language designed for pajeets on botnet hardware and shitty OS.


 No.928803

>>928791

Common Lisp is one of the ugliest programming languages in the world, its proponents are autistic and cannot explain why Lisp is so superior, and every implementation has its own quirks, so if you want to use a library you have to first look up the list of implementations it was tested on.

Scheme looks nice, but it's even worse when it comes to portability, it's effectively the world's most non-portable language. Until r6rs and r7rs there was not even a module system, so if you wanted to split your program over more than one file (and only toy programs are suitable for one file) you could throw portability out of the window. I wanted to work my way through the SICM (not SICP) book and unless you use their specific version of Scheme and their scmutils (which cannot be ported to anything but MIT Scheme because it relies on implementation quirks) you cannot follow along. What is the point if I cannot take what I learned with me into the real world after college?

This is the real problem Lisp is facing: it's a brilliant language, but the people in charge of it are autistic as fuck.


 No.928878

>>928791

Are you saying using lisp determines is person smart or dumb? Academics were smart as long as they were using lisp, but now they are idiots? That's how I read you.

>>928803

Not necessarily autistic, and they can explain why it's hypothetically on paper super good and they do that ad nauseum, but well, they have absolutely nothing to show for it this side of millennium. In my books lispers are just posers. All of them.


 No.928889

>>928791

>designed for pajeets

Literally designed by Scandinavians and is used by tons of white collages.


 No.928890

>>928878

Academics forms people to be workers, not to be knowledgeful.

They teach you science in a job's perspective, not in a general knowledge perspective. That's very different, and it makes it change everything regarding what it's gonna teach you.


 No.928891

>>928878

> Not necessarily autistic, and they can explain why it's hypothetically on paper super good and they do that ad nauseum, but well, they have absolutely nothing to show for it this side of millennium.

They do, but the whole point of embedding a DSL in Lisp is so end users don't have to learn Lisp. So it becomes a catch-22: the best way to show off the power of Lisp is to hide the Lisp.

The Guix package manager's configuration languages is an EDSL (embedded domain-specific language) sitting on top of Guile. You write Guix code and it gets magically translated to Scheme code. If Guix was using Python or Lua for configurations, then users of Guix would have to learn Python or Lua, which is overkill for configuring a package manager. On the other hand, the Nix developers invented their own configuration DSL, but they had to build everything up from scratch instead of building upon a foundation like Guile.

https://www.gnu.org/software/guix/


 No.928892

>>928890

>Academics forms people to be workers, not to be knowledgeful

Then what the fuck are chemists? They don't tell them how to pick the best iron foundries to work at, they teach you what chemistry.


 No.928893

>>928889

Both Lisp and Forth are dead for the same reason: they give too much freedom. Forth and Lisp are very similar, but also very different. They both give the programmer the ability to extend every part of the language, creating DSLs, and having a consistent non-syntax.

The only difference, is that Forth is a low level language, whereas Lisp is the highest level language in existence. The two languages compliment each other, giving you everything you need. The problem with them is, that you need to master the language, understand it, start thinking in it, and become one with it to use it properly.

If we only had these two essential languages, programming would really be something for "smart people only". The FORTRAN/Algol branch of languages has become more widespread because they are brain-dead. Pick a random language from that branch, and you'll see that they all have hard coded, "nice-looking" statements for the most common operations. (loops, if then else, etc, all with different syntax). This makes them easier to learn for non-programmers, at the cost of the programmer's freedom and power. Then C and Unix came. Unix was a really simple system. Everything was a file, and it didn't have a versioning file system. It had flaws, many flaws, too many flaws. You can read some of them in the Unix Haters Handbook, but most of them don't apply anymore. So, if C was inferior to Lisp and Forth, and Unix was inferior to Lisp machines, why on earth would they replace them? Because they are simple. Everyone can use them without having to think and learn how to use them. C is a static language. You've got if, while, for, goto, and return. You must use these, and nothing else.


 No.928895

>>928893

>Both Lisp and Forth are dead for the same reason: they give too much freedom.

>too much freedom

Unless you can fuck up the kernel with intentional maladies, it's not true freedom. inb4 murder is freedom


 No.928905

>>928890

>They teach you science in a job's perspective, not in a general knowledge perspective. That's very different, and it makes it change everything regarding what it's gonna teach you.

What did he mean by this?


 No.928910


 No.928912

>>928892

There's a book by Jose Ortega y Gasset explaining that. Loosely translated the title of the Spanish book is Rise of the Masses

The point is that idiots are overconfident thanks to liberal democracy, fast technological advancement etc. Academics are mentioned (like chemists) as being one issue people. They know a lot about one subject, so they think they can have a worthy opinion about everything, thanks to their confidence from their knowledgeability of the tiny subject they've "mastered". It's a good read


 No.928913

>>928893

Not everyone is a brainlet who thinks in specific languages.

>>928626

Guile is shit.


 No.928921

File: 3cb5e2792a54c33⋯.webm (15.28 MB, 966x642, 161:107, john-taylor-ghatto.webm)

>>928905

What they're gonna teach you*

There is too the fact that people get specialized. The more specialized, the more blind you are. The greatest scientists in human history were people mastering many fields of sciences. For exemple, a doctor that is too specialized to a certain organ can sometimes hurt the patients because he forget the rest of the body.

Moreover, science never have been neutral. There is nothing less neutral than science. Modernist science is positivist, progressist, secular (to not say masonic) and scientist. Everything you'll be taught will follow these principles. Moreover, college will only teach you, NOTHING MORE, what you need to be able to work in the market.

There is too the fact that higher education jobs give a better social standing. So you'll think that you're in the right, because you're actually socially rewarded. The more rewarded peoples are, the less independent they are. That explain why in the sovietic era, people having high education were given everything they wanted.

Those different points explain why people who did college are actually incredibly easy to manipulate. Now, intellectually limited people are easely manipulated too, but that's not the subject.

School is just an adapted to the market needs, XIXth century prussian military school.

All of this to justify the point that market don't represent what is actually good in science, nor then college, since college follows the market. The market wants money, not intellectual beauty. So following what chose the market as programming language is retarded, especially when you know how shitty programming languages are used just because they were used in the first place, or just because there simply not enough people in your programming language of choice. Moreover, most of people are idiots, so you can't have a complicated to use programming language. You can't just hire people coming from MIT. You want pajeets, because they're cheaper.


 No.928928

>>928891

Having configuration formats that have to be executed to be understood has always been a huge mistake. Imagine if you have a program that needs to pull out the origin of a package given a package file. You'd have to turn guix into a library and bundle it.


 No.928929

>>928928

Any weak configuration format will just end up becoming a bad programming language as complexity grows.


 No.928930

>>928929

Dude systemd is a feature, not a bug.


 No.928931

>>928930

faggotD is for cucks.


 No.928935

File: 0c6c0bc5b5df633⋯.webm (1.38 MB, 202x360, 101:180, (((you))).webm)


 No.928947

>>928893

I agree with you. That's what I read from some article about common lisp from hacker news.


 No.928951

>>928947

Daily reminder that freedom is a bad thing and letting programmers insert random op codes into their software is dangerous.


 No.928952

>getting hacked by the configuration file


 No.928959

>>928952

>Letting your programs do arbitrary IO

LOL


 No.928969

>>928959

>having to sandbox a configuration file


 No.928985

>>928893

>Both Lisp and Forth are dead for the same reason: they give too much freedom. Forth and Lisp are very similar, but also very different. They both give the programmer the ability to extend every part of the language, creating DSLs, and having a consistent non-syntax.

The reason we don't use Lisp is exactly the same as why we don't use a lot of other languages that are better than C and OSes that are better than UNIX.

>The only difference, is that Forth is a low level language, whereas Lisp is the highest level language in existence. The two languages compliment each other, giving you everything you need. The problem with them is, that you need to master the language, understand it, start thinking in it, and become one with it to use it properly.

Lisp can generate machine code without any other language. I don't know what the "highest level language in existence" is.

>If we only had these two essential languages, programming would really be something for "smart people only".

If you want programming to be for "smart people only" you should only use assembly language. Assembly language is more reliable than C, but it takes a lot more time to develop. Compilers are supposed to simplify the work of the programmer and programming languages are for people to read. I wish OS and programming language design was for smart people only because there would be no C or UNIX.

>The FORTRAN/Algol branch of languages has become more widespread because they are brain-dead. Pick a random language from that branch, and you'll see that they all have hard coded, "nice-looking" statements for the most common operations. (loops, if then else, etc, all with different syntax). This makes them easier to learn for non-programmers, at the cost of the programmer's freedom and power.

Easy to use is the opposite of brain-dead. C and UNIX are brain-dead because everything is misdesigned and broken. They make everything hard to learn and use, not easy to learn and use. Something simple like concatenating strings, loops, or case dispatch becomes a huge problem full of bugs and exploits. The C language makes it too hard to do things the right way, so it sucks.

>Then C and Unix came. Unix was a really simple system. Everything was a file, and it didn't have a versioning file system. It had flaws, many flaws, too many flaws.

UNIX sucks because it's not simple. Not everything is a file, which was just UNIX marketing bullshit. It didn't have direct, indexed, or memory-mapped files either, just some byte-oriented tape drive emulation. It has so many flaws that they can completely make up bullshit and call it the UNIX philosophy even though 90% doesn't describe any part of UNIX.

>You can read some of them in the Unix Haters Handbook, but most of them don't apply anymore.

Most of them still do apply, which is why I post these quotes. The only C flaw that no longer applies is gets(). None of the other C flaws were fixed. Most of the UNIX bugs are still there.

>So, if C was inferior to Lisp and Forth, and Unix was inferior to Lisp machines, why on earth would they replace them? Because they are simple.

No, they're not simple. AT&T shills convinced clueless MS-DOS users that UNIX was simple for a multitasking OS and C was a "real" programming language, but that's bullshit. They believed it because UNIX barely had more features than DOS, so they assumed that the bloat of UNIX was fundamental to the features DOS doesn't have.

>Everyone can use them without having to think and learn how to use them. C is a static language. You've got if, while, for, goto, and return. You must use these, and nothing else.

This has absolutely nothing to do with why C and UNIX suck. If C was easy to use without having to learn it, that would be a great breakthrough in computer science, but it's not. This sounds like C shilling disguised as criticism like "C is so simple and easy to use you don't even have to learn it, but if we used Lisp, only a few smart people would be allowed to program." The problem with C isn't just that people don't understand how it works, but that they don't understand that the way it works is wrong.

The fundamental design flaw in Unix is the asinine belief
that "programs are written to be executed by computers
rather than read by humans." [Now that statement may be
true in the statistical sense in that it applies to most
programs. But it is totally, absolutely wrong in the moral
sense.]

That's why we have C -- a language designed to make every
machine emulate a PDP-11. That's why we have a file system
that forces every file to be viewed as a sequence of bytes
(after all, that's what they are, right?). That's why
"protocols" depend on byte-order.

They have never separated the program from the machine. It
never entered their tiny, pocket-protectored with a
calculator-hanging-from-the-belt mind.


 No.928994

>>923814

You eliminate driver cruft by making hardware directly programmable rather than going through generic driver abstraction layers in the operating system.


 No.929007

File: d4628fdcd434d44⋯.jpg (50.38 KB, 960x579, 320:193, DVxGVUbWAAEvRXC.jpg)

>>928969

>Letting any program do arbitrary IO


 No.929008

>>928994

Yes anon lets have every program have to have custom support for every single driver for every piece of hardware instead of making it generic.


 No.929009

>>929008

It was actually quite nice back in the days when programs directly interacted with hardware. In the early '90s I wrote small demos on DOS for the soundblaster where it was just about talking directly to the ports and DMAing to the card. I could do it via what was known as an autoinit DMA transfer that would work like a ring buffer - I'd start a large transfer much larger than the buffer itself and then periodically check where the card was reading from and I could fill in data ahead of that point without having to actually request it be transferred. It was much lower latency than using multiple buffers which is what was being done on Linux at the time.

When I switched to Linux it was painful dealing with how completely fucking shit sound was since I knew how it should be done and that the hardware was capable of so much more. The OSS guys refused to ever properly support reading the DMA pointer and treated it as a special case per card that was only supported on a few of them. And the Linux guys refused to ever properly support the soft realtime scheduling that was necessary to keep buffers filled. Even today I have sound cut out in Linux when doing things like writing large files unless I tune the system's buffers. It's embarrassing.


 No.929010

>>929009

> In the early '90s I wrote small demos on DOS for the soundblaster

Then you also remember the 5 different sound card systems where you had to select which specific one you needed to use when you launched a game and how horribly fucked it was.


 No.929047

>>928890

But that's wrong you dumb poser.


 No.929049

>>929010

It wasn't that bad. They almost all had SB compatibility and just needed the dipswitch bullshit assigned. GUS was its own unique beast and I didn't have one. Adlib was mostly compatible at the hardware level as well. I wrote a player for that, too. The code for all this was pretty small.


 No.929068

>>928928

> You'd have to turn guix into a library and bundle it.

And? Also, what >>928929 said.


 No.929112

>>929049

This. People overstate how clunky things were in DOS. It was usually a simple matter of running the game's setup program and letting it auto-detect your hardware's IRQ/DMA/PORT infos, after you simply selected the right sound card from the list. I had a Pro Audio Spectrum 16 that could emulate Sound Blaster, so I just picked PAS16 when that option was availble, or else just chose SB. Not exactly rocket science!

Even doing stuff like boot menus for different CONFIG.SYS settings wasn't that hard. A bit harder than picking out the sound card name that you bought at the store, but not as hard as a lot of Linux stuff, like setting up LILO or GRUB for multiboot. Linux has tons more options and added complications compared to DOS.


 No.929116

>>929112

>configure graphics card for each game

>configure sound card for each game

>configure network interface for each game

>there are multiple incompatible standards for each thing

yeah it was really a breeze having to set that shit up every single game. I'm sure developers loved having to implement 20 different standards for their game.


 No.929118

>>928893

Forth is one of the few languages worth learning IMO. It's one of the few languages that can perform well on an 8-bit computer, and that's the safest way out of the botnet. Other solutions like TALOS and RISCV sound good on paper, but I can't ever trust that the hardware I get is identical to the specifications, if I'm even allowed to see those specs (not the case with TALOS, apparently).


 No.929123

>>929116

Network other than plain analog modem or RS-232 was pretty rare in DOS games, except at the very end of DOS days. Outside of offices, relatively few people even hard network cards.

Video card wasn't hard to configure. Typically you just select one of: CGA, PCjr, Tandy, EGA, VGA. Sure that was more work for the developers, but it was up to them how much hardware their game would support. It's not like they wouldn't have extra work to do with different hardwares in Linux either. All their sprites and game screens would have to be colored and sized differently, and the timings would be different as well. Remember that back then much was synced to stuff like vertical retrace and had very tight timing constraints. Those details wouldn't magically just disappear because you're running Linux. Actually it would be worse because you'd have a lot more overhead such as during context switches, and you don't want any overhead on those old hardwares.


 No.929163

>>929116

It's a lot worse today, you're just used to using userspace libraries that hide the massive amount of setup code and data transforms required. Go look through the code of SDL for example.


 No.929341

>>929163

>Go look through the code of SDL for example.

m9 thats because SDL works on multiple operating systems that use different abstraction layers


 No.929342

>>929123

Dude your RAMDACs are barfing all over the place.


 No.929344

>>929116

>configure graphics card for each game

>configure sound card for each game

>configure network interface for each game

>there are multiple incompatible standards for each thing

It's like libraries don't exist, right? This can be even a market itself, some company provides libraries for Nvidia cards with excellent performance for voxels (for instance) while other provider offer a better performance for raytracing, so each game can adopt a specialized solution for the hardware and it runs on maximum performance due to no intermediaries between the game and the hardware.

Thanks to competition, everyone would be doing what they can to offer the best cost/benefit. Regarding interface to the hardware, the developer would simply pick up the best solution to the problem, similar to what already happens today with some using Unreal engine, while others using Unity, but there's space for you to try your own thing.


 No.929347

>>929344

Good idea! Complain about a standard interface to computer hardware.... AND THEN MAKE ONE ANYWAYS! Great idea!


 No.929414

>>929341

No, it turned into a mess with SVGA. That was when we all had to switch to using VESA BIOS because the mode was so poorly standardized at the hardware level and nothing ever worked right. You can find some of the legacy of that horror in things like svgalib/SDL.


 No.929469

>>928935

Hey, you're the faggot that saved that video for future use.


 No.929488

File: 43bcacdebe15e67⋯.jpg (172.74 KB, 1080x1068, 90:89, 43bcacdebe15e6772942382966….jpg)


 No.930225

File: 21d6905235a0db9⋯.png (51.6 KB, 970x793, 970:793, lispweenie.png)


 No.930872

>>930225

You're right to say that a lot of pro lisp/pro unix etc.. just circljerk and don't post any actual projects.

No code.

It used to be a lisp general thread with a lot of code, projects, question etc.. but there is nothing anymore. Just blatant shit.

CODE FUCKING DAMN IT!


 No.930891

>>930225

That doesn't make C or C++ or UNIX good


 No.930901

>>930891

>tripfag hates Unix

lmfao


 No.931000

>>930891

Sure doesn't make them bad either. Pick a side.


 No.931079

>>923485

>sysop on a certain public system has written some utilities for us in lisp

>can't program basic programs

>can't


 No.931089

>>930901

Tell everyone why you like Unix. Come on.


 No.931094

>>931089

I love its poor modularity, poor reliability, hard file deletion, lack of file version numbers, and case sensitivity everywhere.


 No.931129

>>930901

>>931000

non-tripfag here, dropping in to say C++, C, and UNIX are all shit

>>931089

the only reason anyone ever liked UNIX is to be a neckbeard LARPer

>>931094

false resistance


 No.931201

>>930891

It absolutely does in comparison: what has been done, how many are actually doing things with C right now and not to mention how obnoxious fucking good for nothing unaccomplished larping shits LISPfags are. Cfags at least do something.


 No.931215

>>931201

What the fuck are you talking about. The fact that more code is written in C does not in any way make it good, unless your definition of good is solely "a language that lots of people have written code in".


 No.931238

>>931129

>non-tripfag

still a fag.


 No.931244

>>923254

if lisp is so good then why is there no lisp 2?


 No.931253

>>931201

Like Java, the strong point of C is its ecosystem. The languages themselves are shit. C is QWERTY, some other language to come (probably not Lisp honestly) is DVORAK (or some other, better layout). Is QWERTY more used because it is better to type?

And even with Java, you have a very strong standard library, but C's stdlib is a joke. The other strong point of C is that it is extremely flexible, but at what cost?

>>931215

This, ad populum is a fallacy.

To keep with what OP wanted the thread to be, my favourite thing with C is trying to reimplement everything found in higher languages. It feels a bit like being left on your own in a jungle with only a hunting knife and a loincloth, and you have to make yourself a nice house and all.

For real world projects? Get that shit out of my sight. I've had to maintain a 200k sloc ANSI C project with 20 years worth of code rot, and that's when I stopped being a C fanboy.


 No.931282

>>931253

> The other strong point of C is that it is extremely flexible, but at what cost?

The strong point of C is that everyone is using it. I can use a C library in Python, but good luck using a Common Lisp library in Python. C is the lingua franca of computing for better or for worse, and you can get a piece of C code to run on your toaster if you want to. It's also portable and doesn't put much abstraction between you and the hardware, which is what allowed it to become the universal language in the first place.


 No.931285

>>931282

Yes, but these are not qualities inherent to C. English hasn't become the lingua franca of the Internet because it is inherently superior. Virtually every non-ASM language out there that is still used is machine-agnostic, just like C.


 No.931287

>>931285

Assuming your machine is turing complete, you can also use any ASM language on your machine.


 No.931293

>>931287

Good luck writing x86 ASM, of any variant, for ARM v7 microprocessors.


 No.931295

>>931293

It should be pretty easy to do using qemu.


 No.931297

>>931295

Sure, if you emulate the CPU, then you can run things on another CPU. But what's your point?


 No.931302

>>931297

I'm making a point that machine-agnosticy alone means nothing as in the end as any turing complete language can be represented by another turing complete language.


 No.931341

>>931089

My favorite part of Unix is the bit where I can use it.


 No.931472

>>931253

>C is QWERTY, some other language to come (probably not Lisp honestly) is DVORAK (or some other, better layout). Is QWERTY more used because it is better to type?

The difference between C and a better language is not something minuscule like keyboard layout. Better languages can be 10 or 100 times more productive than C and need much less code.

>The other strong point of C is that it is extremely flexible, but at what cost?

Lisp is extremely flexible. C just has pointer arithmetic and a bad preprocessor. In the 60s, there were new techniques like tagged memory, segmented memory, and garbage collection, and they understood the advantages and didn't want their language tied to any particular kind of machine. C is much less portable than any of these languages.

>>931282

>The strong point of C is that everyone is using it. I can use a C library in Python, but good luck using a Common Lisp library in Python. C is the lingua franca of computing for better or for worse, and you can get a piece of C code to run on your toaster if you want to.

That's AT&T monopolistic bullshit. If it sucks, they want to spread it everywhere so people have no choice. Users of other languages don't really care how many other people use the language because they're not trying to take away other people's choice to use different languages. There would be much better integration between languages on a Lisp machine because more types can be shared.

>It's also portable and doesn't put much abstraction between you and the hardware, which is what allowed it to become the universal language in the first place.

C is the least portable ANSI or ISO standard language. What sucks about this is that C is holding back hardware design. C is "portable" because all the new computers are RISCs or extensions of machines that can already run C.

> ...
> There's nothing wrong with C as it was originally
> designed,
> ...

bullshite.

Since when is it acceptable for a language to incorporate
two entirely diverse concepts such as setf and cadr into the
same operator (=), the sole semantic distinction being that
if you mean cadr and not setf, you have to bracket your
variable with the characters that are used to represent
swearing in cartoons? Or do you have to do that if you mean
setf, not cadr? Sigh.

Wouldn't hurt to have an error handling hook, real memory
allocation (and garbage collection) routines, real data
types with machine independent sizes (and string data types
that don't barf if you have a NUL in them), reasonable
equality testing for all types of variables without having
to call some heinous library routine like strncmp,
and... and... and... Sheesh.

I've always loved the "elevator controller" paradigm,
because C is well suited to programming embedded controllers
and not much else. Not that I'd knowingly risk my life in
an elevator that was controlled by a program written in C,
mind you...


 No.931498

>>931472

>can't tell if setf or cadr from the context

>doesn't implement his own error handling hook

>needs a GC to hold his hand

>fixed data types that would make a program less portable

And most importantly,

>elevator's security depend on software

Amerimutt engineering.


 No.931527

>>931472

> C is the least portable ANSI or ISO standard language.

OK, then please show me how to portably open a file in Common Lisp.


 No.931528


 No.931552

>>931527

with-open-file

It will even handle closing the file for you after you're finished.

>>931472

>such as setf and cadr

I don't quite understand this. How can = be like cadr? Wouldn't cadr be more like list->next.value?


 No.931581

>>931552

>>931528

OK, now tell me how to specify the file in question. There is a whole chapter in Practical Common Lisp about building a package that wraps up the unportable implementation behind an interface:

http://www.gigamonkeys.com/book/practical-a-portable-pathname-library.html


 No.931587

>>931581

For my manga dumper I use:

(with-open-file (file (ensure-directories-exist filename)
:direction :output
:if-does-not-exist :create
:if-exists :supersede
:element-type '(unsigned-byte 8))
Where filename is just a relative path which I create using:
(concatenate 'string (book-name manga)
"/"
(extract-file image-url))


 No.931771

>>931527

To be fair portability is one of the least problems of Common Lisp. It's almost Java-tier in that regard (you still need to specify windows .exe or linux whatever when spitting out Lisp image that then just werks without any external depencies wherever, so not quite .jar).

It is obnoxious terrible language nobody uses for anything important, but portability isn't its problem.


 No.931774

>>931587

Why not


(with-open-file (file (ensure-directories-exist filename)
:direction output
:if-does-not-exist create
:if-exists supersede
:element-type '(unsigned-byte 8))

For readability? This is one of the terrible aspects, no differentiation between command and argument. I know my alternative works too, but nobody among Lispers agree on proper format, and difference between using "string" or plain symbol that has no special markers is extremely poorly documented. Nobody really knows what they are doing. I think you could even use 'quote.


 No.931821

File: 10d1c04a42877da⋯.png (32.62 KB, 1326x586, 663:293, write once rewrite everywh….png)

>>931472

>Lisp is extremely flexible

Unless you want it to be fast, use little ram, not be shit, ..

>C is much less portable

Lisp isn't even portable between lisp implementations, let alone something you can target multiple platforms with.


 No.931838

>>931821

>Lisp isn't even portable between lisp implementations

You actually can and should specify which CL implementation to target with which instruction, in case you hop outside spec and use implementation specific functionality like networking. Just write +implementationName and what program should do when ran in that implementation and only that implementation.

Or you can use some library that does it for you and call it a day.


 No.931845

>>931774

Output, create, and supersede are variables but with the : they're keywords. If you run your code, there would be unbound variable errors.

http://www.lispworks.com/documentation/lw51/CLHS/Body/11_abc.htm

http://www.lispworks.com/documentation/lw51/CLHS/Body/11_abcb.htm


 No.931848

File: 28b233bc2baf61c⋯.mp4 (274.03 KB, 360x360, 1:1, How_'Bout_NO.mp4)


 No.933211

File: 9c1684298dac123⋯.jpg (71.5 KB, 669x696, 223:232, 9c1684298dac1236b6595c53f1….jpg)

Imagine if Lisp was as superior AND its programmers as elite as they claim.

There would be no buggy software, everything would be written once and then it would work, most if not all software would be in Lisp, any corporation resisting Lisp for stupid evil corrupt corporate fatcat reasons, as of course why else they use something else than Lisp reasons sick delusional lispfag, would inevitably fall due to superiority of Lisp and its supreme elite programmers, everything would be in Lisp world bug-free and likely building star fleets under super AI made in Lisp of course for lulz in one afternoon by elite hacker.

...yet they have yet to outcompete notepad.exe with their memelanguage and elite hacker skillz


 No.933247

>>931838

That's the fucking problem, every implementation does its own thing. You can write a list of supported implementations, but that's just applying duct tape to the problem, and every time you come across something unportable you apply even more duct tape. Chances are you won't even know that something doesn't work until a user tries running it, it breaks, he files a bug report, you install that implementation, and then you figure out what's wrong and add yet another condition.

> Or you can use some library that does it for you and call it a day.

That's just off-loading the problem to someone else.


 No.933316

>>933211

>There would be no buggy software, everything would be written once and then it would work

Yes just like all those bug free non bloated emacs packages that never conflict with each other and never have errors


 No.933345

>>933316

I never had any problem with any emacs package.

The problem is not lisp, it's money.

The goal is not to provide the most beautifully coded program, written with a good language, it's to literaly puke a shit tone of buggy software coded by pajeet to win the most money possible.

People still don't understand that in a software company, money is the most important, not the software.

But to explain that to a burger, those religion is money, is difficult.


 No.933346

>>933345

Yes its almost like useful shit that works is more important than non existent shit that doesn't funny how that works


 No.933347

>>933345

>I never had any problem with any emacs package.

You must not use emacs very much then


 No.933349

>>933345

Money is measure of success. If Lisp was so good, companies using it could outcompete those other companies you claim "literaly puke a shit tone of buggy software coded by pajeet to win the most money possible" as Lisp companies would be raking in even MORE money. Capitalism 101 you dumb commie fuck.

But nooo that doesn't happen.


 No.933351

>>933349

You forget that capitalism is also about slashing the bottom line as much as possible. I've been reading about the Symbolics LispM* - it really is as elegant as our resident Unix hater claims.

*http://www.symbolics-dks.com/Software.htm


 No.933358

>>933355

That's in fact more or less what they do when they're not in debt. And they are 99% of the time.


 No.933361

>>933358

>That's in fact more or less what they do when they're not in debt

Like google amazon facebook microsoft and every other tech company?


 No.933365

>>933355

False. The larger an industry/company gets, the more they'll need to slash their bottom line to profit. Are you not an American? You can see it happen everyday here.


 No.933368

>>933361

>every other tech company

Every other tech company sold themselves to those giants, or are in fact in debt. Tech giants do sell themselves, but in small chunks.


 No.933370

>>933351

Again Lisp-based companies should be able to outcompete those that "literaly puke a shit tone of buggy software" due to radically lower cost of development and maintenance which slashes costs.

How is understanding market economy so unsurmountably difficult for commies? Can you provide any insight you pothead shit? Or does your brain lack cognitive ability to self-reflect?


 No.933376

>>933370

Symbolics failed because it was a conglomerate of programmers trying to be a software/hardware company. There were far too many internal issues as well. As of now, there is no point programming in Lisp, because everything has stagnated around C. (Which in turn has stymied innovation.)

>How is understanding market economy so unsurmountably difficult for commies? Can you provide any insight you pothead shit? Or does your brain lack cognitive ability to self-reflect?

Way to come to the wrong conclusions, knuckle dragger.


 No.933387

>>933365

The larger a company gets, the more of their operation they can force the taxpayer to pay for, so the more bloat and waste they can take on. They eventually become "too big to fail" at which point their transformation into a parasite is complete.


 No.933389

>>933376

I'm not talking of Symbolics you fucking communist retard. So what if one company was mismanaged? Most are, most fail within few years, who cares. Look at the larger picture if your monkey-like self-reflection incapable communist cognition can do that which I strongly doubt.

Again, why don't Lisp-based companies outcompete what you say are companies that "literaly puke a shit tone of buggy software" in environment which you say is "about slashing the bottom line as much as possible" when claimed radically lower cost of development and maintenance achieves just that?


 No.933395

>>933389

You keep castigating me because you've presupposed I'm a communist, which is false. Symbolics _is_ the best example, they made better software than what was the norm at the time (Eunuchs); but failed because they didn't know how to run a company.

>Again, why don't Lisp-based companies outcompete what you say are companies that "literaly puke a shit tone of buggy software"

Are you new to imageboards? Sometimes the person who replies to you is *not* the person you were originally having discourse with. They weren't able to outcompete them because they were programmers, not businessmen. Unixtards convinced the world that using rm * .foo instead of rm *.foo is a 'right of passage' - the reason Unix won is because of AT&T and patently false _lies_ that are fellated by simians like yourself.


 No.933396

>>933395

> but failed because they didn't know how to run a company

anon you just totally skipped over the entirety of his post


 No.933398

>>933396

He's asking me why they failed when they are easier to maintain - It's because of the Unix psychosis people were already under at the time. Let's talk about the rm example I gave in my last post. Some of the more mentally deficient people here would say "but, any good sysadmin always has backups" - that would be missing the point. It would be trivial to fix that rm issue by giving a warning, but that isn't the "Eunuch way".


 No.933400

File: 522e7bd4adefac3⋯.jpg (190.55 KB, 1920x1080, 16:9, 1526256547978.jpg)

>>933395

>doesn't understand market economy

>can't read

Yup, it's a commie.


 No.933401

>>933398

>He's asking me why they failed when they are easier to maintain -

Not why THEY failed. ffs


 No.933404

>>933400

>shitty moe anime

Watch Feelings of Moutains and Waters, faggot.

>>933401

What do you mean by "they"? Lisp Machines in general? Because they were expensive and Unix is what everyone knew (thanks to AT&T giving it to universities), despite it lacking in everyway. The portability of Unix is the why.


 No.933407

>>933404

> The portability of Unix is the why.

humm I thought lisp was a great magical language that could trivially be ported to anything


 No.933408

>>933404

> Lisp Machines in general

ffs thats just symbolics again


 No.933411

>>933407

I never said that?

>>933408

I don't understand the question you're asking of me - who/what is "they"?


 No.933412

>>933411

Exactly, you don't understand, yet again.


 No.933415

>>933395

You Can't Prove Any of That: The Post


 No.933417

>>933412

Then please elucidate what exactly I'm missing.


 No.933419

>>933415

I Can Only Respond With Memetic Verbiage Because I Have No Sapience: The Post


 No.933421

>what is climacs


 No.933422

File: bb067fdc56e11a4⋯.jpg (11.29 KB, 275x183, 275:183, you win the prize.jpg)


 No.933426

>>933422

Great image macro, champ!


 No.935839

>>933395

>the reason Unix won is because of AT&T and patently false _lies_ that are fellated by simians like yourself.

It's a more sinister version of the Emperor's New Clothes.

https://www.quora.com/Why-do-so-many-languages-base-their-syntax-around-C

>If I had to believe that a God exists and that he, only once, talked to us humans, then, this once definitely had to be to dictate Dennis Ritchie and Brian Kernighan on how to make the programming language with the perfect syntax.

>For C’s syntax was truly inspired.

>Now, many will tell you how great C is. How it’s eminently suited to many tasks. How natural they find the syntax. And so on. It just seems right.

>I largely agree. But I’m afraid mine is the same thinking that Richard Feynman mocks. We find the ‘shape’ of C pleasing, because it’s familiar. And then we think—after the event—that it’s suitable, and well-structured, and so on. It had to be. There’s even another post in response to your question that suggests God spoke to Kernighan & Ritchie. How miraculous is that?


 No.935843

>>935839

>We find the ‘shape’ of C pleasing, because it’s familiar. And then we think—after the event—that it’s suitable, and well-structured, and so on

>We

C's syntax has its problems (mainly types; function pointers and how you must read from right to left if you introduce restrict/const qualifiers) but I don't see anything better out there. Most of C's problems aren't in its syntax, at least.


 No.940782

It seems like after over one month lispfags can't make a simple preferably cross-platform GUI text editor as a proof of concept. Let's give another challenge: make the first efficient AV1 encoder that is in demand in another big thread here.


 No.940788

>>940782

Everyone already answered, avatarfag. Climacs is a pure lisp text editor. kkkys.


 No.940794

>>940788

>265 replies

>2 offhand comments about some Climacs

Well where can I download Windows build so I can test it?


 No.940798

>>940788

>climacs

>click link to devel list

>404

>check last release

>2008

>"Climacs is not yet ready for prime time as a complete replacement for GNU Emacs"

>try to check out the code

>connection refused

lololol


 No.940801

>>940798

Oh wait, it gets better.

>track down where the project went

>find "second climacs" on shithub

<"Second Climacs is an Emacs-like editor written entirely in Common Lisp. It is called Second Climacs because it is a complete rewrite of the Climacs text editor."

>they actually had to restart it from scratch before it was ever useful

>can it even do anything..

<"At the moment, all you can do is type some text, and you can use C-x i to insert and existing file. Some basic Emacs commands also work, like C-f, C-b, C-p, C-n, M-<, M->, and C-x C-c. The visible window does not automatically follow the cursor yet."

It amazes me how completely and utterly useless the lisp community is.


 No.940856

File: 86efa1413dc2067⋯.png (324.88 KB, 1514x994, 757:497, if lisp is so good.png)

This is so hilarious I had to save something for future generations.


 No.941045

>>940794

>windows

lynch yourself


 No.941047

>>940788

This anon ( >>923496 ) answered you and then you just moved the goalpost. You're mentally retarded.


 No.941122

File: 89a8012de869dcc⋯.png (317.86 KB, 1286x1514, 643:757, paper driven development.png)

>>940856

It.. it gets even better.

>look at the commits of second climacs

>recently active, over 1,600 commits

>how can it be barely functional with over 1,600 commits?

>look at the code

>oh

>oh god


 No.941185

File: 749ca079b91a982⋯.png (80.48 KB, 1239x789, 413:263, mit scheme.PNG)

>>941047

I gave Edwin a go but out their Windows binaries fail to run on Win10. Strike one, not working. So good person that I am, I took sources and whoop dee fucking dee what a surprise that it's full of C code again, just like Emacs. Pic related. Try again. This is not what I requested you absolute goatse homos. I gave a pass to Edwin without checking on the first go out of good will, trusting that GNU Scheme comes with some simple line editor, shouldn't have been so gullible. You lied again. And so what if I moved goalposts? Should be given to have a GUI and advanced functionality in text editor these days. Yet you lying pieces of shit can't even outcompete notepad.exe feature-wise.

>>941122

Bwahahahaha! That should say years, maybe decades, as they scrapped original Climacs in 2008, restarted it and here they are.


 No.941195

The mental gymnastics on show by Lispfags in this thread is astonishing.


 No.941321

File: 4e6c98d1e03309f⋯.png (28.79 KB, 1426x760, 713:380, edwin.PNG)

>>941185

Alright, let's go step by step.

>I gave Edwin a go but out their Windows binaries fail to run on Win10. Strike one, not working.

See pic related, stupid fuck.

> So good person that I am, I took sources and whoop dee fucking dee what a surprise that it's full of C code again, just like Emacs.

What you're seeing is the source code of the compiler itself, you can verify that yourself looking at your screenshot: "F:\mit-scheme-9.2\src\...". Also it's funny because I just installed the Windows binaries and it doesn't even come with the C source, so you probably downloaded the source knowingly.

You know what's even more funny? The editor is extensible in Scheme itself, which makes it much more complex that "notepad.exe".

Here, have some documentation:

https://www.emacswiki.org/emacs/EdWin

https://www.emacswiki.org/emacs/HackingEdwinScheme

https://www.gnu.org/software/mit-scheme/documentation/mit-scheme-user/Edwin.html


 No.941328

File: 100baa6660aa407⋯.png (37.56 KB, 512x574, 256:287, Screen Shot 2018-07-11 at ….png)

File: 8dde2ac7e0a4c2c⋯.png (54.34 KB, 717x770, 717:770, Screen Shot 2018-07-11 at ….png)

File: 81fe9e7da6bf909⋯.png (46.64 KB, 717x770, 717:770, Screen Shot 2018-07-11 at ….png)

>>941185

oh and by the way, here, have some code


 No.941341

File: 4aab1a579116e62⋯.png (11.61 KB, 511x78, 511:78, edwin_src.png)

>>941321

>I just installed the binaries

lol wot


 No.941345

>>941341

The Windows installer does not come with the C source.

Instead, when you download the source, it comes with the C source and the Scheme source for the compiler and the tools.

Of course the compiler and essential shit is going to be written in C, it's meant to be portable, not some kind of weird "we can do everything in lisp" competition.

The thing is, the EDITOR (Edwin) is written entirely in Scheme with a couple of shell scripts to ease the install.


 No.941348

>>941345

>Of course the compiler and essential shit is going to be written in C, it's meant to be portable

C is portable now?


 No.941349

>>940798

>>try to check out the code

>>connection refused

What? Seems ok to me.

https://github.com/robert-strandh/Climacs


 No.941350

>>941345

nah unix binary has the C code so...

>not some kind of weird "we can do everything in lisp" competition

So you didn't even read the OP.


 No.941352

>>941350

If we provide a runtime for it you'll complain the runtime is not lisp.

If we don't provide a runtime for it you'll complain that you can't run it.

Either way you are just going to move the goal post.


 No.941354

>>941352

Maybe get on it and write that LISP OS and get it done.


 No.941361

>>941354

Alright.

https://github.com/froggey/Mezzano

It even comes with an editor! You know what that means.


 No.941370

>>941361

Where's the bootloader?


 No.941375

>>941349

The project's website still lists the CVS address. You're looking at the author's shithub which is just an archive of the old code.

https://common-lisp.net/project/climacs/

He's the stereotype of a lispfag that never leaves academia and never accomplishes even simple projects. He's been publishing papers on this non-editor for at least 14 years.


Christophe Rhodes and David Lewis, An editor for lute tablature (accepted for CMMR, Pisa 2005)
Christophe Rhodes, Robert Strandh and Brian Mastenbrook, Syntax analysis in the Climacs Text Editor (ILC, Stanford, 2005)
Robert Strandh, Matthieu Villeneuve and Timothy Moore, Flexichain: An editable sequence and its gap-buffer implementation (European Lisp and Scheme Workshop, Oslo, 2004)


 No.941401

>>941345 >>941350 >>941352

How long are you going to dodge this clear fact that should be apparent for everyone by now: you lispfags can't even make a text editor. You can't make anything. You are completely useless. Your meme language is worthless and so are you.

Let's list concrete basic requirements now so you can't try to weasel yourself out for umpteenth time by combination of lies and referring to obscure/dead/historic projects:

1. Text editor must be written in Common Lisp or in any Scheme dialect, or in mixture of those in any proportions. Spelled out in simplest terms possible: source code must not contain any other language.

2. Text editor must have graphical user interface

3. Text editor must have feature parity with Microsoft Notepad, excluding following features: Page setup and Print

4. Source with build instructions must be available

5. Executable binary providing usable editor must be provided for Linux 4.0+ only, with Windows 10 and macOS builds as applaudable but not obligatory

6. You may seek anyone outside this board for help, but links to source and executable must be delivered to 8ch.net/tech

7. There is no time limit for completion as software projects are never really complete. However, working and runnable version no matter how buggy is to be expected by end of October. Failure to deliver that much is failure of challenge.

8. Any attempt to weasel out of this challenge will be interpreted as surrender and silent admittance that lisp is useless shit language and lisp community consists entirely of useless idiots.

That is all. Think you very smart elite lisp hackers can do that much with your superior programming language? Too difficult? At least try.


 No.941440

>>941361

>can't boot on real hardware, only run on virtualbox, qemu, or kvm

>uses kboot as the bootloader

>lots of assembly with a thin lisp coating

>takes 10 minutes to boot

>does almost nothing

Yep, checks out. It's lisp.


 No.941610

>>941440

It's better than Plan 9.


 No.942634

>>923474

All software environments were ultimately bootstrapped from machine code, so programming languages don't truly exist.


 No.942638

>>942634

They exist because they are, but arguing over which is better or not is ludicrous. It's entirely dependent on compiler/interpreter. Even assemblers dismantle and change the source. Arguing about programming outside of binary instructions and data is demonstrably invalid.


 No.943148

using Lisp-written text editor on a C/C+/et. al. written/compiled OS is wasteful.

Maybe when theres Lisp OS then there will be Lisp anything...


 No.943168


 No.943169

>>943148

Lisp has never been tried.


 No.943192

>>942638

>They exist because they are, but arguing over which is better or not is ludicrous. It's entirely dependent on compiler/interpreter.

The definitions of languages make compiler/interpreter implementations possible or impossible, and this includes hardware. There are hardware designs that just get in your way if you're using C, but are a big help for other languages. Tagged memory gets in your way with C, but it's beneficial for Lisp, Fortran, Pascal, Ada, and other languages, like being able to treat an array or structure as a value. This is because C is based on the PDP-11 and is not really a portable language. C puts more limitations on how hardware can be designed, and prevents many faster hardware designs, so it's definitely reasonable to argue whether one language is better than another from the implementation perspective.

>Even assemblers dismantle and change the source.

Only a few do, like Plan 9 assembler, which doesn't follow the typical conventions for any architecture. Normal assemblers don't dismantle or change anything.

>Arguing about programming outside of binary instructions and data is demonstrably invalid.

High-level languages are for people to read, so it's definitely valid. The value of binary instructions and data comes from properties of the implementation like reliability, speed, and RAM usage. The value of source code comes from how easy it is to read, understand, and modify, which is why Stallman distinguishes between source and viewing the program in a hex editor. Languages have a big impact on hardware and compiler/interpreter design, but also on how easy programs are to develop and modify.

The fundamental design flaw in Unix is the asinine belief
that "programs are written to be executed by computers
rather than read by humans." [Now that statement may be
true in the statistical sense in that it applies to most
programs. But it is totally, absolutely wrong in the moral
sense.]

That's why we have C -- a language designed to make every
machine emulate a PDP-11. That's why we have a file system
that forces every file to be viewed as a sequence of bytes
(after all, that's what they are, right?). That's why
"protocols" depend on byte-order.

They have never separated the program from the machine. It
never entered their tiny, pocket-protectored with a
calculator-hanging-from-the-belt mind.


 No.943233


 No.943253

>>941401

Anyone up for challenge? It's alright to admit it's too difficult.


 No.943254


 No.943332

>>943253

>>941401

nigga this is /tech/ and there's like only 20 posters around. maybe try twitter and @insertsome10xdeveloper

your sample size is too small so there goes the fallacy and bias for coming here.

>That is all. Think you very smart elite lisp hackers can do that much with your superior programming language? Too difficult? At least try.

so when is the deadline of your uni requirement?


 No.943334

>>941401

>source code must not contain any other language

How the fuck are we supposed to interact with operating systems written in C? This is stupid. There's a reason why Emacs has C code.


 No.943356

>>943334

>kvetching about the rules

(((lisp))) everyone


 No.943426

>>943356

What a retard, also have you checked vip?


 No.943468

>>943334

The same way Java, C#, Python etc do I'd think. Then again this thread is making it increasingly obvious what a shit language Lisp really is so I wouldn't be that surprised to learn it can't do basic tasks.


 No.943565

>>943334

>How the fuck are we supposed to interact with operating systems written in C

Via the standard system call list you retard.


 No.943685

>>943254

see >>941401

You are trying to offer me complete lisp implementations that ship with some sort of editor instead of a program. First Edwin now that. Normal people don't point you to JDK if you want to see example of a program written in Java. It's okay to admit you are too incompetent and can't make notepad.exe clone with your shit language that apparently can't interact with operating system.

>>943148

>>943332

>>943334

>8. Any attempt to weasel out of this challenge will be interpreted as surrender and silent admittance that lisp is useless shit language and lisp community consists entirely of useless idiots.

And so this began four posts and four days after posting challenge with every single useless lispfag beginning to cry in unison about it.

Case is now closed and we can all happily acknowledge that

1) Lisp is useless shit language

2) Lisp community consists entirely of useless idiots


 No.943691

>>943468

>The same way Java, C#, Python etc do I'd think.

https://github.com/python/cpython

>has C code

https://github.com/mozillazg/pypy

>has C code

I'm pretty sure Java and C# use C++ or C at some point, probably to do with the native methods or something.


 No.943692

>>943691

They don't need C code (well, Java does because it's shit) they use it in glue because C is so much easier than their faggy high level alternatives like P/Invoke, ctypes, etc..

So many nodevs in this thread.


 No.943772

>>943685

Well I guess Lisp is a shit language because you say so! I will continue to use it regardless, cheers


 No.943773

>>943685

> You are trying to offer me complete lisp implementations that ship with some sort of editor instead of a program.

What? It includes a vim clone in its distribution, what's so hard to understand?


 No.943829

>>943692

>ctypes

Its just a FFI, maybe better than others, but apparently not good enough to actually use for anything too serious. C FFIs for Lisp implementations exist, heres Racket's (Scheme dialect): https://docs.racket-lang.org/foreign/

>they use it in glue because C is so much easier

So they've failed about as much as Lisp has failed in this regard, then.

>>943685

>Normal people don't point you to JDK if you want to see example of a program written in Java.

Yes, just install the JRE to use this program instead.


 No.944040

tbh I'm actually disappointed by infinite kvetching of lispfags. I was actually a bit swindled myself, thinking that community that brands itself as elite hackers with vast knowledge that spends all their worthless time hyping Lisp would take simple challenge with attitude such as "This sounds fun! Let's make it and bunch of other simple usable applications that are just a bit more complex than toy programs!".


 No.944083

>>923533

elisp is a mediocre language in all aspects


 No.947340

I just realized that average pajeet programmer with that has simple graphical Java app in Google Play store has accomplished more than entire Lisp community in 21st century.


 No.947691

Hello so Lisp apolegics ITT have said something about Climacs, which doesn't ship any exe/sh aka ready program and is just a research project some state funded nutty professor from New Algeria has been working on for 20 years. HOWEVER why don't you wankers try to make something out of it? Can you deliver 100% lisp program that

1. is program anyone can run

2. opens native lisp window (CLIM was gui toolkit name)

3. has text field one can type in

I don't think I need to say that asking for something more advanced than that for example saving file or cursor movement is waaaaayyy beyond what entire Lisp community can do.


 No.947697

>>947691


(in-package :common-lisp-user)

(defpackage "APP"
(:use :clim :clim-lisp)
(:export "APP-MAIN"))

(in-package :app)

(define-application-frame superapp ()
()
(:panes
(int :interactor :height 400 :width 600))
(:layouts
(default int)))

(defun app-main ()
(run-frame-top-level (make-application-frame 'superapp)))


 No.947701

File: 549b2ece80e2b89⋯.png (215.16 KB, 506x662, 253:331, web development the correc….png)

>>923563

That's pretty depressing to read.


 No.947787

>>947697

>1. is program anyone can run

>3. has text field one can type in


 No.947802

>>947787

1. install clisp

3. run the program nigger


 No.947813

If Ruby didnt succeed no OOP language will

its combined the best from everyone and avoids the pitfalls

its the C++ of OOP


 No.947820

>>947813

C++ is OOP tho


 No.947824

>>947813

>4/5 TIOBE top5 languages is OOP

>didn't succeed

Absolute state of denial of lispniggers


 No.947825

File: fea678cd26555b7⋯.png (91.41 KB, 265x272, 265:272, 1502044794159.png)

>>947802

I'd like a runnable binary please, just like every application I use. Can't do it? Of course you can't do it. You're a fucking lispfag. Sassuga.


 No.947827

>>947825

Ok, I hope you have a Lisp-compatible processor, then, because I'm going to send Lisp Machine machine code.


 No.947828

>>947825

>What is SBCL, what is Chez


 No.948257

can i make an i bit cpu or simulate a lisp os with some fpgas

big time poser here but it sounds fun


 No.948261

>>948257

so yeah if i wana go down this route (as i see a few other abandoned websites have), is there anything other than my own laziness and lack of skill stopping me from getting an fpga, programming it, and making a baremetal lisp machine ?

Of course itd probably take 5-10 years realistically but still


 No.948275

>okay class let's draw lots and whichever language you pick you have to write a simple text editor for it

>note: it has to be purely written in just that language

>*picks lisp*

>shitposts on tech

???

heh


 No.948529

File: a238e0a988d330b⋯.png (145.51 KB, 798x920, 399:460, 68558768787.png)

>>947827

>>947828

>maybe if we try even more confusing kvetching than usual while playing unusually smug he won't notice that we can't make runnable binaries

Not this time! You absolute shit-assed drooling incompetent morons with FAS and CP know exactly what I mean:

deliver a runnable binary

I don't care if you pretend to not understand what that means, because you actually can be just that stupid that you don't. In fact, that level of idiocy is expected from lispfags.


 No.948542

File: ba42b7203b86809⋯.jpg (28.11 KB, 354x404, 177:202, 1477570946500.jpg)

I'm no Lispfag, however I have a few questions :

1) Considering https://common-lisp.net/project/mcclim/, how come no-one here is able to write a proof of concept Notepad-like application ? What does prevent you from doing the "logical' part of the program, considering the GUI is already available ?

What about writing a POC that only runs through Lisp black magic before trying to have a binary Kizuna would be happy with ?

2) About the binary file, since clisp is a compiler, why not write the program in Lisp and keep it in this form and just have a launcher that is compiled (written in Lisp ofc) interpret the rest of the program. Is there an actual issue compiling the whole project with clisp so that you get a native executable ?

E.g. :


(eval-file 'editor/actual-main.lisp')

3) Just... how come no-one here is able to answer the question, wtf ?


 No.948582

>>948542

"Able to" isn't the right question. "Want to" is. A notepadish text editor is terrifically boring as an application.


 No.948619

>>948582

Do better then


 No.948628

>>948542

I am sure a Lisp compiler can include the runtime library in the executable file.


 No.948647

>>948529

https://common-lisp.net/project/mcclim/excite.html

If you browse any lisp site, you can see what the lisp community is doing. Lisp can be compiled, so binaries are easily distributable. You're just in denial, spastic fuck.


 No.948649

>>948619

Do better what? I'm not spending time to develop an app to please some bad-faith faggot on a polynesian underwater basket weaving board.


 No.948683

>>948647

>lisp can be compiled

>by bundling the entire SBCL compiler and the lisp script in an "executable" and shipping it

tee hee


 No.948689

>>948683

>he thinks compiling means native code

95 IQ cs major


 No.948693

>>948683

>he thinks SBCL is an interpreter

Nigger, compilers are compilers.


 No.948699

>>948689

SBCL does compile to native code.


 No.948724

I've got some experience in C++ and I'm on page 511 at SICP.

I think my main problem with the language is the idolising of abstraction,

factoring out components of complex problems is a wonderful way to increase

code reuse and to divide programs into understandable chunks, but if you build

only with abstractions you necessarily don't know what your program is actually

doing on the machine.

The second problem I've got is with the syntax, writing directly in a AST is

extremely powerful and enables lisps primary features, including its powerful

macro system, but the way this semantic concept is expressed is in the least

ergonomic and readable way possible. Typing lisp is physically painful as is

reading it. Luckily because of the powerful macro system this can be completely

resolved as in languages such as wisp. [1]

Third is the lack of static typing, static typing makes writing programs soo

much easier to debug and understand. I know the reasoning for it not being

included in most lisps (subtypeing is necessary for heterogeneous lists to make

a homoiconic syntax and make macros etc work) but today tech has advanced enough

to make this reasonable as in typed racket. [2]

Just my 2 cents, Lisp has some great ideas but flounders on execution.

[1] http://www.draketo.de/light/english/wisp-lisp-indentation-preprocessor

[2] https://docs.racket-lang.org/ts-guide/


 No.948725

>>948693

>>948699

Really anon. Then what do you think happens when you call eval? It just explodes?


 No.948742

>>948725

SBCL includes itself to make it work. A compiled "Hello, World!" is over 50 megs because the whole compiler has to be linked in. It's embarrassing.


 No.948744

>>948725

Ok, I'm no lispfag and I admit was going off of secondhand info, so I tried it myself.

>write 5 line script to print a number

>look up command to compile with sbcl, it's a bunch of shit, clearly this is something unnatural I'm doing

>exe is 60MB

>strip exe

>no longer does anything

>find compression option

>exe is now 12MB and takes half a second to print a number

This is ridiculous.


 No.948747

File: 02f2c932a1c839e⋯.png (5.17 KB, 332x44, 83:11, Zrzut ekranu z 2018-07-30 ….png)

File: 838fc1d8cf1da82⋯.png (6.84 KB, 587x76, 587:76, Zrzut ekranu z 2018-07-30 ….png)

File: 57124d7348f5b70⋯.png (11.94 KB, 460x110, 46:11, Zrzut ekranu z 2018-07-30 ….png)


 No.948752

File: 852ce965a9e05f2⋯.png (46.56 KB, 1246x275, 1246:275, Zrzut ekranu z 2018-07-30 ….png)

>>948750

So it just calls the sbcl interpreter? That surely is a real binary.


 No.948754

>>948752

kiddo deleted his post after realizing hes delusional, he claimed .fasl is a native binary


 No.948757

You blokes have a naive view of the world. Real life has nuance.


 No.948762

>>948754

>he claimed .fasl is a native binary

I did not claim that. I only claimed that it is the more reasonable option as making a "real binary" is often a pointless pursual.


 No.948772

>>948724

>I think my main problem with the language is the idolising of abstraction,

>factoring out components of complex problems is a wonderful way to increase

>code reuse and to divide programs into understandable chunks, but if you build

>only with abstractions you necessarily don't know what your program is actually

>doing on the machine.

Most programming languages hide what the program is actually doing on the machine. Even with C after the optimizer is done with your code it's barely recognizable. Generally it's best to concentrate on efficient algorithms and data structures and assume the implementation is sensible. I mean sure, integers could be implemented as Church numbers, but it's safe to assume they are implemented in hardware instead.

>The second problem I've got is with the syntax, writing directly in a AST is

>extremely powerful and enables lisps primary features, including its powerful

>macro system, but the way this semantic concept is expressed is in the least

>ergonomic and readable way possible. Typing lisp is physically painful as is

>reading it. Luckily because of the powerful macro system this can be completely

>resolved as in languages such as wisp. [1]

I never had problems with S-expressions, the parentheses become invisible after a while and with a good editor (auto-closing parentheses, rainbow coloring) it's no worse to type than any other language. I never got the appeal of Wisp, it just makes things more complicated than they need to be.

>Third is the lack of static typing, static typing makes writing programs soo

>much easier to debug and understand. I know the reasoning for it not being

>included in most lisps (subtypeing is necessary for heterogeneous lists to make

>a homoiconic syntax and make macros etc work) but today tech has advanced enough

>to make this reasonable as in typed racket.

I agree with this one, static typing has saved my ass a couple of times. You can add type annotations in Common Lisp, but the standard leave open what they do, so most the time a type declaractsion is just a run-time assertion. Unless you optimize for speed, then all safety is thrown out of the winow.

>>948742

>>948747

Then don't write Hello World in Common Lisp. Unix is an alien environment to Lisp, so it has to include its own biosphere. This would be like porting a POSIX application to Windows and complaining how you have to include all of POSIX (via Cygwin) as well.


 No.948774

>>948772

Except Common Lisp is designed to run on UN*X, not on a Lisp Machine.


 No.948784

>>948774

That's now how programming languages work, anon.


 No.948792

>>941401

You're never going to find a language that needs garbage collection that runs on bare metal. It's like asking for the JVM to be written in Java. If this shit is going to be possible at all, it would have to be written in a manually-memory-managed variant of lisp.


 No.948801

>>948747

>52 bytes of code

>39M of executable

Is there a text editor hidden in there or something? How could it possibly need 39M to print "Hello, World!"? I have a Linux-based firmware for my router that's smaller than that and it's a complete OS with web server and shell access.


 No.948805

>>948772

>Unix is an alien environment to Lisp, so it has to include its own biosphere.

Even the .NET core runtime is only 22M and it includes a hell of a lot more and can be reused by every .NET app on the system.


 No.948808

>>948772

>Most programming languages hide what the program is actually doing on the

machine.

Yes, of course, and there is a reason I don't write asm, this is the type of thing

demanding compromise and thats just the conclusion I derived from my limited

experience. The machine metaphor is stronger in C, because memory is tangible.

In fact that seems pretty undeniable, I do understand that this doesn't even make

problems easier to understand for many people but for whatever reason it does for

me.

Obviously this machine metaphor comes at the heavy cost of stateful programming

with all its bugs, lack of composability, and poor concurrency. Im currently in

the process of conceptualising a language based on linear logic to recapture

at least some of this.

Also as far as optimisations go doing something like restructuring data to take

advantage of SIMD instructions or doing cache prefetches is impossible in any

high level language and extremely important.

I can understand it becoming readable given enough time but should we really

design our languages such that they require getting used too for no reason?

Also that doesn't change ergonomics, ) is one of the most difficult keys to press,

I can't imagine what typing lisp for a living on a standard qwerty keyboard

would do to your hands.

Even more so what I don't get is if you are more or less going to be pretty printing

your code, why waste the keystrokes to add additional uneccessary encapsulation.


 No.948809

>>948801

If you are worried about filesize, why not use ECL? You can get the size down to like 13KiB and that still includes all of common lisp.


 No.948820

>>948792

What does "bare metal" mean to you? Because that's common as hell.


 No.948829

>>948792

>Garbage collected languages can't be compiled.

Guess you have never heard of D then.


 No.948835

>>948809

Can I get a Windows executable with that? Can I make a portable text editor?


 No.948837


 No.948838

>>948837

But no one actually has..


 No.948875

>>948808

>Also that doesn't change ergonomics, ) is one of the most difficult keys to press,

>I can't imagine what typing lisp for a living on a standard qwerty keyboard

>would do to your hands.

I don't remember when I had to press ) the last time I was writing Lisp. I use a plugin for automatically inserting the closing parenthesis in Vim and it does wonders.

https://github.com/Raimondi/delimitMate

But why is this a complaint about Lisp specifically? In C you have to use parenentheses as well, the only difference is that you write poo() and poo(in, loo) instead of (poo) and (poo in loo). Same keys to press. This sort of thing was the reason I installed the plugin in the first place, I did not even know about Lisp at that time.


 No.948881

>>948875

In C you don't have ))))))))) at the ends of lines where it takes a sophisticated editor to make sense out of the mess and help identify if the number of them is wrong.


 No.948887

>>948875

yah, I know not sure why didnt include the other ()***

My complaints applied to most languages, they just so happened to also apply to

lisp. C and especially C++ have more problems than I can count.

Lisp really has one amazing idea to me and that is what makes it a lisp,

writting directly in a AST, it cant be denied how powerful this is but I dont

think we should tollerate the rest of the languages flaws just because of this.

And you have to admit using special tooling to make the language usable and

having to "get used to" the syntax are just this, tollerating.

It's really the same thing these Cfags are doing, they recognise the power of a

low floor in a language but instead of taking a nuanced position recognising the

power with the flaws of the language they proclaim it the ultimate language

because there are certain problems it makes possible/easier to solve.


 No.948889

File: 323138eda8660b6⋯.png (36.92 KB, 849x310, 849:310, the power of lisp.png)

>>948887

It's the ultimate language because even lispfags recognize it as such.


 No.948891

>>948809

>Embeddable Common-Lisp

lmfao


 No.948925

File: 81ce497f2cdda05⋯.png (352.27 KB, 533x526, 533:526, 1479575901315.png)

>>948582

>"Able to" isn't the right question. "Want to" is. A notepadish text editor is terrifically boring as an application.

But spending TWO MONTHS actively dodging and kvetching is not? Haha! You could have just whipped up notepad.exe clone in one evening since you sound like super hacker that regularly works on super serious super complicated programs, then said "OP is a fag, kys" and dropped mic, but instead you kvetch and dodge swimming in your nervous sweat for TWO MONTHS. Hahahaha, give me a break!

>>948647

Well do it you CP challenged FAS fuck, it can't be that absolutely impossible to move from this supposedly working code >>947697 to compiled program anyone can run without that much kvetching and sweating.


 No.948942

File: 2cef579d72a7e39⋯.png (440.9 KB, 526x524, 263:262, 1479574479008.png)

>>948762

>Lisp can be compiled, so binaries are easily distributable

12 posts later~

>making a "real binary" is often a pointless pursual.

We are hitting levels of something that needs a new word entirely to describe how lispfags with superiority complex behave that shouldn't even be possible! I'm absolutely astonished at this point over this shitshow where lispfags diligently play the clown part post after post without apparently even understanding that.


 No.948955

>>948881

poo(in(loo(op(is(a(faggot()))))));

>>948887

Granted, but what is the better way to structure source code? Use significant whitespace like in Python? Use semicolons to delimit statements like in C? Explicit tags like in XML? I don't think that S-expressions are really that much worse than any other formal syntax. Writing code in any language using just a barebones notepade style editor is a pain if you want the code to look tidy. I know because that was how I wrote my first lines of code.


 No.948969

>>948955

Concerning ergonomics and efficiency I think whitespace is the obvious solution mainly because you are going to be useing it for encapsulation anyway, and nothing is more ergonomic to type than nothing.

Some additional syntax has to be added to make things work nicely but honestly not enough to matter at all from a ergonomics / learn-ability / implementation perspective. This can be seen in Wisp. [1]

[1] http://www.draketo.de/light/english/wisp-lisp-indentation-preprocessor


 No.949371

>>948942

If you want to distribute a LISP program, you just distribute the source code.


 No.949458


 No.949550

>>949371

Unironically kill yourself for this moronic fucking comment. You still need an interpreter/compiler/whatever to actually execute that code.


 No.949608

>>949550

Your point? Even python users have the mental capacity to know you have to have python installed to run a python program.


 No.949612

>>949608

Sure they do.

>OH NO! This python script is written in a version of python that isn't licensed for my device.

>What will I do?


 No.949647

>>949608

I've seen winfags get confused and frustrated when they have to install Python to run a script.


 No.949730

File: e75ff2b092e0b90⋯.jpg (28.02 KB, 470x470, 1:1, 6ef9abf7.jpg)

>>949608

Damn dude, that must've been the biggest BTFO moment I've witnessed. DAT NIGGA GAT ROASTED LMAO


 No.949731

>>949647

They aren't winfags AND python users for nothing


 No.949736

>>949608

Python users rarely IF EVER go around in forums acting all smug and claiming their language is vastly superior to anything else and all other programming languages are pointless stupid mess. Furthermore Python has been used to create a lot of excellent software a lot of people use. Python community gets a pass. They get shit done, don't act all smug about it, don't go around spreading bullshit that their programming language is some magic bullet, readily acknowledge its shortcomings. Pythonistas are some of the more irritating people, but EVEN THEY are total opposite of do-nothing lispfags. That's how fucking horrible you are.

Besides all that your (typical for idiotic lispfag) grossly misinformed claim over other programming languages is again incorrect. You CAN make Python binaries that don't require Python to be installed very easily. Bing it you fucking lisp retard. Lots of instructions to do just that.


 No.949738

>>923811

>C is not a good language but they still work with it - the real faggots are people like Linus Torvalds - he still hates Wirth and Dijkstra.

Are you one of those cancerfags who hate goto just because?


 No.949743

>>949736

Well that's a load of bullshit right there. Back in the early 00's, a bunch of those python dick suckers constantly raided comp.lang.perl.misc to shitpost and cause flamewars.


 No.949759

>>949736

my god it's unbelievable how mad you are

based lispfags


 No.949786

>>949759

Those mad are the lispfags who constantly report >>949736 for avatarfagging, which to me it doesn't look like, as he is politely discussing and making overall good posts.

You, on the other hand, might get sanctioned for shitposting/thread-derailment.

Stay on-topic and be civil.


 No.949787

>>949743

>>949759

Oh god I replied to slide message, damn!

>we can't do a fucking thing with our shitty lisp! oh no we are being found out as retarded posers with zero achievem !

>hey I know let's start claiming other programmer communities act just like us too and spread total lies about how making portable executables is impossible in that language too!

Well then let's return to topic, my bad, I admit.

Let's return to subject, which is: You fucking slimy kvetching imbeciles swimming in your nervous sweat can't even make a simple very basic graphical application as a portable executable.

You have been dodging that for two months and counting by now.

You are lowest of lowest lower than shit tier tech community ever to exist.

You can't do anything except maybe toy programs, you are completely incompetent.

Your language of choice is utter shit.

Your latest string of bullshitting, dodging and :

>creating runnable binary is simple u stupid avatarfag what is SBCL

12 posts later

>lol trying to create binaries is dumb haha

5 posts later

>well of course you distribute programs as source code lolololol

You people are worse than dogshit.


 No.949799

>>949786

Do you know what avatarfagging is, retard? The tripfags made good posts sometimes, yet you banned and deleted all their posts. You're just a spastic fuck.


 No.949803

File: f0c031250d805c2⋯.png (164.34 KB, 891x546, 297:182, mission impossible for eli….PNG)

Let's get this show back on the road after somewhat successful sliding attempt. Pic related. That is all you lispfags need to do to redeem a tiny bit of dignity after two months of dodging, kvetching, sweating and sliding. Two months until deadline. I am not holding my breath to ever see that "much" accomplished by your entire self-titled super elite community using self-claimed vastly superior programming language.


 No.949804

>>949803

Here's a simple example (OC) of how elegant Lisp can be. A simple "asm" parser in Emacs Lisp:


(defun caddr (x)
"caddr lol" (cadr (cdr x)))

(defun cadddr (x)
"cadddr lol" (caddr (cdr x)))

(defun get-function (str-id operands func-list)
"Finds an instruction function given its identifier string"
(let* ( (instruction (car func-list))
(instruction-str (car instruction))
(instruction-function (cadr instruction))
(instruction-pattern (caddr instruction))
(instruction-param (cadddr instruction)))
(cond
((equal func-list '()) nil)
((and (equal str-id instruction-str) (matches? operands instruction-pattern)) (list instruction-function instruction-param))
(t (get-function str-id operands (cdr func-list))))))


(defun instruction-mov (param operands memory ip)
"Moves from memory to memory."
(setf (nth (car operands) memory) (nth (cadr operands) memory))
(+ ip 1))

(defun instruction-movi (param operands memory ip)
"Move immediate value to memory."
(let ((op1 (cadr operands)))
(setf (nth (car operands) memory) op1)
(+ ip 1)))

(defun arithmetic-immediate (op operands memory ip)
(let ((op1 (nth (cadr operands) memory))
(op2 (caddr operands)))
(setf (nth (car operands) memory) (funcall op op1 op2))
(+ ip 1)))

(defun arithmetic-memory (op operands memory ip)
(setf (nth (car operands) memory) (funcall op (nth (cadr operands) memory) (nth (cadr operands) memory)))
(+ ip 1))

(defun instruction-beqz (param operands memory ip)
"Branches if equal to zero."
(cond ((= (nth (car operands) memory) 0) (cadr operands))
(t (+ ip 1))))

(defun instruction-bneqz (param operands memory ip)
"Branches if not equal to zero."
(cond ((not (= (nth (car operands) memory) 0)) (cadr operands))
(t (+ ip 1))))

(defun instruction-display (param operands memory ip)
"Prints ASCII character."
(message (car operands))
(+ ip 1))

(defun tokenize (operands)
"Tokenizes operands."
(let ((tokens '()))
(dolist (token operands)
(cond ((string-prefix-p "$" token)
(setf tokens (append tokens (list (list 'int (string-to-number (mapconcat 'identity (cdr (split-string token "" t)) "")))))))
((string-prefix-p "!" token)
(setf tokens (append tokens (list (list 'string (mapconcat 'identity (cdr (split-string token "" t)) ""))))))
(t
(setf tokens (append tokens (list (list 'cell (string-to-number token))))))))
tokens))

(defun get-values (tokens)
"Gets the values of tokens."
(let ((values '()))
(dolist (token tokens)
(setf values (append values (cdr token))))
values))

(defun matches? (tokens expected-types)
"Returns true if tokens matches expected-types."
(if (and (equal tokens nil) (equal expected-types nil)) t
(and
(equal (caar tokens) (car expected-types))
(matches? (cdr tokens) (cdr expected-types))
)))

(defun parse-lines (raw-list instruction-def-list)
(cond ((equal raw-list '()) '())
((equal (aref (car raw-list) 0) ?\#) (parse-lines (cdr raw-list) instruction-def-list))
(t (let* (
(line (car raw-list))
(parts (split-string line " " t))
(instruction-id (car parts))
(operands (tokenize (cdr parts)))
(function-object (get-function instruction-id operands instruction-def-list))
(function-symbol (car function-object))
(function-param (cadr function-object))
)

(cond ((equal function-symbol nil) (error (concat "Unrecognized instruction: " instruction-id)))
(t (cons (list function-symbol (get-values operands) function-param) (parse-lines (cdr raw-list) instruction-def-list)))
)))))

(defun execute (instruction-list memory instruction-pointer)
(cond ((< instruction-pointer (length instruction-list))
(let* ((instruction (nth instruction-pointer instruction-list))
(instruction-function (car instruction))
(instruction-values (cadr instruction))
(instruction-param (caddr instruction)))
(message "IP:%d (%s) MEM:%s" instruction-pointer (symbol-name instruction-function) memory)
(execute instruction-list memory (funcall instruction-function instruction-param instruction-values memory instruction-pointer))))
(t instruction-pointer)
))

(defun define-arithmetic-immediate (str func)
(list str 'arithmetic-immediate (list 'cell 'cell 'int) func)
)

(defun define-arithmetic-memory (str func)
(list str 'arithmetic-memory (list 'cell 'cell 'cell) func)
)


 No.949805

>>949804

cont.


let ((memory (make-list 16 0))
(instruction-list '())
(instruction-set (list
(list "MOV" 'instruction-mov (list 'cell 'cell) '())
(list "MOV" 'instruction-movi (list 'cell 'int) '())
(list "BNEQZ" 'instruction-bneqz (list 'cell 'int) '())
(list "BEQZ" 'instrution-beqz (list 'cell 'int) '())
(list "DISPLAY" 'instruction-display (list 'string) '())
(define-arithmetic-memory "ADD" '+)
(define-arithmetic-memory "SUB" '-)
(define-arithmetic-memory "DIV" '/)
(define-arithmetic-memory "MUL" '*)
(define-arithmetic-memory "MOD" '%)
(define-arithmetic-immediate "ADD" '+)
(define-arithmetic-immediate "SUB" '-)
(define-arithmetic-immediate "DIV" '/)
(define-arithmetic-immediate "MUL" '*)
(define-arithmetic-immediate "MOD" '%)
))
)
(execute (parse-lines (list
"MOV 0 $5"
"SUB 0 0 $1"
"DISPLAY !hello"
"# this is a comment that should be ignored"
"BNEQZ 0 $1"
)instruction-set) memory 0)
(message "MEM:%s" memory))


 No.949825

>>949804

You should line break on almost every function call anon. Othewise lisp is unreadable


(+ (+ (* (+ 2 3) (+ 3 4) 3) 4 (+ 3 4)) 4 (* 2 3))

Even worse when other punctuation is involved.


(list (list 'int (string-to-number (mapconcat 'identity (cdr (split-string token "" t)) ""))))


 No.949971

File: be8faf8673a6c31⋯.png (829.02 KB, 834x875, 834:875, be8faf8673a6c31a97ad33392f….png)

lispfags so BTFO they've resorted to shitting up the metaboard in an attempt to get OP banned.

>>>/metatech/1752


 No.950018

>>949804

>>949805

Lisp looks ugly. And it's difficult to use. Imperative languages implement syntax that is closer to algebraic expression. Functional languages are garbage when it comes to that. It is unintuitive. If you want to waste your time with LISP, it's your time to waste. Good luck.


 No.950020

>>950018

>Lisp looks ugly

I disagree. It's beauty comes from its simplicity.

>And it's difficult to use

[citation needed]

It's literally a programming language for beginners. Babby's first programming languages. If you can't handle it then GTFO.

>Functional languages are garbage when it comes to that

Haskell, OCaml, and plenty of other functional languages let you use infix notation. There's even a package for common lisp for using infix notation.


 No.950022

>>950020

>It's literally a programming language for beginners. Babby's first programming languages. If you can't handle it then GTFO.

Then why has no one completed OPs challenge?


 No.950045

File: 24a0cea24f5413c⋯.jpg (22.77 KB, 293x284, 293:284, 1447311400347.jpg)

>>949804

>make simple graphical text editor and distribute it in binary

<sure, here is source code for toy program that has absolutely nothing to do with graphical text editor

What in the everlasting fuck is wrong with you? I'm not even calling you retards anymore, it's beginning to be a grave insult towards retards to compare them to lisperati.


 No.950052

>>950020

Unrelatedly, Haskell also lets you make distributable binaries without 400 posts trying to work it out.


 No.950067

>>949805

Only a lispfag would even consider doing this in lisp and not with a parser generator.


 No.950068

>>950052

Haskell is one of the only "functional" functional languages, but it still suffers from the standard autism of that model that leads to code with low malleability. A few requirements change and the code needs rewritten.


 No.950081

>>950045

I've posted a program I made a few months ago to practice parsing. Maybe that would show you the elegance of Lisp, as I knew it 100% then.

Anywho, I don't have time for your challenges, as I:

a) forgot how to use Lisp

b) don't want to reimplement shit that already exists in the thousands and won't improve my skills

What's the language that you oh-so like, anti-lispfag?


 No.950087

http://www.cs.yale.edu/homes/lucas.paul/posts/2017-07-31-making-an-editor.html

Here you go, faggot. GPLv3 entirely-in-lisp editor. To compile, mash all that shit into a file, and in your command prompt type in `raco exe --gui editor.rkt'

Satisfied?


 No.950122

>>950087

Ah yes the LISP everyone complains about as being most bloated, Racket. It took the big dog of LISP bloat to get a simple text editor working.


 No.950123

>>950068

> A few requirements change and the code needs rewritten.

Lol no.


 No.950124

>>950122

How is Racket bloated? Yes, it has a shitton of libraries available, but it's not like you have to use them all.

What is even the point of this thread? The reason people don't write text editors in Lisp is because there is no need for it when there are already editors available. Writing a text editor is a non-trivial task and no one is going to bother only to appease OP.


 No.950125

>>950124

This.

>>950122

The requirements were met? It's a GUI text editor with features of notepad, and can be compiled into a binary.


 No.950127

>>950124

>Writing a text editor is a non-trivial task

what are you talking about?

>>950125

There's no find or replace.


 No.950135

>>950123

Lol yes. It's the problem with pure functional languages. Code is too clever and slight changes wind up requiring rewrites rather than the kludges you can get away with in imperative languages. This is a well-known fault.


 No.950151

>>950135

This is how retarded your average imperative programmer actual is folks.


 No.950153

>>950125

>Yes guys just include the provided TEXT EDITING BOX AVAILABLE IN RACKET, and add a save button and that counts as an implementation.

LOL


 No.950154

>>950125

>>950087

>lispfag spends 400 posts avoiding the problem

>finally actually posts something

>it's the built in racket text widget

LOL


 No.950165

>>950153

>>950154

What's wrong with it being built-in? It's made in racket.


 No.950174

After finishing TAPL and LISP in Scheme I'll have a go at writing a pure lisp editor.

Most likely R7RS but with type extensions


 No.950183

>>950087

Congrats lispfags, you have your own editor.

Too bad it sucks dick.


 No.950191

>>950174

You read this thread and thought the languages weren't academic toys?

>Scheme does not directly support a GUI library

Good luck anon.


 No.950198

>>950191

They aren't academic toys at all. I find it rather sad that so many reject tools from academia as they're missing out. GHC is a brilliant compiler, ATS2 is another which allows you to get to the level of C while keeping type safety.

I have no issues with FFI bindings / dynamic loading of symbols. Also, I did mention I will not hold to the standard completely thus can fit as much as I need to get things done.

Guile is one which has seen quite a bit of use recently and I'll be glad to add a new R7RS (+ extras) scheme to the list of practical languages.

What do you mean by "good luck"? This isn't exactly a difficult task.


 No.950210

>>950198

>list of practical languages

ATS2 has 69 repos. Guile 310. Scheme as a whole 9,402. Common Lisp 13,668. Emacs Lisp 37,747.

Feel free to kvetch about my numbers anon I know it's something you people really like to do, second only to making grandiose statements that amount to nothing.

>This isn't exactly a difficult task.

hmm


 No.950216

>>950210

Emacs has like 2 or 3 repos, lol. ELPA and MELPA are the main ones.


 No.950225

>>950216

Are you retarded?


 No.950231

>>950225

Are you? Do you know what a repo is?


 No.950233

>>950231

Do you?


 No.950263

>>950135

You do realize, Haskell is very readable for those that write it. Hell even refactoring Haskell is simple as shit as your compiler tells you what needs to be changed when massive changes come about.

Small changes aren't a big deal either as they hadly effect type signatures


 No.950271

>>950263

This, it's one of the safest languages to refactor. While pretty much a newbie, I took the source of a project I used, tore all the guts out that I didn't want, and after fixing all errors it just werked.


 No.950272

>>950271

Yeah that's how I basically learned Haskell, I started a project with someone then as I learned more Haskell I would retrofit the old code with better design or abuse a new technique to get more readable and robust code. It's amazing how far you can take it in terms of readability and maintainability


 No.950281

>>950210

Yet haskell has more yet it's academic.

Each language has a use, ATS being used in a small area where you need C but also correctness, Scheme were you need an extension language or something to explore with, etc.

I'm using scheme to explore type systems and developing an editor as a result with the language built.

You seem to be pushing an editor as a difficult task, it is not. Be it a gap buffer, inefficient array copy, zipper, and/or ropes, editor cores are not that complex. Extending them is.

I find it odd that you put interacting with libraries as difficult when nearly every scheme has FFI for this (chicken, chibi, guile, chez, ...). If the languages here are mere toys then tell me what I should be using in your view. Currently? I see no reason to use awkward languages where a scheme-like makes sense.


 No.950286

>>950127

> what are you talking about?

Writing a text editor requires dealing with the data structures and a presentation library for manipulating the text. It's not something you whip up over a weekend and call it a day. It's on the easier side of non-trivial tasks, but it still requires more effort than would be worth it for no good reason. How about we turn this around: OP, pick your favorite language and write a text editor in it following your own rules.

>>950153

So what, the text% and editor% classes are written in Racket as well:

https://github.com/racket/gui/blob/master/gui-lib/mred/private/wxme/text.rkt

https://github.com/racket/gui/blob/5e433c8035e434b203d2a0a4b1d74e8dd6984a3f/gui-lib/mred/private/wxme/editor.rkt


 No.950290

>>950286

Wowww lisp is so minimal and expressive! It only took over 8000 lines of code.


 No.950292

>>950281

Haskell and Scala have a pretty large number of commercial users at this point.


 No.950313

>>950281

>Each language has a use

I agree kinda.

I've tried ATS. I liked it well enough, it's very interesting but I can't imagine writing anything much with it. Maybe I'm a brainlet who knows.

I've embedded both chibi and guile to get repls inside gui apps, chibi is much better btw almost as easy to embed as lua. That was not particularly easy that's why I say good luck.

>>950286

Maybe you are right anon. But tbf nobody in this thread wrote an editor. So OP could just post a link to Vim or Notepad itself and be done.


 No.950377

>>950122

>Ah yes the LISP everyone complains about as being most bloated

No, that would be Arc.


 No.950445

>>950313

> Maybe you are right anon. But tbf nobody in this thread wrote an editor. So OP could just post a link to Vim or Notepad itself and be done.

Sure, but OP started this dumb topic, so I think it would be fair if he did the first move.


 No.950486

>>950087

No. See rules >>949803

>>950174

Looking forward to it.

>>950286

I'm not making pompous claims to superiority in any way while lispfags constantly claim superiority in both skill and programming language in most arrogant manner possible while having nothing to show for it. Plenty of not-made-with-lisp editors and IDEs around anyways in case you haven't noticed. Sorry guys, onus is on you. Or should I say anus, you have been shitted on hard and you deserve all of it. Incompetent little fucks.


 No.950825

>>950486

> I'm not making pompous claims to superiority in any way while lispfags constantly claim superiority in both skill and programming language in most arrogant manner possible while having nothing to show for it.

There is that one lispfag who keeps posting unrelated usenet quotes, so what?

> Plenty of not-made-with-lisp editors and IDEs around anyways in case you haven't noticed.

Yes, and we have shown you DrRacket, which is written in Racket (a Lisp). So what is the point of this thread? Do you want /tech/ to write an editor or what?


 No.950828

This thread is timeless proof that lisp is leftyfag levels of delusion.

Do nothing except kvetch about everything, the rules, abstract concepts, claim it's unfair to be challenged, that challenges are beneath you, that you aren't arrogant, everything.

Post totally unrelated links or points then act smug, duuh educate yourself about binaries.

Complain to mods to ban, delete posts that you can't refute.

If eventually one of the links is approximately relevant act like "we" won the argument and shut down the conversation.

>we have shown you

>what is the point of this thread

Never finish anything, never confront the central point, claim the achievements of others and accept no responsibility.

Make exaggerated claims of competence/ability which you never ever follow up or come close to demonstrating. "Hey I'm a genius who could easily refute this but I'm too busy."

Pretend nothing happened.

Convince yourself that the opposite of all these things is what happened itt.

Truly an eye opening thread.


 No.950835

>>950825

>one

No, that behavior is ubiquitous to lispfags. Look at this fucking thread you stupid slimy motherfucker. Not a single one of you has even come close to admitting you are bullshitting with all your constant babbling about lisp superiority. Again, you are kvetching and dodging.

>Yes, and we have shown you DrRacket,

No you haven't. Search this thread. Yours is the first mention of DrRacket. It took 428 posts ITT for someone to deliver a solution that fulfills only one of the requirements, again, rules >>949803

It's 100% racket code, congrats! Checked source on Github. Now... why do I need to download and install entire language that takes 467MB hard disk space on Windows to use it? That's not exactly distributable text editor binary. Not to mention entire Racket source itself again has not so surprisingly C code in it. You fail again fag.

Can this thread be given some special privileges? Seems to be at bump-limit. Absolutely golden, too good to let it go to waste. Archive material even. Never thought BTFOing entire lisp community would be this throughout.


 No.951642

>>950081

>forgot how to use Lisp

<forgot how to use lisp


 No.952452

>>949786

>it's not avatarfagging if he makes good posts

cringe


 No.952634

>>952452

Well, it's true though.




[Return][Go to top][Catalog][Nerve Center][Cancer][Post a Reply]
Delete Post [ ]
[]
[ / / / / / / / / / / / / / ] [ dir / animu / arepa / asmr / fast / hypno / leftpol / tacos / vg ]