4 ms·

(2007) lisp (imho) pushed the limits of what it was possible for a language to do. It pushed in many directions. eval, macros, gc, the comments suggest many th

by jfoutz 10y ago

(2007) lisp (imho) pushed the limits of what it was possible for a language to do. It pushed in many directions. eval, macros, gc, the comments suggest many things. As computers got faster, it became worthwhile to incorporate more and more of those expensive ideas. Heck, go is billed as a systems language and it's GC'ed! That would be crazy 20 years ago. Perhaps still a little crazy today, but far more feasible. Lisp is like the Simpsons. Lisp did it. (maybe not first, but lisp did it) Of course later languages are going to pull some of that wonderful functionality. Other stuff, like reader macros gets left behind. it's even possible to do pretty explicit typing in lisp, but it never felt as natural as an ML/Miranda/Haskell kind of typing. The C# observation is amusing, the original garbage collector was written in lisp. [1] [1] https://blogs.msdn.microsoft.com/patrick_dussud/2006/11/21/how-it-all-startedaka-the-birth-of-the-clr/ https://blogs.msdn.microsoft.com/patrick_dussud/2006/11/21/h...

lisper 10y ago
> Perhaps still a little crazy today Why?
- jfoutz 10y ago
  Depends on how you build your application. Small focused processes work great. If you're not careful, and all the functionality gets stuck in one huge executable, it's possible to have long pauses. If that one huge executable winds up interacting with a serial device, like an old printer, or dumb terminal, well buffers are small. data gets lost. you have to resync and it sucks. FWIW, my experience with that stuff is with java perhaps a decade ago. It can all be made to work with smaller heaps, better partitioning, but you wind up introducing more, but bigger buffers. It almost never matters. Right up until you have to read the status from some old microscope, or something equally obscure.
- BinaryIdiot 10y ago
  RAII is an exceptionally well done memory management model that some languages, like C++ and Rust, use to handle memory and it works exceptionally well. Hell even reference counting in Objective-C is pretty good. Garbage Collection adds a lot of overhead but gives you a good amount of safety and speed in development but you certainly wouldn't want to use it in a scenario that requires something done in real time or many types of embedded systems. Honestly I wish more things embraced RAII. It seems like it would be a better thing to do, in the long run, but that's just my opinion.
spriggan3 10y ago
> go is billed as a systems language When people say "system" they mean "back end" servers and tools. They don't mean kernel programming.
- jfoutz 10y ago
  I can imagine a webserver that drives a little robot via bluetooth. Low consequence for failure. It's easy to imagine the webserver part of the functionality causing a long pause, and a "stop" message to the robot being late. golang would do a fantastic job at this, i think it would be far more enjoyable than C. Latency almost never matters. But sometimes it matters.
- vortico 10y ago
  Many people consider Go (and Rust) as a reasonable choice for developing a toy kernel, and some projects have turned out to be somewhat serious.
  - vvanders 10y ago
    Go and Rust aren't in the same domain. Any time you have a GC then you need to talk about pinning, non-determinism and a whole host of other issues. FWIW last time I looked Go doesn't even specify heap vs stack which would be a non-starter for me.
    - dualogy 10y ago
      "When possible, the Go compilers will allocate variables that are local to a function in that function's stack frame. However, if the compiler cannot prove that the variable is not referenced after the function returns, then the compiler must allocate the variable on the garbage-collected heap to avoid dangling pointer errors. Also, if a local variable is very large, it might make more sense to store it on the heap rather than the stack. In the current compilers, if a variable has its address taken, that variable is a candidate for allocation on the heap. However, a basic escape analysis recognizes some cases when such variables will not live past the return from the function and can reside on the stack." https://golang.org/doc/faq#stack_or_heap https://golang.org/doc/faq#stack_or_heap
groovy2shoes 10y ago
> Heck, go is billed as a systems language and it's GC'ed! That would be crazy 20 years ago. Modula-3 was a systems language with GC that was released in the late 80s. It could be disabled for applications that couldn't benefit from it, but in the long run it helped Modula-3 be a much safer language for systems programming than anything with manual memory management. After all, most "systems programs" aren't OS kernels anyway. Even if I were to write an OS in Modula-3, the first thing I'd do is write a real-time GC as an `unsafe` module (possibly mixed with some assembly), then write the rest of the OS such that it can make use of that. Hell, modern machines have so many cores that it might not be crazy to dedicate a core to a concurrent GC. There are also GCs that allow programmers to set a cap on latency, and the GC always ensures that it returns control before the cap is reached [1]. Given the considerable amount of research that has gone into writing operating systems in managed languages (Lisp, Oberon, Haskell, C#, ...), it doesn't seem particularly crazy to me today. Besides, there are plenty of other reasons to dis Go :p [1]: http://www.cesura17.net/~will/Professional/Research/Papers/boundedLatencyGC.pdf http://www.cesura17.net/~will/Professional/Research/Papers/b...
wiml 10y ago
20 years ago, perhaps. But 30 years ago, you could buy workstations that were programmed in Lisp all the way down to the metal: https://en.wikipedia.org/wiki/Symbolics https://en.wikipedia.org/wiki/Symbolics
pjmlp 10y ago
> Heck, go is billed as a systems language and it's GC'ed! That would be crazy 20 years ago. Perhaps still a little crazy today, but far more feasible. Not at all, I was introduced to Native Oberon around 20 years ago. It was a great OS used at ETHZ and many European universities. Specially the system 3 version with its gadgets framework. Around the same time DEC/Compaq had SPIN OS implemented in Modula-3, with POSIX API and a very interesting distributed objects framework. Xerox PARC had the Mesa/Cedar workstation in the early 80's. There were a few OSes implemented with Algol 68 variants that had GC at OS level in the early 70's. The craziness is that in the last 20 years, thanks to the rise of FOSS and its UNIX/C culture, younger generations seem not to bother with everything else that existed.
lobster_johnson 10y ago
Java came out 20 years ago, though.
josteink 10y ago
> Heck, go is billed as a systems language and it's GC'ed! That would be crazy 20 years ago. When your allow the term to mean anything, it's only natural that anything qualifies. The computing world uses the term to describe things you build operating systems and kernels and hardware interfaces with. Google redefined it to mean something you build web apps with ala NodeJS. By that definition, PHP is a systems language too. Basically Go as a systems language is a false claim.
- josteink 10y ago
  Just to clarify my comment in case it comes off overly negative: I don't think go is a bad language as such. I just think representing it as an alternative to C, a systems language, is misleading.

by jfoutz 10y ago

lisper 10y ago

> Perhaps still a little crazy today Why?

jfoutz 10y ago
Depends on how you build your application. Small focused processes work great. If you're not careful, and all the functionality gets stuck in one huge executable, it's possible to have long pauses. If that one huge executable winds up interacting with a serial device, like an old printer, or dumb terminal, well buffers are small. data gets lost. you have to resync and it sucks. FWIW, my experience with that stuff is with java perhaps a decade ago. It can all be made to work with smaller heaps, better partitioning, but you wind up introducing more, but bigger buffers. It almost never matters. Right up until you have to read the status from some old microscope, or something equally obscure.
BinaryIdiot 10y ago
RAII is an exceptionally well done memory management model that some languages, like C++ and Rust, use to handle memory and it works exceptionally well. Hell even reference counting in Objective-C is pretty good. Garbage Collection adds a lot of overhead but gives you a good amount of safety and speed in development but you certainly wouldn't want to use it in a scenario that requires something done in real time or many types of embedded systems. Honestly I wish more things embraced RAII. It seems like it would be a better thing to do, in the long run, but that's just my opinion.

spriggan3 10y ago

> go is billed as a systems language When people say "system" they mean "back end" servers and tools. They don't mean kernel programming.

jfoutz 10y ago
I can imagine a webserver that drives a little robot via bluetooth. Low consequence for failure. It's easy to imagine the webserver part of the functionality causing a long pause, and a "stop" message to the robot being late. golang would do a fantastic job at this, i think it would be far more enjoyable than C. Latency almost never matters. But sometimes it matters.
vortico 10y ago
Many people consider Go (and Rust) as a reasonable choice for developing a toy kernel, and some projects have turned out to be somewhat serious.
- vvanders 10y ago
  Go and Rust aren't in the same domain. Any time you have a GC then you need to talk about pinning, non-determinism and a whole host of other issues. FWIW last time I looked Go doesn't even specify heap vs stack which would be a non-starter for me.
  - dualogy 10y ago
    "When possible, the Go compilers will allocate variables that are local to a function in that function's stack frame. However, if the compiler cannot prove that the variable is not referenced after the function returns, then the compiler must allocate the variable on the garbage-collected heap to avoid dangling pointer errors. Also, if a local variable is very large, it might make more sense to store it on the heap rather than the stack. In the current compilers, if a variable has its address taken, that variable is a candidate for allocation on the heap. However, a basic escape analysis recognizes some cases when such variables will not live past the return from the function and can reside on the stack." https://golang.org/doc/faq#stack_or_heap https://golang.org/doc/faq#stack_or_heap

groovy2shoes 10y ago

> Heck, go is billed as a systems language and it's GC'ed! That would be crazy 20 years ago. Modula-3 was a systems language with GC that was released in the late 80s. It could be disabled for applications that couldn't benefit from it, but in the long run it helped Modula-3 be a much safer language for systems programming than anything with manual memory management. After all, most "systems programs" aren't OS kernels anyway. Even if I were to write an OS in Modula-3, the first thing I'd do is write a real-time GC as an `unsafe` module (possibly mixed with some assembly), then write the rest of the OS such that it can make use of that. Hell, modern machines have so many cores that it might not be crazy to dedicate a core to a concurrent GC. There are also GCs that allow programmers to set a cap on latency, and the GC always ensures that it returns control before the cap is reached [1]. Given the considerable amount of research that has gone into writing operating systems in managed languages (Lisp, Oberon, Haskell, C#, ...), it doesn't seem particularly crazy to me today. Besides, there are plenty of other reasons to dis Go :p [1]: http://www.cesura17.net/~will/Professional/Research/Papers/boundedLatencyGC.pdf http://www.cesura17.net/~will/Professional/Research/Papers/b...

wiml 10y ago

20 years ago, perhaps. But 30 years ago, you could buy workstations that were programmed in Lisp all the way down to the metal: https://en.wikipedia.org/wiki/Symbolics https://en.wikipedia.org/wiki/Symbolics

pjmlp 10y ago

> Heck, go is billed as a systems language and it's GC'ed! That would be crazy 20 years ago. Perhaps still a little crazy today, but far more feasible. Not at all, I was introduced to Native Oberon around 20 years ago. It was a great OS used at ETHZ and many European universities. Specially the system 3 version with its gadgets framework. Around the same time DEC/Compaq had SPIN OS implemented in Modula-3, with POSIX API and a very interesting distributed objects framework. Xerox PARC had the Mesa/Cedar workstation in the early 80's. There were a few OSes implemented with Algol 68 variants that had GC at OS level in the early 70's. The craziness is that in the last 20 years, thanks to the rise of FOSS and its UNIX/C culture, younger generations seem not to bother with everything else that existed.

lobster_johnson 10y ago

Java came out 20 years ago, though.

josteink 10y ago

> Heck, go is billed as a systems language and it's GC'ed! That would be crazy 20 years ago. When your allow the term to mean anything, it's only natural that anything qualifies. The computing world uses the term to describe things you build operating systems and kernels and hardware interfaces with. Google redefined it to mean something you build web apps with ala NodeJS. By that definition, PHP is a systems language too. Basically Go as a systems language is a false claim.

josteink 10y ago
Just to clarify my comment in case it comes off overly negative: I don't think go is a bad language as such. I just think representing it as an alternative to C, a systems language, is misleading.