If Common Lisp were really the "secret weapon" its proponents make it out to be, one would expect it to occasionally win contests like this. There are usually CL entrants in this contest, but they rarely do very well.
CLers then mutter things like your "the most active and talented lispers tend not to bother in the first place", implying that they could of course win if they wanted to, but that they are above all of that. Really? Okay, prove it by winning three times in a row. If CL gives its users the kind of advantage claimed, it shouldn't even require the "most active and talented" to do win.
This sort of nonsense, combined with the arrogant hostility of the CL community toward honest questions about the emperor's current wardrobe, are MAJOR reasons for CL's lack of popularity.
I've never been to Mars, but I know there are not any apple trees there.
Well, no, you really don't. It seems very unlikely that there are any apple trees on Mars, given what we do know, but you don't know. You (and I) merely assume so based on the evidence so far. Normally, that's fine and I wouldn't complain about the term "know", but in the context of a discussion regarding whether it is a waste to test things we already "know", it's good to remind ourselves that what we think we know are really just assumptions.
And your assumption about Martian apple trees is based on far less evidence than the assumption that time is absolute--an assumption that Einstein proved wrong, of course. And, frankly, I'd be less amazed by the discovery of apple trees on Mars than I still am about some of the findings of 20th century physics.
I think a lot of people would be surprised at how little tuition figures into covering the operating budget of a university.
And I think a lot of people would be surprised at how little of the operating budget of a university goes toward teaching the people paying the tuition.
Well, then my gain in real karma offsets my loss in Slashdot karma.;-)
Re: Ruby & Unicode -- a couple of years ago, Matz was routinely making anti-Unicode statements that made it clear how provincial and amateurish his internationalization ideas were. A lot of people were complaining, but he was shrugging it off with "it's my language, designed by me for my own work". I don't really want to get into the details because they would require writing more than I want to, but if you treat your Unicode encoding(s) as "just another encoding", your internationalization will almost always be retarded because your built-in text features can't assume enough about the nature of the text to do the right thing in any but the simplest cases. Beyond that, it's up to the app programmer to either employ more expertise than most non-specialists have or to decide (as is usually the case) that "we'll worry about 'international' later", resulting in an amateurish architecture.
Ruby may have gotten better in this respect due to pressure from others, but I walked away from it after hearing Matz's position(s) on these issues. If I have to deal with an amateurish platform, it will at least be a popular one that people will PAY me to deal with (like PHP).
Re: Ruby performance - My experience is similar to yours. They are *absolutely* and *always* working on performance, but performance is a very hard problem with dynamic languages and takes more resources than most small languages have available to them. Guido keeps wishing that someone would step forward and create a HotSpot-type JIT compiler for Python. He may have to wait for Microsoft and Python.Net (aka IronPython). I wouldn't hold my breath for Ruby, but Scheme has Big Loo, if you don't mind a language named Large Toilet.
Well, if you were in my shoes and starting this little quest from scratch as it were and given what you know today, what would you do?
Based on all you say, I AM in your shoes, or a reasonable facsimile thereof, and I've told you my conclusions.
Your list of requirements are all non-language issues, and I think they are very wise. I would add maturity of tools; availability of diverse, free, and well debugged libraries (similar to what you said); and popularity among programmers (for lots of reasons).
Unfortunately, this narrows things down to a VERY small set of languages, none of which will be unfamiliar to you. Among these, even Python is iffy. Python is great for smallish personal projects and for some not-too-busy Web apps, though, so I use it often.
Beyond that, the two languages I really want are mature versions of two currently embryonic languages: Paul Graham's Arc and Walter Bright's D (see digitalmars.com). The latter is much closer to a reality than the former, but both will take years (if ever) to mature. Arc is more interesting, but it's just party conversation, AFAICT.
D has a real chance, though. I find it almost as easy as Python (but it wouldn't be if I didn't know C), has dozens of great features, it can use existing C libraries as well as C can, a GCC front end is available making it very portable, its performance is faster than anything except C & asm (usually faster than C++), and it's free in every sense I care about (no cost for anything and open source where I want it to be). If you haven't already done so, check it out.
In a meeting I attended a few months ago, Guido said that one of his regrets was including too much "functional language" stuff in Python initially. Things like map, fold, etc. This was in the context of future directions of Python. He was also unenthusiastic about the idea of introducing macros into Python. The overall impression I got was that, despite the claims of Lispers that everything is getting more Lisplike, his intention was to make Python less Lisplike over time. I was quite frustrated by that as were a few others in the audience, but most attendees thought that was a splendid idea. I got the sense that he places a higher priority on ease of use for the masses than on what Lispers consider power for the elite.
Still, despite frustrating warts, I DO find Python easier to remember after a month of working in some OTHER language than something like Perl, so Python has replaced Perl in my toolbox as my Swiss Army Knife for on-the-spot, one-off applications. For those, lots of clever abstractions aren't necessary.
As for Ruby...I prefer the syntax to Python's, but it has three strikes against it from my perspective. One, Matz's attitude toward internationalization is the Japanese equivalent of the ASCII-only mentality of many English speaking developers. He has stated that internationalization (the ability to work smoothly in any combination of languages) is a lower priority to him than enabling him to work with the LEGACY Japanese text data that he personally works with frequently. This is HIS language, optimized for HIS needs, and to the extent that it turns out to be useful to others, they are welcome to use it, too. For someone like me, who needs to make applications work smoothly in all major languages, his provincial approach makes Ruby completely unsuitable for serious, professional applications, so I don't want to put too much time into it.
Two, Ruby's performance is far worse than even Python, and Python is pretty bad.
Three, Ruby's user community is not appreciably bigger than Scheme's, though it's growing faster. That means fewer and less mature libraries, tools, reusable source, etc.
And as far as macros, Matz has already stated that Lisp macros are "too powerful" in his opinion and are intentionally absent in order to make Ruby better for "ordinary users". If you love Lisp, the lets-keep-it-simple-for-the-masses comments from both Guido and Matz are not encouraging.
As for placing Ruby on the "power continuum", I wouldn't try to quantify it, but my sense is that it is above Python, but below more interesting languages like CL, Scheme, Haskell, OCaml, etc. I can't be more specific, because Matz's provincial attitudes about internationalization make it useless for me. It's not much more popular than Scheme, though -- not yet popular enough to have the mature tools, libs, and programmers needed for most commercial work.
So, if you are willing to suffer the costs of using a non-mainstream language, why not go with a more interesting language?
I think they DID find a cure. Didn't Picard win the Sexiest Man Alive contest in People Magazine one year? The "cure" for male pattern baldness in the 23rd Century is apparently what it has always been: power, fame, or fortune.
Do you know of a language besides Lisp that supports true macros? If so, I'll be there in a heartbeat as I don't really want to associate with such a conspicuously smug community if I can help it.
Great question & comment. Few serious developers are willing to put up with a developer community as dysfunctional as comp.lang.lisp if they don't have to, and these days nobody has to. Common Lisp seems to be an evolutionary dead end.
I can't imagine any other languages with the flexibility of Lisp that aren't just another form of Lisp, such as Common Lisp, Scheme, Arc, etc.
Common Lisp is a fossil. Scheme is a bunch of science projects by people who seem to want to know everything about programming languages except how to make them useful for real production. Arc is a collection of ideas to talk about at conferences and apparently nothing more.
Python has the right stuff from every perspective EXCEPT the language itself, where it is a faint shadow of the power of Common Lisp. I use it all the time, but it is a huge frustration to have such a limited language after using a real Lisp. The comp.lang.python community is a breath of fresh air after the misanthropes at comp.lang.lisp.
You may just have to use interesting languages like Lisp or Haskell for fun, and live with using mainstream languages for real work, applying techniques you learned from the more interesting languages when you can.
MS could afford to license full fledged Windows operating systems for FREE to certain strategic markets. Consider the Chinese cell phone market, for example. License the handset OS for free, then integrate it with an MS server OS that lets phone users buy things easily thru their phones. MS then tries to get a slice of the server-side commerce.
How else would MS make money in China? Giving the phone OS away for free could make a lot more money for them than attempts to sell their desktop OS & apps.
Their OS could make a phone into a digital music player, with music provided from the server for barely more than the cost of phone service alone, and no easy way to get the music off the phone. Cheap and easy to get any music you want for barely more than the cost of the phone you'd be paying anyway. So people in markets like China would be paying for music, too, and probably not caring too much.
And if this approach makes money for MS, they could do it worldwide. It's not as though it would be cannibalizing other MS sales, only cannibalizing Apple sales.
If you are going to use Lisp for anything practical, you have to deal with the fact than any programming platform you choose is a combination of base language, libraries, dev tools, documentation, implementations (at several levels), other programmers, etc.
The Lisp aspect that Lisp lovers (like me) tend to like most is in the most fundamental notions of the "idea of Lisp". A very small toolbox of ideas that are combinable in an amazingly flexible way, allowing a layering of totally customizable abstractions. The power of such an approach is intoxicating, leading to a real love of the language for so many people.
The basic ideas aren't the problem. They are so pure and simple that they are almost timeless, like a branch of mathematics.
Lisp's problem is that those ideas don't exist in a vacuum. When you need to use Lisp for practical purposes, you have to deal with all the other aspects that come along with a platform, and those are stuck in a time warp.
While the fundamental ideas of Lisp are as fresh today as ever, fresher than the ideas of more mainstream languages as any Lisper will tell you (endlessly), the non-fundamental aspects of Lisp, such as the myriad design decisions in the Common Lisp version of Lisp, reflect design decisions optimized for the constraints of the computing industry of the Apollo Space Program era.
The fresh, powerful, timeless, amazing ideas of Lisp are inseparably intertwined with obsolete baggage (technical and marketing) that users of mainstream languages don't want to, and don't have to, deal with.
A New Lisp, where the timeless aspects are retained, but the other design and marketing decisions reflected today's circumstances could be terrific. Paul Graham has been talking about that for years now, essentially preempting anybody else by increasing their risk of irrelevance while refusing to deliver so much as an annual status report.
Any mention of a New Lisp to Common Lispers is like throwing water on a cat. They hiss and shriek that Common Lisp is so close to perfection that nothing needs to be changed beyond "a few libraries". It seems they have to convince themselves of that because there is so little life in the Lisp community that no one CAN produce a new Lisp. They're stuck with the old one, so they elevate it to almost the status of a religion. Those who require a more modern complete system leave Lisp (for inferior languages in superior systems), and only the True Believers remain to console one another and hiss at outsiders who ask the natural questions about the emperor's wardrobe.
It became a development environment in version 1.0.
Can I use Excel to compile my C++, Java and C# apps?
It sounds as though you're confused about what software development really is.
None of the Lisp or Scheme dev systems I use are capable of compiling your C++, Java, and C# apps. Likewise for my copy of Mathematica. Or the IBM mainframe I started out with or my current favorite Python/IDE combo. It sounds as though you don't realize that software development is a lot broader, with a much wider diversity of styles and tools, than your limited experience has acquainted you with.
Excel is analogous to a scripting language in some ways, with easy scripting of powerful built-in functionality but certain semantics are represented visually instead of textually.
It is also a functional programming platform that those with experience in functional programming immediately recognize and know how to exploit to great advantage. This is not an accident. Early spreadsheet engine designers were more familiar with functional paradigms than are most "C++, Java, and C#" programmers these days, so today's newbie programmers often don't even recognize the nature of the platform they're looking at.
Excel is not a "platform". Excel is an application that you can control through Automation.
Sure, sure. And Oracle isn't a platform, is it? Or Mathematica, or Matlab, etc. They're just big applications that you control through automation.
Ah, I can tell you have limited development experience with _real_ applications that don't use Excel or Access as a "back-end".
Oh, the irony is rich....
Of course Excel is a platform, and an excellent one for certain types of work. I've used it for sophisticated and flexible financial modeling, nuclear effects data analysis, and genealogical data organization, among other things.
I do agree with you about the quality of the built-in functions, though. I think the poster you were responding to may not realize how poorly implemented some of those built in functions are, from a numerical methods perspective. I tend to write my own implementations, using Excel primitives, instead of using Excel's fancier functions (e.g., random num generation, internal rate of return, etc.), and there are times when I'll prototype in Excel but end up doing the production implementation partially in C. The same can be said for Python, though. It doesn't mean that Excel and Python aren't real platforms.
Unlike the GPL, Microsoft technology licenses are not viral. You pay for the right to use them in your own proprietary works. You can statically link MFC into your own Windows app without losing ownership of the resulting app to MS. You just don't own MFC. You can use MS fonts as you like, as long as you have a valid license, and any document you embed them in is still yours. (The FONT isn't yours, but you have some redistribution rights that you paid for.)
Crying "FUD!" or some anti-MS nonsense may pass for logical argument among GPL True Believers, but for others there are issues of substance to consider when basing commercial work on technologies with viral licenses.
And I say that as someone who uses GPL, non-viral Open Source (such as BSD, Apache, etc.), and commercial licenses for both commercial and personal work. I love some of my GPL'ed tools, and I acknowledge some possibility that I might not have had them if not for the viral nature of the GPL. Even so, there are times when, if you want to be "Free", you're better off paying for your own lunch than accepting a free one with strings attached.
They won't make their money from dividends or stock sales. They'll make their money from the difference between strike price of the stock option and the market price of a share.
They each will have several million options that allow them to buy Google stock for for a dollar or two per share. When they exercise those options, they will be getting a financial payment equal to the difference between the option price and the market price times the number of options.
That payment is considered ordinary income for "non-qualified" options--the kind regular employees get. They're not dividends, not capital gains, just income, and taxed accordingly.
Senior execs are usually given a different type of option ("qualified") that might allow them to save a bundle on taxes, but the rules are complex. What will happen to them instead is that they will get snagged by the Alternative Minimum Tax, which doesn't care how carefully you managed your tax liabilities.
Steve Jobs did this $1 salary thing a few years back at Apple when he rejoined as CEO. All of these people are billionaires. They don't care about personal taxes anymore. The point of it is to show investors and employees with options that they are so confident in a rising stock price that they are willing to tie 100% of their compensation to stock price appreciation. Of course, for billionaires, it's a bit of a stunt because they'll be rich no matter what.
mlyle is doing a great job explaining, but maybe I can say it in a different way.
You start at 100km above the ground and not moving relative to the ground. You end at 0km off the ground and again not moving relative to the ground.
In between you took the potential energy that you had at 100km and disposed of it...somehow. And that's a huge amount of energy for one little human body.
In the scenario being discussed, you fell for a long time through so little atmosphere that you accelerated to an extremely high velocity then began encountering enough atmosphere to stop your acceleration and cause your deceleration. Most of the deceleration would occur within a couple of minutes. It's like sliding down a very steep hill on wet ice, going faster and faster, then and at some point sliding off the ice and onto a carpet.
Your potential energy has turned into kinetic energy (so you still have most of it) and suddenly the friction increases and converts the kinetic into heat. If the conversion is sudden, it will fry you. Eventually, you'll reach the ground and cool off, but it'll be too late for you.
It's probably reasonable to assume that either the questioners or the majority of the respondants were thinking of desktop Linux.
Server Linux is very different in terms of perceptions and visibility. What operating system is in the thermostat on the wall or the office PBX or all of those little wifi access points? Who cares? Management doesn't have to train the staff in those operating systems.
The desktop OS is where all manner of daily activities are carried out by all sorts of employees doing a huge variety of different tasks. Marketing people need to be able to use the standard tools of their trade, as do accountants, as do the sales people, etc. The standard tools for all of them are Windows apps, and they can all be reasonably expected to know how to use Windows itself and the standard apps for their profession before they are even hired.
The fact that there may be an inferior knockoff of some of those standard apps available on Linux is no incentive to switch. These are apps that nobody in the company knows how to use and nobody they have to work with outside the company (advertising vendors, etc.) knows how to use. Why deal with the hassle? The fact that those inferior knockoffs are free doesn't matter when compared to the personnel costs and the need to get things done smoothly, quickly, and reliably.
And it should go without saying that the freedom to reprogram your own desktop apps is of very limited value to most people--even to busy programmers who are being paid to deliver company products, not hack their word processor's outliner features.
That's the reality, but it is a CURRENT reality in an ever changing world. On the server side, Linux apps are NOT inferior knockoffs--they are becoming the standards. If a few killer desktop apps appear for specialists that also become standards, and the ordinary "office" apps on Linux become the (real, not imagined) equals of their Windows equivalents, more people will switch. If enough people switch, it will weaken the "standard" argument for Windows, allowing the freedom arguments to become more persuasive.
I think time is on the side of Linux & open source, but Linux fans who call businesses stupid for not switching to desktop Linux now are pretty clueless.
Since you participated, could you tell us what programming languages the teams use for these contests? Does everyone use the same, or one of a specified list, or is it completely up to each team?
I agree completely. So what's the difference between this and any other compiler / code generator? There are Scheme implementations that compile to C. You "describe" the algorithms in a notation called Scheme, and the system "writes your C code for you". I usually use Python scripts to generate static array initialization code for great big C arrays. If the parameters change, I just rerun the Python and it "writes code" for me. If I draw a user interface with Visual Studio.Net, VS automatically generates all of my C# UI code for me.
So what's so new about this automatic code generation system that it could revolutionize the way code is written? Well, according to the article, it produces DSP code and it's called "Spiral". Hmm. I'm not fully satisfied with that explanation....
It's not just prestige. It's reasonable to assume that the aerospace industry--and human activity in general--will expand into orbit, then to the Moon, then Mars, then beyond, in layers, like the layers of an expanding onion.
There will be lonely robots with little support at the outer fringes, but each layer farther in you come, the more infrastructure, traffic, and activity you'll have. The innermost layer is full commercial and personal life: residence, travel, business, and play.
All of these layers are expanding outward, with each layer paving the way for the next layer to expand into its space. This has been happening for centuries. Lands that were once destinations only for government expeditions became destinations for powerful corporations then ordinary business and rich tourists, then anybody (from prosperous societies), with each group creating an infrastructure that enables the next.
We now have robots going to nearby bodies, early industry in earth orbit, and full commercial and personal travel off the surface (in the atmosphere). So next we send robots to farther bodies, expand early industry to the moon, and get full commercial and personal activity into low orbit.
The Japanese can see this long-term trend and intend to be full participants. It's not just "me, too" showmanship, and "why not just send robots?" doesn't make sense if you look at the big picture.
Thanks for pointing that out. It's clearly a Slashdotism for Evil Big Corporation. See, they are suing to protect their patents, so they must be evil, and we can prove it: they are known as a Weapons Manufacturer!
People who know of Honeywell either recognize the name from all of those thermostat covers, or they remember Honeywell, the computer company from back in the mainframe era. And all of the mainframe era computer companies (worldwide, not just US) did weapons systems work, built supermarket scanners, built CRT displays, manufactured chips, wrote OSes, and countless other things.
Honeywell they got involved in a three-continent joint venture/merger/acquisition deal (it evolved thru those stages) with Japan's NEC and France's Bull, and their computer business (and most of the company) went away. The deal didn't work out very well, and Bull ended up buying out the other partners.
Ironic that Java, famous for its sandbox, seems to be the door through which this intruder enters.
I keep wondering if it wouldn't be better to have something like VMWare a standard part of a consumer OS. You would intantiate a VMWare-type virtual machine, preloaded with your Web browser, email client, etc., for all external communications. You would leave your "real machine" with no Net connection, but use it for other tasks that didn't need a live Net connection. Attacks from the outside would have no way to damage anything other than a virtual machine. If it got screwed up or infected, even by your kids playing with it and saying "Yes" to download offers, you'd just delete it and instantiate a new one.
You'd be able to reach from the real machine into one of the VMs and retrieve a file that you were satisfied was safe, but there would be no way for a VM to export (VMWare is like this). There would be occasions when fetching an infected file would infect your real machine, but the overall incidence of external damage should be significantly reduced by this approach and recovery from screwups would be quick and easy (at a cost of performance for activities done from a VM).
It's just a thought, but it seems as though this would just be an extension of the Unix notion of having root power but doing most of your work from a non-root account just to be safe.
All such diatribes have one thing in common. They are about what it takes to get two groups to embrace Free Software: proprietary software vendors, and know-nothing bozos.
Wow, time for a Screed Part II.
The former will never embrace Free Software because, frankly, they have little to offer it, and less all the time.
No, the former (software vendors) are reluctant to embrace it, not because they have so litle to offer it but because they have so little to GAIN FROM IT.
Profit is revenue minus costs. The fragmentation of the market significantly raises costs.
And as long as the "I'm entitled to your work for free and the real heros are the ones who help me obtain it" ethos continues to pervade the Linux user community, those who make their living creating software for sale don't expect there will be much revenue.
Low revenues plus high costs.... But the 14 yr olds still living with Mama, the ones the article referred to, seem to consider themselves heroes of a revolution against those who work for a living, so it's hard for them to understand.
The question isn't whether ISVs have anything to contribute. Millions of users of useful Windows apps with no real equal on Linux know that they do. The real question is whether alternative business models will appear that provide equivalent incentive for the development of software to that currently driving commercial Windows ISVs. My experience as a user of both platforms is that for servers we're already there, but for general workstation use, we're not even close yet.
...and know-nothing bozos.
The "know-nothing bozos" referred to, of course, are the vast majority of human beings--the ones with lives too full of important things to leave much room for configuring computers.
Windows does a remarkably poor job of serving their needs, yet Linux can't hold a candle to Windows yet for serving most of them.
Though a very large percentage of the Linux community appears to have no life beyond configuring their systems, downloading porn, ripping off music, and demanding various "rights", the best and brightest in the community are far more impressive.
There are very smart people who care a great deal about making Linux as useful and convenient as possible for doctors trying to cure diseases, small business people trying to produce things of value, grandmothers too old to travel who and who live for pictures and news of their grandchildren, and so on.
Fortunately these savvy people have more than their proportional share of influence over developments in Linux and free software, so there is reason for optimism. But the armies of lifeless system configuring trolls who consider the living "know-nothing bozos" are a real achilles heel for Linux.
I didn't understand half of what you said. But it sounds like you're talking about implementation difficulties.
Let me take a stab at it. The most general, lowest-abstraction-level view is to simply treat text as a sequency of tokens (characters) that are either identical or not. There is no "different but equivalent" rule. If the characters aren't the same, they're different.
The notion that some characters are in some ways equivalent to other characters is a higher-level view that varies by locale, application, etc. (It's not wrong, it's just highly context dependent in ways that most developers don't know much about.)
These days data flows from environment to environment. Other cultures have different character equivalency rules, some of which get pretty complicated, and even English speakers have circumstances where 'a' and 'A' are not considered the same. There are also technical aspects of Unicode where certain sequences are "canonically equivalent" to others, having nothing to do with case.
The way to make things as simple and reliable as possible amidst this complexity is to simply have everyone go by the simple rule that if you want to make text the same, make it identical, otherwise it'll be considered different. Though at times it's a little less convenient, the simplicity of this approach makes it easy for everybody to get it right without having to understand potentially very complicated equivalency rules.
Single, standard, universal plain text format:
on
What's Wrong with Unix?
·
· Score: 0, Flamebait
Likewise not standardising some basic data-interchange formats (Even it was just pre-formated ASCII)...
Define the standard *nix system text encoding to be UTF-8. Require every tool to assume UTF-8 when no encoding or other modifiers are specified, and make UTF-8 support a requirement for every tool that wants to participate in the chaining/piping operations that are the backbone of *nix.
Terminal programs, terminal servers, shells, system fonts, cut/copy/paste, file system, GUIs, editors,...ALL use the same, consistent, universal plain text format everywhere, in every language. All characters, all the time, in all applications, on all forms of *nix.
Slashdot Mirror
If Common Lisp were really the "secret weapon" its proponents make it out to be, one would expect it to occasionally win contests like this. There are usually CL entrants in this contest, but they rarely do very well.
CLers then mutter things like your "the most active and talented lispers tend not to bother in the first place", implying that they could of course win if they wanted to, but that they are above all of that. Really? Okay, prove it by winning three times in a row. If CL gives its users the kind of advantage claimed, it shouldn't even require the "most active and talented" to do win.
This sort of nonsense, combined with the arrogant hostility of the CL community toward honest questions about the emperor's current wardrobe, are MAJOR reasons for CL's lack of popularity.
I've never been to Mars, but I know there are not any apple trees there.
Well, no, you really don't. It seems very unlikely that there are any apple trees on Mars, given what we do know, but you don't know. You (and I) merely assume so based on the evidence so far. Normally, that's fine and I wouldn't complain about the term "know", but in the context of a discussion regarding whether it is a waste to test things we already "know", it's good to remind ourselves that what we think we know are really just assumptions.
And your assumption about Martian apple trees is based on far less evidence than the assumption that time is absolute--an assumption that Einstein proved wrong, of course. And, frankly, I'd be less amazed by the discovery of apple trees on Mars than I still am about some of the findings of 20th century physics.
I think a lot of people would be surprised at how little tuition figures into covering the operating budget of a university.
And I think a lot of people would be surprised at how little of the operating budget of a university goes toward teaching the people paying the tuition.
Well, I do appreciate your answers.
;-)
Well, then my gain in real karma offsets my loss in Slashdot karma.
Re: Ruby & Unicode -- a couple of years ago, Matz was routinely making anti-Unicode statements that made it clear how provincial and amateurish his internationalization ideas were. A lot of people were complaining, but he was shrugging it off with "it's my language, designed by me for my own work". I don't really want to get into the details because they would require writing more than I want to, but if you treat your Unicode encoding(s) as "just another encoding", your internationalization will almost always be retarded because your built-in text features can't assume enough about the nature of the text to do the right thing in any but the simplest cases. Beyond that, it's up to the app programmer to either employ more expertise than most non-specialists have or to decide (as is usually the case) that "we'll worry about 'international' later", resulting in an amateurish architecture.
Ruby may have gotten better in this respect due to pressure from others, but I walked away from it after hearing Matz's position(s) on these issues. If I have to deal with an amateurish platform, it will at least be a popular one that people will PAY me to deal with (like PHP).
Re: Ruby performance - My experience is similar to yours. They are *absolutely* and *always* working on performance, but performance is a very hard problem with dynamic languages and takes more resources than most small languages have available to them. Guido keeps wishing that someone would step forward and create a HotSpot-type JIT compiler for Python. He may have to wait for Microsoft and Python.Net (aka IronPython). I wouldn't hold my breath for Ruby, but Scheme has Big Loo, if you don't mind a language named Large Toilet.
Well, if you were in my shoes and starting this little quest from scratch as it were and given what you know today, what would you do?
Based on all you say, I AM in your shoes, or a reasonable facsimile thereof, and I've told you my conclusions.
Your list of requirements are all non-language issues, and I think they are very wise. I would add maturity of tools; availability of diverse, free, and well debugged libraries (similar to what you said); and popularity among programmers (for lots of reasons).
Unfortunately, this narrows things down to a VERY small set of languages, none of which will be unfamiliar to you. Among these, even Python is iffy. Python is great for smallish personal projects and for some not-too-busy Web apps, though, so I use it often.
Beyond that, the two languages I really want are mature versions of two currently embryonic languages: Paul Graham's Arc and Walter Bright's D (see digitalmars.com). The latter is much closer to a reality than the former, but both will take years (if ever) to mature. Arc is more interesting, but it's just party conversation, AFAICT.
D has a real chance, though. I find it almost as easy as Python (but it wouldn't be if I didn't know C), has dozens of great features, it can use existing C libraries as well as C can, a GCC front end is available making it very portable, its performance is faster than anything except C & asm (usually faster than C++), and it's free in every sense I care about (no cost for anything and open source where I want it to be). If you haven't already done so, check it out.
Again, good questions.
In a meeting I attended a few months ago, Guido said that one of his regrets was including too much "functional language" stuff in Python initially. Things like map, fold, etc. This was in the context of future directions of Python. He was also unenthusiastic about the idea of introducing macros into Python. The overall impression I got was that, despite the claims of Lispers that everything is getting more Lisplike, his intention was to make Python less Lisplike over time. I was quite frustrated by that as were a few others in the audience, but most attendees thought that was a splendid idea. I got the sense that he places a higher priority on ease of use for the masses than on what Lispers consider power for the elite.
Still, despite frustrating warts, I DO find Python easier to remember after a month of working in some OTHER language than something like Perl, so Python has replaced Perl in my toolbox as my Swiss Army Knife for on-the-spot, one-off applications. For those, lots of clever abstractions aren't necessary.
As for Ruby...I prefer the syntax to Python's, but it has three strikes against it from my perspective. One, Matz's attitude toward internationalization is the Japanese equivalent of the ASCII-only mentality of many English speaking developers. He has stated that internationalization (the ability to work smoothly in any combination of languages) is a lower priority to him than enabling him to work with the LEGACY Japanese text data that he personally works with frequently. This is HIS language, optimized for HIS needs, and to the extent that it turns out to be useful to others, they are welcome to use it, too. For someone like me, who needs to make applications work smoothly in all major languages, his provincial approach makes Ruby completely unsuitable for serious, professional applications, so I don't want to put too much time into it.
Two, Ruby's performance is far worse than even Python, and Python is pretty bad.
Three, Ruby's user community is not appreciably bigger than Scheme's, though it's growing faster. That means fewer and less mature libraries, tools, reusable source, etc.
And as far as macros, Matz has already stated that Lisp macros are "too powerful" in his opinion and are intentionally absent in order to make Ruby better for "ordinary users". If you love Lisp, the lets-keep-it-simple-for-the-masses comments from both Guido and Matz are not encouraging.
As for placing Ruby on the "power continuum", I wouldn't try to quantify it, but my sense is that it is above Python, but below more interesting languages like CL, Scheme, Haskell, OCaml, etc. I can't be more specific, because Matz's provincial attitudes about internationalization make it useless for me. It's not much more popular than Scheme, though -- not yet popular enough to have the mature tools, libs, and programmers needed for most commercial work.
So, if you are willing to suffer the costs of using a non-mainstream language, why not go with a more interesting language?
I think they DID find a cure. Didn't Picard win the Sexiest Man Alive contest in People Magazine one year? The "cure" for male pattern baldness in the 23rd Century is apparently what it has always been: power, fame, or fortune.
Do you know of a language besides Lisp that supports true macros? If so, I'll be there in a heartbeat as I don't really want to associate with such a conspicuously smug community if I can help it.
Great question & comment. Few serious developers are willing to put up with a developer community as dysfunctional as comp.lang.lisp if they don't have to, and these days nobody has to. Common Lisp seems to be an evolutionary dead end.
I can't imagine any other languages with the flexibility of Lisp that aren't just another form of Lisp, such as Common Lisp, Scheme, Arc, etc.
Common Lisp is a fossil. Scheme is a bunch of science projects by people who seem to want to know everything about programming languages except how to make them useful for real production. Arc is a collection of ideas to talk about at conferences and apparently nothing more.
Python has the right stuff from every perspective EXCEPT the language itself, where it is a faint shadow of the power of Common Lisp. I use it all the time, but it is a huge frustration to have such a limited language after using a real Lisp. The comp.lang.python community is a breath of fresh air after the misanthropes at comp.lang.lisp.
You may just have to use interesting languages like Lisp or Haskell for fun, and live with using mainstream languages for real work, applying techniques you learned from the more interesting languages when you can.
MS could afford to license full fledged Windows operating systems for FREE to certain strategic markets. Consider the Chinese cell phone market, for example. License the handset OS for free, then integrate it with an MS server OS that lets phone users buy things easily thru their phones. MS then tries to get a slice of the server-side commerce.
How else would MS make money in China? Giving the phone OS away for free could make a lot more money for them than attempts to sell their desktop OS & apps.
Their OS could make a phone into a digital music player, with music provided from the server for barely more than the cost of phone service alone, and no easy way to get the music off the phone. Cheap and easy to get any music you want for barely more than the cost of the phone you'd be paying anyway. So people in markets like China would be paying for music, too, and probably not caring too much.
And if this approach makes money for MS, they could do it worldwide. It's not as though it would be cannibalizing other MS sales, only cannibalizing Apple sales.
You need to review...
You need to review...
You need to review...
You need to review...
You need to review...
Q.E.D.
It seems YOU need to review what constitutes a valid logical argument.
If you are going to use Lisp for anything practical, you have to deal with the fact than any programming platform you choose is a combination of base language, libraries, dev tools, documentation, implementations (at several levels), other programmers, etc.
The Lisp aspect that Lisp lovers (like me) tend to like most is in the most fundamental notions of the "idea of Lisp". A very small toolbox of ideas that are combinable in an amazingly flexible way, allowing a layering of totally customizable abstractions. The power of such an approach is intoxicating, leading to a real love of the language for so many people.
The basic ideas aren't the problem. They are so pure and simple that they are almost timeless, like a branch of mathematics.
Lisp's problem is that those ideas don't exist in a vacuum. When you need to use Lisp for practical purposes, you have to deal with all the other aspects that come along with a platform, and those are stuck in a time warp.
While the fundamental ideas of Lisp are as fresh today as ever, fresher than the ideas of more mainstream languages as any Lisper will tell you (endlessly), the non-fundamental aspects of Lisp, such as the myriad design decisions in the Common Lisp version of Lisp, reflect design decisions optimized for the constraints of the computing industry of the Apollo Space Program era.
The fresh, powerful, timeless, amazing ideas of Lisp are inseparably intertwined with obsolete baggage (technical and marketing) that users of mainstream languages don't want to, and don't have to, deal with.
A New Lisp, where the timeless aspects are retained, but the other design and marketing decisions reflected today's circumstances could be terrific. Paul Graham has been talking about that for years now, essentially preempting anybody else by increasing their risk of irrelevance while refusing to deliver so much as an annual status report.
Any mention of a New Lisp to Common Lispers is like throwing water on a cat. They hiss and shriek that Common Lisp is so close to perfection that nothing needs to be changed beyond "a few libraries". It seems they have to convince themselves of that because there is so little life in the Lisp community that no one CAN produce a new Lisp. They're stuck with the old one, so they elevate it to almost the status of a religion. Those who require a more modern complete system leave Lisp (for inferior languages in superior systems), and only the True Believers remain to console one another and hiss at outsiders who ask the natural questions about the emperor's wardrobe.
What a mess....
When did Excel become a development environment?
It became a development environment in version 1.0.
Can I use Excel to compile my C++, Java and C# apps?
It sounds as though you're confused about what software development really is.
None of the Lisp or Scheme dev systems I use are capable of compiling your C++, Java, and C# apps. Likewise for my copy of Mathematica. Or the IBM mainframe I started out with or my current favorite Python/IDE combo. It sounds as though you don't realize that software development is a lot broader, with a much wider diversity of styles and tools, than your limited experience has acquainted you with.
Excel is analogous to a scripting language in some ways, with easy scripting of powerful built-in functionality but certain semantics are represented visually instead of textually.
It is also a functional programming platform that those with experience in functional programming immediately recognize and know how to exploit to great advantage. This is not an accident. Early spreadsheet engine designers were more familiar with functional paradigms than are most "C++, Java, and C#" programmers these days, so today's newbie programmers often don't even recognize the nature of the platform they're looking at.
Excel is not a "platform". Excel is an application that you can control through Automation.
Sure, sure. And Oracle isn't a platform, is it? Or Mathematica, or Matlab, etc. They're just big applications that you control through automation.
Ah, I can tell you have limited development experience with _real_ applications that don't use Excel or Access as a "back-end".
Oh, the irony is rich....
Of course Excel is a platform, and an excellent one for certain types of work. I've used it for sophisticated and flexible financial modeling, nuclear effects data analysis, and genealogical data organization, among other things.
I do agree with you about the quality of the built-in functions, though. I think the poster you were responding to may not realize how poorly implemented some of those built in functions are, from a numerical methods perspective. I tend to write my own implementations, using Excel primitives, instead of using Excel's fancier functions (e.g., random num generation, internal rate of return, etc.), and there are times when I'll prototype in Excel but end up doing the production implementation partially in C. The same can be said for Python, though. It doesn't mean that Excel and Python aren't real platforms.
Unlike the GPL, Microsoft technology licenses are not viral. You pay for the right to use them in your own proprietary works. You can statically link MFC into your own Windows app without losing ownership of the resulting app to MS. You just don't own MFC. You can use MS fonts as you like, as long as you have a valid license, and any document you embed them in is still yours. (The FONT isn't yours, but you have some redistribution rights that you paid for.)
Crying "FUD!" or some anti-MS nonsense may pass for logical argument among GPL True Believers, but for others there are issues of substance to consider when basing commercial work on technologies with viral licenses.
And I say that as someone who uses GPL, non-viral Open Source (such as BSD, Apache, etc.), and commercial licenses for both commercial and personal work. I love some of my GPL'ed tools, and I acknowledge some possibility that I might not have had them if not for the viral nature of the GPL. Even so, there are times when, if you want to be "Free", you're better off paying for your own lunch than accepting a free one with strings attached.
They won't make their money from dividends or stock sales. They'll make their money from the difference between strike price of the stock option and the market price of a share.
They each will have several million options that allow them to buy Google stock for for a dollar or two per share. When they exercise those options, they will be getting a financial payment equal to the difference between the option price and the market price times the number of options.
That payment is considered ordinary income for "non-qualified" options--the kind regular employees get. They're not dividends, not capital gains, just income, and taxed accordingly.
Senior execs are usually given a different type of option ("qualified") that might allow them to save a bundle on taxes, but the rules are complex. What will happen to them instead is that they will get snagged by the Alternative Minimum Tax, which doesn't care how carefully you managed your tax liabilities.
Steve Jobs did this $1 salary thing a few years back at Apple when he rejoined as CEO. All of these people are billionaires. They don't care about personal taxes anymore. The point of it is to show investors and employees with options that they are so confident in a rising stock price that they are willing to tie 100% of their compensation to stock price appreciation. Of course, for billionaires, it's a bit of a stunt because they'll be rich no matter what.
mlyle is doing a great job explaining, but maybe I can say it in a different way.
You start at 100km above the ground and not moving relative to the ground. You end at 0km off the ground and again not moving relative to the ground.
In between you took the potential energy that you had at 100km and disposed of it...somehow. And that's a huge amount of energy for one little human body.
In the scenario being discussed, you fell for a long time through so little atmosphere that you accelerated to an extremely high velocity then began encountering enough atmosphere to stop your acceleration and cause your deceleration. Most of the deceleration would occur within a couple of minutes. It's like sliding down a very steep hill on wet ice, going faster and faster, then and at some point sliding off the ice and onto a carpet.
Your potential energy has turned into kinetic energy (so you still have most of it) and suddenly the friction increases and converts the kinetic into heat. If the conversion is sudden, it will fry you. Eventually, you'll reach the ground and cool off, but it'll be too late for you.
It's probably reasonable to assume that either the questioners or the majority of the respondants were thinking of desktop Linux.
Server Linux is very different in terms of perceptions and visibility. What operating system is in the thermostat on the wall or the office PBX or all of those little wifi access points? Who cares? Management doesn't have to train the staff in those operating systems.
The desktop OS is where all manner of daily activities are carried out by all sorts of employees doing a huge variety of different tasks. Marketing people need to be able to use the standard tools of their trade, as do accountants, as do the sales people, etc. The standard tools for all of them are Windows apps, and they can all be reasonably expected to know how to use Windows itself and the standard apps for their profession before they are even hired.
The fact that there may be an inferior knockoff of some of those standard apps available on Linux is no incentive to switch. These are apps that nobody in the company knows how to use and nobody they have to work with outside the company (advertising vendors, etc.) knows how to use. Why deal with the hassle? The fact that those inferior knockoffs are free doesn't matter when compared to the personnel costs and the need to get things done smoothly, quickly, and reliably.
And it should go without saying that the freedom to reprogram your own desktop apps is of very limited value to most people--even to busy programmers who are being paid to deliver company products, not hack their word processor's outliner features.
That's the reality, but it is a CURRENT reality in an ever changing world. On the server side, Linux apps are NOT inferior knockoffs--they are becoming the standards. If a few killer desktop apps appear for specialists that also become standards, and the ordinary "office" apps on Linux become the (real, not imagined) equals of their Windows equivalents, more people will switch. If enough people switch, it will weaken the "standard" argument for Windows, allowing the freedom arguments to become more persuasive.
I think time is on the side of Linux & open source, but Linux fans who call businesses stupid for not switching to desktop Linux now are pretty clueless.
How about this: He stays, and YOU leave.
Since you participated, could you tell us what programming languages the teams use for these contests? Does everyone use the same, or one of a specified list, or is it completely up to each team?
I agree completely. So what's the difference between this and any other compiler / code generator? There are Scheme implementations that compile to C. You "describe" the algorithms in a notation called Scheme, and the system "writes your C code for you". I usually use Python scripts to generate static array initialization code for great big C arrays. If the parameters change, I just rerun the Python and it "writes code" for me. If I draw a user interface with Visual Studio.Net, VS automatically generates all of my C# UI code for me.
So what's so new about this automatic code generation system that it could revolutionize the way code is written? Well, according to the article, it produces DSP code and it's called "Spiral". Hmm. I'm not fully satisfied with that explanation....
It's not just prestige. It's reasonable to assume that the aerospace industry--and human activity in general--will expand into orbit, then to the Moon, then Mars, then beyond, in layers, like the layers of an expanding onion.
There will be lonely robots with little support at the outer fringes, but each layer farther in you come, the more infrastructure, traffic, and activity you'll have. The innermost layer is full commercial and personal life: residence, travel, business, and play.
All of these layers are expanding outward, with each layer paving the way for the next layer to expand into its space. This has been happening for centuries. Lands that were once destinations only for government expeditions became destinations for powerful corporations then ordinary business and rich tourists, then anybody (from prosperous societies), with each group creating an infrastructure that enables the next.
We now have robots going to nearby bodies, early industry in earth orbit, and full commercial and personal travel off the surface (in the atmosphere). So next we send robots to farther bodies, expand early industry to the moon, and get full commercial and personal activity into low orbit.
The Japanese can see this long-term trend and intend to be full participants. It's not just "me, too" showmanship, and "why not just send robots?" doesn't make sense if you look at the big picture.
Thanks for pointing that out. It's clearly a Slashdotism for Evil Big Corporation. See, they are suing to protect their patents, so they must be evil, and we can prove it: they are known as a Weapons Manufacturer!
People who know of Honeywell either recognize the name from all of those thermostat covers, or they remember Honeywell, the computer company from back in the mainframe era. And all of the mainframe era computer companies (worldwide, not just US) did weapons systems work, built supermarket scanners, built CRT displays, manufactured chips, wrote OSes, and countless other things.
Honeywell they got involved in a three-continent joint venture/merger/acquisition deal (it evolved thru those stages) with Japan's NEC and France's Bull, and their computer business (and most of the company) went away. The deal didn't work out very well, and Bull ended up buying out the other partners.
Ironic that Java, famous for its sandbox, seems to be the door through which this intruder enters.
I keep wondering if it wouldn't be better to have something like VMWare a standard part of a consumer OS. You would intantiate a VMWare-type virtual machine, preloaded with your Web browser, email client, etc., for all external communications. You would leave your "real machine" with no Net connection, but use it for other tasks that didn't need a live Net connection. Attacks from the outside would have no way to damage anything other than a virtual machine. If it got screwed up or infected, even by your kids playing with it and saying "Yes" to download offers, you'd just delete it and instantiate a new one.
You'd be able to reach from the real machine into one of the VMs and retrieve a file that you were satisfied was safe, but there would be no way for a VM to export (VMWare is like this). There would be occasions when fetching an infected file would infect your real machine, but the overall incidence of external damage should be significantly reduced by this approach and recovery from screwups would be quick and easy (at a cost of performance for activities done from a VM).
It's just a thought, but it seems as though this would just be an extension of the Unix notion of having root power but doing most of your work from a non-root account just to be safe.
Wow, time for a Screed Part II.
The former will never embrace Free Software because, frankly, they have little to offer it, and less all the time.
No, the former (software vendors) are reluctant to embrace it, not because they have so litle to offer it but because they have so little to GAIN FROM IT.
Profit is revenue minus costs. The fragmentation of the market significantly raises costs.
And as long as the "I'm entitled to your work for free and the real heros are the ones who help me obtain it" ethos continues to pervade the Linux user community, those who make their living creating software for sale don't expect there will be much revenue.
Low revenues plus high costs.... But the 14 yr olds still living with Mama, the ones the article referred to, seem to consider themselves heroes of a revolution against those who work for a living, so it's hard for them to understand.
The question isn't whether ISVs have anything to contribute. Millions of users of useful Windows apps with no real equal on Linux know that they do. The real question is whether alternative business models will appear that provide equivalent incentive for the development of software to that currently driving commercial Windows ISVs. My experience as a user of both platforms is that for servers we're already there, but for general workstation use, we're not even close yet.
The "know-nothing bozos" referred to, of course, are the vast majority of human beings--the ones with lives too full of important things to leave much room for configuring computers.
Windows does a remarkably poor job of serving their needs, yet Linux can't hold a candle to Windows yet for serving most of them.
Though a very large percentage of the Linux community appears to have no life beyond configuring their systems, downloading porn, ripping off music, and demanding various "rights", the best and brightest in the community are far more impressive.
There are very smart people who care a great deal about making Linux as useful and convenient as possible for doctors trying to cure diseases, small business people trying to produce things of value, grandmothers too old to travel who and who live for pictures and news of their grandchildren, and so on.
Fortunately these savvy people have more than their proportional share of influence over developments in Linux and free software, so there is reason for optimism. But the armies of lifeless system configuring trolls who consider the living "know-nothing bozos" are a real achilles heel for Linux.
I didn't understand half of what you said. But it sounds like you're talking about implementation difficulties.
Let me take a stab at it. The most general, lowest-abstraction-level view is to simply treat text as a sequency of tokens (characters) that are either identical or not. There is no "different but equivalent" rule. If the characters aren't the same, they're different.
The notion that some characters are in some ways equivalent to other characters is a higher-level view that varies by locale, application, etc. (It's not wrong, it's just highly context dependent in ways that most developers don't know much about.)
These days data flows from environment to environment. Other cultures have different character equivalency rules, some of which get pretty complicated, and even English speakers have circumstances where 'a' and 'A' are not considered the same. There are also technical aspects of Unicode where certain sequences are "canonically equivalent" to others, having nothing to do with case.
The way to make things as simple and reliable as possible amidst this complexity is to simply have everyone go by the simple rule that if you want to make text the same, make it identical, otherwise it'll be considered different. Though at times it's a little less convenient, the simplicity of this approach makes it easy for everybody to get it right without having to understand potentially very complicated equivalency rules.
Thanks
Likewise not standardising some basic data-interchange formats (Even it was just pre-formated ASCII)...
...ALL use the same, consistent, universal plain text format everywhere, in every language. All characters, all the time, in all applications, on all forms of *nix.
Define the standard *nix system text encoding to be UTF-8. Require every tool to assume UTF-8 when no encoding or other modifiers are specified, and make UTF-8 support a requirement for every tool that wants to participate in the chaining/piping operations that are the backbone of *nix.
Terminal programs, terminal servers, shells, system fonts, cut/copy/paste, file system, GUIs, editors,