[ / / / / / / / / / / / / / ] [ dir / arepa / fa / feet / hkpol / leftpol / sonyeon / vg / vichan ]

/tech/ - Technology

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.931503

>>931297

get on irc, fag. I want to know if you've abandoned your memlang yet.


 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

File: f84436e5178a182⋯.jpg (29.28 KB, 368x535, 368:535, 1523040788433.jpg)

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

File: 674c1928efc7b8f⋯.webm (3.35 MB, 638x360, 319:180, kizuna_terminator.webm)

>>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

File: 820a36a5d3c12fe⋯.jpg (55.23 KB, 640x661, 640:661, kizuna-ai.jpg)

>>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

File: 6fa44482233cc27⋯.png (262.43 KB, 530x544, 265:272, ai broke it.png)

>>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

File: 456fd6ff7c5b855⋯.jpg (88.69 KB, 983x834, 983:834, smugAI.jpg)

>>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

File: 2c6af7c5ea56f7b⋯.jpg (53.31 KB, 842x699, 842:699, 2c6af7c5ea56f7bcbf2615a333….jpg)

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




[Return][Go to top][Catalog][Nerve Center][Cancer][Post a Reply]
Delete Post [ ]
[]
[ / / / / / / / / / / / / / ] [ dir / arepa / fa / feet / hkpol / leftpol / sonyeon / vg / vichan ]