machine
Images are sometimes not shown due to bandwidth/network limitations. Refreshing the page usually helps.
You are currently reading a thread in /g/ - Technology
You are currently reading a thread in /g/ - Technology
Would /g/ use a LISP machine on today's hardware, if it were reimplemented opportunely?
>>53555084
How would one use a lisp machine on today's hardware when lisp machine is just a specialized hardware with a CL-based OS on top to take advantage of it?
>>53555204
well, several companies produced native java processors... Also, it would be also feasible in a way similar to android: a VM ontop of some kernel, such as linux or a bsd one, or whatever
>>53555268
So SBCL and just about every other CL repl?
We already have these today.
You're not going to find anyone wanting a native cheap that can understand CL code. It's expensive and slow and why RISC won ultimately.
If you want a Lisp OS then you can still play with symbolics OS but there's no point . SBCL is a better approach and you can run it on any major OS today.
>>53555084
post moar qts with guns
>2016
>there are still people who don't use StumpWM and Emacs as their OS for their lisp machine
>shiggy diggy
Linux or BSD are just the drivers between the hardware and emacs
>>53555314
what I ultimately dream about is using CL as scripting language everywhere in the system. Like, wanna automate a process (like with bash script)? CL! wanna edit some obscure config file? CL!
Why? Because CL is a lot easier and more pleasant interface between a programmer and the computer. It's more readable, and it's closer to human logic than shit like unix shell.
For example, - the parentheses in bash shell have no syntactic value - they're part of semantics (like, a logical construct); it's like invoking a function. Try not putting a space between an open square bracket and the condition, see what happens...
Already do.
>>53555364
I actually wanna learn emacs. I already know vim, but it takes time to become really proficient in it. Also, the keyboards we use now, in 2016 are not made to be used by people with hands. I'm not even typing that much, and I'm already starting to feel pain in my wrists. Touchtyping ~80-100wpm various syntax excluded
>>53555445
who dat?
>>53555364
I use Emacs, but is StumpWM worth it if i3 basically gets the job done for me with minimal customization?
>>53555463
Could always try Emacs+Evil or Spacemacs.
>>53555084
But how would I use hardware on hardware? I don't get it.
>>53555314
The only reason RISC won is that bell labs were big back then. You know what's expensive and slow? RISC processors.
>>53555609
spacemacs (aka buggy outdated emacs + evil combination) is dogshit. Evil, while claiming to have all of vim's features, really doesn't even have 1%. Vim will never be equaled at this rate, let alone outdone. Emacs is a joke "b-but muh concurrency" is literally no better than vim's sequential model because in both cases a misbehaving plugin WILL lock everything up. Except since vim is sequential, you can always kill the plugin by C-c whereas there is no such option for emacs.
>>53555609
considering that I am currently learning clojure, I really should.
>>53555364
how is StumpWM? I'm using i3 too, but never tried that one
>>53555639
I'm not speaking about that; I dream about a computer with an OS written completely in LISP. Well, at least in a VM with CL shell.
It could be interesting, if you go all the way. And by that I mean, taking care of the bedrock layer, like he talks about here:
http://www.loper-os.org/?p=55
Also (http://www.loper-os.org/?p=69):
> You never understood LISP. Not in the slightest. The principal thing that makes LISP what it is has NEVER been replicated. Anywhere. Not even in Scheme or the disgusting pile of shit that is Clojure. It’s not macros, it’s not GC, it’s not syntax. It’s the philosophy of the language and the environment. The fact that every error is recoverable from. That any process can be paused, inspected, it’s functions modified and rerun with new definitions. That the operator is wholly in control of the machine. That productivity, understandability and inspectability is the top priority, at all times, no such idiocies such as “debug vs. release builds”.
>>53555698
nonsense.
>Emacs for strength.
>>53555719
>http://www.loper-os.org/?p=69
It is Godspeak you are quoting.
>>53555445
Barack Obama, president of Australia
>>53555364
Too bad cl and elisp are the worst lisps.
>>53555463
>I'm already starting to feel pain in my wrists.
1) stop using small keyboards and shitty trackpads
2) Don't ever use 'palm rests' on anything ever
My netbook wrecked my left wrist because of these things
>>53555463
Buy yourself a good ergonomic keyboard. I got a Kinesis Classic, back around 1999 when I started having problems with tendonitis. Apart from the old style IBM Thinkpad laptop keyboards, it's the only one I can stand.
I only ever use vi for editing though, too much of that holding down several keys at once business would probably cause problems for me in the long run. That's why I avoided Emacs... The modal editing in vi seems less stressful overall.
>>53555840
14" dell latitude e6440 here, not that small i'd say. Also, no palmrests. My major issue are those bunch of fucking symbols and modifiers all under the pinkie, - they hurt to press, other than slow me down...
>>53555708
OCaml would be significantly better desu senpai. Although lisp has its own unique advantages. OCaml is the implementation language of the most popular unikernel, so it's at least viable.
>>53555719
>The fact that every error is recoverable from. That any process can be paused, inspected, it’s functions modified and rerun with new definitions.
... except this works better with scheme than anywhere else.
>>53555797
Also this.
https://github.com/froggey/Mezzano/releases/tag/demo2
>>53555698
Except in VIm your interface locks up no matter what during batch processing.
>>53555855
an ergodox is coming to my home next month, hoping it's gonna justify its absurd price.
>>53555879
that's why neovim is being worked on
>>53555877
metaprogramming, bitchez. No existing programming language beats lisp in it
>>53555879
True, but how often do you want to be doing something during that time? Keep in mind that it's not going to take long to complete anyway - typing 3 extra characters isn't going to change your workflow efficiency (especially when vim's control mode is so superior to emacs).
Anyway, the worst fanbase are the neovim tards.
>neovim is already a full replacement for vim, p-please believe us!
>it's a broken unusable mess and wouldn't be usable for the next 2 decades at this rate, let alone feature-par
>>53555877
They made Lisp machines, but did they make Scheme machines?
>>53555872
Swap capslock and control.
In general I avoid laptop keyboards no matter what application I'm using for text editing
>>53555797
Elisp sure, but what's wrong with CL?
>>53555084
No because Lisp is disgusting.
I would use a Forth system though (processor designed for Forth with optimized stack engine, auto cached stack top in registers, etc)
>>53555938
it's not even about the ctrl. It's about these motherfuckers:
<>,.?/"{}[]\|+=_-()
fuck whoever thought it would be a good idea placing EVERYTHING there.
>>53555983
why do you think lisp is disgusting?
>>53555797
>Too bad cl and elisp are the worst lisps.
>>53555877
>... except this works better with scheme than anywhere else.
Which scheme?
Do any schemes even have comparable condition systems to what is mandated in the CL standard?
Don't get me wrong, I like scheme quite a bit, but this is nonsense.
>>53555906
OCaml's ppx is equivalent to lisp macros. The advantage still goes to lisp because of the syntax regularity and simplicity, but it's close enough that nobody cares.
On the other hand, the solid static typing system and debugging capabilities will never be matched by a lisp.
However, lisp's hot-reload capabilities are in-built whereas they require a special setup for ocaml (although it's still possible, the kernel would have to dynamically load components at runtime, and these components would have to dynamically load subcomponents, etc; allowing recompiling and reloading) - but the advantage is that ocaml's recompiled unit will be almost as fast as the original whereas a recompiled unit in lisp is interpreted and slow.
A solid typing system (more solid than OCaml's even) is a massive boon to development. Combined with solid inference, it doesn't get in the way at all even when scripting.
>>53555797
>>53556031
what's with CL and elisp being the worst?
>>53555972
LispNs offer first-class functions in the same way that C does, for example. Basically, doing any kind of functional programming in CL becomes ugly, bulky and unreadable extremely fast, while at the same time, the inherent lispy syntax isn't well suited to imperative programming and causes some amount of undue bulk.
>>53555084
I'd rather use special purpose deep learning hardware to make the computer execute what I tell it in natural language.
>>53556031
>Do any schemes even have comparable condition systems to what is mandated in the CL standard?
I don't know of a scheme that doesn't. If you mean at the top-level (wow, who cares), chicken and guile both prop you into a new debug environment, and most schemes which don't do that automatically have an option to do so.
>>53556062
It isn't
The only shitty lisps are the ones that are dynamic by default and have no TCO
Emacs is actually addressing this as a problem, unlike another lisp we could name.
>>53556138
>The only shitty lisps are the ones that are dynamic by default
So, common lisp?
>>53556079
>LispNs offer first-class functions in the same way that C does
having to #' a symbol isn't the same as only having function pointers.
The LispN, as you call it, was a concession to enable cleaner metaprogramming with existing technologies, and it worked.
>>53556198
Oh look, a retard.
>>53556079
I can see what you mean about the functional side (though I'd say it's still a lot more pleasant than in C), but I don't get what bulk there is in the imperative side outside of the optional loop macro.
>>53556225
I laughed.
>>53556113
>I don't know of a scheme that doesn't.
As in, user-defined error-handling procedures (not just "hurr (+ 1 "a") => CANT ADD STRINGS, DIPSHIT. what do?")
Again, this seems like the sort of thing you end up getting nailed to one-and-only-one implementation if you decide to use it, or putting in double effort for every implementation you decide to support.
>>53556244
In imperative programming, you want to perform sequential bindings, sometimes interspersed with operations that may modify values and return nothing. Compare(let ((x (box 3)))
(do-it x)
(let ((y (box 7)))
(do-it y)
(do-it-again y)
(do-these x y))
or(let* ((x (box 3))
(nothing1 (do-it x))
(y (box 7))
(nothing2 (do-it y))
(nothing3 (do-it-again y))
(nothing4 (do-these x y)))
nil)
With something simple likelet x = 3;
do-it(x);
let y = 7;
do-it(y);
do-it-again(y);
do-these(x, y);
Especially if y depends on a state of x.
>>53556387
>With something simple like
Just mutate in place then.
What's the problem?
It's disgusting and you're a heretic, but you can do it exactly the same.
>>53556321
It is mandated in the standard that scheme implementations allow modifying a running image at runtime. Unlike in CL, there is no mechanism, beside renaming or syntax-context expansion, which allows capturing the present state of a function, so unless the person really didn't want to capture the function currently in scope instead of the function in the scope at definition time, reloading will work as planned. As such, it works slightly better than in CL.
Whether or not an error sends you to an ad-hoc environment depends on the implementation. MIT scheme, gambit, guile and chicken, among others, all do it. However, since scheme implementations are very sharded "on purpose", it makes no sense NOT to rely on a specific implementation's mechanisms. It is virtually impossible to write cross-implementation portable scheme code in the first place without doing manual adjustments for each targeted scheme. There are projects that try to address that but they're mostly abandoned (including r7rs-large).
r5rs (probably earlier) already requires scheme implementations to support unwind-protect, call/cc, error, and handle-based erroring mechanisms.
>>53556610
The problem is that let-expressions have explicit scope extent, which significantly increase verbosity. The examples I gave ARE in-place mutations, it's how you have to write them in the presence of bindings that's the issue.
The true heretics, ultimately, are CLfags for encouraging this style of programming so strongly by making functional programming cumbersome, and yet not providing appropriate primitives for it.
>>53555425
You already can. Sbcl has a script parameter to do this.
>>53555657
Guess what your using right now? A cpu that's RISC at its core.
>>53557032
Yes, and compared to the performance we'd get if good CPUs had been developed instead, they're fucking dogshit.
>>53555609
>I use Emacs, but is StumpWM worth it if i3 basically gets the job done for me with minimal customization?
then keep i3, if you aren't looking for a replancement then don't change.
>>53555314
a lisp machine is more than an operating system. it's an architecture, not dissimilar to the way the Actor model was proposed as a computational derivative from von-neuman architecture
>>53556079
Lisp never was and never will be about functional programming.
Lisp is a symbolic programming language.
>>53557166
Lisp was a multi-paradigm language. However, common lisp is an anti-paradigm language. That's a bad thing.
>>53557096
Any good info on alternative CPU architectures?
Like those of Burroughs mainframes, to give you an example.
>>53557194
lisp is about manipulating expression symbolically, nothing more.
>>53557194
Are you just spewing words that have no meaning now? CL is by definition multi-paradigm.
>>53557194
How is CL's imperative programming worse than traditional LISP's, though?
No, I just want a MIPS Warrior server. Probably going to save up and get that POWER8 workstation motherboard that's coming out
>>53557232
It includes the option for imperative programming; thus, making it worse.
>>53557260
>muh functional
/g/ is like a live version of c2.com
>>53557232
It's not, but lisp1's do not have the awkwardness CL has for functional programming, and CL has lots of imperative primitives. Imperative programming is also surprisingly popular with CL compared to with other lisps.
>>53557304
>MUH FUNCTIONAL
give it up already man.
>>53557032
Have anyone ever done it before? Like, taking sbcl, setting it as login shell, loading global vars in it and using it normally, like a shell? to execute commands, navigate between folders, etc?
> binary API
> firefux + webm support
> mongolian pictureshow codecs
port that to genera and then i'll care
>>53557388
You completely could write a CL-shell, i'm sure some autist out there has done it.
Whether it's worth it or not, idk.
>>53557421
will look into it someday; could even try to write one, if it's never been done before. I'm pretty sure that it could be useful, if anything, - to the emacs neckbeards, who use nothing but lisp all day erry day.
>>53557455
http://www.cliki.net/Lisp%20as%20a%20shell
>>53555480
Jeremy Corbyn.
>>53557407
Genera doesn't even run on hardware, it's just a VM. There is no real Lisp machine for a long time.
>>53557388
scsh is more appropriate.
>>53556725
Don't use Let then.(defvar *x* 3)
(defvar *y* 7)
(do-it *x*)
(do-it *y*)
(do-it-again *y*)
(do-these *x* *y*)
FFS, THINK!
>The true heretics, ultimately, are CLfags for encouraging this style of programming so strongly by making functional programming cumbersome,
I find FP reasonably comfortable in CL, though it is not quite as clean as in Scheme.
I'm still not comfortable with OOP (everything feels like I'm overengineering), but procedural and FP are pretty straight forward as far as I'm concerned.
>and yet not providing appropriate primitives for it.
What?
I like scheme, but almost ironically, I find using it much more cumbersome, be it the tooling, libraries, or just the general spartan nature of the language implementations.
Maybe R7RS-Large will change that, if anybody bothers implementing it.
>>53558849
>global state
Are you serious right now? Am I being kidded?
>>53555084
>if it were reimplemented opportunely
actually laughed out loud
>>53558849
try racket while you don't have R7RS-Large
>>53558970
Too bad TR is basically unusable.
>>53555983
GreenArrays has what you need anon...
>>53558920
I'm not sure what you want(let ((x 3) (y 7))
(declare (dynamic-extent x y))
(do-it x)
(do-it y)
(do-it-again y)
(do-these x y))
Explain what your contrived example relates to.
>>53561033
CLfags everybody!
>>53561165
>I want to modify variables from outside their scope IT'S HARD
>What do you mean use global binding?
what do you even want?
Your example doesn't look like it would be useful by itself; I'm asking for some context because you sound like a schizophrenic.
>>53561248
Oh, you're not a CLfag, you're just inbred. OK then, carry on.
>>53561300
Oh, you're just shitposting. Thanks for providing a worktime distraction anyway.
https://github.com/froggey/Mezzano/releases/tag/demo2
A Lisp HV/OS/Compiler targeting x86_64 written in pure Common Lisp with a GUI.
Comes with an editor, debugger, Swank server/SLIME, telnet client, file manager, memory inspector, and IRC Client
>>53557388
>>53557421
It's called avesh
>>53555084
You sort of can by implementing a Forth OS and then building the lisp vocabulary on top of it, since both are cell based its kinda easy.
And you would have the best of both worlds Forth is the Lisp of low level interaction.
Am actually going to try it, the problem is doing VGA and that stuff which I dont know jack.
>>53559001
Chuck Moore is G-d
