71–80 of 124 posts
Earlier quoted context omitted.
I don't think anyone is going to say that Haskell's type classes in any way fit the traditional notion of a type. It's more the exception that proves the rule in this case.
I know it's a common saying, but I've never understood how exceptions can prove rules.
I think as working programmers, we end up torn between two opposing perspectives with our tools (i.e. programming languages, editors, language features): On one side, there's the aesthetic of minimalism. Visualize the master Japanese calligrapher seated in an otherwise empty room, table before him. One parchment, one pot of ink, one brush. And he creates the most flawless art one could imagine. Mastery means removing…
Your metaphor certainly resonates with me, but there are two mixed concepts here: 1) The 'zen' axis of language syntactic joy. 2) The 'practicality' axis which is a kind of mix of size of the standard library, availability of 3rd party libraries that do Really Cool Useful Stuff and the speed of the resulting binary. Your toolkit isn't really about the zen axis. It's about the practicality axis, and that's where java…
Agreed Java came out of the gates with a good (??) desktop programming library. Google Go's library on the other hand is very web oriented with the building blocks of http, templating, json all woven in - maybe its a better approach to take, seeing how desktop programming is fast disintegrating into a proprietary, incompatible mess with bottle windows (metro) and apple (ios) locking up their environments.
I agree heartily with the zen metaphor, when programming in Go, I find the language recedes to the background and allows me to focus on the task at hand. That's the hallmark of a great language design.
The very very very fast compilation times (you have to experience this to believe it), helps a lot. Gives it the fast turnaround of a scripting language without any loss of power/ expressiveness.
I'm still of the opinion they made a mistake by not having exceptions. When programming in Python exceptions are wonderful because they let me put error handling code in the appropriate place without having to litter all the intermediary code to where errors happen with error flags. (Panic is not the same thing.) The usual complaint about exceptions is "expense", but the same claims can be made about gc. The Go FAQ i…
The reason we didn't include exceptions in Go is not because of expense. It's because exceptions thread an invisible second control flow through your programs making them less readable and harder to reason about. In Go the code does what it says. The error is handled or it is not. You may find Go's error handling verbose, but a lot of programmers find this a great relief. In short, we didn't include exceptions becaus…
I can understand why, coming from a C++ context, you'd want to avoid them like the plague, but other languages (Python, Java, Smalltalk, ...) do a good job of making them a first-class citizen in the language, which saves a LOT of boilerplate typing. Seeing call stacks implementing a half-assed exception catching mechanism makes me sad. (Okay, Java only gets half credit here, since its checked exceptions inflict a different kind of boilerplate, but my larger point remains.)
Lack of exceptions is half the reason I'm not interested in writing Go code yet. The other half is that anything that seriously intends to replace C++ does need an escape hatch to allow manual memory management for when the GC's one-size-fits-all approach is simply a poor fit. For a language whose goal was explicitly to replace C++, this is an odd place to be tone deaf. I'm disappointed to see an attitude of "haha stupid C++ programmers don't understand that programmer efficiency is more important than CPU efficiency," instead of realizing that there are valid use cases where you do need to care about this and addressing them.
Which is unfortunate.
Its not just that many programmers want more control. Its also the case that many programmers want more complication. They really prefer the most complicated and difficult way to do things. They don't trust things that are easier or simpler. I think that maybe they believe deep down that ease-of-use versus power is truly a zero-sum game, and you just can't get more of one thing without giving up some of the other. Al…
Some people don't trust black boxes because they have been burned too many times in the past. I don't want to make this an age thing, but in my observation the people who are chomping at the bit to jump on the next big thing are generally those who haven't yet really suffered because of someone else's mistake. Cryptography's got the right attitude. Don't use things that are proven to be broken, but at the same time d…
People move on to the next thing because they know it solves fundamental engineering problems built in to the platform they are on that are causing constant problems and they are tired of suffering through that. Such as manual memory management or traditional threading.
For example, back in my C/C++ days, I worked on a number of projects that were threaded and manually memory managed. No matter how genius the team members were we always spent a significant amount of time either guarding against those types of issues or diagnosing them, or working on Make scripts or other build-related distractions.
So that was one reason why I moved to C#/.NET many years ago. The advantage of being able to access source code in open source projects, cost benefit and lack of vendor lock in moved me away from that.
Or for example my main project right now is based on Etherpad which was originally written in Rhino which is a Java-based JavaScript. They saved a lot of lines/characters of code by doing it in JavaScript originally which was good software engineering since less code means fewer defects and JavaScript runs on both the browser and server which is also helpful. However, it was built on Java which has dated overly complicated APIs and Rhino is an inferior JavaScript engine. And we can't get it to stop freezing up/crashing at random times, which according to one of the former Etherpad team members is normal.
So we are following the lead of Etherpad and converting the application to be based on Etherpad Lite which is a running on Node.js which is another next big thing. There are no threads, so I know that can't cause any freezing. The V8 memory management and code generation is state of the art. The system will use an order of magnitude fewer resources than the old one. The asynchronous Node execution model and APIs are obviously superior to Java. At least its obvious to me.
Earlier quoted context omitted.
Atlassian is on that list but I know that last year we rewrote our Go code to Python after our main Go developer left.
I've never understood this kind of action. Go is so small you could hold the spec in your hand and it's going to be faster and more efficient than python as well as safer to modify thanks to type safety. If it were haskell, or a similarly difficult language to wrap your head around, I could see wanting to rewrite to something easier to understand. But Go has none of those problems. What could possibly motivate a rewr…
The team rewrote from Go to Python for various reasons:
* Tool support (debugging, etc) was supposedly poor
* The standard library wrappers were supposedly buggy
* They had to write a lot of wrappers and libraries themselves
* People on the team were already familiar with Python - after Atlassian's single "Go developer" left, there wasn't much reason to keep it
> Early in the rollout of Go I was told by someone that he could not imagine working in a language without generic types. As I have reported elsewhere, I found that an odd remark. What I find odd is that he makes this statement, but then doesn't explain which of the following he prefers: 1. Rewriting algorithms again and again for each minor variation of a data type 2. Downcasts everywhere 3. Contorting code to work…
You don't need to pick one of those three. Maps and arrays cover most cases. The rest of the time you can implement capabilities on your types (touched on in the article) and do some type assertions. The really odd thing about the original statement is that this guy "can't imagine" working without generics. That is a remark that could only be made by someone who is fixated on modeling all problems in terms of type sy…
I can see myself making that statement, and obviously "can't imagine" is hyperbole, since I've written a lot of C, but I can't imagine taking seriously a new language that doesn't let me reuse data structures. I'm not sure what you mean by fixated on modeling with types.. I don't care about inheritance hierarchies, I just want a priority queue (and a multimap and a graph and a blocking queue oh wait that's yet another built-in special case) that doesn't force me to downcast like in Java 1.4.
Earlier quoted context omitted.
I don't think anyone is going to say that Haskell's type classes in any way fit the traditional notion of a type. It's more the exception that proves the rule in this case.
I know it's a common saying, but I've never understood how exceptions can prove rules.
Earlier quoted context omitted.
I don't think anyone is going to say that Haskell's type classes in any way fit the traditional notion of a type. It's more the exception that proves the rule in this case.
I know it's a common saying, but I've never understood how exceptions can prove rules.
Parking allowed 3pm-5pm
that implies that parking is not allowed at other times.
Earlier quoted context omitted.
Your metaphor certainly resonates with me, but there are two mixed concepts here: 1) The 'zen' axis of language syntactic joy. 2) The 'practicality' axis which is a kind of mix of size of the standard library, availability of 3rd party libraries that do Really Cool Useful Stuff and the speed of the resulting binary. Your toolkit isn't really about the zen axis. It's about the practicality axis, and that's where java…
IMHO, its not fair to compare Go libraries (at this stage) with the more mature implementation of libraries in C++ and Java. That will come with adoption, but even at this early stage, the set of libraries that come with go offer a lot of power. Agreed Java came out of the gates with a good (??) desktop programming library. Google Go's library on the other hand is very web oriented with the building blocks of http, t…
It's patently absurd to argue that because go > C++ on the 'Zen' scale, that it's somehow also > C++ on the 'practicality' scale. These two axes are not totally independent (arguably say, the verbosity of java for example, decreases its value on the practicality scale) but they're weakly related.
Having a toolkit like QT makes C++ a vastly superior choice to go for a desktop application, despite the fact that C++ lies somewhere on the dark depths of hell on the 'Zen' scale.
What I was saying, and agreeing with the OP on, is: Pick your tool for your problem.
In some cases, that's Go. In some its C++. In some it might be java; but not having all those tools lying around that people can pickup to use is a major failing for go.
...and sure, that'll change eventually I'm sure; but it's an entirely valid complaint right now