Huh what lisp functional programming whaa...?! LISP is as imperative as it gets. The key feature of LISP is that code is data. That way you can run complex things at compile time -- things that write code for you, generate tables, implement domain specific languages, etc. The functional features are an afterthought and not really in any way key to LISP's power. They are a commonplace in most languages these days. I mean, come on, once you have function pointers in C, you can directly emulate all of LISP's "functional" features save for ones that need to generate code at compilation time (or runtime, too). It's not like qsort(...., int (*cmp)(const void *, const void*)) is not possible in C, you know. Lambda is very nice syntactic sugar, but not impossible to live without. Same goes for continuations: it's possible all right to have continuations in C and C++, just that you have to make to continuation state explicit in a data structure. Heck, it's even possible to have full-fledged coroutines in C -- again, you have to code for it, and it doesn't look pretty, but it's not technically impossible. No stack switching hacks needed. Of course if you want to run arbitrary C, you need stack switching:)
The template metaprogramming in C++ is a completely unnecessary crutch. It's there only because nobody had the balls to have full-featured compile time code execution in C++. Once you have that, you can write things in a much easier to interpret way using simple imperative style. C++ is, at heart, an imperative language. The fact that you need a functional-style language added to it just in order to work around a reasonably simple deficiency is quite telling. C++ basically requires you to learn two languages that have nothing in common, that use completely different idioms, etc.
Just look at how much trouble there is making the C++ metaprograms actually execute decently in the compiler: now a C++ compiler is not merely a compiler, but also a functional programming runtime / virtual machine! Those things are hard to make to run well -- just look at how long it took Haskell people to get something semi-useful. Adding template functionality that allows metaprogramming to C++ suddenly doubled or tripled the effort required to implement a C++ front-end. Whoever thought it a good idea should be shot.
What would have been the problem to simply let C and C++ compilers run code that is declared as a macro, just like LISP does it? This would have solved everything one uses templates for. A C/C++ host-targeting compiler shouldn't have any problems in extracting the macros, compiling them and running them -- and then consuming their output.
Instead of doing the simple thing, and leveraging the skills of imperative mindset already needed to be an effective C/C++ developer, the C++ language designers have implemented a limited, hard to implement and hard to use functional programming crutch that effectively doubles the requirements placed on the end user. Never mind the poor sods who implement the C++ front end and have to take constant flak from folks who actually want to use the damn feature without having to endure hour-long compile times and multi-gigabyte compiler resident sets just to get through a 10-line metaprogram. Give me a fucking break. Most of boost's metaprogramming stuff is there to basically say: hey, if it really worked here's how it'd look. Then you try to actually use it, and you run into the silly compiler-imposed limitations quicker than it takes to read this sentence. Large scale template metaprogramming is, essentially, completely impossible. About the only thing it's good for in practice are eigen-style libraries. Everything else it promises is summarily non-delivered. It's not funny.
I think that calling C "portable assembly" is really a bit untrue. One of the core features of most any machine language is that flags are part of the result of many computing operations. Yet C completely removes access to it.
Suppose you have a code that adds two things, then jumps on overflow. On most machines that's two instructions if the operands have the right size. You look at it, and the intent is obvious: we add, then jump on overflow.
Things are seriously wrong (IMHO) if a higher level language completely obfuscates this and requires code where it's not obvious at all what you mean! Heck, what's worse, each compiler likely requires slightly different code so that the meaning is extracted by the optimizer and the correct assembly output is produced without paying both code size and performance penalties! In C, the best you can do on a good compiler is to have an inlineable function that returns the numerical part of the result, uses comparisons to "recreate" the detection of overflow, and returns the overflow condition in a char* out-parameter. If the optimizer is good, it'll recognize that the out parameter accesses an automatic variable in the caller, and that your comparison is just checking for overflow. This code, while portable C, will perform horribly as soon as you compile it without state-of-the-art optimization capabilities. I'd think that means that if your compiler wasn't released in the last year or two, and isn't a mainstream decently optimizing one (like gcc, llvm, visual studio), you're out of luck. On many platforms a saturating increment/decrement is also two or three assembly instructions at most, without jumps -- but good luck getting a compiler to actually emit such code.
I think that providing no way to access the flags part of arithmetic operation results is one of the biggest oversights in C. I'd think that every platform C runs on provides such flags.
Sweetheart, wasn't it the intelligent and money-smart German bankers buying lots of the junk paper that nobody in the U.S. would even touch with a long pole just before the recent housing bust? I think there was a few billion USD worth of that stuff that is being written off by the landesbanks all over the place. Slowly but surely. It got to a point where "boys from Stuttgart" were joked about here.
A camera? Now stop being silly. Go to a location that has presumedly similar layout to the one in question. Take a pic with your digital camera. Scale it down to NTSC resolution. That's the best case image you're going to get -- stuff from usual cameras used for monitoring looks much worse. Most security cameras are completely useless. You can barely tell between a human and a gorilla on most of the feeds that catch large areas. A small storefront may leave you with a bit better image than most, but it's still way too large area of an to cover if you want to see any faces. Other than recognizing faces, what's the point? I mean, you know there was a break-in, there's no reason to look at a video recording to confirm what's obvious. Either you get faces that are recognizable, or it's mostly useless.
You've basically fallen for the security monitoring scam: people love it until they actually need to see the images and realize they are useless.
To get good monitoring you need HD cameras, and plenty of them. For a small storefront monitoring, you may need coverage from two 1080p webcams. They are not exactly the most inexpensive of things. Alternatively, if you believe in a bit of luck, a digital photo camera taking timelapse pictures every second may also be likely to catch the faces. I'd go for one of the Canons where you can replace stock firmware with CHDK. You can then make it delete old pictures and keep new ones in round-robin fashion.
Yes, the experiment is the ultimate validation of any theory, but it needs to be done in such a way that sufficiently controls for things. Here, demonstrably, when you control for the solidity of the car and choose a solid car, you're not ripping anything out. I'm not surprised junk cars that the likely burglars drive would be, um, more prone to getting the rear end separated.
Exactly. It is due to those determined people that you don't want to be alerted instantly -- because you may just do something stupid like go there and get beaten up or shot.
To me it seems possible that it's a protection racket and they're not telling you that they've been asked for money. Maybe they just didn't get the hint.
Alas, but beware! Computer science != software engineering. Both aspects are important for a successful software developer. If you're in a computer science course of study in academia, I do expect you to be no better in software engineering side of things than a self-taught kid fresh out of the college. Same goes for those who only know the engineering side well, without grokking the mathematical theory.
Only because there was no API to achieve certain things. Only because of that. A built-in assembler and library calls to modify the stuff people usually peeked and poked for would remove 99% of peeks and pokes.
Huh? So obviously in those "higher level languages" you can trivially generate pointers that will let you overwrite your stack, or alias some variables the compiler presumes you'll not alias, or write past the end of the array (or before its beginning), etc? Because, you see, those are the problems that stuff in C and C++ runs into, never mind memory leaks and use of freed memory.
Because it's a language that's not really good for anything. It's widely used because there are no alternatives, not because it's particularly good. It wasn't really designed by people who had solid foundations of programming language design, and it wasn't designed to solve the particular problems that the web is facing in the long term. It has been kludged to work. Just look at how much effort it takes to efficiently JIT that thing. Lua's JIT is almost trivial in comparison, yet produces very decent code.
Legacy codesys-based industrial PLCs, where I evaluated LuaJit as a replacement, have arrays limited to 64 kbytes in size, even when targeting 32 bit Intel platforms. Whatever limitations LuaJIT has, save for 2.0 teething pains, are not even on my horizon:)
But I'm not comparing it to scripting languages -- I'm comparing it to other things that are in use in a particular application domain. In industrial process control, there's generally no distinction between a scripting vs. non-scripting language. Everything is written in the same environment, and the languages all translate to same byte code that is then either run on a bytecode VM or compiled to native code. If you want to get rid of that, you can't just get rid of a small part of it -- it's not worth it. Either you keep using the existing environment, or you replace it wholesale with Lua. With LuaJit, I see performance that generally makes the codesys mess redundant.
On microcontrollers -- sure as heck I can beat any compiler in assembly, without using anything but paper and pencil, and an assembler (eventually). On a modern Intel core? Yeah, but it'll take me 10x longer than on a microcontroller, and I may need to use tools like cachegrind to check my work in progress.
Lua by itself is pretty abysmal, performance wise and IMHO, but LuaJIT is perhaps the best thing since sliced bread. I've been playing with the recent 2.0 release on ARM, and it looks like I may quite comfortably write a big chunk of an industrial process controller in Lua. Now that's something. No more messing with IEC PLC programming languages that are still stuck in the 80s.
Piggybacking data on packets being an insurmountable problem? Huh? I don't know the specifics, but tunneling and encapsulation come to mind, and are relatively trivial to implement in most cases.
I do understand what you're after, of course -- sometimes the requests just don't make any sense.
If your management is fighting you, you have already lost the battle -- you're working for the wrong bosses. As for their management: that's why you hire the right people who can set the customer straight while the customer is thinking all the time that they are in charge. Manipulating career bureaucrats is easy -- they are all the same, after all. You only need those who know how to pull it off working for you. That's all. I've heard first hand from a small European consulting company that undertook a few out of the view but significant projects, and they had two psychologists on staff -- one specializing in negotiations and another one specializing in profiling. I think a couple private investigators were also temporarily retained to figure out the exact political pressures in play. A couple weeks into the bid review process they had a pretty good handle about the personalities of all the key people who they were interfacing with on the customer end, and the bosses above those people. The competitors didn't even stand a chance.
Slashdot Mirror
Huh what lisp functional programming whaa...?! LISP is as imperative as it gets. The key feature of LISP is that code is data. That way you can run complex things at compile time -- things that write code for you, generate tables, implement domain specific languages, etc. The functional features are an afterthought and not really in any way key to LISP's power. They are a commonplace in most languages these days. I mean, come on, once you have function pointers in C, you can directly emulate all of LISP's "functional" features save for ones that need to generate code at compilation time (or runtime, too). It's not like qsort(...., int (*cmp)(const void *, const void*)) is not possible in C, you know. Lambda is very nice syntactic sugar, but not impossible to live without. Same goes for continuations: it's possible all right to have continuations in C and C++, just that you have to make to continuation state explicit in a data structure. Heck, it's even possible to have full-fledged coroutines in C -- again, you have to code for it, and it doesn't look pretty, but it's not technically impossible. No stack switching hacks needed. Of course if you want to run arbitrary C, you need stack switching :)
The template metaprogramming in C++ is a completely unnecessary crutch. It's there only because nobody had the balls to have full-featured compile time code execution in C++. Once you have that, you can write things in a much easier to interpret way using simple imperative style. C++ is, at heart, an imperative language. The fact that you need a functional-style language added to it just in order to work around a reasonably simple deficiency is quite telling. C++ basically requires you to learn two languages that have nothing in common, that use completely different idioms, etc.
Just look at how much trouble there is making the C++ metaprograms actually execute decently in the compiler: now a C++ compiler is not merely a compiler, but also a functional programming runtime / virtual machine! Those things are hard to make to run well -- just look at how long it took Haskell people to get something semi-useful. Adding template functionality that allows metaprogramming to C++ suddenly doubled or tripled the effort required to implement a C++ front-end. Whoever thought it a good idea should be shot.
What would have been the problem to simply let C and C++ compilers run code that is declared as a macro, just like LISP does it? This would have solved everything one uses templates for. A C/C++ host-targeting compiler shouldn't have any problems in extracting the macros, compiling them and running them -- and then consuming their output.
Instead of doing the simple thing, and leveraging the skills of imperative mindset already needed to be an effective C/C++ developer, the C++ language designers have implemented a limited, hard to implement and hard to use functional programming crutch that effectively doubles the requirements placed on the end user. Never mind the poor sods who implement the C++ front end and have to take constant flak from folks who actually want to use the damn feature without having to endure hour-long compile times and multi-gigabyte compiler resident sets just to get through a 10-line metaprogram. Give me a fucking break. Most of boost's metaprogramming stuff is there to basically say: hey, if it really worked here's how it'd look. Then you try to actually use it, and you run into the silly compiler-imposed limitations quicker than it takes to read this sentence. Large scale template metaprogramming is, essentially, completely impossible. About the only thing it's good for in practice are eigen-style libraries. Everything else it promises is summarily non-delivered. It's not funny.
Lists are general but poorly performing data structures. Modern Lisps aren't all about lists at all. They have multiple data types.
I think that calling C "portable assembly" is really a bit untrue. One of the core features of most any machine language is that flags are part of the result of many computing operations. Yet C completely removes access to it.
Suppose you have a code that adds two things, then jumps on overflow. On most machines that's two instructions if the operands have the right size. You look at it, and the intent is obvious: we add, then jump on overflow.
Things are seriously wrong (IMHO) if a higher level language completely obfuscates this and requires code where it's not obvious at all what you mean! Heck, what's worse, each compiler likely requires slightly different code so that the meaning is extracted by the optimizer and the correct assembly output is produced without paying both code size and performance penalties! In C, the best you can do on a good compiler is to have an inlineable function that returns the numerical part of the result, uses comparisons to "recreate" the detection of overflow, and returns the overflow condition in a char* out-parameter. If the optimizer is good, it'll recognize that the out parameter accesses an automatic variable in the caller, and that your comparison is just checking for overflow. This code, while portable C, will perform horribly as soon as you compile it without state-of-the-art optimization capabilities. I'd think that means that if your compiler wasn't released in the last year or two, and isn't a mainstream decently optimizing one (like gcc, llvm, visual studio), you're out of luck. On many platforms a saturating increment/decrement is also two or three assembly instructions at most, without jumps -- but good luck getting a compiler to actually emit such code.
I think that providing no way to access the flags part of arithmetic operation results is one of the biggest oversights in C. I'd think that every platform C runs on provides such flags.
This is perhaps the most informative thing I've read all day. Thanks!
So, nothing you'd care to run makeinfo on. Point taken. Er, what were you saying, again?
That's true of course.
Sweetheart, wasn't it the intelligent and money-smart German bankers buying lots of the junk paper that nobody in the U.S. would even touch with a long pole just before the recent housing bust? I think there was a few billion USD worth of that stuff that is being written off by the landesbanks all over the place. Slowly but surely. It got to a point where "boys from Stuttgart" were joked about here.
So, where's all the useful stuff he invented? Do I have any of that in my home? Do any of my neighbours do? Huh?
They'll soon have to pay people for such stories.
A camera? Now stop being silly. Go to a location that has presumedly similar layout to the one in question. Take a pic with your digital camera. Scale it down to NTSC resolution. That's the best case image you're going to get -- stuff from usual cameras used for monitoring looks much worse. Most security cameras are completely useless. You can barely tell between a human and a gorilla on most of the feeds that catch large areas. A small storefront may leave you with a bit better image than most, but it's still way too large area of an to cover if you want to see any faces. Other than recognizing faces, what's the point? I mean, you know there was a break-in, there's no reason to look at a video recording to confirm what's obvious. Either you get faces that are recognizable, or it's mostly useless.
You've basically fallen for the security monitoring scam: people love it until they actually need to see the images and realize they are useless.
To get good monitoring you need HD cameras, and plenty of them. For a small storefront monitoring, you may need coverage from two 1080p webcams. They are not exactly the most inexpensive of things. Alternatively, if you believe in a bit of luck, a digital photo camera taking timelapse pictures every second may also be likely to catch the faces. I'd go for one of the Canons where you can replace stock firmware with CHDK. You can then make it delete old pictures and keep new ones in round-robin fashion.
Yes, the experiment is the ultimate validation of any theory, but it needs to be done in such a way that sufficiently controls for things. Here, demonstrably, when you control for the solidity of the car and choose a solid car, you're not ripping anything out. I'm not surprised junk cars that the likely burglars drive would be, um, more prone to getting the rear end separated.
Exactly. It is due to those determined people that you don't want to be alerted instantly -- because you may just do something stupid like go there and get beaten up or shot.
To me it seems possible that it's a protection racket and they're not telling you that they've been asked for money. Maybe they just didn't get the hint.
Alas, but beware! Computer science != software engineering. Both aspects are important for a successful software developer. If you're in a computer science course of study in academia, I do expect you to be no better in software engineering side of things than a self-taught kid fresh out of the college. Same goes for those who only know the engineering side well, without grokking the mathematical theory.
Only because there was no API to achieve certain things. Only because of that. A built-in assembler and library calls to modify the stuff people usually peeked and poked for would remove 99% of peeks and pokes.
Huh? So obviously in those "higher level languages" you can trivially generate pointers that will let you overwrite your stack, or alias some variables the compiler presumes you'll not alias, or write past the end of the array (or before its beginning), etc? Because, you see, those are the problems that stuff in C and C++ runs into, never mind memory leaks and use of freed memory.
Because it's a language that's not really good for anything. It's widely used because there are no alternatives, not because it's particularly good. It wasn't really designed by people who had solid foundations of programming language design, and it wasn't designed to solve the particular problems that the web is facing in the long term. It has been kludged to work. Just look at how much effort it takes to efficiently JIT that thing. Lua's JIT is almost trivial in comparison, yet produces very decent code.
Legacy codesys-based industrial PLCs, where I evaluated LuaJit as a replacement, have arrays limited to 64 kbytes in size, even when targeting 32 bit Intel platforms. Whatever limitations LuaJIT has, save for 2.0 teething pains, are not even on my horizon :)
But I'm not comparing it to scripting languages -- I'm comparing it to other things that are in use in a particular application domain. In industrial process control, there's generally no distinction between a scripting vs. non-scripting language. Everything is written in the same environment, and the languages all translate to same byte code that is then either run on a bytecode VM or compiled to native code. If you want to get rid of that, you can't just get rid of a small part of it -- it's not worth it. Either you keep using the existing environment, or you replace it wholesale with Lua. With LuaJit, I see performance that generally makes the codesys mess redundant.
On microcontrollers -- sure as heck I can beat any compiler in assembly, without using anything but paper and pencil, and an assembler (eventually). On a modern Intel core? Yeah, but it'll take me 10x longer than on a microcontroller, and I may need to use tools like cachegrind to check my work in progress.
Especially that the trace is equivalent to gcc profile-guided optimizations. It can rock your world.
Lua by itself is pretty abysmal, performance wise and IMHO, but LuaJIT is perhaps the best thing since sliced bread. I've been playing with the recent 2.0 release on ARM, and it looks like I may quite comfortably write a big chunk of an industrial process controller in Lua. Now that's something. No more messing with IEC PLC programming languages that are still stuck in the 80s.
Piggybacking data on packets being an insurmountable problem? Huh? I don't know the specifics, but tunneling and encapsulation come to mind, and are relatively trivial to implement in most cases.
I do understand what you're after, of course -- sometimes the requests just don't make any sense.
So, you don't fix the internal inept employee problem, but instead hire an external contractor? LOL. No wonder it's all downhill from there.
If your management is fighting you, you have already lost the battle -- you're working for the wrong bosses. As for their management: that's why you hire the right people who can set the customer straight while the customer is thinking all the time that they are in charge. Manipulating career bureaucrats is easy -- they are all the same, after all. You only need those who know how to pull it off working for you. That's all. I've heard first hand from a small European consulting company that undertook a few out of the view but significant projects, and they had two psychologists on staff -- one specializing in negotiations and another one specializing in profiling. I think a couple private investigators were also temporarily retained to figure out the exact political pressures in play. A couple weeks into the bid review process they had a pretty good handle about the personalities of all the key people who they were interfacing with on the customer end, and the bosses above those people. The competitors didn't even stand a chance.
a good architect can tell a client to fuck off
Bingo!