I think you and the parent may be talking past each other. When most people talk about "un-ambitious" people they're talking about "cogs". People working in some generic job in a big company.
Your dad sounds like he probably effectively has his own business which I admire and aspire to.
Personally what I hate is this attitude that think if you didn't become google/facebook you failed. There was a reddit post a while back about some guy who opened a cleaning service that replaced his "cog" salary and allowed him to quit his day job. One of the first comments was "this won't scale!". He was able to quit his job! How much more scale does he need?
> When most people talk about "un-ambitious" people they're talking about "cogs". People working in some generic job in a big company.
No, that's exactly what I mean. You are not better than the "cogs" simply because you've made different occupational choices. We all have our reasons for choosing what we do. And some people don't even have much choice.
We'll have to agree to disagree on that. Right now I'm a cog in a big company and I know what I do isn't as valuable as what entrepreneurs do. I came in to a team who had a horrible software system, replaced everything and brought running costs way down by decreasing code size while increasing features and maintainability. But in the end, it's all for nothing. As soon as I'm gone the team will either be decommissioned entirely, handed over to some other team who will have no use for what I've done or outsourced somewhere that will rewrite everything again.
Big companies are just a game of musical chairs for managers. They just need to show something on their 360 reports so they can get a promotion and they couldn't care less what happens to their previous team once they get that. They don't even care about the company itself, only climbing the ladder. If the company fails then they can just move somewhere else with their new higher rung experience and start the climb again. If you're a developer in such a place either you're trying to play the game yourself or you're literally whoring out your mind and fingers for cash. The job itself is utterly meaningless and can never be made meaningful because what you produce is irrelevant. The only part that matters is the politics.
It's true that many of us end up here because we have no other choices, but it's important to keep in mind what you're actually doing. Don't romanticize being an intellectual prostitute. Save up as much as you can so you can get out. If you're happy to stay in such a place, then yea I do have less respect for you.
>Unlike the poster below thinks though I don't have 40 free hours a week these days. I am working to build the next big thing because this is in my blood,
I suspect this is what the poster below meant by having 40 free hours a week. If someone handed me a billion dollars I would probably take a bit more vacation than now, but quite working? No way! I have a million ideas. I'd like to do as many as possible in the time I have.
>I would not want to work for Facebook for any amount of money.
For any amount? I'd even work for the Koch brothers for, say, $10m/yr. Of course I'll be gone from their company and the entire rat race after a year, but still.
I think it's fair to say that when people suggest "any amount of money" they have already bounded it by what is reasonable. Of course the Koch bros. aren't going to pay you $10m/yr to scale their website. They don't even pay people that much to spout their agenda. Similarly, "any amount of money" probably means 150% or so of the going market rate.
I disagree completely. I would say everyone should start with Smalltalk. Start with something beautiful and clean and then learn the messy stuff that makes it possible later.
As I said, it's a massive undertaking. The minimal acceptable toolkit (to say nothing of competing with GTK or QT, just getting the minimal toolkit that users will tolerate) is an immense amount of work. Quite a lot of it is essential complexity, the things that textboxes do that are simply expected and are true representations of complexity, not accidental artifacts of the paradigm used. Functional programming may or may not help with accidental complexity but nothing can duck the essential complexity. I'd estimate that even a minimal toolkit would be on par with the time invested into GHC itself, and to seriously compete, tack a couple of orders of magnitude on there.
In a world where everybody implements MVC web framework in their favorite language, reimplements window managers in their favorite language, and reimplements all manner of other software simply because it wasn't in their favorite language... there's a reason all the communities just bind to GTK, QT, and wxWidgets and don't reimplement widget frameworks from scratch in their favorite language, even for languages much better funded and bigger than all the functional programming communities put together. Just the bindings can be major and in some cases unsustainable efforts for smaller communities.
Perhaps if you need a comprehensive toolkit that supports the various widgets and gestures in contemporary toolkits, it is a big undertaking (probably not that massive, IMO).
It is incomplete and non-comprehensive, but adding the nuances needed to make it more complete and comprehensive wouldn't be too much work (it's simply not our focus in the project).
I was citing the amount of work to create a minimal acceptable toolkit to a programmer on the street, the sort of toolkit you'd point a hostile Python programmer to to say "Yes, we have a native toolkit", not the toolkit that you'd use to convince an already-converted Haskell user. Bear in mind that Tk prior to their relatively recent theme work was not that toolkit either! And that was actually a pretty decent kit, with layout managers, a nice text widget, tabs, all the basic stuff you'd need, if not the fanciest ever.
* It is incomplete and non-comprehensive, but adding the nuances needed to make it more complete and comprehensive wouldn't be too much work*
So it's minimal AND incomplete. Not even minimal and complete. That's what the parent was saying. And it will likely stay that way (as it's not even your focus in the project), and be forgotten.
Does git-svn now handle svn:externals properly? I can't find anything saying it now has support. I'd love to switch to git as my client, but we have upwards of 70 externals for libraries we maintain, and converting those to git submodules is not an option. Well it is, but it is far more work than simply using git as a client.
I don't think Git submodules were added until 2009 (at least that's what the commit history looks like). We deployed with SVN at least six years ago, long before git could compete.
Still, I would like to use git as my svn client, but it's just not a suitable replacement without externals handled nicely.
I had some merge problems with SVN too (like a 6 hour merge session twice a year), but that may be due to my limited SVN knowledge and poor branch setup.
As an aside, I changed jobs to another place using SVN, and when they started moving to Git I changed jobs again. Still using SVN! :-)
It's a good, if fairly old [1] insight. The fact is, there are two kinds of patterns: architectural patterns (e.g. "message bus", "web service", etc.) and there are language deficiency patterns (e.g. factory, double dispatch/visitor, etc.). A good way to gauge the power of a language is to see how many of these patterns you need.
For example, when I was exposed to Smalltalk I fell in love with it. So many of the patterns I was used to needing were not necessarily there. That's because Smalltalk is more expressively powerful than, say, Java. You see this directly in the GoF patterns book as several of the patterns only provide C++ code and say "Smalltalk doesn't need this as it does X".
Eventually, though, I begin to see that pg was right and single dispatch is a subset (in this case; inferior) of generic functions. The issue was double dispatch. Smalltalk needs it, Lisp doesn't. I never have to write boring double dispatch wiring in Lisp because of how generic functions work.
So I don't think it's OO itself that is flawed (though it's not as a big a deal as it's made out to be. It's a form of code organization, specifically global variable demarcation and code reuse), but rather many OO languages that are weak enough to require programmers to hand-code out these common patterns instead of either providing it in the language or providing a powerful enough language to let us solve it once.
Agreed. I'll go ahead and burn the karma on an overwrought historical analogy right now:
C++ did to object-oriented languages in the 90s what the Church did to Europe in the medieval period. Thankfully functional languages (the Islamic world) preserved a lot of knowledge through that period so that it can now be re-introduced.
I agree that single dispatch seems to be a pretty obvious problem with most oop languages, if you have a method that has two different types as parameters, on which do it belong? Take a pick and hold your breath... or do some unwieldy manager class :) Smalltalk and Lisp seems (zealously) loved by many, and it's easy to like the simple elegance of languages like that.
For me they always felt wee bit too messy and academically oriented. I want a language that reads more like a book and less like a formula, perhaps that's just me :)
This problem is easily resolved by noting that you think the method has to 'belong' to one type or another instead of exist as a first class object of its own. In practice this was done first in Lisp (the 'generic function' works better with typical Lisp environments than endless (send object message) calls, in particular with functions like map), and then the fact that the generic function treated one and only one argument specifically was noticed. From here we get multiple dispatch in a very natural way, a concept that is quite awkward in a language like Smalltalk.
The concept is quite awkward in any single dispatch language. The biggest WTF ever is Racket adding single dispatch OO! You actually have to say (send object 'message).
> I want a language that reads more like a book and less like a formula, perhaps that's just me :)
Perhaps you shouldn't look so much for a new language, but rather a new way of using the language. Have a look at http://www.literateprogramming.com/adventure.pdf, a showcase of literate programming using the example of the venerable Colossal Cave Adventure.
I don't know, things actually seem to be trending the opposite. Who would have thought that people would spend so much time in facebook playing games that have seemingly no point.
I also disagree that HTML5 is any easier. After over 20 years of trying, it seems unlikely that browsers are ever going to converge on any kind of standard and even if they did there will probably always be people on a bad version.
Personally, I'm betting on a world with native front ends to REST web applications.
There were several reasons for the crash, but the main cause was supersaturation of the market with hundreds of mostly low-quality games which resulted in the loss of consumer confidence.
I think it very likely is the case. They can't put ads on the iOS app without giving Apple a cut so they are very likely making the App subtly worse as time goes by.
