/prog/rider's secret society

We should create a club/lodge for programmers. If stonemasons created one many years ago just because they knew how to carve stupid stones and build some basic structures, why we still don't have one?
This is what we need:
◦ A symbol.
◦ A secret handshake.
◦ A set of rules.
◦ An unknown leader.
◦ An unknown sub-leader.
◦ A library with exceptional computer books, a printed version of world4ch's /prog/ (aka The Old Testament), ancient computers, and other relics.
◦ A list of heretic languages carved in stone.

>>40
Modularizing each part of a Operating System in simple programs that can interact using standards IPCs seems pretty much KISS, or at least that's what I though until now...

But please, go on and delight us with your knowledge about Genera and Smalltalk.

_{btw, ``we conjure the spirits of the computer with our spells'' should be, without any doubt, our moto.}

>>29
Awesome, thanks. Do you think there's room for something that hackerspace-types would use?

>>40,41 et al
You will be stronger united.

all

I'm going to create separate threads for projects and founding ideology. I think these should be separate.

>>41
I would delight you, but I do not know where to begin.

In a Lisp system there's no ``programs'' as a UNIX user might think of them. There's just symbols and the Lisp objects they name. What's called a program in Lisp is called a function or subroutine in other languages and systems; but in Lisp a procedure isn't program text, (although you can say it can be represented by text). Imagine you could type in a C ``function'' in your UNIX shell, and it would automatically be compiled, and then you could refer to it by name and call it, and that every ``program'' you ran was like this. So programs don't pass text around to eachother, they just call eachother with the arguments they expect. One program can call the programs used by another program, larger programs are built out of combining more primitive ones.

Smalltalk systems also don't have the same notion of programs UNIX does. Just objects. Objects send each other messages, and this is how everything works. Some objects define how other objects answer messages, and can create new objects of the same kind; these objects are classes. For example, in Smalltalk integers are objects, and they answer the message + anInteger by performing a machine (or primitive) instruction. This isn't very interesting, but then you have objects such as SystemBrowser, the system browser class, which can create new instances of SystemBrowser, which is an object which knows or creates other objects and sends them messages, but otherwise encapsulates a graphical interface to a typical Smalltalk system.

As you can see, I am having a lot of trouble explaining this, because it is a difficult and stupid thing to have to explain. If you are genuinely interested, then it would probably be instructive for you to download SBCL or Pharo and have a play and see what it is like. Then remember that once upon a time your whole computer was like that, from the ISA up. Then become unhappy with computers for the rest of your days.

>>44
I must admit that what you are describing sounds beautiful, though, I can't imagine how it would work in the practice. mm I also feel a bit confused about your post in general: it seems that you are talking about CL compilers or maybe interpreters/repl?

>>45
A REPL is one particular Lisp program, and the traditional way of interacting with a Lisp system. It's possible to interact with Lisp systems in many other ways. It is entirely possible to have a REPL-less Lisp. However, due to Lisp programmer's fondness for REPLs, most Lisp systems do have a REPL, and other means of interaction, including mouse interaction, follow a REPL like ``protocol''.

The E in REPL stands for evaluate, and it's the step after R for read.

Evaluation may be by interpertation, or by compilation depending on the Lisp system, and your settings.

Now, the land of Lisp is vast. It's an entirely alternate universe with regards to personal computing. A good path for a beginner might be to read Practical Common Lisp and write a lot of Common Lisp programs, on your favorite UNIX or VMS clone. Later, you might try pirating or buying Open Genera, getting it working in an emulator or real Lisp machine, and seeing how it all works. However that is not a good first step, IMHO. It's best to understand how a more mundane Lisp system works and its advantages and disadvantages, before going back in time to see one approach to Lisp as an operating system.

For example, if you were to watch videos of Symbolics Genera now you probably wouldn't think it is that impressive. That's because you fail to realize things a Lisp programmer knows, that e.g. you can select any peice of text, graphic, widget etc. and then ``debug'' the object that thing represents, at run time. You might not know that there is always a way to jump to the source of the object that thing represents, modify it and recompile it and see the changes immediately etc. etc. But these luxuries you will grow to love and expect when you program in today's Lisp systems, because they are available (but not ubiquitous).

So I think learning e.g. SBCL or Allegro Common Lisp and the surrounding development tools and libraries is your best option for really getting the significance of a Lisp OS, because then when you hear Lisp OS you won't have to see examples or anything you'll just think ``Oh my gosh! of course, I wish everything was like my Lisp''

Smalltalk on the other hand you can almost use as an operating system today (but it won't be on the bare metal like it once was), and of course it won't run your favorite applications. Just download Pharo, make it full screen and start exploring, there's two quite good free tutorial books on the Pharo system.

There are many similarities between a Smalltalk system (in the Smalltalk-80 -> Squeak -> Pharo tradition) and an Lisp sytem, especially an Interlisp system.

In other ways, Lisp systems were behind UNIX. For example, a Lisp system doesn't have any concept of ownership, so even if you can have multiple users interacting with the same machine, they can step on eachother's toes. However, most Lisp programmers will tell you that the UNIX approach to ownership is wrong, and that a hardware enforced cryptographic capabilities approach is better, and this is true. My hunch is that a hypervisor giving everyone a virtualized view of a portion of the computational resources is the best approach, and then everyone has their own personal Lisp system on top of that, but I have not given this serious thought.

>>44
The idea is that the interpreter/compiler is the shell and fundamentally forms the operating system itself. In unix programs were meant to be compiled to machine code, read and write from their stdout,stderr,stdin, open files, and use system calls to request other misc services from the operating systems. Then shell scripts can call these programs, redirect their outputs into each other and things like that. In a lisp system, all services provided by the operating system are invoked though lisp. Programs are subroutines written in lisp. There are other projects with the aim of creating an operating system in this sort of language, and one advantage is that since it's garbage collection, it is not possible (or should not be possible) to refer to memory that was not provided to the program for use. So there doesn't need to be a hardware solution to keeping memory allocated to a process private to that process. But these languages are currently slower than languages like C and hand coded asm. Also in order to communicate with the underlying architecture, there needs to be some asm at some point.

>>46
unix style permissions are sufficient as long as it's acceptable for physical access to the machine to compromise the system. Otherwise encrypting each user's home directory with a key provided by the user will preserve privacy in the face of physical access when the user is not active. However the super user can still know the key of the user when the user creates their account, and the one with physical access to the machine can still discover the key when the user logs in or is active. The old unix system was based around the model of multiple users logging into a possibly remote machine, and in this case encryption doesn't help very much for personal use, since you don't physically own the machine.

In response to the starting of a pseudo-anonymous firm of some sort that is capable of making money, I wouldn't join this firm. I divide my free time between things not related to programming, things I program for fun, and things I program because I have some desire for the end product to be complete. There may or may not be people that would be willing to pay me for the product. But given the nature of the product there are also probably people (probably not in my country, but you never know) that would like to prosecute me for developing this product. So I prefer to keep a lower profile, and just make it, drop it somewhere, and hope someone who finds it might use it.

>>47
You can have a REPL-less Lisp system.

The REPL is not what defines a Lisp system, and it is certainly not what defines a Lisp operating system.

A Lisp system can have no text at all. The syntax of Lisp is defined as a syntax on Lisp objects, not on text. A different (i.e. non textual) representation of objects is possible, and this was done on Genera; the scheme was later standardized into CLIM (note text is still used, but some objects are not text).

I can imagine a Lisp system where I write my programs by arranging squares and triangles.

A skin deep similar system (i.e. just the conclusion) is the Mathematica notebook today.

Home directories, users, files, and so on are UNIX concepts. There have been fileless Lisp systems (e.g. Interlisp). In a fileless system, UNIX concepts of ownership make no sense; capabilities are a better fit.

Smalltalk systems are fileless to this day (with notable exceptions).

Think about what files are... they're utterly stupid are they not?

Lisp compiles to pretty fast machine code these days. You can inline assembly and disassemble programs trivially. If you make the Lisp look like C then it's usually a bit slower or a bit faster than the corresponding C. There's room for improvement. I'd like to see more JIT approaches with regards to dynamic uses.

>>49
That was beautiful.

To some extent this is done with files. A file is an encoding of some arbitrary thing, where the arbitrary thing is realized once a specific program is used to load it and present it in some way. A lisp data structure is some sort of tree of arbitrary objects, and not that different from a file system with various files stored in various encodings. The file system is clunky, restrictive, and not approachable to the typical user. But it's layout is standardized. I can always move one file from one location to another. My file system checker knows how to check for errors in the file system. My programs all know how to interact with the file system using a basic interface.

In a lisp system, the file system doesn't need to exist. The objects that are normally dormant sitting in encoded files are alive and ingrained in the image of your lisp system. They pass between ram and persistent memory fluidly on a need basis. Perhaps the lisp system uses a transaction system for checking out and committing objects. I was planning on finding a few disadvantages to using this, but now I can't. Perhaps the only reason this isn't the standard today is that the current system is good enough, and if we want something like the lisp system, it can be layered on top of the current standard as a user process that stores its image in a file.

>>50
The difference between objects and files is that the interface to a file is a stream of characters, and the interface to an object is a dictionary (i.e. set of procedures) over that object. A file can be an image, or a geometric description, or a document and your interface to that file is still getchar, and not something more appropriate. You can later paper over it in some way, but that's the fundamental interface a file system provides. Compare this to the hypothetical transparently persistent object store you mentioned (which would be the equivalent of a file system).

Some operating systems (e.g. Amiga OS and BeOS) papered over files very well with ``datatypes'' as part of the services the OS. This is one step up from the usual UNIX nonsense, but it sits on top of a layer that was the wrong abstraction in the first place (files), so this is not very good (hence why I said ``papering over'').

>>51

With procedures being associated with the file at the operating system level, the basic operations associated with the file are handled by the operating system. Whereas if the file is only seen as a sequences of bytes by the operating system, the basic operations associated with the file are pushed into the application level. I can see an efficiency gain if the operating system hosts the services. Each application needs to load a library in order to operate on a file. If two applications are using the same file, they can't be aware that they are using the same information and share it. But if this was done at the operating system level, it could see that two processes requested the same service of the same file, so they could both read from the same cache.

If an image viewer and a printing application were to both request the raster scan interface of a jpeg file, the operating system could load the data of the file from however it is stored, decode the image into a region of memory, and provide this region of memory read only to both processes. The computer decodes the image once. If this was done at the application level, the printing application and the image viewer would both load the same jpeg library, both decode the image so they each have their own raster representation of it, and then they can both use their own copy. The image is loaded twice using the unix way.

If you wanted to shoe horn this feature into unix, the usual was is to create a daemon that sits and waits for processes to request certain operations on some file. The daemon loads the file and provides an interface or some result to the querying process.

>>52
Your analysis pretty good.

A ``datatypes'' service for UNIX clones would be welcome by me, but it's against the UNIX way: The daemon (or library or whatever) would have to provide a pretty darn good (and ideally polymorphic) interface to a wide variety of files representing different things, from videos to images to audio to database serializations to spreadsheets to documents etc. etc. and could hardly be called ``doing one thing and doing it well'' as it would be doing MPEG decoding, XML parsing, PNG compression and decompression etc. etc.

I don't give a rats butt about the UNIX way though :D

Again, it would be papering over the true problem. Nevertheless it's paper I would welcome.

>>52
If you want to write ``datatypes for UNIX'' as a Common Lisp (specifically CLOS, to which this problem is well suited) library interfaceable in Lisp in the usual way but which also has a (start-daemon) function to interface over UNIX sockets via some standard RPC protocol (as a bonus you can interface remote files the same way), I am interested, and we could collaborate.

>>54
I have too many other things to do right now, but the project would be fun. It would consist of taking existing libraries and finding a protocol that could describe all of their usages. Sockets could do it, and would make it very plan9, but there's also the shmat and friends for sharing memory if you want to zomgmitize it.

>>55
I have too many things to do too, and was kind of hoping you'd say that.

The protocol already exists; you just steal and improve the AmigaOS one. The idea is you use existing Lisp or C libraries to implement those protocols, and also provide a lower level one for the exact file type e.g. you have an image protocol, and you also have a jpeg, png, gif etc. protocol.

If I ever make a start I might post the repo here.

>>53

:D

Kill yourself you low IQ third world retard shitskin or eurotrash.

>>57
Oh, I get it, this is a /prog/raider. Enjoy your ban, faggot.

>>58
It's pretty clear that you're the new one from le 4chan nigger.

>>57
I'm european yes, but I do not live in europe.

>>57-60
Keep this shit on /loung-

Nevermind, just shut the fuck up and don't act like retards from 4chan.

[hidden]I'm not a programmer. I know about this place and now I know about your secret society. How does that make you feel?[/hidden]

>>62
There is no secret society.

>>62
really? so tell me the name of the secret board. faggot.

>>64
faggot.

Designing an Alpha Microprocessor

http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.199.7582&rep=rep1&type=pdf

http://ootbcomp.com/topic/introduction-to-the-mill-cpu-programming-model-2/

I found it on HN

btw this place is a bit quite lately..

>>67

This place is a bit quite lately

I attribute that to the Spring semester. Bored university students on break tend to inflate sites.

>>16
I apologize for the late response.

I've been pretty busy and distracted between meeting a milestone at work and being ill with the flu, and I'm just catching up on these threads now.

I would like to see a way to take a dataset - an image, or, say, spectrographic data, or a sound file, and apply mathematical transformations to it just by issuing some simple commands. Maybe have a "math mode" to plug in equations and an "English mode" where you could name the mathematical functions.

I too have done industry work in computer vision. When I was doing R&D, I had success using Octave to test out my mathematical models and algorithms. I also used AWK to transform text datasets.

It's not LISP, but it worked well for what I needed.

Machine learning and a memory of which algorithms chained together worked in similar situations would definitely be an asset. Is that workable?

Now this would definitely be useful.

>>69
I feel like easing use of, and experimentation with, ML algorithms would be useful. Really we would only be building a framework off of which to hang algorithms, and I guess some kind of meta-algorithm based on data types provided.

I used Octave as well, although lately I've been using Python to do more or less the same thing in personal projects. Sorry, I know the reputation it has around here, but it has a lot of libraries. I do wish it had easier syntax to write in vim. I basically have to have a separate .vimrc if I want to use it at all.

On April 7, 2014, Christopher Poole decided to put to sleep the Old World. As an immediate consequence a pack of wild Jews migrated to the New World.

Things will never be the same. April 7th, never forget!

>>71

Remember the Shoah!

>>72

Shalom!

--------8<------------------------------------

Let's start again. Do not bump.