How do you have a week long SendMail outage? SendMail doesn't have all kinds of untraceable configuration files and documents what's wrong pretty clearly. SendMail is harder to setup initially, SendMail is less user friendly. But no question SendMail is way way easier to fix if something goes seriously wrong.
As for support I'd say SendMail there is a ton of online documentation and great books. If you mean paid, either. If you mean naive support by an admin Postfix or Exim are far better choices for people who don't know the SendMail programming language and don't want to learn.
That's like saying pro football players didn't find a car door to hard to open so why should the average customer? Stock exchanges have first class IT teams. Companies with first class IT teams are used to handling a variety of technical applications.
People who don't like rapid frequent updates are unlikely to be happy with OSX. People who have trouble installing service packs because they have to do a few configuration changes to make them work are unlikely to be happy with Linux. Classic jump out of the pot into the fire.
It's interesting because in the past Microsoft planned these things very carefully beforehand, and after the release of OS was very careful to not change core functionality. Maybe this is the future, then.
Microsoft has been quite explicit this is the future. They want an update process more like Apple's. Which means getting their customer base and their developer base used to much faster turnaround on features and issues. They are unlikely to ever get as fast as Apple, and probably don't want to but they don't want to be where DEC or IBM were when Windows Server replaced their "bug for bug compatible" systems.
I'm with you on that it isn't even close to Git vs. Linux. But...
The reason for seeing Git as important is that Git was the first free version control system to resolve the performance issues with distributed version control. The combination of free and fast allowing distributed version control to effective in practice for large / complex projects. It moved distributed version version control from a really cool theoretical idea to a practice. The people who had been working in distributed version control before (BitKeeper exempted) had been mainly academic in their orientation. They had no interest in supporting a large project and so performance issues (which were not uncommonly an quadratic function on the number of lines of code in terms of time and memory needs) didn't bother them.
Is that comparable to Linux, hell no. Is that a major accomplishment other than Linux, hell yes.
Guy I have to tell you I think the legal threat is a BS excuse the BSD people have been pushing for a generation. The difference was one of attitude towards new users and recruitment. The BSD people never even aimed for the average Windows poweruser to be able to switch over.
He gets the award for successfully doing things that lots of other people were doing. BSDs didn't have the level of compatibility of Linuxes and fell behind on hardware support almost immediately. They offered a good free x86 based Linux, but arguably one that was worse than SCO. Linux redefined Unix.
Linux developers are... juvenile adolescents.. near-mindless obsession with modernity and false "innovation"
That in one broken sentence sums up why BSD loses. Linux appealed to the young as platform for them to learn Unix and tried to be cool. BSDs allowed themselves to fall behind terribly then and now.
BSD = appeal to existing Unix administrators looking to run Unix on x86. Linux = appeal to Windows users. Not successful. But was successful in moving Unix users over to x86 based Unixes until OSX offered a better alternative.
The result was the next generation of admins knew Linux and didn't know BSD.
In all fairness a lot of that had to do with hardware. People often forget how much more impressive the x86 environment became between the 286 era and the 486 era. It was the period where the difference between what you got for $40k and what you got for $4k shrunk remarkably from a hardware standpoint. Certainly I give Linux credit, but you may be overstating the case a bit.
An SGI, SUN, NeXT workstation was around $7k. A PC was around $2k. SCO was generally about $600-1k, and Dell for example had a great OEMed version of SCO. What Linux did was bring the price of having a home Unix down. In particular it made it possible for people who mostly worked professionally on Unix to have a Unix at home. People and certainly companies that wanted a Unix could buy one before Linux.
The rest about commodity hardware is absolutely true. And that's the point. It shifted the price moderately and that moderate price shift resulted in a surge of users.
I was focusing on the allowing regular folks to program. Honestly I couldn't follow your description of what you wanted and there was no explanation of why those choices made sense.
Functional programming languages have do structures when you need statements to execute in sequence. But again the idea is that state should be isolated, so the incidental sequential stuff isn't present and only the mandatory sequential stuff is.
And BTW Excel is a mostly pure functional programming language where order of execution (which cell gets computed when) is not up to the programmer. Lots of pretty average programmers write stuff in Excel all the time.
Learning to think in Haskell isn't undoable there there is a learning curve. You have to learn different ways of thinking about problems and different techniques. I'd say get a very basic easy Haskell book and do some very simple projects in it.
That's why isolating state and lazy is so awesome in FP. Algorithms that open network connections are isolated from algorithms that want to act on a network connection. So if you have a loop of 10,000 elements that need to open 50 network connections the 50 connections calls get grouped:
List of stuff to send to A List of stuff to send to B List of stuff to send to C
the actual opening to A, B and C end up in another module which would have security and which doesn't have the looping structure.
I'm not a fan of FP everywhere. I'm a fan of FP for complex algorithms. If you have simple algorithms that just need to be structured into a sequence with lots of I/O all FP gets you is a bad imperative language.
Lazy evaluation by default is the most controversial aspect of Haskell. That's the one big design issue where Haskell hasn't proven to be a clear cut win. I think the advantage of lazy by default is really captured by "non deterministic order of evaluation by default" and that's been a huge win for parallelism.
Not sure what you would want here. Just look at Haskell code. Doing a side effect inside the wrong kind of function (i.e. one not in a side effect monad like I/O) just throws a type error.
Class definition of Haskell simply contains methods defined abstractly.
For example the collections class is defined:
class Collects e ce where
empty:: ce
insert:: e -> ce -> ce
member:: e -> ce -> Bool
What this reads is there are 3 functions empty which tells you if a collection is empty insert which takes an element and a collection is arguments and then "inserts" the element into the collection member which takes an element and a collection is arguments which tests to see if an element is a member of a collection
That's it for the class. If you have a collection you are guaranteed those 3 things exist. But you guaranteed nothing about implementation at all. Because of that the methods empty, insert, member are incredibly polymorphic. Which means I can continue to define new functions using these abstractions. So "insert list"
insertList list collection = foldr insert collection list and I get an efficient operation involving a looping structure with no complexity at all.
You keep arguing for (a) by arguing for (b). A company most certainly can get resources for Erlang. As for your arguments regarding efficiency there have been tests again and again for decades that higher level languages increase efficiency. Programs which in practice become too difficult in imperative languages like Java are written all the time in functional languages.
If the developers were simply unwilling to learn to use new tools properly that certainly is a serious issue but that's a good argument for outsourcing the project away from that development team or being in a new team. It is not an argument for using the wrong tool.
I would agree that Haskell, LISP... can unquestionable provide outright "stuckage". No question. I'll grant that one. In an FP if the programmer who wrote the code is moderately more advanced than the person maintaining it than the maintainer will often have to do some serious learning to get the new code.
If you exclude that issue though shorter is easier. For example take parallelism. In pure FPs the parallel strategy is often a single operator located in a few key places in the code. You can just skip it, as a compiler directive. In imperative languages it is scattered all over the code and there is no way to skip.
Code that is 10-20x shorter is right off the bat quite a bit more readable. Code that is structurally simple is quite a bit more readable. Code that uses powerful abstractions can be much less readable till you get used to thinking that way.
I suspect the mixed paradigm languages will make functional techniques more popular. Heck they are having to introduce them into Java now they've become so popular. The.NET compiler is all functional. Javascript, Scala, Perl6, Ruby... are mixed paradigm. I think the change is happening.
Slashdot Mirror
How do you have a week long SendMail outage? SendMail doesn't have all kinds of untraceable configuration files and documents what's wrong pretty clearly. SendMail is harder to setup initially, SendMail is less user friendly. But no question SendMail is way way easier to fix if something goes seriously wrong.
As for support I'd say SendMail there is a ton of online documentation and great books. If you mean paid, either. If you mean naive support by an admin Postfix or Exim are far better choices for people who don't know the SendMail programming language and don't want to learn.
That's like saying pro football players didn't find a car door to hard to open so why should the average customer? Stock exchanges have first class IT teams. Companies with first class IT teams are used to handling a variety of technical applications.
People who don't like rapid frequent updates are unlikely to be happy with OSX. People who have trouble installing service packs because they have to do a few configuration changes to make them work are unlikely to be happy with Linux. Classic jump out of the pot into the fire.
Microsoft has been quite explicit this is the future. They want an update process more like Apple's. Which means getting their customer base and their developer base used to much faster turnaround on features and issues. They are unlikely to ever get as fast as Apple, and probably don't want to but they don't want to be where DEC or IBM were when Windows Server replaced their "bug for bug compatible" systems.
I'm with you on that it isn't even close to Git vs. Linux. But...
The reason for seeing Git as important is that Git was the first free version control system to resolve the performance issues with distributed version control. The combination of free and fast allowing distributed version control to effective in practice for large / complex projects. It moved distributed version version control from a really cool theoretical idea to a practice. The people who had been working in distributed version control before (BitKeeper exempted) had been mainly academic in their orientation. They had no interest in supporting a large project and so performance issues (which were not uncommonly an quadratic function on the number of lines of code in terms of time and memory needs) didn't bother them.
Is that comparable to Linux, hell no. Is that a major accomplishment other than Linux, hell yes.
Guy I have to tell you I think the legal threat is a BS excuse the BSD people have been pushing for a generation. The difference was one of attitude towards new users and recruitment. The BSD people never even aimed for the average Windows poweruser to be able to switch over.
He gets the award for successfully doing things that lots of other people were doing. BSDs didn't have the level of compatibility of Linuxes and fell behind on hardware support almost immediately. They offered a good free x86 based Linux, but arguably one that was worse than SCO. Linux redefined Unix.
That in one broken sentence sums up why BSD loses. Linux appealed to the young as platform for them to learn Unix and tried to be cool. BSDs allowed themselves to fall behind terribly then and now.
BSD Unix had a cultural problem.
BSD = appeal to existing Unix administrators looking to run Unix on x86.
Linux = appeal to Windows users. Not successful. But was successful in moving Unix users over to x86 based Unixes until OSX offered a better alternative.
The result was the next generation of admins knew Linux and didn't know BSD.
In all fairness a lot of that had to do with hardware. People often forget how much more impressive the x86 environment became between the 286 era and the 486 era. It was the period where the difference between what you got for $40k and what you got for $4k shrunk remarkably from a hardware standpoint. Certainly I give Linux credit, but you may be overstating the case a bit.
An SGI, SUN, NeXT workstation was around $7k. A PC was around $2k. SCO was generally about $600-1k, and Dell for example had a great OEMed version of SCO. What Linux did was bring the price of having a home Unix down. In particular it made it possible for people who mostly worked professionally on Unix to have a Unix at home. People and certainly companies that wanted a Unix could buy one before Linux.
The rest about commodity hardware is absolutely true. And that's the point. It shifted the price moderately and that moderate price shift resulted in a surge of users.
I was focusing on the allowing regular folks to program. Honestly I couldn't follow your description of what you wanted and there was no explanation of why those choices made sense.
Functional programming languages have do structures when you need statements to execute in sequence. But again the idea is that state should be isolated, so the incidental sequential stuff isn't present and only the mandatory sequential stuff is.
And BTW Excel is a mostly pure functional programming language where order of execution (which cell gets computed when) is not up to the programmer. Lots of pretty average programmers write stuff in Excel all the time.
You might have meant:
http://blog.sigfpe.com/2006/08...
http://www.haskell.org/haskell...
Learning to think in Haskell isn't undoable there there is a learning curve. You have to learn different ways of thinking about problems and different techniques.
I'd say get a very basic easy Haskell book and do some very simple projects in it.
That's why isolating state and lazy is so awesome in FP. Algorithms that open network connections are isolated from algorithms that want to act on a network connection. So if you have a loop of 10,000 elements that need to open 50 network connections the 50 connections calls get grouped:
List of stuff to send to A
List of stuff to send to B
List of stuff to send to C
the actual opening to A, B and C end up in another module which would have security and which doesn't have the looping structure.
I'm not a fan of FP everywhere. I'm a fan of FP for complex algorithms. If you have simple algorithms that just need to be structured into a sequence with lots of I/O all FP gets you is a bad imperative language.
Lazy evaluation by default is the most controversial aspect of Haskell. That's the one big design issue where Haskell hasn't proven to be a clear cut win. I think the advantage of lazy by default is really captured by "non deterministic order of evaluation by default" and that's been a huge win for parallelism.
Not sure what you would want here. Just look at Haskell code. Doing a side effect inside the wrong kind of function (i.e. one not in a side effect monad like I/O) just throws a type error.
Class definition of Haskell simply contains methods defined abstractly.
For example the collections class is defined:
class Collects e ce where :: ce :: e -> ce -> ce :: e -> ce -> Bool
empty
insert
member
What this reads is there are 3 functions
empty which tells you if a collection is empty
insert which takes an element and a collection is arguments and then "inserts" the element into the collection
member which takes an element and a collection is arguments which tests to see if an element is a member of a collection
That's it for the class. If you have a collection you are guaranteed those 3 things exist. But you guaranteed nothing about implementation at all. Because of that the methods empty, insert, member are incredibly polymorphic. Which means I can continue to define new functions using these abstractions. So "insert list"
insertList list collection = foldr insert collection list
and I get an efficient operation involving a looping structure with no complexity at all.
Those tools do exist. Visual Basic, Ruby on Rails, Livecode....
You keep arguing for (a) by arguing for (b). A company most certainly can get resources for Erlang. As for your arguments regarding efficiency there have been tests again and again for decades that higher level languages increase efficiency. Programs which in practice become too difficult in imperative languages like Java are written all the time in functional languages.
If the developers were simply unwilling to learn to use new tools properly that certainly is a serious issue but that's a good argument for outsourcing the project away from that development team or being in a new team. It is not an argument for using the wrong tool.
I would agree that Haskell, LISP... can unquestionable provide outright "stuckage". No question. I'll grant that one. In an FP if the programmer who wrote the code is moderately more advanced than the person maintaining it than the maintainer will often have to do some serious learning to get the new code.
If you exclude that issue though shorter is easier. For example take parallelism. In pure FPs the parallel strategy is often a single operator located in a few key places in the code. You can just skip it, as a compiler directive. In imperative languages it is scattered all over the code and there is no way to skip.
Code that is 10-20x shorter is right off the bat quite a bit more readable.
Code that is structurally simple is quite a bit more readable.
Code that uses powerful abstractions can be much less readable till you get used to thinking that way.
I suspect the mixed paradigm languages will make functional techniques more popular. Heck they are having to introduce them into Java now they've become so popular. The .NET compiler is all functional. Javascript, Scala, Perl6, Ruby... are mixed paradigm. I think the change is happening.