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

If stonemasons created one many years ago just because they knew how to carve stupid stones and build some basic structures,

You are an ignorant, retarded, NIGGER.

kill yourself

>>2
Why? It's the undeniable truth.

We should carve bonerlang in wood if you get my drift.

>>1
* λ
* SYN SYN-ACK ACK, but spoken out loud
* Kill everyone who dares touching the FIOC or the anally prolapsed Javashit
* tdavis
* Mentifex
* http://libgen.net
* Same as those forbidden by the holy rules

>>2
I hope I didn't offend you Masonic-chan...

>>1
Although you appear to have written this facetiously, I've been thinking seriously about it for some time. We can do a lot for each other if we organize ourselves, and as you say, with all due deference to the freemasons, if normal people can do this, then it shouldn't be hard for us at all.

I suggest a short list of objectives, in order of importance:

1. Freedom to pursue the arcane arts, embodied in our case in programming, but including science, engineering, pure mathematics, and whatever else interests us
2. Survival of the society
3. Acquisition of arcane power

Although tolerating, say, Java would be a choice I would oppose, I don't think we should limit ourselves by formally rejecting certain languages or principles, or by tying ourselves to ones that are at some point desirable. This practice extends to social issues as well, in that we ought to be above the drudgery of politics. We can best deal with the control-freak bogeymen - personified most forcefully at the moment by SJWs and the NSA - by ignoring and excluding individuals who are more active in the social and political arenas than in those of direct interest to us. While it would not be proper to prevent members from taking a political stance, a political or social cause is not something the organization as a whole should endorse.

I also have a suggestion regarding leadership which I think aids the survival of a society composed of intelligent people. Our activies as an organization will focus largely on the completion of projects, whether they are software or pure research. Project selection can be accomplished by a leaderless organization, in which individual members are free to choose to participate on a project or not as they like. Most likely, some people will always work on their own, while others will usually collaborate. Within the scope of a project, the individual or group responsible for its inception would run the show. This would

A. maximize freedom
B. maximize enjoyment
C. permit collaboration on large projects without affecting A or B
D. limit the influence of new, more naive members, while offering them a wide range of options

and probably other things, I don't know. Valve has done something like this, and the danger has been shown to be the formation of cliques. This is inevitable, but should and can be discouraged, since it is an ape-habit, and not the business of our hypothetical society.

Selecting new members could be accomplished in a manner like the one the freemasons use: invitation of individuals by one or two of our own, followed by some kind of evaluation by other existing members. I hope it goes without saying that non-practitioners - salespeople, laborers, and so on - will be excluded from membership, and should ideally not know the nature of the organization they are serving.

This leads to economic concerns. In order to effectively accomplish goal 1 (freedom to pursue study) without endangering goal 2 (our survival), we must derive profit from some fraction of our projects. However in accepting the limitations of commerce, we limit the degree to which we can fulfill goal 1. I see two ways around this. One is obviously to find projects which are both enjoyable and potentially profitable. The other, which is possible only in a mature organization, is to require initiates to serve a short time in projects not of their choosing. In this manner they would be treated as apprentices, and could additionally evaluated for full membership.

The point of founding this sort of society would be to free us from working on projects which are beneath us while furthering projects which we do value, a goal which is very much in our interests. It is not reasonable to expect that the ideas I have laid out here are perfect, but I hope they form a starting point from which we can build, as OP put it, a secret society; some kind of mages' guild.

>>7
So basically the FSF, but with pseudonyms and more public key crypto?

>>8
No. I would like a place which can sustain itself financially (without begging), and I am slightly against anonymity within the society itself. Avoiding notice from the outside isn't hard, and I don't care one way or the other whether people know about us. The FSF also evangelizes free software, which is fine, but I'm much more interested in sharing software amongst ourselves than with outsiders. If anything, we should encourage the notion that computers are inaccessible and hard to understand. We could use that belief to our advantage.

Basically, rather than trying to drag everyone along like the FSF, I think we should cut the dead weight loose and see how high we can go.

>>9

but I'm much more interested in sharing software amongst ourselves than with outsiders.

That sounds in contradiction with the prime objective of the hypothetical organization.

If anything, we should encourage the notion that computers are inaccessible and hard to understand. We could use that belief to our advantage.

If indeed the populace doesn't understand anything about computers and programming, politicians can much more easily manipulate them into taking away computer freedom, contradicting the prime objective.

>>10

politicians can much more easily manipulate them into taking away computer freedom

That's a valid point. My concern is that politicians don't seem to be terribly interested in what the population is asking for as it stands now. They listen to people with power, so the best way to determine the battle's outcome is to become too powerful to ignore. The FSF is never going to have that much power, because they give their work away to evil people as well as good. They are existentially a neutral force.

I know it sounds ridiculous to talk about this on a 12-person BBS with no one important paying attention, but this is exactly the kind of place these things get started. Given the code I've seen on the /prog/ board, we've got the programmers we need, if we can just agree on something for long enough to get it done. We can gather resources and use them to further our goals. But your ten hours a week and my ten hours a week in isolation will not likely do that. It's only by working together that we are likely to make something happen.

Anyway, if you're talking about what contradicts the primary objective, then you must already be in agreement with it. The only question remaining is whether you're willing to act.

>>11

The FSF is never going to have that much power, because they give their work away to evil people as well as good.

I thought we weren't going to get political, what metric are you using to determine evilness?

>>9

If anything, we should encourage the notion that computers are inaccessible and hard to understand. We could use that belief to our advantage.

This is too extreme.

My life goal is to create or otherwise contribute to an understandable computer. A truly understandable computer from the schematics of the keyboard and the display to the CPU. The commercial success of this product is one of the goals. It's not enough for Symbolics to have once made Lisp Machines, they should still be making them today. There is a market here however niche.

By understandable I mean understandable to a non-retard, but understandable nonetheless.

I want computers to stop being used primarily as convenient all-in-one-1800s-state-of-the-art multi devices (i.e. telephone, telegram and television but all in one!) and start being used as a means of moulding abstract things (i.e. programs and the things they represent) like clay.

I don't think its right that the only thing that separates a programmer from a non programmer isn't intelligence or love for ideas but just how much stupid pointless bullshit (x86, UNIX etc.) you're willing to put up with.

>>12
Giving away software is itself a political act, and besides that it's a blunt instrument. We can do more by requiring that (at least corporate) customers contribute to our cause by paying for our work. I don't feel that this is political, but if you do, I would rather drop or limit the apolitical requirement than lose the ability to charge companies, for whom I have no particular regard, for the fruits of our labor.

>>13

This is too extreme.

I'll concede that. Given the opinions expressed, I hereby renounce it.

My dream is to create a world where all basic needs - food, shelter, and so on - are met by automated systems. I see that as complementing your goal, in that each could lead more quickly to the other.

Is there one concrete thing you could think of to make it happen?

>>14

Giving away software is itself a political act, and besides that it's a blunt instrument. We can do more by requiring that (at least corporate) customers contribute to our cause by paying for our work. I don't feel that this is political, but if you do, I would rather drop or limit the apolitical requirement than lose the ability to charge companies, for whom I have no particular regard, for the fruits of our labor.

I understand. Not making corporate customers pay for the fruits of our labour would be unfair to ourselves. However, I feel it would contradict our prime objective if we didn't make the source to the software we produce available for all to study and audit. So how about this:
- non-commercial non-governmental users may freely (without any payment) study, redistribute, modify, and execute the software we make for educational and personal not-for-profit things
- everyone else must pay for it (of course, they can study/audit it (which would help computer security) but they can't actually use it without payment)

Is there one concrete thing you could think of to make it happen?

Design and manufacture an understandable (and auditable!) computer like >>13 said.

>>15
That's a perfect solution, which in fact already exists here and there.

Design and manufacture an understandable (and auditable!) computer like >>13 said.

Ok, but something we can actually do within, say, six months or a year. I mean that I support that idea, and I'll work on it, but we need to break it into smaller pieces if we ever want to release something. I'm assuming that we're all software people (although if anyone here knows electrical and/or mechanical engineering, please speak up), which means that we're restricted to programming; we also (for now) have to limit ourselves to a narrow goal.

For me, I would like to see some way to rapidly analyse and modify complex data sets. Be aware that the remainder of this paragraph is pulled straight out my ass. However: last year I was working on software that was supposed to recognize faces, facial features, skin, etc. Rather than coding it (as I did), then looking at the results, then going back and tweaking endlessly, 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. Machine learning and a memory of which algorithms chained together worked in similar situations would definitely be an asset. Is that workable? The reason I think it fits loosely into the goal of creating a readily-understood computer is that it makes complex math fairly easy. I could see similar tools being used in electronics design, for example.

Speaking of which, another thought I had a while ago was a "compiler" or "high level language" for electronic circuits. Basically, shove in component X (an IC?) and component Y (I don't know, a Voltage source), say "here are the data sheets, hook these things together at points a, b and c, and make sure nothing goes over/under voltage/current." The software would figure out the resistors, transformers, voltage converters, etc. and bang, instant circuit. Supposedly. If that's not NP-hard, and heck, maybe even if it is. But anyway, that's something that might help too. Thoughts?

>>16
They both sound like cool ideas, and the latter sounds like an amazing idea (as it would finally allow people who have a solid basis in computer science and mathematics but don't know much about electronics to quickly design circuits).

>>16

Speaking of which, another thought I had a while ago was a "compiler" or "high level language" for electronic circuits

Verilog, VHDL, SKILL, SPICE...

A device owned by a person will operate in accordance to the expectations of the person. It will not act as a survallence device for a third party. This is partially helped by the proliferation of peer reviewed open source software.

Information that is free shall remain free and accessible to anyone in the world who wants to find it. Currently exists and doesn't depending on where in the world you are. If it cannot be obtained politically, it should be obtained using technology that helps the internet resist censorship. Contributions to projects like tor and freenet help, but if their users are persecuted then obfuscated protocols and or stenography is needed.

All details of all individuals' digital information should be private and accessible only to them and the ones they specifically choose to share it with. Everyone should have the benefits of cryptography for privacy and safety. User friendly applications providing encryption by default help. But people need to care enough to take the initiative first, so some amount of public activism or education is needed here.

Dependence on centralized infrastructures and services should be minimized. These services should be moved out into p2p models so that those who control the centralized service can't use dependence on the service to control their users. This is aided by the development of p2p substitutes for centralized services like distbb!

That's mostly it for now. I don't expect to be paid for working towards any of these causes.

young minds poisoned by the gang of four
cut off from the ancient knowledge
LISP has left the building
we're doing python now
SICP a mere shadow of its past

the next PHP programmer interrupts me
"his" language can do it all anyways
blinded by ignorance
he cannot even see his shackles he built for himself

so we bite our lips just a little longer
learn to avoid the puzzled looks of the youngins
when they see the disappointment in our eyes
when they announce their newest web-project

brogrammers copy pastin code from stackoverflow
unaware of the finer subtleties of the art
the principles of UNIX long forgotten
in a tldr culture that nobody has time for

woe us
little to gain
nothing to lose
trapped in the bottom of the belly the machine
divided
defeated

and the machine is dying

>>20
is this a modification of the lyrics of an existing song?

>>21

No, this was an original by me, yours truly. But inspiration was taken from (at least) these two sources:

http://www.youtube.com/embed/oOYdQOLkqf4

The government is corrupt,
and we're on so many drugs
with the radio on and the curtains drawn.

We're trapped in the belly of this horrible machine,
and the machine is bleeding to death.

The sun has fallen down,
and the billboards are all leering,
and the flags are all dead at the top of their poles.

(though I originally had a better version of the song in mind, one with more pump, this is the one I was able to find.)

and:

http://hackingdistributed.com/2013/01/29/mongo-ft/

Look, I realize that we live in a TL;DR culture. I lived through 8 years of a non-reading president along with everyone else. I know that the brogrammers out there are constantly getting texts from their buddies to plan the weekend's broactivities, trying to decide in whose mancave they'll be setting up their lan party, and are thoroughly distracted in between futzing with their smart phones and writing a few lines of code per day by cutting and pasting it from stackoverflow. But it's really not ok to act functionally illiterate when you're not actually illiterate, when an advanced society that once put a man on the moon worked so hard to educate you.

(emphasis mine)

found it: http://www.youtube.com/embed/UhfUWgUH6Qc

>>22
Not all of us are Americans.

>>20
The principles of UNIX? I'm a Lisp programmer, I don't give a rat's butt about the principles of UNIX.

>>25
And your LISP interpreter runs on what exactly? NT?
inb4 Symbolics

>>18
I was using programming language more as a metaphor; I had something more graphical in mind, like EagleCAD but doing more for the designer. The aim would be to ease the design process for an expert, but also to educate a novice in why various components were needed.

Verilog and VHDL seem to focus mainly on logic gates; they are more like real programming languages. SPICE is closer to what I had in mind, but only models circuits handed to it. I would like to see about taking the next obvious step and smooth the process of circuit design by allowing the designer to work with higher-level abstractions. As with programming, this would reduce the flexibility available, and the old guard would often turn their noses up at it, but I suspect it could also be used to do a lot of work fairly quickly, making it appealing to a lot of people.

Do you have experience in this field? I was just throwing the idea out, and I don't have much knowledge of electronics itself.

>>8
The FSF? more like the CCC!

>>27
Not really. I know the basic physics, and I designed a crappy microcoded 4-bit register machine with an ALU as part of my formal education. But that's it.

There's plenty of really very very good EDA tools out there. Cadence's offerings I hear are the very best, although I have not used them. GNU Electric is little known but highly regarded (developed at Sun, used to design Sun products (now Oracle)), and very easy to use (I have used it).

I've tried using the gEDA suite but that's the usual UNIX style small is beautiful batch processing with text interface bullshit i.e. unusable efficiently by humans, terrible to interface for programmers. There's KiCAD which I haven't tried using, but seems nicer than gEDA.

There used to be New Schematic for Symbolics' Genera...

To get started you'd probably want to read http://www.allaboutcircuits.com/ which uses gEDA tools. Then you'd want to read the bible i.e. "The art of electronics", or maybe read "Practical electronics for inventors" before that. When you read the latter two books it's probably good to follow along with whatever EDA tools you choose (might be a good idea to choose two of them and compare).

There's lots of examples to study from: http://opencores.org//.

With specific regards to the CPU the PDP-10 is interesting, as is the SPARC for contrast. Symbolics' patents are absurdly and stupidly detailed...

http://bitsavers.trailing-edge.com/pdf/symbolics/patents/4887235_3600_patent.pdf

>>26
It's not ``LISP'' (and hasn't been for a while), it's Common Lisp, and it's a system, including, but not just, an interpreter. In fact, I don't remember ever evaluating (setf sb-ext:*evaluator-mode* :interpret), so I probably have never used the interpreter. It runs on a wide variety of computers and operating systems including the world's favorite UNIX and VMS clones.

I use Linux myself, and I suppose I am grateful, but in no way do I think it's ideal or even close to it. The UNIX philosophy or the UNIX way should be something to be abhorred and disgusted by, embraced only out of practical necessity for money in today's world, not something to idolize.

>>29

not something to idolize

really??

From "The Unix programming environment":

Even though the UNIX system introduces a number of innovative programs and techniques, no single program or idea makes it work well. Instead, what makes it effective is the approach to programming, a philosophy of using the computer. Although that philosophy can't be written down in a single sentence, at its heart is the idea that the power of a system comes more from the relationships among programs than from the programs themselves. Many UNIX programs do quite trivial things in isolation, but, combined with other programs, become general and useful tools.

And then also, from "The Bell System Technical Journal" (1978):

(i) Make each program do one thing well. To do a new job, build afresh rather than complicate old programs by adding new features.
(ii) Expect the output of every program to become the input to another, as yet unknown, program. Don't clutter output with extraneous information. Avoid stringently columnar or binary input formats. Don't insist on interactive input.
(iii) Design and build software, even operating systems, to be tried early, ideally within weeks. Don't hesitate to throw away the clumsy parts and rebuild them.
(iv) Use tools in preference to unskilled help to lighten a programming task, even if you have to detour to build the tools and expect to throw some of them out after you've finished using them.

>>30
Yes, really.

>>31
Well, I disagree.

>>32
What else can you expect from a linux user? Go BSD or go home.

>>33
There's not that much difference between Linux and BSD.

Programs are still binary blobs. The interface between programs is still byte streams. Files and file systems still exist...

>>32
Have you ever used Genera or a Smalltalk environment?

I can't believe what I am reading here, are you against the KISS principle? what kind of hipsters are you?!

>>34
Yes we get it, you're autistic.

>>37
suck my anus

>>36
False dichotomy.

Telecomix is a really cool secret club: they have a symbol, secret members, and amazing project.
The old cypherpunks mailing list was kind of a secret order for cryptographers, and they really changed everything.
The Chaos Computer Club in Germany is the oldest computer club in the world, and they are awesome.

I believe that /prog/ have enough net-culture to start a new secret society.
If you really are into it you should read The Illuminatus trilogy, and Discordianism stuff like Principia Discordia. But I suppose you already did.

>>36
I am not a hipster, I am a sorcerer who summons the spirits of the computer with his spells.

There is nothing KISS about UNIX. A more apt description for what UNIX adheres to is KIRR or Keep It Retarded, Retard.

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