It kind of depends. It's "just" a Master's thesis, which means that you need to be able to put together something credible in the sense that you can formulate a larger academic work with an argument, sources and perhaps something of your own to back your thesis up.
At least over here in Finland, the point is not to really produce original research. That's for Ph.D.'s. For Master's you want to show you understand your subject matter and aren't just wantonly making shit up. In this sense I can understand your professor wanting to just get your degree and move on... if you're going to do actual publication in a journal, write a PhD thesis or something, the criteria are different.
The idea with getters and setters is that in the end the value may not actually be a field (it may be computed), and interfaces can't contain fields. Plus the JavaBeans style naming conventions are pretty ubiquitous in the Java world... not sure if everything works right with just plain fields like that (it may).
Well, the first idea that comes to mind is having a 3D grid with greater costs for those routes that need to be offset vertically from where the ground is now, and making sure that only such routes are valid that do not offset more than by +1/-1 per horizontal move.
Of course this may screw up A*/Dijkstra's "edge" nodes' ideas of their route costs when a nearby route decides to start modifying terrain... hmm.
The formula itself doesn't need to be proven correct except by having repeated experimentation confirming its validity as far as has been tested. However, incompleteness does raise the interesting question of whether all universal laws really would be derivable from some fundamental theory of everything, because, as we know, all theories are necessarily either incomplete or contradictory...
Let's pay verified girls to post in Slashdot discussions. Then, for a fee, you'll get either dirty or flirty responses to your posts about programming languages or whatnot.
I really, really hope they do not go overboard with the different "natures" of civilizations. It's really boring to know beforehand what kind of an opponent you're dealing with just by knowing which civilization they are, and by being really pushed into some play-style by the civilization you are playing.
If the player wants to stress a certain direction in his game, he should build towards that, not get bonuses handed to him to make it easier...
IMO Python-style genericity makes code much briefer and manageable in the sense that it is easier to see that some piece of code, in isolation, does things correctly as long as the assumptions regarding the objects given hold. And as the type information is there at runtime, type errors actually crash the program in testing very quickly, after which it's just a case of verifying where you're making that call and what it is you're giving the function.
I do understand what you're saying, but simply am a bit unimpressed by the supposed benefits of explicitly telling the compiler what you already know.
By the way, Lisp wins here in general; it's duck-typed to begin with, but lets you annotate type information, which both helps the compiler and and can warn you when the compiler can tell the type annotations do not add up.
The deal is that if you're writing generic enough code, you shouldn't really care what it actually is that you've got, as long as it works as required. Explicitly spelling out things like interfaces help the compiler, but is generally redundant information.
Documentation should always be written of course, especially when behaviour needs to be documented. This is something that a static type system won't help with.
A lot of those things don't really require an assembly-level knowledge of things. Understanding the complexity classes of your algorithms is perfectly doable without any kind of low-level understanding, so is managing the concept of linked lists, hashes, other data structures... pointers are essentially just an indirect reference type. Why tail calls are optimizable is clear from languages like Scheme already.
I'm not saying low-level understanding is useless, but it certainly overrated.
Wow. I know that I have always had the impression that low-level guys really can't see the forest for the trees and seem to stress the nitty-gritty at the expense of having an idea of the big picture of what kind of "things" go into a programmed solution... but wow.:)
That just makes learning and developing your mindset about programming much slower. Programming is, at least to me, a formulation of a computable solution in some Turing-complete language. The machine-specific stuff is actually not the part that the human is most required in, as it can be pushed to be done by the machine itself.
A wrongly constructed algorithm fails just as much in a higher-level language as it does in a lower-level language, but allows for clearer, faster understanding of why it actually fails. The machine-implementation failure related stack traces are code-monkey style stuff in comparison.
If Python has a problem as a language for tutorial programming, it is probably in its rather limited error checking.
Well, one can have an entire discussion over the merits of, say, static vs. duck typing. IMO most type errors are so grave that they are caught by even simple testing (remember, Python is still strongly typed), and messing with the type system especially if you're a beginner is more trouble than what it is worth... in particular in languages like Java where the OOP stuff can make the learning curve far more steep than it needs to be.
true high performance computing, knowing your hardware can make a huge difference too
From my perspective, "true high performance computing" when defined like this is essentially a special field... a bit like J2EE, which you can't do without Java. When the comparisons are to programmers who can't tell apart linear from quadratic, the objections sound dubious.
Add to that that a lot of the low-level guys seem to be so oblivious to appreciating anything beyond the hardware that it sometimes makes me wonder where they actually get their ideas regarding what and how to actually code...
The issue with Knuth is his insistence on machine code representation and the time he spends analyzing something like mere linked lists... philosophically, I am much more inclined to be fond of the way McCarthy did it with Lisp, and this was a long time ago too...
I'm a bit of both an algorithmics and programming language design geek with leanings for high level programming, and I never quite understood
and a programming technique compatible with the underlaying hardware and/or OS structure,
this part. A good language that allows for flexible design doesn't necessarily have to do much with the hardware, but it still allows you a very good access to the algorithmic part of the problem. The "hardware" side of things will mostly give you constant-factor improvements... but strangely, a lot of the people who talk about programming near the hardware will then give really awful examples like your O(n^2) case. That sort of stuff should be obvious to anyone doing any kind of programming IMO.
Not every programmer you're going to run into is going to be a brilliant assembly level kernel hacker. Some of them (these days anyway) are going to be mediocre.
I would have to disagree with the notion that a programmer is either brilliant by being an "assembly-level kernel hacker" or then he is mediocre and "just uses library calls". This is the kind of weird dichotomy I tend to see from the most arrogant-ignorant low-level guys who probably don't have much of a theoretical CS background, or something. Software does not work on a continuum from hardware level to stupid cut and paste code monkeys.
The most brilliant programmers I know are the ones who have a loads of insight into the working and structure of software in general, regardless of language and/or proximity to hardware. It is all about identifying the problem solution and then making use of some formalism to describe that solution in computable terms. IMO good Lispers are hard to beat in this regard...
I have actually been talking at length to these people whose only interest is in speed within tiny constraints (in the context of "in what order should one teach things when teaching a future insightful coder"), and they always leave me with the impression that that really is the only thing they know -- at least that is how loudly they condemn higher-level programming without giving me much reason to assume they know what they're talking about... for example "closure" doesn't seem to mean much;)
Assembly is a specialized programming formalism and domain in a similar style as J2EE is. It requires a specific knowledge set, but it is possible to be a just code monkey in both of them.
And yes, I do know asm, just never saw it as much more than a simple sequence of state manipulations... E. Dijkstra said that "our tools influence our thinking", and I have personally been influenced by pretty much everything else.
But then again I'm a somewhat philosophical CS type -- my interests are not only in speed in tiny constraints:p
IMO Haskell fulfills that role just as well... I do find Lisp to be more general-purpose -- in particular the syntax-tree transformations that Lisp macros are are somehow the most "general" form of programming I've come across... the whole thing is, in the end, an extensible compiler in itself on top of a minimally small set of maximally expressive primitives.
This is also why the "writing of interpreter" is an educational experience. I used to somewhat dismiss the statement from likes of Paul Graham about how you should be programming in terms of creating specialized languages, but then I got the religion, and talked to a really smart hobbyist programmer linguist, too, at length...
Slashdot Mirror
Alternatively, he would have got a bullet in the back of the head. Think the melamine milk scandal.
It kind of depends. It's "just" a Master's thesis, which means that you need to be able to put together something credible in the sense that you can formulate a larger academic work with an argument, sources and perhaps something of your own to back your thesis up.
At least over here in Finland, the point is not to really produce original research. That's for Ph.D.'s. For Master's you want to show you understand your subject matter and aren't just wantonly making shit up. In this sense I can understand your professor wanting to just get your degree and move on... if you're going to do actual publication in a journal, write a PhD thesis or something, the criteria are different.
But that's just "over here".
The idea with getters and setters is that in the end the value may not actually be a field (it may be computed), and interfaces can't contain fields. Plus the JavaBeans style naming conventions are pretty ubiquitous in the Java world... not sure if everything works right with just plain fields like that (it may).
But, those are part of ISO-8859-1 of course.
äöäöäö. No.
Well, the first idea that comes to mind is having a 3D grid with greater costs for those routes that need to be offset vertically from where the ground is now, and making sure that only such routes are valid that do not offset more than by +1/-1 per horizontal move.
Of course this may screw up A*/Dijkstra's "edge" nodes' ideas of their route costs when a nearby route decides to start modifying terrain... hmm.
The formula itself doesn't need to be proven correct except by having repeated experimentation confirming its validity as far as has been tested. However, incompleteness does raise the interesting question of whether all universal laws really would be derivable from some fundamental theory of everything, because, as we know, all theories are necessarily either incomplete or contradictory...
I wonder what sort of a fig leaf it will use to plug the gap in the goatse photo...
Wut r u waring??
Let's pay verified girls to post in Slashdot discussions. Then, for a fee, you'll get either dirty or flirty responses to your posts about programming languages or whatnot.
I really, really hope they do not go overboard with the different "natures" of civilizations. It's really boring to know beforehand what kind of an opponent you're dealing with just by knowing which civilization they are, and by being really pushed into some play-style by the civilization you are playing.
If the player wants to stress a certain direction in his game, he should build towards that, not get bonuses handed to him to make it easier...
Really? How good are you at Prolog, Lisp and Haskell?
IMO Python-style genericity makes code much briefer and manageable in the sense that it is easier to see that some piece of code, in isolation, does things correctly as long as the assumptions regarding the objects given hold. And as the type information is there at runtime, type errors actually crash the program in testing very quickly, after which it's just a case of verifying where you're making that call and what it is you're giving the function.
I do understand what you're saying, but simply am a bit unimpressed by the supposed benefits of explicitly telling the compiler what you already know.
By the way, Lisp wins here in general; it's duck-typed to begin with, but lets you annotate type information, which both helps the compiler and and can warn you when the compiler can tell the type annotations do not add up.
The deal is that if you're writing generic enough code, you shouldn't really care what it actually is that you've got, as long as it works as required. Explicitly spelling out things like interfaces help the compiler, but is generally redundant information.
Documentation should always be written of course, especially when behaviour needs to be documented. This is something that a static type system won't help with.
Yeah, I know. I'm more of a lisper though, but same thing.
A lot of those things don't really require an assembly-level knowledge of things. Understanding the complexity classes of your algorithms is perfectly doable without any kind of low-level understanding, so is managing the concept of linked lists, hashes, other data structures... pointers are essentially just an indirect reference type. Why tail calls are optimizable is clear from languages like Scheme already.
I'm not saying low-level understanding is useless, but it certainly overrated.
Wow. I know that I have always had the impression that low-level guys really can't see the forest for the trees and seem to stress the nitty-gritty at the expense of having an idea of the big picture of what kind of "things" go into a programmed solution... but wow. :)
That just makes learning and developing your mindset about programming much slower. Programming is, at least to me, a formulation of a computable solution in some Turing-complete language. The machine-specific stuff is actually not the part that the human is most required in, as it can be pushed to be done by the machine itself.
A wrongly constructed algorithm fails just as much in a higher-level language as it does in a lower-level language, but allows for clearer, faster understanding of why it actually fails. The machine-implementation failure related stack traces are code-monkey style stuff in comparison.
If Python has a problem as a language for tutorial programming, it is probably in its rather limited error checking.
Well, one can have an entire discussion over the merits of, say, static vs. duck typing. IMO most type errors are so grave that they are caught by even simple testing (remember, Python is still strongly typed), and messing with the type system especially if you're a beginner is more trouble than what it is worth... in particular in languages like Java where the OOP stuff can make the learning curve far more steep than it needs to be.
true high performance computing, knowing your hardware can make a huge difference too
From my perspective, "true high performance computing" when defined like this is essentially a special field... a bit like J2EE, which you can't do without Java. When the comparisons are to programmers who can't tell apart linear from quadratic, the objections sound dubious.
Add to that that a lot of the low-level guys seem to be so oblivious to appreciating anything beyond the hardware that it sometimes makes me wonder where they actually get their ideas regarding what and how to actually code...
The issue with Knuth is his insistence on machine code representation and the time he spends analyzing something like mere linked lists... philosophically, I am much more inclined to be fond of the way McCarthy did it with Lisp, and this was a long time ago too...
I'm a bit of both an algorithmics and programming language design geek with leanings for high level programming, and I never quite understood
and a programming technique compatible with the underlaying hardware and/or OS structure,
this part. A good language that allows for flexible design doesn't necessarily have to do much with the hardware, but it still allows you a very good access to the algorithmic part of the problem. The "hardware" side of things will mostly give you constant-factor improvements... but strangely, a lot of the people who talk about programming near the hardware will then give really awful examples like your O(n^2) case. That sort of stuff should be obvious to anyone doing any kind of programming IMO.
Not every programmer you're going to run into is going to be a brilliant assembly level kernel hacker. Some of them (these days anyway) are going to be mediocre.
I would have to disagree with the notion that a programmer is either brilliant by being an "assembly-level kernel hacker" or then he is mediocre and "just uses library calls". This is the kind of weird dichotomy I tend to see from the most arrogant-ignorant low-level guys who probably don't have much of a theoretical CS background, or something. Software does not work on a continuum from hardware level to stupid cut and paste code monkeys.
The most brilliant programmers I know are the ones who have a loads of insight into the working and structure of software in general, regardless of language and/or proximity to hardware. It is all about identifying the problem solution and then making use of some formalism to describe that solution in computable terms. IMO good Lispers are hard to beat in this regard...
I have actually been talking at length to these people whose only interest is in speed within tiny constraints (in the context of "in what order should one teach things when teaching a future insightful coder"), and they always leave me with the impression that that really is the only thing they know -- at least that is how loudly they condemn higher-level programming without giving me much reason to assume they know what they're talking about... for example "closure" doesn't seem to mean much ;)
Assembly is a specialized programming formalism and domain in a similar style as J2EE is. It requires a specific knowledge set, but it is possible to be a just code monkey in both of them.
And yes, I do know asm, just never saw it as much more than a simple sequence of state manipulations... E. Dijkstra said that "our tools influence our thinking", and I have personally been influenced by pretty much everything else.
But then again I'm a somewhat philosophical CS type -- my interests are not only in speed in tiny constraints :p
IMO Haskell fulfills that role just as well... I do find Lisp to be more general-purpose -- in particular the syntax-tree transformations that Lisp macros are are somehow the most "general" form of programming I've come across... the whole thing is, in the end, an extensible compiler in itself on top of a minimally small set of maximally expressive primitives.
This is also why the "writing of interpreter" is an educational experience. I used to somewhat dismiss the statement from likes of Paul Graham about how you should be programming in terms of creating specialized languages, but then I got the religion, and talked to a really smart hobbyist programmer linguist, too, at length...