Slashdot Mirror

C++ damages the brain.

I wish Nokia provided some better alternatives to C++ for development on Symbian.

Java is not any better (and in many ways worse), and the S60 python port is nice, but it doesn't quite cut it for writing things like games in such limited hardware.

I would love to be able to build Symbian apps in Google's Go, it is an ideal language for secure, fast, lightweight programs for mobile apps.

For any other system to provide something as elegant and convenient as Plan 9's cpu(1) command.

It was Steve Bourne who was so used to Algol that he had a bunch of macros to make his C code look-algol-like.

But what is much worse is that the Algol leaked into his shell's grammar, which is a horrible undefined mess, and over the years instead of cleaning it up, people just have piled up more and more layers of crap.

Tom Duff did a wonderful job when he designed and built the rc shell for Plan 9, I have used it extensively, and it beats any other scripting language, every feature fits beautifully with the rest, it is very powerful yet very simple and is easy to learn the whole language inside out. It is very good at helping you glue specialized tools and making the Unix tool philosophy shine in ways that are unimaginable with any other scripting language.

It was Steve Bourne who was so used to Algol that he had a bunch of macros to make his C code look-algol-like.

But what is much worse is that the Algol leaked into his shell's grammar, which is a horrible undefined mess, and over the years instead of cleaning it up, people just have piled up more and more layers of crap.

Tom Duff did a wonderful job when he designed and built the rc shell for Plan 9, I have used it extensively, and it beats any other scripting language, every feature fits beautifully with the rest, it is very powerful yet very simple and is easy to learn the whole language inside out. It is very good at helping you glue specialized tools and making the Unix tool philosophy shine in ways that are unimaginable with any other scripting language.

We have better shells now, that there are people still using bourne-style shells is rather sad, and bash in particular is a hideous abomination.

Also, python and even perl can't come anywhere near the elegant expressive power of shell pipelines.

I'm sure it is too minimalistic for you, but I have friends using it in their companies intranets: werc.

It is implementing the rc shell and is very simple and designed for extremely lazy people like me that wants to do as little work as possible.

I'm sure it is too minimalistic for you, but I have friends using it in their companies intranets: werc.

It is implementing the rc shell and is very simple and designed for extremely lazy people like me that wants to do as little work as possible.

That is generally true, but there are exceptions, some badly broken supposedly "unix" systems like Aix and Solaris have ridiculously bloated and slow processes.

Fortunately most such abominations are either dead or dying fast, and being replaced by systems like Linux where processes are extremely cheap (so cheap that 'threads' are implemented as pretty much normal processes that happen to share memory, in the style of Plan 9's rfork(2)).

What blocks Africa from global participation are the tariffs, subsidies and other trade barriers in the 'developed' world; specially theinsane farm subsidies in Europe and the US.

Financial institutions on the other hand have little if any incentive to block Africa from global participation as Africa does not represent a threat to their business and actually represents an opportunity to expand.

> And this is the reason why you shouldn't use CGI scripts these days - the interface sucks and forking a process for each request is very expensive.

No it isn't. This is a common myth that just never dies.

I have built a whole web framework with the rc shell that does dozens of forks per request (calling commands like sed, awk, grep, echo, cat, etc), it is much faster than some php frameworks using fcgi, and certainly many magnitude order faster than perl or python takes to even start up.

You can do many thousands of forks per second on modern *nix systems even when running on a crappy virtual host or ancient hardware.

But note that I *statically* link all the binaries, when fork/exec-ing dynamically linked binaries things are considerably slower, but still much faster than what people assume.

But then, it doesn't use a database either and instead uses the file system to store and organize data, which also many claim is slower than a 'proper database', except that (as git and hg show) it is faster.

In short, the problem is not fork, bu ridiculously bloated and overly complex software.

> And this is the reason why you shouldn't use CGI scripts these days - the interface sucks and forking a process for each request is very expensive.

No it isn't. This is a common myth that just never dies.

I have built a whole web framework with the rc shell that does dozens of forks per request (calling commands like sed, awk, grep, echo, cat, etc), it is much faster than some php frameworks using fcgi, and certainly many magnitude order faster than perl or python takes to even start up.

You can do many thousands of forks per second on modern *nix systems even when running on a crappy virtual host or ancient hardware.

But note that I *statically* link all the binaries, when fork/exec-ing dynamically linked binaries things are considerably slower, but still much faster than what people assume.

But then, it doesn't use a database either and instead uses the file system to store and organize data, which also many claim is slower than a 'proper database', except that (as git and hg show) it is faster.

In short, the problem is not fork, bu ridiculously bloated and overly complex software.

> Don't ask me if it's right or wrong. I don't think it's that simple a question, with black and white answers for every case.

Actually it is pretty black and white and very simple: Freedom is about being able to do things that are unpopular and others don't approve of. Anything else is not freedom at all.

Or, as one of my favorite quotes much more eloquently put it:

"The only freedom which counts is the freedom to do what some other people think to be wrong. There is no point in demanding freedom to do that which all will applaud. All the so-called liberties or rights are things which have to be asserted against others who claim that if such things are to be allowed their own rights are infringed or their own liberties threatened. This is always true, even when we speak of the freedom to worship, of the right of free speech or association, or of public assembly. If we are to allow freedoms at all there will constantly be complaints that either the liberty itself or the way in which it is exercised is being abused, and, if it is a genuine freedom, these complaints will often be justified. There is no way of having a free society in which there is not abuse. Abuse is the very hallmark of liberty." -- Lord Chief Justice Halisham

> And this is the reason why you shouldn't use CGI scripts these days - the interface sucks and forking a process for each request is very expensive.

No it isn't. This is a common myth that just never dies.

I have built a whole web framework with the rc shell that does dozens of forks per request (calling commands like sed, awk, grep, echo, cat, etc), it is much faster than some php frameworks using fcgi, and certainly many magnitude order faster than perl or python takes to even start up.

You can do many thousands of forks per second on modern *nix systems even when running on a crappy virtual host or ancient hardware.

But note that I *statically* link all the binaries, when fork/exec-ing dynamically linked binaries things are considerably slower, but still much faster than what people assume.

But then, it doesn't use a database either and instead uses the file system to store and organize data, which also many claim is slower than a 'proper database', except that (as git and hg show) it is faster.

In short, the problem is not fork, bu ridiculously bloated and overly complex software.

> And this is the reason why you shouldn't use CGI scripts these days - the interface sucks and forking a process for each request is very expensive.

No it isn't. This is a common myth that just never dies.

I have built a whole web framework with the rc shell that does dozens of forks per request (calling commands like sed, awk, grep, echo, cat, etc), it is much faster than some php frameworks using fcgi, and certainly many magnitude order faster than perl or python takes to even start up.

You can do many thousands of forks per second on modern *nix systems even when running on a crappy virtual host or ancient hardware.

But note that I *statically* link all the binaries, when fork/exec-ing dynamically linked binaries things are considerably slower, but still much faster than what people assume.

But then, it doesn't use a database either and instead uses the file system to store and organize data, which also many claim is slower than a 'proper database', except that (as git and hg show) it is faster.

In short, the problem is not fork, bu ridiculously bloated and overly complex software.

So, what has Go brought to the table?

Go is designed with internal messaging capabilities, intended to simplify the creation of applications running on different nodes, and improve their performance.

"It's a way to try to address how to write concurrent software that's more robust, as opposed to using the old threading model of Java and others," Voss said.

...

In this regard, Go offers "a new programming paradigm" that makes it easier to solve a wide variety of programming problems by simplifying many types of parallel processing.

No, Go doesn't bring anything new to the concurrency table. The two things I've seen about Go concurrency that are regarded as special are M:N/"green" threads and CSP-style channels.

M:N threading is an implementation detail of a language runtime. Whereas the standard library of a language might specify how threads are available to client applications (programs written in the language), it's best left to the implementation (runtime or compiler) to decide how to translate those threads onto the machine. Some implementations might want to focus on scalable, high-performance threading, and so they'd choose M:N. Some others might emphasize simplicity, and map language threads directly to OS threads. What Go has done is standardized this implementation detail into the language specification. (I don't think that's a good idea, but that's a matter of taste.) Other language implementations offer M:N threading, including GHC and (I think) Erlang.

On channels: they're cool. I love them. But there's a lot of prior art here, and many languages have great CSP-style channel libraries written for them that offer the same great flavor of relatively safe message passing and alternation between sets of channels:

• Communicating Sequential Processes for Java (JCSP)
• C++CSP2
• CHP: Communicating Haskell Processes
• python-csp
• Plan 9 libthread for C (and not just Plan 9, thanks to plan9port)
• and my own: Calispel for Common Lisp

In summary, I just don't get what the buzz with Go is about, besides that it's Google's very own language.

until so called 'intellectual property' is exposed for the oxymoron that it is.

The problem some people, including the fags using proportional fonts, have is that they are writing C when they would be happier writing CSS.

Like this particular fag? (Yes, those fonts are proportional).

that the patent system is a monster completely out of control.

We have gone from a system where (supposedly) the best products at the lowest price were successful, to one where the company with the best lawyers can shut down anyone else and where serving consumers is a lower and lower priority because so called 'intellectual property' can be used to limit their options.

The programming environments by Rob Pike use proportional fonts by default. Both Acme (also used by Dennis Ritchie) and Rob's previous text editor Sam (still used by Ken Thompson, Brian Kernighan and Bjarne Stroustrup).

The rio terminal windows also use proportional fonts.

At first (like many other things from the Plan 9 world) the lack of precise control about how everything spaced can be a bit frustrating, but once you learn to stop worrying about it, it can be rather pleasant and liberating to use (good) proportional fonts for writing code.

The programming environments by Rob Pike use proportional fonts by default. Both Acme (also used by Dennis Ritchie) and Rob's previous text editor Sam (still used by Ken Thompson, Brian Kernighan and Bjarne Stroustrup).

The rio terminal windows also use proportional fonts.

At first (like many other things from the Plan 9 world) the lack of precise control about how everything spaced can be a bit frustrating, but once you learn to stop worrying about it, it can be rather pleasant and liberating to use (good) proportional fonts for writing code.

You're not alone.

Yep, this one sounds like it might be even as tame as your average climategate discussion.

If there's one thing geeks are good at, it's picking a postition and sticking to it no matter what. No matter what side is taken, the geek can provide solid -- or at least superficially solid -- evidence to support his take and can continue to argue it, indefinitely if so required, regardless of the course of the argument.

When it comes to topics with any level of subjectivity or doubt, geek arguments become farcical. Witness the conflicting positions on various technologies such as IPv6 or topics like net neutrality or even evolution. A thread around here on gender issues is like a console fanboy war, just with better grammar and spelling.

To return to the topic, my own personal opinion is that the amount of women in computer science has more to do with cultural reasons than biological ones. My undergraduate mathematics course has a gender ratio of about 50/50, and indeed has for several years. Given that computer science is mathematics, I'm then inclined to believe that there are others factors than biology at play.

I completely agree.

However, that doesn't mean I think Quartz or whatever Windows uses is better. Some of the alternatives that are miles better, but unfortunately didn't catch on simply because they were a bit too late include Sun's NeWS and Plan 9's /dev/draw.

1. Don't be fucking stupid.

I'm not.

XML needs replacing. I know you won't listen to me alone when I say that, however, but fortunately you don't have to. There's a replacement that you can read about here.

My own document format is a little less complex than YAML, but YAML is more thoroughly developed, and is intended to do more things.

2. It's XML. They can document it as well as they like; but said documentation is as long as I knew it was going to be. Anything written in XML is unavoidably difficult to read, by design. It isn't a format with which transparency is really possible.

3. If you're afraid of complex things, you really shouldn't be on the internet. I imagine you'd be happy living in a tent on the side of the mountain, but us societal folk like our technology.

This is garbage. The Internet's original application protocols are all (with the single exception of FTP) text-based.

I love technology, too. I just prefer it to be well designed. That means a couple of things.

a) That it's text based, and more purely text-based than XML. It doesn't need, at a fundamental level, to be anything other than text based, either. When I say that, I'm not saying that there shouldn't be support for multimedia; but protocols should be written in a purely textual way.

b) That it complies, broadly speaking, with what is written here.

Complexity also *is* a bad thing, yes. There was a time when computer programmers actually understood that. I'm not sure what's happened in the intervening few decades.

The waves are persistent, accessible to anyone who's added to them, and include the ability to track changes, so they ultimately work quite well as a medium for the non-tactical parts of an RPG.

IRC channels are entirely persistent. I regularly visit one that has existed for nearly 15 years now.

In terms of the ability to track changes, I'm assuming they mean something like CVS, but IRC can use date-stamped log files, as well.

IRC isn't less popular because it was a bad protocol. It's become somewhat less popular because corporations have marketed proprietary alternatives, and people have believed the claims about them supposedly being more capable, when in reality they aren't at all.

6. Another prejudice! Wooo! Some people would be ashamed to let the world know that they think that one, single word typed by one, single marketing droid determines the overall quality of the finished product... but not you! Fuck in-depth analysis! All you need is ONE WORD!

It might be a prejudice, but it's an accurate one. Go and find me a single case of the word, "richness," having been used, where the marketing droid in question actually bothers to define exactly what the word means. They never do. It's there purely to make what they're hyping sound good.

I really, really hope I was trolled, because knowing I wasted a bit of my time makes me feel MUCH better than knowing that someone as bitter and backwards as you is allowed to roam the internet.

I am in the ongoing process of attempting to learn to control my temper, and to avoid allowing quite so much bitterness to creep into what I write. Unfortunately, I didn't succeed in doing that in my last post. I'm hoping this one is a bit more clear.

The Inferno Documentation Archive is a good place, specially:

• A Descent into Limbo by Brian Kernighan.
• The Limbo Programming Language by Dennis M. Ritchie.

The Inferno Documentation Archive is a good place, specially:

• A Descent into Limbo by Brian Kernighan.
• The Limbo Programming Language by Dennis M. Ritchie.

The Inferno Documentation Archive is a good place, specially:

• A Descent into Limbo by Brian Kernighan.
• The Limbo Programming Language by Dennis M. Ritchie.

http://gsoc.cat-v.org/projects/kencc/

How to Use the Plan 9 C Compiler (html ps pdf)
Rob Pike
The starting point for C programming under Plan 9.

Plan 9 C Compilers (html ps pdf)
Ken Thompson
The design and some internals of the compiler suite.

Man page

We did that already

http://gsoc.cat-v.org/projects/kencc/

Someone on the GSoc is hoping to do an OpenBSD 9p kernel extension. If they get it going then I'll be giving it a go (read only OpenBSD that is).

9p abstracts loads of things away for you so you could, for instance, use postgresql as your "file system" and boot from that, I have the code to do that bit already, although it's not listed here yet.