I believe that Python, Java, C#, Objective-C and Javascript all have the same basic approach to this problem. The Ruby way is better for handling some Japan-specific problems. But that's at the cost of making life harder and less predictable for everyone else.
It's a pretty straightforward tradeoff. Of course people who are not Japanese will naturally be upset to pay a cost in complexity for a feature of benefit primarily to a programmers from a single country. Non-Japanese Ruby programmers will just have to decide whether their solidarity with Japanese programmers outweighs their personal and collective inconvenience.
> But stop whining. All over the USA, people who work hard, who get great reviews from bosses, customers and peers, who were promised bonuses and profit sharing, are seeing instead slashed pay and benefits. That is, if they are lucky, and not getting RIFed.
Most of them are not the subject of congressional investigations.
> If you worked anywhere besides the financial industry at a company in AIG's shape, you wouldn't be getting a bonus, not because of politics, but because there wouldn't be any money to pay one.
No, but he'd get a salary. Which he did not at AIG (according to his account).
> People in your line of work compensated themselves as if they were founders and early investors in F500 companies, while holding positions that would barely command six figure salaries in other industries.
Yes, that's more or less what he said in the article.
> I'm sure most readers here on HN would like to be in the position to write a 750k check to charity in the face of a depression.
Yes, that's more or less what he said in the article.
> That $100 million a year in equity and commodity trading? How much of that was on the back of the tech and housing bubble, and exploding oil prices? Sans the games the guys down the hall were playing with CDS and CDOs, would your returns even have been so high?
Perhaps your job also depends on the bubble economy. We'll know by this time next year.
If you follow the thread to the end, you'll see that the guy renamed some variables, resubmitted and got accepted.
PhoneGap is open source. There is no "signature" that they can use to know that you incorporated code from it. They would have to disavow their own APIs in order to stop people from using it.
JSON is much more popular than s-expressions, and not just accidentally. Explicit, compact syntax for both lists and key-value pairs is The Right Thing in a language like this.
JSON is a subset of s-expressions. (Yes, s-expressions provide explicit and compact representations for mappings. They also handle other kinds of objects.)
The other difference is that there are JSON parsers and generators for more languages and they're not programmable.
I'm confused why you don't see this as obvious. (There are several possible ways to represent mappings. I picked one that was close to something that you're happy with.)
Clojure uses {} for maps, #{} for sets, and [] for vectors, and vectors are used in function definitions, let statements, etc. This slight decrease in regularity makes a lot of functionality more visible. For example:
SBCL:
(defun f (x y) (let ((z (gethash x :a))) (+ z y))
Clojure
(defn f [x y] (let [z (get x :a)] (+ x y)))
Having syntax for maps is a huge win. Like ML's pattern matching, it's one of those things that changes your coding style entirely for the better, in a way that you wouldn't predict just by looking at the feature.
The only think I miss from CL when I work in Clojure is keyword arguments to functions. There, the Clojure way is a bit worse:
(defun f (x &key y z) (list x y z))
(f 2 :z 3) => (2 nil 3)
(defn f [x {y :y z :z}] (list x y z))
(f 2 {:z 3}) => (2 nil 3)
> (defun f (x y) (let ((z (gethash x :a))) (+ z y))
vs
> (defn f [x y] (let [z (get x :a)] (+ x y)))
The CL defn of f is a function that is called with two arguments. That function is called like "(f a b)" If the Clojure definition is comparable, that is, the call looks like "(f a b)", why are []s used in the definition and the let?
> This slight decrease in regularity makes a lot of functionality more visible.
What functionality? x,y aren't part of a vector and neither is z. (x,y may come from a vector in the caller, but I'll assume that the defn works if they don't, so
that shouldn't matter.)
It would make data generation more difficult. When you emit any given data, you'd have to know its level of nesting to get the correct number of indents. Using begin and end tokens (whatever they are) makes that much easier.
(I actually prefer Python's style of using indentation to indicate blocks, but I recognize generating such code is harder than code with tokens.)
In my current project, I've implemented a source-to-source compiler. In the places where I emit C code, I usually don't have a handle to the scopes above me. I could get one, but it would take more work.
The code I generate has no indents and no newlines. Not having to keep track of these makes life simpler. To make my generated code more legible, I just run indent on it.
I've written C code emitters too. FWIW, I've found nicely-indented output templates help to keep the source code of the emitter clear (and with no need to get at the enclosing scopes). But the question you raised was whether indentation-only was harder to generate, and I'd say no, because code.replace('\n', '\n ') is as simple as '{' + code + '}', if slightly slower.
And my point was that with the transformations I generate, I don't just say '{' + code + '}'. I'm applying transformations to existing code, not generating all of my own code from scratch.
Again, I see no point in making efforts to generate clean looking code when utilities like indent exist.
1.hmm, well, if you try it you'll see
that at least in the area of programming languages, after
spending some time you'll see that you reinvented s-expressions.
2. can be very interesting to see for example
this (sum of every vector-element) in json/yaml...
A decent JSON parser is also only a day's worth of work or less in just about any language.
My experience is that it is as little as and possibly less initial development and maintenance as a custom flat-file format or a really robust csv parser.
A few years ago, I took over maintenance of a Windows program that depended upon a Java component wrapped in COM. With Sun and Microsoft at war, that seemed a bit risky to me.
I asked: "why is this Java component in the Windows client app?" The answer was that the server was also implemented in Java and the SOAP libraries were compatible, whereas Microsoft's and Java's were not (at that time).
I nearly choked: they chose a "standard" like SOAP and then re-standardized on a particular library (client and server components of it) "for compatibility."
So to bring this digression back to relevance, I'll say this: if you already have Java code around, it will be easiest to talk to it from Java. And since Java is the new COBOL, there is a bunch of Java floating around. (but if you need a Java client to talk to a Java server using a "standard" protocol then something is seriously awry somewhere)
You say libraries aren't the issue, but the discussion is about a blog pst that said: "And why Python, then? Well, said Sussman, it probably just had a library already implemented for the robotics interface, that was all."
I'm sure your experience is grounded in a general reality. But the post you disagreed with was about a specific case: i.e. the one described in the blog post.
From the point of view of a person at an instant in time, libraries are a concern. But when we're talking about Scheme being displaced by Python at MIT, where Scheme was developed 30 years ago, we really ought to ask what's been happening to Scheme during that 30 years.
The problem, at MIT and elsewhere, is that hackers don't like hacking Scheme enough. Python has more libraries than Scheme now, but that's not the main thing that made more people use it. People use it because they prefer the language. This is something that Sussman and others at MIT should be trying to understand, but it doesn't strike me that they are trying to understand it. They're just saying "Python has a better robotics library -- oh well!" as if this were something completely random that they have no control over. That doesn't seem like the sort of attitude that produced Scheme in the first place.
My point of contention with the comment I replied to is the idea that fixing the problem is a question of writing more libraries for Scheme. Writing or interfacing to libraries for numerics, 3D graphics, etc. is a trivial task compared to making a language hackers love.
Now, maybe hackers' distaste for Scheme is Scheme's fault, or maybe it's hackers'; but in any case, the issue is with the core language, not the libraries. And based on my personal experience with Scheme I would say that enough of the fault lies on Scheme's side that it's worth fixing.
The prospect of Scheme as a potential mainstream programming language went down with the rest of the Lisp ship in the late-1980s AI winter - the same one that sank Symbolics and anyone who was remotely Lisp-guilty by association.
It is no accident that it survived almost exclusively in non-saltmine sanctuaries like MIT, where industry herdthink held less sway. In the linked article, Sussman directly admits that he is unable or unwilling to fight back against the intellectual decay that has consumed non-academic programming.
He has decided to "go with the flow" - namely, the flow of industrial sewage into students' heads.
We're talking about the user interface to computational machines. There is no abstract "right" or "wrong" and no context-insensitive "practical" or "impractical."
He wanted to do a course about robots, and according to him, the interface to the robots was Python, which was otherwise an adequate language.
If you want to make a case to the contrary, it should be rooted in the specifics of the situation.
Process management is done with a custom tool. In theory we could have a dynamic number of apps, but in practice it is static. Occasionally we have to take a few out of rotation, and haproxy handles it just fine.
It's a pretty straightforward tradeoff. Of course people who are not Japanese will naturally be upset to pay a cost in complexity for a feature of benefit primarily to a programmers from a single country. Non-Japanese Ruby programmers will just have to decide whether their solidarity with Japanese programmers outweighs their personal and collective inconvenience.