Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Gerbil – An opinionated dialect of Scheme designed for systems programming

github.com

Post reply on HN
Print view View original

61–70 of 80 posts

Re: Gerbil – An opinionated dialect of Scheme designed for systems programming

#61

Post by cat199 »

Johnny_Brahms wrote: post #54
ClFromEmacs wrote: post #47

Earlier quoted context omitted.

R7RS ftw.

I feel that not standardising a low level FFI for r7rs large is a mistake. They should at least recommend some reasonably low level stuff that can be used to build abstractions.

Agree with the sentiment, but at the same time understand the rationale - FFI implies alot of GC/memory internal interfacing stuff, and to some extent expects a c-based implementation (not e.g. JVM,CLR,etc).

If r7 & library interface are widely adopted, some flavors of FFI could evolve within the library/srfi process and gradually become defacto standards..

Probably hoping too much.. but in any event..

Re: Gerbil – An opinionated dialect of Scheme designed for systems programming

#62

Post by cat199 »

xfer wrote: post #24
Naac wrote: post #11

Earlier quoted context omitted.

I think maybe there is a different interpretation of the words "systems programming"? I took it to mean a scheme used for developing close to the hardware programs, where as maybe others are taking it to mean a language which can be used to write common scripts and tools used by Systems Engineers.

Close to the hardware can also be done with scheme and indeed has been done in the past. Look at all the smartcards, running a JVM. For scheme, it just requires some engineering effort and there is not much demand for it. Btw, there is picobit( https://github.com/stamourv/picobit ) which can be run on micro-controllers.

That wasn't the point of parent -

scsh is purely interpreted and interfaces well with user-level programs but was being put forth as a systems-programming tool - while this works for some definitions of systems programming, it doesn't for others, and it is this distinction that the parent was pointing out.

Re: Gerbil – An opinionated dialect of Scheme designed for systems programming

#63

Post by cat199 »

rfreytag wrote: post #41
flavio81 wrote: post #13

Earlier quoted context omitted.

>Why do people keep thinking they can use a garbage-collected language for “systems programming”? Why do you think it can't be done? It was already used for systems-programming in the early 80s; whole machines were programmed in Lisp in low level: TI Explorer, Xerox workstations and others.

I distinctly remember waiting quite a long while with my Symbolics locked up while it completed a GC.

I distinctly remember waiting quite a long while with my PC locked up while it completed a Win32 load.

Re: Gerbil – An opinionated dialect of Scheme designed for systems programming

#64

Post by cat199 »

astrobe_ wrote: post #53
CoolGuySteve wrote: post #12

Earlier quoted context omitted.

I always wonder exactly what kind of "systems" these people are programming, clearly not any with real-time constraints. It almost seems like "systems programming" got co-opted to mean "not interpreted". At least that's what I noticed with Go's marketing. There are a few HFT firms, most notably Virtu, that use Java. But my understanding from having interviewed people that worked there is that it's so convoluted to av…

It seems to md that systems (with a 's') programming was a term lntroduced by Go, and I always understood it has something with a wider scope than system programming - actually "intermediate level" applications for which a GC is acceptable both time-wise and space-wise. Yet for system (without 's') programmers (kernel, driver or embedded systems devs for instance) a GC is still a no-go.

> lntroduced by Go

no. further popularized perhaps, but no.

perhaps a shorthand for 'distributed systems' programming, idk.

Definately heard the phrase applied in this area 10+ years ago, by people who had been around for 10+ years (see also go authors)

Re: Gerbil – An opinionated dialect of Scheme designed for systems programming

#65

Post by e12e »

WindowsFon4life wrote: post #40
e12e wrote: post #25

Earlier quoted context omitted.

Some excellent comments there. Looking around a bit, I came across a couple of implementations that might be of interest for those wanting to mash up "some kind of system programming" and "scheme": Bigloo (interpret / compile to executables, java byte code or experimentally dot.net) and larceny (interpret / direct compile to machine code / optionally via c): http://www-sop.inria.fr/mimosa/fp/Bigloo/ http://www.larcen…

Try building a modern project in either. Anything non-trivial will highlight where Gerbil stands out.

I'd be happy to see some example non-trivial, new(ish) projects in any scheme, actually.

Hop looks like one such project, I don't know if gerbil would be better as an underpinning than Bigloo?

https://github.com/manuel-serrano/hop

Re: Gerbil – An opinionated dialect of Scheme designed for systems programming

#66

Post by mschaef »

xfer wrote: post #24
Naac wrote: post #11

Earlier quoted context omitted.

I think maybe there is a different interpretation of the words "systems programming"? I took it to mean a scheme used for developing close to the hardware programs, where as maybe others are taking it to mean a language which can be used to write common scripts and tools used by Systems Engineers.

Close to the hardware can also be done with scheme and indeed has been done in the past. Look at all the smartcards, running a JVM. For scheme, it just requires some engineering effort and there is not much demand for it. Btw, there is picobit( https://github.com/stamourv/picobit ) which can be run on micro-controllers.

PreScheme serves the same sort of role within the Scheme48 ecosystem. It's been a while since I've looked at Scheme48, but if I remember right, the VM is written in PreScheme, which is usually compiled down to either C or machine code. However... you can also run PreScheme code within Scheme48, so that it's possible to test/update the VM semantics without actually compiling down to C for each dev cycle.

Re: Gerbil – An opinionated dialect of Scheme designed for systems programming

#67

Post by mschaef »

CoolGuySteve wrote: post #12
jblow wrote: post #3

Why do people keep thinking they can use a garbage-collected language for “systems programming”?

I always wonder exactly what kind of "systems" these people are programming, clearly not any with real-time constraints. It almost seems like "systems programming" got co-opted to mean "not interpreted". At least that's what I noticed with Go's marketing. There are a few HFT firms, most notably Virtu, that use Java. But my understanding from having interviewed people that worked there is that it's so convoluted to av…

> But my understanding from having interviewed people that worked there is that it's so convoluted to avoid GC pauses that you might as well be using C++.

I've done a very minimal amount of this... the gist is that you avoid GC pauses by avoiding allocation. This translates into reusing objects using pools, etc.... and the assorted complexities that come from having to explicitly manage object lifecycles. In critical applications you often want to avoid dynamic memory in C/C++, so it may not be all that different.

Re: Gerbil – An opinionated dialect of Scheme designed for systems programming

#68

Post by dleslie »

cat199 wrote: post #61
Johnny_Brahms wrote: post #54

Earlier quoted context omitted.

I feel that not standardising a low level FFI for r7rs large is a mistake. They should at least recommend some reasonably low level stuff that can be used to build abstractions.

Agree with the sentiment, but at the same time understand the rationale - FFI implies alot of GC/memory internal interfacing stuff, and to some extent expects a c-based implementation (not e.g. JVM,CLR,etc). If r7 & library interface are widely adopted, some flavors of FFI could evolve within the library/srfi process and gradually become defacto standards.. Probably hoping too much.. but in any event..

That didn't happen with R5RS, why would it happen now?

Face it, by refusing to be opinionated they ensured Scheme will remain a toy.

Re: Gerbil – An opinionated dialect of Scheme designed for systems programming

#70

Post by dleslie »

kovrik wrote: post #48
nextos wrote: post #46

Earlier quoted context omitted.

Yes, Chez & Stalin are the fastest in these benchmarks, which seems to match what the community usually answers when asked about quick implementations. Sadly Stalin is unmaintained. Its whole program optimization techniques were really advanced. I remember it even got my ivory-tower professors, who were big in the static analysis field, excited. Now, a tricky question. I'm mostly unfamiliar with Scheme for writing re…

> A problem with Scheme is excessive fragmentation. Yes. And not only that, but also the fact that each Scheme implementation is slightly (at best) different from all other implementations. I guess that is because Scheme standards are not that strict (for example, compare with Java specs)

They're fairly strict; if you code to RnRS and use only SRFIs then you'll find your code to be fairly portable... And nigh-useless.

The problem with the Scheme standards is that the committee refuses to be opinionated about implementation details, and so the standard is defined in terms of itself with little to no consideration for the environment in which Scheme will operate. In practical terms, this means that if you want to communicate with other libraries, or virtually any aspect of the system on which you're running, then you're venturing outside of the Scheme specification and into implementation-specific territory.

Scheme is a toy language. The implementations are not, but then they aren't Scheme so much as they are Scheme with useful extensions.

Post reply on HN