It sucks because programming is 99% about "side effects" than mathematical formulas.
Please note the use of quotes for 'side effects'. They are called 'side effects', although they are the most interesting part of programming. It's the part that things happen inside a computer that change the world.
Haskell makes it really difficult to write useful code (where useful means 'with side effects').
They may show you how to create 'infinite' number sequences and process them.
Cool. Ask them to make a Model-View-Controller application in Haskell, where the model is a tree of nodes modified by user actions. Trivial in imperative languages, hard as hell in Haskell: you have to use the a special monad, mix the useful code with visitation to the tree nodes, because the only way to modify tree node links in Haskell is via local arguments that 'pretend' to be the tree's nodes...
Managers do nothing, most of the time.
on
Tech Vs. Business?
·
· Score: 1
Managers do nothing significant, most of the time. If they do not push papers around, then they just talk and talk and talk...we, on the other hands, work our asses out 12 hours a day, doing real work, solving problems...
There are few managers that really work: they think of new ideas, they manage, they lay out plans...most of the managers are fluff.
Couldn't the hardware remain relatively the same (i.e. dedicated fast VRAM and bus) but the programs sent to it be simple C++ programs that are parallelized with the help of the compiler?
I don't think Sweeney is that away from reality. He did not say that all the graphics will be run from the main PC bus. He said that the fixed function processors will be a thing of the past, and since they will be general purpose, there would not be a need for an API between the applications and the hardware.
The real meaning of punishment here, from the University's perspective, is that "don't mess with our systems, or they'll be consequences". It's a punishment to discourage others, who may not be that good, to attempt hacking.
CPUs are not designed to provide component isolation within a process. You either share everything or nothing. That's a VERY BIG PROBLEM, that not only affects browsers, but also kernel design. The battle between micro-kernels and monolithic kernels exists simply because there is no in-process component isolation enforced at hardware level.
In the context of a previous Slashdot discussion on Microkernels, I emailed Andy Tanenbaum and asked him what he thinks of hardware component isolation inside processes. He welcomed the idea, but he said it is going to be a tough sell to CPU manufacturers.
Personally, I don't think that much change is required in CPUs. Actually, what is only needed is two more tables: a) a table like the page table, that defines component boundaries within a process, b) a component function entry table. Accessing something outside of the boundaries would cause a hardware exception. Accessing a function of another component should only be allowed if the target address is contained in the function entry table. Both tables could be implemented as assosiative caches, with very little CPU die dedicated to them.
Isn't capitalism's principle to maximize the profits, minimize the costs? one way of minimizing the cost is to provide a cheaper product. Cheaper products lead to more sales.
Isn't capitalism's goal to have as much profit as possible?
Ads don't have to be good. They can be stupid, but as long as they get the audience's attention, they've done their job. And, judging from the article on/. and the reactions, it did.
All programming languages cause that, don't let anyone fool you. Due to the halting problem, there is no general algorithm to prove the correctness of any program, thus all the programs have bugs in them.
Unfortunately, you are in for a treat! the future is going to be exactly as Star Trek predicted: religious nuts everywhere, soldiers on drugs, wars, pollution etc.
I grew up with this dream as well (to live in a world that is rational and secular), but we won't have it any time soon.
Yeah, I'm just crazy that I read the boost docs for fun;)
Or you may have too much free time on your hands:-).
The use of the stack in C++ is fairly limited.
On the contrary...C++ is the one language which uses the stack most.
It's really only for small objects that can be passed around by value, and not for long-lived objects.
True. But the majority of objects are small...around 90% for a project. That's why generational GC was born. C++ does not need that, it has the stack!
Like I was saying, anything complex enough to have a non-trivial destructor is probably going to be too complex to be useful allocated on the stack.
I don't think so...on the contrary: anything complex enough to have a non-trivial destructor is usually a job to be executed at the end of a procedure, so it's natural to declare it in the stack and let the destructor be executed upon procedure exit.
Well, that's the whole point of smart pointers. You get the EXACT same kind of determinism with your destruction, without having to use only local variables.
You don't get any real determinism. In a complex program, you don't know when the last reference will be destroyed. It's the same as in GC. You may think you know, but it's unprovable (halting problem etc). You only get a bunch of problems as I mentioned in a previous post.
That's Bjarne Stroustrup's definition. He coined it as a general design pattern that should be used whenever possible.
I thought Stroustrup meant it for stack allocation only. Anyway, it's much better to put RAII on the stack, because for better performance and guarranteed cleanup. There is no point in using smart pointers, even if a resource is passed around as a pointer.
Large scale allocation/deallocation of homogenous data types
You said homogeneous...I said heterogeneous...nevertheless, using memory pools, the only problem solved is that of allocation/deallocation. I solved the problem using the allocator of Doug Lea, which is roughly equal to memory pools. Still, the computer does redundant work when compared to GC.
Is there a reason you can't use the very excellent Boehm garbage collector library for C++?
Yes it is. It's not excellent, by a long shot. Usually it does not compile for Windows. When it does, it has all shorts of strange behaviors. Support is non existent; I have tried to use it a lot but I stumbled on problems and while I repeatedly asked for help, I was not given any. It does not play well with DLLs. It does not play well with things initialized before main. I am using Qt in this project for the UI, and Qt has its own memory management system, so I can't bind the two (Boehm + Qt) unless I am really careful and know what Qt does like I wrote it.
Slashdot Mirror
It sucks because programming is 99% about "side effects" than mathematical formulas.
Please note the use of quotes for 'side effects'. They are called 'side effects', although they are the most interesting part of programming. It's the part that things happen inside a computer that change the world.
Haskell makes it really difficult to write useful code (where useful means 'with side effects').
They may show you how to create 'infinite' number sequences and process them.
Cool. Ask them to make a Model-View-Controller application in Haskell, where the model is a tree of nodes modified by user actions. Trivial in imperative languages, hard as hell in Haskell: you have to use the a special monad, mix the useful code with visitation to the tree nodes, because the only way to modify tree node links in Haskell is via local arguments that 'pretend' to be the tree's nodes...
Managers do nothing significant, most of the time. If they do not push papers around, then they just talk and talk and talk...we, on the other hands, work our asses out 12 hours a day, doing real work, solving problems...
There are few managers that really work: they think of new ideas, they manage, they lay out plans...most of the managers are fluff.
Couldn't the hardware remain relatively the same (i.e. dedicated fast VRAM and bus) but the programs sent to it be simple C++ programs that are parallelized with the help of the compiler?
I don't think Sweeney is that away from reality. He did not say that all the graphics will be run from the main PC bus. He said that the fixed function processors will be a thing of the past, and since they will be general purpose, there would not be a need for an API between the applications and the hardware.
Authenticated like the passport of Mohamed Atta found in the rumbles of the WTC???
The real meaning of punishment here, from the University's perspective, is that "don't mess with our systems, or they'll be consequences". It's a punishment to discourage others, who may not be that good, to attempt hacking.
The lack of hardware in-process component isolation coupled with the non-safety of C/C++ can make operating systems like crash...
CPUs are not designed to provide component isolation within a process. You either share everything or nothing. That's a VERY BIG PROBLEM, that not only affects browsers, but also kernel design. The battle between micro-kernels and monolithic kernels exists simply because there is no in-process component isolation enforced at hardware level.
In the context of a previous Slashdot discussion on Microkernels, I emailed Andy Tanenbaum and asked him what he thinks of hardware component isolation inside processes. He welcomed the idea, but he said it is going to be a tough sell to CPU manufacturers.
Personally, I don't think that much change is required in CPUs. Actually, what is only needed is two more tables: a) a table like the page table, that defines component boundaries within a process, b) a component function entry table. Accessing something outside of the boundaries would cause a hardware exception. Accessing a function of another component should only be allowed if the target address is contained in the function entry table. Both tables could be implemented as assosiative caches, with very little CPU die dedicated to them.
Indeed, but an erroneous C/C++ plugin can cause havoc in other threads as well, but in other languages it is not possible to do so.
Because in other programming languages, NULL pointers can be caught as exceptions, and the thread can be gracefully terminated.
They have already chosen the lucky gent with the red shirt...
It's pure fat man! pure fat!!!
Are you a democracy? I thought you were a republic.
cheaper nuclear fuel -> cheaper power -> more nuclear waste -> reactors aging -> economy fails -> cutbacks in reactor maintenance -> nuclear accidents
Isn't capitalism's principle to maximize the profits, minimize the costs? one way of minimizing the cost is to provide a cheaper product. Cheaper products lead to more sales.
Isn't capitalism's goal to have as much profit as possible?
Ads don't have to be good. They can be stupid, but as long as they get the audience's attention, they've done their job. And, judging from the article on /. and the reactions, it did.
Judging from the screenshots, the 3d characters are no more believable than Alyx from HL2. And that particular game is already 4 years old.
Diapers stopped covering my needs a long time ago, unlike Firefox.
All programming languages cause that, don't let anyone fool you. Due to the halting problem, there is no general algorithm to prove the correctness of any program, thus all the programs have bugs in them.
Well, if you consider them funky, then what you'll get will be much funkier...
Firefox covers all my needs. Is there a reason to try Chrome?
Unfortunately, you are in for a treat! the future is going to be exactly as Star Trek predicted: religious nuts everywhere, soldiers on drugs, wars, pollution etc.
I grew up with this dream as well (to live in a world that is rational and secular), but we won't have it any time soon.
You can say that we are born in the wrong era.
Indeed, but at least you know that a stack object was prematurely destroyed and you can adjust your algorithm accordingly.
From within the destructor of the class that encapsulates the reference count, you throw an exception if the object is still referenced.
Actually, the problem of nobody having a reference to a stack object is very easily solvable, using reference counting.
Or you may have too much free time on your hands :-).
On the contrary...C++ is the one language which uses the stack most.
True. But the majority of objects are small...around 90% for a project. That's why generational GC was born. C++ does not need that, it has the stack!
I don't think so...on the contrary: anything complex enough to have a non-trivial destructor is usually a job to be executed at the end of a procedure, so it's natural to declare it in the stack and let the destructor be executed upon procedure exit.
You don't get any real determinism. In a complex program, you don't know when the last reference will be destroyed. It's the same as in GC. You may think you know, but it's unprovable (halting problem etc). You only get a bunch of problems as I mentioned in a previous post.
I thought Stroustrup meant it for stack allocation only. Anyway, it's much better to put RAII on the stack, because for better performance and guarranteed cleanup. There is no point in using smart pointers, even if a resource is passed around as a pointer.
You said homogeneous...I said heterogeneous...nevertheless, using memory pools, the only problem solved is that of allocation/deallocation. I solved the problem using the allocator of Doug Lea, which is roughly equal to memory pools. Still, the computer does redundant work when compared to GC.
Yes it is. It's not excellent, by a long shot. Usually it does not compile for Windows. When it does, it has all shorts of strange behaviors. Support is non existent; I have tried to use it a lot but I stumbled on problems and while I repeatedly asked for help, I was not given any. It does not play well with DLLs. It does not play well with things initialized before main. I am using Qt in this project for the UI, and Qt has its own memory management system, so I can't bind the two (Boehm + Qt) unless I am really careful and know what Qt does like I wrote it.