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

The state of low-level system programming

erik-poupaert.blogspot.com

Post reply on HN
Print view View original

51–60 of 62 posts

Re: The state of low-level system programming

#51

Post by vq »

eropple wrote: post #39
frujka wrote: post #36

it's probably an interesting read except that being hosted on google's blogspot means it only display blank pages due to content being embedded in some javascript shenanigans. Even a screenshot would be better than this. Please move on to some actual html website that just works or rehost the content elsewhere before posting it here. Thanks.

I used to be one of These Guys who never used JavaScript, too, but honestly? It's 2012 and JavaScript is a thing pretty much everywhere worth targeting. Demanding that somebody cater to your microsegment is a little much.

Although I'm the kind of guy who usually have JS disabled I could be made to see your point. But this page is actually a good example of why I run with JS disabled. It magically positioned links and boxes over the scrolling bar and caused my initial attempt at scrolling down to navigate away from the page.

Disabling JS usually have the effect of doing away with such nonsense but here that is no option.

This time it was worth the hassle since it was an interesting article, but I definitely prefer it when JS is optional.

Re: The state of low-level system programming

#52

Post by sublimit »

frujka wrote: post #36

it's probably an interesting read except that being hosted on google's blogspot means it only display blank pages due to content being embedded in some javascript shenanigans. Even a screenshot would be better than this. Please move on to some actual html website that just works or rehost the content elsewhere before posting it here. Thanks.

My attempts to read this on my phone were futile. Every time I tried to scroll, it just jumped back to the top immediately.

Re: The state of low-level system programming

#53

Post by guard-of-terra »

dschiptsov wrote: post #38

This is called FFI.) And yes, a language with which you cannot dload and call any shared library you wish is, how to say, handicapped language. NodeJS, Java to name a few. Look what they do due to inability to call, say, libpq.so.) But of course, re-monkey-patching everything from scratch by amateurs coders is much better idea. And, you know, you could create an entire "standard" with hundreds of pages of specificati…

I'm so happy Java can't load libpq you won't believe. Because it means that Postgresql API gets reimplemented as a crispy JVM code that never crashes my JVM. If we would live in the world where a Java program would use libpq and libxml and libldap and whatever, it would be so much less stable, introspective and consistent that it won't be Java anymore. It would be a particularly ugly kind of Python.

And yes, it would crash when you use threads. Since all those C libraries pretend that threads don't matter. Guess what, our Java program has 500 threads and feels fine.

Re: The state of low-level system programming

#54

Post by martincmartin »

For example, Java and C# cannot walk like a duck, not even if that is what it would take to save themselves from drowning. Therefore, they are absolutely unsuitable as system languages.

Hadoop held the world record for sorting a Terrabyte for a while. If sorting large amounts of data as fast as possible isn't a system's programming task, then I'm a three-headed monkey.

Re: The state of low-level system programming

#55

Post by eswangren »

martincmartin wrote: post #54

For example, Java and C# cannot walk like a duck, not even if that is what it would take to save themselves from drowning. Therefore, they are absolutely unsuitable as system languages. Hadoop held the world record for sorting a Terrabyte for a while. If sorting large amounts of data as fast as possible isn't a system's programming task, then I'm a three-headed monkey.

Yes, because "must sort quickly" is the only important requirement in a systems level language.

Re: The state of low-level system programming

#56

Post by Yttrill »

dschiptsov wrote: post #38

This is called FFI.) And yes, a language with which you cannot dload and call any shared library you wish is, how to say, handicapped language. NodeJS, Java to name a few. Look what they do due to inability to call, say, libpq.so.) But of course, re-monkey-patching everything from scratch by amateurs coders is much better idea. And, you know, you could create an entire "standard" with hundreds of pages of specificati…

Au contrare it is C which is handicapped.

How handicapped is C++ considering it subsumes C, can use C right at the source level, has an inline FFI, and yet C++ libraries can't be called by C because C++ provides type-safe linkage.

Advanced languages are advanced because they improve on C and this inevitably means they must go beyond C. This is why such languages require setting up an environment, usually by providing main().

Even if you could set up an environment with a C function call, which is trivially achieved by replacing main with mymain(), you would simply be starting a foreign environment, not providing a library of functions which could be individually called by C.

My system Felix (http://felix-lang.org) is specifically designed to live with the compromises of C/C++ compatibility, but you still cannot put arbitrary Felix code in C callable functions because Felix provides an advanced environment supporting, for example, fibres with channels. Fibres are scheduled by returning control to a scheduler so they cannot be nested inside a function which puts its return address on the machine stack.

If you Felix write code without using features requiring advanced support that code can be made into a C callable library (both static and dynamic linking is supported).

Felix is probably better at C/C++ integration than any other language except C++.

Re: The state of low-level system programming

#57

Post by doublec »

erichocean wrote: post #47
doublec wrote: post #7

Earlier quoted context omitted.

It's a pity ATS doesn't get more attention in the "Systems programming language" field. It can call into C, be called from C, provides a powerful type system, and can be used to write very low level code. I've written a few posts about how ATS can interact with C on my weblog here: http://www.bluishcoder.co.nz/tags/ats/

I like reading your blog posts on ATS, but I don't think I could use it effectively. I've had much better luck with exhaustive testing with Klee and related libraries (e.g. for testing multi-threaded programs). For whatever reason, they map better to how I think about problems, and I've found it easier to develop new code that is testable within those constraints.

If you start off treating ATS like an ML variant interfacing with C without using any of the type annotations for safety you can go far. Then you can tighten the types up for safety as you get more experienced or find you need it.

You could write tests as needed and when a test fails write types that make that failure as close to compile time as possible.

Another approach is to just write C code, either embedded in ATS files or in C files that are linked into ATS. Then slowly convert C to ATS as you feel comfortable.

Re: The state of low-level system programming

#58

Post by Yttrill »

TheCondor wrote: post #22
sparkie wrote: post #20

Earlier quoted context omitted.

The need for C isn't so much restricted by the operating system, but by the hardware manufacturers. The simple fact is that C is the defacto choice of language for hardware vendors to ship a compiler for, and that doesn't look to change any time. It's a standard that can't be avoided, unless we can work cooperatively with enough major vendors to change this.

There is C specific hardware?!? This is a myth and part of the vicious circle here. I'm not a C hater by any means but the reason hardware vendors have historically included it is because there are free compilers that are nearly C enough that they can include and they have to include something. C is just a portable assembly, you can almost write a simplistic compiler in pure yacc and more than a couple of these C com…

Of course there is C specific hardware!

X86 provided efficient call/return protocol instructions including display management, specifically targeting Pascal/Modula style languages. Microsoft Windows 3.1 even mandated this calling protocol. However old style C didn't use this API because it doesn't work with varargs and C doesn't have nested functions.

Instead Intel observed real code and optimised their instruction set to speed it up, locking everyone into lame languages like C. Attempts by Intel to break from this, for example with x64, have failed (x64 has two stacks).

Similarly segmented architectures, which implement extension of the Harvard machine model, have been largely unsupported in favour of linear addressing von Neumann machines, primarily because that's what C and Unix use. Interesting to see Microsoft adapt their OS designs based on this trend.

To support more advanced features in a language often requires only a few very low level primitives. This is why Linux kernel doesn't need much assembler, to do things like stack swapping. Control exchange is one of those things completely missing from C.

Re: The state of low-level system programming

#59

Post by dschiptsov »

pjscott wrote: post #40
dschiptsov wrote: post #38

This is called FFI.) And yes, a language with which you cannot dload and call any shared library you wish is, how to say, handicapped language. NodeJS, Java to name a few. Look what they do due to inability to call, say, libpq.so.) But of course, re-monkey-patching everything from scratch by amateurs coders is much better idea. And, you know, you could create an entire "standard" with hundreds of pages of specificati…

I believe his thesis was actually that most languages are handicapped because they can not easily be called via the usual "load a .so file and call a function" ABI. Java, for instance, would be a more useful language to me if I could easily create Python bindings for useful Java libraries like Lucene, without needing to use something like Jython that runs on the JVM.

The confusion arises when some language developers decide to ignore or break existing ABI for a particular platform.

There are general ways to call procedures - there machine instructions for this. ABI defines how exactly parameters and return values should be passed - using, registers or stack or both.

As long as you follow the rules there is no difficulty in calling everything you wish.

The whole idea of JVM as something disconnected from reality^W OS and hardware is simply wrong, and all the confusion is the consequence of that premature decision.

Of course, slogan "you don't have to know" always wins.

Re: The state of low-level system programming

#60

Post by dschiptsov »

guard-of-terra wrote: post #53
dschiptsov wrote: post #38

This is called FFI.) And yes, a language with which you cannot dload and call any shared library you wish is, how to say, handicapped language. NodeJS, Java to name a few. Look what they do due to inability to call, say, libpq.so.) But of course, re-monkey-patching everything from scratch by amateurs coders is much better idea. And, you know, you could create an entire "standard" with hundreds of pages of specificati…

I'm so happy Java can't load libpq you won't believe. Because it means that Postgresql API gets reimplemented as a crispy JVM code that never crashes my JVM. If we would live in the world where a Java program would use libpq and libxml and libldap and whatever, it would be so much less stable, introspective and consistent that it won't be Java anymore. It would be a particularly ugly kind of Python. And yes, it would…

Technically, an instance of JVM is mere a user process, which, by definition, must obey "laws" for user processes. This could be end of story - the idea that something "reliable" could be implemented as a single user level process is, well, naive.

btw, you still must call libc.so and libpthread.so

As for pthreads, guess what, they are also bad decision, as long as they are not isolated as processes supposed to be, and crash of one thread messes up rest 499.

People who did some research, like developers of Erlang, found that neither one-process model or threaded-threaded process model is even applicable when you need a reliable system.

So, again, jvm.exe is mere yet another .exe.)

Post reply on HN