The Big Programming Thread - Page 468

On April 14 2014 06:39 bangsholt wrote:


Why are you not converting the string date into a DateTime or something similar as soon as you can? You can always get the string representation at a later point - or even use Humanizer, if it's to show for a user.

http://www.hanselman.com/blog/NuGetPackageOfTheWeekHumanizerMakesNETDataTypesMoreHuman.aspx

On April 15 2014 03:19 Nesserev wrote:

Use regular expressions?

On April 14 2014 06:43 Manit0u wrote:


It all depends. I have a friend who quit uni because he couldn't be bothered with this kind of stuff and now is a top notch programmer working for big companies (Symantec, Oracle and such). What's most important in this business is the experience, nothing beats that. You can learn all you want from books/courses/studies but at the end of the day it all comes down to 'Are you experienced enough to do it without really thinking about it?'. That's the feeling I get when I'm asking my friends who are established programmers for some help. They're able to solve the problems that take me several hours in 5 minutes and do it way more efficiently and elegantly than I could ever hope to do now. Because they all have 10+ years in doing this stuff under their belts they know the realities, all the design patterns and best ways to do things inside out.

On April 15 2014 03:13 Manit0u wrote:Also, a stupid question perhaps, but related to the subject. Does C# have a method that would convert '000018920300' into '189203.00'?

The rather dirty way for me to do it was take it as a string, strip leading zeros, split into two substrings and join them with '.' to get the final string.

On April 14 2014 22:04 misirlou wrote:
I made a sieve with some optimizations, source at https://github.com/Misirlou/CparParallelSieve/blob/master/single.c
There are 3 different functions, named 1,2 and 3 . The first function is terribly slow for anything greater than n=2^27, that is computing all primes lower than 2^27. I can get the other ones to run till 2^33 under a minute. The 3rd function takes an extra argument that defines a block size. This is used to split the sieve into little pieces so the array gets stored in cache instead of RAM, which is a much faster memory, as the results I collected can prove, on google spreadsheet
I also stored the primes not as an int array but in a char array. Every bit of a char represents a number, so one char can hold 8 "numbers". If it's unmarked when the computation is finished, it means that number is a prime. I also don't have a position for even numbers, I skip them entirely because the only even number that is prime is 2. All of this was done in an effort to use the least amount of memory. The code gets a little more tricky and it takes more operations to access an element but these operations are meaningless compared to what I save in memory access.

On your code shouldn't marked and sieve be the same array?

On April 14 2014 22:04 misirlou wrote:
I made a sieve with some optimizations, source at https://github.com/Misirlou/CparParallelSieve/blob/master/single.c
There are 3 different functions, named 1,2 and 3 . The first function is terribly slow for anything greater than n=2^27, that is computing all primes lower than 2^27. I can get the other ones to run till 2^33 under a minute. The 3rd function takes an extra argument that defines a block size. This is used to split the sieve into little pieces so the array gets stored in cache instead of RAM, which is a much faster memory, as the results I collected can prove, on google spreadsheet
I also stored the primes not as an int array but in a char array. Every bit of a char represents a number, so one char can hold 8 "numbers". If it's unmarked when the computation is finished, it means that number is a prime. I also don't have a position for even numbers, I skip them entirely because the only even number that is prime is 2. All of this was done in an effort to use the least amount of memory. The code gets a little more tricky and it takes more operations to access an element but these operations are meaningless compared to what I save in memory access.

On your code shouldn't marked and sieve be the same array?

On April 15 2014 09:54 tofucake wrote:
Doing math in functional languages is simpler.

On April 15 2014 11:47 Manit0u wrote:


Might be a reason why most operating systems run on C and not higher-level stuff.

On April 15 2014 13:33 obesechicken13 wrote:

I thought higher level stuff had performance issues and that was the reason. Doing math in C is horrible compared to in R or matlab.

On April 16 2014 02:47 darkness wrote:


Well, that's why Java still keeps primitive data types despite Integer/Boolean/etc being redundant.

On April 15 2014 13:33 obesechicken13 wrote:

I thought higher level stuff had performance issues and that was the reason. Doing math in C is horrible compared to in R or matlab.

On April 16 2014 03:16 windzor wrote:


Java keeps primitive types because its too much of a hassle to remove it from the language, even though the big Java guys wants to remove them.

On April 15 2014 13:33 obesechicken13 wrote:

I thought higher level stuff had performance issues and that was the reason.

On April 15 2014 09:50 Nesserev wrote:
Can anyone tell me when it's better/more preferable to use a functional programming language like Haskell over an OO/Imperative programming language?

Some things are really easy/fast to code in functional programming languages compared to OO/Imperative programming languages, but I can't put a finger on what it is, or when this is the case. I had to program Battleships in Haskell, which was a total b!tch to be honest...

On April 16 2014 18:09 Ben... wrote:

A few years ago that certainly was the case. Haskell, for instance, used to be dreadfully slow. However, now it is approaching being nearly as fast as C, and a good Haskell programmer, just by virtue of the language, can write something significantly faster than a person doing something in C. Back in the day, computers used to be rather expensive so making code run as fast as possible was ideal. However, now we have fairly cheap computers that are quite powerful so the larger cost to a company will be the programmer, not the equipment used by that person, so if they can make that person more productive, it gives the company a better return for their money. The downside is that functional languages are really tricky to learn so you typically have to get really smart people, who might cost more money. But they will be able to code things much faster.

Of course when it comes to OSes and things like that, speed is still king, so the fastest languages will still be dominant. Being nearly as fast as C isn't the same as being as fast as C.

Which leads to this:


Though, with all of the huge security issues we've been seeing with stuff like Heartbleed and the above goto fail and GnuTLS, I wouldn't be shocked if certified programming becomes much more prevalent fairly soon. I've done a bit of it and it is pretty cool. The idea behind certified programming is basically that you can prove something does exactly what you say it does. This is done so mathematically via proofs. One of the more common certified programming languages, Coq (yup, that's the name), is very Haskell-like. It is a functional language in which types are handled in a very similar fashion. A lot of the code I have seen is basically Haskell code with a slightly more verbose syntax.

On April 16 2014 18:09 Ben... wrote:

A few years ago that certainly was the case. Haskell, for instance, used to be dreadfully slow. However, now it is approaching being nearly as fast as C, and a good Haskell programmer, just by virtue of the language, can write something significantly faster than a person doing something in C. Back in the day, computers used to be rather expensive so making code run as fast as possible was ideal. However, now we have fairly cheap computers that are quite powerful so the larger cost to a company will be the programmer, not the equipment used by that person, so if they can make that person more productive, it gives the company a better return for their money. The downside is that functional languages are really tricky to learn so you typically have to get really smart people, who might cost more money. But they will be able to code things much faster.

Of course when it comes to OSes and things like that, speed is still king, so the fastest languages will still be dominant. Being nearly as fast as C isn't the same as being as fast as C.

Which leads to this:


Code bloat and productivity of the programmer is what was often mentioned to us in my class that focused on functional languages. As you have probably experienced, code done in functional languages is significantly shorter than code from many imperative languages (for me, probably 2/3 to 3/4 of each haskell assignment was tests with maybe 50-100 lines of actual program code). This makes it significantly easier to maintain a database of code over time since all of the different pieces of code are upwards of 50-90% shorter than their C/Java counterparts. Also, due to the nature of functional languages, it is much less likely for there to be weird bugs introduced, simply because the code probably wouldn't compile due to how functional languages are structured. Of course I'm more talking things like merge mess ups or copy/paste errors. Stuff like the goto fail error we saw on the open source SSL implementation Apple was using would not likely have happened in Haskell because GHC would have complained. Probably the same for the 8 year old GnuTLS issues (From what I have read, those were pretty rough. C library functions that should not have been in such critical code, pieces of code for encrypting that didn't do what they were supposed to upon testing). This is all combined with the code being much simpler to read (after you know the language well of course) makes it so you can be much more productive with functional languages. Of course the downside is you have to be insanely smart to use functional languages effectively. But once you do, you can do some pretty crazy things with them. We built another programming language in Haskell in about 40 lines in total.

Though, with all of the huge security issues we've been seeing with stuff like Heartbleed and the above goto fail and GnuTLS, I wouldn't be shocked if certified programming becomes much more prevalent fairly soon. I've done a bit of it and it is pretty cool. The idea behind certified programming is basically that you can prove something does exactly what you say it does. This is done so mathematically via proofs. One of the more common certified programming languages, Coq (yup, that's the name), is very Haskell-like. It is a functional language in which types are handled in a very similar fashion. A lot of the code I have seen is basically Haskell code with a slightly more verbose syntax.