Catch up on stories from the past week (and beyond) at the Slashdot story archive


Forgot your password?

Comment Re:Scheme is a functional programming language (Score 1) 107

It may be well-written code, but given that it's only quite recently that we have garbage collectors that can cope with pure-functional-style memory pressures, nobody in practice writes large LISP projects in functional style -- at least not projects that are not very recent. I can't wait for LuaJIT's new garbage collector to be done -- if it could be then "reshaped" to serve a LISP system like SBCL, it'd be a major win IMHO.

Comment Re:Emulate (Score 1) 233

I had a self-made circular slide rule in high school, then got a real one for college, just for the heck of it. Way easier to use than the linear one, IMHO. The self made one was, um, interestingly made. I scribed it on stainless steel, but based on a divider plotted on A3 paper using a Roland flat bed plotter. I think I wrote a QuickBasic program to generate the HPGL for the divider.

Comment Re:Scheme looks scary and unreadable to me (Score 1) 107

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.

Comment Re:Perl hater (Score 4, Interesting) 173

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.

Comment Re:Best you've got = bogus downmods? (Score 1) 108

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.

Slashdot Top Deals

To restore a sense of reality, I think Walt Disney should have a Hardluckland. -- Jack Paar