Right. Apple created Swift because Objective-C was a nice language for the requirements of '90s computing, but is starting to be limited by its C heritage. They needed a more modern language that interoperates very well with Objective-C (because they have a lot of legacy Objective-C code that isn't going away any time soon) and this required making a new language because there weren't any good contenders available. MacRuby is the closest, but falls short in a number of areas.
Google didn't create Go as the result of some corporate masterplan, a small team at Google created it and managed to get buy-in from some other groups at Google. It's still far from the most widely used language for new projects inside Google, but it does have some advantages (though is slightly let down by Rob Pike's refusal to accept that some people who are not Rob Pike have had good ideas in the last 30 years).
The recruiting thing can't really work. It would only really make sense if people would learn a cool language and then discover that there are very few places where they can work and use it. This is sort-of true for something like Erlang or Smalltalk, but Swift is fairly widely used by people developing for iOS and OS X (and would probably not be worth Apple's effort in developing it if it weren't). If the language is successful enough that enough people are learning it to significantly affect the pool of potential applicants for a company the size of Apple or Google, then enough other companies are likely to be using it that it isn't a significant benefit.
I'm also not in America. The BCS is our local equivalent, but the ACM has a large international membership and either runs, or co-runs with the IEEE, almost all of the top-tier computer science conferences around the world. It also publishes most of the top-tier journals in computer science. What country are you from where no one has ever heard for the ACM? I'd have guessed Australia from your username, but that can't be it as the ACM has a fairly significant presence there.
A compositing display server saves a lot of CPU, by just doing the rendering and rasterisation of windows once and then alpha blending the resulting windows. You don't need to redraw for expose events, you just composite the results. This saves even having to bring the background applications into the cache (or into RAM if they're swapped out). Within an application, you can get the same benefit, caching the rendered results of (for example) a complex data-driven view and not having to do a load of queries of a model object because an overlapping view needs redrawing.
The down side of this is that you end up doing a lot of compositing. Sure, you can do this on the CPU (and a modern CPU is fast enough to do it on the vector unit reasonably fast), but that consumes a lot more power than doing it on the GPU.
I've hacked on GPU drivers. These days the command submission part is pretty simple, most of the driver is the compiler that generates optimised code for a processor that's highly optimised for a fairly narrow set of workloads. The firmware, on the other hand, is an entirely different thing. This is closer to CPU microcode than a driver. It's likely written to a one-off architecture and is likely to be completely rewritten for the next revision.
Steve Jobs made anti-DRM statements very early on. At the time, the music industry was insisting on DRM for everything. They eventually learned that it gave more power to the distributors than to them and allowed Amazon to sell DRM-free music (but didn't allow Apple the same deal for a while, to allow Amazon to become a viable competitor). For some reason, the movie studios are intent on making the same mistake and insisting that Amazon and Netfilx take complete control of their supply chain, when the best thing for their business is a healthy competitive ecosystem driving each others margins.
If they had any sense, the music and movie studios would insist that distributors sell without DRM.
If you run a messenger service, you aren't entitled to decide that select groups can't use your service. You can't decide that you will monitor the messages, and only deliver those messages that you approve of. You don't get to decide that you will deliver partisan messages that favor your position, and just lose messages that support the other side.
I'm fine with you doing all of these, as long as you're willing to take responsibility for every message sent on your service. Bomb threats, death threats, trade secrets, copyright infringement, all become your liability - if you're policing the content then you're responsible for it.
The NSA or GCHQ (or any similar intelligence agency) almost certainly could insert a backdoor into MS software. Doing the same any other piece of proprietary software developed by people that they could easily blackmail would also be easy. There are a number of approaches that would work for open source too - there was a recent story about a lot of contributors to prominent projects hosted on GitHub having weak SSH keys, so compromising one of these from someone who hasn't committed in a long time and putting in a bug fix along with an obfuscated backdoor would be easy.
The danger of doing this is that there's a lot of potential fallout if they're caught. This kind of active intervention raises the stakes and also weakens their defences (it's very hard to create a backdoor that isn't a security vulnerability). Given that almost no software is formally verified and most is very complex and not aggressively tested against hostile input, if you've got enough resources to throw at it then you can probably find an exploitable bug already and not have to bother. This is much more deniable, because no one can be completely sure that you were the ones exploiting the vulnerability.
In Smalltalk, there are two integer types that can be used pretty much interchangeably. SmallInt objects are stored inside a pointer, so they are typically 31 or 61 bits, with the low bits used to distinguish pointers from small objects (on 64-bit platforms, some float values can be safely stored in a pointer too). If a SmallInt operation overflows, then the result is a BigInt object. BigInt objects are real (immutable) objects that encapsulate an arbitrary-precision integer. They're much slower to use than SmallInts, but you generally don't think about which you're using, you just use an integer type and let the language / libraries handle making it efficient. Floating point values are handled similarly, though they don't grow precision (I don't remember what the Smalltalk-80 spec mandates, but some implementations provide high-precision floating point classes that you can use instead of the efficient hardware-sized floating point).
In contrast, JavaScript provides an IEEE double and nothing else. Implementations try very hard to avoid actually using doubles to implement them for values that are actually integers, because floating point operations are a lot slower than integer ones on modern CPUs. Because operators are special in JavaScript (anyone know what object + array is?), you can't provide any kind of number with increased precision. Try dealing with any data that comes with 64-bit values (e.g. file offsets on a modern FS) in JavaScript and you'll see the pain.
The JavaScript implementation from Cadence that's used for scripting various IC design systems avoids this by providing the full Smalltalk set of number types (it's actually implemented in NewSpeak, which is implemented in Smalltalk, for extra fun).
It's also useful for providing an API that other tools can use. Lots of things can parse RSS feeds, not just readers, and it's a good way of providing activity indicators on other sites.
And, especially, the maps where I most want this are embedded (e.g. in a hotel side where I want to see how far the hotel is from the places I actually want to go) and so don't provide access to the directions bar.
There's a nice paper from the developers of the Apple Newton, which argues that class-based OO maps very well to model objects (where you have lots of objects that are mostly the same), whereas prototype-based OO is a better fit for views, where you want a bit of customisation for almost every instance. JavaScript is a language that is designed for UIs, with the back end being written in some other language, so it's hardly a surprise that it chose prototypes.
My biggest complaint about JavaScript is that, even with Smalltalk and Self as examples of languages that did it right that the developers were intimately familiar with, they still managed to get numbers wrong.
This would have been more funny 10 years ago when people still said 'Java applet' without laughing and both statements could have been applied to either language. I rather like the top answer though: 'Java and Javascript are similar like Car and Carpet are similar'.
Yes, exactly. Being old and cynical that was my thought too. Show source 'A' but compile from source 'B'. Then we'll truly 'experience their committment to transparency' won't we?
It depends on the threat model that you care about. On the one hand, it is bad if there are intentionally and maliciously injected trojans. On the other hand, the Snowden disclosures have shown that this is rarely done - it's high risk and there are enough vulnerabilities in code that the NSA can exploit without needing to do anything active to the supply chain. Being able to find these and get MS to fix them is probably quite important.
My main objection to this is that I don't like to see tax money being used to improve a single company's product.
USB C was something Apple gave the USB folks because they're just disgusted with the crap that is the USB connector
i second the 'huh?' from the other poster. Apple did grant the USB consortium some patents, but they were not involved with the design of the USB C connector at all. It was developed by a committee, with some fairly major contributions from Google.
Nokia has also been in the market of selling the infrastructure for mobile networks for a long time. And, unlike the handsets, this is a very profitable place to be. Both Nokia and Ericsson saw the commoditisation of the handset market and Nokia in particular watched their margins evaporate and decided it was time to get out. But because they're now no longer in the public eye, they're perceived as losing. Now their customers are people who make money from the products that they sell, so are willing to pay a reasonable premium because a few minutes of downtime costs far more.
Of course, when Apple decides to concentrate on the high-margin part of a business, no one claims that they're dying, because they concentrate on a consumer-visible part of the market.
There's some overlap. Altera FPGAs have lots of fixed-function blocks on them, ranging from simple block RAMs to fast floating point units. There's a good chance that Intel could reuse some of their existing designs (which, after all, are already optimised for their manufacturing process) from things like AVX units and caches on x86 chips. A lot of the FPGAs also include things like PCIe, USB, Ethernet and so on controllers. Again, Intel makes these in their chipset division and, again, they're optimised for Intel's process so being able to stick them on FPGAs instead of the Altera ones would make sense.
The main reason that you're probably right is that Intel is generally pretty bad at getting their own internal divisions to play nicely together, let alone ones that are used to being in a completely separate company.
My guess would be coarse-grained reconfigurable architectures. Altera FPGAs aren't just FPGAs, they also have a load of fixed-function blocks. The kinds of signal processing that the other poster talks about work because there are various floating point blocks on the FPGA and so you're using the programmable part to connect a sequence of these operations together without any instruction fetch/decode or register renaming overhead (you'd be surprised how much of the die area of a modern CPU is register renaming and how little is ALUs).
FPGAs are great for prototyping (we've built an experimental CPU as a softcore that runs on an Altera FPGA at 100MHz), but there are a lot of applications that could be made faster by being able to wire a set of SSE / AVX execution units together into a fixed chain and just fire data at them.
That minimum wage guy is one of the major costs for a taxi company. The IRS rates miles driven in a car at a little under 60/mile, which should cover maintenance, depreciation, insurance and fuel. A taxi that only had these costs could be quite profitable at 70/mile. In New York, taxis cost $2/mile, which isn't that far off other places in the USA. The minimum wage guy needs to be paid even when the taxi is waiting for the next fare. With an automated car, you'd just leave them scattered around the city powered down and turn on the closest one when you got a new job.
A Kickstarter-like model would work. Release a single for free, designate an amount that you think the full album is worth. If enough people are willing to pay, then you release the album for free. For the second album, hopefully enough people have copied the first that you don't need to do much to encourage them to pay for the second. As an added bonus, you can reduce your up-front costs by only renting the studio time to record the first track and only record the rest once people have paid for it.
Recording a song (at least, a song that people want to buy) requires talent, creativity, and often expensive instruments and studio time. Copying a song once it's recorded is basically free. Any business model that relies on doing the difficult thing for free and then trying to persuade people to pay for you to do the easy thing is doomed to failure. Imagine if Ford had noticed that people wanted coloured cars and decided to give away unpainted cars and charge for painting them, then bribed politicians to pass laws so that only Ford was allowed to paint cars Ford sold and driving an unpainted car on the road was illegal. It wouldn't take people long to realise that this was a stupid business model and that you could get rid of the laws and charge for the cars, but in the case of copyright people are still trying very hard to make the 'free car, expensive and exclusive paint' model work with different variations.
It's an ABI mismatch, and the summary is nonsense, saying almost the exact opposite of TFA (which I actually read, because the summary is obvious nonsense). The issue is that the Windows ABI defines long double as being a 64-bit floating point value (which is fine, because the only requirement for long double is that it have no less precision than double. If you're using it and expecting some guaranteed precision for vaguely portable code then you're an idiot). For some reason, MinGW (which aims to be ABI-compatible with MS, at least for C libraries) uses 80-bit x87 values for long double, so you get truncation. I forget the exact calling conventions for Windows i386, but I believe that in some cases this will be silently hidden, as the value will be passed in x87 register and so be transparently extended to 80 bits in the caller and truncated in the callee anyway. It's only if it's passed on the stack (or indirectly via a pointer) that it's a problem.
It's not obvious which definition of long double is better. On modern x86, you'll use SSE for 32- and 64-bit values, and may lose precision moving between x87 and SSE registers. You also get worse IEEE compliance out of the x87 unit, which may matter more than the extra 16 bits of precision. 80-bit floats are not available on any platform other than x86 (128-bit is more common, though PowerPC has its own special non-IEEE version of these and on some other platforms they're entirely done in software), so they're a bad choice if you want portable code that generates the same output on different platforms.
The same is true of university exams. My undergraduate exams, for example, mostly required that you answer two of three questions per exam. To get a first (for people outside the UK: the highest classification), you needed to get 70%. Most questions were around 40% knowledge and 60% application of the knowledge. If you could predict the topics that the examiner would pick, then that meant that you could immediately discard a third of the material. To get the top grade, you needed to get 100% in one question and 40% in another. This meant that you could understand a third of the material really well and understand another third well enough to get the repetition marks, but not the understanding ones and still get the top grade. This meant that you could study 50% of the material and still do very well in the exams, as long as you picked the correct 50%. And some of the lecturers were very predictable when setting exams...
Slashdot Mirror
Right. Apple created Swift because Objective-C was a nice language for the requirements of '90s computing, but is starting to be limited by its C heritage. They needed a more modern language that interoperates very well with Objective-C (because they have a lot of legacy Objective-C code that isn't going away any time soon) and this required making a new language because there weren't any good contenders available. MacRuby is the closest, but falls short in a number of areas.
Google didn't create Go as the result of some corporate masterplan, a small team at Google created it and managed to get buy-in from some other groups at Google. It's still far from the most widely used language for new projects inside Google, but it does have some advantages (though is slightly let down by Rob Pike's refusal to accept that some people who are not Rob Pike have had good ideas in the last 30 years).
The recruiting thing can't really work. It would only really make sense if people would learn a cool language and then discover that there are very few places where they can work and use it. This is sort-of true for something like Erlang or Smalltalk, but Swift is fairly widely used by people developing for iOS and OS X (and would probably not be worth Apple's effort in developing it if it weren't). If the language is successful enough that enough people are learning it to significantly affect the pool of potential applicants for a company the size of Apple or Google, then enough other companies are likely to be using it that it isn't a significant benefit.
I'm also not in America. The BCS is our local equivalent, but the ACM has a large international membership and either runs, or co-runs with the IEEE, almost all of the top-tier computer science conferences around the world. It also publishes most of the top-tier journals in computer science. What country are you from where no one has ever heard for the ACM? I'd have guessed Australia from your username, but that can't be it as the ACM has a fairly significant presence there.
A compositing display server saves a lot of CPU, by just doing the rendering and rasterisation of windows once and then alpha blending the resulting windows. You don't need to redraw for expose events, you just composite the results. This saves even having to bring the background applications into the cache (or into RAM if they're swapped out). Within an application, you can get the same benefit, caching the rendered results of (for example) a complex data-driven view and not having to do a load of queries of a model object because an overlapping view needs redrawing.
The down side of this is that you end up doing a lot of compositing. Sure, you can do this on the CPU (and a modern CPU is fast enough to do it on the vector unit reasonably fast), but that consumes a lot more power than doing it on the GPU.
I've hacked on GPU drivers. These days the command submission part is pretty simple, most of the driver is the compiler that generates optimised code for a processor that's highly optimised for a fairly narrow set of workloads. The firmware, on the other hand, is an entirely different thing. This is closer to CPU microcode than a driver. It's likely written to a one-off architecture and is likely to be completely rewritten for the next revision.
Seriously? A site for geeks can't expect people to know the professional association for computer scientists? Would you also want IEEE expanded?
Steve Jobs made anti-DRM statements very early on. At the time, the music industry was insisting on DRM for everything. They eventually learned that it gave more power to the distributors than to them and allowed Amazon to sell DRM-free music (but didn't allow Apple the same deal for a while, to allow Amazon to become a viable competitor). For some reason, the movie studios are intent on making the same mistake and insisting that Amazon and Netfilx take complete control of their supply chain, when the best thing for their business is a healthy competitive ecosystem driving each others margins.
If they had any sense, the music and movie studios would insist that distributors sell without DRM.
If you run a messenger service, you aren't entitled to decide that select groups can't use your service. You can't decide that you will monitor the messages, and only deliver those messages that you approve of. You don't get to decide that you will deliver partisan messages that favor your position, and just lose messages that support the other side.
I'm fine with you doing all of these, as long as you're willing to take responsibility for every message sent on your service. Bomb threats, death threats, trade secrets, copyright infringement, all become your liability - if you're policing the content then you're responsible for it.
The NSA or GCHQ (or any similar intelligence agency) almost certainly could insert a backdoor into MS software. Doing the same any other piece of proprietary software developed by people that they could easily blackmail would also be easy. There are a number of approaches that would work for open source too - there was a recent story about a lot of contributors to prominent projects hosted on GitHub having weak SSH keys, so compromising one of these from someone who hasn't committed in a long time and putting in a bug fix along with an obfuscated backdoor would be easy.
The danger of doing this is that there's a lot of potential fallout if they're caught. This kind of active intervention raises the stakes and also weakens their defences (it's very hard to create a backdoor that isn't a security vulnerability). Given that almost no software is formally verified and most is very complex and not aggressively tested against hostile input, if you've got enough resources to throw at it then you can probably find an exploitable bug already and not have to bother. This is much more deniable, because no one can be completely sure that you were the ones exploiting the vulnerability.
Hmm, that looks familiar. It was either that or an extended tech report version of the same thing that I was thinking of. Thanks!
In Smalltalk, there are two integer types that can be used pretty much interchangeably. SmallInt objects are stored inside a pointer, so they are typically 31 or 61 bits, with the low bits used to distinguish pointers from small objects (on 64-bit platforms, some float values can be safely stored in a pointer too). If a SmallInt operation overflows, then the result is a BigInt object. BigInt objects are real (immutable) objects that encapsulate an arbitrary-precision integer. They're much slower to use than SmallInts, but you generally don't think about which you're using, you just use an integer type and let the language / libraries handle making it efficient. Floating point values are handled similarly, though they don't grow precision (I don't remember what the Smalltalk-80 spec mandates, but some implementations provide high-precision floating point classes that you can use instead of the efficient hardware-sized floating point).
In contrast, JavaScript provides an IEEE double and nothing else. Implementations try very hard to avoid actually using doubles to implement them for values that are actually integers, because floating point operations are a lot slower than integer ones on modern CPUs. Because operators are special in JavaScript (anyone know what object + array is?), you can't provide any kind of number with increased precision. Try dealing with any data that comes with 64-bit values (e.g. file offsets on a modern FS) in JavaScript and you'll see the pain.
The JavaScript implementation from Cadence that's used for scripting various IC design systems avoids this by providing the full Smalltalk set of number types (it's actually implemented in NewSpeak, which is implemented in Smalltalk, for extra fun).
It's also useful for providing an API that other tools can use. Lots of things can parse RSS feeds, not just readers, and it's a good way of providing activity indicators on other sites.
And, especially, the maps where I most want this are embedded (e.g. in a hotel side where I want to see how far the hotel is from the places I actually want to go) and so don't provide access to the directions bar.
I read a paper copy of it almost 10 years ago, so unfortunately I don't have one to hand, unfortunately.
There's a nice paper from the developers of the Apple Newton, which argues that class-based OO maps very well to model objects (where you have lots of objects that are mostly the same), whereas prototype-based OO is a better fit for views, where you want a bit of customisation for almost every instance. JavaScript is a language that is designed for UIs, with the back end being written in some other language, so it's hardly a surprise that it chose prototypes.
My biggest complaint about JavaScript is that, even with Smalltalk and Self as examples of languages that did it right that the developers were intimately familiar with, they still managed to get numbers wrong.
This would have been more funny 10 years ago when people still said 'Java applet' without laughing and both statements could have been applied to either language. I rather like the top answer though: 'Java and Javascript are similar like Car and Carpet are similar'.
Yes, exactly. Being old and cynical that was my thought too. Show source 'A' but compile from source 'B'. Then we'll truly 'experience their committment to transparency' won't we?
It depends on the threat model that you care about. On the one hand, it is bad if there are intentionally and maliciously injected trojans. On the other hand, the Snowden disclosures have shown that this is rarely done - it's high risk and there are enough vulnerabilities in code that the NSA can exploit without needing to do anything active to the supply chain. Being able to find these and get MS to fix them is probably quite important.
My main objection to this is that I don't like to see tax money being used to improve a single company's product.
USB C was something Apple gave the USB folks because they're just disgusted with the crap that is the USB connector
i second the 'huh?' from the other poster. Apple did grant the USB consortium some patents, but they were not involved with the design of the USB C connector at all. It was developed by a committee, with some fairly major contributions from Google.
Nokia has also been in the market of selling the infrastructure for mobile networks for a long time. And, unlike the handsets, this is a very profitable place to be. Both Nokia and Ericsson saw the commoditisation of the handset market and Nokia in particular watched their margins evaporate and decided it was time to get out. But because they're now no longer in the public eye, they're perceived as losing. Now their customers are people who make money from the products that they sell, so are willing to pay a reasonable premium because a few minutes of downtime costs far more.
Of course, when Apple decides to concentrate on the high-margin part of a business, no one claims that they're dying, because they concentrate on a consumer-visible part of the market.
There's some overlap. Altera FPGAs have lots of fixed-function blocks on them, ranging from simple block RAMs to fast floating point units. There's a good chance that Intel could reuse some of their existing designs (which, after all, are already optimised for their manufacturing process) from things like AVX units and caches on x86 chips. A lot of the FPGAs also include things like PCIe, USB, Ethernet and so on controllers. Again, Intel makes these in their chipset division and, again, they're optimised for Intel's process so being able to stick them on FPGAs instead of the Altera ones would make sense.
The main reason that you're probably right is that Intel is generally pretty bad at getting their own internal divisions to play nicely together, let alone ones that are used to being in a completely separate company.
You might want to look at the papers from MS Research on their use of FPGAs in their data centres.
My guess would be coarse-grained reconfigurable architectures. Altera FPGAs aren't just FPGAs, they also have a load of fixed-function blocks. The kinds of signal processing that the other poster talks about work because there are various floating point blocks on the FPGA and so you're using the programmable part to connect a sequence of these operations together without any instruction fetch/decode or register renaming overhead (you'd be surprised how much of the die area of a modern CPU is register renaming and how little is ALUs).
FPGAs are great for prototyping (we've built an experimental CPU as a softcore that runs on an Altera FPGA at 100MHz), but there are a lot of applications that could be made faster by being able to wire a set of SSE / AVX execution units together into a fixed chain and just fire data at them.
That minimum wage guy is one of the major costs for a taxi company. The IRS rates miles driven in a car at a little under 60/mile, which should cover maintenance, depreciation, insurance and fuel. A taxi that only had these costs could be quite profitable at 70/mile. In New York, taxis cost $2/mile, which isn't that far off other places in the USA. The minimum wage guy needs to be paid even when the taxi is waiting for the next fare. With an automated car, you'd just leave them scattered around the city powered down and turn on the closest one when you got a new job.
A Kickstarter-like model would work. Release a single for free, designate an amount that you think the full album is worth. If enough people are willing to pay, then you release the album for free. For the second album, hopefully enough people have copied the first that you don't need to do much to encourage them to pay for the second. As an added bonus, you can reduce your up-front costs by only renting the studio time to record the first track and only record the rest once people have paid for it.
Recording a song (at least, a song that people want to buy) requires talent, creativity, and often expensive instruments and studio time. Copying a song once it's recorded is basically free. Any business model that relies on doing the difficult thing for free and then trying to persuade people to pay for you to do the easy thing is doomed to failure. Imagine if Ford had noticed that people wanted coloured cars and decided to give away unpainted cars and charge for painting them, then bribed politicians to pass laws so that only Ford was allowed to paint cars Ford sold and driving an unpainted car on the road was illegal. It wouldn't take people long to realise that this was a stupid business model and that you could get rid of the laws and charge for the cars, but in the case of copyright people are still trying very hard to make the 'free car, expensive and exclusive paint' model work with different variations.
It's an ABI mismatch, and the summary is nonsense, saying almost the exact opposite of TFA (which I actually read, because the summary is obvious nonsense). The issue is that the Windows ABI defines long double as being a 64-bit floating point value (which is fine, because the only requirement for long double is that it have no less precision than double. If you're using it and expecting some guaranteed precision for vaguely portable code then you're an idiot). For some reason, MinGW (which aims to be ABI-compatible with MS, at least for C libraries) uses 80-bit x87 values for long double, so you get truncation. I forget the exact calling conventions for Windows i386, but I believe that in some cases this will be silently hidden, as the value will be passed in x87 register and so be transparently extended to 80 bits in the caller and truncated in the callee anyway. It's only if it's passed on the stack (or indirectly via a pointer) that it's a problem.
It's not obvious which definition of long double is better. On modern x86, you'll use SSE for 32- and 64-bit values, and may lose precision moving between x87 and SSE registers. You also get worse IEEE compliance out of the x87 unit, which may matter more than the extra 16 bits of precision. 80-bit floats are not available on any platform other than x86 (128-bit is more common, though PowerPC has its own special non-IEEE version of these and on some other platforms they're entirely done in software), so they're a bad choice if you want portable code that generates the same output on different platforms.
The same is true of university exams. My undergraduate exams, for example, mostly required that you answer two of three questions per exam. To get a first (for people outside the UK: the highest classification), you needed to get 70%. Most questions were around 40% knowledge and 60% application of the knowledge. If you could predict the topics that the examiner would pick, then that meant that you could immediately discard a third of the material. To get the top grade, you needed to get 100% in one question and 40% in another. This meant that you could understand a third of the material really well and understand another third well enough to get the repetition marks, but not the understanding ones and still get the top grade. This meant that you could study 50% of the material and still do very well in the exams, as long as you picked the correct 50%. And some of the lecturers were very predictable when setting exams...