Best language for n00bs

[EduardoLeon]

IMHO, the best way to learn is using x86 assembly. If all you have is a C compiler, use inline assembly. Starting with Java or .NET makes you idiot. Starting with a dynamic language makes you even more idiot. Learn how computers work and only then, after you have learnt (and suffered) quite a lot, switch to a tool that lets you get more work done in less time.

If all you have ever used is a framework that does all the work for you, you haven't learnt how to program. And you will always be a n00b.

[The EGE]

IMHO, the best way to learn is using x86 assembly. If all you have is a C compiler, use inline assembly. Starting with Java or .NET makes you idiot. Starting with a dynamic language makes you even more idiot. Learn how computers work and only then, after you have learnt (and suffered) quite a lot, switch to a tool that lets you get more work done in less time.

If all you have ever used is a framework that does all the work for you, you haven't learnt how to program. And you will always be a n00b.

So... the best way to learn to program is to be a masochist, choose an abusive language, and suffer for a while before you switch to something that actually lets you work efficently?

Unless you are going to write an OS, or a security suite, or a web browser, then you don't have to work with the guts of the computer - you're just writing an application that runs on the OS. Learning assembly is not going to get you anywhere fast. Learning Java, or Python, will let you try lots of cool stuff and try many different techniques, and ultimately, I think it's exploring your language and learning how to do a lot of different things with it, and challenging yourself, that makes a good programmer.

And honestly Eduardo, you sound like a stodgy old guy who walks aroung mumbling about 'kids these days' and 'hell in a handbasket'.

[EduardoLeon]

Learning Java, or Python, will let you try lots of cool stuff and try many different techniques

No technique can be "cooler" or "more badass" than multiple inheritance and templates, so, if you want to suggest him a language that provides "cool facilities", then suggest him C++. Java and Python are rather limited, compared to C++. In particular, Java enforces type safety so much that it's doomed to always being slow. Python can be fun to use if you want to write quick-n-dirty apps, though.

[Berengal]

Java enforces type safety so much that it's doomed to always being slow

I'll assume you mean slow to write, not slow to run. Haskell enforces type safety to a much much greater degree than Java, but it's much faster to write.

No technique can be "cooler" or "more badass" than multiple inheritance and templates

Haskell runs circles around C++ when it comes to cool features, but the best part is most of them are implemented as simple libraries on top of the relatively small core language...

[EduardoLeon]

I'll assume you mean slow to write, not slow to run.

Java is too slow to run for my needs. And since I'm so selfish and self-centered, I don't care whether Java is fast for you.

Haskell runs circles around C++ when it comes to cool features, but the best part is most of them are implemented as simple libraries on top of the relatively small core language...

... that can't be compiled to binary!

[Xanthir]

Haskell runs circles around C++ when it comes to cool features, but the best part is most of them are implemented as simple libraries on top of the relatively small core language...

... that can't be compiled to binary!

Huh? Haskell can certainly be compiled. So can Lisp, which at its core is only *7* functions. (Of course, for performance no one actually implements everything in just those 7 functions - a lot of the base language is open-coded in assembly in any non-toy implementation.)

[EduardoLeon]

Huh? Haskell can certainly be compiled. So can Lisp, which at its core is only *7* functions. (Of course, for performance no one actually implements everything in just those 7 functions - a lot of the base language is open-coded in assembly in any non-toy implementation.)

AFAIK, Haskell can be compiled to another functional language, not machine code the processor understands. (Of course, you can pack the compiled code with an interpreter for the target language in an executable.)

[stephentyrone]

You fool! You fell victim to one of the classic blunders! The most famous is never get involved in a land war in Asia, but only slightly less well-known is this: never go in against the XKCD fora when Haskell is on the line!

[Xanthir]

Huh? Haskell can certainly be compiled. So can Lisp, which at its core is only *7* functions. (Of course, for performance no one actually implements everything in just those 7 functions - a lot of the base language is open-coded in assembly in any non-toy implementation.)

AFAIK, Haskell can be compiled to another functional language, not machine code the processor understands. (Of course, you can pack the compiled code with an interpreter for the target language in an executable.)

Someone lied to you, or else you have a definition of "functional language" which includes machine code.

[EduardoLeon]

If there is an implementation of Haskell that compiles to machine code and is comparable in speed to C++, please let me know. I'll gladly use it. (I mean, who doesn't hate the STL and Boost after using them?)

[stephentyrone]

I mean, who doesn't hate the STL and Boost after using them?

Yakk, 0xBADFEED, and phlip, apparently.

[Briareos]

If there is an implementation of Haskell that compiles to machine code and is comparable in speed to C++, please let me know.

GHC.

[EduardoLeon]

If there is an implementation of Haskell that compiles to machine code and is comparable in speed to C++, please let me know.

GHC.

Nice, I will try it.

[0xBADFEED]

Wow.
I like this EduardoLeon character.
Mind you, I disagree with pretty much everything he has said in every single post. Most of it is either inaccurate or just outright false.

But you have to admire his bravado. Seldom have I seen someone be so wrong with such flair.

*golf clap*

[The EGE]

Wow.
I like this EduardoLeon character.
Mind you, I disagree with pretty much everything he has said in every single post. Most of it is either inaccurate or just outright false.

But you have to admire his bravado. Seldom have I seen someone be so wrong with such flair.

*golf clap*

Quoth my awesome band director: "If you're going to be wrong, be wrong LOUD"

[EduardoLeon]

http://www.haskell.org/haskellwiki/Introduction#When_C_is_better

So Haskell is just another high-level language for kids. Even Haskell apologists admit it.

Functional programming is like mathematics. When you do mathematics, you don't care how contrived and long the proof is, as long as it's a correct proof. When you do functional programming, you don't care how much the program takes to run, as long as it performs the correct computation.

[stephentyrone]

http://www.haskell.org/haskellwiki/Introduction#When_C_is_better
So Haskell is just another high-level language for kids. Even Haskell apologists admit it.

C is just another high-level language for kids. If you're doing micro-optimization at the level where small constant factors are your concern, it's asm or nothing (well, ok, sometimes I have to write machine code to work around assembler bugs, but I usually manage to avoid it). If you're writing code at any level above that, you're writing to an abstract machine anyway, so chose whichever you find it easiest to work with. C, scheme, haskell, D, Java, whatever. To the people who use them, they're all wonderful, and you can teach someone to program using any of them.

I'm a professional assembly programmer, and I wouldn't teach anyone to code using assembly. That said, I wouldn't force the way I would choose to teach on anyone either: good old fashioned writing scheme programs with pencil and paper (that's how I learned, for the most part -- no computer at home or at school, but the library had a copy of the little schemer and the wizard book).

And if I was going to teach someone using assembly, I sure as hell wouldn't chose x86 ASM. It's the cruftiest, least-orthogonal, ugliest instruction set in existence, with performance hazards and instruction timings that even Intel's own simulator can't model perfectly. I'd probably use an ARM board with no extensions. Or PPC. Or IA64. Anything but x86.

[EduardoLeon]

Of course C is just a toy too. In my first post, I suggested starting with assembly because it teaches you how your computer works. (Machine code can be avoided only because it doesn't provide any additional insight.) It's similar to the way how people learn maths. First, you learn the basic operations and how to use them to solve simple problems ("if I have two apples and then I eat one..."), which get increasingly more difficult ("my age is half the age she will have when I marry..."). Then, you learn more powerful tools, like algebra and calculus, and how to use them to solve rather simple problems ("what's the rate at which...?"), which get increasingly more difficult ("two bodies are initially left in an empty space with some initial speeds, forced only by their gravitational attraction..."). Only after you understand how all of this works, you can grab a programmable calculator and use it to solve a differential equation numerically.

Ok, programming is similar. First, you learn the basic operations (MOV, ADD, SUB, etc.) and how to use them to solve simple problems (printing text to the screen, reading a number as a string and converting it to an actual number in memory), which get increasingly longer (not more difficult, just longer). Then, as assembly starts getting tedious, you wonder... are there any tools that can automate this task for me, even if just a bit? Then, you learn more powerful tools, like structured programming, and how to use them to solve rather simple problems (say, programming the logic of a cards game), which get increasingly more difficult (say, programs that require function pointers). Then, you learn more powerful tools, like object-oriented programming, with its vtables and such and, when you find how much C++ sucks, you start using managed environments and frameworks and etc., etc., etc. But don't get too far, or you will end up using Ruby and pretending computers are human.

In the end, you will almost never use assembly, FORTRAN or C. But learning how the machine works MUST BE before creating a website and copy-pasting some JavaScript to make a form work

And if I was going to teach someone using assembly, I sure as hell wouldn't chose x86 ASM. It's the cruftiest, least-orthogonal, ugliest instruction set in existence, with performance hazards and instruction timings that even Intel's own simulator can't model perfectly. I'd probably use an ARM board with no extensions. Or PPC. Or IA64. Anything but x86.

x86 assembly is ugly, but it works. An interesting project would be writing an x86 assembler without bugs using x86 assembly and compiling it with an assembler with bugs (!), a goal that could be achieved if we used Dijkstra's approach to software design.

x86 assembly is ugly, but I don't want to buy another motherboard just to start learning programming.

[The EGE]

http://www.haskell.org/haskellwiki/Introduction#When_C_is_better
Functional programming is like mathematics. When you do mathematics, you don't care how contrived and long the proof is, as long as it's a correct proof. When you do functional programming, you don't care how much the program takes to run, as long as it performs the correct computation.

Wrong and wrong.

For mathematical proofs, ideally you do want the most simple and elegant proof. For the first proof, yes, you want a bulletproof proof, even if it's a bit long and convoluted. But after that, you're going to look for the most elegant proof. Consider Paul Erdos's idea of the book, a theoretical book in which a diety would keep the msot elegant proofs for every mathematical idea.

For a functional program, you do care how long it takes to run. No one will buy or use a web browse that takes 5 minutes to start, and for something like a mathematical compuation that takes hours, speed is also of the essence. I spend hours optimizing my programs to take get a few percent improvement in speed. I'd much rather be able to simulate a rocket launch in seconds and milliseconds rather than minutes.

You seem to be of the mind that anything easy is not worth doing, and therefore anything that makes any task easier is not worth it. Well, you know what? You're wrong. You're just fucking wrong. No one uses FORTRAN anymore, and if you do you'll beat yourself up for hours and hours, and not learn a lot, and not do much of anything, and you'll probably tire of programming before you get anywhere. Same with assembly. Anything you can do in FORTRAN, I can do on my calculator in a tenth the time. Meanwhile, if someone starts out with something fast, easy, and sensible like Python, they'll be doing awesome things very quickly, and doing awesome things is the best way to learn.

[EduardoLeon]

For mathematical proofs, ideally you do want the most simple and elegant proof.

Your concept of "most simple" seems to be "the proof that can be written using the least steps, the better".

My concept of "most simple" is "the proof that can be written using the least FUNDAMENTAL steps (applying axioms), the better".

Of course, anybody can write a simple proof using other other people's theorems. Of course, anybody can write small programs using libraries and frameworks (and fundamental instructions such as printing a string, sorting lists and multiplying vectors). But your processor won't treat each "fundamental instruction" as an actual single instruction.

In mathematics, you can use different axioms to define an equivalent system. The computing equivalent of that would be defining a different instruction set capable of doing the same computing tasks. If you define an instruction set that treats strings, lists and vectors natively, I'll gladly use a language that treats them as first-class citizens. Because that would be the way the machine works.

You seem to be of the mind that anything easy is not worth doing, and therefore anything that makes any task easier is not worth it. Well, you know what? You're wrong. You're just fucking wrong.

I am of the mind that losing efficiency is a price too high to pay for an irrelevant (for the user) thing such as making the program simple to program. Also refer to my last paragraph about treating complicated objects as first-class citizens.

Meanwhile, if someone starts out with something fast, easy, and sensible like Python, they'll be doing awesome things very quickly, and doing awesome things is the best way to learn.

Evidently, our concepts of "awesome" differ.

[0xBADFEED]

I am of the mind that losing efficiency is a price too high to pay for an irrelevant (for the user) thing such as making the program simple to program. Also refer to my last paragraph about treating complicated objects as first-class citizens.

Pray tell, what kind of software do you write that requires such blinding speed?

[EduardoLeon]

I am of the mind that losing efficiency is a price too high to pay for an irrelevant (for the user) thing such as making the program simple to program. Also refer to my last paragraph about treating complicated objects as first-class citizens.

Pray tell, what kind of software do you write that requires such blinding speed?

Software that sends MIDI instructions to my keyboard. Continuous-time simulation software. A math library exposing the following data types: tensors, Bézier curves, B-splines, differentiable functions, geometrical objects defined from "patches", etc. And I'm currently implementing my very own alternative to @RISK.

[stephentyrone]

Software that sends MIDI instructions to my keyboard.

You can saturate a MIDI channel from python on a 386.

Continuous-time simulation software.

May or may not require native hardware performance, depending on what you're actually simulating.

A math library exposing the following data types: tensors, Bézier curves, B-splines, differentiable functions, geometrical objects defined from "patches", etc.

Almost certainly doesn't require native hardware speed, and would be much easier to implement in a higher-level language. "Professional" math software is rarely written in C, except for a small computational kernel.

And I'm currently implementing my very own alternative to @RISK.

There are excellent high-performance monte carlo libraries available in pretty much every commonly used language. Using one of those would give superb performance.

None of which is to say that you shouldn't use C (I probably would, because I like programming in C). But it does mean that C isn't, by any stretch of the imagination, necessary for these problems.

[Berengal]

Not going to let myself be drawn into the discussion proper, but I'm going to post a few links:
http://shootout.alioth.debian.org/u64q/benchmark.php?test=pidigits&lang=all&box=1
http://shootout.alioth.debian.org/u64q/benchmark.php?test=threadring&lang=all&box=1

In particular the last link is interesting:

• There are 7 languages faster than C
• 4 of them are more than 5 times as fast
• Haskell is almost 20 times as fast, and uses less memory
• 3 are functional.
• The functional languages all have a smaller source file
• 3 are dynamically typed
• 2 are bytecode-interpreted
• 2 are source-interpreted
• 2 use mathematical reasoning to optimize. One is haskell, the other is AST, which is basically C with dependent types

[EduardoLeon]

@Berengal:

Not going to let myself be drawn into the discussion proper, but I'm going to post a few links:
http://shootout.alioth.debian.org/u64q/benchmark.php?test=pidigits&lang=all&box=1
http://shootout.alioth.debian.org/u64q/benchmark.php?test=threadring&lang=all&box=1

In particular the last link is interesting:

• There are 7 languages faster than C
• 4 of them are more than 5 times as fast
• Haskell is almost 20 times as fast, and uses less memory
• 3 are functional.
• The functional languages all have a smaller source file
• 3 are dynamically typed
• 2 are bytecode-interpreted
• 2 are source-interpreted
• 2 use mathematical reasoning to optimize. One is haskell, the other is AST, which is basically C with dependent types

Writing an efficient C program is hard. Of course, if you malloc and free little chunks of memory here and there, you're going to be in big trouble after a while. Real Men estimate how much memory they will need, and then allocate it. If they need to allocate more memory, they realloc twice (or some other number of times) the memory they allocated before. It's not that difficult, it only requires thinking. But people writing benchmarks are usually trying to promote the latest fashionable toy language, so they use C and/or C++ in a naïve and sloppy way.

Besides that, most C compilers suck. They have needless flags, when they could always optimize for both speed and low memory usage.

@stephentyrone:

Software that sends MIDI instructions to my keyboard.

You can saturate a MIDI channel from python on a 386.

As a Dream Theater fan, I really care about the (well, almost) exact timing of every 32nd note. My program must be fast, even when I'm running a virtual machine in another process. Even when I'm running Windows in that virtual machine. Even when I'm running Visual Studio in that Windows instance.

Continuous-time simulation software.

May or may not require native hardware performance, depending on what you're actually simulating.

Continuous-time simulations in which the computer simulates only part of the system and the rest of the system is being run in real life requires native hardware performance. Real life won't wait.

A math library exposing the following data types: tensors, Bézier curves, B-splines, differentiable functions, geometrical objects defined from "patches", etc.

Almost certainly doesn't require native hardware speed, and would be much easier to implement in a higher-level language. "Professional" math software is rarely written in C, except for a small computational kernel.

I think assembly is THE language to implement multilinear algebra and numerical calculus. I concede that other functionality built upon this foundation can be implemented in a toy language, like C. Using human language interpreters such as Java or Python is an excess.

And I'm currently implementing my very own alternative to @RISK

There are excellent high-performance monte carlo libraries available in pretty much every commonly used language. Using one of those would give superb performance.

I've seen C++ be slow for second-order simulation.

[Berengal]

But people writing benchmarks are usually trying to promote the latest fashionable toy language, so they use C and/or C++ in a naïve and sloppy way.

Then I'm sure you can improve on it. The shootout accepts submissions from everyone. The current fastest C submission is also pretty simple, not doing any dynamic memory allocation, or even stack allocation. Everything's allocated statically at compile-time.

[EduardoLeon]

I would if today wasn't my birthday. I will review the source next weekend.

[Xanthir]

Ok, programming is similar. First, you learn the basic operations (MOV, ADD, SUB, etc.) and how to use them to solve simple problems (printing text to the screen, reading a number as a string and converting it to an actual number in memory), which get increasingly longer (not more difficult, just longer). Then, as assembly starts getting tedious, you wonder... are there any tools that can automate this task for me, even if just a bit? Then, you learn more powerful tools, like structured programming, and how to use them to solve rather simple problems (say, programming the logic of a cards game), which get increasingly more difficult (say, programs that require function pointers). Then, you learn more powerful tools, like object-oriented programming, with its vtables and such and, when you find how much C++ sucks, you start using managed environments and frameworks and etc., etc., etc. But don't get too far, or you will end up using Ruby and pretending computers are human.

In the meantime, your mind has been irreparably poisoned by explicitly statement-oriented languages, so that you can never use a proper functional language correctly; it always feels somehow 'wrong' and unnatural, and you wonder why your programs are slow and ugly when you're just implementing the algorithms the same way you always have.

You've also gotten the idea that there's nothing *wrong* with long programs or repetition, though you use tools to avoid it sometimes. Your programs contain bogs of (hopefully!) copy-pasted code, duplicated functionality, and logic that actually requires inline comments to understand. You never see the 'big deal' about being able to write an algorithm in less than five lines, or understand what DRY means and how vitally important it is. You end up assuming that performance is the be-all-end-all of programming and create write-only programs that *hopefully* your fiery genius can still understand, but lesser mortals can only badly imitate, fostering a culture of bugs and ruinous maintenance costs. And one day, when staring at your 500 MLOC application (or rather, as much of it as you can scroll through quickly), you wonder where it all went wrong, which decision it was that led to this and, had you decided differently that day, could have avoided it all. Then you put your head down and hack, and hack, and hack, because that's all that's left to you in your shattered, wasted life.

See? Assembly ruins lives. QED.

But learning how the machine works MUST BE before creating a website and copy-pasting some JavaScript to make a form work

This doesn't make any sense whatsoever. Javascript is so high-level that knowing how the machine works is worth very little. What value you *can* derive from that knowledge you can get without sacrificing your innocence at the black altar of imperative programming.

[EduardoLeon]

In the meantime, your mind has been irreparably poisoned by explicitly statement-oriented languages, so that you can never use a proper functional language correctly; it always feels somehow 'wrong' and unnatural, and you wonder why your programs are slow and ugly when you're just implementing the algorithms the same way you always have.

I can do functional programming. [sarcasm] I've been waiting for a processor that does expression reduction (efficiently, of course) natively for years. When such a processor is commercially viable, I will give up imperative programming, I swear. [/sarcasm]

In my experience, functional programming is a practical tool only to teach lambda calculus. It's not fundamentally "wrong", of course. But reducing a functional specification to the most efficient instruction sequence is an undecidable problem. Thus, you can only and at best use heuristics and metaheuristics to *hopefully* reduce your functional specifications to somewhat efficient instruction sequences.

So the moral of the story is... why let a computer that doesn't think reduce the functional specification to its actual implementation, when you, a thinking human, can do it? My answer is that "because it takes less effort" is not a good answer.

You've also gotten the idea that there's nothing *wrong* with long programs or repetition, though you use tools to avoid it sometimes. Your programs contain bogs of (hopefully!) copy-pasted code, duplicated functionality, and logic that actually requires inline comments to understand. You never see the 'big deal' about being able to write an algorithm in less than five lines, or understand what DRY means and how vitally important it is.

I never duplicate functionality at source level. Ever heard of macros and templates? If they didn't exist, I would create a preprocessor of my own. However, I don't think there's anything wrong with a longer program than another if the former does the same thing with less loops and, most important of all, using the call stack (or call "insert data structure", if I'm doing coroutines) more wisely than the latter.

You end up assuming that performance is the be-all-end-all of programming and create write-only programs that *hopefully* your fiery genius can still understand, but lesser mortals can only badly imitate, fostering a culture of bugs and ruinous maintenance costs. And one day, when staring at your 500 MLOC application (or rather, as much of it as you can scroll through quickly), you wonder where it all went wrong, which decision it was that led to this and, had you decided differently that day, could have avoided it all. Then you put your head down and hack, and hack, and hack, because that's all that's left to you in your shattered, wasted life.

I can use libraries and appreciate modularity too. But, when I write a program using libraries, I try to minimize not the number of lines of code, but the number of atomic instructions actually executed (CALL and JMP (and its variants) instructions not counting, or else I would never use libraries, of course). My knowledge of what happens under the hood when I use a library prevents me from programming as if the functions exposed by it were native functions. Take instead those sloppy "programmers" who only know Matlab. They write programs as if matrix multiplication and Fourier transforms were processor instructions, when they are so evidently not.

And my life's not wasted if I can make a performance improvement that matters to the user.

This doesn't make any sense whatsoever. Javascript is so high-level that knowing how the machine works is worth very little. What value you *can* derive from that knowledge you can get without sacrificing your innocence at the black altar of imperative programming.

First, that using lots of JavaScript in a Web page hurts performance. I mean, you actually know what the previous sentence means; not just follow blindly a "best practice".

Second, that JavaScript is the main reason why browsers leak memory. Then, you start writing your scripts more carefully.

Finally, that the Web sucks. There are much better uses for the Internet.

[Philwelch]

In my experience, functional programming is a practical tool only to teach lambda calculus.

Funny, I thought the only practical use of the lambda calculus was to enable functional programming. And to motivate the Church-Turing thesis.

So the moral of the story is... why let a computer that doesn't think reduce the functional specification to its actual implementation, when you, a thinking human, can do it? My answer is that "because it takes less effort" is not a good answer.

Have fun being a human compiler.

I never duplicate functionality at source level. Ever heard of macros and templates? If they didn't exist, I would create a preprocessor of my own.

Oh, dear God.

I thought we all agreed by now that text-level code generation and metaprogramming was a silly, silly idea. If you're going to write macros, write them in a language that lets you write macros against the abstract syntax tree. (Whoa, there are languages that let you do that? Yup, of course there are, didn't you know?)

[Berengal]

I thought we all agreed by now that text-level code generation and metaprogramming was a silly, silly idea. If you're going to write macros, write them in a language that lets you write macros against the abstract syntax tree. (Whoa, there are languages that let you do that? Yup, of course there are, didn't you know?)

Of course, you could write your code-generating code in another language, such as haskell. At this point you get all kinds of fun stuff, like language fixed-points and Futamura's projections.

[The EGE]

You end up assuming that performance is the be-all-end-all of programming and create write-only programs that *hopefully* your fiery genius can still understand, but lesser mortals can only badly imitate, fostering a culture of bugs and ruinous maintenance costs. And one day, when staring at your 500 MLOC application (or rather, as much of it as you can scroll through quickly), you wonder where it all went wrong, which decision it was that led to this and, had you decided differently that day, could have avoided it all. Then you put your head down and hack, and hack, and hack, because that's all that's left to you in your shattered, wasted life.

I can use libraries and appreciate modularity too. But, when I write a program using libraries, I try to minimize not the number of lines of code, but the number of atomic instructions actually executed (CALL and JMP (and its variants) instructions not counting, or else I would never use libraries, of course). My knowledge of what happens under the hood when I use a library prevents me from programming as if the functions exposed by it were native functions. Take instead those sloppy "programmers" who only know Matlab. They write programs as if matrix multiplication and Fourier transforms were processor instructions, when they are so evidently not.

And my life's not wasted if I can make a performance improvement that matters to the user.

If you are still writing in assembly, then you are the only one who can understand your code. No one else can debug it or find ways to *gasp* improve it. If someone else needs to work with it, they cannot. People like you were why Y2K had the potential to be devastating - people writing mainframe programs in archaic languages like COBOL, never updating them with newer, more common languages, and then retiring, leaving no one to fix the program when its original shortcomings posed a huge problem.

And as far as I'm concerned, when I'm in matlab, I'd rather be able to type fft and take a little performance hit than writing 30 lines of assembly and having my program run 1% faster. Sometimes absolute performance has to take a backseat to programmability and the ability for others to understand and safely modify your code. Unless you are the only one using your programs, then you should not be the only one able to understand the syntax of those programs.

Finally, that the Web sucks.

Then get the hell off it.

[EduardoLeon]

I thought we all agreed by now that text-level code generation and metaprogramming was a silly, silly idea. If you're going to write macros, write them in a language that lets you write macros against the abstract syntax tree. (Whoa, there are languages that let you do that? Yup, of course there are, didn't you know?)

There's no such thing as an AST in an assembler. The only thing you can replace are source code text or binary code.

Of course, you could write your code-generating code in another language, such as haskell. At this point you get all kinds of fun stuff, like language fixed-points and Futamura's projections.

I do Futamura projections by hand. And why give it a pompous name when the idea behind it is so simple (evaluating static arguments at compile time)?

And as far as I'm concerned, when I'm in matlab, I'd rather be able to type fft and take a little performance hit than writing 30 lines of assembly and having my program run 1% faster. Sometimes absolute performance has to take a backseat to programmability and the ability for others to understand and safely modify your code. Unless you are the only one using your programs, then you should not be the only one able to understand the syntax of those programs.

I'm not against using Matlab per se. I'm against not knowing that what you're doing sometimes implies a performance hit. If you never program in a low-level language, you never know what that performance hit is about. If you know what the atomic instructions are, you know how to program efficiently both using atomic instructions and using complex instructions built upon these atomic instructions.

Finally, that the Web sucks.

Then get the hell off it.

There's no replacement for the Web, unfortunately.

[Philwelch]

I thought we all agreed by now that text-level code generation and metaprogramming was a silly, silly idea. If you're going to write macros, write them in a language that lets you write macros against the abstract syntax tree. (Whoa, there are languages that let you do that? Yup, of course there are, didn't you know?)

There's no such thing as an AST in an assembler. The only thing you can replace are source code text or binary code.

Yeah, I thought you meant C preprocessor macros or C++ templates. You could write assembler macros, and if you did enough of that you would probably invent C, and then people would make fun of you for it.

[EduardoLeon]

I thought we all agreed by now that text-level code generation and metaprogramming was a silly, silly idea. If you're going to write macros, write them in a language that lets you write macros against the abstract syntax tree. (Whoa, there are languages that let you do that? Yup, of course there are, didn't you know?)

There's no such thing as an AST in an assembler. The only thing you can replace are source code text or binary code.

Yeah, I thought you meant C preprocessor macros or C++ templates. You could write assembler macros, and if you did enough of that you would probably invent C, and then people would make fun of you for it.

I wouldn't invent C. I'd invent a better C (not C++, which IMHO is a worse C). First of all, no call stack! You define the call data-structure. Second, I'd also define a keyword to mark variables that won't be modified by any other threads. Third, ...

[Philwelch]

You could write assembler macros, and if you did enough of that you would probably invent C, and then people would make fun of you for it.

I wouldn't invent C. I'd invent a better C (not C++, which IMHO is a worse C). First of all, no call stack! You define the call data-structure. Second, I'd also define a keyword to mark variables that won't be modified by any other threads. Third, ...

Sure, but C wasn't invented to be a better C. It was invented as a small, quick, pragmatic language designed to generate PDP assembly that encoded a lot of the assumptions (e.g. ASCIZ string representation) they had at the time.

[Xanthir]

In the meantime, your mind has been irreparably poisoned by explicitly statement-oriented languages, so that you can never use a proper functional language correctly; it always feels somehow 'wrong' and unnatural, and you wonder why your programs are slow and ugly when you're just implementing the algorithms the same way you always have.

I can do functional programming. [sarcasm] I've been waiting for a processor that does expression reduction (efficiently, of course) natively for years. When such a processor is commercially viable, I will give up imperative programming, I swear. [/sarcasm]

In my experience, functional programming is a practical tool only to teach lambda calculus. It's not fundamentally "wrong", of course. But reducing a functional specification to the most efficient instruction sequence is an undecidable problem. Thus, you can only and at best use heuristics and metaheuristics to *hopefully* reduce your functional specifications to somewhat efficient instruction sequences.

So the moral of the story is... why let a computer that doesn't think reduce the functional specification to its actual implementation, when you, a thinking human, can do it? My answer is that "because it takes less effort" is not a good answer.
[snip more stuff]

I'm glad that you are a supergenius who can hold every detail of your programs in your head at once, and write code so bug-free that other humans have no need to look at it, let alone correct it.

Most of us are not and do not. We take whatever cognitive shortcuts we can get to make programming as simple as possible, because this shit really is pretty fucking hard. More details are involved in programming a complex application than in any other engineering project on the planet, and people being macho about it are the reason that we have the highest failure rate of any engineering discipline in the world. I measure my progress in terms of LOC *not* written - every line saved is a line that can't cause bugs or complicate my mental model. I value turning in a better-functioning product over one that might run more efficiently but that is ruinously complex and thus can't be extended easily. Making my programming take less effort really is a valuable goal, because the amount of effort I can put forth is a finite quantity and I'd rather convert it into a program using higher-octane fuel.

[The EGE]

What Xanthir said. He hit the nail on the head there so hard it just went all the way through the wall.

You may have a photographic memory, Eduardo, and be the only person who ever needs to reverse-engineer or modify your code, but for the rest of us, a lot of simplicity writing the code beats out a little bit of simplicity for my processor to deal with.

[EduardoLeon]

I'm glad that you are a supergenius who can hold every detail of your programs in your head at once, and write code so bug-free that other humans have no need to look at it, let alone correct it.

Most of us are not and do not. We take whatever cognitive shortcuts we can get to make programming as simple as possible, because this shit really is pretty fucking hard.

I'm not a supergenius. I use high-level tools when they are needed. But I do care, at least to some extent, about what's happening below the abstraction layer I'm working at. ALWAYS.

See:

• http://en.wikipedia.org/wiki/Leaky_abstraction
• http://www.joelonsoftware.com/articles/LeakyAbstractions.html

More details are involved in programming a complex application than in any other engineering project on the planet, and people being macho about it are the reason that we have the highest failure rate of any engineering discipline in the world.

I am not being macho. I just said that low-level stuff matters and every programmer should start learning that first. High-level programming is good and necessary, but to write good programs using high-level languages, you must know how they work internally down to, at least, OS level.

I measure my progress in terms of LOC *not* written - every line saved is a line that can't cause bugs or complicate my mental model.

I do that as well. But only when it doesn't interfere with performance in a way that I consider critical.

I value turning in a better-functioning product over one that might run more efficiently but that is ruinously complex and thus can't be extended easily. Making my programming take less effort really is a valuable goal, because the amount of effort I can put forth is a finite quantity and I'd rather convert it into a program using higher-octane fuel.

The way how engineers (should) design is about making compromises. Every product has different needs. Whether you prioritize performance, extensibility, programmability or any other desirable feature shouldn't be decided dogmatically, but in a per case basis.

---

Some people have misinterpreted me. I never said "stay stuck using archaic tools forever". I just said "what happens under the hood matters and should be learnt before using this foundation to make fancy stuff". The heat of the discussion got me a bit carried away. (And, admit it, you all were a bit carried away as well.)

[Philwelch]

I don't really disagree for the most part--you need to understand how it works on the low level--but programmers who start from that level usually have a hard time working at any higher level.

The fact is, you'll do a better job 70+% of the time working in high level languages and, where necessary, using profilers to optimize where performance is empirically important than you'll do starting with a low level language and playing human compiler.