Programming thread

Most OSes annoy the shit out of me. I kinda want them to get out of the way so I can just write code.

But there's a few that I find interesting.

The old Lisp machine OSes were reportedly cool as shit.

Their whole shtick was that they were essentially just elaborate JIT compiling interpreters. The whole OS was written in Lisp, from top to bottom. And at any point, you can open up a repl (like a shell) and run code that manipulates kernel structures directly. There is no wall between compile time and runtime. It was all accessible.

(Now, there's going to be a lot of caching mechanisms and access controls and things like that. But it's generally all within reach of the repl, and even if currently running code was compiled now, you could do something like `(set! some-function (lambda () ...))` and just replace the code and it'd get compiled and injected in place.)

It had tools that were kind of like the html DOM inspector that browsers have, except for the OS. You could inspect GUI elements and poke and prod everything.

And if you changed something in the repl and you wanted to keep it, you could toss the code in their analog of ~/.xinitrc or whatever and it'd be there on startup.

Too much software is developed to be broadcast at people from centralized sources, at the expense of being able to conveniently fuck with it yourself. Being able to fuck with your own software directly is great. Anything that makes fucking with your own software easier, faster or more responsive is an improvement.

I think JIT and repls provide the single biggest improvement towards that end. Like, if I have to work with a new language, and if it doesn't have a repl, I'm blown away. How does anyone get anything done if they can't mold the program interactively?

Having to edit, save a file, and run "make test" over and over like a baboon? Forget that nonsense.
 
  • Agree
  • Informative
  • Thunk-Provoking
Reactions: MarvinTheParanoidAndroid, hauser, trashbat and 3 others
if you run things ind debug you don't really need a repl. Change the registers (including program counter), the stack, the memory, etc...
 
  • Informative
Reactions: MarvinTheParanoidAndroid
Marvin said:
The old Lisp machine OSes were reportedly cool as shit.

Their whole shtick was that they were essentially just elaborate JIT compiling interpreters. The whole OS was written in Lisp, from top to bottom. And at any point, you can open up a repl (like a shell) and run code that manipulates kernel structures directly. There is no wall between compile time and runtime. It was all accessible.
Click to expand...
Everything about that sounds amazing, but the above section worries me a little bit. Most people I know, even the ones that are "tech literate" by normie standards, should not be let anywhere near code that can manipulate kernel structures directly. A lot of modern OS features are designed to make them as idiot-proof as possible, and for good reason.

Also, there's a guy on 8chan's /tech/ that talks a lot about lisp machines. Most people hate him because he derails tons of threads, but I find it interesting.
 
  • Informative
  • Agree
Reactions: MarvinTheParanoidAndroid, Kosher Salt, Zero Day Defense and 1 other person
DNJACK said:
They don't use C as the main programming language, but they certainly interact with it for interface with external librairies, unlike javascript.

As such, they have to understand some of it.
Click to expand...
In my experience financial analysts use SAS Enterprise Miner and take to drink and hookers due to the resulting existential crisis.
 
  • DRINK!
Reactions: MarvinTheParanoidAndroid
Stock Image Photographer said:
Everything about that sounds amazing, but the above section worries me a little bit. Most people I know, even the ones that are "tech literate" by normie standards, should not be let anywhere near code that can manipulate kernel structures directly. A lot of modern OS features are designed to make them as idiot-proof as possible, and for good reason.
Click to expand...
It'd be akin to kernel modules.
Stock Image Photographer said:
Also, there's a guy on 8chan's /tech/ that talks a lot about lisp machines. Most people hate him because he derails tons of threads, but I find it interesting.
Click to expand...
It's neat stuff, but certainly not something to hammer into every conversation.

Here's an interesting piece of lisp machine history.
 
  • Informative
Reactions: MarvinTheParanoidAndroid and grumbleBum
Splendid Meat Sticks said:
@Marvin, you mentioned the Smalltalk VMs/IDEs/whatever, and now that sounds cool as shit.
However, it doesn't seem like much commercial code actually gets written in Smalltalk.
Click to expand...
Yeah, Smalltalk is an interesting mirror image to Lisp.

It's got that dynamic, interactive development process shtick too. And with Smalltalk, it's turtles all the way down.

Though I can't think of much that was written in Smalltalk. That might be because I'm more of a lisp weenie.

There's nothing keeping anyone from working in Smalltalk. Maybe sometime I'll work on a sample project to scope it out.
 
  • DRINK!
  • Agree
Reactions: MarvinTheParanoidAndroid and grumbleBum
Splendid Meat Sticks said:
@Marvin, you mentioned the Smalltalk VMs/IDEs/whatever, and now that sounds cool as shit.
However, it doesn't seem like much commercial code actually gets written in Smalltalk.
Click to expand...
There’s a certain amount of commercial code written in Smalltalk but it tends to be in house stuff/not available to the general public. The visualisation package, Roassal, is fantastic and well supported. Pharo is a great open source environment with an active community: https://pharo.org/
 
  • Informative
Reactions: MarvinTheParanoidAndroid, Marvin and Splendid
Welcome to the 21st century, where compilers are smart enough to just look to the right of the equals sign and figure out the type right there.
Honestly, this feature should have been universally available by 1990 at the latest, but I think some languages still don't have it.
 
  • Winner
  • Semper Fidelis
Reactions: MarvinTheParanoidAndroid, Ravelord, grumbleBum and 1 other person
Splendid Meat Sticks said:
Welcome to the 21st century, where compilers are smart enough to just look to the right of the equals sign and figure out the type right there.
Honestly, this feature should have been universally available by 1990 at the latest, but I think some languages still don't have it.
Click to expand...
the right of the equal sign but not the line right under.

maybe in 2025....

Also wtf happened to types...
std::list<std::vector<custom::list<int**>>>

DIfferencing between types of pointers was a mistake.
 
  • Thunk-Provoking
Reactions: MarvinTheParanoidAndroid
DNJACK said:
the right of the equal sign but not the line right under.

maybe in 2025....
Click to expand...
But then this turns into a give a mouse a cookie situation.
Give them one line under, they'll want n lines under.
Give them n lines, then they'll want it within a different block.
Give them a different block, they'll want a different method.
Give them a different method, they'll want a different namespace/module/whatever.
etc. etc.
 
  • Like
  • Informative
Reactions: MarvinTheParanoidAndroid and Horus
Stock Image Photographer said:
Speaking of lisp, are you more of a common lisp or scheme guy?
Click to expand...
Scheme. A single namespace for functions and data is simpler. In my experience, there's not much reason for a split namespace, other than allowing someone to name a function "list" that operates on an argument called "list" (instead of just "lst").

However, Common Lisp has produced lots of excellent innovations that get ported to Scheme and other languages. For example, I consider CLOS to be the pinnacle of OOP systems. (Not just in the lisp world, but elsewhere as well.)

The only intellectual competitor to CLOS I can think of is Smalltalk. (I don't really know Smalltalk very well, so I'm just relying on what little I've read on wikipedia.)

Schemes downsides are that it's less of a unified language and more like a family of languages. Or the raw material for a language.

Here's an overview of a CLOS-style OOP system for scheme.
Splendid Meat Sticks said:
Welcome to the 21st century, where compilers are smart enough to just look to the right of the equals sign and figure out the type right there.
Honestly, this feature should have been universally available by 1990 at the latest, but I think some languages still don't have it.
Click to expand...
DNJACK said:
the right of the equal sign but not the line right under.

maybe in 2025....
Click to expand...
Hindley -Milner can infer those types as well. All the math masturbation in that article aside, it basically just consists of tracing the whole program tree and tracking all the types as they pop up. If you've got a function "my_function()" that returns an int, it can fill in the type (at compile time) when you do: foo = my_function();

Although it would prevent code like this:
Code: 
var foo;
foo = new Something();
// some code
foo = new SomethingElse();
Or it'd require some annoying semantics that'd be a nightmare to debug.
 
  • Informative
Reactions: MarvinTheParanoidAndroid
Let me say something else controversial: I don't know F# or Haskell, but I'm gonna guess F# is probably better because you can actually use it for real world things.
 
  • Like
  • Thunk-Provoking
Reactions: MarvinTheParanoidAndroid and Marvin
Stock Image Photographer said:
Most people I know who use Scheme tend to specifically use Racket, so I'm not sure if that's that big of a downside.
Click to expand...
When building stuff with lisp, the end result ends up being very much a custom job. It'll fit the problem like a glove. So there are Schemes that compile to C, schemes that are purely interpreted, schemes that have bytecode interpreters, etc.

Racket is like the Python of the scheme world. It's reliable and general purpose.

Personally I like Chicken. It compiles to C (and uses a pretty neat compilation strategy) and has a pretty nice FFI. But yeah, Racket's cool too.

Speaking of lisp, the Crash Bandicoot games were programmed using a lisp dialect. They had lisp macros that expanded inline to assembly code. Lisp macros are basically hooks into the compiler where you can rewrite syntax.

If this was a C/Java/other-bracketed-language, it would be like being able to write a hook that rewrites:
Code: 
with_signal {
  // normal code here
}
SIGINT {
  // sigint handler hre
}
SIGKILL {
  // sigkill handler here
}
Into whatever the necessary code would be to catch a Unix signal and handle it. And when the with_signal block exits, it'll unset the signal handlers.

(Actually implementing this feature would require dumping the content of the handler blocks into functions at the top of the file, with some randomly generated function names, like signalhandler_000134, then calling signal(SIGKILL, signalhandler_000134) before the block, and signal(SIGKILL, 0) after the block.)

It's a fascinating feature because it helps you bridge the gap between readable code and efficient code. (Because you can speed things up by generating stuff at compile time.)

http://all-things-andy-gavin.com/2011/03/12/making-crash-bandicoot-gool-part-9/

And actually, the whole series of articles about the development of Crash Bandicoot is great (it's not just about programming, but also about the business aspects and dealing with japanese publishers and things like that): http://all-things-andy-gavin.com/2011/02/02/making-crash-bandicoot-part-1/
Splendid Meat Sticks said:
Let me say something else controversial: I don't know F# or Haskell, but I'm gonna guess F# is probably better because you can actually use it for real world things.
Click to expand...
Go with F#. F# is like Ocaml for .Net.

If you're just picking up a functional language, having one of these two properties would be useful:
  • big library of existing code
  • not dealing with too many new concepts all at once
With F#, you have access to all .Net code.

Haskell's neat, but its evaluation strategy is alien.

Basically, if you know what promises are, every value in Haskell is a promise by default.

Code: 
function foo(a, b) {
  if (a) {
    return b;
  }
  else {
    return 40;
  }
}

foo(bar(), baz())
It's Javascript, but pretend we're using Haskell semantics.

So in the above code, if bar() return false, then baz() will never get called.

If baz() does something like 'printf("hello faget");', then nothing will ever get printed if bar() returns false.

It provides some interesting properties, like implementing threading systems is brain-dead simple, and your code becomes very theoretical. You can ask all sorts of complicated things of your code, and only the bare minimum necessary to fulfill your request will get executed.

But... as interesting as it all is, it's probably best to be able to hit the ground running with something practical first.

(Well, don't get me wrong. A lot of smug haskell people think eager (normal) evaluation is babby's first programming language and haskell's way is the ultimate goal. It's not, it's actually useful and straightforward for virtually everything people need to program for. There's a reason why it's the standard evaluation strategy. But of course, it's not the only option, and haskell does bring some interesting things to the table.)
Stock Image Photographer said:
I tried to learn Haskell, but the syntax ended up being really confusing to me. Maybe I'm just too much of a brainlet for functional languages. Reading over some stuff on F# though, it seems like it was actually designed to be used.
Click to expand...
The syntax objection I have with Haskell is that it's got significant whitespace. I hate Python for that and I hate Haskell for it too. (Still neat and useful languages, it just annoys the shit out of me.)
 
  • Informative
  • Winner
Reactions: Effluvial Ooze, MarvinTheParanoidAndroid, Zero Day Defense and 1 other person
You must log in or register to reply here.
Back