hp

I don't see the problem with having two protocols on one socket, as long as its defined how it works (how to switch over). HTTP for example supports switching to websocket.

The spec has always said it was informal and needed more work, for at least a decade now. Many people have implemented dbus and rewriting the spec hasn't been enough of a priority for any of them to do it. To me that says that while many are willing to say "it should be better" (including me) none of them are willing to say "and it's important enough to spend my next few months on" (including me). But the beauty is that at any time someone is free to change that.

I think it's wrong to say something is must-have when it obviously by existence proof has not been must-have. And in fact a lot of tech that had the must-have failed. Say CORBA, which certainly had specs. They were just specs that specified the wrong thing. I'd rather have the (approximate, good enough) right thing with an informal but good enough spec (to a motivated reader giving it a chance), than pay a bunch of committee people to write down a design that failed to solve the requirements.

I did stop, many years ago, in part because I was tired of this sort of thread. People who don't know the requirements and don't bother to learn anything go on ill-informed rants about other people's work. Hey, it's no longer officially my problem. But the people who are still working on improving the software still don't deserve the abuse.

Speed wasn't the right design goal for a mechanism used mostly for control purposes that simply didn't have to be fast. Least-common-denominator flexible implementation was the most important thing (threads or main loop, no dependencies, etc) in order to be adopted. And then validation was required to use it on system contexts not only trusted in-user-session contexts. It also had to swap in for both DCOP (KDE) and CORBA (GNOME). These were the choices that made it viable and why it became widely used.

Many years later people decided it would be nice to have performance too so they reimplemented with more assumptions that didn't used to be safe, and did the kdbus work. The result is still compatible with the original protocol because it was always possible to make a fast implementation.

This is how open source works. People do what they care about. When speed came to the top of the list people did it.

Adoption speaks for itself. Things are adopted when they are a viable solution. Others thought speed was the key and they were wrong; dbus was adopted precisely because it focused elsewhere. But speed wasn't precluded by the design and when people cared they solved it.

I created dbus and wrote the original spec. There is a nul byte first because some platforms require that to send credentials. Then a plain text protocol modeled on SASL for authentication. After that the binary message protocol begins.

Sorry if others could have done it better, but they didn't, and many tried. My way works and exists.

Here is the full context about the auth protocol in the spec:

Authentication Protocol

Before the flow of messages begins, two applications must authenticate. A simple plain-text protocol is used for authentication; this protocol is a SASL profile, and maps fairly directly from the SASL specification. The message encoding is NOT used here, only plain text messages.

In examples, "C:" and "S:" indicate lines sent by the client and server respectively.

Protocol Overview

The protocol is a line-based protocol, where each line ends with \r\n. Each line begins with an all-caps ASCII command name containing only the character range [A-Z_], a space, then any arguments for the command, then the \r\n ending the line. The protocol is case-sensitive. All bytes must be in the ASCII character set. Commands from the client to the server are as follows:

No. he's confusing the auth protocol with the dbus protocol.

Yes, there's an auth protocol before the actual dbus protocol - there are two protocols in the spec. I think that's what you are missing.

Perhaps it's confusing but slow down and understand the tech before criticizing. It is not in fact an ASCII-only binary protocol. Other engineers do sometimes know what they are doing.

I think people who haven't hacked on making nice UIs for system features don't understand what problems these things solve. But people who have do, and that's why they code them.

Is there a simpler, less-engineered way? Probably, in the truism sense that all software sucks. But then, anyone could have coded this better way and made it work, and they didn't. So the current work has the advantage that somebody did it and it exists. I'll take that.

Knowing the problems solved here I actually think the current stuff is pretty good. Not flawless -it's software - but good. It does pretty much work. Go use 15 year old Linux if you want to replace nostalgic memories with a good dose of how much it sucked :-p

No. It means everything is on-wire essentially the same as it would be in memory. Read the spec: http://dbus.freedesktop.org/doc/dbus-specification.html

This article is essentially "I didn't understand something after spending 15 minutes (or so) on it, and here are my criticisms of how I speculate this might work."

You know, fair enough. But if you as the reader want actual knowledge you can read the docs and code yourself and spend more than 15 minutes (or however long it was, but not long enough to have accurate info for sure).

There are hundreds of people and packages using dbus after many similar technologies were tried and didn't catch on. A curious person might ask why.

It isn't ASCII only, and I don't even see where the author of this article got that idea. Read the spec instead of the article and you'll learn more: http://dbus.freedesktop.org/doc/dbus-specification.html

Scala doesn't have operator overloading btw. It just doesn't restrict method names very much. This is very different from how C++ treats operators as special cases.

If you give your methods bad names, it really is not the language's fault. You can probably find a way to make a bad API even if you are limited to a-zA-Z0-9 ...

If a library has an inscrutable set of method names blame the lib not the language.

The current direction we're hacking on is definitely toward shared code between Eclipse and other tools and editors.

the sbt point is really outdated; sbt 0.13 only ever requires you to use "foo := bar" (assign bar to foo), though one might choose to use convenience operators such as "foo += bar" (append bar to foo). sbt's syntax has been cleaned up nicely and now it has very clean syntax.

https://github.com/scala/async is the syntactic sugar to write sequential nonblocking code in Scala (no callbacks). Though functional-style code works well also if you know it.

Scala has an `async`/`await` feature (like C#) now, which hides the Future ceremony and gives sequential syntax. https://github.com/scala/async

I guess this does still require the `await` word, but I think it's good to have a magic word for "suspend execution now" so you can see where it's happening.

An OS thread still has to block on blocking IO calls somewhere, of course. There's no "syntactic" fix for that on the JVM - you have to actually port the blocking IO to nonblocking IO - AFAIK nobody can magically fix JDBC to be nonblocking from outside JDBC.

VC funding is usually a decision to "go big or go home" on a timeframe, while bootstrapping allows you to continue indefinitely at any scale once revenues cover costs. Both have risks but the VC model is explicitly to spend at unsustainable levels in order to try to get big fast. That's kind of the whole point of VC. It isn't wrong or selling out, but you have to know what you're getting into (as founder, employee, or customer). If you spend way ahead of revenue to grow fast, and you don't go big, then you usually go home.

the config has arrays, it is a json superset. foo.bar = [1, 1]

Steve Jobs made the point nicely:

"This stuff doesn’t change the world. It really doesn’t … Technologies can make it easier, can let us touch people we might not otherwise. But it’s a disservice to constantly put things in a radical new light that it’s going to change everything. Things don’t have to change the world to be important."

Using flags in your visual design can be tempting but in my experience it's a bad idea. The problem is that certain flags force you to "take sides" in political disputes that you likely aren't aware of and don't understand. You'll inadvertently make one side very angry with you, and you won't even really know what political statement you accidentally made.

It's OK if you stick to flags you know but if you start trying to have a list of all flags, there's no way to do that without making various groups angry.

I don't doubt that there's a "right" answer to all disputes over flags but do you really know what all the disputes are and want to arbitrate them as part of developing your software ...

Deliberately not digging up specific disputes because the whole point is, if you have to ask what they are or if you start debating them case by case, maybe this wasn't a can of worms that needed opening.

(also, the last time I encountered this was long enough ago that I'm sure the relevant examples have changed, and I never understood them well to begin with. But it was clear that flags poked more than one political group in the eye.)

Insurance can't work if either all or none of your customers are going to file a claim, because the premise of insurance is that those who don't file claims pay for those who do. This insurance would have to charge a premium that would cover the "everyone files a claim" case, which means people would be paying N dollars in order to have a chance of getting their N dollars back. Not a good deal ;-)

It makes total sense to omit comments, because JSON is optimized for machine-readability and interoperability (simple spec, simple implementation, no extension mechanism, fast to parse). Putting comments in would compromise it for that purpose.

JSON isn't a great config file format, if your config file is meant to be human-edited. But the solution is simple; use a format designed for human editing.

Config files need UI design too.

During Akka and Play 2.0 development, we approached this by starting from the hand-rolled parsers found in Akka 1.2 and Play 1.2 (both had ad-hoc parsers to support a "pretty" config file format). We took the aesthetic preferences of the hand-rolled parsers seriously, and came up with HOCON: https://github.com/typesafehub/config (scroll down to "JSON Superset"), https://github.com/typesafehub/config/blob/master/HOCON.md

The HOCON format is a superset of JSON and also happens to be mostly compatible with the Play and Akka 1.2 ad hoc parsers (which were independently developed, so two data points on what people wanted).

HOCON is roughly similar to YAML in complexity. Like YAML the spec is pretty long ( http://www.yaml.org/spec/1.2/spec.html ). And the Typesafe Config and SnakeYAML jars have pretty comparable amounts of bytecode in them.

HOCON or YAML would be terrible formats for an API or something like that, and they're painful to implement, but I strongly prefer them to JSON for human-maintained configuration.

Anyway, I think the genius of JSON was its focus on machine interoperability rather than trying to do everything, that's why it works so well for machine interoperability. But it doesn't mean you have to use it for everything.

I agree with basically everything Elijah has to say here for example: http://people.gnome.org/~newren/eg/git-eg-differences.html

I found that the syntax _was_ the hard part of git. That and the often-terrible man pages. Both docs and syntax are inconsistent, verging on random, and full of irrelevant details. It's pretty hard to figure out the actual concepts beneath all the noise and misdirection.

the git vs EasyGit diff basically summarizes what I'd change about git.

EasyGit, single script, very well thought out, longstanding tested project, doesn't "conflict with" or conceal the underlying git just fixes up the UI.

http://people.gnome.org/~newren/eg/ https://github.com/blog/333-easy-git

here is a great post from Owen Taylor in 1999 after this idea was repeatedly raised for the "g" stack on Linux:

http://mail.gnome.org/archives/gnome-list/1999-December/msg0...

it kept coming up, too: http://mail.gnome.org/archives/gtk-devel-list/2001-February/...

Here is what GLib 2.0 ended up with instead, which works well: http://developer.gnome.org/glib/2.31/glib-Error-Reporting.ht...

as someone who has used libpng I'd describe it as an example of why this is a terrible idea.

The Scala community is more of a blend on this front. It has FP aficionados, but it's also in production use and has commercial contributors focusing on practical issues. If Scala continues to gain popularity, it will probably continue to get more of a practical focus (there are only so many FP geeks in the world).

The other thing with Scala is that it compiles to bytecode; once compiled, it's just Java. And you can always use any Java library. So there's that base of a very solid JVM runtime and very solid ecosystem of libraries that's always there.

The bug in this post is thinking that if you have someone willing to contribute feature X to an open source project, they were also available to contribute feature Y.

Open source patches are all itch-scratchings. For Scala macros, it's a researcher at EPFL, I believe. I don't think you could write a thesis about fixing bugs in the IDE. So this contributor was not available to submit IDE bugfixes; they _were_ available to submit macros.

It's the same for other contributors. Someone building an app on Scala may be available to submit a fix for some scalability issue they are hitting in production; they will not be available to work on macros, or on IDE bugfixes.

Open source projects get the fixes they get. You can't act like the priorities are set by some central product manager.

So I think it's just not correct to argue that "the priorities are wrong, why are they doing this instead of that, etc." - everyone is doing what matters to them. Some people _are_ working on IDE bugfixes, other people are working on macros. People can do what they want.

Play is really not a large amount of code though and it's all in one source tree. It generally doesn't have a lot of "layers" compared to even something like Tomcat; the stack just doesn't get as deep. I've had an easy time digging in to the Play source code when needed.

Just one experience fwiw. Sure, it's still a framework.

"They didn't take a patch on one occasion, and then we had a couple never-diagnosed bugs that we think could have been in the framework."

Fair enough, but I wouldn't switch to an inferior framework over it.