A single, large power plant is far more efficient than thousands/millions of small engines.
You are correct, as are the others who corrected me. My post was a knee-jerk reaction to people equating "electric" with "absolutely clean and free power," which certainly isn't true. It is much better than the current situation, of course.
I'm still waiting for infra-red solar to get out of the research phase.
I didn't realize Ars Technica had automotive experts in addition to video card experts:P
Anyhow, electric cars may avoid the gasoline problem up front, but they still need to get electricity from *somewhere*. In most areas, that electricity isn't coming from solar or wind power, making them not as oh-so-envioronmentally friendly as some people like to think. Better, yes, but more of a dodge than a solution.
Oh, wow. What you say might sound so sensible, but, I am afraid, is so very wrong. My point is that once you really do embrace typeful programming (in the sense of Luca Cardelli, or beyond...), then all of these kinds of types might make perfect sense.
This is the kind of thing that scares people away from FP.
What's you're suggesting is pedantic in the extreme. In OOP, the complexity moves from raw code into the class hierarchy. That is, the code may look simple, but there's an elaborate framework that you need to understand as well. In the type of programming you're proposing, the complexity moves into the type system. Once you've painstakingly developed all the types you need, including algebraic properties and restrictions, then you've done most of the work. The resulting code may look simple, but, again, there's complexity elsewhere.
In general, it is a mistake to build up fancy mechanisms for simple tasks. In most programming, the typing is very simple. I find it easier to develop a program without regard to type, and then put the types in later. Otherwise I'm doing extra work for a prototype that may, in the end, be incorrect. Imagine if you couldn't just email a note to someone without diagramming each sentence to show that it is, in fact, grammatically correct. To a linguist, yes, maybe that is interesting, but not to everyone else. Programming is not the same as programming language theory. If it were, then no one would ever have been able to write code in C, C++, assembly, or Lisp, as those languages don't force you to specify every step of the way.
The reality here is that it's not the "functional" aspect of such languages that programmers really want, it's the other biggies: garbage collection, lack of declarations, built-in support for hash tables, interactive development environment, and so on. If an imperative language had all of these, most programmers wouldn't feel the need to get the rest of what functional programming provides: higher-order functions, currying, provability, laziness, monads. And there are already languages that provide the features that are most wanted including, notably, Python.
> it is harder to argue that ML is more productive > than Erlang or pure Lisp, for example, based on > static vs. dynamic typing.
Really? I find static typing to be a huge help in debugging my programs. I wouldn't give it up for anything! It may come at the intellectual overhead of learning the type system, but once you do it really does make sense.
Really:) Compared to C, both ML and Lisp provide interactive development, garbage collection, higher order functions, and less bookkeeping clutter. With all of that on the table, with both languages far beyond C in those ways, it is difficult to tell how much of an issue the type system plays in productivity. You will find many notable experts who prefer dynamic typing (Peter Norvig and Kent Pitman, for example), and you will find many other notable experts who prefer static typing. So it is more of a personal preference than anything else.
Yes, but that's bad design. You could have different types for co-ordinates, and for lengths. My experience with Haskell and ML has overwhelmingly led me to believe that strict type systems are a good thing.
Yes, but while types are a good thing, there's a limit. No one wants to take this to the extreme, and have a type for odd integers, a type for the number of students in a class (as opposed to the number of books in a library), and so on. After a while, being pedantic ceases to pay off. Actually, it ceases to pay off rather quickly, I think.
The typing issue is confused by all the other benefits that functional programming languages provide. While there is good reason to belive that ML and Haskell are better suited to many problems than C, it is harder to argue that ML is more productive than Erlang or pure Lisp, for example, based on static vs. dynamic typing.
Arrogance. There is an annoying elitism among functional programming proponents, implying that all current Perl and Python and C++ programmers are wrong. Similarly, Linux zealots refuse to believe that multi-billion dollar corporations are being run using Windows 98 and NT.
Fragmentation and infighting. Some FP proponents insist that functional laziness is the key. Others think that laziness is unpredictable and does more harm than good. Some FP proponents insist that static typing systems are The Only Way. Others are very productive with dynamic typing and ignore the first group. Some FP proponents thing that uniqueness types or monads are the correct way to introduce the concept of state into a purely functional framework. Others don't care as much about purity, preferring to have imperative features readily available. Similarly, Linux zealots fight about distributions, text editors, and window managers.
Ignorance of what the market wants. Many FP language developers would prefer to do research on new type systems, rather than create useful libraries. Many think that language choice is more important than tool choice, as if ML would somehow be better at GUI-driven applications than Delphi. Similarly, Linux zealots think that operating system choice is more important than application choice, and many would prefer to live in a backward 1970s terminal window world without trying to understand why many people don't want to.
That's quite a claim. References? By what measure? Lines of code? Useless. Number of projects started? Please. Function points? What? Back up this claim or let VB molder in the grave it deserves.
Number of projects. I've seen this mentioned in several sources--yes, one of which was from Microsoft--but I can believe it. I should clarify that the correct statistic is "60% of all new *desktop* applications are written in Visual Basic." The majority of all software is still written for embedded systems, not desktops.
Most desktop software consists of so-called enterprise applications: database front ends, form-filling programs, time reporting programs, sales trackers, etc. Visual Basic makes sense here.
Everyone who's used ML can attest to this fact: once your programs typecheck, they Just Work.
This is a myth. I agree that it does prevent certain types of errors, but not others. For example, suppose you have a function that draws a rectangle: rect(x,y,width,height). You forget and pass the parameters like this instead(x,width,y,height). The type system won't catch the error, because all the values are integers. These kinds of errors are at least as common. I'll agree that catching some errors is better than none, but the ones that are caught come at the expense of a possibly elaborate type system; a type system whose complexity may not be worth the benefit.
I've thought about this issue a good amount over the last few years. Here's my take:
1. While certain complex algorithms are much easier to express in Haskell, there are many, many times when you really just want to do something imperative. Haskell has a way of wrapping imperative operations into a functional framework, and though it may be theoretically beautiful it comes across as contrived. I think issues like this come up enough that it is easier to use an imperative language and struggle with the parts that should be written functionally, than to use a functional language and struggle with the parts that should be written imperatively.
2. The developers of functional languages are living in a theoretical world in which many topics seem very important, topics that people doing actual programming see as minor issues. Static typic systems come at the top of the list. Proof systems are another.
3. Many functional language proponents have fooled themselves into thinking that imperative programming is so low-level and dangerous as to be all but impossible. Truth is, there have been people writing complex video games in hundreds of thousands of lines of 16-bit assembly code, games that shipped on consoles and had no known bugs (examples: Donkey Kong Country, Sonic the Hedgehog 3, NBA Jam, Crusin' USA). So, yes, Haskell may let you write a Quicksort in three lines of code, but there's more to programming than that. You could equally fool yourself into thinking that cars are too dangerous to drive, because there's no safety mechanism preventing one from veering into another.
4. In all honesty, relatively few people are doing classic programming any more. Most programmers do things like database interfacing, GUI tool building using Delphi or Visual Basic (data point: 60% of all new software is written in Visual Basic), CGI scripting, etc. Not too many programmers find themselves needing to do something algorithmically tricky, like handling red-black trees or dealing with weighted graphcs.
I like functional languages for certain types of problems, but it isn't too difficult to see why they haven't caught on in a bigger way.
Did you actually *look* at the screen for this comparison?
Arguably, this is because X ships with some of the most unaesthetic fonts I have ever seen. Mac and Windows fonts are much nicer, though I hate to admit it.
I think the real problem is that Gas has been so cheap in the US for so long. We have had it WAY too good.
It is like this with a lot of things. People scramble for huge home entertainment centers, pointlessly fast PCs with monster monitors, and every appliance under the sun. That's because electricity isn't outrageously expensive here. If it were, you'd start seeing a turn toward to realistic.
The astounding thing about X is how much code it needs to do almost nothing. Window management is up to a window manager. Hardware specific code is up to a device driver. Gadgets and such are up to higher-level libraries like Qt. Standard GUI niceties are left up to desktop environments, like KDE and Gnome.
The truth is that it takes very little code to do what X does. One of the most minimal windows managers for X, Blackbox, is approximately 12,000 lines of C++ (the author likes to give a line count). Think about that. 12,000 lines of code to simply act as an interface between you an X in a very minimal way. You could write an entire GUI, including hardware-specific code, in 12,000 lines. Maybe it wouldn't be KDE, but it shows how far off base we've become. Don't believe it? here is a functioning GUI, which doesn't use any external libraries for graphics, done in a few kilobytes of object code.
Corel has taken a big chance on Linux, and so far they've spent a lot of time and money without earning anything back. WordPerfect and Photo Paint are excellent, but are being given away free. WINE isn't a commercial product. Corel Linux is still very new and is being piffed by the Linux die-hards as "Linux for weenies." It will come around, but it will take time.
Remember, Corel is a decent sized company with bills to pay. It isn't the same as a freebie consulting service that eventually earned a reputation and the ability to charge money. The latter is more typical of Linux-oriented businesses.
You're missing the point. When someone reviews an application or game for Windows, the reviewer doesn't stop to think about Mac vs. PC vs. UNIX. It is irrelevant. But many Linux users, at least an overly vocal minority, fixate on the Us vs. Them angle and absolutely cannot stand to think that something for Linux might not be as up to snuff as a product for another OS. I can't say I've seen this in reviews for commercial software, but you see it commonly on Usenet and right here at Slashdot. Raving loons insisting that The Gimp blows away Photoshop or that Emacs does everything that Word does and more, that gcc + make + Emacs is superior to Visual C++ and Codewarrior. Sometimes they're right, but often they're reporting blind, without having tried the equivalent Windows product. In many cases, I suspect that people are simply spewing the thoughts of others, and people who've never set up a server are raving about how wonderful Apache is or people who can't program go on about how Open Source enables bugs to be fixed quickly.
It takes you thirteen seconds to come up with the "specific usability goals" thought. This guy asks you for specifics (ie the menu in panel thing). You come back with more rants. If you have nothing more than "I want something different. I don't know what, just different, and usable. Now get to work all you hackers," then you have nothing to contribute to the world.
You missed the point completely. The point is that it big changes to KDE are no longer so easy, now that large companies are beginning to lean on it. Look at it this way: If KDE were changed dramatically--for the better--it immediately invalidates half a dozen "How to use KDE" books.
What I would like is simply a user interface designed for *usability* rather than twiddling. There are good books on the subject that can be used as templates, such as this one or the one by a Microsoft Windows architect who realized that Windows interface was going off in the wrong direction (I forget the name; it is currently in print). It is simply a matter of the KDE (and Gnome) people ignoring what's out there, trying to out do Microsoft at their own game, and missing the point entirely.
I think the reason Open Media is dominated by youth probably has as much to do with younger folks' higher learning curve, as it does with the fact they don't have the money to buy all the stuff they get for free.
Plus they have "free" T1 connections at school and more time to surf.
I don't know if it comes from using PDAs and emulators for 8-bit home computers, but I'm actually starting to prefer lowish resolutions on small monitors. Maybe it's just the realization that I'm usually staring at a small window in the center of a large, expensive, EMF emitting monitor. Along the same lines, I'm starting to see anti-aliased text as *fuzzy* rather than smoother. I was using an Atari 800 emulator the other day, believe it or not, I really got into the sharp, chunky feel of the text.
I'm shocked...seriously, I'd be really curious to hear if anyone specifically knows of any large projects in recent time that have written in Pascal?
There's quite a bit of Windows software written using Pascal. Some commercial games, even.
The three things that make Pascal a wonderful development language are:
1. Very tight module control. You don't need separate header files. Everything is very clean and organized.
2. Less temptation to trivially optimize code by using inline functions and pointer math and such and multiple ways of phrasing simple expressions. I find there's less mental baggage associated with Pascal programming than in C++.
3. Lightning fast compiles. Big projects, ie. 200,000 lines, rebuild completely in 20 seconds or so. Normal "bring project up to date" operations are instantaneous. This is over an order of magnitude better than any C++ compiler I've used.
C) Do you have a better coherent vision of what a UI should be? If so, why have you done nothing about it? Do you really think that bitching about other people's work does any good?
Ah, the stock reply: "Do it yourself!" The trouble with big systems like KDE is that they take a long time to build up momentum and then they're unstoppable (a la Windows). I could come up with alternatives. So could other people. But if Corel and Borland and other companies with a lot of money at stake choose KDE, then that's going to make KDE the most viable option for most people, simply because it has the biggest elephants behind it. In the end, we'll wish for something better but settle for KDE, just as we've been doing with Windows all these years.
It is mildly frustrating that both leading GUI efforts are from the Windows school. That is, both are very geared toward fiddly gadgets and customizing themselves rather than having specific usability goals in mind. Note: I know about Blackbox (which I use) and Sawmill and such, but those are raw window managers for X and nothing more.
Now that Kylix seems to be locking into Qt and Corel has chosen KDE, there looks to be less opportunity for something cleaner and more user-oriented to come along. Even if someone were working in a different direction, they have a lot of corporate momentum to overcome. That's why most people are using Windows in the first place, unfortunately.
Why is it I keep seeing posts regarding why MS, etc should open up their sources so people can grab the source code and make something better of their own?
And it's not like it's remotely easy to pick up 250,000 lines of source and make something better. I work on huge projects during the day, and it's common for a programmer on the project to misunderstand an interface subtlety and make a mistake that shows up later down the road. And this with experience working on a code base full-time.
One of the great myths of open source is that it makes bug fixes and enhancements easy.
Good stuff, but the whole hook of Borland's compilers has always been the speed of compilation. Delphi is up near a million lines a minute on an average machine (300MHz). If FPC is more in line with gcc, then there's no reason to switch (for me).
A typical day for many people includes one to two hours of checking web sites and answering unimportant email. The result is that they have 25% less time to do their normal work in. ICQ is another intrusion. It makes you feel like you need to interrupt what you're doing and respond. When you come down to it, most ICQ and email intrusions and web sites have no direct value. If you decided to just do your job and not check Slashdot (or whatever) daily, then after a month you'd find that you really didn't miss anything. Somebody posted some misleading benchmarks and there was heated debate. Gnome or KDE or Apache or the kernel had a minor patch that doesn't benefit you. Some new graphics card or CPU got 5% faster, though nobody cares because the price is too high or the drivers are crappy. There were some supposed breakthroughs in genetics or quantum computing or somesuch that doesn't have a relation to anything tangible (i.e. it's vaporware). I bet you get more done during that month than the previous two.
Slashdot Mirror
A single, large power plant is far more efficient than thousands/millions of small engines.
You are correct, as are the others who corrected me. My post was a knee-jerk reaction to people equating "electric" with "absolutely clean and free power," which certainly isn't true. It is much better than the current situation, of course.
I'm still waiting for infra-red solar to get out of the research phase.
I didn't realize Ars Technica had automotive experts in addition to video card experts :P
Anyhow, electric cars may avoid the gasoline problem up front, but they still need to get electricity from *somewhere*. In most areas, that electricity isn't coming from solar or wind power, making them not as oh-so-envioronmentally friendly as some people like to think. Better, yes, but more of a dodge than a solution.
Oh, wow. What you say might sound so sensible, but, I am afraid, is so very wrong. My point is that once you really do embrace typeful programming (in the sense of Luca Cardelli, or beyond...), then all of these kinds of types might make perfect sense.
This is the kind of thing that scares people away from FP.
What's you're suggesting is pedantic in the extreme. In OOP, the complexity moves from raw code into the class hierarchy. That is, the code may look simple, but there's an elaborate framework that you need to understand as well. In the type of programming you're proposing, the complexity moves into the type system. Once you've painstakingly developed all the types you need, including algebraic properties and restrictions, then you've done most of the work. The resulting code may look simple, but, again, there's complexity elsewhere.
In general, it is a mistake to build up fancy mechanisms for simple tasks. In most programming, the typing is very simple. I find it easier to develop a program without regard to type, and then put the types in later. Otherwise I'm doing extra work for a prototype that may, in the end, be incorrect. Imagine if you couldn't just email a note to someone without diagramming each sentence to show that it is, in fact, grammatically correct. To a linguist, yes, maybe that is interesting, but not to everyone else. Programming is not the same as programming language theory. If it were, then no one would ever have been able to write code in C, C++, assembly, or Lisp, as those languages don't force you to specify every step of the way.
The reality here is that it's not the "functional" aspect of such languages that programmers really want, it's the other biggies: garbage collection, lack of declarations, built-in support for hash tables, interactive development environment, and so on. If an imperative language had all of these, most programmers wouldn't feel the need to get the rest of what functional programming provides: higher-order functions, currying, provability, laziness, monads. And there are already languages that provide the features that are most wanted including, notably, Python.
> it is harder to argue that ML is more productive
> than Erlang or pure Lisp, for example, based on
> static vs. dynamic typing.
Really? I find static typing to be a huge help in debugging my programs. I wouldn't give it up for anything! It may come at the intellectual overhead of learning the type system, but once you do it really does make sense.
Really
Yes, but that's bad design. You could have different types for co-ordinates, and for lengths. My experience with Haskell and ML has overwhelmingly led me to believe that strict type systems are a good thing.
Yes, but while types are a good thing, there's a limit. No one wants to take this to the extreme, and have a type for odd integers, a type for the number of students in a class (as opposed to the number of books in a library), and so on. After a while, being pedantic ceases to pay off. Actually, it ceases to pay off rather quickly, I think.
The typing issue is confused by all the other benefits that functional programming languages provide. While there is good reason to belive that ML and Haskell are better suited to many problems than C, it is harder to argue that ML is more productive than Erlang or pure Lisp, for example, based on static vs. dynamic typing.
Arrogance. There is an annoying elitism among functional programming proponents, implying that all current Perl and Python and C++ programmers are wrong. Similarly, Linux zealots refuse to believe that multi-billion dollar corporations are being run using Windows 98 and NT.
Fragmentation and infighting. Some FP proponents insist that functional laziness is the key. Others think that laziness is unpredictable and does more harm than good. Some FP proponents insist that static typing systems are The Only Way. Others are very productive with dynamic typing and ignore the first group. Some FP proponents thing that uniqueness types or monads are the correct way to introduce the concept of state into a purely functional framework. Others don't care as much about purity, preferring to have imperative features readily available. Similarly, Linux zealots fight about distributions, text editors, and window managers.
Ignorance of what the market wants. Many FP language developers would prefer to do research on new type systems, rather than create useful libraries. Many think that language choice is more important than tool choice, as if ML would somehow be better at GUI-driven applications than Delphi. Similarly, Linux zealots think that operating system choice is more important than application choice, and many would prefer to live in a backward 1970s terminal window world without trying to understand why many people don't want to.
That's quite a claim. References? By what measure? Lines of code? Useless. Number of projects started? Please. Function points? What? Back up this claim or let VB molder in the grave it deserves.
Number of projects. I've seen this mentioned in several sources--yes, one of which was from Microsoft--but I can believe it. I should clarify that the correct statistic is "60% of all new *desktop* applications are written in Visual Basic." The majority of all software is still written for embedded systems, not desktops.
Most desktop software consists of so-called enterprise applications: database front ends, form-filling programs, time reporting programs, sales trackers, etc. Visual Basic makes sense here.
Everyone who's used ML can attest to this fact: once your programs typecheck, they Just Work.
This is a myth. I agree that it does prevent certain types of errors, but not others. For example, suppose you have a function that draws a rectangle: rect(x,y,width,height). You forget and pass the parameters like this instead(x,width,y,height). The type system won't catch the error, because all the values are integers. These kinds of errors are at least as common. I'll agree that catching some errors is better than none, but the ones that are caught come at the expense of a possibly elaborate type system; a type system whose complexity may not be worth the benefit.
I've thought about this issue a good amount over the last few years. Here's my take:
1. While certain complex algorithms are much easier to express in Haskell, there are many, many times when you really just want to do something imperative. Haskell has a way of wrapping imperative operations into a functional framework, and though it may be theoretically beautiful it comes across as contrived. I think issues like this come up enough that it is easier to use an imperative language and struggle with the parts that should be written functionally, than to use a functional language and struggle with the parts that should be written imperatively.
2. The developers of functional languages are living in a theoretical world in which many topics seem very important, topics that people doing actual programming see as minor issues. Static typic systems come at the top of the list. Proof systems are another.
3. Many functional language proponents have fooled themselves into thinking that imperative programming is so low-level and dangerous as to be all but impossible. Truth is, there have been people writing complex video games in hundreds of thousands of lines of 16-bit assembly code, games that shipped on consoles and had no known bugs (examples: Donkey Kong Country, Sonic the Hedgehog 3, NBA Jam, Crusin' USA). So, yes, Haskell may let you write a Quicksort in three lines of code, but there's more to programming than that. You could equally fool yourself into thinking that cars are too dangerous to drive, because there's no safety mechanism preventing one from veering into another.
4. In all honesty, relatively few people are doing classic programming any more. Most programmers do things like database interfacing, GUI tool building using Delphi or Visual Basic (data point: 60% of all new software is written in Visual Basic), CGI scripting, etc. Not too many programmers find themselves needing to do something algorithmically tricky, like handling red-black trees or dealing with weighted graphcs.
I like functional languages for certain types of problems, but it isn't too difficult to see why they haven't caught on in a bigger way.
Did you actually *look* at the screen for this comparison?
Arguably, this is because X ships with some of the most unaesthetic fonts I have ever seen. Mac and Windows fonts are much nicer, though I hate to admit it.
I think the real problem is that Gas has been so cheap in the US for so long. We have had it WAY too good.
It is like this with a lot of things. People scramble for huge home entertainment centers, pointlessly fast PCs with monster monitors, and every appliance under the sun. That's because electricity isn't outrageously expensive here. If it were, you'd start seeing a turn toward to realistic.
The astounding thing about X is how much code it needs to do almost nothing. Window management is up to a window manager. Hardware specific code is up to a device driver. Gadgets and such are up to higher-level libraries like Qt. Standard GUI niceties are left up to desktop environments, like KDE and Gnome.
The truth is that it takes very little code to do what X does. One of the most minimal windows managers for X, Blackbox, is approximately 12,000 lines of C++ (the author likes to give a line count). Think about that. 12,000 lines of code to simply act as an interface between you an X in a very minimal way. You could write an entire GUI, including hardware-specific code, in 12,000 lines. Maybe it wouldn't be KDE, but it shows how far off base we've become. Don't believe it? here is a functioning GUI, which doesn't use any external libraries for graphics, done in a few kilobytes of object code.
Corel has taken a big chance on Linux, and so far they've spent a lot of time and money without earning anything back. WordPerfect and Photo Paint are excellent, but are being given away free. WINE isn't a commercial product. Corel Linux is still very new and is being piffed by the Linux die-hards as "Linux for weenies." It will come around, but it will take time.
Remember, Corel is a decent sized company with bills to pay. It isn't the same as a freebie consulting service that eventually earned a reputation and the ability to charge money. The latter is more typical of Linux-oriented businesses.
You're missing the point. When someone reviews an application or game for Windows, the reviewer doesn't stop to think about Mac vs. PC vs. UNIX. It is irrelevant. But many Linux users, at least an overly vocal minority, fixate on the Us vs. Them angle and absolutely cannot stand to think that something for Linux might not be as up to snuff as a product for another OS. I can't say I've seen this in reviews for commercial software, but you see it commonly on Usenet and right here at Slashdot. Raving loons insisting that The Gimp blows away Photoshop or that Emacs does everything that Word does and more, that gcc + make + Emacs is superior to Visual C++ and Codewarrior. Sometimes they're right, but often they're reporting blind, without having tried the equivalent Windows product. In many cases, I suspect that people are simply spewing the thoughts of others, and people who've never set up a server are raving about how wonderful Apache is or people who can't program go on about how Open Source enables bugs to be fixed quickly.
It takes you thirteen seconds to come up with the "specific usability goals" thought. This guy asks you for specifics (ie the menu in panel thing). You come back with more rants. If you have nothing more than "I want something different. I don't know what, just different, and usable. Now get to work all you hackers," then you have nothing to contribute to the world.
You missed the point completely. The point is that it big changes to KDE are no longer so easy, now that large companies are beginning to lean on it. Look at it this way: If KDE were changed dramatically--for the better--it immediately invalidates half a dozen "How to use KDE" books.
What I would like is simply a user interface designed for *usability* rather than twiddling. There are good books on the subject that can be used as templates, such as this one or the one by a Microsoft Windows architect who realized that Windows interface was going off in the wrong direction (I forget the name; it is currently in print). It is simply a matter of the KDE (and Gnome) people ignoring what's out there, trying to out do Microsoft at their own game, and missing the point entirely.
I think the reason Open Media is dominated by youth probably has as much to do with younger folks' higher learning curve, as it does with the fact they don't have the money to buy all the stuff they get for free.
Plus they have "free" T1 connections at school and more time to surf.
You're talking to a bunch of people using an operating system designed in the early 1970s. *We* are the old farts.
I don't know if it comes from using PDAs and emulators for 8-bit home computers, but I'm actually starting to prefer lowish resolutions on small monitors. Maybe it's just the realization that I'm usually staring at a small window in the center of a large, expensive, EMF emitting monitor. Along the same lines, I'm starting to see anti-aliased text as *fuzzy* rather than smoother. I was using an Atari 800 emulator the other day, believe it or not, I really got into the sharp, chunky feel of the text.
I'm shocked...seriously, I'd be really curious to hear if anyone specifically knows of any large projects in recent time that have written in Pascal?
There's quite a bit of Windows software written using Pascal. Some commercial games, even.
The three things that make Pascal a wonderful development language are:
1. Very tight module control. You don't need separate header files. Everything is very clean and organized.
2. Less temptation to trivially optimize code by using inline functions and pointer math and such and multiple ways of phrasing simple expressions. I find there's less mental baggage associated with Pascal programming than in C++.
3. Lightning fast compiles. Big projects, ie. 200,000 lines, rebuild completely in 20 seconds or so. Normal "bring project up to date" operations are instantaneous. This is over an order of magnitude better than any C++ compiler I've used.
C) Do you have a better coherent vision of what a UI should be? If so, why have you done nothing about it? Do you really think that bitching about other people's work does any good?
Ah, the stock reply: "Do it yourself!" The trouble with big systems like KDE is that they take a long time to build up momentum and then they're unstoppable (a la Windows). I could come up with alternatives. So could other people. But if Corel and Borland and other companies with a lot of money at stake choose KDE, then that's going to make KDE the most viable option for most people, simply because it has the biggest elephants behind it. In the end, we'll wish for something better but settle for KDE, just as we've been doing with Windows all these years.
It is mildly frustrating that both leading GUI efforts are from the Windows school. That is, both are very geared toward fiddly gadgets and customizing themselves rather than having specific usability goals in mind. Note: I know about Blackbox (which I use) and Sawmill and such, but those are raw window managers for X and nothing more.
Now that Kylix seems to be locking into Qt and Corel has chosen KDE, there looks to be less opportunity for something cleaner and more user-oriented to come along. Even if someone were working in a different direction, they have a lot of corporate momentum to overcome. That's why most people are using Windows in the first place, unfortunately.
Why is it I keep seeing posts regarding why MS, etc should open up their sources so people can grab the source code and make something better of their own?
And it's not like it's remotely easy to pick up 250,000 lines of source and make something better. I work on huge projects during the day, and it's common for a programmer on the project to misunderstand an interface subtlety and make a mistake that shows up later down the road. And this with experience working on a code base full-time.
One of the great myths of open source is that it makes bug fixes and enhancements easy.
Good stuff, but the whole hook of Borland's compilers has always been the speed of compilation. Delphi is up near a million lines a minute on an average machine (300MHz). If FPC is more in line with gcc, then there's no reason to switch (for me).
A typical day for many people includes one to two hours of checking web sites and answering unimportant email. The result is that they have 25% less time to do their normal work in. ICQ is another intrusion. It makes you feel like you need to interrupt what you're doing and respond. When you come down to it, most ICQ and email intrusions and web sites have no direct value. If you decided to just do your job and not check Slashdot (or whatever) daily, then after a month you'd find that you really didn't miss anything. Somebody posted some misleading benchmarks and there was heated debate. Gnome or KDE or Apache or the kernel had a minor patch that doesn't benefit you. Some new graphics card or CPU got 5% faster, though nobody cares because the price is too high or the drivers are crappy. There were some supposed breakthroughs in genetics or quantum computing or somesuch that doesn't have a relation to anything tangible (i.e. it's vaporware). I bet you get more done during that month than the previous two.