For example, some of the following: OCaml, Python, Ruby, C++, D.
But there are really lot of them available. What's best, depends on what you try to do and your taste.
Go through SICP book. DrScheme is a nice scheme implementation for trying examples in the book. You'll learn to understand some deeper programming concepts, that you problably would not pick up in a few years of random programming practice.
For god's sake, the man claims that C++ doesn't have resizeable arrays, built-in strings, garbage collection or even class properties!
Resizeable arrays - quote from D website:
Part of the standard library for C++ implements resizeable arrays, however, they are not part of the core language. A conforming freestanding implementation of C++ (C++98 17.4.1.3) does not need to provide these libraries.
Although std::vector has always been good enough for me.
Garbage collection - quote from D website:
The Hans-Boehm garbage collector can be successfully used with C and C++, but it is not a standard part of the language.
I would be glad, if you can share, how the class properties can be done sanely in C++.
It is technically possible to use special class with overloaded = as a public field of C++ class, but it is cumbersome enough to redirect the getter-setter methods to main class, that you probably don't bother. Furthermore, it is not possible to override those properties in child classes (using D inbuilt class properties it is imho possible).
About stuff that you ignored in D - it has lambda functions (calling them delegates), which are practically impossible to emulate conviniently in C++ (I know about boost hacks - these are not anywhere near convinient lambdas or first-class functions).
Still, I personally don't use D. OCaml is simply nicer with really cool data types, pattern matching and more convinient syntax;)
With all seriousness, I am now bound to ask,
why Microsoft don't fix all their bugs,
like all the other decent programmers over the world have always done?
Since we all know, that the bugs are EVIL and the creation of the DEVIL,
it is clear that only worshippers of the SATAN can tolerate those
bugs in their code.
Therefore, I am now bound to request,
that Microsoft shall be burned on the stake!
"> And in functional programming, you're creating functions on the fly.
I'm trying to imagine a programming language that doesn't let you create
functions on the fly but is powerful enough for writing real applications."
In most functional languages you can write something like this:
(* This function takes a function f as argument, applies it to number 2 and prints out the result *) let print_f_2 f = print_int (f 2);;
(* This function sums two integers *) let plus a b = a + b;;
(* integer x is read from stdin *) let x = int_of_string (input_line stdin) in
(* function plusx is created, which adds value of x to its argument *) let plusx = plus x in
(* plusx is given as argument to print_f_2, which in turn cause to print x + 2 *) print_f_2 plusx;;
In this OCaml code, the plusx is created "on the fly" and it is different function, depending on the value of x that is read on runtime. How do you do this in C ?
> 1) Just because you can, doesn't mean you should.
No, no. If it is possible, then it is intended to be used.
> 2) One line of code means one operation or idea. MAAAAYBE 2. See point #1.
Or maybe 3... or 4... or 5. oh well, I agree, 10 is usually too much.
> 3) If there is a cute, short, hackerish way to do something, and a longer, more boring, more explicit way to do the same thing, ALWAYS pick the boring way.
Programming has to be fun. So the boring way doesn't count. Anyway, the short way assures, that I also have some fun when I sometimes later reread my own code and for every tenth line or so stop glaring at it and saying, WTF THIS IS SUPPOSED TO DO? And after few minutes say... oh it does this...
Problem is not that there are many toolkits, problem is that they are not compatible enough. Enough compatibility would mean:
Different libraries should use same desktop themes.
They should perform similarly enough when using same theme, so the user would not notice difference between applications using different gui libraries.
There should be some kind of VFS unification, this means the vfs trees should look same for all applications.
Achieving this would require cooperation between different toolkit projects, and is probably possible only for major ones (like Qt and Gtk+).
It would be better than using one toolkit, because this approach will give programmers a choice about what API they like to use. One prefers Qt api, another Gtk+'s one and the choice about what to use shouldn't depend of the desktop system the program will run.
Although smaller toolkits may still look different, it is practically unavoidable - anyone can create they're own weird widgets even when there are system ones (for example, there exists many windows programs, which use their own widgets).
The sorry thing about C++ programming is, that almost nobody knows enough about it to make it useful. It is a very powerful and efficient language for smart programmers, who know the whole C++ language and have learned how this can be used. Also, a standard C++ should be learned, not something that was done by C++ compilers ten years ago... C++ ten years ago was quite pathetic and not the same thing as current C++.
Some points:
OO-programming and C++ classes.
Everybody thoughs that C++ should be an OO language. C++ is quite bad about OO (as imho is also Java... the main Java advantage is having an inbuilt garbage collector, so you don't need to create you're own reference counting template or something similar, as in C++). OO wants more dynamically typed language than C++ and its alikes are. Statically typed OO problem is too much casting into derived types (dynamic_cast in C++ for example).
The fact is that C++ "classes" are very good for almost anything else but OO in the classic sense (which uses class hiearchies). They are a great way to create a custom data types (about as some smart structs). They can be used for creating something like continuations and for giving some temporary "static" variables to some function group (which are then the class members).
Resource allocation is initialization. This shall be burned into every C++ programmers brain...
If you have something that requires allocating resources and freeing them, it is usually good idea to put it into an C++ class and use constructor/destructor for allocating/freeing the resource. This is very useful together with objects put into stack - the resources are then automatically freed, when you leave the block.
In a good C++ program you find very few explicit delete usage - and most of these delete's should be in some destructors.
Resources shouldn't be "owned" by alone pointers in stack. This creates exception nightmare, where you must use try-catch to free resources when exception comes. When pointers are in wrappers, everything is nice and exceptions cleanup by themselves (since all objects in stack will be destructed, when exception flies through).
As a sidenote, the resource allocation is initialization thing is the reason why finally is left out of C++ language - finally is not needed when used resources are freed by stack object destructors.
Error handling should be done using exceptions in most cases.
For some reason many C++ programmers ignore exceptions and make their lives hard with this. Since the STL (and new) uses exceptions you cannot avoid them anyway. Ignoring standard exceptions just leads to a flawed program. Inventing your own error handling instead of using exceptions is just an unnecessary additional work to recreate a feature that is inbuilt into language and leads usually to error handling code bloat.
C++ compiler creates a working copy constructors and assignement operators for you, when all your class members are value types. And any class with working copy constructors and assignement operators is a good value type for this.
This is a very useful, but quite a few C++ programmers seem to know about it. It basically means that you may assemble you're data types with very few trouble. The fact that pointers are not a good value types in this context can be often over come using reference counting wrappers for them (but it is usually a good idea to threat these shared pointers as read-only, unless you implement copy-on-write in you're pointer wrapper).
Templates are one of the most useful C++ features, giving an ability to reuse code for different data types. STL is a fine example of template usage and libraries like Boost give an idea about what can be done with templates. It is often useful to create some template classes/functions for handling similar operations on different data types (and avoid things like void* and casting in the code).
Sorry for bad spelling, I'm not a native english speaker.
The is no need for MDI, when you have virtual desktops - the virtual desktop itself is the one big window, where the Gimp windows will sit. The virtual desktop solution is also more flexible - you may put some other apps windows to the same desktop as Gimp ones, when you find it useful and the Window Manager can be configured to behave as you like. Only on Windows it is useful to have one big maximized window with small ones inside it, since it doesn't have the virtual desktops.
pd.c is for parallel port ide device driver. When you do not have some parallel port ide device, just do not compile modules for them (disable these modules from kernel config).
Slashdot Mirror
The btrfs actually has compression (although I think you can't switch it on/off per-directory in single btrfs filesystem). http://blogs.oracle.com/wim/entry/btrfs_compression
If the kernel is so good, couldn't they write some linux-like syscall compatibility layer on top of it or emulate linux in libc?
Used a hacked Cannon camera.
http://www.francescobonomi.it/ICBNN
http://icbnn.wordpress.com/
For example, some of the following: OCaml, Python, Ruby, C++, D.
But there are really lot of them available. What's best, depends on what you try to do and your taste.
Are you going to tell, that some bitch is more important than a great filesystem?
</cynical sarcasm>
Go through SICP book. DrScheme is a nice scheme implementation for trying examples in the book. You'll learn to understand some deeper programming concepts, that you problably would not pick up in a few years of random programming practice.
In Soviet China google is diagnosed as a disease.
For god's sake, the man claims that C++ doesn't have resizeable arrays, built-in strings, garbage collection or even class properties!
- Resizeable arrays - quote from D website:Although std::vector has always been good enough for me.
- Garbage collection - quote from D website:
- I would be glad, if you can share, how the class properties can be done sanely in C++.
It is technically possible to use special class with overloaded = as a public field of C++ class, but it is cumbersome enough to redirect the getter-setter methods to main class, that you probably don't bother. Furthermore, it is not possible to override those properties in child classes (using D inbuilt class properties it is imho possible).
About stuff that you ignored in D - it has lambda functions (calling them delegates), which are practically impossible to emulate conviniently in C++ (I know about boost hacks - these are not anywhere near convinient lambdas or first-class functions).Still, I personally don't use D. OCaml is simply nicer with really cool data types, pattern matching and more convinient syntax ;)
Nitroglycerin solved in alcohol is quite stable. Add water and pure nitroglycerin should settle at the bottom. Then shake...
why Microsoft don't fix all their bugs,
like all the other decent programmers over the world have always done?
Since we all know, that the bugs are EVIL and the creation of the DEVIL,
it is clear that only worshippers of the SATAN can tolerate those bugs in their code.
Therefore, I am now bound to request,
that Microsoft shall be burned on the stake!
Rob Pike's Systems Software Research is Irrelevant seems to be on the topic.
Shareaza code is based on MFC, so I wonder, whether it could be ported to wxWindows (which has similar interface).
I'm trying to imagine a programming language that doesn't let you create functions on the fly but is powerful enough for writing real applications."
In most functional languages you can write something like this:
In this OCaml code, the plusx is created "on the fly" and it is different function, depending on the value of x that is read on runtime. How do you do this in C ?No, no. If it is possible, then it is intended to be used.
> 2) One line of code means one operation or idea. MAAAAYBE 2. See point #1.
Or maybe 3... or 4... or 5. oh well, I agree, 10 is usually too much.
> 3) If there is a cute, short, hackerish way to do something, and a longer, more boring, more explicit way to do the same thing, ALWAYS pick the boring way.
Programming has to be fun. So the boring way doesn't count. Anyway, the short way assures, that I also have some fun when I sometimes later reread my own code and for every tenth line or so stop glaring at it and saying, WTF THIS IS SUPPOSED TO DO? And after few minutes say... oh it does this...
- Different libraries should use same desktop themes.
- They should perform similarly enough when using same theme, so the user would not notice difference between applications using different gui libraries.
- There should be some kind of VFS unification, this means the vfs trees should look same for all applications.
Achieving this would require cooperation between different toolkit projects, and is probably possible only for major ones (like Qt and Gtk+). It would be better than using one toolkit, because this approach will give programmers a choice about what API they like to use. One prefers Qt api, another Gtk+'s one and the choice about what to use shouldn't depend of the desktop system the program will run.Although smaller toolkits may still look different, it is practically unavoidable - anyone can create they're own weird widgets even when there are system ones (for example, there exists many windows programs, which use their own widgets).
Some points:
Everybody thoughs that C++ should be an OO language. C++ is quite bad about OO (as imho is also Java... the main Java advantage is having an inbuilt garbage collector, so you don't need to create you're own reference counting template or something similar, as in C++). OO wants more dynamically typed language than C++ and its alikes are. Statically typed OO problem is too much casting into derived types (dynamic_cast in C++ for example).
The fact is that C++ "classes" are very good for almost anything else but OO in the classic sense (which uses class hiearchies). They are a great way to create a custom data types (about as some smart structs). They can be used for creating something like continuations and for giving some temporary "static" variables to some function group (which are then the class members).
If you have something that requires allocating resources and freeing them, it is usually good idea to put it into an C++ class and use constructor/destructor for allocating/freeing the resource. This is very useful together with objects put into stack - the resources are then automatically freed, when you leave the block.
In a good C++ program you find very few explicit delete usage - and most of these delete's should be in some destructors.
As a sidenote, the resource allocation is initialization thing is the reason why finally is left out of C++ language - finally is not needed when used resources are freed by stack object destructors.
For some reason many C++ programmers ignore exceptions and make their lives hard with this. Since the STL (and new) uses exceptions you cannot avoid them anyway. Ignoring standard exceptions just leads to a flawed program. Inventing your own error handling instead of using exceptions is just an unnecessary additional work to recreate a feature that is inbuilt into language and leads usually to error handling code bloat.
This is a very useful, but quite a few C++ programmers seem to know about it. It basically means that you may assemble you're data types with very few trouble. The fact that pointers are not a good value types in this context can be often over come using reference counting wrappers for them (but it is usually a good idea to threat these shared pointers as read-only, unless you implement copy-on-write in you're pointer wrapper).
Sorry for bad spelling, I'm not a native english speaker.
The is no need for MDI, when you have virtual desktops - the virtual desktop itself is the one big window, where the Gimp windows will sit. The virtual desktop solution is also more flexible - you may put some other apps windows to the same desktop as Gimp ones, when you find it useful and the Window Manager can be configured to behave as you like. Only on Windows it is useful to have one big maximized window with small ones inside it, since it doesn't have the virtual desktops.
pd.c is for parallel port ide device driver. When you do not have some parallel port ide device, just do not compile modules for them (disable these modules from kernel config).
Xandros is derived from Corel Linux.