/tech/ - Technology★

UNIX machines are shit and never amounted to anything. Unix haters bitch all day about Unix problems from 20 years ago and yet cant even build a basic functional system. Remember guys UNIX is simple and elegant! In fact its so simple we are incapable of writing a modern version and can only bitch all day.

>>921190

>UNIX machines are shit and never amounted to anything

<What is LINUX, BSD, OSX

> In fact its so simple we are incapable of writing a modern version and can only bitch all day.

<What is almost every OS

>>921193

><What is LINUX, BSD, OSX

Not UNIX

><What is almost every OS

Not UNIX

>>921194

sorry pedantic fuckwit https://en.wikipedia.org/wiki/POSIX

>>921197

>Not to be confused with Unix, Unix-like, or Linux.

hmmmmmmmmmmmmmmmmmmmmmm...

>>921198

You realize unix haters hb is not literally about original at&t unix right.

>>921198

Just replace everything above with *posix if your brain is capable

>>921200

UNIX a shit. No matter what flavor.

>>921201

POSIX is also shit.

>>921203

>POSIX is also shit.

See initial post >>921189 (OP)

Bitch and moan with no productivity

>>921205

???

>Bitch and moan with no productivity

So like OP?

UNIX, POSIX, and LISP is all a shit.

>>921207

>UNIX, POSIX, and LISP is all a shit.

I am comfy with my POSIX machine.

>>921209

>no permissions

I'm not.

>>921210

>What are accounts

>>921211

*users

>>921211

>>921212

useless

anyways i'm going to stop. this thread a shit.

>>921213

>>921214

Please leave

>In fact its so simple we are incapable of writing a modern version and can only bitch all day.

It takes a tough man to make a tender chicken.

     It Takes a Tough Guy to Make a Tender Chicken


  Cooking chicken badly is easy.  (Search for the "Rubber Chicken
Circuit.")

  In large family reunions at my grandmother's, preparations for
barbecuing the chicken started months before, with gathering the wood
out in the trees.  (Yes, you could just pick up wood on the day of the
barbecue.  Wood that had seasoned by lying on the ground.  It wouldn't
make good coals, or any coals at all, really.  You'd end up with
chicken that was half burnt and half raw.)

  So you gathered green wood months/years before, and put it where it
would season properly.  You gathered real wood, instead of buying
charcoal briquets, because it flavored the chicken better.  

  You also chopped the wood into small enough chunks to make coals of
the right size to spread across the bottom of the barbecue and heat all
the food evenly.   You also got up before dawn to light the seasoned
wood and partly cover it so that it would make good coals.  It would
take hours for the wood to burn down to coals, but anything cooked on
them would not taste of lighter fluid.  And you had to watch the wood
so that nothing went wrong.

  The coals would be taken from the open pit where they had been
prepared and put into closeable barbecue pits for the actual cooking.
(Moving lit coals is not something you should undertake lightly.)

  Barbecuing would start about 10:00am, or earlier, to have the food
ready at 1:00pm, or later.  That's how long it took to cook chicken,
etc, to be tender and juicy.  (Just cooking the food that long wasn't
enough, remember.  The coals had to be right so that the food didn't
overcook or undercook.)

  The proper way to barbecue chicken so that it's not rubbery I never
learned properly.  It's probably too long to relate here anyway.

>>921189 (OP)

>Lisp Machine Hate Thread

Why would I hate technology that I never, in any way, interacted with?

>>921226

>LISP keyboards have Facebook thumbs up/down keys built in

>>921226

All high IQ people spends years memorizing as many esoteric commands and flags as possible on Unix. Asking for helping is what brainlets do.

>>921194

If none of that counts as UNIX then nearly nobody on this board uses UNIX. And if that's the case then why do you spam unix.haters copypastas all day long?

>>921226

Yes anon thats what we need more GUI.

>>921241

because apropos exists and so do man

>>921226

Do you want more people that don't know how to use a computer shitting everything up? Why not shill Apple instead then?

>>921289

>Do you want more people that don't know how to use a computer shitting everything up

Are you in favor of having no documentation at all then? Maybe if we gave them documentation they would then know how to use a computer.

>Why not shill Apple instead

Why would I praise a weenix like operating system?

lisp machines stands for the faggy lisp those people have lol

Gradually, I realized that the Social Democratic press was conducted predominantly by Jews. But I did not put any
special significance on this circumstance because the conditions were exactly the same in the other papers. Only one
fact was obvious: there was not a single paper with Jews present on it that could be designated as truly national, at least
according to my education and conceptions.
When I mastered myself enough to read these kinds of Marxist press productions, the aversion grew to such proportions
that I now sought to get to know about the manufacturers of these thrown together villainies.
From publishers on down, they were all Jews.
I gathered all the obtainable Social Democratic brochures and sought out the names of their authors: Jews. I noted the
names of almost all the leaders: they were in by far the greatest part also members of the “Chosen People,” whether
acting as members of the parliament or in the secretariats of the trade unions, heads of organizations, or street
agitators. It was always the same uncanny picture. The names Austerlitz, David, Adler, Ellenbogen, etc. will remain
eternally in my memory.
One thing had become clear to me: the leadership of the Party, with whose petty members I had been carrying on a
violent battle for months, lay almost exclusively in the hands of an alien people. For that the Jew was no German I now
knew to my inner satisfaction and with finality.
Only now did I learn to know the seducers of our people completely.
A year of my sojourn in Vienna had sufficed for me to become convinced that no worker could be so stubborn as to be
beyond better knowledge and better explanations. Slowly I mastered their doctrine and employed it as a weapon in the
struggle for my own inner convictions.
Almost always now I was victorious.
The great mass was to be saved but only after the heaviest sacrifices of time and patience.
Never, however, was a Jew to be freed from his viewpoint.
I was still childlike enough at that time to want to make the madness of their doctrine clear to them; I talked my tongue
sore and my throat hoarse and thought that I must succeed in convincing them of the harmfulness of their Marxist
insanity. In fact, I achieved just the opposite. It seemed as though the mounting insight into the nihilistic effect of Social
Democratic theories and their realization only served to strengthen them in their determination.
The more I argued with them the more I learned their dialectic. At first they calculated on the stupidity of their adversary.
Then, when they could find no other way out, they played stupid themselves. ...Whenever you attacked one of the
apostles, your hand closed around slimy matter which immediately separated and slipped through the fingers and the
next moment reconstituted itself. If you struck such an annihilating blow that, observed by the audience, he had no
choice but to agree with you, and thus you thought you had taken one step forward, the next day your amazement would
be great. The Jew knew nothing at all about yesterday and repeated his same old twaddle as though nothing had
happened; if you angrily challenged him on this, he could not remember a thing other than he had demonstrated the
correctness of his assertions on the previous day.
Many times I stood there astonished.
I didn’t know what to be more amazed at: their verbal agility or their art in lying.
Gradually, I began to hate them.

>>921299

Based post, fellow MAGApede

>>921222

Checked!

And THIS.

How can we hate what we never used?

Many may hate *NIX, but it's there, it's being used. This is infinitely better than not have anything at all.

>>921220

That's a bullshit excuse.

>I won't try to come up with a cure to cancer because it takes a tough man to make a tender chicken.

>>921340

C is shit but Lisp is slow.

>>921341

C is a quick hack of a compiled language that has grown exponentially by adding adipose crap to it, it has "ANSI" "standards" to make the language sound legitimate, but is generally fast. If you want a replacement for C, we already have it; It's Pascal (Ada is good too).

"The designers of Pascal were aware of this problem and "fixed" it by storing a byte count in the first byte of the string. These are called Pascal Strings. They can contain zeros and are not null terminated. Because a byte can only store numbers between 0 and 255, Pascal strings are limited to 255 bytes in length, but because they are not null terminated they occupy the same amount of memory as ASCIZ strings. The great thing about Pascal strings is that you never have to have a loop just to figure out the length of your string. Finding the length of a string in Pascal is one assembly instruction instead of a whole loop. It is monumentally faster.

The old Macintosh operating system used Pascal strings everywhere. Many C programmers on other platforms used Pascal strings for speed. Excel uses Pascal strings internally which is why strings in many places in Excel are limited to 255 bytes, and it's also one reason Excel is blazingly fast.

For a long time, if you wanted to put a Pascal string literal in your C code, you had to write:

char* str = "\006Hello!";

Yes - you had to count the bytes by hand, yourself, and hardcode it into the first byte of your string. Lazy programmers would do this, and have slow programs:

char* str = "*Hello!"; str[0] = strlen(str) - 1;

Notice in this case you've got a string that is null terminated (the compiler did that) as well as a Pascal string. Also, since strcat has to scan through the destination string looking for null terminators each time, again and again, C strings were much slower than they needed to be, didn't scale well, and were obsolete.

>>921344

>Pascal strings are limited to 255 bytes in length

Well thats real great. Have fun with your real language that cant even have a kilobyte piece of text.

>>921345

https://web.archive.org/web/20170223042420/https://www.joelonsoftware.com/2001/12/11/back-to-basics/

Shlemiel gets a job as a street painter, painting the dotted lines down the middle of the road. On the first day he takes a can of paint out to the road and finishes 300 yards of the road. “That’s pretty good!” says his boss, “you’re a fast worker!” and pays him a kopeck.

The next day Shlemiel only gets 150 yards done. “Well, that’s not nearly as good as yesterday, but you’re still a fast worker. 150 yards is respectable,” and pays him a kopeck.

The next day Shlemiel paints 30 yards of the road. “Only 30!” shouts his boss. “That’s unacceptable! On the first day you did ten times that much work! What’s going on?”

“I can’t help it,” says Shlemiel. “Every day I get farther and farther away from the paint can!”

>>921349

>This justifies sub kilobyte strings.

>>921344

I like a macro challenge. I think this should work for any compiler that supports literal concatenation.

	#define PASCAL_STR(X,S)\
	  char __PASCAL_ ## X[sizeof(S)+1] = " " S; __PASCAL_ ## X[0] = sizeof(S); char * X = __PASCAL_##X+1;
	
	PASCAL_STR(test,"This is a test\n")
	
	for(int i = 0; i < test[-1]; i++)
		fputc(test[i],stdout);

>>921193

>Linux is not UNIX

Damn right a kernel isn't UNIX. And GNU is literally an acronym for GNU'S Not UNIX.

>>921365

An operating system is "software that securely abstracts and multiplexes physical resources" (Tanenbaum, 1987). Sure sounds like Linux to me. While we're at it, quoted from The Design of the UNIX Operating System:

The operating system interacts directly with the hardware, providing common services to programs and insulating them from hardware idiosyncrasies. Viewing the system as a set of layers, the operating system is commonly called the system kernel, or just the kernel, emphasizing its isolation from user programs. Because programs are independent of the underlying hardware, it is easy to move them between UNIX systems running on different hardware if the programs do not make assumptions about the underlying hardware.

All GNU programs are userspace and non-essential. Richard is just using this as propaganda and you idiots are falling for it.

>>921370

Stallman and his foot fungus was really the worst thing to happen to free software.

>>921371

True. Something a lot people don't know: Stallman TOOK James Gosling's code to make GNU Emacs. Same with gcc - he copy-pasted code from the Pastel compiler. When Gosling made his (previously unlicensed) version of Emacs proprietary, they told Stallman to remove what he stole. He went apoplectic. This happened on at least two other occasions, where Stallman took code and was asked to stop later, further enraging him. In fact, he set out to destroy Symbolics by cloning their software. Originally he was stealing it directly out of the source code until they locked him out. Later, he cloned it based on the documentation. This is also what gave him the impetus to make his communist license. Later, when he failed to make a kernel before Linus, he gave up programming and went purely into activism. He was angry at Linus, and set out to make sure everyone knew it should really be called GNU/Linux - and that Linux was only "a single program." Also, you know as well as I do that Stallman would be in court for cloning their software identically and giving it away today. Everything he's done is just a pathetic/petty defense mechanism.

Haskell machines when

>>921344

Jesus fuck man at that point just make a struct.

>>921406

>Haskell machines when

We already have the spineless tagless g-machine.

>>921376

>>921371

protip: free software works exactly like this, you fork software to make it do new things that the upstream project doesn't do.

>>921437

>protip: free software works exactly like this

They literally were not free software. He was just stealing.

>>921439

All software was free software by default during that time. This is how all computing and all software worked at the beginning of computers. It worked this way until the 70's when developers decided that software should be controlled and restricted rather than be free.

>>921441

>All software was free software by default during that time

Really anon? Where was the document where the developers waved copyright?

>>921441

You should go check your history books. Even when RMS started to reimplement stuff based off reading from the documentation he still copy and pasted some code from Symbolics (albeit from what I remember it was only some minor stuff). What happened at the MIT AI lab was one tipping points of RMS creating the free software movement.

>>921441

Are you retarded? code is and always has been copyrighted by default, unless you explicitly license it as free software. Even the FSF will say this on their website.

>>921442

>>921446

None. When I buy a lawnmower and lend it to a friend, do I create a proof of ownership certificate and get my friend to sign a lease contract before making it happen? This kind of thing doesn't happen between friends. Likewise at the beginning of computing, the computer engineers and mathematicians wrote software and shared the software freely with one other. Sometimes they forked the software to make it do new things that the parent software didn't do and all this happened freely.

>>921444

Stallman started the free software movement because there was a political attack on his community: the attack that software should be hoarded and users be required to capitulate to the owners of the software. He did this because his community was a community that lived by freely sharing software and this was the norm from the beginning of computers up until that point.

>>921449

>When I buy a lawnmower

You can hate copyright law all you want. It existed back then, it exists now. Software was copyrighted all the same.

> the attack that software should be hoarded

Yes I see keeping the secrets of what you made to yourself is an attack.

>>921449

>because there was a political attack on his community

Guess who did that. It was Symbolics. The MIT AI Lab and Symbolics had a legal agreement that stated that MIT AI Lab was able to get access to the changes to the lisp machine that they made, BUT they could not redistribute these changes to anyone else.

>>921452

Sad! MIT made a voluntary agreement with a company and that is somehow an attack on the MIT community!

>>921450

Software was copyrighted in that time but there were no violations of copyright law. The copyright holders gave implicit permission to share and redistribute the software.

>>921452

The Symbolics company was just one part of the problem of proprietary software, they were not the only problem. The political attack on Stallman's community was a much wider problem. The attack is on the very idea that users ought to be free in the software and Symbolics weren't the only people who were advocating the idea of proprietary software to the public at large.

>>921455

>The copyright holders gave implicit permission to share and redistribute the software.

Bullshit. Almost all software has always been proprietary. We had proprietary Fortran code bases starting in 1957, proprietary COBOL 1959, shit ton of assembly before both of those. The idea it was all commie freedom land is totally inaccurate.

>>921455

People never gave "implicit permission", it was a violation of copyright law. In the example that was originally mentioned, the copyright holder also understood and observed what RMS did as a violation of copyright law. The copyright holders did not give implicit permission to redistribute the software by distributing their own copyrighted software for free.

>>921459

People did give implicit permission, you simply went to the person who wrote the software and asked for a copy. Your peers would then come to you and ask for a copy. This was the normal way for software at the beginning of software. This also happened in Gosling's Emacs - it was freely shared at the beginning. This state of affairs was changed when he decided that Emacs will be completely controlled by himself. What Gosling didn't understand is that you cannot take back what was already put into the public, you can only restrict new publications of works.

>>921467

>What Gosling didn't understand is that you cannot take back what was already put into the public.

If I put some software on my website with the source code available that DOES NOT MEAN I am giving up copyright to it.

>>921471

Yes.

>>921478

And if I give you a copy that does not mean I have given up copyright

>>921480

Yes.

Year of the microkernel desktop when?

>>921515

There are better streamcatchers than youtube-dl, like quvi, cclive, and rtmpdump.

>>921437

In theory. In practice you then become maintainer and run at risk of your fork breaking at some point with what it depends on. Happens so often it's silly in so-called pro environments where people dick around with that one part from npm and few months or even weeks later start getting unexpected behavior that's hard to debug.

>>921523

No they are not, youtube-dl offers full range of formats to download and integrates with ffmpeg to wrap them up to whatever you want.

>>921525

<youtube-dl

>unironically recomending the downloader jewgle themselves took over and crippled the functionality of to (((respect copyright))) and download slowly from jewgle's personal servers by shoahing patchsets to bypass throttles

>>921523

Why not streamlink?

>>921528

What? I'm getting max speeds with it.

>>921376

>communist license

GPL is most capitalistic license that exists. It allows you to hire whoever you want to modify your software, instead of being at mercy of whoever originally wrote propriety software.

>>921621

inb4 developer freedom is more important than user freedom

>>921521

Its sad that lisp machines have no meaningful security and are really the opposite of a microkernel.

>instead of being at mercy of whoever originally wrote propriety software

By the original developer I do believe you mean the capital owner.

>>921683

>have no meaningful security

They are single user machines. You can trust all the code that is running on it.

>are really the opposite of a microkernel

How so? I could see an analog being made that about how the LISP interpreter is the microkernel and the lisp code for managing the hardware are the equivalent of the userland drivers.

>>921699

>You can trust all the code that is running on it.

Really the it being an insecure piece of shit is a feature guys!

>are the equivalent of the userland drivers.

Except those userland drivers are not userland. Its all one uni stack.

>>921718

>so in second pic related, does it look more like left or right?

Its user mode vs kernel mode that matters. If you run all your code in the kernel level its not a micro kernel.

>>921226

What does the "rub out" key do?

>>921757

Backspace?

>>921762

correct

>>921757

It preforms a backspace. (moves the cursor back one and deletes the character) Some later keyboards for LISP machines also included a BS key. For those keyboards rub out and BS were equivalent.

>>921744

>It looks more like the right. See pic related.

Do you have literally any evidence that its structured that way.

>>921796

What part of it are you skeptical about? Once you tell me, I'll try to find a source pertaining to the claim.

>>921341

Lisp being slow was true enough in the 70s and earlier. But in the 80s it had dedicated hardware to run on and today SBCL is almost a third the speed of C for trivial programs, which makes it much faster than Python or Java, for example.

>>921812

>SBCL 1/3 the speed

That's a laugh. When I was programming in LISP, my program would take 6 hours to complete. In C, that time was 2 minutes.

>>921803

>What part of it are you skeptical about?

That the LISP operating system is at all comparable to a micro kernel.

>SBCL is almost a third the speed of C for trivial programs, which makes it much faster than Python

Yes anon I have no doubt that your slow language can be faster than other languages known to be slow.

>>921824

>>921824

>That the LISP operating system is at all comparable to a micro kernel.

Just take a look at the picture. The Microkernel based Operating System and LISP based Operating System look similar for a reason. A key similarity is the fact that the arrow connects two things that are on the same layer unlike the monolithic kernel operating system which communicates only vertically.

>>921848

>Just take a look at the picture.

I can see the picture anon. Now why do think that represents the lisp OS at all. Having an interpreter somewhere does not magically make that the architecture.

>>921853

>Now why do think that represents the lisp OS

The file driver was written in lisp. Device drivers were written in lisp. The code for scheduling the applications was written in lisp. When an application wants to interface with for example the disk it calls a method in the file driver to do so. All of this is running on the same lisp interpreter.

>>921860

>The file driver was written in lisp. Device drivers were written in lisp ....

Yes anon and on my Linux machine the file driver is written in C, the drivers are written in C, the scheduler is written in C. That does not make Linux a microkernel.

If these are all isolated userspace implementations then that would be a microkernel. Thats not how it works on shitty lisp machines. They have no user / kernel space isolation.

>>921848

>>921853

>>921860

>>921867

LISP is nil terminated. Freaks.

>>921872

And? You going to bring up the fact that it uses cons cells?

>>921874

LISP is nil terminated.

>>921882

and?

>>921867

>They have no user / kernel separation.

And therein lies their brilliance.

>>921935

>Lack of basic security is a feature

>>921936

They were single user machines intended for experts. Security was not

a design consideration. You'll find that this was pretty well the norm at the time,

since even though computers could be networked, they were rarely used

by lay-people and intentionally malicious code was almost unheard of.

>>921938

I agree, any program should be able to crash the entire machine. The software will be such amazing quality that this can never happen.

>>921944

That typically didn't happen though since everything is written in lisp and the parts of the device drivers that invoked low level instructions were small. Worst case, the debugger popped up giving you options such as aborting or restarting the process.

<but what about if someone wrote C code

Unlike something like unix, runtime errors bring up the debugger instead of just crashing. This means you can just abort the process that crashed without having your whole system crash.

Fun fact: Like temple OS, Symbolics C comes with a C listener that let's you type C code like in a REPL. This code also does not need to be linked (it also doesn't get linked in temple on either)

>>921978

> Worst case, the debugger popped up giving you options such as aborting or restarting the process.

Wait tho. I thought the hardware-level debugger on Lisp machines let you actually examine the code, change stuff, and then resume the process?

>>921988

Depending on what type of error yes. Usually it's not worth doing though. I typically just look at the backtrace and abort.

>>921978

>and the parts of the device drivers that invoked low level instructions were small.

Your answer is literally the green text above. The absolute state of lisp fags.

>>921936

>>921938

>>921944

The confusion comes from different ideas of what security means. Lisp users think security means keeping your machine safe from hackers, protecting your data from broken or malicious programs, keeping programs from being corrupted/altered by viruses, and the like. UNIX weenies think security means keeping the user away from parts of the machine, like being unable to replace or delete the MINIX on your chip. They can't understand how an OS that lets the user do anything can prevent programs from doing anything.

Of -course- mail to Unix-Haters fails to blame any
particular responsible individual.  -Every- little bug or
problem is actually the responsibility of some individual,
if you could only figure out who.  The problem is that
dealing with Unix seems like a grand game of finger pointing
and pass-the-buck (without Harry Truman).  Is the real
problem that the programmer didn't check the array bounds?
Or is it ultimately the fault of the designers of C for
designing a language in which programmers must error check
array indices manually?

Eventually, you stop caring about the details that would let
you sort out who was responsible.  Recently I was unable to
use FTP on a PC to send a file to my directory on a Unix
machine because on the Unix box I use the `bash' shell.
Heaven help me, I even understand why this restriction
plugged yet another security hole in Unix, and I was able to
remove the restriction as soon as I understood what was
happening, but after enough absurdities like that, your
average user has no energy left to assign blame.  What do
all these bad experiences have in common?  Unix!  Thus, Unix
is the problem.

Hell, Unix even -encourages- this phenomenon.  Contrast what
happens on ITS or a Lisp Machine or Multics when a program
error happens, with what happens on Unix.  On ITS, Lisp
Machines or Multics your program suspends and you are given
the opportunity to debug the problem and perhaps fix it and
proceed.  You are given the chance to assign some blame.  On
Unix -- *blam* -- core dumped.  -Maybe- you can debug it,
but you certainly can't proceed, so why bother?  Ignore that
(huge) core dump file and move on to your next task.

Note that users -like- this behavior.  No kidding.  Ask half
the graduate students at MIT these days -- they -hate- the
Lisp Machine debugger.  All those blasted -choices-.  All
those explainations and questions.  They don't want to know
who to blame -- all they want to know is that it what they
were doing didn't work so they can try something else.

So if I want to -think- about who to blame for my problems,
I'll go use a Lisp Machine (or an ITS or a Multics).  But
these days I use Unix, where I don't have to think.

				- A Satisfied Customer

>>922290

>Really the lack of security is a feature suck it UNIX!

>>921190

Nice madlibs

>>922308

I'm glad we finally agree on something cuteposter. That's a rare thing.

>>922308

It doesn't have to be one or the other. You could design a computer where only the local user sitting at the console can use the hardware debugger. On a Unix system, the dude who has physical access to the machine can do wtf he wants anyway. There is no security there already.

>>922318

>Physical access

Anon these are multi user networked machines.

If Lisp is so good how come my self-contained lisp image hello world is 31 megs in size and I can't make other kind of binaries?

(if that abomination is even a binary that is)

>>922308

>That's an Intel and x86 hardware issue, not an issue with the OS software.

He was making an analogy. Who's the baka now.

>>922323

It's bundling the whole LISP interpreter / compiler with it.

>>922325

>It's bundling the whole LISP interpreter / compiler with it.

Bloat

C is the mostly bloated language there is. Anyone who does not want to use C must package interpreters and JIT compilers with their code to get it to run. Everyone duplicates their work over and over and over again. Code sizes bloat and all because we are stuck with this stupid little autistic language that was never supposed to leave the lab. C is the equivalent of a fat girl taking a myspace angle picture to present herself at fat.

>>922325

>60 year old language

>still can't make a proper executable

LISP is the ultimate LARP language.

>>922333

Will you be ok?

>>922321

Lisp machines don't exist anymore though, and they were gone before the age of botnet. If you were to design one today, then yeah you'd have to make sure only the local user has access to the hardware debugger, since you're basically giving him negative gonzo ring priviledges. But hey, if I buy a computer, that's exactly the kind of access I want to have.

>>922333

>C is the mostly bloated language there is

ok let's see why

>Anyone who does not want to use C must package interpreters and JIT compilers with their code to get it to run

...that would make C less bloated

>C is the equivalent of a fat girl taking a myspace angle picture to present herself at fat

1. who the hell still uses myspace?

2. so she's angling it to make herself look fatter?

3. how in the world does this relate to C?

>>922336

pls rember that wen u feel scare or frigten

never forget ttimes wen u feeled happy

wen day is dark alway rember happy day

>>922330

>>922335

Lisp wasn't meant to be used in an environment where each program is its own self-standing binary.

Instead a system listener should load and evaluate code at runtime. This listener can load compiled code as well as plain text representations. On my machine a compiled hello world in Common Lisp comes to 149 bytes, smaller than any C program you can easily create, as far as I know.

You could also claim C is huge and bloated if you include the size of the kernel with every binary, it's not like most programs will run without it.

>>922442

Also it should be noted that there are implementations such as ECL that can create relatively small binaries by using C as an intermediary language and stripping unused functionality such as runtime evaluation.

>>921299

Nice hitler text

>>922341

>how in the world does this relate to C?

It is a metaphor you autistic faggot. C promises you lean binaries but this is a lie because once you look behind the curtain you realize the code base is massive compared to a higher level language. Just like a fat girl taking a myspace angle picture.

>>921189 (OP)

they can't be worse than UNIX cancer

>>921872

Lmao, eat shit homo.

>>922475

Fuck you too.

>>922490

>wew

see

>>922442

>>922442

That's either flawed or Jewish thinking mixing up the role of the kernel. Think of it this way: I can make a tiny C plugin for another program whether that program is written in C, Python, or even LISP. But can I make a tiny LISP plugin for a program that isn't written in LISP? The kernel is irrelevant.

>>922584

> I can make a tiny C plugin for another program whether that program is written in C, Python, or even LISP

Thats because literally every language has a C FFI because they all run on Unix or Windows and its nearly an absolute requirement. If everything else had a LISP FFI it would be the same situation.

>>922593

How do computers work?

>>922593

Are you really that clueless or are you merely pretending?

>>922602

>>922598

>Every language has a C FFI because the CPU is a C interpereter (thats what the C means)

Hint: This is wrong.

>>922607

Which you can do with a compiled LISP all the same.

>>922605

Legitimately clueless I guess. Hint: the processor can actually run compiled C directly while it cannot run compiled LISP directly.

>>922584

You're entirely correct, as soon as I posted that I realised I was stretching too far with the kernel statement.

The crux of the matter is that Lisp is not at home in the Unix environment and forcing it to work like C doesn't make for a fair comparison. Especially considering that the size and complexity of a C program under this same environment is somewhat obfuscated by extensive system support at the most basic levels, including things like dynamic linking and syscalls.

>>922323

That's because UNIX doesn't have any Lisp libraries included. If you were using a non-UNIX OS and C programs had to bundle a UNIX environment and C library, C programs would be huge too, or if every Java program had to bundle a JVM or every Python program had to bundle a Python interpreter. If Lisp was the OS language, every program would be smaller because there would be less duplicate code, but this wouldn't only be true for Lisp. Most languages would need less code than C.

>>922333

This is the truth, and it gets even worse as time goes on. Memory allocation and error handling suck in C. Numbers, arrays, and strings suck in C too, and they can't be fixed because C programs depend on everything not working. They depend on all the array information disappearing besides the address of the first element when it's used as an argument. That's how all the C string functions "work." They depend on being able to truncate a string with '\0' and then put back another character and read the rest of the string. That's how strtok "works." Fixing C's strings and arrays would break the entire C library, POSIX, and all the C programs.

>>922584

>Think of it this way: I can make a tiny C plugin for another program whether that program is written in C, Python, or even LISP. But can I make a tiny LISP plugin for a program that isn't written in LISP? The kernel is irrelevant.

That's only true when the OS is written in C. C on the Lisp machines has special C data types to handle C bullshit like null-terminated strings and array decay. C can't use the standard string and array types, so it needs a Lisp FFI.

>>922593

>If everything else had a LISP FFI it would be the same situation.

UNIX weenies don't believe that even though they know it's true. Stockholm syndrome sufferers are like that.

Once one strips away the cryptology, the issue is control.
UNIX is an operating system that offers the promise of
ultimate user control (ie: no OS engineer's going to take
<feature> away from ME!), which was a good thing in its
infancy, less good now, where the idiom has caused huge
redundancies between software packages.  How many B*Tree
packages do we NEED?  I think that I learned factoring in
high school; and that certain file idioms are agreed to in
the industry as Good Ideas.  So why not support certain
common denominators in the OS?

Just because you CAN do something in user programs does not
mean it's a terribly good idea to enforce it as policy.  If
society ran the same way UNIX does, everyone who owned a car
would be forced to refine their own gasoline from barrels of
crude...

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.

>>922649

How do compilers work?

>>921189 (OP)

>we are incapable of writing a modern version and can only bitch all day.

I believe GuixSD + StumpWM + Emacs is the closest you can get today.

>>922872

>compilers magically add support for functionality that has to be managed by a virtual machine

>>922863

>If you were using a non-UNIX OS and C programs had to bundle a UNIX environment and C library, C programs would be huge too

>Most languages would need less code than C.

Wrong: you can still get tiny statically linked C binaries if you use musl as your libc and don't depend on bloated libraries like GTK+ or Qt. Don't confuse the failings of C with the failings of glibc and overengineered GUI libraries, it only makes you look stupid.

>>921757

makes you nut

>>921815

There is just no way this is right. That's just orders of magnitude off.

>>923107

Are you calling me a liar?

>>923112

Only a /pol/ would lie this hard.

>>923107

The last time we had a programming contest on /tech/ the LISP entry had a run time nearly 1,000 times slower than the C entry. IIRC it was about counting the second most frequent character in a string, if anyone still has that thread saved. Would be a shame if not as it was the last time there was programming on /tech/.

>>923129

/pol/ is notoriously always right you know.

>>923131

That doesn't sound legit for a compiled language. Even Perl will do much better.

Does Emacs count as (virtual) Lisp machine?

>>923161

Of course it does.

>>923147

What's 'compiled' in times of JITs, anyway?

>>923107

>There is just no way this is right. That's just orders of magnitude off.

Maybe he used bc to do the math.

Subject: bc Follies


The following was brought to my attention by VP.
Try using bc to calculate the value of 163/ln(163)

Here's a Sun4:

   titanic:~[13] bc -l
   163/l(163)
   32.0-75570-60420-20649243140-49

Here's a DecStation:

   hindenburg:~[1] bc -l
   163/l(163)
   32.0-85189980504841560572

(((lisp)))

>>925229

(((l(((((((i))(sp)))))))))

Ftfy

>>923026

there would have to be a runtime but that doesn't mean LISP isn't already compiled nor that it couldn't be actual machine-level bootloader code

http://www.loper-os.org/?p=300

>The GUI of my 4MHz Symbolics 3620 lisp machine is more responsive on average than that of my 3GHz office PC.

>The former boots (into a graphical everything-visible-and-modifiable programming environment, the most expressive ever created) faster than the latter boots into its syrupy imponade hell.

>And this is true in spite of an endless parade of engineering atrocities committed in the name of “speed.”

>>927536

But does it run far cry?

It's time for lisp fans to realize that lisp was never good.

>>923161

It counts as a bloated lisp machine

>>927536

>the loperos idiot doesn't understand that his 3GHz office pc is running multiple decades of garbage code

I guarantee if lisp machines had survived to the present day they'd be just as bloated. Everything was fast in the 90s, that doesn't mean anything.

>>927818

This. see >>923110

>>we need more than 30 million lines of code just to post on this website.

>We would need that much even if one of those other OSes became the mainstream. Notice that PDP-11 Unix isn't 30 million lines. Notice that from what I can tell, these meanies in the blockquotes are referring to quirks in the SunOS Unix or some other variant that existed at the time of writing (that right away should tell you how outdated the book is, when even the unices mentioned don't exist anymore).

>Notice that there is not a fully feature-complete lisp OS or Multics clone for today's world. You and the quote meanies are literally comparing things from several decades apart with wildly different feature sets.

>>927837

I don't know man, Quake and Doom ran beautifully under C. It's just the fault of incompetent programmers, not the language itself.

>>927536

>>And this is true in spite of an endless parade of engineering atrocities committed in the name of “speed.”

That's because C sucks. C weenies refuse to check for errors for "speed" but then they use slow null-terminated strings and array decay.

>>927818

>his 3GHz office pc is running multiple decades of garbage code

That's why it sucks. Lisp machine code quality is better. People don't have to reinvent wheels all the time because the code that comes with the OS is good. This is what allows the OS to stay smaller with more functionality.

https://en.wikipedia.org/wiki/Genera_(operating_system)

>Genera is written completely in Lisp (using Zeta Lisp and Symbolics Common Lisp)

>Even all the low-level system code is written in Lisp (device drivers, garbage collection, process scheduler, network stacks, etc.)

>The source code is more than a million lines of Lisp and available for the user to be inspected and changed. The source is relatively compact, compared to the provided functionality, due to extensive reuse

>I guarantee if lisp machines had survived to the present day they'd be just as bloated.

Even a full browser with JavaScript would be smaller on a Lisp machine.

>Everything was fast in the 90s, that doesn't mean anything.

Lisp machines were fast with GC and dynamic typing.

Date: Sun, 23 Dec 90 16:19:19 EST
Subject: Think how much faster and more efficiently this
   smaller program is able to trash the filesystem compared
   to a bloated AI-weenie one (which would all its time
   checking for uninitialised variables, doing bounds
   checking, allocating and freeing storage, actually caring
   about exceptional cases, signalling errors, etc.)

>>927854

>C weenies refuse to check for errors for "speed"

Proofs? Also that'd be a flaw of programmers, not of the language

>array decay.

doesn't affect performance

>Lisp machine code quality is better.

Proofs?

>People don't have to reinvent wheels all the time because the code that comes with the OS is good.

That's nice, but that's possible in almost any language, including C

>Lisp machines were fast with GC and dynamic typing.

Compared to what?

>>927854

since you seem to be a huge lisp fanboi, can you explain what Richard Stallman is talking about in these parts of his "How I do my computing" article?

>When you start a Lisp system, it enters a read-eval-print loop. Most other languages have nothing comparable to `read', nothing comparable to `eval', and nothing comparable to `print'. What gaping deficiencies!

>I skimmed documentation of Python after people told me it was fundamentally similar to Lisp. My conclusion is that that is not so. `read', `eval', and `print' are all missing in Python.

>>927854

> but then they use slow null-terminated strings

Remember guys you should store 8 extra bytes for every little string you want instead of just one byte!

>>927837

Conquests of the Longbow was a fun game. I played it on DOS, though.

>>927858

Not him, but it mainly stems from python's eval()'s deficiencies.

You can do read in python with: eval(input())

You can do eval in python with: eval()

You can do print in python with: print(repr())

I would say that doing print in python this way is close to how it works in a LISP. The other two are not because eval can only operate on an expression. A simple test to show how inferior it is, is to convert a python program into a string and then try to eval it. It will just complain about invalid syntax instead of actually evaluating it.

>>927854

>That's because C sucks. C weenies refuse to check for errors for "speed" but then they use slow null-terminated strings and array decay.

Isn't in this very thread a post saying how Lisp uses nil terminated strings and it simply got a reply of "and?" ( >>921872 >>921885 ). I don't know if this is Lisp implementation dependent, but I'm just saying how hypocritical some people are when they language of choice do something they consider bad in others.

>Lisp machine code quality is better.

Better compared to what? Basically, for ALL of your posts, you need QUANTITATIVE metrics, you're only providing qualitative, which are subjective.

>People don't have to reinvent wheels all the time because the code that comes with the OS is good. This is what allows the OS to stay smaller with more functionality.

Agreed, but such a concept is not exclusive to any OS whatsoever.

>Even a full browser with JavaScript would be smaller on a Lisp machine.

How do you know that? Have you implemented a web browser in a Genera Lisp Machine? It may be, or may be not, that depends on many factors, from the competency of the developers to the problem's complexity.

And now for the old quote:

Lisp machines were fast with GC and dynamic typing.
Date: Sun, 23 Dec 90 16:19:19 EST
Subject: Think how much faster and more efficiently this
   smaller program is able to trash the filesystem compared
   to a bloated AI-weenie one (which would all its time
   checking for uninitialised variables, doing bounds
   checking, allocating and freeing storage, actually caring
   about exceptional cases, signalling errors, etc.)

Imagine how slower and inefficiently a bloated AI-weenie program is able to trash the filesystem compared to a smaller and more efficient one? Because someone incompetent can fuck up in any language in the same way you can use axe to chop some wood or chop your own hand off.

In some languages you have way more freedom to produce something powerful at the cost of being capable of fucking everything up or you can have a hand-holding environment to protect you from yourself at the cost of being bloated. Both are valid approaches, one for implementing something well understood and the other for experimenting.

>>927855

>Proofs? Also that'd be a flaw of programmers, not of the language

Some languages check most errors automatically so you don't have to do as much work and some make it impossible, like overflow and array bounds checks in C. If someone made a magical C compiler that did check all these things, it would still suck.

>>array decay.

>doesn't affect performance

Bullshit. Array decay is one of the biggest problems with C. C compilers assume any pointer can be used as an array with pointer arithmetic, which is extremely slow. There are problems besides the slowness, like not being able to pass an array as an argument or treat it as a single object in any other way. Arrays on Lisp machines are objects like structures and classes and functions.

>>Lisp machine code quality is better.

>Proofs?

Lisp machines do more with less code and don't have UNIX bullshit like broken commands, panic, and OOM killers.

>That's nice, but that's possible in almost any language, including C

It's been tried with all those microkernels in the 90s, but they didn't work because they were written in C. UNIX weenies blamed everything but C, which gave microkernels a bad reputation.

>Compared to what?

Compared to hardware that doesn't have tags for GC and dynamic typing. Those computers were all much slower than today's computers, which are fast enough to emulate Windows in your browser. Lisp machines would be even faster today because of how many programs use a GC and dynamic typing compared to the 80s and 90s.

>>927860

>Remember guys you should store 8 extra bytes for every little string you want instead of just one byte!

Anyone who has enough strings that saving 7 bytes per string is worth it wouldn't want to be looking for all those null characters. Storing an 8 byte length more than makes up for all the problems null-terminated strings cause, and it's much faster too.

>>927879

>Isn't in this very thread a post saying how Lisp uses nil terminated strings and it simply got a reply of "and?" ( >>921872 >>921885 ).

Lisp does not use nil terminated strings, it uses arrays for strings, which means strings have all the power of Lisp arrays. It has nil terminated lists.

>How do you know that? Have you implemented a web browser in a Genera Lisp Machine?

No, but JavaScript on a Lisp machine wouldn't have to reinvent wheels since most of it is a bad implementation of what's already available in Lisp.

>Both are valid approaches, one for implementing something well understood and the other for experimenting.

UNIX weenies "experiment" but they very rarely fix anything. Changing =- to -= is the only one I can think of off hand. The UNIX file system would suck even if there were no bugs.

Mr. A is being hurt by a Unix bug, a bug accidentally
introduced into the file system code when Unix was first
written.

You see, a file is internally described by an inode entry,
which contains 13 pointers to the disk blocks that
constitute the file.  The first 10 of these pointers behave
normally, but a strange mutation occured in some code left
sitting overnight on a disk in a room where the air
conditioning had failed.  As a result of this mutation, the
eleventh pointer came to point, not to a block of the file,
but to a block containing a whole bunch more (like 256)
pointers.  Later on, replication of the erroneous code
fragment due to gamma ray damage made things even worse:
Now, the twelfth pointer points to a block of pointers to
blocks of pointers, and the thirteen to a pointer to blocks
of pointers to blocks of pointers to blocks of pointers (or
something like that).

A result of this bug was the cancerous growth in Unix file
sizes.  Remember that a cancer is uncontrolled growth, in
the wrong place at the wrong time.  In the intended scheme,
no file could be more than 13 blocks long, and most of Unix
was designed around that assumption.  The mutations
introduced the potential for growth way beyond this design
parameter.  Needless to say, nothing has worked quite right
since.  The X window system is probably the worst of example
of metastasized Unix code.  I think it's safe to say that no
piece of X would have managed to survive on a Unix system
with only the original 13 block pointers.

And what can you say about a language which is largely used
for processing strings (how much time does Unix spend
comparing characters to zero and adding one to pointers?)
but which has no string data type?  Can't decide if an array
is an aggregate or an address?  Doesn't know if strings are
constants or variables?  Allows them as initializers
sometimes but not others?

(I realize this does not really address the original topic,
but who really cares.  "There's nothing wrong with C as it
was originally designed" is a dangerously positive sweeping
statement to be found in a message posted to this list.)

>>927903

>pointer arithmetic

>slow

Do you think people actually believe your bullshit? Why don't you go back to MIT and pout with your loser academic buddies while real work is done by real men.

>>927905

Here we have another barely sapient C/C++ programmer using the word "real" - "real" programmers work on critical systems, so they'd be using Ada/SPARK if they have a brain.

>>927906

We sure know you don't program ada/spark, because how else would you have time to shitpost all day? no one programs in ada because it's unnecessary.

>>927909

>no one programs in ada because it's unnecessary.

Except for the fact it was mandated for a long time.

>>927506

>>927903

>Lisp does not use nil terminated strings, it uses arrays for strings, which means strings have all the power of Lisp arrays. It has nil terminated lists.

So that's a nil list at the end of the list, not an null terminator. My mistake then.

>No, but JavaScript on a Lisp machine wouldn't have to reinvent wheels since most of it is a bad implementation of what's already available in Lisp.

What reinventing the wheels means? This term is used a lot in programming but never actually defined. You mean with features out-of-the-box like how Python is capable of handling dictionaries and lists without third party libraries? And again, you just use qualitative comparison like "bad implementation", how is it bad? Does it takes 10 seconds to accomplish a task that takes 3 in another implementation? Does it crash with numbers larger than 4.295e+09? Give us something factual.

>UNIX weenies "experiment" but they very rarely fix anything. Changing =- to -= is the only one I can think of off hand.

Using UNIX weenies is just name calling, not an argument, like using "something around quotes" to signal an irony.

>The UNIX file system would suck even if there were no bugs.

How is it bad? What are the alternatives? I know that BeOS (Haiku) uses a database approach, have you tried it? Can you compare the two (Haiku's or anything else)?

>>927912

What does it mean when the law says

>where cost effective

Sounds like Ada isn't used if it costs too much. Uh oh.

It's almost as if the language isn't the problem but the programmer. Geez, I wonder why that is?

>>927918

In assembly an idiot will do a fucked up memory access every few lines with dangerous results (remote code execution etc). In javascript they can't if they tried (would have to escape the sandbox). Languages sure as hell matter. I hate web devs as much as everyone else but lets not pretend everything is just equal when it comes to errors.

>>927920

You make a lot of assumptions.

It must always be the fault of Ada!

http://www.adapower.com/index.php?Command=Class&ClassID=FAQ&CID=328

Stop drooling, you barely ambulatory (C)hildren. There's a reason why pretty much all of NATO adopted it too - it's the only language that satisfies the Steelman language requirements. Imagine wanting to program aircrafts and weapon systems with a footgun (and thinking we'd be better off for it). C programmers have zero sentience.

>>927926

>Stop drooling, you barely ambulatory (C)hildren.

Shit dude, you just burned me good. I better go get my burn cream.

>>927879

>>927927

>>927928

pt. 3 (This time I'm inserting some extra words so that 8chan doesn't squish my code tags into a single column so that you can easily read it without having to scroll back and forth from the start to the end)

The FLAG BIT,  in the case of a string array,  is 1 to indicate that
this string may be relied upon to contain only ordinary printing
characters.  Its use with other array types is not yet defined.
(THIS IS AN EFFICIENCY HACK, WHICH IS CURRENTLY IGNORED).

  The %%ARRAY-NAMED-STRUCTURE-FLAG is 1 to indicate that this
array is an instance of a NAMED-STRUCTURE (probably defined with DEFSTRUCT with
the NAMED-STRUCTURE option, etc).  The structure name is found in array leader
element 1 if %%ARRAY-LEADER-BIT is set,  otherwise array element 0.
  Named structures may be viewed as implementing a sort of user defined
data typing facility.  Certain system primitives, if handed a NAMED-STRUCTURE,
will obtain the name and obtain from that function to apply, ACTOR like,
to perform the primitive.  One can see that there is some potential

        The only one of these fields which has not yet been mentioned is the ARRAY TYPE field.  The options are:

        NUMBER  TYPE            USE
        ======  ====            ===
           0    ART-ERROR       This is always an error,  to prevent randomness.
           1    ART-1B          Each element is one bit,  and 32 are stored per word.
           2    ART-2B          Analogous.
           3    ART-4B          Analogous.
           4    ART-8B          Analogous.
           5    ART-16B         Analogous.
           6    ART-32B         Analogous.  Since FIXNUM datatype is supplied
                                24 bits of data are retrievable.
           7    ART-Q           Each element is a Q,  that is,  it has a datatype and
                                a pointer field.
           8    ART-Q-LIST      Same as Q,  but the elements also form a list.
                                By using GET-LIST-POINTER-INTO-ARRAY and G-L-P
                                you can get pointers into the beginning or even
                                the middle of such an array.
           9    ART-STRING      This is stored the same way as an 8 BIT array.
          10.   ART-STACK-GROUP-HEAD (see STACK GROUP FORMATS)
          11.   ART-PDL-SEGMENT (see STACk GROUP FORMATS)
          12.   ART-TVB         TV Buffer
          13.   ART-TVB-PIXELS  TV Buffer in pixel mode.

Note: the elements of arrays (those which are smaller than 32 bits) are
stored right-to-left (i.e.,  the first element of a 4 BIT ARRAY would be
stored right-justified,  including the lest significant bit).

However,  TV buffer arrays (ART-TVB) are DIFFERENT,  for hardware reasons.
Only the bottom 16 bits of each word are used and the bits are stored
left to right.

TV-BUFFER-PIXEL arrays have a plane mask in array leader element 0.  1 bits
in the plane mask correspond to active tv-buffer planes, 0 bits to inactive
planes.  Each time a active plane is encountered on a store, the low order
bit is stored in that plane (a la ART-TVB), and the remaining bits shifted
right one.

        STRING arrays are stored the same way as Q-ARRAYs,  and STACK-GROUP-HEAD
and STACK-SEGMENT arrays are stored the same as Q-ARRAYs are.  The reason for
supporting both array types is so that programs can easily tell apart those
8-bit arrays used for strings,  etc.  Strings,  although like 8-BIT arrays at low levels,
are treated differently at higher levels,  such as by READ,  EVAL,  and PRINT.

>>927929

Do tell me why NATO used Ada for their projects and not your "real man's" language.

>>927931

>implying I care

>>921453

MIT is publicly funded, all their code should be copyright free. Don't even get me started on the fact Unix should be too since they agreed to make their tech public in return for their government protected monopoly.

>>927942

Why is it Ada's fault when there's an engine malfunction? Is Ada supposed to magically fix the engine or something?

>>927854

>lisp machines were fast with GC and dynamic typing

LuaJIT my dude

>>927903

>no oom killers

nice so they just crash? much better option I agree

>entire filesystem thing

ok so you admit you are a retard? also X isn't unix nice try

Define PCLSRing for me right now without changing tabs or never post again

>>927940

>MIT is publicly funded, all their code should be copyright free.

What lol? They did not write the symbolics code, they paid symbolics to use it. InB4 universities paying for anything proprietary should be illegal.

>>927944

Scheme R6RS has engines that work pretty well.

>>927946

>nice so they just crash?

When your memory is getting really full it will tell you that you that you are running out of memory and that you should turn the gc on / invoke the gc. If you ignore this, then it will warn you again at the last possible moment that you should run the GC. If you do run out of memory you won't crash, but the debugger will come up allowing you to recover from it. If the debugger crashes from running out of memory it will cause another debugger to be started for that error. After 25 times it will pop up the emergency debugger which does not allocate any memory at all.

Anyways, from the debugger you can save the system or just reboot the machine.

>>927944

It crashed due to control surface failure.

>>927972

https://archive.fo/wU9oi

Says it was from:

>The ill-fated Draken is understood to have been written off in a crash caused by a catastrophic failure of its single Volvo Flygmotor RM 6C afterburning turbojet engine.

>>927940

>MIT is publicly funded, all their code should be copyright free.

MIT is a private university.

>>927849

That's not a very good example, since tons of people had to buy entirely new computers to play those games.

>>928073

>doom

>entirely new computer

Wrong. People were playing that game just fine with 386. Quake was engineered to use 3d accelerated video cards, one of the first games to do so, so of course people would have to get new hardware to be able to use software that was designed for new hardware.

>>928076

Dude, I played Doom on a 386DX/33 and it was fucking sloooooow even in the "graphic detail" option set to low, and somewhat reduced screen size. It was someone else's computer, and I was shocked at how much worse it played than my 486DX/33, which itself had problems with slowdown in Doom II.

And Quake wasn't designed for 3D cards, it was designed to run well on regular VGA cards, which is how most people ran it in 1996. You needed a Pentium, and that's it. A 486DX4/120 could sorta play it (badly, like a 386 could play Doom) but it wasn't fun that way. I've seen it in person, just like the 386 and Doom. Used to play lots of games over modem and LAN those days with other peeps.

>>928089

>Being this old and still posting on an image board

>>928091

> Hurr durr, go post on facebook since you're old.

Next thread:

> Hurr durr all those old farts only post on facebook.

>>928095

Whats your point both those things are true.

>>928101

Hello /g/.

>>928089

>Throughout the company's tenure, Rendition managed to get a leg up on the competition by working with John Carmack to develop the first 3D-accelerated version of Quake

> A year prior, Carmack stated "Verite will be the premier platform for Quake."

>https://www.pcgamer.com/from-voodoo-to-geforce-the-awesome-history-of-3d-graphics/

Carmack was always big on adopting 3d accelerated cards and open platforms.

I played doom plenty on 386 on school lan. it was fine. shit, doom was fine 68k macs.

>>927903

>>>array decay.

>>doesn't affect performance

>Bullshit. Array decay is one of the biggest problems with C. C compilers assume any pointer can be used as an array with pointer arithmetic, which is extremely slow.

Show proofs for pointer arithmetic being slow.

>There are problems besides the slowness, like not being able to pass an array as an argument or treat it as a single object in any other way.

But you can pass arrays as arguments.

>Lisp machines do more with less code

Proofs?

>and don't have UNIX bullshit like broken commands

Such as? Is this something that can't be fixed?

>panic

Haven't seen one in years.

>and OOM killers.

Every Unix handles OOM differently, so this is not a valid argument. Some have OOM killers, some don't.

>It's been tried with all those microkernels in the 90s, but they didn't work because they were written in C.

Show proofs.

>Compared to hardware that doesn't have tags for GC and dynamic typing. Those computers were all much slower than today's computers, which are fast enough to emulate Windows in your browser. Lisp machines would be even faster today because of how many programs use a GC and dynamic typing compared to the 80s and 90s.

Come on, show benchmarks.

>>927966

>When your memory is getting really full it will tell you that you that you are running out of memory

Just like malloc.

>Debugger to recover OOM processes

Can be implemented on Unix similarly. I wonder why this concept wasn't successful.