Maintaining your beliefs whether or not they are correct is not integrity; it's simply stubbornness. Integrity includes being able to admit you were wrong before, which is seems to be looked down on in our society; consider how many politicians have been accused of "flip-flopping" on a controversial subject.
No, the problem with purely functional languages is that they are incomplete and do not cover all useful paradigms sufficiently. If a language makes you write anything out longhand, it failed to properly provide an expressive form for the paradigm.
Hasn't stopped Java. They like to call them "design patterns" rather than "failures of notation," though.
There are a few problems with functional programming languages that have prevented their true adoption anywhere.
1. Limited paradigms - I always prefer languages that let me write my code the way I want, a la C++, than a language that requires a strict paradigm from academia like Lisp. If I want to use the inherent hardware property based side effects of certain code structures, let me. Programming languages =/= mothers.
The problem with a language that "lets you write the code the way you want" is that most people don't want to read code that's been written the way you want to write it. That may also include you six months from now; you end up with code that's hard to read and hard to maintain.
2. Difficulty. 90% of programmers (not on the internet, in general) write code like Fortran when its 2010. The most popular languages now, C# and Java, are popular because they are extremely easy to understand, if not easy to get things done in. You dont need to know lambda calculus or templates or prototyping to understand 99% of C# / java code (yes, I know C# has all of those and java has 2/3 of those). The problem with functional languages is that they always use these paradigms.
I'm not sure I'd consider Java "extremely easy to understand." I find Java code very hard to read, if only because the syntax is so cluttered. I'm not a functional programmer at all, (I mostly program in Go) but I think lambda calculus is an interesting concept, if only because it's very different from how I usually write programs. Object-oriented programming (at least, as it's done in Java) is also quite different from what I'm used to doing, and I think it's an interesting approach to writing programs as well. Neither way is really "better," just different.
I mean, I dont use them. Thats personal preference. I like the way C and OO work more than I like dynamic typing and having no data and all the other out of this world paradigms. I really hope that D can achieve what I hope it will evolve into, a language that is hopefully as easy to understand as Python without the boilerplate of Java but with the performance of C. Thats kind of where the end goal of programming languages needs to be.
Have you checked out Go? It fits your description pretty well, though your mileage may vary as to how well.
I agree with the linked article in that we need more languages, but those languages need to try to do less. For instance, you mentioned that 99% of C#/Java code doesn't use lambda calculus or templates or prototyping; then what's the point of them being in the language if nobody uses them? This also gets back to the point I made above about C++; when you try to do everything really well, you end up doing everything poorly. Go is my favorite language not only because of the features it has, but also because of the features that were deliberately left out. Sometimes, trying to program in a language that doesn't have everything is easier than trying to program in a language that does.
One of the reasons context-free searches isn't more prevalent in everyday computing is the increase in complexity and thus computation resources needed to process it. If regular grammar was linear, then context-free is closer to linearithmic (n*log(n)).
Regular grammar searches are linear, or they are in a proper implementation. In addition, LALR parsers also run in linear time. There is an increased space requirement; regular grammars are equivalent of finite-state automata, and therefore require constant state, whereas a context-free grammar is equivalent to a pushdown automata, or a FSA with an extra stack. I couldn't find any sources on the space requirements of an LALR or an LR parser, but I should probably note that a linearly-bounded automaton requires O(n) space and is more powerful than a pushdown automaton, so the space requirements are likely less than linear for an LALR parser.
This reminds me of a paper Rob Pike wrote a while back addressing this problem. His solution was a generalization of regular expressions, which he termed Structural Regular Expressions. I'm not sure how these stack up against context-free grammars, but it's an interesting approach that seems at least fairly similar to the Dartmouth work. In any case, I didn't see it as a reference, so I thought I'd mention it.
I think Go would be a better choice. C's great and all, but rather than spending development time "building useless OOP frameworks," they'll be spending their time managing memory; considering they're PHP/Python/Ruby programmers, it's possible most of them don't have a lot of C experience. Go would be a much better choice in this case. You'll still get a significant speed increase, though not as much as C, but it's garbage collected, so you don't have to learn how to manage memory all at once. Many people on the mailing list have come from a dynamic language like Python or Ruby, and say Go is a great improvement because of the type safety and performance. I haven't done much web programming myself, but ask around on the mailing list, there's plenty of people doing that sort of thing.
Sorry but the only instances of pirated games I have ever seen (and btw didn't download) were cracked versions of a game that could be downloaded for free. I haven't seen a site offering to sell me someone else's game for a fee. I agree its a matter of convenience in a lot of cases - when something cool is out people want access to it now - but I think it must be a much less common thing that people buy the game from a pirate. I have never associated piracy with a separate sale arrangement, just people who want something for free, or simply want it where its not available or (as noted by an Aussie above) its grossly overpriced and people feel ripped off.
The pirates charge less than the game companies. The fact that the price is $0.00 doesn't really matter; you're still paying less than if you bought it legally. If I were to make a bunch of copies of a game disc, and go around handing it out to people and paying them $5 (note, *I'm* paying them to "buy" my product), then I'm selling the game at an even lower price than the pirates. Yes, it would be incredibly stupid to do that, but that's not the point; the point is, just because the customer isn't paying doesn't mean they're not sales.
I think Gabe's got it spot-on. In economics terms, the pirates are competition; competition who is selling a better product, more widely available, and cheaper. You can't beat competition like that by crippling your product even further.
notice anything: there's no 'desktop' and I don't have any need for it. I'm quick to open a term window of some kind, do things in it and if a graphic app pops up, so be it; move its window, place it and use it.
drag to trash? really? people feel they need a desktop for that?
This sounds a bit similar to Plan 9 from Bell Lab's window manager, rio. Brief explanation:
No desktop
Mouse3 (right click) brings up a menu for window controls
Mouse2 (middle click) brings up commands for editing text
Mouse1 (left click) selects text and switches between windows, as you'd expect.
New windows open up a terminal. Starting up a graphic application uses the window of the terminal in which it was started.
That's pretty much everything for using the windowing system. Oh yeah, and it's a file server, so it's network-transparent; the entire window system, or just a few windows can be exported and imported on a remote computer very easily. It's also easy to recurse; running rio within rio to act like a virtual machine. It's pretty cool stuff. Very different from what most people are used to, but cool nonetheless.
The Slashdot posting states (perhaps correctly) that this is China's first HPC installation that doesn't use Intel or AMD processors, however, the article makes a bigger claim:
Second, this is the first significant high-power computing (HPC) installation in the world that doesn’t use Intel or AMD processors.
No matter how you look at it, it's wrong. According to the Top500, there are 45 supercomputers that use POWER processors, one that uses NEC processors, and two that use SPARC. In particular, the processors in the current fastest supercomputer, the K Computer in Japan, are SPARC processors built by Fujitsu.
Video chat would be impractical
on
iPad Review
·
· Score: 1
I've always thought that video chat on an iPad would be impractical.
You commented on the weight of the device; now think about holding it out at arms length for 30 minutes while you have a video chat. In addition to that, you'd have to hold it in such a way so that the camera shows your face, and not your stomach or the wall above your head.
For a company whose reputation is built entirely on user experience, I don't see Apple adding a feature that's as likely to create more headaches/sore arms than it cures.
Slashdot Mirror
Maintaining your beliefs whether or not they are correct is not integrity; it's simply stubbornness. Integrity includes being able to admit you were wrong before, which is seems to be looked down on in our society; consider how many politicians have been accused of "flip-flopping" on a controversial subject.
No, the problem with purely functional languages is that they are incomplete and do not cover all useful paradigms sufficiently. If a language makes you write anything out longhand, it failed to properly provide an expressive form for the paradigm.
Hasn't stopped Java. They like to call them "design patterns" rather than "failures of notation," though.
There are a few problems with functional programming languages that have prevented their true adoption anywhere.
1. Limited paradigms - I always prefer languages that let me write my code the way I want, a la C++, than a language that requires a strict paradigm from academia like Lisp. If I want to use the inherent hardware property based side effects of certain code structures, let me. Programming languages =/= mothers.
The problem with a language that "lets you write the code the way you want" is that most people don't want to read code that's been written the way you want to write it. That may also include you six months from now; you end up with code that's hard to read and hard to maintain.
2. Difficulty. 90% of programmers (not on the internet, in general) write code like Fortran when its 2010. The most popular languages now, C# and Java, are popular because they are extremely easy to understand, if not easy to get things done in. You dont need to know lambda calculus or templates or prototyping to understand 99% of C# / java code (yes, I know C# has all of those and java has 2/3 of those). The problem with functional languages is that they always use these paradigms.
I'm not sure I'd consider Java "extremely easy to understand." I find Java code very hard to read, if only because the syntax is so cluttered. I'm not a functional programmer at all, (I mostly program in Go) but I think lambda calculus is an interesting concept, if only because it's very different from how I usually write programs. Object-oriented programming (at least, as it's done in Java) is also quite different from what I'm used to doing, and I think it's an interesting approach to writing programs as well. Neither way is really "better," just different.
I mean, I dont use them. Thats personal preference. I like the way C and OO work more than I like dynamic typing and having no data and all the other out of this world paradigms. I really hope that D can achieve what I hope it will evolve into, a language that is hopefully as easy to understand as Python without the boilerplate of Java but with the performance of C. Thats kind of where the end goal of programming languages needs to be.
Have you checked out Go? It fits your description pretty well, though your mileage may vary as to how well.
I agree with the linked article in that we need more languages, but those languages need to try to do less. For instance, you mentioned that 99% of C#/Java code doesn't use lambda calculus or templates or prototyping; then what's the point of them being in the language if nobody uses them? This also gets back to the point I made above about C++; when you try to do everything really well, you end up doing everything poorly. Go is my favorite language not only because of the features it has, but also because of the features that were deliberately left out. Sometimes, trying to program in a language that doesn't have everything is easier than trying to program in a language that does.
One of the reasons context-free searches isn't more prevalent in everyday computing is the increase in complexity and thus computation resources needed to process it. If regular grammar was linear, then context-free is closer to linearithmic (n*log(n)).
Regular grammar searches are linear, or they are in a proper implementation. In addition, LALR parsers also run in linear time. There is an increased space requirement; regular grammars are equivalent of finite-state automata, and therefore require constant state, whereas a context-free grammar is equivalent to a pushdown automata, or a FSA with an extra stack. I couldn't find any sources on the space requirements of an LALR or an LR parser, but I should probably note that a linearly-bounded automaton requires O(n) space and is more powerful than a pushdown automaton, so the space requirements are likely less than linear for an LALR parser.
This reminds me of a paper Rob Pike wrote a while back addressing this problem. His solution was a generalization of regular expressions, which he termed Structural Regular Expressions. I'm not sure how these stack up against context-free grammars, but it's an interesting approach that seems at least fairly similar to the Dartmouth work. In any case, I didn't see it as a reference, so I thought I'd mention it.
I think Go would be a better choice. C's great and all, but rather than spending development time "building useless OOP frameworks," they'll be spending their time managing memory; considering they're PHP/Python/Ruby programmers, it's possible most of them don't have a lot of C experience. Go would be a much better choice in this case. You'll still get a significant speed increase, though not as much as C, but it's garbage collected, so you don't have to learn how to manage memory all at once. Many people on the mailing list have come from a dynamic language like Python or Ruby, and say Go is a great improvement because of the type safety and performance. I haven't done much web programming myself, but ask around on the mailing list, there's plenty of people doing that sort of thing.
Sorry but the only instances of pirated games I have ever seen (and btw didn't download) were cracked versions of a game that could be downloaded for free. I haven't seen a site offering to sell me someone else's game for a fee. I agree its a matter of convenience in a lot of cases - when something cool is out people want access to it now - but I think it must be a much less common thing that people buy the game from a pirate. I have never associated piracy with a separate sale arrangement, just people who want something for free, or simply want it where its not available or (as noted by an Aussie above) its grossly overpriced and people feel ripped off.
The pirates charge less than the game companies. The fact that the price is $0.00 doesn't really matter; you're still paying less than if you bought it legally. If I were to make a bunch of copies of a game disc, and go around handing it out to people and paying them $5 (note, *I'm* paying them to "buy" my product), then I'm selling the game at an even lower price than the pirates. Yes, it would be incredibly stupid to do that, but that's not the point; the point is, just because the customer isn't paying doesn't mean they're not sales. I think Gabe's got it spot-on. In economics terms, the pirates are competition; competition who is selling a better product, more widely available, and cheaper. You can't beat competition like that by crippling your product even further.
notice anything: there's no 'desktop' and I don't have any need for it. I'm quick to open a term window of some kind, do things in it and if a graphic app pops up, so be it; move its window, place it and use it.
drag to trash? really? people feel they need a desktop for that?
This sounds a bit similar to Plan 9 from Bell Lab's window manager, rio. Brief explanation:
No desktop
Mouse3 (right click) brings up a menu for window controls
Mouse2 (middle click) brings up commands for editing text
Mouse1 (left click) selects text and switches between windows, as you'd expect.
New windows open up a terminal. Starting up a graphic application uses the window of the terminal in which it was started.
That's pretty much everything for using the windowing system. Oh yeah, and it's a file server, so it's network-transparent; the entire window system, or just a few windows can be exported and imported on a remote computer very easily. It's also easy to recurse; running rio within rio to act like a virtual machine. It's pretty cool stuff. Very different from what most people are used to, but cool nonetheless.
Second, this is the first significant high-power computing (HPC) installation in the world that doesn’t use Intel or AMD processors.
No matter how you look at it, it's wrong. According to the Top500, there are 45 supercomputers that use POWER processors, one that uses NEC processors, and two that use SPARC. In particular, the processors in the current fastest supercomputer, the K Computer in Japan, are SPARC processors built by Fujitsu.
I've always thought that video chat on an iPad would be impractical. You commented on the weight of the device; now think about holding it out at arms length for 30 minutes while you have a video chat. In addition to that, you'd have to hold it in such a way so that the camera shows your face, and not your stomach or the wall above your head. For a company whose reputation is built entirely on user experience, I don't see Apple adding a feature that's as likely to create more headaches/sore arms than it cures.