lubutu

I'm not sure that's true. Though it obviously depends more on the programmer themself, the semantics of a language can make it easier, at least, to write higher quality code. For example, bounds checking removes a whole class of bugs (probably the most common in C) from the equation. I disagree that this effect could be described as "marginal".

I suppose what I'm trying to say is that for me it wasn't that there was "something I wanted to do and I used a programming language", but rather that I wanted to use a programming language so I found something to do. For me it was about the (self-guided) achievements and challenges: I wasn't "hacking a way to a solution," and would often return to the same problem and solve it again and again, never "falling back to really hacky solutions to get things done." It's a bit fuzzy (things do get done either way), but I think there is a distinction in approach.

I think the way that one learns to program says a lot about the programmer. I, like many people, started with games and websites, but although I understood conditionals and loops, and even glimpsed OO, I wasn't very good. My software sucked, I got bored of it, I slowed to a stall.

A couple of years later I picked up Python, and instead of trying to make games or websites, I worked on stupid little puzzles. Pointless things, really. After a lot of work I built a Befunge interpreter (probably my own "tipping point"). And many useless puzzles later, I somehow wound up a genuine computer scientist.

People always talk about "getting things done". I just worked on meaningless puzzles, and that was the best thing I could have done. Anecdotally, to me it was about achievements and challenges. If you grow tired of the drive to "get things done", make something pointless.

Wayland may improve the speed of compositing on the Linux desktop, but it's very unlikely to improve consistency or reliability. Wayland applications draw their own window decorations (rather than a window manager), which obviously doesn't encourage consistency. And last I heard, when a Wayland application hangs, its window will become completely immovable. No, really.

'Conjecture' is a verb as well as a noun. But I'll admit it sounds weird — by French inflection one would expect "I conject", which seems to be obsolete...

The docopt documentation suggests that a lone "--", signifying the end of the command-line flags, is only supported if "[--]" is added explicitly to the syntax string. In my opinion this is a mistake, and may even break POSIX XBD §12 [1]. I would seriously recommend the authors support it by default.

[1]: http://pubs.opengroup.org/onlinepubs/009604499/basedefs/xbd_...

If anyone's interested, a while back I put together a table of commands available in various versions of ed, from 1st edition UNIX up to POSIX, as well as sam. It's largely academic, but I did find it interesting how features crept in.

http://lubutu.com/misc/ed-languages

You believe that text as a universal interface isn't a good design principle because it doesn't reflect how other UIs, built upon completely different principles, behave? Is it not possible that it remains a good principle that WIMP GUIs simply do not adhere to? (Also related, "everything is a file.")

I would argue that very few of today's programmers really follow the Unix philosophy, but those I know who do would likely agree that our tools should be reassessed. But you seem to be conflating the idea of reassessing our tools and reassessing our principles. In my opinion the core principles [1] are eternal, however transient the programs themselves.

[1]: http://en.wikipedia.org/wiki/Unix_philosophy

You're looking for ctags or cscope, the first of which is mentioned in the blog. As for code analysis and warnings, surely that's a property of the compiler being used?

A slight tangent, but dmenu-4.5 uses token matching, which allows you to search somewhat fuzzily: "foo rb" will match "foobarbaz". How it looks compared to Alfred and co. is a matter of one's aesthetic...

Disclosure: I'm a dmenu developer.

If all the non-volatile in-process data structures have the same semantics, with type annotations etc, one can imagine those structures being just as transparent and ready for inspection as modern filesystems are.

I don't want to be mean, but do you really feel the need to update us with who you've shown this to, and who liked whose tweet, every 5 minutes? The signal to noise ratio in your comment is pretty low... In future could you keep it a little more concise, and less update-happy? Thanks.

As I said, Coraid uses it for SANs. The question you're asking is equivalent to "Windows can play games, why doesn't Linux have any games?" Some of the things you might do with Unix Plan 9 cannot do. However, the reverse is also true.

You seem to seem to be looking for "an alternative to Unix." If that is the case, Plan 9 probably isn't what you're looking for. It is, however, useful in ways that Unix is not. It probably won't replace your specific Unix needs, though it largely replaces mine. Hope that clears that up.

It very much depends on what you want to do. But yes, you can certainly do things with Plan 9. Ruling out Plan 9 because it does run a certain language, or doesn't run Postgres, is like ruling out Linux because it can't run Microsoft Office. It is intended for a different purpose. Also note that Coraid use Plan 9 in a lot of their systems, to do real work (specifically SANs).

Edit: Also, Plan 9 has HTTP servers, CIFS support, central authentication (factotum), etc. I suggest you Google them.

I think I agree with you, that it's (for those who actually do like Unix) a discoverability problem, but then I think that can be helped by simply reducing the number of command line tools. If you have a small set of tools you know extremely well, the pipelines necessary become immediately obvious whenever you encounter a task... I think part of the problem is that many modern Unix commands are non-orthogonal. It would be interesting to look at ways to improve the discoverability of manpages, though, or at least have some kind of well-structured "if you want to X, you could use Y" index.

I agree that programmers should learn the 'Unix philosophy', but lumping Perl in there doesn't make much sense. Perl is just a scripting language, like Python or Ruby, and one of which I'm not particularly fond. It does not espouse 'one tool, one task' — "those days are dead and gone and the eulogy was delivered by Perl." Definitely learn shell, awk, sed, and co. But avoiding Perl won't do any harm.

That API is actually quite well designed, thanks. I don't really use Python anymore, but if I did I'd really consider using it. Although "bake" should really be "curry".

I agree. In Go break is the default, and there's an explicit 'fallthrough' statement.

Sudo has authentication timeouts built in, so you don't have to type in your password (your password, not root's) every time you want to run an administrative program. Also, the fact that you have to sudo is one of the reasons why Unix is more secure than the Windows "administrator by default" approach.

As for your last point, you're complaining about nano. It would be perfectly possible for an editor to sudo when writing to disk.

As a vegetarian growing up in England, I remember having non-packed lunch at primary school only once: I was given a hamburger, and told to take the burger out. At the time I just took it in my stride, but on reflection...

I don't quite understand what the difference is between Light Table's modes and IDEs' plugins. Domain-specific components are exactly what make IDEs 'integrated'; without them they are generalised editors. But there is absolutely no difference, as far as I can tell, between Light Table's new SQL mode and an SQL IDE plugin.

I'm personally much more fond of the Unix 'tool approach', in which there are no task-specific modes or plugins, but tools can still be composed ad hoc, as in Plan 9's Acme.

Brainfuck is almost 20 years old, and extremely well-known. Is this really worth a submission?

There is no reason to use clear during a terminal session. ^L (Ctrl-L) does this for you in one key press, without needing to clear your input or fill your history.

glibc is not the only libc in existence. It is reasonable to ask that applications support systems other than those developed by GNU.

"cwd[] should be MAXPATHLEN bytes long"

This is actually a common mistake — PATH_MAX and the like are not guaranteed to be defined. In fact, in POSIX it is literally impossible to ever know whether your buffer is long enough. Your best bet is,

  #ifdef PATH_MAX
  char cwd[PATH_MAX];
  long len = sizeof cwd;
  #else
  char *cwd;
  long len;
  if((len = pathconf(".", _PC_PATH_MAX)) < 0)
    len = 8192; /* some arbitrary value */
  cwd = malloc(len);
  #endif

This is probably one of the ugliest parts of POSIX.

This post literally makes no sense. I skipped the beginning diatribe, but the bullet points as to why functional programming is an "abomination" are completely false.

FP is not bound to threaded concurrency; map-reduce is even named after the concepts from FP. Data structures can be modified by multiple threads, deterministically. Concurrency in FP is strictly deterministic, unlike most models of concurrent computation. Point 3 actually makes no sense; it's clear the author doesn't actually know any functional languages.

To be honest, the entire article is meaningless. I'm flagging it.

I'm sorry, did you read mine? "If you want to handle NUL, simply use length-annotated slices instead of C-style NUL-terminated strings."

Seriously though, using 0xFF as a UTF-8 string terminator would be a terrible mistake.

No. NUL is backwards-compatible with ASCII, and is used everywhere. Choosing some arbitrary invalid UTF-8 byte for use as a terminator would be a terrible decision. If you want to handle NUL, simply use length-annotated slices instead of C-style NUL-terminated strings. Anything else is completely wrong.

This is a great resource; it was extremely useful when I was writing a UTF-8 library myself. I found the UTF-8 stress test file is particularly useful to run tests against: http://www.cl.cam.ac.uk/~mgk25/ucs/examples/UTF-8-test.txt