Unicode has the entire gamut of Greek letters, mathematical and technical symbols, brackets, brockets, sprockets, and weird and wonderful glyphs such as "Dentistry symbol light down and horizontal with wave" (0x23c7). Why do we still have to name variables OmegaZero when our computers now know how to render 0x03a9+0x2080 properly?
uh yeah, Go allows you to use the full unicode just fine; on identifiers and everything - people should read the spec before making sensationalist comments that waste everyones time.
I think your two issues are programming mindset (code today is structured and designed differently from code in the 80's - a lot of innovation is not in programming languages but in how programming is approached.)
Work from your Pascal experience: - Learn Delphi, this will get you into Object Oriented languages while building off your Pascal experience - this gives you a strength to fall back on. - Using Delphi, write various GUI applications, this will move you from a procedural style of programming to todays event-driven style of programming. - Having mastered Delphi, move to C++; the two are similar enough to allow you to translate the concepts from Delphi into roughly equivalent C++. - Write GUI applications in C++ to see how modern platform APIs work (Qt, win32, wxWindows, dare I suggest MFC?) - You can doodle with C++ more advanced features (templates etc.) or decide not to bother, however following C++ you can move to "higher" languages like Java and C# if desired, or move toward dynamic languages like Python and Javascript. - Write a server-app in a few of those; don't bother with scaling any of it, but make sure the code elegantly handles any and all error conditions.
You do realise that wikipedia is a very complete collection of algorithms? Show me eg. Tarjan's strongly connected components algorithm in your freebookcentre - infact, clicking a few links, show me a book in your freebookcentre!
Could someone make an algorithm book please and then share with the rest of us?
Just grab the Algorithm category and all its subcategories - unfortunately it does not recursively descent to grab all pages by itself nor does it categorize into chapters so this will be a bit of work:-(
When done, please share and post a PDF here, or if possible (even better) share the book so it can be printed and wikipedia can get its dues!
So teach him assembler as a first language, and EVERYTHING else will look simple in comparison!
I think for many of us who grew up on home computers, Assembler was our first language; and we used it to write games and demos on C64 and Amiga's. Things don't get any simpler than assembly language (few concepts and a very finite set of instructions) and it's great for getting a gradual but very deep understanding for what a computer is and how it works. We did it in 68K and it was the ideal set-up for growing into higher-level languages (as it showed you what a higher level language is trying to help you with.) The problem with learning a higher level language first is you'll be too easily intimidated by lower-level concepts (pointers, call-stacks, hardware interfaces or just the way things are laid out in memory) and avoid those things for the rest of your career - I'm sure we've all seen the type of 'professional' programmer I'm talking about.
Having said that, the amount of shit ("work") you need to wade through to get anything done these days in assembler means it's no longer an option; definitely not for a "from-scratch" type of program, and definitely not for getting quick experimental results; so it's today pointless for teaching a kid how to code as he'll get bored before anything exciting happens (unlike the Amiga days when the code to get some copper bars going would fit on your screen.)
Not everywhere is like Dilbert, but everyone has known PHBs and know how destructive they can be. But I'm not one of them.
I would definitely not suggest you're a PHB, you sound like a good team leader. It is however very rare for a group of people to all have the same opinion; which is exactly why a 360 is so damn interesting.
My team members respect me and do as I ask because I'm not full of shit.
Work up your courage and do an anonymous 360; you'll be surprised. I'm assuming the team you're managing is of a meaningful size (eg. 15-20) the diversity of comments you get back is amazing and educational. People tend to have diverse needs from their superiors but face to face you usually get mostly smiley faces.
Don't kid yourselves, buying a new vehicle to "save the planet" is deluded. Keep your old one, no matter how inefficient it is, until something truly better and efficient comes along. Its energy costs have already been paid, for better or worse. Don't pay them over again, how is that ecologically sound?
Actually in some countries there's a good financial reason for getting a Prius; eg. in NL there is a 40% tax (called BPM, it's in addition to about 20% VAT) for every car sold. This tax is waived on the Prius and, needless to say, makes a huge difference in price.
Now if only we could convince goverments that optimal aerodynamics "save the planet", we'd be getting somewhere....
Parent is absolutely right, and this is true of many large companies today. Within IBM, there is too much focus on saving a dollar and doing things on the cheap, while missing the bigger picture and becoming ever distant to one's customers through intertwined cogs and wheels of process bureaucracy. There is a very strong innovative drive by doing your development in regions that have strong universities, a culture for innovation and local use and appreciation of the end product. Where that is depends on what you're doing. For cars, southern germany, for the web, california, for finance NYC and London.
However, by outsourcing everything to China and India, you loose that innovative drive, which erodes your longer term growth.
This is fine in only two cases I think, A) you don't care about the innovation of what you're developing (it's not your core business), or B) the type of work you're doing is extremely expensive *and* specialized (eg. chip design & manufacturing,) making it hard for an upstart to compete with you, even if your work is sloppy.
IBM rarely innovates anymore aside from some of its hardware, I'm not aware of any genuine software innovations from IBM in, say, the last 10 years.
The way large companies seem to be doing it now is by acquiring their way into innovation. I'm happy they do, because it makes startups that more valuable to do. Perhaps if large companies are changing their game, we engineers should wake up and adapt ours.. do more startups?
You are posting in a thread about the fact that Apple made their implementation open source and you are claiming vendor lock-in?
Are you one of those rabid Apple-haters we see so often around here? Or are you just amazingly stupid?
I must be amazingly stupid because I rather like Apple products.
Proprietary extensions are done for (arguably) the same reason by Microsoft; the goal should instead be to work on better iterations of language standards (C/C++) and not on introducing arbitrary language extensions that are not portable across compilers - especially not really extremely awkward ones like 'anonymous function pointers.' There's a similar argument to be made for 'encouraging' developers to use C# and Objective C.
The problem with multi-threading isn't in laborious API's, it's also not in language support for nifty features. The problem with multi-threading is that some problems are damn hard to multi-thread, either due to algorithms, or more commonly due to the way the internal structures are linked together.
This will only make overconfident developers shoot themselves in the foot more quickly (and provide some vendor lock-in for apple as things get increasingly less portable.)
The issue with raytracing is memory access patterns; this is not so much an issue with GPUs vs CPUs, but rather that both CPUs and GPUs rely on linear prefetch patterns through memory, which raytracing breaks as you traverse the spatial subdivision structure.
Secondly, ray tracers scale very well with resolution O(n) where n = number of pixels; we currently still have a relatively high constant cost, but assuming moore's law keeps up in performance and we find an answer to the memory problem, it is superior.
What makes the move to raytracing somewhat an inevitability, however, is not raytracings ability to very straightforwardly do more sophisticated lighting (many of which can be mimicked in awkward ways), but its ability to scale to massive amounts of geometry; eg. when using octrees, we're looking at O(log(n)) for n primitives - this is better than GPU rasterizing hardware where it is O(n).
The one critical failure of raytracing - and the reason it is hard to do games - is that to get to O(log(n)) you (currently) have to have static geometry - it cannot animate dynamically in realtime as you need to rebuild the spatial subdivision structure for the animated geometry on a frame by frame basis, and that gets expensive..
Perhaps some kind of mix will ultimately be used, but the geometry benefits of raytracing do still make the technology inevitable.
Having said that, Larrabee will be a stillborn for the first reason outlined.
Any sufficiently advanced technology is indistinguishable from magic; however you'll see these types of things pop up more and more.
Things to google for if you want to implement this yourself:
- "Point Matching" - when given two frames, which points are matching?
- "Five Point Relative Pose Problem" - this helps correlate camera motion from frame to frame when given 5 matching 2D points
- RANSAC - this helps filter out those matches that correspond to different moving objects - you'll burn through a lot of 5 point combinations and eventually the majority winner stays on.
Where I hope this area of technology goes is in the development of highly efficient HD codecs; I personally can't wait!
What's your opinion on the liquidity infusions and euro bank bailouts - do you expect libor rates to be a good indicator of an increase in money supply and do you expect that to lead to an inflationary environment over the longer term?
I'd have mod you up had I had the points, instead I find myself replying.
Given that many (if not most) of business in the world are looking towards America for leadership, it'll be interesting to see where this is heading.
Europe may perhaps be behind in productivity due to socialist labor protection, but the US is arguably too far on the other end of the spectrum.
I have knuth 1-2-3, the only reason I found for needing "Introduction to Algorithms" is the description contained there-in for red-black trees (which is painfully missing in knuth).
WOW! RMS not only gets to completely clarify his GNU/Linux nomenclature, he's also got the "Free software" vs. "Open Source" software argument nailed.
All this in a magazine like Forbes!
Holy crap and WOW! This might now be adopted by others in the press, and I love the "Linux Operating System Kernel" naming convention as a trade-off.
Wonderful. Now if only the Nobel committee would consider him and Torvalds for a Nobel Prize for sacrificing much of their lives for the sake of computing humanity's freedom, THEN we'll be getting somewhere.
For the casual slashdot reader; the Dutch and the Belgians appear to have a "thing" with eachother, whereby the Belgians are quite convinced the Dutch are cheap and eat only cheese. The Dutch, on the other hand, are convinced the Belgians are stupid & dumb.
From this, the casual Slashdot reader can immediately conclude two points, 1) The Dutch are not cheap, nor do they only eat cheese since, if this were true, the profound intelligence required to reach such a conclusion would mean Belgians are not stupid. 2) Given -1-, the writer of this post must obviously be Dutch.
from the article:
Unicode has the entire gamut of Greek letters, mathematical and technical symbols, brackets, brockets, sprockets, and weird and wonderful glyphs such as "Dentistry symbol light down and horizontal with wave" (0x23c7). Why do we still have to name variables OmegaZero when our computers now know how to render 0x03a9+0x2080 properly?
uh yeah, Go allows you to use the full unicode just fine; on identifiers and everything - people should read the spec before making sensationalist comments that waste everyones time.
I think your two issues are programming mindset (code today is structured and designed differently from code in the 80's - a lot of innovation is not in programming languages but in how programming is approached.)
Work from your Pascal experience:
- Learn Delphi, this will get you into Object Oriented languages while building off your Pascal experience - this gives you a strength to fall back on.
- Using Delphi, write various GUI applications, this will move you from a procedural style of programming to todays event-driven style of programming.
- Having mastered Delphi, move to C++; the two are similar enough to allow you to translate the concepts from Delphi into roughly equivalent C++.
- Write GUI applications in C++ to see how modern platform APIs work (Qt, win32, wxWindows, dare I suggest MFC?)
- You can doodle with C++ more advanced features (templates etc.) or decide not to bother, however following C++ you can move to "higher" languages like Java and C# if desired, or move toward dynamic languages like Python and Javascript.
- Write a server-app in a few of those; don't bother with scaling any of it, but make sure the code elegantly handles any and all error conditions.
Then you should be in the modern world.
do the opposite
You do realise that wikipedia is a very complete collection of algorithms? Show me eg. Tarjan's strongly connected components algorithm in your freebookcentre - infact, clicking a few links, show me a book in your freebookcentre!
Just grab the Algorithm category and all its subcategories - unfortunately it does not recursively descent to grab all pages by itself nor does it categorize into chapters so this will be a bit of work:-(
When done, please share and post a PDF here, or if possible (even better) share the book so it can be printed and wikipedia can get its dues!
Thanks!
Audi HQ is in Ingolstadt,
Mercedes HQ is in Stuttgart,
BMW HQ is in Munich,
VW HQ is in Wolfsburg,
Porsche is in Zuffenhausen (which apparently is in Stuttgart).
I think that about covers German cars.
So teach him assembler as a first language, and EVERYTHING else will look simple in comparison!
I think for many of us who grew up on home computers, Assembler was our first language; and we used it to write games and demos on C64 and Amiga's. Things don't get any simpler than assembly language (few concepts and a very finite set of instructions) and it's great for getting a gradual but very deep understanding for what a computer is and how it works. We did it in 68K and it was the ideal set-up for growing into higher-level languages (as it showed you what a higher level language is trying to help you with.) The problem with learning a higher level language first is you'll be too easily intimidated by lower-level concepts (pointers, call-stacks, hardware interfaces or just the way things are laid out in memory) and avoid those things for the rest of your career - I'm sure we've all seen the type of 'professional' programmer I'm talking about.
Having said that, the amount of shit ("work") you need to wade through to get anything done these days in assembler means it's no longer an option; definitely not for a "from-scratch" type of program, and definitely not for getting quick experimental results; so it's today pointless for teaching a kid how to code as he'll get bored before anything exciting happens (unlike the Amiga days when the code to get some copper bars going would fit on your screen.)
Not everywhere is like Dilbert, but everyone has known PHBs and know how destructive they can be. But I'm not one of them.
I would definitely not suggest you're a PHB, you sound like a good team leader. It is however very rare for a group of people to all have the same opinion; which is exactly why a 360 is so damn interesting.
My team members respect me and do as I ask because I'm not full of shit.
Work up your courage and do an anonymous 360; you'll be surprised. I'm assuming the team you're managing is of a meaningful size (eg. 15-20) the diversity of comments you get back is amazing and educational. People tend to have diverse needs from their superiors but face to face you usually get mostly smiley faces.
Interesting how easy it is to classify (former) colleagues as sociopath, clueless or loser, yet how this gets harder to do on ourselves.
Don't kid yourselves, buying a new vehicle to "save the planet" is deluded. Keep your old one, no matter how inefficient it is, until something truly better and efficient comes along. Its energy costs have already been paid, for better or worse. Don't pay them over again, how is that ecologically sound?
Actually in some countries there's a good financial reason for getting a Prius; eg. in NL there is a 40% tax (called BPM, it's in addition to about 20% VAT) for every car sold. This tax is waived on the Prius and, needless to say, makes a huge difference in price.
Now if only we could convince goverments that optimal aerodynamics "save the planet", we'd be getting somewhere....
That admittedly is pretty cool - but IBM has (last time I checked) 320,000 employees; so would you agree the point I'm trying to make still holds?
However, by outsourcing everything to China and India, you loose that innovative drive, which erodes your longer term growth.
This is fine in only two cases I think, A) you don't care about the innovation of what you're developing (it's not your core business), or B) the type of work you're doing is extremely expensive *and* specialized (eg. chip design & manufacturing,) making it hard for an upstart to compete with you, even if your work is sloppy.
IBM rarely innovates anymore aside from some of its hardware, I'm not aware of any genuine software innovations from IBM in, say, the last 10 years.
The way large companies seem to be doing it now is by acquiring their way into innovation. I'm happy they do, because it makes startups that more valuable to do. Perhaps if large companies are changing their game, we engineers should wake up and adapt ours.. do more startups?
You are posting in a thread about the fact that Apple made their implementation open source and you are claiming vendor lock-in?
Are you one of those rabid Apple-haters we see so often around here? Or are you just amazingly stupid?
I must be amazingly stupid because I rather like Apple products.
Proprietary extensions are done for (arguably) the same reason by Microsoft; the goal should instead be to work on better iterations of language standards (C/C++) and not on introducing arbitrary language extensions that are not portable across compilers - especially not really extremely awkward ones like 'anonymous function pointers.' There's a similar argument to be made for 'encouraging' developers to use C# and Objective C.
The problem with multi-threading isn't in laborious API's, it's also not in language support for nifty features. The problem with multi-threading is that some problems are damn hard to multi-thread, either due to algorithms, or more commonly due to the way the internal structures are linked together. This will only make overconfident developers shoot themselves in the foot more quickly (and provide some vendor lock-in for apple as things get increasingly less portable.)
The issue with raytracing is memory access patterns; this is not so much an issue with GPUs vs CPUs, but rather that both CPUs and GPUs rely on linear prefetch patterns through memory, which raytracing breaks as you traverse the spatial subdivision structure.
Secondly, ray tracers scale very well with resolution O(n) where n = number of pixels; we currently still have a relatively high constant cost, but assuming moore's law keeps up in performance and we find an answer to the memory problem, it is superior.
What makes the move to raytracing somewhat an inevitability, however, is not raytracings ability to very straightforwardly do more sophisticated lighting (many of which can be mimicked in awkward ways), but its ability to scale to massive amounts of geometry; eg. when using octrees, we're looking at O(log(n)) for n primitives - this is better than GPU rasterizing hardware where it is O(n).
The one critical failure of raytracing - and the reason it is hard to do games - is that to get to O(log(n)) you (currently) have to have static geometry - it cannot animate dynamically in realtime as you need to rebuild the spatial subdivision structure for the animated geometry on a frame by frame basis, and that gets expensive..
Perhaps some kind of mix will ultimately be used, but the geometry benefits of raytracing do still make the technology inevitable.
Having said that, Larrabee will be a stillborn for the first reason outlined.
Things to google for if you want to implement this yourself:
- "Point Matching" - when given two frames, which points are matching?
- "Five Point Relative Pose Problem" - this helps correlate camera motion from frame to frame when given 5 matching 2D points
- RANSAC - this helps filter out those matches that correspond to different moving objects - you'll burn through a lot of 5 point combinations and eventually the majority winner stays on.
Where I hope this area of technology goes is in the development of highly efficient HD codecs; I personally can't wait!
What's your opinion on the liquidity infusions and euro bank bailouts - do you expect libor rates to be a good indicator of an increase in money supply and do you expect that to lead to an inflationary environment over the longer term?
Such a beautiful, obviously overpriced candidate for shorting.
I'd have mod you up had I had the points, instead I find myself replying. Given that many (if not most) of business in the world are looking towards America for leadership, it'll be interesting to see where this is heading. Europe may perhaps be behind in productivity due to socialist labor protection, but the US is arguably too far on the other end of the spectrum.
I have knuth 1-2-3, the only reason I found for needing "Introduction to Algorithms" is the description contained there-in for red-black trees (which is painfully missing in knuth).
Amusing sarcasm but there's no reason for a database not to write directly to any random access device.
All this in a magazine like Forbes!
Holy crap and WOW! This might now be adopted by others in the press, and I love the "Linux Operating System Kernel" naming convention as a trade-off.
Wonderful. Now if only the Nobel committee would consider him and Torvalds for a Nobel Prize for sacrificing much of their lives for the sake of computing humanity's freedom, THEN we'll be getting somewhere.
From this, the casual Slashdot reader can immediately conclude two points, 1) The Dutch are not cheap, nor do they only eat cheese since, if this were true, the profound intelligence required to reach such a conclusion would mean Belgians are not stupid. 2) Given -1-, the writer of this post must obviously be Dutch.
:-P
Klasse lui!
There's no practical way without hacking it to get to the geometry; thus making it useless for indie game development.