Best language for n00bs

Please compose all posts in Emacs.

Moderators: phlip, Prelates, Moderators General

Re: Best language for n00bs

Postby EduardoLeon » Mon Oct 05, 2009 5:21 am UTC

Philwelch wrote: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.


False. It's programmers who start from a very high level who have trouble working at any lower level. If you explain a low level programmer how high level facilities (say, coroutines, virtual functions) are actually implemented, he will be able to understand and use them.

Philwelch wrote: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.


Of course, but learning low-level comes first.
Gott weiß ich will kein Engel sein!
EduardoLeon
 
Posts: 111
Joined: Wed Sep 30, 2009 2:26 am UTC
Location: Lima, Perú

Re: Best language for n00bs

Postby ash.gti » Mon Oct 05, 2009 1:34 pm UTC

Then why is it that most computer scientists that return to school are doing so because they can't get a hold of newer things like OO design? I am talking about the ones that spent like 30 years doing COBOL or fortran or assembly professionally. According to my last college professor, most of the returning students that were from the old crowd or getting a masters later in life that had started and worked primarily with those low level things never got the hang of OO design and came back to school to re-learn them, not to mention they probably don't know the first thing about functional programming other than lisp has lots of parenthesis. Not to mention the lack of understanding of things like process and SQA.
# drinks WAY to much espresso
User avatar
ash.gti
 
Posts: 404
Joined: Thu Feb 07, 2008 1:18 am UTC
Location: Probably a coffee shop.

Re: Best language for n00bs

Postby Xanthir » Mon Oct 05, 2009 3:12 pm UTC

EduardoLeon wrote:
Xanthir wrote: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.

The problem is that your apparent bar for what's "critical" is far lower than it should reasonably be. As a result of this you appear to reject functional languages outright, simply because they can produce code less efficient than what a skilled programmer can do in a lower-level language. You appear to have glommed onto this idea hard enough to uncritically accept FUD like "functional languages can't be compiled" (though hopefully that, at least, has been shown to be incorrect).

Xanthir wrote: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.

Indeed, but the truth is that in almost all situations, valuing programmability is the correct first choice. While you should of course strive not to be wasteful of cycles, actually making performance a *priority* should *only* happen when there is a provable need for it; that is, when a profiler shows you that a particular area of your code is lagging.

Violating this maxim is very nearly always a bad idea. Programmer cycles are in much tighter supply than processor cycles, and so should be carefully meted out in the way that spends them most efficiently.

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.)

Of course I got carried away - that's what makes the discussions fun. As long as no direct insults are flying, outright hyperbole can be a wonderful way to elucidate disagreements.

I'm not trying to imply that understanding your OS and processor is a bad thing; far from it! I think having at least a rudimentary knowledge of assembly is a necessity for being a good programmer (and think that one should similarly have a rudimentary knowledge of digital logic - can't get any lower-level than that and still be working on something you would call a "computer"!). But I strongly disagree that this knowledge should come *first*, or that it's the most important consideration to make. You have to understand the efficiency model of your language, and understanding that requires knowledge about the efficiency models of the languages below it. It is, however, vitally important to learn *when* to care about efficiency; the correct answer is usually far less than you would think.

In a world without Moore's Law, your outlook makes more sense. But we've been riding the crest of exponential speed growth for 40+ years now, and there's still no end in sight, so one should adjust themselves to reality. What is too inefficient today will become acceptable tomorrow, and trivial the day after that. It's more important to value efficiency in spending quantities that *are* finite, like programmer time and attention.
(defun fibs (n &optional (a 1) (b 1)) (take n (unfold '+ a b)))
User avatar
Xanthir
My HERO!!!
 
Posts: 4336
Joined: Tue Feb 20, 2007 12:49 am UTC
Location: The Googleplex

Re: Best language for n00bs

Postby Philwelch » Mon Oct 05, 2009 3:21 pm UTC

Xanthir wrote:In a world without Moore's Law, your outlook makes more sense. But we've been riding the crest of exponential speed growth for 40+ years now, and there's still no end in sight, so one should adjust themselves to reality. What is too inefficient today will become acceptable tomorrow, and trivial the day after that. It's more important to value efficiency in spending quantities that *are* finite, like programmer time and attention.


In fact, the particular shape Moore's Law is now taking almost dictates a focus on functional programming. Now that multicore is the norm, functional programming will become more and more important since there's no other easy way to take advantage of concurrency.
Fascism: If you're not with us you're against us.
Leftism: If you're not part of the solution you're part of the problem.

Perfection is an unattainable goal.
Philwelch
 
Posts: 2904
Joined: Tue Feb 19, 2008 5:33 am UTC
Location: RIGHT BEHIND YOU

Re: Best language for n00bs

Postby stephentyrone » Mon Oct 05, 2009 3:40 pm UTC

Philwelch wrote:In fact, the particular shape Moore's Law is now taking almost dictates a focus on functional programming. Now that multicore is the norm, functional programming will become more and more important since there's no other easy way to take advantage of concurrency.


Concurrency is never easy*, not even in functional languages. Even if a language saves you from explicitly specifying which tasks are suitable for concurrent execution, Amdahl's law will neuter the parallelization gains of any non-trivial algorithm unless it's constructed with careful consideration of concurrency. Implementing concurrent algorithms can be easier in functional languages, but designing them is the real challenge. By the time you get to 128 processors, the difference between 2% serial computation and 1% serial computation is nearly 60% of overall application performance. Asymptotically it's a 2x speedup.

All of which isn't to say that functional programming isn't great, or that indicating concurrent tasks generally needs to get simpler, but it is to say that functional programming is magic fairy dust. A poorly chosen algorithm will suck no matter how you implement it.

*for non-trivial tasks
GENERATION -16 + 31i: The first time you see this, copy it into your sig on any forum. Square it, and then add i to the generation.
stephentyrone
 
Posts: 779
Joined: Mon Aug 11, 2008 10:58 pm UTC
Location: Palo Alto, CA

Re: Best language for n00bs

Postby EduardoLeon » Mon Oct 05, 2009 4:05 pm UTC

ash.gti wrote:Then why is it that most computer scientists that return to school are doing so because they can't get a hold of newer things like OO design? I am talking about the ones that spent like 30 years doing COBOL or fortran or assembly professionally.


COBOL, FORTRAN and assembly don't encourage modularity, encapsulation and those things that are needed when a large system is being developed. But that doesn't mean that you can't write modular programs in those languages. If, after toying with any programming language, especially a low level one, you haven't found how important it's to divide big problems in smaller parts and, thus, big programming projects into several subprograms as least interrelated as possible, then you haven't been born for programming, engineering or any other discipline that requires structured thinking.

ash.gti wrote:According to my last college professor, most of the returning students that were from the old crowd or getting a masters later in life that had started and worked primarily with those low level things never got the hang of OO design and came back to school to re-learn them, (...)


Object-oriented design has never struck me as something oh-so-difficult like, say, thermodynamics or quantum mechanics. The concepts of "class", "object", "message", "inheritance", "encapsulation", "polymorphism", "object-oriented design pattern" etc. are rather straightforward. Inheritance means "don't implement the damn thing twice". Encapsulation is another name for the concept of modularity applied to design. Polymorphism means "there's gonna be either an overloaded function or a function pointer, even if you don't know it". Design patterns are abstractions of what are usually good ways to do object-oriented design.

ash.gti wrote:(...) not to mention they probably don't know the first thing about functional programming other than lisp has lots of parenthesis.


Functional programming is warping your mind around how the specification should be done so that it's compiled / interpreted efficiently by a computer. It's like trying to explain a complicated thing to a stupid boy when you could do the things by yourself.

ash.gti wrote:Not to mention the lack of understanding of things like process and SQA.


The concept of process isn't hard either. But I guess I have an unfair advantage since my parents are chemical engineers (and they bothered to answer my stupid questions on what their work is). SQA is something that should be done by people who (at least as a group) can *hopefully* imagine all the possible scenarios in which the program is going to be run. That ability to imagine scenarios can't be developed if you haven't done any programming, especially low-level programming.

Xanthir wrote:The problem is that your apparent bar for what's "critical" is far lower than it should reasonably be. As a result of this you appear to reject functional languages outright, simply because they can produce code less efficient than what a skilled programmer can do in a lower-level language.


Unlike most people, I don't want my laptop to be a netbook. I want a powerful computer that happens to be portable. I want to squeeze better performance than that of gaming machines from ordinary hardware.

Xanthir wrote:You appear to have glommed onto this idea hard enough to uncritically accept FUD like "functional languages can't be compiled" (though hopefully that, at least, has been shown to be incorrect).


Functional languages can be compiled, but I don't have any control over what the result of the compilation process is. In particular, I don't have any control over memory management.

Xanthir wrote:(...) But I strongly disagree that this knowledge should come *first*, or that it's the most important consideration to make. You have to understand the efficiency model of your language, and understanding that requires knowledge about the efficiency models of the languages below it. It is, however, vitally important to learn *when* to care about efficiency; the correct answer is usually far less than you would think.


I've tried to explain "efficiency models" to many people and none of them have understood what the ... I was talking about until I explained the low-level detail of what makes things efficient. Perhaps that means there is something fundamentally wrong with the people I hang with.

Besides, there are a couple of languages whose actual implementation make me wonder if it's so true that efficiency almost never matters.

Philwelch wrote:In fact, the particular shape Moore's Law is now taking almost dictates a focus on functional programming. Now that multicore is the norm, functional programming will become more and more important since there's no other easy way to take advantage of concurrency.


I never thought threats and locks were so hard.
Gott weiß ich will kein Engel sein!
EduardoLeon
 
Posts: 111
Joined: Wed Sep 30, 2009 2:26 am UTC
Location: Lima, Perú

Re: Best language for n00bs

Postby Xanthir » Mon Oct 05, 2009 4:30 pm UTC

EduardoLeon wrote:
ash.gti wrote:Then why is it that most computer scientists that return to school are doing so because they can't get a hold of newer things like OO design? I am talking about the ones that spent like 30 years doing COBOL or fortran or assembly professionally.


COBOL, FORTRAN and assembly don't encourage modularity, encapsulation and those things that are needed when a large system is being developed. But that doesn't mean that you can't write modular programs in those languages. If, after toying with any programming language, especially a low level one, you haven't found how important it's to divide big problems in smaller parts and, thus, big programming projects into several subprograms as least interrelated as possible, then you haven't been born for programming, engineering or any other discipline that requires structured thinking.

Most programmers aren't born for programming, to be honest. We still have to work with them.

ash.gti wrote:According to my last college professor, most of the returning students that were from the old crowd or getting a masters later in life that had started and worked primarily with those low level things never got the hang of OO design and came back to school to re-learn them, (...)


Object-oriented design has never struck me as something oh-so-difficult like, say, thermodynamics or quantum mechanics. The concepts of "class", "object", "message", "inheritance", "encapsulation", "polymorphism", "object-oriented design pattern" etc. are rather straightforward. Inheritance means "don't implement the damn thing twice". Encapsulation is another name for the concept of modularity applied to design. Polymorphism means "there's gonna be either an overloaded function or a function pointer, even if you don't know it". Design patterns are abstractions of what are usually good ways to do object-oriented design.

No, design patterns are hacks over a fault in the language. If you find yourself looking at a design pattern, patch your language until it disappears. (Hopefully you're using a language that you can patch yourself, rather than having to beg the maintainers to patch.)

ash.gti wrote:(...) not to mention they probably don't know the first thing about functional programming other than lisp has lots of parenthesis.


Functional programming is warping your mind around how the specification should be done so that it's compiled / interpreted efficiently by a computer. It's like trying to explain a complicated thing to a stupid boy when you could do the things by yourself.

Yes, we know that you don't understand functional programming. That's okay. It doesn't make functional programming bad, though.

Here's the thing: in general, the compiler is smarter than you. You don't try to challenge your calculator on mental arithmetic, because your calculator is much smarter than you on that subject. Similarly, compilers are very smart about optimizing high-level code into efficient low-level code. The absolute *best* programmers (and I mean the absolute geniuses that you can count on one hand in the entire world) can sometimes do better than a good compiler, but only sometimes. The rest of us don't have a hope in hell of doing better than the compiler. It can hold ridiculously large amounts of detail in its mind at once when figuring out how to order instructions, and it has the ability to pattern-match across datasets that we can't dream of (like the project for gcc, I think, that's enumerating all possible orderings of small sets of instructions to find the most efficient one for a given processor).

Using higher-level concepts gives the compiler *much* more latitude in how it can rearrange things for maximum efficiency. Every decision you make "for efficiency" is you trying to second-guess a machine intelligence vastly smarter than you on this particular subject. Make damned sure that you're right before doing so.

Xanthir wrote:The problem is that your apparent bar for what's "critical" is far lower than it should reasonably be. As a result of this you appear to reject functional languages outright, simply because they can produce code less efficient than what a skilled programmer can do in a lower-level language.


Unlike most people, I don't want my laptop to be a netbook. I want a powerful computer that happens to be portable. I want to squeeze better performance than that of gaming machines from ordinary hardware.

Here's the funny thing - very little corporate software written today is done in a functional language. If you're complaining about bloatware, you can pretty much point to Java, C++, and C# as the culprits, as they're the languages behind the majority of consumer applications.

The efficiency problem has little to nothing to do with the language you're using. Programs become bloatware because the programmers writing them aren't good enough. Perhaps if they were using proper languages that hid more from them, so the compiler could optimize things itself rather than programmer trying (and badly failing) to hand-optimize things that don't need to be optimized because they've been taught that they should be "efficient".

Xanthir wrote:You appear to have glommed onto this idea hard enough to uncritically accept FUD like "functional languages can't be compiled" (though hopefully that, at least, has been shown to be incorrect).


Functional languages can be compiled, but I don't have any control over what the result of the compilation process is. In particular, I don't have any control over memory management.

And that's a good thing. You very rarely have any need to control memory management. That sort of low-level control means that mistakes cause memory leaks, which are *much* less prevalent these days now that most programmers use languages with automatic GC. In a memory-managed language you don't have to worry about that; the worst thing that can happen is that you cons up a lot of memory that then gets thrown away and collected. That's the sort of thing that profilers are built to tell you about, though, and you can then focus your efforts on reducing consing in that one spot (in Lisp, you can often just switch to destructive functions)

Xanthir wrote:(...) But I strongly disagree that this knowledge should come *first*, or that it's the most important consideration to make. You have to understand the efficiency model of your language, and understanding that requires knowledge about the efficiency models of the languages below it. It is, however, vitally important to learn *when* to care about efficiency; the correct answer is usually far less than you would think.


I've tried to explain "efficiency models" to many people and none of them have understood what the ... I was talking about until I explained the low-level detail of what makes things efficient. Perhaps that means there is something fundamentally wrong with the people I hang with.

Well, yeah, like I said, to understand a language's efficiency model you have to understand the efficiency models of the languages beneath it. If you focus on this, though, you start micro-optimizing, which more often than not actually *interferes* with the compiler's ability to *actually* optimize your code.

Besides, there are a couple of languages whose actual implementation make me wonder if it's so true that efficiency almost never matters.

I don't know what you mean here. Elaborate?

Philwelch wrote:In fact, the particular shape Moore's Law is now taking almost dictates a focus on functional programming. Now that multicore is the norm, functional programming will become more and more important since there's no other easy way to take advantage of concurrency.


I never thought threats and locks were so hard.

They are hard. They are so difficult in fact that one of the overriding concerns about many of the new client storage solutions in browsers (introduced in HTML5) is how to implement concurrency/multithreading without so much as *mentioning* locks to the programmer. Mutexes are a massive lose in practice, as has been shown pretty much every time they've been used. The average programmer *cannot* handle mutexes beyond trivial examples without creating deadlocks or still allowing races. The only excuse for using mutexes is when you're programming at a low enough level that they're the only concurrency primitive you can use.
(defun fibs (n &optional (a 1) (b 1)) (take n (unfold '+ a b)))
User avatar
Xanthir
My HERO!!!
 
Posts: 4336
Joined: Tue Feb 20, 2007 12:49 am UTC
Location: The Googleplex

Re: Best language for n00bs

Postby EduardoLeon » Mon Oct 05, 2009 5:08 pm UTC

Xanthir wrote:Yes, we know that you don't understand functional programming. That's okay. It doesn't make functional programming bad, though.


Functional programming means that everything is a function application. A function that doesn't affect the "state" of the program, because there's not such a thing as "state" in first place. However, since state is a very real thing, it must be simulated when you do functional programming. And, since not any there's not any decent alternative, state must be expressed as a function parameter. And, since you can't fill the stack so much (yes, parameters fill the call stack!!!), you have to resort to contrived things such as tail call optimization, because the compiler can simply replace the old parameter values with the new ones and goto the first instruction of what the function becomes when it's compiled.

But I guess that transforming a general recursive program into a general iterative program is an undecidable task. (I don't know, really.) Only if it's a decidable task and it can be done in a reasonable time, then functional programming might be worth a try. I mean, functional programming using a computer.

And, before you say I don't understand functional programming, I always define the transformations in my programs as functions using recursion (mainly because iteration would make my head asplode). And, yes, I express those transformations in a stateless way. Then, I manually transform the recursive definition into an iterative sequence of instructions that evaluates the function. (Of course, I don't take this approach when doing GUI stuff. But I seldom do GUI stuff.)

Xanthir wrote:Here's the funny thing - very little corporate software written today is done in a functional language. If you're complaining about bloatware, you can pretty much point to Java, C++, and C# as the culprits, as they're the languages behind the majority of consumer applications.


I've never advocated the use of Java or C#. In fact, those are examples not to follow in my book. C++ has some good ideas like emphasizing const-correctness. For example, you can overload an operator using const references. But templates suck (I forgot this word) eggs. Every useful thing that can be done with templates, I can do with C macros. (Yes, I have even included header files recursively.)

Xanthir wrote:
EduardoLeon wrote:Besides, there are a couple of languages whose actual implementation make me wonder if it's so true that efficiency almost never matters.


I don't know what you mean here. Elaborate?


Ruby and Groovy.
Last edited by EduardoLeon on Mon Oct 05, 2009 10:27 pm UTC, edited 1 time in total.
Gott weiß ich will kein Engel sein!
EduardoLeon
 
Posts: 111
Joined: Wed Sep 30, 2009 2:26 am UTC
Location: Lima, Perú

Re: Best language for n00bs

Postby Xanthir » Mon Oct 05, 2009 6:29 pm UTC

EduardoLeon wrote:But I guess that transforming a general recursive program into a general iterative program is an undecidable task. (I don't know, really.) Only if it's a decidable task and it can be done in a reasonable time, then functional programming might be worth a try. I mean, functional programming using a computer.

Yes, so your bar for efficiency is unreasonably high. I mean, who writes general recursive programs? Good compilers can recognize and unfold many recursive patterns automatically.

And, before you say I don't understand functional programming, I always define the transformations in my programs as functions using recursion (mainly because iteration would make my head asplode). And, yes, I express those transformations in a stateless way. Then, I manually transform the recursive definition into an iterative sequence of instructions that evaluates the function. (Of course, I don't take this approach when doing GUI stuff. But I seldom do GUI stuff.)

No, you really don't seem to understand functional programming. Recursion is a very small part of it. Why recurse when you can map or fold, for instance? (And map and fold can be *very* trivially unrolled into iterative constructs by the dumbest of compilers.) Recursion is identical to iteration - it's something you use when your language doesn't provide sufficiently powerful primitives. Of course you have to pay attention to what you're doing when you recurse, because it's still a fairly low-level operation.

Functional programming is about treating functions as first-class objects that can be passed around and manipulated by the program, created in one place and given to another function to be evaluated elsewhere. It's about making the *structure* of your program into yet another thing that can be coded, manipulated, and hidden away.

As well, this runs straight into the maintenance issues I keep harping on. If the recursive definition is easier to understand, do you keep it around in the comments? When you need to make a bugfix, do you change the recursive definition and then regenerate the iterative one? If so, you're wasting your time and can hand that job to the compiler. If you don't, then I sure am glad you're a supergenius who writes bug-free code, or else being a maintenance programmer on one of your projects would be a *nightmare*.

Xanthir wrote:Here's the funny thing - very little corporate software written today is done in a functional language. If you're complaining about bloatware, you can pretty much point to Java, C++, and C# as the culprits, as they're the languages behind the majority of consumer applications.


I've never advocated the use of Java or C#. In fact, those are examples not to follow in my book. C++ has some good ideas like emphasizing const-correctness. For example, you can overload an operator using const references. But templates eggs. Every useful thing that can be done with templates, I can do with C macros. (Yes, I have even included header files recursively.)

I don't care what you can do with C++. The point is that you used "I don't want my programs to be bloatware" as the reason for disdaining functional languages. Bloat is not related to languages in that manner, though. It's tied much more strongly to programmer skill; most programmers are *not* highly skilled, just as most practitioners of *any* discipline are not highly skilled. Basic Sturgeon's Law. Thus it's ideal to make the language/compiler do as much of the heavy lifting as possible so efficiency becomes automatic, rather than something that must be manually tracked and inserted by the programmer. At some point you *do* have to mess with it yourself, but that is far down the line, rather than an upfront concern. Just make sure your language gives you hooks into low-level stuff for when you absolutely, positively need it. (Lisp, frex, allows inline assembly.)

Edit: It also of course has the magic of its macro system, which is so far beyond C's text-based macros that it's an insult to use the same word for them. Lisp macros let you use high-level constructs which are then automagically transformed *using human reasoning* into more performant, but more complex, code.
(defun fibs (n &optional (a 1) (b 1)) (take n (unfold '+ a b)))
User avatar
Xanthir
My HERO!!!
 
Posts: 4336
Joined: Tue Feb 20, 2007 12:49 am UTC
Location: The Googleplex

Re: Best language for n00bs

Postby Berengal » Mon Oct 05, 2009 7:01 pm UTC

First a little tangent. I love Haskell's concurrency system. Well, basically it has three of them. The first is the only one where you explicitly fork off threads, usually called simply "concurrency". Because of purity the only way you can fuck up another thread is if you explicitly hand it a mutable reference you're modifying without locking. You can safely hand it a pure value, because that can't be modified anyway; the worst that can happen is that two threads evaluate it at the same time (there's a 1-instruction window where that can happen), but even then the only consequence is doing the same work twice, as both threads will replace the thunk with the same data.
Then there's MVars, which used to be the only concurrency primitive before STM. MVars are nifty, because they're like locks with values. They're either empty or full, and there's blocking and non-blocking operations (the non-blocking operations don't circumvent the lock, they just do nothing, and tells you so, where the blocking operations would've failed). It's still possible to deadlock, and it's best not to share MVars between too many threads, or things could get compliated.
The last addition to haskell concurrency is called STM, which is short for Software Transactional Memory. The basic premise is that you've got TVars (which are like MVars, except they're never empty), a few operations on them (read and write, basically), a few operations on those operations (orElse), and finally a stand-alone operation called retry. These operations are all monadic, so they can be sequenced and contain pure values. Now, every STM operation guarantees that either all reads and writes complete without interference from another thread, or none of them do. When composed, this guarantee carries through to the entire resulting operation, making for easily composable atomic operations. For example, it's not hard to imagine a TMVar (in fact, such a thing already exists. It's simply a TVar (Maybe a)). Just like MVars, these can be used for locks. What you can't do with regular MVars, however, is take several locks at once without caring about which order you take them in, or releasing them in the correct order if you failed to take them all. Neither can you arbitrarily compose two lock-taking operations without caring for exactly what they're doing.

The second concurrency system in haskell is called "parallellism". The difference between it and concurrency is that a concurrent program does several things at the same point in time, like handling keyboard events while drawing things on the screen. A parallell program does one thing, but uses several threads to do it; they all pull together in the same direction towards a common goal. The nice thing about parallellism is that it's not important which thread does what and in what sequence. Therefore, instead of spawning threads, you instead annotate your code in places where parallell execution might be a good idea. "Here I need to know the values of both x and y, and they both take some time to compute, so it might be a good idea to compute y in parallell while I do x, and then later we can add them together." The runtime has a collection of these sparks, and whenever a worker thread is free it picks up one of these sparks and evaluates it. If the main thread requires a sparked but unevaluated value, it'll just evaluate the spark itself like it normally would in a non-parallell program.
Parallellism removes the need to worry about threads and locks or any other concurrency mechanizm. Instead, they'll only have to worry about which values would be a good idea to evaluate in parallell and making sure things don't get too fine-grained, or the usually small overhead will grow larger than the gains you get from evaluating multiple things at once.
Parallellism is also somewhat limited in that it can only evaluate pure values that have no side-effects. Anything else would be madness, as you want control of the sequencing of side-effectful code. One of the great things about parallellism is that a working program will never break if you add parallellism to it; it can only become slower, but will always return the same result.

The last concurrency system is in my opinion even niftier: Nested data parallellism. Data parallellism already exists; some FORTRAN dialects have it, and possibly others too. The idea here is that it's possible for a compiler to look at a sequential algorithm and automatically derive parallellism in such a way that all threads are at maximum utilization at all times, including concerns such as cache-performance, locality and whatnot. Typically this has been restricted to single-level loops over arrays using a restricted subset of operations usually available, and writing those algorithms has usually been hard.
Then some guys threw a bunch of maths together and developed nested data-parallellism, which is a way of converting nested loops into a flat one, combining and transforming the operations along the way. This makes writing parallell algorithms almost as easy as writing sequential ones, and they'll most likely perform a lot better than any hand-tuned assembly will. It also helps that Haskell's restricted subset of operations is the entire set of pure functions (as long as they're correctly types. There's currently restrictions on the type of the vector elements); because purity is what's needed to convert those sequential algorithms implicitly into parallell ones, and there's no way to prove something's pure in FORTRAN, developers are stuck with whatever's there already, unable to write their own abstractions. In Haskell, proving purity is simple, and you can do pretty much whatever you want.
GHC got some alpha-stage experimental support for this in its 6.10 release. Last I heard, it was a crapload harder to implement than they'd first imagined, but they were starting to get on top of things, so while 6.12 still won't have full support it's quite possible 6.14 or 6.16 will.


Now then, back to flaming.

EduardoLeon wrote:However, since state is a very real thing, it must be simulated when you do functional programming.

Not very zen of you. If you can simulate state, you have state.

EduardoLeon wrote:And, since not any there's not any decent alternative, state must be expressed as a function parameter. And, since you can't fill the stack so much (yes, parameters fill the call stack!!!)

Where do you think your loop varaible's located? If you say "in a register" I'll retort by saying that's where functional programs put their parameters.

EduardoLeon wrote:you have to resort to contrived things such as tail call optimization

I like to call that tail call pesimization. Tail call optimization is doing just what you'd do yourself in assembly anyway: Instead of calling another function only to return as soon as it returned to you, you simply jump to it, letting it return to your caller instead of you. This goes for all functions, not just self-recursive ones, and if people have gotten used to otherwise it's only because compiler-writers are lazy slobs.

EduardoLeon wrote:But I guess that transforming a general recursive program into a general iterative program is an undecidable task. (I don't know, really.) Only if it's a decidable task and it can be done in a reasonable time, then functional programming might be worth a try. I mean, functional programming using a computer.

As Xanthir said, every recursive program can be transformed into an equivalent iterative one. How else did you think compilers for functional programs even work? Some recursive algorithms require a stack when transformed into iterative ones; the compiler usually uses the one that's already there. You know, the call stack... I'd do the same if I were hand-coding this in assembly, instead of bothering about allocating a new stack somewhere else.

EduardoLeon wrote:I manually transform the recursive definition into an iterative sequence of instructions that evaluates the function.
That's pretty dumb when any decent compiler would do the exact same thing for you if you enable optimizations.
It is practically impossible to teach good programming to students who are motivated by money: As potential programmers they are mentally mutilated beyond hope of regeneration.
User avatar
Berengal
Superabacus Mystic of the First Rank
 
Posts: 2707
Joined: Thu May 24, 2007 5:51 am UTC
Location: Bergen, Norway

Re: Best language for n00bs

Postby Philwelch » Mon Oct 05, 2009 7:06 pm UTC

EduardoLeon wrote:And, before you say I don't understand functional programming, I always define the transformations in my programs as functions using recursion (mainly because iteration would make my head asplode). And, yes, I express those transformations in a stateless way. Then, I manually transform the recursive definition into an iterative sequence of instructions that evaluates the function.


So the issue is...you're not convinced that compilers work for functional programming?

EduardoLeon wrote:
Xanthir wrote:
EduardoLeon wrote:Besides, there are a couple of languages whose actual implementation make me wonder if it's so true that efficiency almost never matters.


I don't know what you mean here. Elaborate?


Ruby and Groovy.


Yes, MRI is a poor interpreter, which is why YARV/KRI is the primary implementation for Ruby 1.9. The thing is, it's easier to design a good language (e.g. Ruby) and then, later, write an optimized interpreter for it. What's hard is designing a fast, optimized interpreter and then trying to build a good language out of that quick-and-dirty tool. That way lies Perl. (And another religious war.)
Fascism: If you're not with us you're against us.
Leftism: If you're not part of the solution you're part of the problem.

Perfection is an unattainable goal.
Philwelch
 
Posts: 2904
Joined: Tue Feb 19, 2008 5:33 am UTC
Location: RIGHT BEHIND YOU

Re: Best language for n00bs

Postby ash.gti » Mon Oct 05, 2009 9:06 pm UTC

I am still not convinced that a complete programming noob should start so low as assembly or C.

I know understanding whats going on under the hood of haskell, or python or lisp, or perl or whatever is really important, but its not *required* that you learn it first to understand what all is involved with programming. I am talking "Okay class, this is programming 101, today lets go over what a variable is" type of programming, not what you'd do or need for everyday use as a professional programmer.

Having a language like python that can hold your hand while you discover the magic of loops to calculate some physics problem in 10 seconds that would of taken you a page and a half to do on paper is pretty amazing. Thats the kind of thing most people learn when they start programming.

Once you know a language and have a grasp for the basic things like IO, file management, what a process is, etc. Then sure you really should drop down to a lower level to know when things are being allocated, why does this operation take so long, whats in memory? What is a pointer? What is pass-by-value vs pass-by-reference? How/Where/When do you allocated memory on the heap? Why is there a heap? Whats the stack useful for, etc. But I see no reason that needs to be taught first, other than you might want to discourage people from programming, which I don't agree with.

No, not everyone is a assembly expert, but not everyone needs to be, and if we all were then thats great, but there is a time and place for all the tools we have, a complete noob doesn't need to know that since his 32 bit integer is signed that the first bit is the positive or negative value indicator. He simply needs to know that it can hold a value from -2,147,483,648 to +2,147,483,647.
# drinks WAY to much espresso
User avatar
ash.gti
 
Posts: 404
Joined: Thu Feb 07, 2008 1:18 am UTC
Location: Probably a coffee shop.

Re: Best language for n00bs

Postby Philwelch » Mon Oct 05, 2009 10:06 pm UTC

It really depends on what you're trailing a programmer to do. If you're cross-training a scientist to program, then yeah, no reason to worry about low level stuff. If you're training a professional software developer, then hell yes, make him write everything between assembly and Lisp, and then make him write a basic Lisp in assembly (or C).
Fascism: If you're not with us you're against us.
Leftism: If you're not part of the solution you're part of the problem.

Perfection is an unattainable goal.
Philwelch
 
Posts: 2904
Joined: Tue Feb 19, 2008 5:33 am UTC
Location: RIGHT BEHIND YOU

Re: Best language for n00bs

Postby EduardoLeon » Mon Oct 05, 2009 10:10 pm UTC

Xanthir wrote:
EduardoLeon wrote:But I guess that transforming a general recursive program into a general iterative program is an undecidable task. (I don't know, really.) Only if it's a decidable task and it can be done in a reasonable time, then functional programming might be worth a try. I mean, functional programming using a computer.


Yes, so your bar for efficiency is unreasonably high. I mean, who writes general recursive programs? Good compilers can recognize and unfold many recursive patterns automatically.


Really? Then why are well-written C programs still more efficient?

Xanthir wrote:
EduardoLeon wrote:And, before you say I don't understand functional programming, I always define the transformations in my programs as functions using recursion (mainly because iteration would make my head asplode). And, yes, I express those transformations in a stateless way. Then, I manually transform the recursive definition into an iterative sequence of instructions that evaluates the function. (Of course, I don't take this approach when doing GUI stuff. But I seldom do GUI stuff.)


No, you really don't seem to understand functional programming. Recursion is a very small part of it. (...)

Functional programming is about treating functions as first-class objects that can be passed around and manipulated by the program, created in one place and given to another function to be evaluated elsewhere. It's about making the *structure* of your program into yet another thing that can be coded, manipulated, and hidden away.


Functions as first-class objects means that, in the actual implementation, you either inline functions or use function pointers. I treat functions as first-class objects as well when I use macros and, duh, function pointers. [sarcasm] Unless I have the processor I was dreaming of for so long, which treats functions as first-class objects natively. [/sarcasm]

And, of course, back in the days when self-modifying code was allowed, the structure (or lack thereof) of my program was something that could be coded, manipulated and hidden away.

Xanthir wrote:As well, this runs straight into the maintenance issues I keep harping on. If the recursive definition is easier to understand, do you keep it around in the comments? When you need to make a bugfix, do you change the recursive definition and then regenerate the iterative one? If so, you're wasting your time and can hand that job to the compiler. If you don't, then I sure am glad you're a supergenius who writes bug-free code, or else being a maintenance programmer on one of your projects would be a *nightmare*.


I always comment everything. I even comment how I derived the program, if it isn't obvious, that is, almost always. And I waste my time, if you want to call regenerating the iterative definition so.
Last edited by EduardoLeon on Mon Oct 05, 2009 10:24 pm UTC, edited 1 time in total.
Gott weiß ich will kein Engel sein!
EduardoLeon
 
Posts: 111
Joined: Wed Sep 30, 2009 2:26 am UTC
Location: Lima, Perú

Re: Best language for n00bs

Postby EduardoLeon » Mon Oct 05, 2009 10:22 pm UTC

Berengal wrote:
EduardoLeon wrote:But I guess that transforming a general recursive program into a general iterative program is an undecidable task. (I don't know, really.) Only if it's a decidable task and it can be done in a reasonable time, then functional programming might be worth a try. I mean, functional programming using a computer.


As Xanthir said, every recursive program can be transformed into an equivalent iterative one. How else did you think compilers for functional programs even work? Some recursive algorithms require a stack when transformed into iterative ones; the compiler usually uses the one that's already there. You know, the call stack... I'd do the same if I were hand-coding this in assembly, instead of bothering about allocating a new stack somewhere else.


The call stack is small. The heap is big.

Sometimes I need a call queue, a call tree, even a call graph, even if just to show off by making incomprehensible programs. Of course, this can be faked with coroutines, but call data-structures are way more elegant. That I can do only with assembly.

Berengal wrote:
EduardoLeon wrote:I manually transform the recursive definition into an iterative sequence of instructions that evaluates the function.


That's pretty dumb when any decent compiler would do the exact same thing for you if you enable optimizations.


You can't guarantee that the compiler will generate the best instruction sequence.
Last edited by EduardoLeon on Mon Oct 05, 2009 10:30 pm UTC, edited 1 time in total.
Gott weiß ich will kein Engel sein!
EduardoLeon
 
Posts: 111
Joined: Wed Sep 30, 2009 2:26 am UTC
Location: Lima, Perú

Re: Best language for n00bs

Postby Philwelch » Mon Oct 05, 2009 10:28 pm UTC

EduardoLeon wrote:
Berengal wrote:
EduardoLeon wrote:I manually transform the recursive definition into an iterative sequence of instructions that evaluates the function.


That's pretty dumb when any decent compiler would do the exact same thing for you if you enable optimizations.


You can't guarantee that the compiler will generate the best instruction sequence.


You can't guarantee that you will, either.
Fascism: If you're not with us you're against us.
Leftism: If you're not part of the solution you're part of the problem.

Perfection is an unattainable goal.
Philwelch
 
Posts: 2904
Joined: Tue Feb 19, 2008 5:33 am UTC
Location: RIGHT BEHIND YOU

Re: Best language for n00bs

Postby Xanthir » Mon Oct 05, 2009 10:39 pm UTC

EduardoLeon wrote:
Xanthir wrote:
EduardoLeon wrote:But I guess that transforming a general recursive program into a general iterative program is an undecidable task. (I don't know, really.) Only if it's a decidable task and it can be done in a reasonable time, then functional programming might be worth a try. I mean, functional programming using a computer.


Yes, so your bar for efficiency is unreasonably high. I mean, who writes general recursive programs? Good compilers can recognize and unfold many recursive patterns automatically.


Really? Then why are well-written C programs still more efficient?

They're not. Toy programs written by a skilled C hacker can sometimes be more efficient, but even then a compiler like GHC can perform some *scary* optimizations that produce near-identical assembly.

The skill required of a hacker to maintain that sort of efficiency rises super-linearly with the length of the program. At some point you're inevitably performing an 'optimization' that really isn't without realizing it.

As well, let me mention again maintainability. A program that can never be modified is more useless than a program that runs too slow. The latter can be improved, the former can only be rewritten.

Xanthir wrote:
EduardoLeon wrote:And, before you say I don't understand functional programming, I always define the transformations in my programs as functions using recursion (mainly because iteration would make my head asplode). And, yes, I express those transformations in a stateless way. Then, I manually transform the recursive definition into an iterative sequence of instructions that evaluates the function. (Of course, I don't take this approach when doing GUI stuff. But I seldom do GUI stuff.)


No, you really don't seem to understand functional programming. Recursion is a very small part of it. (...)

Functional programming is about treating functions as first-class objects that can be passed around and manipulated by the program, created in one place and given to another function to be evaluated elsewhere. It's about making the *structure* of your program into yet another thing that can be coded, manipulated, and hidden away.


Functions as first-class objects means that, in the actual implementation, you either inline functions or use function pointers. I treat functions as first-class objects as well when I use macros and, duh, function pointers. [sarcasm] Unless I have the processor I was dreaming of for so long, which treats functions as first-class objects natively. [/sarcasm]

If you are actually doing so, then you're just hacking a functional language into C using text-substitution, and without a smart compiler able to take that higher-level knowledge and optimize based on it. No wonder you don't think functional programming is that useful - you're doing it wrong. (Well, actually, you're falling victim to Greenspun's Tenth Rule.)

And, of course, back in the days when self-modifying code was allowed, the structure (or lack thereof) of my program was something that could be coded, manipulated and hidden away.

Self-modifying code was the devil, and we shall never speak of it. It doesn't allow optimizations of the correct kind, or even *compilation*, really.

Xanthir wrote:As well, this runs straight into the maintenance issues I keep harping on. If the recursive definition is easier to understand, do you keep it around in the comments? When you need to make a bugfix, do you change the recursive definition and then regenerate the iterative one? If so, you're wasting your time and can hand that job to the compiler. If you don't, then I sure am glad you're a supergenius who writes bug-free code, or else being a maintenance programmer on one of your projects would be a *nightmare*.


I always comment everything. I even comment how I derived the program, if it isn't obvious, that is, almost always. And I waste my time, if you want to call regenerating the iterative definition so.

That's too much commenting. There are only two types of comments - those describing something obvious, which can be dumped, and those describing a hack in the code, which should be dumped after rewriting the code.

And yes, that is *definitely* wasting your time.
(defun fibs (n &optional (a 1) (b 1)) (take n (unfold '+ a b)))
User avatar
Xanthir
My HERO!!!
 
Posts: 4336
Joined: Tue Feb 20, 2007 12:49 am UTC
Location: The Googleplex

Re: Best language for n00bs

Postby qbg » Mon Oct 05, 2009 10:42 pm UTC

1) The Reduceron is awesome.
2) Every call is a tail call.
qbg
 
Posts: 586
Joined: Tue Dec 18, 2007 3:37 pm UTC

Re: Best language for n00bs

Postby Xanthir » Mon Oct 05, 2009 10:48 pm UTC

Xanthir wrote:They're not. Toy programs written by a skilled C hacker can sometimes be more efficient, but even then a compiler like GHC can perform some *scary* optimizations that produce near-identical assembly.

For example, take these two posts:
http://donsbot.wordpress.com/2008/05/06 ... recursion/
http://donsbot.wordpress.com/2008/06/04 ... rformance/

The first shows how a failure in Haskell's optimizations (due to it being a lazy language, nothing to do with it being functional) can be trivially worked around by understand Haskell's efficiency model to produce code equally as fast as a tight C implementation. The benefit, of course, is that you get to use Haskell for things *other* than the tight inner loops, while the C program has to be C the whole way through.

The second shows how rewriting the offending function (mean) to use high-level primitives could potentially solve the problem automatically, but due to a limitation in the current GHC compiler it doesn't work. It then shows how you can augment the compiler (easy to do in GHC) to recognize a much larger class of optimizations, including the relevant one, allowing you to code in *pure* high-level primitives but still generate tight assembly identical to the skilled C code.
(defun fibs (n &optional (a 1) (b 1)) (take n (unfold '+ a b)))
User avatar
Xanthir
My HERO!!!
 
Posts: 4336
Joined: Tue Feb 20, 2007 12:49 am UTC
Location: The Googleplex

Re: Best language for n00bs

Postby Philwelch » Mon Oct 05, 2009 11:10 pm UTC

Guys, I think we're missing a big point here.

EduardoLeon claims that he, a human being, is a more efficient compiler of functional languages than an actual compiler of functional languages. Clearly, he should do one of the following two things:

1. Document his compilation process and then use that documentation to write a compiler--in assembly, of course--so the rest of us can write optimized functional programs, too.
2. If (1) is too difficult, EduardoLeon probably doesn't need to even write programs himself. He would be way more valuable actually working as a human compiler. Other programmers can write Haskell or whatnot, and EduardoLeon can read their code and compile it for them. After all, that's what he says he does with his own programs. If it's really worthwhile for him to hand-compile his functional programs, then obviously he would be able to compete in the marketplace against compilers to make a living.
Fascism: If you're not with us you're against us.
Leftism: If you're not part of the solution you're part of the problem.

Perfection is an unattainable goal.
Philwelch
 
Posts: 2904
Joined: Tue Feb 19, 2008 5:33 am UTC
Location: RIGHT BEHIND YOU

Re: Best language for n00bs

Postby stephentyrone » Mon Oct 05, 2009 11:33 pm UTC

Philwelch wrote:If it's really worthwhile for him to hand-compile his functional programs, then obviously he would be able to compete in the marketplace against compilers to make a living.


That's basically what I do. Turns out it pays quite well.

So while I think that the forces of functional programming are generally in the right in this discussion, I'm not sure that this particular line of attack will get you anywhere.
GENERATION -16 + 31i: The first time you see this, copy it into your sig on any forum. Square it, and then add i to the generation.
stephentyrone
 
Posts: 779
Joined: Mon Aug 11, 2008 10:58 pm UTC
Location: Palo Alto, CA

Re: Best language for n00bs

Postby Philwelch » Mon Oct 05, 2009 11:46 pm UTC

stephentyrone wrote:
Philwelch wrote:If it's really worthwhile for him to hand-compile his functional programs, then obviously he would be able to compete in the marketplace against compilers to make a living.


That's basically what I do. Turns out it pays quite well.


About how many software projects do you think would justify employing someone of your skills, though?
Fascism: If you're not with us you're against us.
Leftism: If you're not part of the solution you're part of the problem.

Perfection is an unattainable goal.
Philwelch
 
Posts: 2904
Joined: Tue Feb 19, 2008 5:33 am UTC
Location: RIGHT BEHIND YOU

Re: Best language for n00bs

Postby EduardoLeon » Tue Oct 06, 2009 12:01 am UTC

Xanthir wrote:If you are actually doing so, then you're just hacking a functional language into C using text-substitution, and without a smart compiler able to take that higher-level knowledge and optimize based on it. No wonder you don't think functional programming is that useful - you're doing it wrong. (Well, actually, you're falling victim to Greenspun's Tenth Rule.)


[sarcasm] How come I am doing functional programming wrong? I'm doing imperative programming! What I do before writing the code is mathematics. Oh, wait, functional programming is mathematics. [/sarcasm] Now, seriously, what do you mean when you say I am doing functional programming wrong? And what is Greenspun's Tenth Rule? Excuse me for my ignorance.

Xanthir wrote:Self-modifying code was the devil, and we shall never speak of it. It doesn't allow optimizations of the correct kind, or even *compilation*, really.


Why so dogmatic?

Xanthir wrote:That's too much commenting. There are only two types of comments - those describing something obvious, which can be dumped, and those describing a hack in the code, which should be dumped after rewriting the code.


There should be no hacks in the code, in first place.

Xanthir wrote:The first shows how a failure in Haskell's optimizations (due to it being a lazy language, nothing to do with it being functional) can be trivially worked around by understand Haskell's efficiency model to produce code equally as fast as a tight C implementation. The benefit, of course, is that you get to use Haskell for things *other* than the tight inner loops, while the C program has to be C the whole way through.


Of course, and the benefit of using C is that I get to use C for other things than the tight inner loops as well.
Gott weiß ich will kein Engel sein!
EduardoLeon
 
Posts: 111
Joined: Wed Sep 30, 2009 2:26 am UTC
Location: Lima, Perú

Re: Best language for n00bs

Postby ash.gti » Tue Oct 06, 2009 12:05 am UTC

I like this tangent but shouldn't it go elsewhere?

Also, there is still little to no evidence supporting the idea that you should start at assembly. Why? It's not something you'd have to do on a regular basis for most programming jobs. Its something you should know and understand, but why should it come first? EduardoLeon's main reason has been:
EduardoLeon wrote: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.


But what about java or .net or a dynamic language makes you 'stupid'? Why do those skills need to come first?

Easing someone into programming seems like a better idea to me. You don't go up to a first grade and say "Here is 1 + 1, now integrate this sine wave from a to infinity". There are some fundamental programming concepts that are much easier to teach and learn in higher level languages. The low level stuff is awesome, useful, and needed but it shouldn't come first. You crawl before you walk.
# drinks WAY to much espresso
User avatar
ash.gti
 
Posts: 404
Joined: Thu Feb 07, 2008 1:18 am UTC
Location: Probably a coffee shop.

Re: Best language for n00bs

Postby EduardoLeon » Tue Oct 06, 2009 12:24 am UTC

ash.gti wrote:But what about java or .net or a dynamic language makes you 'stupid'? Why do those skills need to come first?


Most Java and .NET programmers I know can't understand anything low-level. Their brains have been damaged forever.

ash.gti wrote:The low level stuff is awesome, useful, and needed but it shouldn't come first. You crawl before you walk.


You learn to crawl when you think in terms of the most basic operations the computer can do. You walk when you use complex functionality packed in a class or module.
Gott weiß ich will kein Engel sein!
EduardoLeon
 
Posts: 111
Joined: Wed Sep 30, 2009 2:26 am UTC
Location: Lima, Perú

Re: Best language for n00bs

Postby EduardoLeon » Tue Oct 06, 2009 12:28 am UTC

A little off-topic:

stephentyrone wrote:So while I think that the forces of functional programming are generally in the right in this discussion, I'm not sure that this particular line of attack will get you anywhere.


I laughed really hard at the phrase "the forces of functional programming".
Gott weiß ich will kein Engel sein!
EduardoLeon
 
Posts: 111
Joined: Wed Sep 30, 2009 2:26 am UTC
Location: Lima, Perú

Re: Best language for n00bs

Postby EduardoLeon » Tue Oct 06, 2009 12:42 am UTC

Philwelch wrote:Guys, I think we're missing a big point here.

EduardoLeon claims that he, a human being, is a more efficient compiler of functional languages than an actual compiler of functional languages. Clearly, he should do one of the following two things:

1. Document his compilation process and then use that documentation to write a compiler--in assembly, of course--so the rest of us can write optimized functional programs, too.


My compilation process involves using intelligence.

Philwelch wrote:2. If (1) is too difficult, EduardoLeon probably doesn't need to even write programs himself. He would be way more valuable actually working as a human compiler. Other programmers can write Haskell or whatnot, and EduardoLeon can read their code and compile it for them. After all, that's what he says he does with his own programs. If it's really worthwhile for him to hand-compile his functional programs, then obviously he would be able to compete in the marketplace against compilers to make a living.


I hand-compile my own programs. Not others. Not even those I write for others.
Gott weiß ich will kein Engel sein!
EduardoLeon
 
Posts: 111
Joined: Wed Sep 30, 2009 2:26 am UTC
Location: Lima, Perú

Re: Best language for n00bs

Postby Philwelch » Tue Oct 06, 2009 1:00 am UTC

EduardoLeon wrote:
Philwelch wrote:2. If (1) is too difficult, EduardoLeon probably doesn't need to even write programs himself. He would be way more valuable actually working as a human compiler. Other programmers can write Haskell or whatnot, and EduardoLeon can read their code and compile it for them. After all, that's what he says he does with his own programs. If it's really worthwhile for him to hand-compile his functional programs, then obviously he would be able to compete in the marketplace against compilers to make a living.


I hand-compile my own programs. Not others. Not even those I write for others.


If you're really as good as you think you are, you're making a terrible career choice ;)

Here is the now-obligatory story of Mel.
Fascism: If you're not with us you're against us.
Leftism: If you're not part of the solution you're part of the problem.

Perfection is an unattainable goal.
Philwelch
 
Posts: 2904
Joined: Tue Feb 19, 2008 5:33 am UTC
Location: RIGHT BEHIND YOU

Re: Best language for n00bs

Postby EduardoLeon » Tue Oct 06, 2009 2:45 am UTC

Philwelch wrote:If you're really as good as you think you are, you're making a terrible career choice


I'm also very good at swallowing both my pride and my principles at work. If I weren't, I'd be fired, because I'm just a grunt.
Gott weiß ich will kein Engel sein!
EduardoLeon
 
Posts: 111
Joined: Wed Sep 30, 2009 2:26 am UTC
Location: Lima, Perú

Re: Best language for n00bs

Postby qbg » Tue Oct 06, 2009 2:46 am UTC

EduardoLeon wrote: And what is Greenspun's Tenth Rule? Excuse me for my ignorance.

"Any sufficiently complicated C or Fortran program contains an ad hoc, informally-specified, bug-ridden, slow implementation of half of Common Lisp."
qbg
 
Posts: 586
Joined: Tue Dec 18, 2007 3:37 pm UTC

Re: Best language for n00bs

Postby Emu* » Tue Oct 06, 2009 12:15 pm UTC

EduardoLeon wrote:
ash.gti wrote:But what about java or .net or a dynamic language makes you 'stupid'? Why do those skills need to come first?


Most Java and .NET programmers I know can't understand anything low-level. Their brains have been damaged forever.


Screw you.

<re-lurks>
Cosmologicon wrote:Emu* implemented a naive east-first strategy and ran it for an hour, producing results that rivaled many sophisticated strategies, visiting 614 cells. For this, Emu* is awarded Best Deterministic Algorithm!
User avatar
Emu*
 
Posts: 689
Joined: Mon Apr 28, 2008 9:47 am UTC
Location: Cardiff, UK

Re: Best language for n00bs

Postby phlip » Tue Oct 06, 2009 1:23 pm UTC

EduardoLeon wrote:
ash.gti wrote:The low level stuff is awesome, useful, and needed but it shouldn't come first. You crawl before you walk.


You learn to crawl when you think in terms of the most basic operations the computer can do. You walk when you use complex functionality packed in a class or module.

No. What? Are you crazy?

You learn to crawl when you learn how to break a task (say, "build a CLI calculator") into pieces (say, "read a command", "parse a command", "evaluate a parsed command", "output a result"). You learn to walk when you break those pieces down further into whatever primitives are available in your Language Of Choice. You learn to run when you break it all the way down to what's being run on the metal.

If you teach someone, say, Python and then ASM, then first they'll learn imperative thinking, and then they'll learn low-level details. If you teach someone ASM and then Python, then first they'll have to learn imperative thinking and low-level design at once, and then when they get to Python they'll gain little from it, which is a shame, 'cause there's a lot to be gained from abstractions, even ones that leak at the corners. At least, that's what would have to happen for the people who make it through... most would get swamped by having to learn so many new concepts at once, get completely lost, and drop out.

Sure, the top-down approach isn't the be-all and end-all, and the bottom-up approach is important too. But it doesn't have to be first. You make the analogy to maths, and how arithmetic is taught before algebra, is taught before calculus. And sure, there's a good reason for that. But there's also a good reason why most kids hate learning maths that way, and only the few who really like maths will actually follow that chain all the way to the end. And most of those had already, of their own volition, learned some advanced maths top-down before hand. I know I did. I knew, handwavily, what calculus was, before I even knew about limits, or even the high levels of algebra. Sure, it wasn't a good working knowledge, but it was enough that when we did learn limits, I knew where it was headed, so I actually had motivation to learn the fundamentals. I think maths education would benefit from formalising such an approach... teach some kind of limit-free calculus, maybe even algebra-free calculus, work directly on the graphs themselves with naive geometry or something. Get those learning interested, show them the power of it, get them thinking logically. Then, once they're thinking logically, show them where the logical holes are in the definitions, and fill in the gaps with the fundamentals. And I think programming benefits from the same approach. Learn Python. Then learn C or ASM or something. Then learn Python again, this time keeping in mind the fundamentals. Then learn Haskell or Scheme, for the change of pace.

On an unrelated note, to bring out the mod pen:
It has been suggested to me that this thread should be split, presumably into a "best language for newcomers" thread and a "best language for everything" thread. I really don't want to have to do that, trying to filter out all the posts would cause me physical pain. So instead, I will say: this thread is for "best language for newcomers" discussions. Only. If you want to argue that your on-the-job code should be written by hand-carving ones and zeros into a stone tablet, which is then transcribed into the computer by a team of blind monks, then, as ash.gti kindly pointed out, the thread to do so is over there. I would be happy to debate you on the value of Programmer Time vs Program Running Time over there. Continued discussion of that topic in here will result in severe reprimands, followed by death.
While no one overhear you quickly tell me not cow cow.
but how about watch phone?
User avatar
phlip
Restorer of Worlds
 
Posts: 7207
Joined: Sat Sep 23, 2006 3:56 am UTC
Location: Australia

Re: Best language for n00bs

Postby EduardoLeon » Tue Oct 06, 2009 2:46 pm UTC

Dear Mr. Moderator:

I agree with ash.gti you that this thread should have been about what the best language for newcomers is. I argued that it's assembler. But then came a succession of counter-arguments and counter-counter-arguments, and we all (myself included, I admit) got carried away. My sincere apologies. I won't get out of the topic again.

Sincerely yours,

Eduardo León

---

Back to the flame:

phlip wrote:Sure, the top-down approach isn't the be-all and end-all, and the bottom-up approach is important too. But it doesn't have to be first. You make the analogy to maths, and how arithmetic is taught before algebra, is taught before calculus. And sure, there's a good reason for that. But there's also a good reason why most kids hate learning maths that way, and only the few who really like maths will actually follow that chain all the way to the end. And most of those had already, of their own volition, learned some advanced maths top-down before hand. I know I did. I knew, handwavily, what calculus was, before I even knew about limits, or even the high levels of algebra. Sure, it wasn't a good working knowledge, but it was enough that when we did learn limits, I knew where it was headed, so I actually had motivation to learn the fundamentals. I think maths education would benefit from formalising such an approach... teach some kind of limit-free calculus, maybe even algebra-free calculus, work directly on the graphs themselves with naive geometry or something. Get those learning interested, show them the power of it, get them thinking logically. Then, once they're thinking logically, show them where the logical holes are in the definitions, and fill in the gaps with the fundamentals. And I think programming benefits from the same approach. Learn Python. Then learn C or ASM or something. Then learn Python again, this time keeping in mind the fundamentals. Then learn Haskell or Scheme, for the change of pace.


So your suggestion is to formalize informal learning? When I was at school, I thought the problem was that maths was not formal enough. The lack of formality leaded everybody (teachers included) to subtle traps. Besides, there are many counterintuitive facts in mathematics, and your approach wouldn't when dealing with them.
Gott weiß ich will kein Engel sein!
EduardoLeon
 
Posts: 111
Joined: Wed Sep 30, 2009 2:26 am UTC
Location: Lima, Perú

Re: Best language for n00bs

Postby Area Man » Thu Oct 08, 2009 5:57 pm UTC

Starting with assembly is more like learning to walk by studying human anatomy, then having to concentrate on every tiny twitch of every strand of muscle. It might make you a slightly better, touch more efficient walker, but it's exhausting, tedious, unnecessary and mostly effective at preventing people from ever wanting to walk.

Wobbling between hand supports may give you bad posture, but that can be fixed after you've got the general idea of how to get around.
Bisquick boxes are a dead medium.
User avatar
Area Man
 
Posts: 256
Joined: Thu Dec 25, 2008 8:08 pm UTC
Location: Local

Re: Best language for n00bs

Postby EduardoLeon » Thu Oct 08, 2009 8:37 pm UTC

Area Man wrote:Starting with assembly is more like learning to walk by studying human anatomy, then having to concentrate on every tiny twitch of every strand of muscle. It might make you a slightly better, touch more efficient walker, but it's exhausting, tedious, unnecessary and mostly effective at preventing people from ever wanting to walk.


Preventing people too idiot to ever program properly from programming is actually one of the goals of my approach to teaching/learning how to program. If some people who could have become programmers give up because they don't like the method, well, that's a small price to pay.

Area Man wrote:Wobbling between hand supports may give you bad posture, but that can be fixed after you've got the general idea of how to get around.


You're not gonna affect anyone but yourself if you don't walk properly. It's not the same with computer programs.
Gott weiß ich will kein Engel sein!
EduardoLeon
 
Posts: 111
Joined: Wed Sep 30, 2009 2:26 am UTC
Location: Lima, Perú

Re: Best language for n00bs

Postby phlip » Thu Oct 08, 2009 9:55 pm UTC

EduardoLeon wrote:So your suggestion is to formalize informal learning? When I was at school, I thought the problem was that maths was not formal enough. The lack of formality leaded everybody (teachers included) to subtle traps. Besides, there are many counterintuitive facts in mathematics, and your approach wouldn't when dealing with them.

Yes, exactly, at least at first. The problem with maths education as it usually stands is that it's a compromise that's the worst of both worlds. It's not completely informal, because, as you say, that way leads pain, and horrible mathematicians (especially in fields like probability and statistics, that have many counter-intuitive results), and it's not completely formal, because then it'd be so goddamn boring that almost noone would actually make it to the end of the course. But the compromise that results is informal enough to keep people falling into traps, as you noticed, and formal enough to still bore everyone to tears.

My suggestion would be to basically teach it twice - once informally, and then again ultra-formally. Get people interested, give them the big-picture view, and then focus on the small details that'll let them avoid the traps. Because if you focus on the small details before you know the big picture, you're only going to end up lost and confused.

EduardoLeon wrote:Preventing people too idiot to ever program properly from programming is actually one of the goals of my approach to teaching/learning how to program. If some people who could have become programmers give up because they don't like the method, well, that's a small price to pay.

And if someone comes up to you (or comes into a forum) and asks "Hey, I want to learn programming, where should I start?" and you say "No, by my metric I just made up, you're too thick to understand programming, go take up something that's more in your level of intelligence, like football or something." then you're just being a dick.

And anyway, you talk like there's major damage done to the programming field by having people who are less-than-perfect learn how to program... or even people who simply don't learn well from a bottom-up approach. And we're not even necessarily talking about professionals here... your strategy would also deny programming to the extreme majority of amateurs, people who're just picking up programming for funsies, or to make their job that little bit less tedious that something like scripting in Excel can do. Where's the gain in being that excessively elitist?

And really, the question is "what's the best way to learn programming?"... the best way for the person, not everyone else. Even if your strategy was good for the programming community as a whole, which I still don't think it is, it wouldn't answer the question - even if you do find someone worthy of becoming a programmer, what's the best way, for that person, to get them from "not programmer" to "programmer"? 'Cause a scheme designed to weed out everyone unworthy isn't likely to cut it.
While no one overhear you quickly tell me not cow cow.
but how about watch phone?
User avatar
phlip
Restorer of Worlds
 
Posts: 7207
Joined: Sat Sep 23, 2006 3:56 am UTC
Location: Australia

Re: Best language for n00bs

Postby EduardoLeon » Thu Oct 08, 2009 11:26 pm UTC

phlip wrote:My suggestion would be to basically teach it twice - once informally, and then again ultra-formally. Get people interested, give them the big-picture view, and then focus on the small details that'll let them avoid the traps. Because if you focus on the small details before you know the big picture, you're only going to end up lost and confused.


Your approach doesn't ease the pain. It just concentrates the pain at a shorter period in time: the transition from just using an informal approach to being rigorous.

phlip wrote:My suggestion would be to basically teach it twice - once informally, and then again ultra-formally. Get people interested, give them the big-picture view, and then focus on the small details that'll let them avoid the traps. Because if you focus on the small details before you know the big picture, you're only going to end up lost and confused.


The big picture view is actually boring without the details.

phlip wrote:
EduardoLeon wrote:Preventing people too idiot to ever program properly from programming is actually one of the goals of my approach to teaching/learning how to program. If some people who could have become programmers give up because they don't like the method, well, that's a small price to pay


And if someone comes up to you (or comes into a forum) and asks "Hey, I want to learn programming, where should I start?" and you say "No, by my metric I just made up, you're too thick to understand programming, go take up something that's more in your level of intelligence, like football or something." then you're just being a dick.


When I was a student, I had to do programming assignments in teams many times, and I can't recall one occasion in which I hadn't struggled against my teammates' trial-and-error programming. Almost everyone lacked the abilities needed to see the interrelations between the parts of the systems, so they took it as a fact of life that, whenever someone modified the program, someone else's code had to break. More often than not, I had to dismiss their work, because it was pure junk. In one occasion, I had to dismiss the whole thing and redo it. I got called a dick as well, but in the end, my work was better than that of the team. (Besides, I passed my works as if it was theirs as well, so the net result for them was positive.)

I have also been in the situation of that whose contribution actually damages the effort of the team. I have never been a good soccer player, but was once forced by a school teacher to belong to the soccer team of my class. When I was replaced, I didn't call the captain (who requested my replacement) a dick, I knew I had to be replaced for good.

So I don't think that being a dick, if you like to call it so, is actually bad. It's good to call things by their names. If someone or something sucks, why not say it?

phlip wrote:And anyway, you talk like there's major damage done to the programming field by having people who are less-than-perfect learn how to program... or even people who simply don't learn well from a bottom-up approach. And we're not even necessarily talking about professionals here... your strategy would also deny programming to the extreme majority of amateurs, people who're just picking up programming for funsies, or to make their job that little bit less tedious that something like scripting in Excel can do. Where's the gain in being that excessively elitist?


I had quite a lot of fun with assembly. Actually, more fun than just creating wobsitez and posting them in teh interwebz.

phlip wrote:And really, the question is "what's the best way to learn programming?"... the best way for the person, not everyone else. Even if your strategy was good for the programming community as a whole, which I still don't think it is, it wouldn't answer the question - even if you do find someone worthy of becoming a programmer, what's the best way, for that person, to get them from "not programmer" to "programmer"? 'Cause a scheme designed to weed out everyone unworthy isn't likely to cut it.


Assembly is the most enjoyable way I can think of to teach someone how to program. When you start using assembly, programs don't work because there is some sort of voodoo magic. You actually understand how it works, and that's what gives you the most pleasure: understanding how it works.
Gott weiß ich will kein Engel sein!
EduardoLeon
 
Posts: 111
Joined: Wed Sep 30, 2009 2:26 am UTC
Location: Lima, Perú

Re: Best language for n00bs

Postby phlip » Thu Oct 08, 2009 11:46 pm UTC

EduardoLeon wrote:The big picture view is actually boring without the details.

But more so than the details without the big picture? I think the current level of boredom in the average maths class suggests not.

I'm not arguing against the fact that it's best to learn both the big picture and the details. I'm disagreeing with you on which one should be first.

EduardoLeon wrote:[...] Almost everyone lacked the abilities needed to see the interrelations between the parts of the systems, [...]

And you think that that would be helped by a stronger focus on the details, and not looking at the big picture?

EduardoLeon wrote:I had quite a lot of fun with assembly. Actually, more fun than just creating wobsitez and posting them in teh interwebz.

Good for you. Do you think you're in the majority?
While no one overhear you quickly tell me not cow cow.
but how about watch phone?
User avatar
phlip
Restorer of Worlds
 
Posts: 7207
Joined: Sat Sep 23, 2006 3:56 am UTC
Location: Australia

Re: Best language for n00bs

Postby EduardoLeon » Fri Oct 09, 2009 12:00 am UTC

phlip wrote:But more so than the details without the big picture? I think the current level of boredom in the average maths class suggests not.


The current level of boredom in the average maths class suggests that most people won't be engineers, physicists, mathematicians, etc. Let's face it, pplz: people might be created equal, but they aren't created equally intelligent.

phlip wrote:I'm not arguing against the fact that it's best to learn both the big picture and the details. I'm disagreeing with you on which one should be first.


Both have to be learnt at the very same time.

phlip wrote:And you think that that would be helped by a stronger focus on the details, and not looking at the big picture?


Both have to be seen at the very same time.

phlip wrote:Good for you. Do you think you're in the majority?


I don't know. I only know a handful of people who can actually program and all of them but two are too old to have learnt to program creating web applications. And those two who could have started creating web applications haven't.
Gott weiß ich will kein Engel sein!
EduardoLeon
 
Posts: 111
Joined: Wed Sep 30, 2009 2:26 am UTC
Location: Lima, Perú

Re: Best language for n00bs

Postby Philwelch » Fri Oct 09, 2009 5:01 am UTC

EduardoLeon wrote:Assembly is the most enjoyable way I can think of to teach someone how to program. When you start using assembly, programs don't work because there is some sort of voodoo magic. You actually understand how it works, and that's what gives you the most pleasure: understanding how it works.


Not at all. You have to start from physics and understand enough EM to know how to build a transistor, and then you can learn logic circuits, and then maybe, just maybe, you can understand how the CPU works if you write in machine code.

Then, maybe, if you know how to build an assembler in machine code, writing in assembly will make you understand how it works.
Fascism: If you're not with us you're against us.
Leftism: If you're not part of the solution you're part of the problem.

Perfection is an unattainable goal.
Philwelch
 
Posts: 2904
Joined: Tue Feb 19, 2008 5:33 am UTC
Location: RIGHT BEHIND YOU

PreviousNext

Return to Religious Wars

Who is online

Users browsing this forum: No registered users and 0 guests